Re: Fast graphics and scrolling
> > BTW, your demo was very good, but so was the demo of Devilman by
> > Liquid-Nitrogen. His background also scrolls very smooth and fast. How
> > would he do it, you think? (Don't try to explain me, cause I am quite
> > ignorant when it comes to fast graphical routines. The only thing I do is
> > look at the demos and ask myself: how do they do this fast scrolling and
> > drawing?)
Well, a lot of values need to be calculated but they don't change
often, or they change linear. If you would save your position as
{x,y} as everybody normally does you had to calculate your position
in memory each time with (y-1)*screen_width + (x-1). However if you
save such a fixed position you can just add the screen_width to go
a line down. There are many other tricks also. You should always to
to use as few variables as you can and avoid atom's also how less
statements are executed the faster it is. When you copy one screen to
another and they have both the same size the engine copys it with
only one mem_copy command. When the sizes aren't the same it copies
it line by line. (which slows it down). There are many other specific
situations where the code could do it faster, i allways try to find
them all. Didn't you wonder why it is about 1000 lines (i'll upload
this version in a minute... it's even longer!).
Also you say they both have scrolling background.... NOT!!
He has a fixed background of a fixed size!! (so he can copy it in
once) He has one sprite that uses a poor sprite technique (mine is
about 100 times faster... sorry) and he uses an image technique to
draw the scrolling field... to prove this all. I'll make a version
with real scrolling background and rest will be the same... i'll use
his pictures... then he can look at my framerate, It would compare
easily.
I do not know if his routines are as flexible as mine... they can't
be more flexible as mine. If you change the video mode at the
beginning of your program, the rest will just work as it is supposed
too. This also goes for the different types of sprites, screens.
If he wants too, he can get my sprite technique so he can speed up
his with about 200% (really, change the demo to have 50 sprites, the
frame rate is about 70%, 80% of the one with the 25 sprites...
He scrolls the blocks and cuts them nicely.. (i still have to update
my routines to allow you to display a sprite partly of screen)
My routines (the ones i am gonna upload in a minute) handle blocks
as fast as normal poke routines do (poke is faster if it is used for
less the 87 bytes on my computer). It is only a BIT slower when you
have transparancy in the middle of a horizontal line. There is also
an amount of COMPRESSION when using sprites... which can save a great
deal of memory real time and only IMPROVE its speed!!!!
> He is using a specialized mode 19 library developed by Hollow Horse
> Software
> (Greg Harris and Lucius L. Hilley). We plan on releasing a freeware version
> in hopefully a few more weeks
> to the RDS homepage after a bit more tweaking, debuging and writing some
> descent documentation. As to his scrolling methods,
> I'll leave that up to him to tell you how that was done :).
I am kind of interested in that... :)
Too compare and change what he routines do faster....
After all our interest is to have the fastest graphix routines not
to make routines that are faster than the others......
I am gonna upload the routines now and then rewrite his demo to
compare and then write docs... it is now about 23:17... I got nothing
else important to do this night or next morning.. so you can all play
with it tomorrow....
The things i added with this and the most recent versions:
* Got some bug out.. :)
* Added compression (it is now faster too when drawing)
* Added second WaitRetrace method which is less accurate but a
lot
faster and ussually is good enough
* Image routines... you can use DisplayImageVS() and
SaveImageVS()
To do normal image things on the monitor or on a virtual
screen
FAST!! Using this for the monitor is faster and if your view is set
right (not of the screen thus) you can't poke out of the video
memory.
* Update gfxsafe to only have the memory addres of the current
video mode allowed when there is a video memory.. otherwise none is
allowed.
* A few smalls things at the inside... optimized some loops!!
It will be GFXNEW3.ZIP
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
|
Not Categorized, Please Help
|
|
