SDL Scrolling Example!

SDL Development
1

Is there a simple Scrolling Example available online at www.libsdl.org ???
I am converting a Game and i want to use a Multiplattformlib like SDL or
ALLEGRO or PTC ???
But before i use this or that Lib i want to see how good the Lib is able to
scroll. Is the Scrolling acurate, is it soft
and so on. If there is no Scrolling Example available on www.libsdl.org
could anybody write a simple
Example in SDL that scrolls a 16Bit Picture out of the Right or Left Border
with a given Framerate ???

Thanks very much !!1

2

Is there a simple Scrolling Example available online at www.libsdl.org ???

I was thinking about writing one just the other day… :slight_smile:

I am converting a Game and i want to use a Multiplattformlib like SDL or
ALLEGRO or PTC ???
But before i use this or that Lib i want to see how good the Lib is able to
scroll. Is the Scrolling acurate, is it soft and so on.

Well, providing you have enough power to update the screen at full frame
rate, there shouldn’t be much (see below) trouble on targets that support
retrace sync. It’s about as fast as it gets, provided you do everything right.

There are some performance issues due to the lack of sysRAM->VRAM DMA blits
on some targets, but that’s not SDL’s fault. AFAIK, this issue, as well as
the lack of retrace sync - is mostly related to UN*X based targets.

If there is no Scrolling Example available on www.libsdl.org
could anybody write a simple
Example in SDL that scrolls a 16Bit Picture out of the Right or Left Border
with a given Framerate ???

If you want it real smooth, you should use hardware accelerated OpenGL with
bilinear filtering. I’m working on a library for that (also including
transparent software rendering “fallback”), and it looks incredibly smooth,
regardless of frame rate and scroll speed.

The problem with smooth scrolling these days is that you cannot safely set or
even check the refresh rate, so you can’t rely on fixed integer pixels/frame
scrolling speeds.

My solution is to “abuse” the texture filtering of the 3D accelerator for sub
pixel accurate rendering, which means that you can scroll say 0.97
pixels/frame, and still create an illusion of the background moving with a
rock steady, constant speed.

This applies to sprites as well, of course. Full scene antialiazing and
focus/blurring effects are free bonuses.

Of course, there is a disadvantage: You really need hardware acceleration
for this to look good, and you need pretty decent acceleration at that, at
least for resolutions that really look good. The screen has to use at least
50% higher resolution than the source graphics data to get smooth sub pixel
accurate animation without “phasor” effects on small details.

Machines that I’ve sucessfully tried the basic methods on:

P-II 400	Mach64 Rage Pro AGP
P-III 933	Matrox G400 MAX AGP

3D cards from the generation before the Rage Pro and older probably won’t
work too well, as many of them can’t blend and filter at the same time. Some
can’t filter at all! Most of them probably have inadequate fillrates for full
frame rate in anything higher than 320x240…

So, it all comes down to your target audience, and how much work you want to
put into making arcade machines look worthless. :slight_smile:

Note: On Utah-GLX/XFree86, you also need my retrace sync patch - or you can
forget about smooth scrolling without tearing. (No h/w pageflipping…)

Ok… Now we’re almost off topic! :slight_smile:

So back to basics; what exactly do you mean by “accurate” and “soft”?

If you want the ultra smooth full frame rate feel of high powered game
consoles and arcade machines, you’re pretty much limited to using 3D
acceleration.

If you were happy with the average Amiga game with half frame rate (25 Hz)
animation, you might get away with software rendering without sub pixel
accuracy. However, as you can’t rely on getting the exact refresh rate you
tuned the game for (say 70 Hz), you may have to accept smooth scrolling with
a “jerk” every few frames. (I personally find that pretty annoying; worse
than a lower frame rate actually!)

If you considered “Flying Shark” on Amiga and Atari ST smooth (varying
between ~8 and 16 fps, I think), well, then you don’t have to worry about any
of this! :wink:

