How to draw to a buffer?
BlitzMax Forums/BlitzMax Programming/How to draw to a buffer?
| ||
| I cant find any commands that allow you to draw an image to an intermediate image/buffer....they all draw direct to the screen. |
| ||
| Direct on the backbuffer you mean, from where you can grab them again as image or pixmap You can't draw onto a buffer |
| ||
| You would probably have to use pixmaps so that you can copy an area from one pixmap to another. Images are usually kept in videoram as openGl textures, although you can get the image's pixmap and write to that. Not sure exactly what command you would use though. |
| ||
| You can get two pixmaps (either from images or as standalone pixmaps), and use copymem to copy the data, or some custom routine? I find it a little bit awkward that in BlitzMax you are only allowed to do PeekLong and PokeLong (and such) to Banks, not just to whatever memory pointer you have. |
| ||
| Nah, looks like it can be done by going into the raw opengl mode. |
| ||
| I'd like to know this too, as there's no sign of SetBuffer ImageBuffer(etc). CreateImage, is in the mix. But the most handy and useful of commands is missing. And not talking about OpenGL - normal 2D drawing. Any ideas, and will it be featured in the Modules? |
| ||
| Im also missing this very much :/ |
| ||
| More discussion... here and in the 'Feature Requests thread. I think it's unlikely they'll be included but I'd like to be proved wrong. |
| ||
| SetBuffer is an absolute must though. Everyone uses it, and it's proving really annoying that it isnt present in BMAX. And there's going to be many many more people asking for it, once BMAX windows is out of Beta. |
| ||
| I agree. |
| ||
| OpenGL doesn't support it in base form, though I believe extensions allow it (meaning it won't work on all cards). I think Mark wants to make sure the base stuff is covered before getting into extensions... |
| ||
| I wonder how libraries like SDL manage it. I think SDL works on OpenGL 1.1. |
| ||
| so is there then a work around? Please bring it into BMAX though, as Buffers are golden. |
| ||
| I don't know how SDL manages it. It could be based on stuff similar to what BMAX already offers: drawing to BackBuffer and then grabbing the image / manipulating pixels of pixmaps. In general BMAX should be fast enough to prevent the need to draw to other buffers. Has anyone really faced a situation in which they really need drawing to another buffers? |
| ||
| Has anyone really faced a situation in which they really need drawing to another buffers? It all depends what has changed in Bmx since Blitzbasic where the doc states... "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!" It was deemed important then (and I used it quite often) and, from it's omission, I guess it's deemed unimportant now. I'm just not sure why it's no longer necessary. We can draw to the backbuffer but we could have done that in BlitzBasic. The drawing is quicker in Bmx but you have to grab and convert from/to pixmap which slows it down somewhat. I'm guessing it's an OGL limitation which wasn't worth coding around. I could be wrong. |
| ||
| > Has anyone really faced a situation in which they really need drawing to another buffers? For a drawing program with a huge image it would be handy. Sure it could be done by doing it one step at a time on the backbuffer but it's just easier being able to do it on the buffer. |
| ||
| It was deemed important then (and I used it quite often) and, from it's omission, I guess it's deemed unimportant now. I'm just not sure why it's no longer necessary. Tony, could you read what I posted up there ^^^ ? I used buffers quite often too, and would now, but the core stuff (without extensions) needs to be solid for now, particularly as most platforms are still in beta. |
| ||
| In the past drawing on screen was relatively slow, while there was lots of memory to waste. That lead to the use of memory buffers to make actual drawing to screen faster (by having less drawing calls). What has changed is that drawing is now handled by the hardware accelerator. It means that now drawing to screen is VERY fast, while available memory is limited. |
| ||
| dynaman, True, that's one case where buffers would be handy. But you must admit that it's quite an exceptional case. |
| ||
| Yup - but it's the first thing I tried to do... |
| ||
| Example, say I have some scrolling text comming across the screen, and I want to have it wobble - much better to have it set to an imagebuffer and then using DrawImageRect to give a much better sin/cos with. It how iver always done it, and it vely hard to do alot of things without setbuffer. I even tried grabimage a lot of times and it just crashed the program. for no reason at all. Just a small plea, stick it on the list! |
| ||
| /me uses hand signals... he said... it's not gonna... happen... in the short term... making sure... CORE... is solid... THEN... worky on... extensions... |
| ||
| he said... it's not gonna... happen... in the short term... making sure... CORE... is solid... THEN... worky on... extensions... Thanks, though I'm not making any promises as to Mark's intentions here, with regards to extensions-based features! Just seems sensible to point out he has to at least get the base stuff solid before looking any further. |
| ||
| Quite understandable BS, it's quite a job I'd of suspected to get a programming language up and running. Same goes for all at BR, nice work. And cant wait for future prospects. |
| ||
| /me uses hand signals... he said... it's not gonna... happen... in the short term... making sure... CORE... is solid... THEN... worky on... extensions... /me responds using famous Agincourt handsignal and reminding Kanati that 'getkey' was a big issue at one point. I realise this is a different situation but if the command was, and is still, considered 'powerful' then I see nothing wrong in a few people requesting it, at least, gets on the 'to-do' list and, if already on, gets bumped up the list a bit. I don't think anybody needs to justify why they think it's an important command as BRL have stated so. The demise of the poor imagebuffer command. From 'powerful' to non-base stuff... bless it!! P.S. I guess it's this... http://oss.sgi.com/projects/ogl-sample/registry/ARB/pixel_buffer_object.txt or maybe this... http://www.opengl.org/documentation/extensions/EXT_framebuffer_object.txt |
| ||
| The ability to blit to an intermediate buffer is the backbone of decent scrolling. |
| ||
| I created a maze generator (actually adapted an existing project from a TrueVision3D user), which could draw a maze of 500x500 squares. In B3D I used a separate ImageBuffer to do the drawing, because the backbuffer (and frontbuffer) wasn't big enough. I then saved that ImageBuffer to disk and there I had my maze in BMP format. Without the possibility of drawing to other buffers in BMax, I cannot easily convert my B3D code into BMax. I can also imagine that, when creating a sort of Super Mario Bros style game (horizontal scrolling of a level), it could benefit from drawing to other buffers. Then you could create a new image, with the total size of the level, draw all level-data (static building-blocks) to this image at the start of the level and just draw that image to the screen, relative to the player's position. If the player moves to the right, then draw that level-image a bit more to the left and you get horizontal scrolling. |
| ||
| There are some good points about scrolling techniques needing extra buffers. However, with faster hardware and accelerated graphics it shouldn't be a problem to redraw the entire display each frame. A preserving scroll routine is something born out of not enough CPU power on older computers. Lots of people came up with clever techniques to get things to scroll smoothly doing the minimum amount of graphics rendering each frame. But now most people are likely to have enough CPU and GPU power to just rebuild the whole screen each frame - which not only makes things a lot easier it also gives you more animation options. However, I can definitely see that it would be desirable to have buffers to support superbitmaps. Let's say you transfer the visible portion of a superbitmap from a pixamp into a set of images, then render them, then you want to modify them in some way - e.g. deformable landscape or paint program, and store the results so that the next frame you can render the images again without having to re-copy the whole screen over from the pixmap. And when certain portions go out of view you'd want to offload them to the pixmap for storage. This would definitely need a use of buffers ie the ability to draw to textures at a fast rate. Grab Image doesn't seem to be very quick and introduces extra steps that would be otherwise unnecessary. Still, has anyone tried using, for example, the accumulation buffer or some other buffer as temporary storage? |
   |