Hi
Can anybody help me. I want to know how I can scroll with the SDL libary.
But I don?t know how I can do this.
Thanks for your help
Ferhat
Someone should put up a scrolling How-To. Or maybe put it in the SDL
FAQ. =)
http://www.mongeese.orgOn Thu, 8 Feb 2001, ferhat ziba wrote:
Hi
Can anybody help me. I want to know how I can scroll with the SDL libary.
But I don?t know how I can do this.Thanks for your help
Ferhat
There are countless different ways of doing this, and SDL indirectly supports
a great deal of them. What exactly do you want to do, in terms of resolution,
speed, frame rate, scene layout etc?
For full screen, multilevel parallax scrolling with lots of sprites the only
way is to simply redraw the entire scene every frame (possibly using various
caching algorithms in the background), except on targets with special
hardware acceleration of these things. (I know only of the Amiga and SNES
doing parallax scrolling in hardware, but I’ve read/heard that some arcade
machines and some other consoles do it as well.)
For simple full screen scrolling, you can use hardware scrolling on most
hardware, but SDL doesn’t support it. Also, very few drivers seem to support
it. The alternative is to do VRAM->VRAM blits to move the screen as quickly
as possible, and then update the areas that are scrolled in from outside the
display window. (DO NOT do this with the CPU! It’s faster only if the blits
are hardware accelerated.)
The simplest way is actually the method that is most portable and best
supported by all APIs and targets, and also (as mentioned above) compatible
with any type of scrolling or other transformations; repaint the entire
display every frame. Just paint the entire scene from back to front.
The most complicated part is probably rendering tiled backgrounds
efficiently: Don’t render the entire map relying on the clipping! Instead,
calculate where on the map the display window is, and then render only the
tiles fully or partially inside that area. That gets increasingly important
with bigger and more complex maps, especially on machines with slow CPUs.
//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 08 February 2001 19:42, ferhat ziba wrote:
Hi
Can anybody help me. I want to know how I can scroll with the SDL libary.
But I don?t know how I can do this.
> For full screen, multilevel parallax scrolling with lots of sprites the only
> way is to simply redraw the entire scene every frame (possibly using various
> caching algorithms in the background), except on targets with special
> hardware acceleration of these things. (I know only of the Amiga and SNES
> doing parallax scrolling in hardware, but I've read/heard that some arcade
> machines and some other consoles do it as well.)
The Atari Lynx could probably handle it, since it has “unlimited” number
of sprites. 
For simple full screen scrolling, you can use hardware scrolling on most
hardware, but SDL doesn’t support it.
And it should!!! Of course, I’d have to recode my scrolling games to
take advantage of it (and either COMPLETELY recode everything to an
in-between API, or have separate code, and fall back to my current
scrolling method for windowed mode or video cards w/o hardware scrolling)
Curious - what PC video cards have hardware scrolling?
> The simplest way is actually the method that is most portable and best > supported by all APIs and targets, and also (as mentioned above) compatible > with any type of scrolling or other transformations; repaint the entire > display every frame. Just paint the entire scene from back to front.Hehe… that’s the way I do it. 
That’s why Defendguin sucks on slow
machines. (Even PII/200 seem to have problems <:^( )
The most complicated part is probably rendering tiled backgrounds
efficiently: Don’t render the entire map relying on the clipping! Instead,
calculate where on the map the display window is, and then render only the
tiles fully or partially inside that area. That gets increasingly important
with bigger and more complex maps, especially on machines with slow CPUs.
It’s amazing how many people DON’T figure this out. Ugh!
-bill!
For full screen, multilevel parallax scrolling with lots of sprites the
only way is to simply redraw the entire scene every frame (possibly using
various caching algorithms in the background), except on targets with
special hardware acceleration of these things. (I know only of the Amiga
and SNES doing parallax scrolling in hardware, but I’ve read/heard that
some arcade machines and some other consoles do it as well.)The Atari Lynx could probably handle it, since it has “unlimited” number
of sprites.
Unlimited? Either it’s not, or it’s blitted hardware sprites; ie what the
Amiga called BOBs.
However, older arcade machines might well have done hundreds of real
sprites (ie generated on the fly by the RAMDAC, rather than written into VRAM
just like on the C64), as that was easier to build than fast blitters back
then. (You can implement it by basically daisy-chaining a bunch of 8-32
channel sprite generators, while a blitter and it’s RAM just has to be
brutally fast to deliver performance.)
For simple full screen scrolling, you can use hardware scrolling on most
hardware, but SDL doesn’t support it.And it should!!!
Well, I was about to design an SDL API extension to allow it, but there
doesn’t seem to be much driver support, so it would result in software,
blitter or OpenGL emulation most of the time.
Of course, I’d have to recode my scrolling games to
take advantage of it (and either COMPLETELY recode everything to an
in-between API, or have separate code, and fall back to my current
scrolling method for windowed mode or video cards w/o hardware scrolling)
I’m working on a project that might be of interest. It’s actually meant to
serve as a common API for efficient OpenGL and software rendering of parallax
scrolled games with plenty of sprites and effects, but could probably support
hardware scrolling transparently as well.
The basic idea is to provide an interface that separates graphics encoding,
rendering order and methods etc from the application in pretty much the same
way that a hardware sprite library would. Throw the data in, build your
scene, and then tell the engine to render your frames, updating the
graphics and scene as required. That is, the actual rendering could be done
in pretty much any way, using any kind of algorithms and hardware.
The problem is that the project has rather low priority, so I have no idea
when, or if it will ever become usable. At least, it seems that I’ve nearly
sorted out the retrace sync issue with Utah-GLX well enough to get back to
this project. (It felt kind of pointless tweaking the sub-pixel accurate,
ultra smooth scrolling when the whole fckng screen was jerking and
tearing…)
Curious - what PC video cards have hardware scrolling?
Basically every single card you can put in a PC, and then some, at least to
some extent. It’s just a matter of being able to change the VRAM display
start address with pixel granularity, which isn’t particularly hard to do
without the horrible bitmapped modes of the old times. (The C64, Amiga, Atari
STE and VGA [including mode-x, as it’s using the 4 planes] had to use
hardware shifters and extra regs to do pixel accurate horizontal scrolling.)
The problem might be that not all cards support finer address granularity
than the VRAM word size (usually 64-256 bits on modern cards), so you won’t
get single pixel horizontal resolution even in 32 bit/pixel modes… I don’t
know if cards still have those delay or shift registers, but I think most
of them do, as it’s not unusual with oversized desktops under Windows and X
being push-scrolled around - and that’s full frame rate and flicker free
regardless of resolution, so it pretty much has to be hardware scrolling.
The simplest way is actually the method that is most portable and best
supported by all APIs and targets, and also (as mentioned above)
compatible with any type of scrolling or other transformations; repaint
the entire display every frame. Just paint the entire scene from back to
front.Hehe… that’s the way I do it.
machines. (Even PII/200 seem to have problems <:^( )
I was trying to design a 2D rendering algorithm similar to span buffering to
eliminate all overdraw, but that was kind of complicated, to say the least! I
still think it’s doable, and my algorithm would work, but there’s too much
per frame preprocessing overhead for it to be a win on lower resolutions.
640x480x24bpp might not be enough…
Anyway, I think any PII+ should handle at least 100% overdraw easilly. (Even
my K6-200 could do full frame rate at 640x480x16bpp @ 60 Hz under DirectX!)
The problem is probably the usual flip blit or VRAM access thing…
The most complicated part is probably rendering tiled backgrounds
efficiently: Don’t render the entire map relying on the clipping!
Instead, calculate where on the map the display window is, and then
render only the tiles fully or partially inside that area. That gets
increasingly important with bigger and more complex maps, especially on
machines with slow CPUs.It’s amazing how many people DON’T figure this out. Ugh!
Yeah… Someone should hack a very basic example that anyone could read and
understand in about 5 mins. (One could actually make the method clearly
visible on screen by setting the “grab rect” smaller than the screen clip
rect.)
//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 08 February 2001 21:35, William Kendrick wrote:
Curious - what PC video cards have hardware scrolling?
Basically every single card you can put in a PC, and then some, at least to
some extent. It’s just a matter of being able to change the VRAM display
start address with pixel granularity, which isn’t particularly hard to do
without the horrible bitmapped modes of the old times. (The C64, Amiga, Atari
STE and VGA [including mode-x, as it’s using the 4 planes] had to use
hardware shifters and extra regs to do pixel accurate horizontal scrolling.)
FYI, as far as I know, there was no way to set the display base scanline
to an arbitrary value with the DirectX API, at least as of version 7.
However, DGA does support nearly arbitrary viewport scrolling, so some
functionality taking advantage of this will end up in SDL eventually.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
The Atari Lynx could probably handle it, since it has “unlimited” number
of sprites.Unlimited? Either it’s not, or it’s blitted hardware sprites; ie what the
Amiga called BOBs.
I’ve always seen it quoted as being “unlimited.” Since the Lynx shares
a lot with the Amiga, I’m guessing it’s BOBs.
Sounds cool.
Basically every single card you can put in a PC, and then some, at least to
some extent. It’s just a matter of being able to change the VRAM display
start address with pixel granularity, which isn’t particularly hard to do
without the horrible bitmapped modes of the old times. (The C64, Amiga,
Atari STE and VGA [including mode-x, as it’s using the 4 planes] had to use
hardware shifters and extra regs to do pixel accurate horizontal scrolling.)
Atari 400/800/XL/XE did, too, y’know!
What was cool with the Atari (and Amiga) was the graphics chip was
programmable, in a sense. You could tell it what kind of graphics mode
to display at a certain scanline, and even where in memory to pull the
data.
So to do some effect with a mirror image below it (like reflecting on
water), you just draw the image twice, then re-show those chunks of
memory, a line at a time, but backwards.
Add to this DLI’s (Display List Interrupts), which allowed you to change
color palette values and sprite locations, and you could do some wicked
stuff. (In the above example, imaging changing the palette to be more
blue on the mirror image… now it DOES look like water!)
-bill!
— William Kendrick wrote:
> For full screen, multilevel parallax scrolling with lots of sprites the only > way is to simply redraw the entire scene every frame (possibly using various > caching algorithms in the background), except on targets with special > hardware acceleration of these things. (I know only of the Amiga and SNES > doing parallax scrolling in hardware, but I've read/heard that some arcade > machines and some other consoles do it as well.)The Atari Lynx could probably handle it, since it
has “unlimited” number
of sprites.
I could be wrong, but, if memory serves, the Atari
Lynx
was practically a portable keyboard-less Amiga that
Atari bought out from under Commedore… (It might
have
been being designed by another company for Commedore
or
something like that…)
Best regards,
-Loren__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
I could be wrong, but, if memory serves, the Atari
Lynx
was practically a portable keyboard-less Amiga that
Atari bought out from under Commedore… (It might
have
been being designed by another company for Commedore
or
something like that…)
I believe Epyx was designing it. I forget, check the Lynx FAQ’s.
ALso, it’s definitely not an Amiga. It’s got a 6502 and some 16-bit
gfx chip(s)… not a 68000, like the Amiga.
It was hella cool. (Still is… I got one not too long ago, and
have a growing collection of games… most are excellent)
-bill!
The Atari Lynx could probably handle it, since it
has “unlimited” number
of sprites.I could be wrong, but, if memory serves, the Atari
Lynx
was practically a portable keyboard-less Amiga that
There are quite a few other things to suggest that as well. 4096
colors, 4 channel digital sound, and IIRC even 32 or 64 colors in the
palette… Never seen detailed docs, though.
Atari bought out from under Commedore… (It might
have
been being designed by another company for Commedore
or
something like that…)
Right, the Amiga was designed by another company, and then bought by
Commodore, IIRC. Can’t remember the name of that company 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 -'On Friday 09 February 2001 00:55, Loren Osborn wrote:
Curious - what PC video cards have hardware scrolling?
Basically every single card you can put in a PC, and then some,
at least to some extent. It’s just a matter of being able to
change the VRAM display start address with pixel granularity,
which isn’t particularly hard to do without the horrible
bitmapped modes of the old times. (The C64, Amiga, Atari STE and
VGA [including mode-x, as it’s using the 4 planes] had to use
hardware shifters and extra regs to do pixel accurate horizontal
scrolling.)FYI, as far as I know, there was no way to set the display base
scanline to an arbitrary value with the DirectX API, at least as of
version 7.
Knew that… 
However, DGA does support nearly arbitrary viewport
scrolling, so some functionality taking advantage of this will end
up in SDL eventually.
Sounds nice…
//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 09 February 2001 00:41, Sam Lantinga wrote:
Basically every single card you can put in a PC, and then some,
at least to some extent. It’s just a matter of being able to
change the VRAM display start address with pixel granularity,
which isn’t particularly hard to do without the horrible
bitmapped modes of the old times. (The C64, Amiga, Atari STE and
VGA [including mode-x, as it’s using the 4 planes] had to use
hardware shifters and extra regs to do pixel accurate horizontal
scrolling.)Atari 400/800/XL/XE did, too, y’know!
Yeah, actually most 8 bit and some 16 bit machines did, I think.
(They pretty much had to. Remember the ST, which barely had the
CPU power to do scrolling with the CPU - and it had to, as there
was no h/w scrolling before the STE.)
What was cool with the Atari (and Amiga) was the graphics chip was
programmable, in a sense. You could tell it what kind of graphics
mode to display at a certain scanline, and even where in memory to
pull the data.
Yep, that was fun. Unlimited horizontal split screens!
So to do some effect with a mirror image below it (like reflecting
on water), you just draw the image twice, then re-show those chunks
of memory, a line at a time, but backwards.
Of course, the h/w scrolling could be reprogrammed on each line as
well (on the Amiga; never programmed the 8 bit Ataris), so you could
improve the water effect some more, virtually for free.
Add to this DLI’s (Display List Interrupts), which allowed you to
change color palette values and sprite locations, and you could do
some wicked stuff. (In the above example, imaging changing the
palette to be more blue on the mirror image… now it DOES look like
water!)
The Amiga used a slave processor for that… I abused that to reload
the sprite DMA data registers (all DMA “stream ports” were accessible
as registers) for the sprite channels to get more than 8 sprites per
raster line. Perfect for score, lives, icons etc on top of a hardware
scrolling background!
Those were the days, eh?
//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 09 February 2001 00:39, William Kendrick wrote:
Of course, the h/w scrolling could be reprogrammed on each line as
well (on the Amiga; never programmed the 8 bit Ataris), so you could
improve the water effect some more, virtually for free.
Same on the Atari. Makes for nifty wave-in effects. (I kinda duplicated
them with blitting in my Linux game Defendguin…)
-bill!
(who finally installed Stella again… man this kicks ass… 2600 under Linux!)
The Atari Lynx could probably handle it, since it
has “unlimited” number
of sprites.I could be wrong, but, if memory serves, the Atari
Lynx
was practically a portable keyboard-less Amiga that
The Lynx has nothing to do with Amiga. It uses a 65C02 CPU vs
a 68000, and had two 16-bit custom co-processors (Mikey and
Suzy). Mikey controls sound, system timing, and video DMA.
Suzy controls the blitter, graphics engine (sprites, scrolling,
scaling), and math co-processing. The Lynx is also limited to 16
colors per scanline.
Amiga was originally produced by Amiga Inc. It was started by
former Atari hardware developer Jay Miner (Atari 2600, 400, 800).
Both Atari and Commodore wanted the Amiga back in 1984, but it
was Commodore that got it (I blame Jack Tramiel).
Jay Miner (and possibly two others from the Amiga design team)
later created the Lynx with Atari. That influence on the machine
might have led to the similarities in the two, but it stops there.
And yes, the Lynx has “unlimited” sprites.On 9 Feb 2001, at 4:04, David Olofson wrote:
On Friday 09 February 2001 00:55, Loren Osborn wrote:
There are quite a few other things to suggest that as well. 4096
colors, 4 channel digital sound, and IIRC even 32 or 64 colors in the
palette… Never seen detailed docs, though.Atari bought out from under Commedore… (It might
have
been being designed by another company for Commedore
or
something like that…)Right, the Amiga was designed by another company, and then bought by
Commodore, IIRC. Can’t remember the name of that company 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 -’
Jup !!! The AMIGA was cool !!!
CU
“David Olofson” schrieb im Newsbeitrag
news:01020904003104.01112 at qooick.hs…> On Friday 09 February 2001 00:39, William Kendrick wrote:
Basically every single card you can put in a PC, and then some,
at least to some extent. It’s just a matter of being able to
change the VRAM display start address with pixel granularity,
which isn’t particularly hard to do without the horrible
bitmapped modes of the old times. (The C64, Amiga, Atari STE and
VGA [including mode-x, as it’s using the 4 planes] had to use
hardware shifters and extra regs to do pixel accurate horizontal
scrolling.)Atari 400/800/XL/XE did, too, y’know!
Yeah, actually most 8 bit and some 16 bit machines did, I think.
(They pretty much had to. Remember the ST, which barely had the
CPU power to do scrolling with the CPU - and it had to, as there
was no h/w scrolling before the STE.)What was cool with the Atari (and Amiga) was the graphics chip was
programmable, in a sense. You could tell it what kind of graphics
mode to display at a certain scanline, and even where in memory to
pull the data.Yep, that was fun. Unlimited horizontal split screens!
So to do some effect with a mirror image below it (like reflecting
on water), you just draw the image twice, then re-show those chunks
of memory, a line at a time, but backwards.Of course, the h/w scrolling could be reprogrammed on each line as
well (on the Amiga; never programmed the 8 bit Ataris), so you could
improve the water effect some more, virtually for free.Add to this DLI’s (Display List Interrupts), which allowed you to
change color palette values and sprite locations, and you could do
some wicked stuff. (In the above example, imaging changing the
palette to be more blue on the mirror image… now it DOES look like
water!)The Amiga used a slave processor for that… I abused that to reload
the sprite DMA data registers (all DMA “stream ports” were accessible
as registers) for the sprite channels to get more than 8 sprites per
raster line. Perfect for score, lives, icons etc on top of a hardware
scrolling background!Those were the days, eh?
file://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 -’