Request:Imagebuffers
BlitzMax Forums/BlitzMax Module Tweaks/Request:Imagebuffers
| ||
| Since BRL are entertaining this and polling for interest I thought I would raise the request for imagebuffers again. Can we have Imagebuffers please? <edit> P.S. my response to anybody saying that there are 3rd party mods available is "Great, shows it's possible. Lets have an official version". |
| ||
| You have pixmaps, isn't that good enough? |
| ||
| Might be. How do you paste another pixmap/Image with alpha/light/shade/whatever with masking or a rect/oval/line to another pixmap/image using native Bmax commands? |
| ||
| >> You have pixmaps, isn't that good enough? No. *g* |
| ||
| I'd like ImageBuffers too. |
| ||
| Well since images are textures you could always use render to texture. Your only issue is that the DX7 surfaces created by BMAX are not set-up as rendertargets. So you're stuck with pixmaps :) |
| ||
| I managed to get render to texture working to some degree. First, I made the Bmax textures non-auto managed so I could create them as rendertargets. This worked well with the downside that I'd have to create a texture manager. Second, I tried creating a seperate render texture and blitting it to the pixmap surface. This worked well except a) The texture got smaller each time (there is a note in my DX7 book that this might happen but nothing to say how to prevent it) and b) the blit only seemed to copy the original pixmap image and not anything rendered to it. I think you had a similar issue when you first tried. So, I could persevere, I could use your render-to-texture, I could use OGL and the HighGfx module etc etc etc. However, raising the request with BRL and, this time, hoping for an official response, seemed a good option. |
| ||
| How do you paste another pixmap/Image with alpha/light/shade/whatever with masking or a rect/oval/line to another pixmap/image using native Bmax commands? By taking the two pixmaps and modifying them accordingly. What you're asking for is render to texture, not image buffers. |
| ||
| Noel, what I am asking for is 'Imagebuffers' as in 'Setbuffer imagebuffer(blah)' from BB as you well know. Anyway, can you let me know how I take 2 pixmaps and modify them accordingly? Are you suggesting grabpixmap or writepixel or is there something else in Bmax I am not aware of? |
| ||
| I am suggesting you use WritePixel and modify the buffers as need be. SetBuffer with BlitzMax would require RTT which, as far as I can see, BRL does not exactly have a vested interest in adding support for something which may prove to introduce more incompatibility with hardware than necessary, since you'll then have to deal with fallbacks for cards without RTT support and that could get pretty messy. |
| ||
| It could yes ... but if we wanted to stay on stone age technology, we could have stayed with BB+ and B3D and there wouldn't have been a need for 2D in 3D which itself requires per default a 3D card (not a SiS, S3 or older Intel) ... There is not much of incompatibility to add ... all cards that are able to run BM with hardware acceleration will have the needed support as well ... those that don't have HA can skip it anyway due to significant inexistant speed. |
| ||
| Max automatically supports glCopyTexSubImage2D() and glCopyTexImage2D(). While these require you to draw to the backbuffer first, and to have such drawing and grabbing be an intermediary step (so not as efficient as directly rendering to the texture), it does let you get drawn graphics into a texture to use as you want. Rather than strictly being render to texture, it's more of a render to backbuffer and copy to texture. I agree with some other comments that it seems there are various compability and performance issues with regards to using the various texture rendering options, whether they be pbuffers, backbuffer objects, or whatever else. Some hardware may not support certain things and at the very least it would probably rely on OpenGL extensions, which are not always supported. No idea on the DX side but I'm sure there's similar issues. The big question is for what purpose do you need to render directly to a texture and is there a different approach you can take. |
| ||
| All cards from ATI and NVidia brought out in the last few years support render targets ... even my crappy old GF440 Go did it 4 years ago ... So no prob on the DX side there. And if I remember correctly, the pBuffer tests we did back that days (for similar reasons btw) worked as well. And its a fair assumption that users will have ATI or NV ... because if they have Intel you will have going to have quite some fun with them ... or their problems I should better say ... (thats what I've seeing on Torque GameBuilder EA boards for over a year now ... SiS are even worse in supporting 2D through 3D) |
| ||
| And its a fair assumption that users will have ATI or NV ... because if they have Intel you will have going to have quite some fun with them If I recall correctly, Intel was the most wide-spread for video cards. I wouldn't make the assumption that people have any specific brand of card for what most people here are doing. It should be compatible with a specific range of cards, and Intel cards should be among them whether or not they are bad. |
| ||
| I have an Intel gfx card on this desktop PC.... and those new Mac laptops (the cheaper dual-core gizmos) are also coming with intel gfx cards, I believe. Best not to assume things ;-) |
| ||
| There are a number of ways to 'render to texture' with DX7. a) Render directly onto the texture. This is not possible in Bmax as it uses DDSCAPS2_TEXTUREMANAGE to create the surface in TD3D7ImageFrame.create. b) Render to surface then blt to texture. This is what I am trying in another thread. The render to surface seems OK but I am having problems getting the blit to 'stick'. c) Render to backbuffer and blt (bitblt) to texture. Basically this is what GrabPixmap does. d) Software rendering. here is an article which discussed each and their uses. This should allow plenty of fallback for cards which don't support render to texture. In addition, each time this request is raised, we discuss whether imagebuffers are required. Here is the documentation for B3D Imagebuffers... There are 1000 reasons for this command. Simply put, you may want to 'draw' on an existing image you've loaded (LoadImage or LoadAnimImage) or created (CreateImage). You could, for example, have a blank wall graphic and you want to add 'graffiti' to it based on the user action (Jet Grind Radio baybeee! Sorry...). Instead of trying to draw a dozen images all over the wall, just use the SetBuffer command to denote the wall graphic as the 'target' buffer, and draw away! Next time you display that graphic (DrawImage), you will see your changes! This is a powerful command! You take a base sprite and paste additional sprites on top (armour, shields, swords, shirts etc etc). I have a semi-solution for this but it doesn't allow ovals, rects etc or for blend modes. So, good enough for BB but not Bmax? BRL responded a couple of years ago stating that Imagebuffers were not implemented as an OGL solution could not be included without using extensions. BRL wanted the product to mature before using extensions. Is the product ready? The question of whether the same can be achieved in a different way. The solution was always to draw to backbuffer and grabpixmap. This is workable, can be slow and, for some people, complicate the draw process. If somebody has a better solution, I would appreciate it. Finally, Tim's render-to-texture does just that. As far as I can see it doesn't alter the base image as the BB Imagebuffer used to do. Hopefully that explains people's queries so far. BRL, is there any chance of this ever happening? |
| ||
| If somebody has a better solution, I would appreciate it. I like my solution best: write your own 2D code. It's what I did, beats the living daylights out of Max2D too. Then again, it's not really hard to put Max2D to shame. |
| ||
| I'm thinking of having a Bmax 'standalone' system where I change the code and never syncmod. I did ask BRL what plans they had for MAX2D (et al) to see if now is the time to do it but didn't get a response. It's a shame, but inevitable I suppose, that you buy something so you don't have to do the nitty-gritty stuff yourself then find it's missing things you want. I reckon, at some point, I will get this working and, sod's law, when I do BRL will announce it's inclusion into Bmax 1.2x |
| ||
| Noel: I don't make the assumption out of sight of "what is spread the most" ... I make it from the point, that intel users will definitely suffer bad problems! The new drivers that came after jan 06 have massive OpenGL problems and other new introduced problems as well ... So unless BM gets a DX9 driver on Windows, forget Intel as acceptable system requirement, it will definitely cause problems. smaller or larger depending on what you try to achieve. But to tell the truth: That doesn't make me wonder. Why should it? Intel cards are for 2 purposes: Office and home Entertainment. They are exceptionaly useless when it comes to realtime 3D, even when they have Shader 3 support ... (half as fast as GF6200TC which is already that slow that CPU emulation won't lack that far behind with a usefully fast CPU). And as we all know: BM is 2D in 3D which means that the card definitely needs to be 3D capable ... and due to the fact that all images are always directly in front of the camera, the card should have an acceptable bandwidth etc ... They only got 3D support to feature everything XP needed (on past chips) and Vista Aero (on current and future versions). |
| ||
| I'll take this oppotunity to say 'yes please' one more time. tony's method c) up above is horrendously slow on Vista under DX. It wasn't too flashy on XP either but it was usable for some things - on Vista it crawls at about 1 frame per 30 seconds. |
| ||
| As grabpixmap uses bitblt I have a horrible feeling that it's not possible to blt directly to an image's surface. This rules out b). I tried running with Texturemanage off but white images when using multiple textures. Finally, it might be possible to use single pass multitexturing. I've got multipass working for something else so just a case of finding the correct renderstage options. BRL, you could put me out of my misery by sharing your thoughts. |
   |