In article <[EMAIL PROTECTED]>, Phoebus R. Dokos <[EMAIL PROTECTED]> writes >At 07:38 �� 18/2/2002 +0000, you wrote: > >>What are you writing ? Presumably a game of some type :-) > >No comment :-)
OK ... :-) >>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 :-) Yes, the graphics toolkit is a need, I see what you are getting at now. Didn't Simon Goodwin do at lot of work on this ? It is interesting that the new capabilities of the QL systems are making demands on graphics. -- Malcolm Cadman
