New TMap vs ImageBuffer
BlitzMax Forums/BlitzMax Module Tweaks/New TMap vs ImageBuffer
| ||
| I would guess that 80%+ of people who own Bmax don't know what TMap is for or don't even know it exists. I would also guess that close to 80% of people would like to see the return of *official* Imagebuffers a la B2D/B3D. Mark, I know you like coding the tricky stuff but couldn't you stop me moaning about Imagebuffers by either providing them, helping me out on my attempt Imagebuffers : Sort of or providing some doc on the current DX texture implementation. I know Bmax is not a democracy but it would be much appreciated. p.s. If it's in the next big update please tell me as I keep returning to my code 'just one more time' and it's beginning to hurt. |
| ||
| All of this TMap talk is so weirdly timed. I just this morning was writing something and thought, "Man, I wish there was a map or dictionary class in BlitzMax". For the hell of it, I checked out the mod directory and ... whoah, map.mod! Score! It works well. It's a shame it isn't documented. |
| ||
| map got a procedural functionionality with its syncmod today so I assume it has now docs as well (it was OO only before). Its now a balanced tree as well :) tonyg: The main problem is: OpenGL does not have surfaces like DX which is the reason there is no such thing as imagebuffers. There are extensions to do the similar thing thought ... |
| ||
| Diablo's HighGFX managed to use the extension. I've managed it with DX but, in both cases I think, it's moving the manually created image back to a Bmax managed image/texture. |
| ||
| Aren't those "image buffer fakes" basing on Render to Texture? Because that isn't the same as image buffers (dx surface or opengl pBuffer) (if you use B3D you will learn that quite fast. Actual NVidia driver don't even let you draw images to texturebuffers anymore nor anything else beside the per pixel draw ops like drawline etc. Drawing text has been broken for quite some time) |
| ||
| I'm talking about the functionality of the ImageBuffer B3D/B2D concept and not the technicalities of it. |
| ||
| What exact functionality are you after then? And to help us better understand, why? |
| ||
| tonyg: The problem is that the techicalities mathers in this case. What does it help if you have something similar to B3D texturebuffers if it only works on Intel crap cards? Right, nothing! And for render to texture, you can use indiepaths module. It works with DX and OpenGL on all system that are able to use rendertargets (newer intel, ATI and NVIDIA, the rest is out). The only other possibility that does not cut anyone out is simply use Pixmaps and do your operations on them. |
| ||
| I would like an official, supported module which allows me to 'render' to a Bmax managed texture/image. Whether this is *really* rendering to that texture or some jiggery-pokery I don't care as long as it's close to real-time. As to why... 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! My main use for it in BB was Composite Sprites. Here's some previous discussion <EDIT> Indie and Diablos RTT methods do that.. render to a non-Bmax managed texture. The next step I would like is to then blt/replace/load/whatever that unmanaged texture into Bmax control. I'm close to doing it (messily) myself... Cry for help |
| ||
| I thought they use BM textures. They just create the surface manually (DX side) because the way BM creates them does not allow them to become render targets (which makes sense as they weren't meant as such :) ). At best, BM would allow rendertarget textures through a flag, similar to the current existing ones and then you could render to them through setbuffer like commands ... ie still more or less the way indiepaths module does it ... just "officially" in ... ^^ If the Max2D core classes were implemented fully BM side all would be less of a problem as we could simply extend the object and make it an additional module. Sadly TImage is heavily procedural based which means a new object is needed as extending isn't of much use. |
| ||
| Fantastic! So it can be done, so BRL could produce an official module. Superb! Thanks for all your help. |
| ||
| Well if anyone can do it, of course BRL can ;] |
| ||
| skid, did you ask for more information for a reason? |
| ||
| Can the accumulation buffer be used to keep a reliable backup of the backbuffer that can then be restored and drawn on top of? Might solve some engine needs. Also Opengl glCopyTexImage2D() works pretty well. I do a full-screen grab into a texture after drawing to the backbuffer and then re-draw that texture. At least on my NVidea GeForce4MX its' fast enough to be 30fps in a high resolution for RGBA textures. You do have the bottleneck of having to draw to the backbuffer first then grab it which isn't as quick as directly drawing to a texture. But hey. You basically are going to need more up to date hardare and sofware in order to directly draw to the textures. Maybe you can support it through extensions if it is enabled and if not fall back to some slower method. |
| ||
| What I would like to know is what is it that you are drawing on top of what and why, and how much of it, and how often, and how long is it on-screen in that state, and why does it need to be permanently written to the image rather than merge the images realtime? |
| ||
| what is it that you are drawing on top of what composite sprites. and why so they can change equipment or take damage and how much of it every animation cell for all characters that can change equipment how often not too often. and how long is it on-screen in that state until one of the characters picks up another piece of equipment, changes from their inventory or takes damage and why does it need to be permanently written to the image rather than merge the images realtime? because there could be multiple composite sprites with multiple 'bits' and multiple damage which would make drawing each each frame a frame hog. . Anyway, don't let it worry you. When it comes to it I'll find a way. My main reason for bumping is that Skidracer asked as if interested but never responded. <edit> For more info |
| ||
| Ok, this is the first I've heard of TMAP. I looked it up in the *ever so ambiguous* BMax documentation, and found a bunch of functions with even more ambiguous descriptions. What is it, and how do I use it? |
| ||
| What is it, and how do I use it? It's a container class, a bit like TList, except that objects are stored in a TMap with a "Key" instead of just stuck in a long list. Objects are then retrieved from the TMap by providing the "key" again. The key can be anything, but the most simple use would be to provide a string. Searching for a particular object in a TMap is much faster than searching in a list because the TMap is sorted by the Key. So if the keys are strings, it's sorted alphabetically, like a dictionary. You don't sort the Map manually though, it's kept in a sorted state automatically. When you insert a new object, it is placed into the Map at the correct point to keep the keys in sort order. |
| ||
| OH! It's a Hash Table. |
| ||
| ImageBuffers can't easily be done because everything is 3D now, and 'render to texture' is not at all widely supported - esp. on both D3D and GL. The only sane alternative woould be to use a software renderer - but this would not be anywhere near 'near realtime', and is only really an option under GL. |
| ||
| Sure on that? Because there were test done a year ago with render targets and even thought the support was "hacked" in it worked quite good (sie Indiepath's render2texture). I thought R2T is a DX9 default feature. It might not be that fast on all cards, but any so called 3D card supports it. (even Intel Extreme 2 (GMA 900)) Especially the point you mention "its all 3D now" would really benefit of this at least unless BM learns some kind of image grouping into a single vertex array or a similar more performant structure than tousands of single quads as it currently is, in which case at least some cases where R2T now is the only way (One of these cases are large part with static pixel data, which need to be redrawn over and over again which costs a fair amount of time otherwise not needed. Blitz3D had the CamCLSMode to prevent static data beeing dropped on renderworld but now all is part of flip and highly uncontrollable) I'm aware that some of the used terminilogy might be wrong or to "B3D focused", but I used them to show more clearly what I mean. |
| ||
| I know this is an OOOLLLDDDD post - but I'm feeling the same pain. It would be very helpful to pick a target for drawing operations! (you can now, sort of, but creating a new graphics object also creates a new window! Yuck!) |
   |