How do you do "multilayered" tilemapping in max?
BlitzMax Forums/BlitzMax Beginners Area/How do you do "multilayered" tilemapping in max?
| ||
| Hey peeps Okay, so in blitz2d you have image buffers and could write to any one of those at any time, allowing me to write certain tiles to certain buffers and allowing me to Z-order things. (no, z-ordering isnt what im trying to do here, thats just what i used to use this technique for) In max, you can only write to the back buffer, right? this causes a problem: i want to write my tiles to the backbuffer, and at a certian point i may find somewhere where i want to draw an effect. I would then previously have drawn my effect to the backbuffer last after rendering it to an image buffer and drawing all player stuff. how would i now render this effect without messing up the contents of the backbuffer? Heres another issue: im doing a GUI that works by rendering its windows to an image, only now i have to render the window to the backbuffer and copy it across using some copyimage/copypixelmap routines (which take time). BUT ive just overwritten what ive been rendering.... Well, i hope you can see my problem anyway... theres probrably a very easy quick fix, but how can i draw to an imagebuffer things like rectangles,triangles,lines???? Cheers for your help again peeps |
| ||
| I asked something similar... http://www.blitzbasic.com/Community/posts.php?topic=42118 I will sorely miss imagebuffers. |
| ||
| How sad :( i'l continue on my way trying to create a kludgefix. I wonder if buffers will return? |
| ||
| something else while im here... i wish windows would allow us to directly access memory.. like qbasic did... people dont realise how much faster this would be even if we had to do things ourselves :( currently in max2d, its more effort to re-write den bros 3 than it was to write it in Qbasic. The 3D side of things, wow. i mean, the power is there- its not even that difficult to write a 3d engine and make games with it... but 2d is struggling.itl change though, with the power available. :) |
| ||
| I would then previously have drawn my effect to the backbuffer last after rendering it to an image buffer and drawing all player stuff. how would i now render this effect without messing up the contents of the backbuffer? I'm not sure I understand. Why is messing up the backbuffer an issue? BUT ive just overwritten what ive been rendering.... Then a) Draw it in the correct place (or one of the correct places) from the start, or b) Draw it before you do any rendering, then do the copy thing, then render game graphics, then render GUI overlay.Depending on the complexity of the GUI, it might be just as fast to just draw the entire GUI every time. |
| ||
| FlameDuck, youre missing the point. Imagebuffers kept things quick and easy. The problem with drawing them in the first place would be that upon continuing drawing the tiles, the effect would get overwritten. The fact that the above can with careful use be gotten around is true. Also, "Do the copy thing".... the "copy thing" seems deadly slow from here weather i use pixmaps or images often dropping the framerate to 10-11fps from 60. Copying plain pixels from buffer to buffer before avoided the complexity of all these issues. The original issue i wrote of above (with the multilayered tiles) ive gotten around because the collision commands (which i do like!) allowing collision layers like Qbasic and DirectQB did it. I suppose im generally not all that impressed with the Max2D module. With a bit ofknowledge, i may write something to bring back the old buffers. :) |
| ||
| FlameDuck, youre missing the point. Imagebuffers kept things quick and easy. I know. However the ability to have multiple Lists will acheive the exact same effect. The problem with drawing them in the first place would be that upon continuing drawing the tiles, the effect would get overwritten. No. You can do Z-ordering in seperate TLists instead of seperate images. Just add the Images in the same Z "space" to the same list, then add those lists to a bigger list in the correct "back to front" z-order, and viola! (It's called "composite pattern").[qutoe]Also, "Do the copy thing".... the "copy thing" seems deadly slow from here[/quote]GrabImage is that slow on your PC? With a bit ofknowledge, i may write something to bring back the old buffers. :) Well I'm sure many will appreciate it, but I'm just not entirely sure it's really worth it TBH. Incidently, you could probably use the composite pattern to get around your GUI problem too (it was originally meant to solve just that issue). |
| ||
| Grabimage is deadly slow on any system as it grabs a pixmap and converts grabpixmap is worlds faster |
| ||
| Well, it does take a bit of getting used to, how everything works in BlitzMax. I think that overall OpenGL based rendering is a good idea, it's a well-supported industry standard, it's fast with good hardware and has lots of flexibility. You might get lucky in that maybe some auxiliary color buffers are supported in most OpenGL implementations. I have no idea how widely supported they are, but they do act as additional backbuffers. You can redirect all drawing routines to output to a different buffer and then use something like CopyPixels to copy it over to the backbuffer. If auxiliary buffers are not available maybe you'll get lucky that a given OpenGL implementation supports stereoscopic views, ie you get extra left and right buffers. Given that the OpenGL rendering library is quite sophisticated, Max2D is really an attempt to make it more palatable for most of us by providing some of the more basic higher-level functions you would expect, like as you say the buffers in previous versions of Blitz. You could possibly use some kind of custom rendering code to draw everything to a pixmap and then just copy it over (albeit more slowly). I think there are some omissions from Max2D and things that can be improved and added to but I'm sure such thoughts are in the pipeline. As far as GUI's and screen refreshing go, it seems trendy these days to throw as much muscle behind the rendering process as possible and just redraw the whole screen each frame. In days gone by people came up with more ingenious ways to drastically reduce the amount of rendering needed and it all worked fine. However, there are some benefits to updating everything every frame - animating stuff is almost for free, and besides OpenGL doesn't really support hardware scrolling - which complicates matters. You could just redraw your whole GUI ever frame, or at least keep it in textures and draw them each frame, only updating the textures when things need to change? Or assemble textures cleverly so you only have to update the minimal amount and make your GUI like a mosaic. Anyway, from the OpenGL red book..chapter 10, at http://fly.cc.fer.hr/~unreal/theredbook/chapter10.html ------- An OpenGL system can manipulate the following buffers: Color buffers: front-left, front-right, back-left, back-right, and any number of auxiliary color buffers Depth buffer Stencil buffer Accumulation buffer Your particular OpenGL implementation determines which buffers are available and how many bits per pixel each holds. Additionally, you can have multiple visuals, or window types, that have different buffers available. At a minimum, you're guaranteed to have one color buffer for use in RGBA mode with associated stencil, depth, and accumulation buffers that have color components of nonzero size, and one color buffer for use in color-index mode with associated depth and stencil buffers. also... Color Buffers The color buffers are usually the ones you draw to. They contain either color-index or RGB color data and may also contain alpha values. An OpenGL implementation that supports stereoscopic viewing has left and right color buffers for the left and right stereo images. If stereo isn't supported, only the left buffers are used. Similarly, double-buffered systems have front and back buffers, and a single-buffered system has the front buffers only. Every OpenGL implementation must provide a front-left color buffer. Up to four optional, nondisplayable auxiliary color buffers can also be supported. OpenGL doesn't specify any particular uses for these buffers, so you can define and use them however you please. For example, you might use them for saving an image that you use repeatedly; rather than redrawing the image, you can just copy it into the usual color buffers. See the description of glCopyPixels() in "Reading, Writing, and Copying Pixel Data" for more information about how to do this. You can use GL_STEREO or GL_DOUBLE_BUFFER with glGetBooleanv() to find out if your system supports stereo (that is, has left and right buffers) or double-buffering (has front and back buffers). To find out how many auxiliary buffers are present, use glGetIntegerv() with GL_AUX_BUFFERS. also... Selecting Color Buffers for Writing The results of a drawing operation can go into any of the color buffers: front, back, front-left, back-left, front-right, back-right, or any of the auxiliary buffers. You can choose an individual buffer to be the drawing target, or you can also set the target to be a combination of these buffers. In a double-buffered application, for example, you might want to draw a common background into both the back and front buffers; from then on, you want to draw only in the back buffer (and swap the buffers when you're finished drawing). In some cases, however, you might want to treat part of a particular double-buffered window as though it were single-buffered by drawing to both front and back buffers. You use the glDrawBuffer() command to select the buffers to be written.void glDrawBuffer(GLenum mode); Selects the buffers enabled for writing or clearing. The value of mode can be one of the following: GL_FRONT GL_BACK GL_RIGHT GL_LEFT GL_FRONT_RIGHT GL_FRONT_LEFT GL_BACK_RIGHT GL_BACK_LEFT GL_AUXi GL_FRONT_AND_BACK GL_NONE Arguments that omit RIGHT or LEFT refer to both the left and right buffers; similarly, arguments that omit FRONT or BACK refer to both. The i in GL_AUXi is a digit identifying a particular auxiliary buffer. You can enable drawing to nonexistent buffers as long as you enable drawing to at least one buffer that does exist. If none of the specified buffers exist, an error results |
| ||
| Theres something called a pbuffer in opengl too, that lets you draw to textures - usefull for those camera / screen effects you see in games!. |
| ||
| Is pbuffers supported in OpenGL 1.2 though? Also, this thread started out asking about multi-layered maps. I presume you were meaning like where basically there is one layer of parallax and the game characters can sometimes walk behind trees or railing and sometimes in front of other scenery? Or were you trying to do parallax? |
| ||
| i was looking up the opengl commands and found gldrawbuffer but i couldnt get anything functioning. Thanks for all your commands. Yes, grabimage AND grabpixel are that slow on my machine.. im on a gf4 ti4200 with latest drivers. As for using Tlists, i reverted to using an x dimentional array and iterating through all the loops a few times... seems fast even on slow end machines (max seems faster at this than b3d) if i can get my OpenGL skills up and enable and write to different "pbuffers" then i will have no quarrels left :) |
   |