Jerky scrolling

SDL Development
1

Hi everybody.

I’ve been making a simple space-shooter-like-thingy with a scrolling
background for some hours now. But the background scrolling is jerky at
times. It’s usually quite smooth, but then after every second or so, it
stops for a little moment and then resumes normally. I’m not really good at
describing it. If you like, you can download the demo here:
http://www.hot.ee/elevant123/lesson6-test1.zip (warning: ~3MB), or you can
get a source only version here:
http://www.hot.ee/elevant123/lesson6-test1-source.zip .

Know that the code is in development state: quite messy.

I’d be really grateful if anybody could help me.

Thanx,
Marius

2

I’m not seeing that on the (rather fast) Windoze box in the next room -
but the scrolling does seem rather “undecided” WRT speed. It jerks
regularly two or three times a second.

Looking at the code, I’m suspecting that the "delta time > 11 ms"
condition for updating the background is the cause of what I’m seeing
(I’d sugest calculating the position instead, and update whenever that
changes), but I don’t think it can explain any stall every few seconds…
Not sure, though - just try it. (Or try removing the condition
altogether; just render the whole screen every frame, and see what you
get.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Sunday 31 March 2002 01:54, Marius Andra wrote:

Hi everybody.

I’ve been making a simple space-shooter-like-thingy with a scrolling
background for some hours now. But the background scrolling is jerky at
times. It’s usually quite smooth, but then after every second or so, it
stops for a little moment and then resumes normally.

3

Hi everybody.

I’ve been making a simple space-shooter-like-thingy with a scrolling
background for some hours now. But the background scrolling is jerky at
times. It’s usually quite smooth, but then after every second or so, it
stops for a little moment and then resumes normally.

I’m not seeing that on the (rather fast) Windoze box in the next room -
but the scrolling does seem rather “undecided” WRT speed. It jerks
regularly two or three times a second.

Looking at the code, I’m suspecting that the "delta time > 11 ms"
condition for updating the background is the cause of what I’m seeing
(I’d sugest calculating the position instead, and update whenever that
changes), but I don’t think it can explain any stall every few seconds…
Not sure, though - just try it. (Or try removing the condition
altogether; just render the whole screen every frame, and see what you
get.)

I tried many different ways to scroll the background (including all of the
ones you mentioned). Unfortuanetly NONE of them help by making the scrolling
smoother :frowning:
The scroll++ every frame method helped a bit, by

Just how do you guys scroll your backgrounds (inf any of you even do scroll
them) ?

Marius

4

I’m sorry if this has already been suggested, but I’ve had problems with
unexplainable choppy motion before too, and I finally discovered that it
was an external program that woke every second on the second.

It actually turned out to be my development environment (probably
checking for syntax colouring or something).

Anyway, make sure it isn’t external.On Wed, 2002-04-03 at 10:17, Marius Andra wrote:

Hi everybody.

I’ve been making a simple space-shooter-like-thingy with a scrolling
background for some hours now. But the background scrolling is jerky at
times. It’s usually quite smooth, but then after every second or so, it
stops for a little moment and then resumes normally.

I’m not seeing that on the (rather fast) Windoze box in the next room -
but the scrolling does seem rather “undecided” WRT speed. It jerks
regularly two or three times a second.

Looking at the code, I’m suspecting that the "delta time > 11 ms"
condition for updating the background is the cause of what I’m seeing
(I’d sugest calculating the position instead, and update whenever that
changes), but I don’t think it can explain any stall every few seconds…
Not sure, though - just try it. (Or try removing the condition
altogether; just render the whole screen every frame, and see what you
get.)

I tried many different ways to scroll the background (including all of the
ones you mentioned). Unfortuanetly NONE of them help by making the scrolling
smoother :frowning:
The scroll++ every frame method helped a bit, by

Just how do you guys scroll your backgrounds (inf any of you even do scroll
them) ?

Marius

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

End of Rant.

Jimmy
Jimmy’s World (http://www.jimmysworld.org)
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020403/146e410e/attachment.pgp

5

hmm. Actually it seems that I have some spooky programs running that make
the scrolling kinda jerky. In linux everything was fine. Now I just need to
get non-jerky fps-independant scrolling…

Does SDL allow some kinda wainting for the monitors vsync, or something…?
I remember back in the old dos days to get good smooth stuff onto the
screen, I called something like waitvsync() after every frame…

Marius

6

hmm. Actually it seems that I have some spooky programs running that
make the scrolling kinda jerky.

That seems to be the most common problem by far…

In linux everything was fine. Now I
just need to get non-jerky fps-independant scrolling…

Well, I’d say the best you can do is OpenGL with subpixel accurate
rendering - and it works pretty well even without retrace sync or h/w
pageflipping. In fact, it works incredibly well under such
circumstances, as long as you keep the scrolling speeds reasonably low.
The traditional fixed speed scrolling shooters (usually 25 or 30 pixels/s
depending on whether the original version was PAL or NTSC) should be fine.

However, using OpenGL means that you’ll have to implement SDL 2D support
as well, unless you want to prevent any use on unaccelerated video
cards. It might be a good idea to start with SDL (smooth enough, usually,
especially in resolutions like 320x240), and implement the OpenGL part
later.

You can look at my smoothscrolling example at

http://olofson.net/mixed.html

for a simple demonstration of scrolling with both SDL and OpenGL. (It’s a
common “rendering API” - a bunch of function pointers - and two
implementations of that. Sub-pixel accurate rendering is used with
OpenGL, but not with SDL 2D.)

Does SDL allow some kinda wainting for the monitors vsync, or
something…?

Not explicitly, but it is supported where possible. AFAIK, syncronization
is done either in SDL_FlipSurface(), or the next time the screen surface
is locked (ie the next time you try to blit to it), depending on target.

I remember back in the old dos days to get good smooth
stuff onto the screen, I called something like waitvsync() after every
frame…

Right, that’s how it used to be done when you wanted fixed speed
scrolling on a display with a known, fixed refresh rate - like arcade
games, consoles and practically any computer that was designed to be
connected to a TV or video (PAL/NTSC) monitor.

VGA Mode-X (“custom mode”) counts as well, although even there, you
might find some weird card that refuses to comply with the standard VGA
clock rates. (I haven’t seen one, but OTOH, I’ve seen plenty that don’t
implement VGA h/w scrolling properly.)

Retrace sync still is essential for that perfectly smooth, flicker free
and tearing free scrolling that we were used to, BUT, you have to realize
that you have no idea what kind of refresh rate you’ll get. You just have
to deal with whatever you get, one way or another.

The most common solution is to calculate the position of every object for
each frame, and the round down to the nearest pixel. A more sophisticated
approach is doing the same, but with sub-pixel accurate rendering instead
of rounding.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 03 April 2002 20:10, Marius Andra wrote:

7

Hi everybody.

I’ve been making a simple space-shooter-like-thingy with a
scrolling background for some hours now. But the background
scrolling is jerky at times. It’s usually quite smooth, but then
after every second or so, it stops for a little moment and then
resumes normally.

I’m not seeing that on the (rather fast) Windoze box in the next room

  • but the scrolling does seem rather “undecided” WRT speed. It jerks
    regularly two or three times a second.

Looking at the code, I’m suspecting that the "delta time > 11 ms"
condition for updating the background is the cause of what I’m seeing
(I’d sugest calculating the position instead, and update whenever
that changes), but I don’t think it can explain any stall every few
seconds… Not sure, though - just try it. (Or try removing the
condition altogether; just render the whole screen every frame, and
see what you get.)

I tried many different ways to scroll the background (including all of
the ones you mentioned). Unfortuanetly NONE of them help by making the
scrolling smoother :frowning:
The scroll++ every frame method helped a bit, by

Try some of the “old” scrolling examples; parallax-2 would be the most
appropriate, I think:

http://olofson.net/mixed.html

Is that smoother than your code on your system? (You may want to tweak
it to use the same resolution as you’re using. The default is 320x240…)

Just how do you guys scroll your backgrounds (inf any of you even do
scroll them) ?

Well, except for the original Project Spitfire/DOS (which used h/w
scrolling with triple buffering, where the “third” buffer was used for
building new backgrounds using minimal CPU time per frame), I’m just
rendering the whole screen every frame, with object positions calculated
from the current time when the rendering starts.

Important: The time is checked right after the flip; not after rendering
each frame, or anything like that. This doesn’t guarantee that you’re
effectively timestamping the retraces, but at least, there’s a chance of
that happening on many targets.

Oh, and on most operating systems, filtering the timing will help, as you
can only dream about actually having your thread woken up right after
every retrace - there will be “random” scheduling latency, which
introduces jitter into your animation, even if you’re running at a steady
full frame rate. (Look at the smoothscroll-1.1 demo for a simple example
of time filtering.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 03 April 2002 17:17, Marius Andra wrote:

8

hmm. Actually it seems that I have some spooky programs running that
make the scrolling kinda jerky.

That seems to be the most common problem by far…

yup

In linux everything was fine. Now I
just need to get non-jerky fps-independant scrolling…

Well, I’d say the best you can do is OpenGL with subpixel accurate
rendering - and it works pretty well even without retrace sync or h/w
pageflipping. In fact, it works incredibly well under such
circumstances, as long as you keep the scrolling speeds reasonably low.
The traditional fixed speed scrolling shooters (usually 25 or 30 pixels/s
depending on whether the original version was PAL or NTSC) should be fine.

However, using OpenGL means that you’ll have to implement SDL 2D support
as well, unless you want to prevent any use on unaccelerated video
cards. It might be a good idea to start with SDL (smooth enough, usually,
especially in resolutions like 320x240), and implement the OpenGL part
later.

You can look at my smoothscrolling example at

http://olofson.net/mixed.html

for a simple demonstration of scrolling with both SDL and OpenGL. (It’s a
common “rendering API” - a bunch of function pointers - and two
implementations of that. Sub-pixel accurate rendering is used with
OpenGL, but not with SDL 2D.)

I looked at your smoothscrolling before. It also did seem to suffer from the
same problems mine suffered in windows (when I used the scroll++; method
every frame). I actually don’t want to use OpenGL this time because after I
create the game. I’m going to create some tutorials about how to build it
(cone3d.gamedev.net). And since the tutorials will be SDL oriented, using
opengl might not be a good idea.

Does SDL allow some kinda wainting for the monitors vsync, or
something…?

Not explicitly, but it is supported where possible. AFAIK, syncronization
is done either in SDL_FlipSurface(), or the next time the screen surface
is locked (ie the next time you try to blit to it), depending on target.

ok. I see.

I remember back in the old dos days to get good smooth
stuff onto the screen, I called something like waitvsync() after every
frame…

Right, that’s how it used to be done when you wanted fixed speed
scrolling on a display with a known, fixed refresh rate - like arcade
games, consoles and practically any computer that was designed to be
connected to a TV or video (PAL/NTSC) monitor.

VGA Mode-X (“custom mode”) counts as well, although even there, you
might find some weird card that refuses to comply with the standard VGA
clock rates. (I haven’t seen one, but OTOH, I’ve seen plenty that don’t
implement VGA h/w scrolling properly.)

Retrace sync still is essential for that perfectly smooth, flicker free
and tearing free scrolling that we were used to, BUT, you have to realize
that you have no idea what kind of refresh rate you’ll get. You just have
to deal with whatever you get, one way or another.

The most common solution is to calculate the position of every object for
each frame, and the round down to the nearest pixel. A more sophisticated
approach is doing the same, but with sub-pixel accurate rendering instead
of rounding.

ok. I’ve put up a bit newer version of the game to
http://cone3d.gamedev.net/files/sdlgfx/lesson6.zip . I put in 2 scrolling
methods: scroll = ((int)(SDL_GetTicks() * 0.05)) % 3909 (3909 = size of the
bg image); (<- is that what you meant by rounding down to the nearest
pixel?) and scroll++; They can be toggled with ENTER/RETURN.

Marius

9

Hi everybody.

I’ve been making a simple space-shooter-like-thingy with a
scrolling background for some hours now. But the background
scrolling is jerky at times. It’s usually quite smooth, but then
after every second or so, it stops for a little moment and then
resumes normally.

I’m not seeing that on the (rather fast) Windoze box in the next room

  • but the scrolling does seem rather “undecided” WRT speed. It jerks
    regularly two or three times a second.

Looking at the code, I’m suspecting that the "delta time > 11 ms"
condition for updating the background is the cause of what I’m seeing
(I’d sugest calculating the position instead, and update whenever
that changes), but I don’t think it can explain any stall every few
seconds… Not sure, though - just try it. (Or try removing the
condition altogether; just render the whole screen every frame, and
see what you get.)

I tried many different ways to scroll the background (including all of
the ones you mentioned). Unfortuanetly NONE of them help by making the
scrolling smoother :frowning:
The scroll++ every frame method helped a bit, by

Try some of the “old” scrolling examples; parallax-2 would be the most
appropriate, I think:

http://olofson.net/mixed.html

Is that smoother than your code on your system? (You may want to tweak
it to use the same resolution as you’re using. The default is 320x240…)

When I put the resolution to 640x480x32, your parallax scrolling demo runs
even worse than my own. I’ll try it later (tomorrow) in linux. (I’m in
windows right now, I’m having some trouble with my network card in linux and
windows is the only place where I can use the internet atm…)

Just how do you guys scroll your backgrounds (inf any of you even do
scroll them) ?

Well, except for the original Project Spitfire/DOS (which used h/w
scrolling with triple buffering, where the “third” buffer was used for
building new backgrounds using minimal CPU time per frame), I’m just
rendering the whole screen every frame, with object positions calculated
from the current time when the rendering starts.

ok.

Important: The time is checked right after the flip; not after rendering
each frame, or anything like that. This doesn’t guarantee that you’re
effectively timestamping the retraces, but at least, there’s a chance of
that happening on many targets.

ok, I’ll implement that.

Oh, and on most operating systems, filtering the timing will help, as you
can only dream about actually having your thread woken up right after
every retrace - there will be “random” scheduling latency, which
introduces jitter into your animation, even if you’re running at a steady
full frame rate. (Look at the smoothscroll-1.1 demo for a simple example
of time filtering.)

ok, I’ll do that…

Marius

10

[…]

You can look at my smoothscrolling example at
[…]
I looked at your smoothscrolling before. It also did seem to suffer
from the same problems mine suffered in windows (when I used the
scroll++; method every frame).

Ok… Did you try the 1.1 version, with the time filter? It helps a lot
on some systems, and in particular, it looked great on the same machine I
tested your code on the other day.

I actually don’t want to use OpenGL this
time because after I create the game. I’m going to create some
tutorials about how to build it (cone3d.gamedev.net). And since the
tutorials will be SDL oriented, using opengl might not be a good idea.

Ok. No sub-pixel accurate rendering, that is. (Well, you could pre-render
a bunch of “shifted” versions of the background, of course…)

[…]

I remember back in the old dos days to get good smooth
stuff onto the screen, I called something like waitvsync() after
every frame…

Right, that’s how it used to be done when you wanted fixed speed
scrolling on a display with a known, fixed refresh rate - like arcade
games, consoles and practically any computer that was designed to be
connected to a TV or video (PAL/NTSC) monitor.

VGA Mode-X (“custom mode”) counts as well, although even there, you
might find some weird card that refuses to comply with the standard
VGA clock rates. (I haven’t seen one, but OTOH, I’ve seen plenty that
don’t implement VGA h/w scrolling properly.)

Retrace sync still is essential for that perfectly smooth, flicker
free and tearing free scrolling that we were used to, BUT, you have
to realize that you have no idea what kind of refresh rate you’ll
get. You just have to deal with whatever you get, one way or another.

The most common solution is to calculate the position of every object
for each frame, and the round down to the nearest pixel. A more
sophisticated approach is doing the same, but with sub-pixel accurate
rendering instead of rounding.

ok. I’ve put up a bit newer version of the game to
http://cone3d.gamedev.net/files/sdlgfx/lesson6.zip . I put in 2
scrolling methods: scroll = ((int)(SDL_GetTicks() * 0.05)) % 3909 (3909
= size of the bg image); (<- is that what you meant by rounding down to
the nearest pixel?)

Kind of. It’s pretty much the only way you can do it without OpenGL or
similar, unless you have an insanely fast CPU and/or very efficient SIMD
code.

and scroll++; They can be toggled with
ENTER/RETURN.

Ok, I’ll have a look at it.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 03 April 2002 22:49, Marius Andra wrote:

11

[…]

Is that smoother than your code on your system? (You may want to
tweak it to use the same resolution as you’re using. The default is
320x240…)

When I put the resolution to 640x480x32, your parallax scrolling demo
runs even worse than my own.

Well, it probably should - it’s rendering at least twice as many pixels
per frame as your code. (That’s what make the latter versions different;
they use variants of a recursive overdraw elimination algorithm.)

BTW, note that the parallax examples don’t use any time filtering. You
system might be one of those that really need that feature - or one
that simply needs a properly working driver…

I’ll try it later (tomorrow) in linux.

Ok.

[…]

Important: The time is checked right after the flip; not after
rendering each frame, or anything like that. This doesn’t guarantee
that you’re effectively timestamping the retraces, but at least,
there’s a chance of that happening on many targets.

ok, I’ll implement that.

Oh, and on most operating systems, filtering the timing will help, as
you can only dream about actually having your thread woken up right
after every retrace - there will be “random” scheduling latency,
which introduces jitter into your animation, even if you’re running
at a steady full frame rate. (Look at the smoothscroll-1.1 demo for a
simple example of time filtering.)

ok, I’ll do that…

…although, if you can’t even get smooth scrolling when you move a fixed
number of pixels each frame, something weird is going on. Judging by the
facts seen so far, it sounds like your system or video card driver is
misbehaving in some way.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 03 April 2002 23:40, Marius Andra wrote:

12

[…]

ok. I’ve put up a bit newer version of the game to
http://cone3d.gamedev.net/files/sdlgfx/lesson6.zip . I put in 2
scrolling methods: scroll = ((int)(SDL_GetTicks() * 0.05)) % 3909
(3909 = size of the bg image);

Ok, I’ve tried it on Win32 now, and I’ve also hacked up some half-arsed
autoconf/automake scripts to try it on Linux.

On both systems, I’m seeing the same “pulsating” effect I saw in the
previous version. No other problems, though, except that in’s painfully
slow on Linux. (600 MHz Celeron; some 32 MB ATI Rage Pro AGP card.) I had
to use SDL_UpdateRects() on a small area of the screen to get any useful
data. (I considered trying it with glSDL as well, but I don’t have a
version that can tile “huge surfaces” around here… :wink:

Anyway, I can see three problems with this version:

1) The player movement speed, and apparently some other
   stuff (not sure) scale with the frame rate.

2) You're calling SDL_GetTicks() all over the place. Don't!
   Call it once, right after you flipped the screen, and
   then use the timing calculated there throughout while
   rendering a frame.

3) This might be a result of 2), as well as the computers
   around here being nasty, but the time could *really*
   use some filtering, it seems. I suspect that this
   "pulsating" instability has to do with this.

Oh, and keep in mind that scrolling without sub-pixel accurate rendering
cannot be even remotely as smooth with, especially not at low speeds.
Try some very high scrolling speeds to reduce the effect of the
positional inaccuracies in the rendering - should make it easier to tell
that kind of effects from any “real” timing issues.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 03 April 2002 23:21, David Olofson wrote: