Getting 35 FPS on hardware surfaces

I ?ve been reading the article about hardware surfaces with SDL on
O`reilly network witch was mentioned in the list some time ago (it?s in
the FAQ too i think, but here?s the URL
http://linux.oreillynet.com/pub/a/linux/2003/08/07/sdl_anim.html?page=1)

Well, although I couldn?t find the file ‘hardline.cpp’ alluded in the
article, it was not difficult to code using a previous version using
sorftware surfaces.
(I got it from a previous article:
http://linux.oreillynet.com/pub/a/linux/2003/05/15/sdl_anim.html)

I?ll get into the point :stuck_out_tongue:

With the help of a frame counter and using the clock class included in
the original code I compute the FPS, and it doesn?t goes beyond 35 - 37 FPS

I?m using windows i?m doing something wrong? I belive that I should get
at least 60FPS or more (depending of mi refresh rate) or am I wrong?

Here?s the code (not included init, I?m pretty sure that I get a
fullscreen hardware surface, checked)
Frame counter located at the very end.

---------------------------CODE----------------------------

while (!done)
{

 // Loop while reading all pending event.

 while (!done && SDL_PollEvent(&event))
 {
   switch (event.type)
   {

     // Here we are looking for two special keys. If we
     // get an event telling us that the escape key has
     // been pressed the program will quit. If we see
     // the F1 key we either start or stop the
     // animation by starting or stopping the clock.

   case SDL_KEYDOWN:
     switch(event.key.keysym.sym)
     {
     case SDLK_ESCAPE:
       done = true;
       break;

     case SDLK_F1:
       if (gt.stopped())
       {
         gt.start();
       }
       else
       {
         gt.stop();
       }
       break;

     default:
       break;
     }
     break;

     // The SDL_QUIT event is generated when you click
     // on the close button on a window. If we see that
     // event we should exit the program. So, we do.

   case SDL_QUIT:
     done = true;
     break;
   }
 }

 // Erase the old picture by painting the whole buffer
 // black.

 SDL_FillRect(screen, NULL, black);

 // Get the current game time. Note that if the clock
 // is stopped this method will return the same value
 // over and over.

 int t = gt.time();

 /*
 rl->update(t);
 gl->update(t);
 bl->update(t);
 //*/
 // Since I'm using a software buffer the call to
 // SDL_Flip() copies the software buffer to the
 // display. That gives you the effect of double
 // buffering without asking for it and without the
 // speed you would get from a hardware double buffered
 // display.


 if (SDL_MUSTLOCK(screen))
 {
     if (-1 == SDL_LockSurface(screen))
     {
         printf("Can't lock hardware surface\n");
         exit(1);
     }
 }

 // Based on the current time update the location of
 // each line and draw the line into the buffer.

 rl->update(t);
 gl->update(t);
 bl->update(t);

 if (SDL_MUSTLOCK(screen))
 {
     SDL_UnlockSurface(screen);
 }
 SDL_Flip(screen);
 frames++;

}//end of while loop

// I added this
gt.stop();

//My frame counter//////////////////////////////////////
printf(“Frames: %d\n”, frames);
printf(“Elapsed time (miliseconds): %d\n”,gt.time());
printf(“FPS: %d\n”, (frames / (gt.time() /1000) ) );

// When we get here, just clean up and quit. Yes, the
// atexit() call makes this redundant. But, it doesn’t
// hurt and I’d rather be safe than sorry.
SDL_Quit();
}

---------------------------CODE----------------------------

Any help appreciated, and excuse my terrible english :frowning:

Regards–

  Ricardo Amores Hern?ndez
ICQ: 19463735
MSN: zheo_ (at) hotmail (dot) es

I?m using windows i?m doing something wrong? I belive that I should get
at least 60FPS or more (depending of mi refresh rate) or am I wrong?

Using a HWSURFACE is very slow, unless everything you plan to render into
it is also a hardware surface (i.e. - not a software surface, not touching
the framebuffer directly).

In 99.9% of the cases, you should be using a software surface.

–ryan.

Using a HWSURFACE is very slow, unless everything you plan to render into
it is also a hardware surface (i.e. - not a software surface, not touching
the framebuffer directly).

     Using everything on hardware is not wrong, actually, it's the best 

setup possible, as it frees the CPU and leaves the task for the video card,
which in turn does what it is SUPPOSED to do: process video data. Try doing
a 3 layered parallax scrolling at 640x480x32bpp on a Celeron 300 with
software surfaces, then try doing it with hardware surfaces. Even an old
16MB accelerated video card will beat any software surface for this task.
Problem is, not all video drivers support hardware surfaces, even if they
are available on other OSs with the same GPU :/.

In 99.9% of the cases, you should be using a software surface.

     I see only ONE situation where software surfaces are *needed* on 

the 2D realms: when you have to use some effects that are not accelerated
by hardware, such as alph blending, zooming and rotation. This is the only
situation where 2D surfaces will beat hardware surfaces. That is, until you
move to Open GL and see that it will beat the hell out of any software and
hardware 2D surfaces on all those operations on a 10:1 basis :).

     Paulo

In 99.9% of the cases, you should be using a software surface.

     I see only ONE situation where software surfaces are *needed* on

the 2D realms: when you have to use some effects that are not accelerated
by hardware, such as alph blending, zooming and rotation.

You just decribed 99.9% of the games I’ve ever worked on. :slight_smile:

Many games, notably first person shooters, draw the entire screen every
frame by touching pixels directly, since blitting multiple surfaces just
wouldn’t do the trick.

There are very few games that just blit sprites around the screen without
extra effects. In such a case, HWSURFACE is faster if you can get
everything into them, but even if you just want to draw a line into the
framebuffer, you lose all benefits of the hardware (unless you plan to
move to OpenGL…this just applies to 2D framebuffers).

–ryan.

You just decribed 99.9% of the games I’ve ever worked on. :slight_smile:

But it doesn’t mean 99.9% of the games on the market, you see? So knowing to judge when to use software surfaces or hardware surfaces is a must on this business ^_-. Anyway, for those looking on the difference between surface types, this discussion has been really interesting :).

Many games, notably first person shooters, draw the entire screen every
frame by touching pixels directly, since blitting multiple surfaces just
wouldn’t do the trick.

Sure, but then again, this goes way off the track as it’s not 2D anymore, so techniques are QUITE different :). Also, using 3D hardware acceleration (either Openg GL or Direct X) will proven more effective for these games than just drawing the screen on a pixel by pixel basis :). Not to mention that we can use 3D acceleration on a 2D engine and have insanely fast zooming, rotation, alpha blending and colorkeying :).

framebuffer, you lose all benefits of the hardware (unless you plan to
move to OpenGL…this just applies to 2D framebuffers).

Well, just what I said a little above ^_-.

Paulo

You just decribed 99.9% of the games I’ve ever worked on. :slight_smile:

But it doesn’t mean 99.9% of the games on the market, you see? So knowing to judge when to use software surfaces or hardware surfaces is a must on this business ^_-. Anyway, for those looking on the difference between surface types, this discussion has been really interesting :).

If you really want to learn the difference please take a look at:
http://linux.oreillynet.com/pub/a/linux/2003/05/15/sdl_anim.html
http://linux.oreillynet.com/pub/a/linux/2003/08/07/sdl_anim.html

	Bob PendletonOn Wed, 2003-09-17 at 18:56, pvwr at sympatico.ca wrote:

Many games, notably first person shooters, draw the entire screen every
frame by touching pixels directly, since blitting multiple surfaces just
wouldn’t do the trick.

Sure, but then again, this goes way off the track as it’s not 2D anymore, so techniques are QUITE different :). Also, using 3D hardware acceleration (either Openg GL or Direct X) will proven more effective for these games than just drawing the screen on a pixel by pixel basis :). Not to mention that we can use 3D acceleration on a 2D engine and have insanely fast zooming, rotation, alpha blending and colorkeying :).

framebuffer, you lose all benefits of the hardware (unless you plan to
move to OpenGL…this just applies to 2D framebuffers).

Well, just what I said a little above ^_-.

Paulo


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±----------------------------------+