At 07:38 �� 18/2/2002 +0000, you wrote: >What are you writing ? Presumably a game of some type :-)
No comment :-) >The usual way, despite all your other intentions which are probably >valid, is to only update that part of the screen where new activity >occurs ... and leave the rest alone. The thing is that there is no "standard" way of managing sprites apart from what PE tells us. The problem with that is that (at least I couldn't find it) documentation on how PE handles sprites apart from their format. So what I see is writing some sort of toolkit (a-la SSG) which can do this in high-colour (and more)... for example clever background redrawing of the screen on the anticipated movement of the sprite, collision detection and the ability to run as a job that can accept input from pipes (so you can feed the job what do you want the sprite to do on a given level etc..) Of course it would need to be able to handle more than 16 sprites (Ambitious aren't we?) What I think is actually needed, is a form of a graphics only toolkit/library for s*basic and C. (And which would be a good Idea to incorporate something like the Packbits command from the DIY toolkit only with 16 bit / 32 bit capability as Packbits compresses only byte-by-byte which makes it unusable for high-colour) Kinda like the Allegro library on the PeeCee (which unfortunately contains x86 assembly and it's impossible to port else we would be up to our necks in games by now :-) Phoebus
