Problem with framerate, and bitmap blitting

Well, the “problems” go as follows.
I have a PIII 866 256MB/RAM and GeForce 2 GTS 32MB.

    • In the simple SDL window -
      SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_FULLSCREEN flags, I load a picture…

80060016:: I load 16-bit bmp format 800600 = 42fps!!!
800
60016:: I load jpg file (same pic but jpeg)=30fps!!!
1024
76816::bmp 42fps!!!
1024
768*32::bmp 40fps!!!
With jpeg… About 3-6 frames slower…

Why? And , it’s just one picture… What if I want to create a menu,
and/or game?? With moving sprites???
Why is it that slow??? I expected 200-300 fps… At least…
It’s a 2D graphics da*n!

Please, answer, I’m a newbie in graphics, so I don’t know too much:)

Well, to avoid any missunderstanding about my code… Here it is…:-------------------
#include <stdio.h>
#include <stdlib.h>

#include <SDL.h>
#include “SDL_image.h”
#include “SoFont.h”

SDL_Surface *screen;
SDL_Surface *back;
SDL_Surface *tekst;

SDL_Event event;

bool quit=false;

Uint32 pst_frmrate=1;
Uint32 cur_frmrate=1;
Uint32 fin_frmrate=1;
double rfps;
int decimal, sign;
char *fps;

int main(int argc, char *argv[])
{
SDL_Init(SDL_INIT_VIDEO);

screen=SDL_SetVideoMode(1024,768,32,SDL_SWSURFACE|SDL_DOUBLEBUF|SDL_FULL
SCREEN);
back=IMG_Load(“gfx\game.bmp”);

Uint32 crno;
crno = SDL_MapRGB(screen->format, 0, 0, 0);

SoFont soFont;
tekst = IMG_Load("font\\arial_white_24.png");
soFont.load(tekst);

while (!quit) {
	while (SDL_PollEvent(&event)) {
		switch (event.type) {
			case SDL_KEYDOWN: {
				switch(event.key.keysym.sym) {
					case SDLK_UP: {break;}
					default:

{SDL_Delay(100); SDL_Quit(); exit(0); break;}
}
}
default : break;
}
}
//usual operations
cur_frmrate=SDL_GetTicks();
fin_frmrate=cur_frmrate-pst_frmrate;
pst_frmrate=cur_frmrate;
rfps=( (float)1000/(float)fin_frmrate) ;
fps=_fcvt(rfps,0,&decimal,&sign);

	SDL_FillRect(screen,NULL,crno);
	SDL_BlitSurface(back, NULL, screen, NULL);

    soFont.PutString(screen,5,2,"FPS:");
	printf("FPS: %s\n", fps);
	soFont.PutString(screen,95,2,fps);

	SDL_Flip(screen);
}	

SDL_Delay(100);
SDL_Quit();
exit(0);;

}

Tonci Jukic

At 05:02 PM 6/7/02 +0200, you wrote:

            SDL_FillRect(screen,NULL,crno);
            SDL_BlitSurface(back, NULL, screen, NULL);

Actually in this way you fill the screen THREE times for each cycle.

One time with FillRect, one time with BlitSurface and the third time with
SDL_Flip().

So you read/write 1024x768x4 = 3MB of datas 2 times in normal ram and a
third time from RAM to the gfx card ram, you can understand that if you
transfer about 9MB each frame you cannot do a lot of FPS…

I think it’s really impossible to build a 1024x768x32 2d game without using
some sort of HW acceleration (the SDL one works for DirectX, while on Linux
you need glSDL or similar stuff…) or stay happy with low framerates.

Bye,
Gabry (gabrielegreco at tin.it)

Friday 07 June 2002 17:02:

Well, the “problems” go as follows.
I have a PIII 866 256MB/RAM and GeForce 2 GTS 32MB.

    • In the simple SDL window -
      SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_FULLSCREEN flags, I load a picture…

80060016:: I load 16-bit bmp format 800600 = 42fps!!!
800
600*16:: I load jpg file (same pic but jpeg)=30fps!!!

Of course, as you didn’t care to convert the loaded surface to the same
pixelformat as the display… Is the bitmap originally 8 bit or 24 bit ? For
sure jpeg is 24 bit, which therefore needs to be converted to 16 bit by SDL
on each blit.

Why? And , it’s just one picture… What if I want to create a menu,
and/or game?? With moving sprites???
Why is it that slow??? I expected 200-300 fps… At least…
It’s a 2D graphics da*n!

You expect 200-300fps on a full-screen redraw. Lemmesee… 1024x768x4=3145728
bytes per frame, times 200 gives 620MB per second to pass through AGP, which
would (over)saturate AGP2x alone in the highly unlikely case that the CPU
stays away from the memory and does not communicate with the gfx card. So, no
no 200fps for you :wink:
But see the parallax4 code to see how you can get reasonable framerates (50+
for 640x480 in my case) for a full-screen redraw with a lot of things on top
of each other, if you program it with the memory transfer efficiency in mind.
After being on this list for just a month, I suggest writing a perl script
that would look for keywords “why is my 2D application so slow” and reply
with:
"See parallax4 on http://olofson.net/mixed.html"
It is really educative example (if you add fps statistics at the end).
Greetings (and great regards to David Olofson),
Jacek–
±------------------------------------+
|from: J.C.Wojdel |
| J.C.Wojdel at cs.tudelft.nl |
±------------------------------------+

Well, the “problems” go as follows.
I have a PIII 866 256MB/RAM and GeForce 2 GTS 32MB.

    • In the simple SDL window -
      SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_FULLSCREEN flags, I load a picture…

You should only use SDL_HWSURFACE if you know you have h/w accelerated blits - and then you should also make sure that all source textures are h/w surfaces as well. (Not all cards and drivers support blitting from system RAM.)

Of course, you should also ensure that the source surfaces are of the same format as the screen. Use SDL_DisplayFormat(Alpha)().

80060016:: I load 16-bit bmp format 800600 = 42fps!!!
800
60016:: I load jpg file (same pic but jpeg)=30fps!!!
1024
76816::bmp 42fps!!!
1024
768*32::bmp 40fps!!!

Seems normal to me. In fact, I’m surprized that 102476832 is as fast as it is.

Even more strange is that the frame rates are so similar… Are you using the same screen resolution and only different size images? (If so, expect no major difference - only the area actually rendered has a significant effect.)

With jpeg… About 3-6 frames slower…

That might have something to do with the destructivene nature of jpeg. Areas that would be opaque (and thus could be optimized nicely by the RLE) will have the characteristic “JPEG noise”.

Why? And , it’s just one picture… What if I want to create a menu,
and/or game?? With moving sprites???

The problem is the blit into VRAM. If you put a software back buffer in system RAM and blit sprites and stuff into that first, you can avoid any extra VRAM blitting. (Software blitting in system RAM is much faster.)

Why is it that slow??? I expected 200-300 fps… At least…

There is no way software rendering can give you that kind of frame rate on current hardware. (Well, possibly in 320x240x8…)

It’s a 2D graphics da*n!

Well, that’s exactly the problem. Modern video cards are designed for 3D acceleration.

The fundamental idea behind the design of current video cards is that you put graphics on the video card, and have the 3D accelerator do all the blitting entirely inside the video card. On AGP cards and some PCI cards, you can also put textures in system RAM and have the card read them using busmaster DMA - slower, but still useful if you have lots of graphics.

What you cannot do very well is using the CPU to move data over the bus, onto the video card - and unfortunately, that’s how software rendering works.

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Fri, 7/06/2002 17:02:48 , Tonci <tonci.jukic at st.hinet.hr> wrote: