Started by ssr86, 23:34, 26 August 13
0 Members and 1 Guest are viewing this topic.
Quote from: ssr86 on 23:34, 26 August 13What are the best practices for preserving the background of the area where a sprite is to be drawn?are these the only possibilities:- keeping somewhere a copy of the entire background screen and "erasing" the sprite using that- saving only the rectangle to be occupied by the sprite and erasing sprite using that?First needs too much memory and the second is quite cputime consuming (when more than one sprite occupies the same area then we copy the same area more than one time). Could someone give me a source code example of the second? (can I find it somewhere in Edgegrinder's source?)
Quote from: ssr86 on 20:51, 27 August 13@AMSDOS: found it http://www.cpcwiki.eu/imgs/f/f3/Amstrad_Action112_16.jpg. Dou you use such table as in the article? With four states? What's the best practice when you have more than one sprite to draw? It seems that, when having to store only the part of the background the sprite occupies, such table is a must. Because you should first store the backgrounds of all the sprites and only after that draw the sprites...However what's the best practice?
Quote from: arnoldemu on 15:34, 29 August 13Ok I understand, you're copying the background into a buffer, drawing the sprites into this buffer and then copying to the screen.Barbarian does similar, it has a background image it never writes to, it uses this to fill the buffer.It then draws the sprites to the buffer and finally puts them to the screen just as you do.With this method do you have to clip sprites into the buffer region? And do you have cases where a sprite can exist in 2 areas so you must first draw it in the first, then draw it in the second?Or do you not have much sprite overlap in your game?
Quote from: TFM on 22:53, 29 August 13What a waste of RAM and time! I handle sprites the following way. This is one compete cycle- Restore picture from buffer (previously stored background)...Advantages:- No copy of the V-RAM needed...
Quote from: AugustoRuiz on 12:02, 30 August 13So... how did you store the background in that buffer?
Quote from: ssr86 on 20:51, 27 August 13@arnoldemu: is it the optimal solution (the one in your code) for when you don't have the memory to store a copy of the entire background for direct access during the drawing routine (for getting the rectangle the sprite occupies)?
Quote from: ssr86 on 23:34, 26 August 13Could someone give me a source code example of the second? (can I find it somewhere in Edgegrinder's source?)
Quote from: arnoldemu on 13:29, 30 August 13@AugustoRuiz: I understand. Thank you. For others:Another method that I should mention which is worth considering because it is used for Spectrum 48K.This is like a double buffer method, but you don't switch the screens with the hardware.You have 2 screens. 1 which is always visible, and another which is hidden.You always draw to the hidden screen, you do all your work here, but at the same time you record which regions you updated (or dirtied).Then you draw these changed regions to the visible screen.This works quite well. Really it doesn't have any advantage on CPC because there is almost no difference compared to a normal double buffered screen.Differences:- do not need to remember regions changed on each screen- you don't need to worry about the screen being made "clean" because you only send dirty regions to the nice visible clean screenOne day I may make an example code for this.
Quote from: AugustoRuiz on 14:04, 29 August 13So, the drawing routine is:While there are items to draw Initialize the background rectangle with the union rectangle of the current item. Check if the next item rectangle intersects with the current background rectangle If it does, the background rectangle is the union of the background rectangle and the item rectangle, keep checking next items If it doesn't, draw the background in the background buffer, with the specified dimensions. Now, we have our background in a buffer, we must draw the items in this buffer (the ones that did intersect!) Blit the buffer into the screen with a bunch of LDIs (I mean, as fast as you can)End While
Quote Keep track which sprites are overlapping, collect them in 'sprite bundles'.For each sprite, determine the rectangle that encloses the old and new sprite positions.Draw the background graphics within this rectangle to an off-screen buffer.Draw the parts of all sprites in the bundle that intersect with the rectangle into the off-screen buffer.Copy the off-screen buffer to the screen.[/l]
Page created in 0.115 seconds with 48 queries.