kumbach@nro.cs.athabascau.ca (Kevin Umbach) (04/29/91)
I'm having problems with an Amiga game I'm working on which has 6 hardware sprites moving over a 320x200 2 bitplane screen. When I simply move the sprites around the screen, they move very quickly without any flicker. However, when I animate them by changing their image data every time the sprites move, considerable flicker or glitches occur. (Yes I do WaitTOF() ) Basically all I do to change a sprites image is do a memcpy() from an array into the sprite's image data area and I believe this is where the glitches originate from. Can anyone suggest a fix or technique they use? I have thought about double buffering the sprite image data by doing the memcpy() into the second image buffer then using ChangeSprite() to point to this buffer. Has anyone tried this before? Any info will be appreciated. Kevin Umbach ersys!kumbach@nro.cs.athabascau.ca Edmonton Remote Systems: Serving Northern Alberta since 1982
aaron@stat.tamu.edu (Aaron Hightower) (05/02/91)
In article <y6i511w164w@ersys.uucp> ersys!kumbach@nro.cs.athabascau.ca (Kevin Umbach) writes: >When I simply move the sprites around the screen, they move >very quickly without any flicker. However, when I animate them >by changing their image data every time the sprites move, >considerable flicker or glitches occur. (Yes I do WaitTOF() ) > >Basically all I do to change a sprites image is do a memcpy() >from an array into the sprite's image data area and I believe >this is where the glitches originate from. > >Can anyone suggest a fix or technique they use? I have thought >about double buffering the sprite image data by doing the memcpy() >into the second image buffer then using ChangeSprite() to point >to this buffer. Has anyone tried this before? I have one game that uses memcpy to change the sprite image, and I have also noted the "glitches". My theory is that is has something to do with the blitter (I think I remember this function being able to use the blitter). In other words, the action of memcpy may be asyncronous. Another game that I wrote used the technique where the images are all stored separately in CHIP mem. Then a ChangeSprite would display the desired sprite. Your idea for double buffering will work fine, but you may need three image slots. Current (on screen), Next (already copied and waiting), and next next (The one you can copy to). This way you won't ever do a ChangeSprite to an Image that is in the process of a memcpy(). Good luck, Aaron Hightower > >Any info will be appreciated. > >Kevin Umbach ersys!kumbach@nro.cs.athabascau.ca >Edmonton Remote Systems: Serving Northern Alberta since 1982
sschaem@starnet.uucp (Stephan Schaem) (05/02/91)
WaitTof dont give you the maximum time.You should wait at the screen bottom position, I think getting vp_DyOffset + sc_Height should work. And you should have the highest priority, since if you 'want' to do a copy you need to be syncronized with the display. If you are in Intuition environment, use a UserCopperlist to set your sprite adr and position... This supose you will not use gfx.library sprite function.And by doing this the system will calculate the start position of your screen and add that to your waits... (If you enable you screen to be scrolled!) So Make all your images has a sprite 'structure' and simply copy the position of the previews sprite into the next sprite animation frame. I actually dont do it like that since I dont use the 'system' dma, but if you manage to set the sprite adr before the 'system' dma reads it everything should animate smothly... Stephan.
pochron@cat30.cs.wisc.edu (David Pochron) (05/02/91)
In article <y6i511w164w@ersys.uucp> ersys!kumbach@nro.cs.athabascau.ca (Kevin Umbach) writes: >Basically all I do to change a sprites image is do a memcpy() >from an array into the sprite's image data area and I believe No no no no! Why are you using memcpy() to change the sprite images? You can just set up all the sprite image structures in the code, then all you have to do is a ChangeSprite whenever you want to change images. ChangeSprite just changes the pointer to the sprite data. It Is MUCH faster to do that than to recopy the sprites entirely into a fixed sprite space. Just make sure all the sprite image data is in CHIP mem. Most good C compilers let you specify where structure/array data gets stored at load time. >Kevin Umbach ersys!kumbach@nro.cs.athabascau.ca >Edmonton Remote Systems: Serving Northern Alberta since 1982 -- David M. Pochron | Transparent DWV pipe: For the man who wants to | see it all... pochron@garfield.cs.wisc.edu | (If you don't know what DWV is, get a life! :-)
aaron@stat.tamu.edu (Aaron Hightower) (05/03/91)
In article <1991May2.155342.1317@daffy.cs.wisc.edu> pochron@cat30.cs.wisc.edu (David Pochron) writes: >In article <y6i511w164w@ersys.uucp> ersys!kumbach@nro.cs.athabascau.ca (Kevin Umbach) writes: >>Basically all I do to change a sprites image is do a memcpy() >>from an array into the sprite's image data area and I believe > >No no no no! Why are you using memcpy() to change the sprite images? I can't answer why for the person who posted the original question, but I first used your technique for one game, but the problem is that if you use one image multiple times, you HAVE to copy it. IE since the position and control information is a field in the sprite data structure, you must have a different copy of the image for each hardware sprite that uses it - no sharing sprite image data between two hardware sprites. So if you have one image that you would like to display with 6 sprites, you will either have to have eight declarations of this image as you suggested with the CHIP storage class modifier, or you will have to copy it somehow. I concluded for one game that it is better to copy it (It's not doing heavy animation though). To sum up, if you have sharing of images your options are something like memcpy vs 7 copies in chip ram of each sprite image or some hybrid method employing the two ideas. (EG double or triple buffering). >You can just set up all the sprite image structures in the code, then all >you have to do is a ChangeSprite whenever you want to change images. > >ChangeSprite just changes the pointer to the sprite data. It Is MUCH faster >to do that than to recopy the sprites entirely into a fixed sprite space. > An important observation. This is the classic speed versus space efficiency debate - you decide - but no ONE way is correct. >Just make sure all the sprite image data is in CHIP mem. Most good C compilers >let you specify where structure/array data gets stored at load time. > > >>Kevin Umbach ersys!kumbach@nro.cs.athabascau.ca >>Edmonton Remote Systems: Serving Northern Alberta since 1982 > > David M. Pochron | Transparent DWV pipe: For the man who wants to > | see it all... >pochron@garfield.cs.wisc.edu | (If you don't know what DWV is, get a life! :-) Aaron Hightower - Texas A&M University - Computer Science