1. Re: Waiting for a retrace & svga
> wait_retrace isn't a procedure anymore.
> it must be called using "call(wait_retrace)"
>
> Hope this helps
It sure does...
Its will be included in my routines..
Does anybody know how to read & write to the vide memory in svga
modes correctly. What are the rules for a location of a pixel
then? I think i could easily write a routine which converts my
compiled sprites to compiled sprites for svga modes. (if the screwed
up location is the only thing!)
All the virtual screen handling is now done..
And most sprite routines are done..
A see-thourgh sprite of 13 by 10 can be copyd to a virtual screen
about 5.000 times per sec. If i remove some see-thourght pixels it
even comes to 20.000 per sec. However with a see-thourgh sprite like
in most games, it's about 1.500 / 2.000 sprites per sec.
With full screen copy and screen clear after EACH sprite i still
have a frame rate of 170 frames per sec!!!!
Can you imagine how it would be if you only copy & clear the screen
each 100 sprites or so...??
Well it was all measured in video mode 19 on my P-60 with memory
screens. (When you create one you can say what type it is.. all
routines work with all types!!)
However all the routines work just as well in any other mode. You
just have to initialize it for the mode and after that all routines
work nicely. It automatically initializes for the current video mode
when it is included.
I am thinking of writing a routine that draws a sprites on a virtual
screen and keep a record of which sections the sprites were drawn.
Then it should copy only those parts of the virtual screen to the
monitor and then restore the sections in the virtual screen.
Well i hope it is totally finished toninght!!
Thank you, Pete, for the asm-code...
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
