Drawing to an imagebuffer

My apologies for bringing this up again, but I was wondering if there's been any progress on this during my absense.

Ultimately a 2D in 3D system that allows drawing to an imagebuffer is what I would like, but I'm thinking I may have to settle for B3DSDK. What about CobraSDK/Ion/whatever? Did that ever become usable outside of the Cobra environment yet?

It actually looks like very little progress has been made with anything in the last 1-2 years actually. Except for BVM2 =]

Any reason you aren't using Pixmaps?

Buffer drawing is much faster, and theres no reason for bmax not to have them.

Pixmaps are a joke for real time operations.

I miss the imagebuffer too. (It was a great thing in BlitzPlus. Why did it disappear?)

I *think* we don't have an imagebuffer/texturebuffer capability because the DX module uses automatic memory management.
Mark has never said why he isn't interested in adding it. I got the feeling he was expecting the community to come up with a solution. A few people have tried but it's never really been successful. The best attempts have been scuppered by changes to Bmax core.
This works on one of my machine but not on my laptop. The view is too small.
This covers the OGL side of it... I think.

The reason is simple:
There is not a real option for the OpenGL Driver.

glCopyTexImage2D , works, but is not a real render2texture or renderbuffer
pBuffer are not supported in Bmax and they are windows only
FBOs (Framebuffer Objects) the only real and fast way to have texture or imagebuffers are only supported in
newer hardware and so also no option.

If you want to have r2t then use the glCopyTexImage2D approach (faster than Grabimage) or the FBO approach (very driver and gfx card dependent)

FBO ImageBuffer: http://www.blitzbasic.com/codearcs/codearcs.php?code=2222

True? I thought the point behind OpenGL was that it was standardised regardless of platform?

I think pbuffers were OGL 1.2 while Bmax is based on 1.1. You can get them via glew but, from a 3 year old post, BRL wanted to get the core working before they started adding additional functionality.

yes, its true.
pbuffer is a wgl extension (windows graphics library) called WGL_ARB_pbuffer.
If you want to use it, you need to include the wgl.h header file, because its the location where
the pbuffer handling is defined. And I guess this header file is not wrapped because its windows only
and thats against blitzmax crossplatform orientation.

It was planned to make this extension available to other platforms as well, but it seems that it was
never done.

All right then, thanks. Please indulge me further...


Is the r2t/glCopyTexImage2D approach suitable for say erasing parts of an image? I actually need this for the opposite reason of most other people - instead of needing to draw stuff onto an image and have that on the image forever I need to start off with an image and remove sections of it randomly.

This image is then used for pixel perfect collision detection...

Additionally I presume if I were to take a r2t approach (if it is even suitable) I would need to chop it up into square sized textures for this to work (as the image can be many thousands of pixels wide or high)?

Does this help?
It's not ideal but might be good enough.

Ugh. It's all so messy these days...

Thanks tonyg, I will look into that further. Thanks also Gfk, looks like pixmaps may be my most likely option (oh, the pain)...

An alternative I've been thinking of is buying the B3DSDK and nSprite/Sprite Candy/something. Although limiting myself to Windows and effectively recreating something I should have access to in Max anyway, if I were to do enough digging (but I am oh so lazy). Although I would prefer for it to all be Max native, so maybe I'm leaning away from this line of thinking.

Must say I didn't look in the beginner sections for topics of this nature as I assumed this was not really a beginner topic. Will delve deeper. =]