Offscreen drawing - superbitmaps and scrolling
BlitzMax Forums/BlitzMax Beginners Area/Offscreen drawing - superbitmaps and scrolling
| ||
| I noticed that all objects drawn to the display in Max2D are clipped automatically. If I want to maintain a `superbitmap` larger than the display, and I want to be able to use Max2D to draw to it, how can I do that? Is it able? How would I go about drawing offscreen to a larger image? Would I have to go about rendering to it using some kind of custom routine accessing a locked image? Also, are images stored in regular ram or video ram and is there a limit on size etc? On the same kind of topic, how would anyone who wants to create a scrolling tile-based engine go about rendering the tiles offscreen and have the display scroll? Is the only option to completely redraw the entire screen content every frame? How can scrolling be implemented? |
| ||
| You normally only display the tiles that are going to be drawn onscreen (+1 in each direction).. If you were to draw all the tiles on a map each frame, it would be very slow... About the bitmap larger than the screen topic.. I don't know. |
| ||
| Hmmmm, anyone else? There's gotta be a way. |
| ||
| I don't see a built-in way to copy rectangular regions between images/pixmaps, unless one is the back buffer. It may be that you have to write a custom routine to copy rectangular regions between pixmaps using ReadPixel and WritePixel. |
| ||
| Well it's technically possible, but probably not incredibly efficient, and would likely look less than brilliant on all but the most advanced 3D hardware. A more managable approach would be to split your superbitmap up into tiles, and yes, you would have to draw them all each frame. The best (only?) way to modify an image, is writing directly to its pixmap. If you can find Simons bpaint example, there's a demo of how to do it safely there. If memory serves, Images are stored primarilly in video RAM (when available) and pixmaps primarilly in 'regular' memory. Allthough don't quote me on that because it might not be factually accurate, because I can't remember where I read it , or whether I just made it up entirely. A bit stressed out at the moment you see... |
| ||
| Mikkel! Hey, this is Paul West of Mildred fame. How's it going? The idea of splitting a superbitmap into tiles - ie individual images, is daunting because it would totally complicate processing of the bitmap - the superbitmap needs to be radically modified a lot and I'm sure changes would have to cross tile boundaries. I'm sure there's a way to get it to work, maybe we need to come up with a `rectanglecopy` command. That would be perfect. What's new with you these days Mikkel? |
| ||
| is daunting because it would totally complicate processing of the bitmap Oh I agree completely. It's a bit like programming cool effects for the PC back when you had to worry about 64K segmented memory boundries.Unfortunately I don't see any other way ATM. I'm sure there's a way to get it to work, maybe we need to come up with a `rectanglecopy` command. It's hard to say. The way I understand Images working it's probably not very feasible. I'm gonna do a couple of tests in a couple of days, and post the results. What's new with you these days Mikkel? Back at Uni, trying to earn my degree. 2 Days until our semester project is due, we're not even half done (might be a slight exageration, but it sure feels like it), and I'm spending too much time on the Blitz forums (if you ask my project group that is)! :o> |
| ||
| Heh heh. They'd prolly be right tho ;] |
| ||
| Well you you know you gotta get your priorities right. BlitzMax first, uni second ;-) |
| ||
| Would it be possible to create a bitmap/image larger then the current screen resolution using OpenGL (ie: OpenGL Context), then EndGraphics and return to regular BMAX mode? Or is this a limitation of OpenGL? L8r, |
| ||
| Not sure why you'd want to do that?? I'm sure you can create images and pixmaps larger than the display ... although you're gunna need plenty of video memory to accomodate a large superbitmap. I need to use a superbitmap to maintain per-pixel state. But getting the OpenGL to display a portion of that image is the problem. Our imac has a whopping 64mb of video ram (which is perfect to use a bit superbitmap image - although 32-bit color takes up a lot of space) ... but the loly ibook only has 4mb (eek). |
| ||
| Heh heh. They'd prolly be right tho ;] I'm not saying they aren't. I'm saying that until they clock as many hours on the project, and get as good grades, they have no right to bitch! :o> Well you you know you gotta get your priorities right. BlitzMax first, uni second ;-) Well as long as I can get away with it, yeah! But getting the OpenGL to display a portion of that image is the problem. Yup. I'm still going to go with "break it up into smaller images". I'm guessing there's some sort of complexity/performance middle ground, and maybe you could dynamically rebuild some parts of the bitmap that get changed often.I have a theory on how something like this could be implemented, and I'll give it a shot over the weekends'ish, and see what I can come up with. Out of curiousity what do you need it for? If I could simulate something like Worms, would that be good enough for what you need it for? |
| ||
| "Out of curiousity what do you need it for? If I could simulate something like Worms, would that be good enough for what you need it for? " You'd be about on the right track. ;-) I came up with much the same conclusion as to the breaking it up into tiles and updating changes, last night :_) |
   |