(Rolling Thunder? hehe I don’t think I’ve ever seen a game that slow, not
even java applets on slow PCs! Amazing… Locked at 6 fps or so; C64, Amiga
and Atari ST all the same. Even more amazing; I still liked something about
that dog slow and bl**dy annoying game.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | --------------------------------------> david at linuxdj.com -'On Thursday 15 February 2001 11:38, WIZARD / SYNTHETIC - Crew wrote:

3

Is there a simple Scrolling Example available online at www.libsdl.org ???
I am converting a Game and i want to use a Multiplattformlib like SDL or
ALLEGRO or PTC ???

My game “Defendguin” scrolls. Defendguin [New Breed Software]

There are many, many more which scroll, too.

(Why does this subject keep coming up? It needs to be answered in an FAQ! :slight_smile: )

-bill!

4

My game “Defendguin” scrolls. Defendguin [New Breed Software]

There are many, many more which scroll, too.

(Why does this subject keep coming up? It needs to be answered in an FAQ! :slight_smile: )

What’s needed is a good tutorial. Akawaka is accepting submissions. :slight_smile:

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

5

Is there a simple Scrolling Example available online at www.libsdl.org
???
I am converting a Game and i want to use a Multiplattformlib like SDL or
ALLEGRO or PTC ???
My game “Defendguin” scrolls. Defendguin [New Breed Software]
There are many, many more which scroll, too.

If you know OpenGL, you could just texture a cylinder and rotate it as
necessary. :slight_smile:

Scrolling is usually such a special case that it is written by whoever needs
it, as a generic scroller probably wouldn’t be very fast.–

Olivier A. Dagenais - Software Architect and Developer

6

I don’t think that’s much of a problem with h/w accelerated OpenGL
rasterization. There’s plenty of time (compared to the 8 and 16 bit eras :slight_smile:
to do all sorts of “flexibility maths”, and lots of precalculations can be
done for 2D, so I think a “generic” OpenGL 2D engine could be pretty
efficient.

I can’t think of many problems with implementing the following, behind a
“build world of objects; repeat { tweak parameters; render; }” fashion API:

Main:
	* Multilevel parallax scrolling
	* Accurate speed with any refresh rate
	* Transparent support for multiple screen resolutions

Objects:
	* Sprites
	* Multisprites ("Component animations")
	* Polygons
	* Convex 3D models
	* Procedural sprites
	* Tiled background layers
	* Procedural tiles
	* Large image layers
	* Layers streaming from disk
	* Video display windows

For all objects:
	* Full antialiazing
	* Subpixel accurate positioning
	* Zooming
	* Stretching
	* Rotation
	* Shearing
	* Alpha blending
	* Additive blending
	* Vertex lighting
	* Color effects

And here are some slightly heavier or more complicated effects, although
still not beyond reach of the average OpenGL card:

Main:
	* "Depth of field" effects

Objects:
	* Pixel/particle effects
	* Procedural background layers
	* "Unlimited" 3D models

For all objects:
	* Various other deformations

For most objects:
	* Lightmaps
	* Out-of-focus blur
	* Motion blur

I haven’t even seen all these features used in console and arcade games, and
I doubt there are many 2D and iso-3D games that would need something that
can’t realistically be done with such an engine. You would need to implement
multiple pixel format versions of any custom pixel effects or other
procedural stuff for maximum performance, but that’s a loooong way from
writing a custom engine from scratch… :slight_smile:

(Yeah, I have some hacking to do… heh)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | --------------------------------------> david at linuxdj.com -'On Thursday 15 February 2001 19:08, Olivier Dagenais wrote:

Is there a simple Scrolling Example available online at www.libsdl.org

???

I am converting a Game and i want to use a Multiplattformlib like SDL
or ALLEGRO or PTC ???

My game “Defendguin” scrolls.
Defendguin [New Breed Software] There are many, many more
which scroll, too.

If you know OpenGL, you could just texture a cylinder and rotate it as
necessary. :slight_smile:

Scrolling is usually such a special case that it is written by whoever
needs it, as a generic scroller probably wouldn’t be very fast.

7

This reminds me of a trick used to create smooth scroll for
MSX 2:

Because of severe limitations of the MSX hardware, almost
every good MSX game used a mix of graphics and text mode, so
you could use redrawn characters as background and monochromatic
sprites for everything else, because drawing primitives are slow.
So the scroll was fixed at 8 pixels in side scroll games (like
Gradius or R-Type).

MSX 2 games were no different, they used the same scroll engine.
But, MSX 2 allowed you to control the position of the screen, so
the game could adjust the screen position without real updates to
the background 7/8 of the time. It’s necessary to compensate
the undesired sprite scrolling, so you move all of them forward 1
pixel everytime you move the screen back. Then after you count 7
pixels moved, you scroll an entire character (8 pixels), reset
the screen position, move all sprites 7 pixels back, and start
counting again. Almost perfect, but now you have to deal with
things on the screen that shouldn’t move, like score points,
number of lives etc. You have to make them look static, but the
whole screen is moving. So you create sprites for numbers too.

I don’t know how they came up with such idea. But although the
machine was serverely limited, they managed to do lots of nice
tricks out of it.

Now, just to be a little on-topic, Xserver can do this smooth
scrolling effect when you create a virtual screen bigger than
real screen. Could it be used to do smooth scrolling in games?On Thu, Feb 15, 2001 at 04:45:43PM +0100, David Olofson wrote:

If you were happy with the average Amiga game with half frame rate (25 Hz)
animation, you might get away with software rendering without sub pixel
accuracy. However, as you can’t rely on getting the exact refresh rate you
tuned the game for (say 70 Hz), you may have to accept smooth scrolling with
a “jerk” every few frames. (I personally find that pretty annoying; worse
than a lower frame rate actually!)

If you considered “Flying Shark” on Amiga and Atari ST smooth (varying
between ~8 and 16 fps, I think), well, then you don’t have to worry about any
of this! :wink:

(Rolling Thunder? hehe I don’t think I’ve ever seen a game that slow, not
even java applets on slow PCs! Amazing… Locked at 6 fps or so; C64, Amiga
and Atari ST all the same. Even more amazing; I still liked something about
that dog slow and bl**dy annoying game.)

–
Pedro.

8

If you were happy with the average Amiga game with half frame rate (25
Hz) animation, you might get away with software rendering without sub
pixel accuracy. However, as you can’t rely on getting the exact refresh
rate you tuned the game for (say 70 Hz), you may have to accept smooth
scrolling with a “jerk” every few frames. (I personally find that pretty
annoying; worse than a lower frame rate actually!)

If you considered “Flying Shark” on Amiga and Atari ST smooth (varying
between ~8 and 16 fps, I think), well, then you don’t have to worry about
any of this! :wink:

(Rolling Thunder? hehe I don’t think I’ve ever seen a game that slow,
not even java applets on slow PCs! Amazing… Locked at 6 fps or so; C64,
Amiga and Atari ST all the same. Even more amazing; I still liked
something about that dog slow and bl**dy annoying game.)

This reminds me of a trick used to create smooth scroll for
MSX 2:

Because of severe limitations of the MSX hardware, almost
every good MSX game used a mix of graphics and text mode, so
you could use redrawn characters as background and monochromatic
sprites for everything else, because drawing primitives are slow.

Many C64 games use character + multicolor mode in that way, instead of “real”
multicolor mode. (3 colors per 8x8 square + common background, pixels merged
horizontally into 4x8 to address the 4 colors.)

So the scroll was fixed at 8 pixels in side scroll games (like
Gradius or R-Type).

No “finescroll”? hehe

MSX 2 games were no different, they used the same scroll engine.
But, MSX 2 allowed you to control the position of the screen, so
the game could adjust the screen position without real updates to
the background 7/8 of the time.

Just like the C64. :slight_smile:

It’s necessary to compensate
the undesired sprite scrolling, so you move all of them forward 1
pixel everytime you move the screen back. Then after you count 7
pixels moved, you scroll an entire character (8 pixels), reset
the screen position, move all sprites 7 pixels back, and start
counting again.

Messy with the sprites - the C64 did nothing like that, IIRC… :slight_smile:

Almost perfect, but now you have to deal with
things on the screen that shouldn’t move, like score points,
number of lives etc. You have to make them look static, but the
whole screen is moving. So you create sprites for numbers too.

Yeah, same thing I did on the Amiga… (Using the copper to do “manual DMA”
for the sprite channels when a channels didn’t cut it.)

I don’t know how they came up with such idea. But although the
machine was serverely limited, they managed to do lots of nice
tricks out of it.

That’s the boring side of modern machines; there are no reliable tricks to do
on the low level. It’s all raw CPU power, or “nice, well defined APIs”… Ok,
doing stuff with 100% code has other interesting sides, but anyway. Modern PC
CPU power + some basic good old hardware tricks could do amazing things.

However, I think one can have quite a lot of fun with a decent 3D accelerator

  • procedural texturing, so all is not lost… :slight_smile:

Now, just to be a little on-topic, Xserver can do this smooth
scrolling effect when you create a virtual screen bigger than
real screen. Could it be used to do smooth scrolling in games?

I would guess so… It seems like DGA supports it.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | --------------------------------------> david at linuxdj.com -'On Thursday 15 February 2001 21:49, Pedro Medeiros wrote:

On Thu, Feb 15, 2001 at 04:45:43PM +0100, David Olofson wrote:

9

What about consistent fonts at different resolutions? Even commercial games
sometimes have problems with that!

  • Brent> Main:
  • Multilevel parallax scrolling
  • Accurate speed with any refresh rate
  • Transparent support for multiple screen resolutions

Objects:

  • Sprites
  • Multisprites (“Component animations”)
  • Polygons
  • Convex 3D models
  • Procedural sprites
  • Tiled background layers
  • Procedural tiles
  • Large image layers
  • Layers streaming from disk
  • Video display windows
10

Well, if characters are rendered as sprites or procedural sprites, you kind
of get that for free.

(As an example, the current proof-of-concept hack library already treats the
screen coordinate system as a virtual coordinate system; ie you can set any
“screen size” you want regardless of the actual resolution. The test program
always use a 320x240 coordinate system regardless of actual screen
resolution.)

Of course, those methods will mean bitmap scaling (the textures are always
of the same resolution), which may not be appropriate for high quality text.
You’d have to use some kind of vector font data for that, but I still can’t
see why this would be a problem. Just render the font at a suitable
resolution after setting up the display, and then use the “virtual screen
coordinat system” as usual. (Texture size in pixels doesn’t matter when
rendering, not even on the OpenGL API level.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | --------------------------------------> david at linuxdj.com -'On Friday 16 February 2001 03:40, Brent Schartung wrote:

What about consistent fonts at different resolutions? Even commercial
games sometimes have problems with that!

11

Example in SDL that scrolls a 16Bit Picture out of the Right or Left Border
with a given Framerate ???

I’ve been playing with a very simple scrolling example. Heres the url below:

http://members.optushome.com.au/nho/scrolling.tar.bz2

Its in 16 bit mode. Oh, and theres no error checking of any sort else it
wouldn’t be very simple :slight_smile:

Nghia

12

Nice and simple, indeed! :slight_smile:

I think I’ll expand some on tiled maps in the form of a “scrolling-2”
example, if you don’t mind…

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | --------------------------------------> david at linuxdj.com -'On Saturday 17 February 2001 14:26, Nghia wrote:

Example in SDL that scrolls a 16Bit Picture out of the Right or
Left Border with a given Framerate ???

I’ve been playing with a very simple scrolling example. Heres the
url below:

http://members.optushome.com.au/nho/scrolling.tar.bz2

Its in 16 bit mode. Oh, and theres no error checking of any sort
else it wouldn’t be very simple :slight_smile:

13

There; a second example, building on the one by Nghia, adding tiles
and a map. :slight_smile:

The 4 tiles are in the same image, as I prefer to do it for various
reasons. It appears to be the cleanest and simplest way to do it,
even for a very basic example. (Note that the tiles are stacked
vertically for cache friendliness when doing software blitting. :wink:

http://www.angelfire.com/ar/agc/download/scrolling_2.bz2

(Note that the bl**dy Angelfire server mangles plain, normal Un*x
file names into something similar to MS-DOG names… It’s a .tar.bz2,
not just a .bz2. >:-/ Don’t have access to usable web space right
now.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

14

Nice and simple, indeed! :slight_smile:

I think I’ll expand some on tiled maps in the form of a “scrolling-2”
example, if you don’t mind…

Thanks for the feedback .The FPS define is a bit dodgy I wasn’t thinking
straight but it should be obvious :slight_smile:
The scrolling appears to slow down a bit when I drag the window around.

15

Very nice example, I did have one question regarding the code (rather a
question on a comment found in the code). On lines 68 and 69 of main.c, as you
are defining dest_rect for the screen, you mention:

dest_rect.w = TILE_W;		/* These two are ignored by SDL! */
dest_rect.h = TILE_H;

Are they really ignored by SDL? I had always assumed that whenever a non-NULL
value was used, all values were important (actually, hadn’t thought much about
it, but I would also assume that the smaller of the two rects .w and .h would
win out over the other…) Just curious…

Thx.On Sat, 17 Feb 2001, you wrote:

There; a second example, building on the one by Nghia, adding tiles
and a map. :slight_smile:

The 4 tiles are in the same image, as I prefer to do it for various
reasons. It appears to be the cleanest and simplest way to do it,
even for a very basic example. (Note that the tiles are stacked
vertically for cache friendliness when doing software blitting. :wink:

http://www.angelfire.com/ar/agc/download/scrolling_2.bz2

(Note that the bl**dy Angelfire server mangles plain, normal Un*x
file names into something similar to MS-DOG names… It’s a .tar.bz2,
not just a .bz2. >:-/ Don’t have access to usable web space right
now.)

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

16

Yeah, and it should, as the timing doesn’t do anything but add to
the time it takes to process one frame.

I have a simple fix for that in the Project Spitfire port I hacked
yesterday (16 hrs straight, constant hacking, translating Object
Pascal/DOS/VGA Mode-X; 80% or so done, I think… :slight_smile:

I can hack it into “Scrolling 3 - Timing” or something… Interested?

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | --------------------------------------> david at linuxdj.com -'On Sunday 18 February 2001 01:59, Nghia wrote:

Nice and simple, indeed! :slight_smile:

I think I’ll expand some on tiled maps in the form of a
“scrolling-2” example, if you don’t mind…

Thanks for the feedback .The FPS define is a bit dodgy I wasn’t
thinking straight but it should be obvious :slight_smile:
The scrolling appears to slow down a bit when I drag the window
around.

17

There; a second example, building on the one by Nghia, adding
tiles and a map. :slight_smile:

The 4 tiles are in the same image, as I prefer to do it for
various reasons. It appears to be the cleanest and simplest way
to do it, even for a very basic example. (Note that the tiles are
stacked vertically for cache friendliness when doing software
blitting. :wink:

http://www.angelfire.com/ar/agc/download/scrolling_2.bz2

(Note that the bl**dy Angelfire server mangles plain, normal Un*x
file names into something similar to MS-DOG names… It’s a
.tar.bz2, not just a .bz2. >:-/ Don’t have access to usable web
space right now.)

Very nice example, I did have one question regarding the code
(rather a question on a comment found in the code). On lines 68 and
69 of main.c, as you are defining dest_rect for the screen, you
mention:

dest_rect.w = TILE_W; /* These two are ignored by SDL! */
dest_rect.h = TILE_H;

Are they really ignored by SDL?

The documentation says so, but I was being a bit paranoid, as it was
in the first version of the example. :slight_smile:

I think those lines should actually just be removed.

I had always assumed that whenever
a non-NULL value was used, all values were important (actually,
hadn’t thought much about it, but I would also assume that the
smaller of the two rects .w and .h would win out over the other…)
Just curious…

That would make some sense. Scaling the area to the now size would be
another logical response to providing non-zero values…

It also makes sense to not even consider these values, as that would
mean that you don’t have to initialize those fields of the rect, and
SDL can just ignore them - that’s why it is like that, I’d guess.

One could claim that SDL_Rect isn’t the right tool here in the first
place, but it does have a “bonus” feature; SDL_BlitSurface() stores
the final rect after clipping there, so you may use that to check
whether anything was drawn or not:

(rect.w && rect.h) == "sprite is visible"

Handy, eh? :slight_smile: Clipping and similar calculations are not free, so
it’s rather nice if you can reuse the output rather than doing it all
over again.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | --------------------------------------> david at linuxdj.com -'On Sunday 18 February 2001 02:42, Samuel Hart wrote:

On Sat, 17 Feb 2001, you wrote:

18

I certainly would. You can never have too many examples! :wink:

Plus, if anyone is interrested in a really inefficient and wasteful (but very
quick and dirty) way of doing simple scrolling, check out my game, Tux Typing
http://www.geekcomix.com/dm/tuxtype/. I scroll the background at the title
screen in a very shameful way… but it was quick and easy (for those apps
where you may not care much!)On Sun, 18 Feb 2001, you wrote:

Yeah, and it should, as the timing doesn’t do anything but add to
the time it takes to process one frame.

I have a simple fix for that in the Project Spitfire port I hacked
yesterday (16 hrs straight, constant hacking, translating Object
Pascal/DOS/VGA Mode-X; 80% or so done, I think… :slight_smile:

I can hack it into “Scrolling 3 - Timing” or something… Interested?

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