• 12
• 27
• 9
• 9
• 20

SDL: too slow for 3 sprites? *solved*

This topic is 4933 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hullo i am realy new to SDL so i hope there is some error on my part, but could it realy be that SDL ist too slow to animate 3 sprites correctly (i mean fast enough)? I initialize sdl with 1024x768@32bit and the three sprites are [0] 150x200@8bit delay 50 [1] 300x400@8bit delay 20 [2] 250x400@8bit delay 20 if i use this delay time sdl is animating the sprites "right", but when i decrease the delay time, to somthing like 10 for example, the animations are slower than they should be. does someon know why? [Edited by - mm-motm on September 12, 2004 6:38:13 PM]

Share on other sites
ah, and i am using SDL_HWPALETTE and SDL_DOUBLEBUF

Share on other sites
Those are some big sprites at a high res, but unless your system sucks, I don't see why that would be slow.

Maybe post some code?

Share on other sites
don't use delay. use SDL_GetTicks, and stick your program in a loop.

here is a good elapsed time function I came up with a while ago.
float GetElapsedTime(void){	static float oldTime = (float)(SDL_GetTicks()/1000.0);	float newTime;	newTime = (float)(SDL_GetTicks()/1000.0);	float elapsed = newTime - oldTime;	oldTime = newTime;	return elapsed;}

it returns the time since the function was last called.
hope it helped

Share on other sites
i already using SDL_Ticks in a drawing loop.

My system is an Athlon XP2000+ 512Ram Radeon 9200, so i think
the system cant be the problem. The programme ist compiled using gcc (dev-c) and best optimization.

Thats the actual drawing function:

if(mi_animate)
{
if(mc_new)
{
i_savebg();
mc_new=0;
} if((ml_lastdrawn+pps_frames[mi_aktiveframe]->i_delay*mf_speed)<SDL_GetTicks() || i_time_is_of_no_importants)
{
i_restorebg();
if((mi_x != mi_oldx) || (mi_y != mi_oldy))
i_savebg();
i_drawframe();
if(!mi_pause)
if(!((++mi_aktiveframe)%mi_number_of_frames)) mi_aktiveframe=0;

mi_oldx=mi_x; mi_oldy=mi_y;
ml_lastdrawn=SDL_GetTicks();
}

}

i_drawframe()
{
SDL_Rect rect_screen;
rect_screen.x=mi_x;
rect_screen.y=mi_y;
SDL_BlitSurface(pps_frames[mi_aktiveframe]->bmp,0,gs_screen,&rect_screen);
SDL_Flip(gs_screen);
return 0;
}

Share on other sites
SDL_Flip waits on the vertical sync to avoid tearing artifacts. Typically this occurs 70-85 times a second, or every 11 to 14ms. Therefore it's not really possible to move something more often than that and redisplay it in each discrete position as your screen simply doesn't update that fast. That's just a fact of life with graphics, really.

In a separate matter, SDL_GetTicks may not be as accurate as you like, so check up on that.

Share on other sites
Could it be that those are 8bit sprites and a 32bit surface, therefore you are forcing SDL to convert the sprite to 32bit from 8bit first? This could be really slow. Surely it's best to have the sprites you are blitting and the surface in the same format?

Just a guess.

Share on other sites
@Kylotan: thx for the tipp about SDL_Flip, maybe i should try to syncronice the sprites, and not flip after every single frame but after all sprites are drawn. [EDIT] Jp, flipping after all the drawing was done, seems to do the trick. Thx man [EDIT]

@LucidIon: jea they are 8 bit, but when loading i am using the SDL_DisplayFormat() function to addept them to the video modus, so they should get converted only one or?

Share on other sites
hmm, or at least it works for about 5 of this sprites. But when i use 7 of them its getting reallly slow.

Share on other sites
It might be your Hungarian notation. Try fixing that, and tell us what happens.

[wink]
Actualy, post your new code in [ source ] [ /source ] tags (without spaces).