Revisiting Speed

SDL Development
1

Hi everyone,
Back in February I asked a question about SDL and speed. After a
couple responses I happily went on my way making sure to only update
small areas of the screen that needed it. Last night I realised that I
just need more speed no question about it. I really wonder if I’m doing
something wrong.
In my tests I initialize SDL, get me screen surface 1024x768x24
SDL_FULLSCREEN SDL_HWSURFACE. I load my bitmap, I do a
SDL_DisplayFormat. I then proceed to blit my 1024x768x24 image onto
that surface (this blit isn’t slow). I then run a loop 100 times that
simply does SDL_UpdateRects(screen,0,0,0,0)

Uint starttime SDL_GetTicks();
for (int c=0; c<100;c++)
{
SDL_UpdateRects(screen,0,0,0,0);
}
Uint endtime SDL_GetTicks();
int time = endtime - starttime;
printf(“average time: %i”,time/100);

the averate time takes about 103milli seconds. That seems like way too
slow. I have an Athlon 1200mhz 512megs of DDR memory, Geforce card with
32megs of DDR memory. My system bus runs at 133mhz so both sets of
memory are running at 233mhz. The UpdateRects should only be copying
under 2.5 megs each time. that is only copying across at about 2mhz.
This makes me really wonder what is going on. Shouldn’t it simply be
copying the 2.5 megs directly across to the screen?

I have tested this on many different machines, the results are similar.
Please any input on this, or ideas on how to get things up to speed are
definitely welcome.
thanks
Jaren Peterson

2

Forgot to mention, I’ve tried this on both my computer with X ver. 4.11
also on many other computers running Windows98
thanks for any responses.
I would also like to know if anyone else is experiencing similar problems.

3

In my tests I initialize SDL, get me screen surface 1024x768x24
SDL_FULLSCREEN SDL_HWSURFACE. I load my bitmap, I do a

unless your framebuffer has a 24bpp packed-pixel mode you probably want
to use a 32bpp format instead. Also you won’t get any hardware surfaces
using the X11 driver (try DGA)

the averate time takes about 103milli seconds.

how does this compare with x11perf numbers? See recent thread in this list

4

How about sending the program (or just the snippet) to the list? It’ll
be much easier to tell what you might be doing wrong if we can see the
actual code you’re using…

BryanOn Thu, May 17, 2001 at 07:25:20AM -0700, Jaren Peterson wrote:

Forgot to mention, I’ve tried this on both my computer with X ver. 4.11
also on many other computers running Windows98
thanks for any responses.
I would also like to know if anyone else is experiencing similar problems.

5

Just because you set SDL_HWSURFACE doesn’t guarantee you have a real
hardware surface and that your blits occur completelty in hardware. A
check might be to use SDL_SWSURFACE and see if there is any speed
difference.

Regards,
DarrellOn Thursday, May 17, 2001, at 09:08 AM, Jaren Peterson wrote:

Hi everyone,
Back in February I asked a question about SDL and speed. After a
couple responses I happily went on my way making sure to only update
small areas of the screen that needed it. Last night I realised that I
just need more speed no question about it. I really wonder if I’m doing
something wrong.
In my tests I initialize SDL, get me screen surface 1024x768x24
SDL_FULLSCREEN SDL_HWSURFACE. I load my bitmap, I do a
SDL_DisplayFormat. I then proceed to blit my 1024x768x24 image onto
that surface (this blit isn’t slow). I then run a loop 100 times that
simply does SDL_UpdateRects(screen,0,0,0,0)

Uint starttime SDL_GetTicks();
for (int c=0; c<100;c++)
{
SDL_UpdateRects(screen,0,0,0,0);
}
Uint endtime SDL_GetTicks();
int time = endtime - starttime;
printf(“average time: %i”,time/100);

the averate time takes about 103milli seconds. That seems like way too
slow. I have an Athlon 1200mhz 512megs of DDR memory, Geforce card with
32megs of DDR memory. My system bus runs at 133mhz so both sets of
memory are running at 233mhz. The UpdateRects should only be copying
under 2.5 megs each time. that is only copying across at about 2mhz.
This makes me really wonder what is going on. Shouldn’t it simply be
copying the 2.5 megs directly across to the screen?

I have tested this on many different machines, the results are similar.
Please any input on this, or ideas on how to get things up to speed are
definitely welcome.
thanks
Jaren Peterson

6

Speaking of this, is there something in SDL at this point that you can use to
determine if you can get hardware surfaces? I do know of SDL_GetVideoInfo, but
doesn’t it just return the “best” video mode available? What I want to know is
if a particular video mode/setting is supported on a particular system…On Thu, 17 May 2001, you wrote:

Just because you set SDL_HWSURFACE doesn’t guarantee you have a real
hardware surface and that your blits occur completelty in hardware. A
check might be to use SDL_SWSURFACE and see if there is any speed
difference.

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

7

Speaking of this, is there something in SDL at this point that you can use to
determine if you can get hardware surfaces? I do know of SDL_GetVideoInfo, but
doesn’t it just return the “best” video mode available? What I want to know is
if a particular video mode/setting is supported on a particular system…

both SDL_ListModes and SDL_VideoModeOK take a ‘flags’ parameter.
If hw surfaces are available for one video mode, they are available for
all SDL_HWSURFACE modes. I think you can count on that

8

Mensaje citado por: Jaren Peterson :

Forgot to mention, I’ve tried this on both my computer with X ver. 4.11
also on many other computers running Windows98
thanks for any responses.
I would also like to know if anyone else is experiencing similar
problems.

Yes, same problem here on http://www.arianne.cx, we can’t get more of 10 fps.
I did exactly the same that you did, and result where a bit diassapointed too.
But I have seen SDL running at 120 fps, so I think that it should be something
related to the configuration.

You can take a look at PowerPak, that use SDL and has a very good speed.

              Miguel Angel Blanch Lardin

         -- http://www.arianne.cx -- Arianne --

The free open source massively multiplayer online role playing game

nuclear cia fbi spy password code encrypt president bomb iran irak korea cuba
Ala yihad mosad kgb free freedom human rights yugoslavia kosovo ebola dna

                -- Echelon must die --
9

Speaking of this, is there something in SDL at this point that you can use
to

determine if you can get hardware surfaces? I do know of SDL_GetVideoInfo,
but

doesn’t it just return the “best” video mode available? What I want to
know is

if a particular video mode/setting is supported on a particular system…

both SDL_ListModes and SDL_VideoModeOK take a ‘flags’ parameter.
If hw surfaces are available for one video mode, they are available for
all SDL_HWSURFACE modes. I think you can count on that

The problem I find is that nothing supports alphablit in hardware. So I’m
doing everything in OpenGL. In comparison everyone who I had test the
program got 8 to 15fps (double buffered, every frame was redrawn) in the
"software 2D mode". In OpenGL I got around 45fps in windowed or 65 in full
screen, I had a person with a voodoo 4 PCI get 200fps in full screen.

All the code was doing was placing 8 RGBA images overtop each other (no
movement) blended._________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

10

Mattias Engdeg?rd wrote in message <200105171512.RAA01544 at my.nada.kth.se>…

In my tests I initialize SDL, get me screen surface 1024x768x24
SDL_FULLSCREEN SDL_HWSURFACE. I load my bitmap, I do a

unless your framebuffer has a 24bpp packed-pixel mode you probably want
to use a 32bpp format instead.

ROFL!

I’m working on this problem with Jaren, and right now I’m running tests with
VC++ in Windows 98.

Here’s my code:

#include “SDL/SDL.h”
#include
#include

int main(int argc, char **argv)
{
const int LOOPCOUNT = 100;
const int COLORDEPTH = 24;
atexit (SDL_Quit);

if(SDL_Init(SDL_INIT_VIDEO) == -1)
{
printf(“Could not initialize SDL: %s.\n”, SDL_GetError());
exit (EXIT_FAILURE);
}

SDL_Surface *screen = SDL_SetVideoMode (1024, 768,
COLORDEPTH, SDL_HWSURFACE | SDL_FULLSCREEN);
const SDL_VideoInfo *info = SDL_GetVideoInfo();

printf ("%i %i %i %i %i %i %i %i %i %i\n",
info->hw_available,
info->wm_available,
info->blit_hw,
info->blit_hw_CC,
info->blit_hw_A,
info->blit_sw,
info->blit_sw_CC,
info->blit_sw_A,
info->blit_fill,
info->video_mem
);

SDL_ShowCursor(0);
// splash from http://mordor.nazgul.com/
SDL_Surface *bitmap = SDL_LoadBMP (“mordor.bmp”);
if (screen == NULL || bitmap == NULL)
{
printf (“Could not load bitmap\n”);
exit (EXIT_FAILURE);
}

SDL_Rect *bitmapRect = new SDL_Rect;
SDL_Rect *screenRect = new SDL_Rect;

bitmapRect->x = 0;
bitmapRect->y = 0;
bitmapRect->w = 471;
bitmapRect->h = 390;
screenRect->x = 276;
screenRect->y = 189;

if (SDL_BlitSurface (bitmap, bitmapRect, screen, screenRect) == -1)
{
printf (“Couldn’t blit\n”);
exit (EXIT_FAILURE);
}

int start = SDL_GetTicks();
for (int i = 0; i < LOOPCOUNT; i++)
SDL_UpdateRect (screen, 0, 0, 0, 0);
printf ("%i\n", SDL_GetTicks() - start);

exit(EXIT_SUCCESS);
}

As you can see, it’s pretty simple, and pretty much what Jaren was doing.
I’m building a release executable, not a debug, by the way, although it
doesn’t really seem to be an issue, since I get almost identical times with
both builds. (Release is only about 100 ms faster, although the executable
is, of course, considerably smaller.)

Every time I ran this, I got a time of about 19 sec. That translates into
190 ms per update… not so hot (that’s an understatement, hehe).

I’d like to point out that when calling GetInfo, all hardware blitting
accelaration was detailed as enabled, except for those relating to alpha
channels, which doesn’t apply here anyway.

Then, I tried your suggestion and changed COLORDEPTH to 32.
WOW! Now I KNOW it’s in the VRAM, because I had to up LOOPCOUNT to
10,000,000 before I saw more than a flash of a window. :stuck_out_tongue:

Result: LOOPCOUNT = 10000000, COLORDEPTH = 32,
2.1 seconds.

  • Ithil
11

“Ithil” wrote in message
news:9e1l1k$70l$1 at ftp.lokigames.com…

Then, I tried your suggestion and changed COLORDEPTH to 32.
WOW! Now I KNOW it’s in the VRAM, because I had to up LOOPCOUNT to
10,000,000 before I saw more than a flash of a window. :stuck_out_tongue:

Result: LOOPCOUNT = 10000000, COLORDEPTH = 32,
2.1 seconds.

That’s because SDL_HWSURFACE without SDL_DOUBLEBUF means that you draw
directly to the frame buffer, so SDL_UpdateRect becomes a null operation.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor