i thank you very much for this informations, but i still have a problem :
when i ask SDL_HWSURFACE | SDL_DOUBLEBUF with setvideomode,
i can’t get them (not only on my computer…)
maybe i make something wrong… can you help me ?*************
here is what i use to test :
#include <stdio.h>
#include <SDL/SDL.h>
int main() {
SDL_Surface *s;
const SDL_VideoInfo *vi;
SDL_Init(SDL_INIT_VIDEO);
vi = SDL_GetVideoInfo();
printf(“hw available : %d\nblit hw-hw : %d\nblit sw-hw : %d\nvidmem :
%d\nbpp : %d \n”,
vi->hw_available,
vi->blit_hw,
vi->blit_sw,
vi->video_mem,
vi->vfmt->BitsPerPixel);
s = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE | SDL_DOUBLEBUF);
printf(“hwsurface : %d\ndoublebuf : %d\nflags : %d\n”,
(s->flags & SDL_HWSURFACE) == SDL_HWSURFACE,
(s->flags & SDL_DOUBLEBUF) == SDL_DOUBLEBUF, s->flags);
return 0;
}
and this is the output :
hw available : 0
blit hw-hw : 0
blit sw-hw : 0
vidmem : 0
bpp : 32
hwsurface : 0
doublebuf : 0
flags : 0
(i test this with a voodoo5 , a matrox mystic 2 and some others… )
On Wed, 8 Nov 2000, blavyl wrote:
first : can i use HWSURFACE and DOUBLEBUF in windowed mode ?
if yes : it doesn’t work with me 
when i make a video info, he says that i have 0Mo of video ram … and
that
hwsurface, blithw->sw, … are not available
and when i create the main surface with setvideomode, even if i ask
HWSURFACE
or DOUBLEBUF, i have none of them
why ?
(this result happen on many different computeurs, not only mine…)
My real problem :
In my program, SDL_updateRect of all screen is very very very slow
(maybe because
i haven’t hwsurface and doublebuf). How can i do if i want to make a
fast scrolling for my
game ?
The fastest blits are from hardware to hardware. If you set
SDL_HWSURFACE|SDL_DOUBLEBUF with SetVideoMode() you can check that it is
hardware by the video flags. If the back buffer is a hardware surface, and
the surface you are blitting is hardware too (sprite/tile/etc) you will
get very fast blitting (but only if you have support for
hardware-to-hardware blits).
You probably know this but just to clarify the following: software
surfaces are in the system’s main memory and hardware surfaces are in AGP
memory or VRAM. Knowing these facts can explain the performance
characteristics of the various blits.
Based on my understanding, here is the order of blits from fastest to
slowest. (assuming the implementation is in place to make them work)
- hardware -> hardware
- software -> software
- software -> hardware
- hardware -> software
To make a fast scrolling game you have to minimize the # of software to
hardware blits (when you have to do bus transactions to video memory ==
slow). One way to do this by caching frequently used tiles/sprites/etc in
hardware surfaces. For example, a certain tile may repeat many times on
the same frame. You can then transfer it to VRAM 1 time instead of however
many times it repeats on that frame, giving you big savings in the number
of bus transactions needed. To blit hardware->hardware you only have to
send a small amount of information telling the video card what to do. I
wrote a small app that does simple verticle scrolling. I found that if the
tiles & backbuffer where in software at 32 bit color, I got 20 fps. But
if all the surfaces are in hardware I get 300 fps!
There are some situations where you should not use hardware surfaces. If
your game needs to access pixels from the surface (for collision detection
etc), you are better off using a software surface (again, since the bus
transaction can cost millions of cycles to complete from VRAM).
AGP memory is kinda half-way between VRAM and main memory - you get not as
fast agp->vram blits but it’s not as slow reading pixels from agp.
Well, thats my 2 bits on the hardware/software blitting story…hope this
helps.
Darrell