Problem with frame rate

Hi guys,
I have a problem with my last game, a sample copy of pong!
The frame rate of this game is very little (about 3 frame per second ((: )
I don’t understand why!
Can somebody help me with little info?
tnx

This is a very common question, with a very simple question. :slight_smile: You’re
probably running in a very high resolution, and calling SDL_Flip() every
frame. :slight_smile:

Every time you call SDL_Flip(), it blits the ENTIRE contents of the backbuffer
to the physical video memory. At 80060016bpp, that’s nearly a megabyte of
data per frame. So, to get a nice 80FPS, you’d need a constant 80MB/s
throughput. That IS possible on some setups, but a real waste. :slight_smile:

You don’t HAVE to redraw the entire screen, is the thing. You only need to
draw what’s changed. Typical sequence goes like:

  1. Draw your background in the rectangles where your sprites are and were
  2. Move your sprites
  3. Draw your sprites
  4. Update the screen where the sprites are and were

Done correctly, this results in a massive performance increase; you’re only
drawing/updating a few sprites instead of an entire meg of data.

For updating parts of the screen rather than the whole thing, look into the
SDL_UpdateRects and/or SDL_UpdateRect functions. SDL_UpdateRects updates an
entire array of rectangles you give it, while SDL_UpdateRect just updates one
specified rectangle.On Wednesday 12 March 2003 11:57 am, NighTiger wrote:

Hi guys,
I have a problem with my last game, a sample copy of pong!
The frame rate of this game is very little (about 3 frame per second ((: )
I don’t understand why!
Can somebody help me with little info?
tnx

Every time you call SDL_Flip(), it blits the ENTIRE contents of the backbuffer
to the physical video memory. At 80060016bpp, that’s nearly a megabyte of
data per frame. So, to get a nice 80FPS, you’d need a constant 80MB/s
throughput. That IS possible on some setups, but a real waste. :slight_smile:

That’s silly.

As long as you’re double- or triple-buffering in hardware, SDL_Flip() should
only switch around a couple pointers in video memory, instantaneously. Only
in some cases are copy-blits needed; most commonly when rendering to a window.

And even when it has to blit, the backbuffer is still in video memory, so
it’s a very fast hardware blit. Sending an extra 80mb/sec from system memory
to the video card is expensive; blitting 80mb/sec internally on the
video card is not. (It’s not free, but it’s not that bad.)

I’m assuming SDL handles these optimizations, since they’re utterly
fundamental to a 2D graphics API. (I don’t know for sure, since I’ve
only used SDL with OpenGL, which takes flipping out of SDL’s hands.)

You don’t HAVE to redraw the entire screen, is the thing. You only need to
draw what’s changed. Typical sequence goes like:

  1. Draw your background in the rectangles where your sprites are and were
  2. Move your sprites
  3. Draw your sprites
  4. Update the screen where the sprites are and were

If you’re writing a side-scroller, the entire screen changes every frame,
since the entire screen is scrolling (and trying to optimize the scrolling
in this type of a game using hardware blits would be a horrible pain).

I’d imagine that vsync would be harder to handle here, too, but I’m not
sure.On Wed, Mar 12, 2003 at 03:32:11PM -0600, Tyler Montbriand wrote:


Glenn Maynard

Yeah, I couldn’t agree more - but even so, it’s the only way to do it
on some platforms.

That’s just the way it is. In some cases, it’s because no one is paid
to fix it, and in other cases, it’s because no one has been motivated
enough to fix it so far.

Another thing to keep in mind is that rendering directly into VRAM
isn’t always optimal. If you’re using heavy blending effects and
can’t have them h/w accelerated, you get the slideshow effect if you
work directly in VRAM. In that case, s/w back buffer is vastly
superior, whether or not you use it together with a h/w pageflipping
double or triple buffered display.

…or just do what the hardware is designed for: Use OpenGL. :wink:

(Actually, some OpenGL implementations do “blit flips” as well, even
in fullscreen modes. However, then it’s indeed all in VRAM and fully
accelerated, so it’s not that much of a performance issue. An extra
fullscreen blit per frame doesn’t kill a modern accelerator, although
it certainly is a waste.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Wednesday 12 March 2003 23.02, Glenn Maynard wrote:

On Wed, Mar 12, 2003 at 03:32:11PM -0600, Tyler Montbriand wrote:

Every time you call SDL_Flip(), it blits the ENTIRE contents of
the backbuffer to the physical video memory. At 80060016bpp,
that’s nearly a megabyte of data per frame. So, to get a nice
80FPS, you’d need a constant 80MB/s throughput. That IS possible
on some setups, but a real waste. :slight_smile:

That’s silly.

Every time you call SDL_Flip(), it blits the ENTIRE contents of the backbuffer
to the physical video memory. At 80060016bpp, that’s nearly a megabyte of
data per frame. So, to get a nice 80FPS, you’d need a constant 80MB/s
throughput. That IS possible on some setups, but a real waste. :slight_smile:

That’s silly.

As long as you’re double- or triple-buffering in hardware, SDL_Flip() should
only switch around a couple pointers in video memory, instantaneously. Only
in some cases are copy-blits needed; most commonly when rendering to a window.

And even when it has to blit, the backbuffer is still in video memory, so
it’s a very fast hardware blit. Sending an extra 80mb/sec from system memory
to the video card is expensive; blitting 80mb/sec internally on the
video card is not. (It’s not free, but it’s not that bad.)

In many cases, and on many platforms, the back buffer is stored in
system memory and must be copied to the display buffer. What you are
describing is only true in the case of a hardware buffer and hardware
acceleration of rendering on hardware buffers is not available on all
platforms. The copy can be made even slower by selecting a pixel depth
that the hardware can’t support. SDL will give you a software buffer
with the pixel depth you want, and then convert to the display pixel
depth (and format) during the copy.

Reality has a way of turning the “silly” into gritty reality.

I’m assuming SDL handles these optimizations, since they’re utterly
fundamental to a 2D graphics API. (I don’t know for sure, since I’ve
only used SDL with OpenGL, which takes flipping out of SDL’s hands.)

It is utterly fundamental that reality trumps assumptions, read the
documentation.

	Bob PendletonOn Wed, 2003-03-12 at 16:02, Glenn Maynard wrote:

On Wed, Mar 12, 2003 at 03:32:11PM -0600, Tyler Montbriand wrote:

You don’t HAVE to redraw the entire screen, is the thing. You only need to
draw what’s changed. Typical sequence goes like:

  1. Draw your background in the rectangles where your sprites are and were
  2. Move your sprites
  3. Draw your sprites
  4. Update the screen where the sprites are and were

If you’re writing a side-scroller, the entire screen changes every frame,
since the entire screen is scrolling (and trying to optimize the scrolling
in this type of a game using hardware blits would be a horrible pain).

I’d imagine that vsync would be harder to handle here, too, but I’m not
sure.

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

In many cases, and on many platforms, the back buffer is stored in
system memory and must be copied to the display buffer. What you are
describing is only true in the case of a hardware buffer and hardware
acceleration of rendering on hardware buffers is not available on all
platforms.

Reality has a way of turning the “silly” into gritty reality.

I’d say that a system that can’t handle hardware back buffers at all
isn’t suitable for running games at all. (The simplest of PC graphics
cards a decade ago could handle this, though they often didn’t have the
memory to do it in any resolution.)

(Of course, people write games for systems unsuitable for gaming all the
time, but that’s their own headache and they can keep it. :slight_smile:

Of course, I agree with David: OpenGL.

The copy can be made even slower by selecting a pixel depth
that the hardware can’t support. SDL will give you a software buffer
with the pixel depth you want, and then convert to the display pixel
depth (and format) during the copy.

In this case, performance is fairly doomed from the start.On Wed, Mar 12, 2003 at 05:02:10PM -0600, Bob Pendleton wrote:


Glenn Maynard

I’d say that a system that can’t handle hardware back buffers at all
isn’t suitable for running games at all.

You’re assuming fullscreen, I think. What about in a window? Windowing and
hardware doublebuffering are incompatible by nature; I get MUCH higher
performance under X-windows with partial redraws than I get with SDL_Flip()
and with good reason. :slight_smile:

(Of course, people write games for systems unsuitable for gaming all the
time, but that’s their own headache and they can keep it. :slight_smile:

And, when they make it work, support more platforms and sell more games. :slight_smile:

Of course, I agree with David: OpenGL.

OpenGL is nice - when it’s there. Software rendering when not, isn’t quite as
nice. Not compiling at all 'cause it isn’t on your target platform’s even
not-nicer. I’m gonna try exploring things with glsdl; mebbe, using clever
#ifdefs, it’s possible to use it only when it’s available?

The copy can be made even slower by selecting a pixel depth
that the hardware can’t support. SDL will give you a software buffer
with the pixel depth you want, and then convert to the display pixel
depth (and format) during the copy.

In this case, performance is fairly doomed from the start.

In that we’re in total agreement. Fortunately it ain’t a problem; setting
the videomode with the SDL_ANYFORMAT flag gives you the bit-depth you
requested only when the hardware actually uses it.On Wednesday 12 March 2003 05:33 pm, Glenn Maynard wrote:

I’d say that a system that can’t handle hardware back buffers at all
isn’t suitable for running games at all.

You’re assuming fullscreen, I think. What about in a window? Windowing and
hardware doublebuffering are incompatible by nature; I get MUCH higher
performance under X-windows with partial redraws than I get with SDL_Flip()
and with good reason. :slight_smile:

I tend to assume fullscreen for games in general.

In the immediate case, “NighTiger” might want to narrow down his problem
somewhat–make sure formats match, and benchmark in a window, and if
everything else is working and it’s still too slow, only then start
thinking about harder stuff like partial updates. (This was mostly what
triggered my response–don’t start worrying about redesigning your
renderer at a low level until you’ve exhausted the more straightforward
options.)

Most directly: Don’t guess. Profile.

(Of course, people write games for systems unsuitable for gaming all the
time, but that’s their own headache and they can keep it. :slight_smile:

And, when they make it work, support more platforms and sell more games. :slight_smile:

Maybe. :slight_smile: (I won’t draw out this debate here.)

Of course, I agree with David: OpenGL.

OpenGL is nice - when it’s there. Software rendering when not, isn’t quite as
nice. Not compiling at all 'cause it isn’t on your target platform’s even
not-nicer. I’m gonna try exploring things with glsdl; mebbe, using clever
#ifdefs, it’s possible to use it only when it’s available?

Software rendering with OpenGL is generally useless. (StepMania runs
150-400 fps on my system, even in a window; it occasionally manages 3 without
acceleration, even without texture filtering.)

I don’t see any reason why you couldn’t use glSDL selectively (for
non-OpenGL apps). In fact, it’d be nice if it was completely
transparent, enabled or disabled at runtime (perhaps based on the
presence of OpenGL acceleration), but maybe very difficult. I’ve
never used it.On Wed, Mar 12, 2003 at 08:09:08PM -0600, Tyler Montbriand wrote:

On Wednesday 12 March 2003 05:33 pm, Glenn Maynard wrote:


Glenn Maynard

Hello Bob,

Thursday, March 13, 2003, 1:02:10 AM, you wrote:

BP> In many cases, and on many platforms, the back buffer is stored in
BP> system memory and must be copied to the display buffer. What you are
BP> describing is only true in the case of a hardware buffer and hardware
BP> acceleration of rendering on hardware buffers is not available on all
BP> platforms.

Back to 1996, eh?
And another myth is born here.

Please give me a list of platforms which have more than 5% of users and
does not support HARDWARE BUFFERS with HARDWARE ACCELERATION.–
Lynx,
http://dotNet.lv mailto:@Anatoly_R

In many cases, and on many platforms, the back buffer is stored in
system memory and must be copied to the display buffer. What you are
describing is only true in the case of a hardware buffer and hardware
acceleration of rendering on hardware buffers is not available on all
platforms.

Reality has a way of turning the “silly” into gritty reality.

I’d say that a system that can’t handle hardware back buffers at all
isn’t suitable for running games at all.

If would appear that you and I have very different definitions of the
word “game”. Card games, board games, most strategy games, and even 2D
action games can run just fine on that kind of a system. And, because
they don’t depend on a high performance graphics back end they run on a
very wide range of computers and therefore have a huge potential market.

(The simplest of PC graphics
cards a decade ago could handle this, though they often didn’t have the
memory to do it in any resolution.)

I was writing games on those cards 10 years ago and one of the ways you
got good rendering performance was to render into main memory, copy into
the back buffer, and then swap buffers. The combination of triple
buffering and high speed access to the in memory rendering buffer got
you the speed. Of course that only worked for games that were dominated
by rendering time.

Now days you see a lot the same kinds of restrictions on PDAs and cell
phones that we had on PCs 10 years ago. Real programmers writing
commercial games on popular platforms have to deal with this kind of
stuff everyday. BTW, PDAs and cell phones are becoming hugely profitable
game platforms.

(Of course, people write games for systems unsuitable for gaming all the
time, but that’s their own headache and they can keep it. :slight_smile:

Of course, I agree with David: OpenGL.

For high performance games newer desktop PCs this is the correct choice.
If you are going after the part of the market dominated by games like
Quake, it is the only portable choice.

The copy can be made even slower by selecting a pixel depth
that the hardware can’t support. SDL will give you a software buffer
with the pixel depth you want, and then convert to the display pixel
depth (and format) during the copy.

In this case, performance is fairly doomed from the start.

Not necessarily, and there are cases where the memory savings could
justify using this feature.

		Bob PendletonOn Wed, 2003-03-12 at 17:33, Glenn Maynard wrote:

On Wed, Mar 12, 2003 at 05:02:10PM -0600, Bob Pendleton wrote:


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

[…]

Of course, I agree with David: OpenGL.

OpenGL is nice - when it’s there. Software rendering when not,
isn’t quite as nice. Not compiling at all 'cause it isn’t on your
target platform’s even not-nicer. I’m gonna try exploring things
with glsdl; mebbe, using clever #ifdefs, it’s possible to use it
only when it’s available?

The #ifdefs are already there; you just need to add OpenGL detection
to your build scripts. (Look at Kobo Deluxe for an example.)

It would be more interesting to load OpenGL dynamically. Then binaries
compiled with OpenGL support would run on systems without OpenGL as
well. (glSDL just refuses to enable OpenGL rendering, as if you had
left out the SDL_GLSDL flag.) Currently, I have to build a separate
non-OpenGL version of Kobo Deluxe, or people w/o OpenGL can’t even
load the binary.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Thursday 13 March 2003 03.09, Tyler Montbriand wrote:

[…]

I don’t see any reason why you couldn’t use glSDL selectively (for
non-OpenGL apps). In fact, it’d be nice if it was completely
transparent, enabled or disabled at runtime (perhaps based on the
presence of OpenGL acceleration), but maybe very difficult. I’ve
never used it.

You can do that already. An application compiled with glSDL will use
SDL rendering unless it passes the SDL_GLSDL flag to
SDL_SetVideoMode(), so you just have to reopen the screen to switch.
All glSDL demos use a command line switch to enable OpenGL rendering,
BTW.

The only problem is that glSDL links statically with OpenGL, so if
there’s no OpenGl shared lib or DLL, the binary just won’t load.
(Un*x platforms will say something like "Unresolved symbol blah…"
and Win32 will say something about missind DLLs.)

SDL itself uses some OpenGL calls, but loads OpenGL dynamically to
avoid this problem. glSDL will do it the same way whenever I get
around to turn it into a real backend.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Thursday 13 March 2003 03.24, Glenn Maynard wrote:

2.5G and 3G cell phones. Want me to give you the details of how I
implemented animation on a 3G network using WAP? How about the Pocket PC
devices such as the IPAQ, or anything that runs Palm OS? I haven’t seen
one so far that had a graphics accelerator or hardware back buffers.
I’ll admit that I haven’t looked in the last year either.

I have to admit that the 5% of users requirement makes the question
tough so I went with devices where I know that the entire platform lacks
acceleration so by definition 100% of users are affected. BTW, last time
I looked cell phones and PDAs were the fastest growing game platforms
and could soon exceed the numbers of PCs + PS2 + NES64 + XBOX combined.

	Bob PendletonOn Thu, 2003-03-13 at 02:01, Anatoly R. wrote:

Hello Bob,

Thursday, March 13, 2003, 1:02:10 AM, you wrote:

BP> In many cases, and on many platforms, the back buffer is stored in
BP> system memory and must be copied to the display buffer. What you are
BP> describing is only true in the case of a hardware buffer and hardware
BP> acceleration of rendering on hardware buffers is not available on all
BP> platforms.

Back to 1996, eh?
And another myth is born here.

Please give me a list of platforms which have more than 5% of users and
does not support HARDWARE BUFFERS with HARDWARE ACCELERATION.


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

Hello Bob,

Thursday, March 13, 2003, 6:14:20 PM, you wrote:

Please give me a list of platforms which have more than 5% of users and
does not support HARDWARE BUFFERS with HARDWARE ACCELERATION.

BP> 2.5G and 3G cell phones. Want me to give you the details of how I
BP> implemented animation on a 3G network using WAP? How about the Pocket PC
BP> devices such as the IPAQ, or anything that runs Palm OS? I haven’t seen
BP> one so far that had a graphics accelerator or hardware back buffers.
BP> I’ll admit that I haven’t looked in the last year either.

BP> I have to admit that the 5% of users requirement makes the question
BP> tough so I went with devices where I know that the entire platform lacks
BP> acceleration so by definition 100% of users are affected. BTW, last time
BP> I looked cell phones and PDAs were the fastest growing game platforms
BP> and could soon exceed the numbers of PCs + PS2 + NES64 + XBOX combined.

Ok, first, 2.5G/3G phones do not have SDL on them :slight_smile:

And yes, iPAQ is an exception from rules which is very nice.

Anyway, to port an application to iPAQ you’ll have to redo interface,
change resolution etc so there is no need to worry about it on early
stages where your target platform is something major.
Right?

And nobody around here except couple of guys cares about it. Yet.
I want to get iPAQ myself with supreme XScale processor. But I assume
that next autumn iPAQ will already have some accelerated embedded gfx
chip and we’ll surely pass that annoying “hey, 90s are back!” part.–
Lynx,
http://dotNet.lv mailto:@Anatoly_R

Hello Bob,

Thursday, March 13, 2003, 6:14:20 PM, you wrote:

Please give me a list of platforms which have more than 5% of users and
does not support HARDWARE BUFFERS with HARDWARE ACCELERATION.

BP> 2.5G and 3G cell phones. Want me to give you the details of how I
BP> implemented animation on a 3G network using WAP? How about the Pocket PC
BP> devices such as the IPAQ, or anything that runs Palm OS? I haven’t seen
BP> one so far that had a graphics accelerator or hardware back buffers.
BP> I’ll admit that I haven’t looked in the last year either.

BP> I have to admit that the 5% of users requirement makes the question
BP> tough so I went with devices where I know that the entire platform lacks
BP> acceleration so by definition 100% of users are affected. BTW, last time
BP> I looked cell phones and PDAs were the fastest growing game platforms
BP> and could soon exceed the numbers of PCs + PS2 + NES64 + XBOX combined.

Ok, first, 2.5G/3G phones do not have SDL on them :slight_smile:

Can you prove that? :-}

And yes, iPAQ is an exception from rules which is very nice.

Anyway, to port an application to iPAQ you’ll have to redo interface,
change resolution etc so there is no need to worry about it on early
stages where your target platform is something major.
Right?

Yes, but that is not the question you asked. ;->

Having played two different versions of DOOM on the IPAQ I can tell you
that the amount of redesign was very small.

And nobody around here except couple of guys cares about it. Yet.
I want to get iPAQ myself with supreme XScale processor. But I assume
that next autumn iPAQ will already have some accelerated embedded gfx
chip and we’ll surely pass that annoying “hey, 90s are back!” part.

There you go, making assumptions about things again…

What is going on here is that you have one frame of reference and I have
another. When I say something, it is based on my frame of reference and
when you interpret it, you must interpret it in your frame of reference.
You also seem to care that you are right, and I know I care about being
accurate. The result is that we are bound to miscommunicate.

My guess is that you are primarily a PC programmer. (if I am wrong I
apologize in advance.) I’ve spent most of the last 6 years working on
ways to deliver interactive entertainment on a wide variety of network
topologies and technologies and an even wider range of devices including
set top boxes, cell phones, and PDAs. My frame of reference is bound to
be different from yours.

		Bob PendletonOn Thu, 2003-03-13 at 11:27, Anatoly R. wrote:


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