Blitting from a hw surface to screen is very fast, so I thought I
should be able to blit from a hw surface to another hw surface just
as fast. However, it’s as slow as sw to hw, or anything else. Is
there not a fast way of doing surface-to-surface blits?
Blitting from a hw surface to screen is very fast, so I thought I
should be able to blit from a hw surface to another hw surface just
as fast. However, it’s as slow as sw to hw, or anything else. Is
there not a fast way of doing surface-to-surface blits?
Can you give more information on your platform?
HW -> HW blits should be fast if you are doing a blit that can be
accelerated in hardware, like straight copy blit or colorkey blit with
hardware colorkey support. If you’re doing something that cannot be
hardware accelerated, then it’s much faster to blit in system memory.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sure.
I’m testing on Windows 98 (K6-2 300). I checked and it is able to
load all the graphics into HW memory. I’m doing a straight blit with
no colorkey or alpha. Drawing fullscreen in 320x240x16.
The system just has a generic S3 Virge chipset. It’s less than
60fps unless I use HW->screen. I can redraw the whole screen
twice (or more, maybe) each frame, and still get 60fps with HW-
Screen… but if I do surface->surface… it slows down. I had a few
people test it, with similar results, but nothing conclusive.
If the screen buffer is in video mem, shouldn’t the surfaces in
video mem be able to copy as quickly?
Maybe I didn’t disable alpha/colorkey on the surface I was using
for surface->surface copying. It should be as fast as surface-
screen, in theory, right? The routines I have now are fine and I
don’t really need to go back to the surface->surface method, but
it’s good to know.On 8 Jan 2001, at 7:19, Sam Lantinga wrote:
Blitting from a hw surface to screen is very fast, so I thought I
should be able to blit from a hw surface to another hw surface just
as fast. However, it’s as slow as sw to hw, or anything else. Is
there not a fast way of doing surface-to-surface blits?Can you give more information on your platform?
HW -> HW blits should be fast if you are doing a blit that can be
accelerated in hardware, like straight copy blit or colorkey blit with
hardware colorkey support. If you’re doing something that cannot be
hardware accelerated, then it’s much faster to blit in system memory.See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Perhaps your refresh rate is what’s holding it
back? SDL_Flip waits for the next retrace
before flipping, so you will never get a frame
rate over your monitor refresh rate.
If the screen buffer is in video mem, shouldn’t the surfaces in
video mem be able to copy as quickly?
If by, HW->screen, you mean video memory
to video memory blit, then that should be
the fastest possible. Definitely faster than
system memory to video memory. I.E. In
this case your sprite will be stored
in the video card memory instead of system
memory and will not have to go through the
PCI bus to be displayed on the screen.
The system just has a generic S3 Virge chipset. It’s less than
60fps unless I use HW->screen. I can redraw the whole screen
twice (or more, maybe) each frame, and still get 60fps with HW-Screen… but if I do surface->surface… it slows down. I had a few
people test it, with similar results, but nothing conclusive.
Being able to redraw the screen ‘more than
once each frame’ is not really an accurate
way of saying it. Because the only thing
the viewer sees is the finished frame
itself so in essence you only draw it once.
What you mean I guess is being able to draw
an entire frame’s worth of data into the same
frame twice?
FYI, for SDL 1.3, I’ll be completely redoing the hardware memory
interface so you can take advantage of things like X11 pixmaps and
so forth. It’ll be very different and much better.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
FYI, for SDL 1.3, I’ll be completely redoing the hardware memory
interface so you can take advantage of things like X11 pixmaps and
so forth. It’ll be very different and much better.
Does that mean any API changes? Does it mean, we can use pixmaps
and windows bitmaps directly? If so, doesn’t that break the platform
independence? Or havn’t I understood, what your anouncement is
about?
Regards,
Andreas Podgurski
FYI, for SDL 1.3, I’ll be completely redoing the hardware memory
interface so you can take advantage of things like X11 pixmaps and
so forth. It’ll be very different and much better.
Does that mean any API changes? Does it mean, we can use pixmaps
and windows bitmaps directly? If so, doesn’t that break the platform
independence? Or havn’t I understood, what your anouncement is
about?
Don’t worry, you won’t be seeing anything for many months. I’ll probably
put out an experimental release late summer. Everything is up in the air
right now.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software