Is there a trick I’m missing to fast 2-D sprite blitting – direct to HW?
For some reason, RLE blitting to system memory and then fast blitting to
HW memory is much faster (with less tearing) than writing directly to the
display surface.
Even syncing with the vertical blank doesn’t help as much as writing to
a system memory back-buffer.
I’d like to chalk it up to “never touch video memory”, but that seems
like a cop-out to me…
Ideas?
Is there a trick I’m missing to fast 2-D sprite blitting – direct to HW?
For some reason, RLE blitting to system memory and then fast blitting to
HW memory is much faster (with less tearing) than writing directly to the
display surface.
Video mem is a) not generally cached, b) often has fast large area blits.
unless you have hardware to do sprites or nice blitters, stay in main
memory. Make the system powerful enough that people can basically set the
position and picture of a sprite and you handle the updating - any more
and you wreck games(sameyness syndrome), any less and people re-invent the
code endlessly. It will also allow hardware accelleration to be do-able.
njhOn Wed, 20 May 1998, Sam Lantinga wrote:
Video mem is a) not generally cached, b) often has fast large area blits.
unless you have hardware to do sprites or nice blitters, stay in main
memory. Make the system powerful enough that people can basically set the
position and picture of a sprite and you handle the updating - any more
and you wreck games(sameyness syndrome), any less and people re-invent the
code endlessly. It will also allow hardware accelleration to be do-able.
I was speaking for the purposes of the example draw program, which now has
an option to specify an arbitrary number of sprites moving randomly, as an
example of using SDL for sprite manipulation.
I thought that having access to the video memory might be a boon, but it
is turning out that every example program (starfield, warp, sprite animation)
is much faster when writing to system memory and then doing area blits to
video memory (usually handled by SDL).
Oh well. 
Cards tested:
Matrox Millennium w/4 MB WRAM
Chips & Technologies w/1 MB VRAM
Is there a trick I’m missing to fast 2-D sprite blitting – direct to HW?
For some reason, RLE blitting to system memory and then fast blitting to
HW memory is much faster (with less tearing) than writing directly to the
display surface.Even syncing with the vertical blank doesn’t help as much as writing to
a system memory back-buffer.I’d like to chalk it up to “never touch video memory”, but that seems
like a cop-out to me…Ideas?
Writting to video memory is generally slower than writing to main memory,
because the data has to go over the PCI bus… Main memory operations can be
upto 5 times faster on my system.
Though I beleive it is possible to have the sprites on the video card, and get
the video card to do the blitting. (this feature is often used for the mouse
cursor.) Doing it like that should improve the speed massively, (If you are
using the same sprites repeatedly, and have enough spare video memory to store
them off screen)
cya
Josh
I’m sorry I’ve kept so quiet. I did notice Sam’s posting a few
weeks ago about BeOS and threads…is there anything I do or
questions I can answer to help bring the BeOS version up to
speed with the rest of the releases?
Best Regards,
David
// Frameworks epitomize software engineering. Code for a reason.
// “Brain ready for infrared upgrade.” -Me
// http://www.cs.uml.edu/~dsowsy
Though I beleive it is possible to have the sprites on the video card, and get
the video card to do the blitting. (this feature is often used for the mouse
cursor.) Doing it like that should improve the speed massively, (If you are
using the same sprites repeatedly, and have enough spare video memory to store
them off screen)
The only time this is really helpful is when the sprite operations that
you are performing can be done by the hardware blitter. i.e. transparency,
etc.
I’d have to check to make sure, but I think when I was running tests,
that I was using the hardware blitter to do transparency. All the surfaces
were in video memory. If the library was doing RLE acceleration, that
would account for the tearing and the relatively low performance.
This means I should add a way to query the blit capabilities of the hardware:
When the hardware can do source colorkeying, put video buffers and sprites
in video memory, unless many of the sprites don’t fit in video memory.
Otherwise, if the blitter doesn’t do colorkeying or there is a limited
amount of video memory, put everything in system memory.
Ack.
Ideas?
Though I beleive it is possible to have the sprites on the video card, and get
the video card to do the blitting. (this feature is often used for the mouse
cursor.) Doing it like that should improve the speed massively, (If you are
using the same sprites repeatedly, and have enough spare video memory to store
them off screen)
If this isn’t what Sam is already doing, then I too would suggest
that. In my experience, there’s nothing you can do in software
(i.e. over the system memory bus) when it comes to blitting, that the
Millenium blitter can’t do a heck of a lot faster in it’w own
memory. On simple colour-fill blits, I’ve achieved ~1.5 GB/s of
bandwidth. That is roughly 3X the system memory’s theoretical
limit…
Doing this kind of blit (VRAM->VRAM) is, roughly, what I want to do
with SDL. Everything else is a bonus! It’s a shame that it seems it’s
not possible to do this kind of blitting on anything else than
DirectX, though. 
/EmilOn Thu, 21 May 1998, Joshua Samuel wrote: