Can SDL and Linux really be used for high speed games?

David_Olofson · November 6, 2000, 3:00pm

Fri, 03 Nov 2000 Michael Vance wrote:

[…2D acceleration stuff…]

If it’s not obvious by now, I’m a 3D guy

This is the general problem with 2D on all platforms; no one seems to care much
about 2D performance. Obviously, no one cares to hack drivers for stuff that
they don’t use, which has serious impact on Free/Open Source projects…

(Indeed, 2D acceleration on Windows is rather crippled compared to 3D
acceleration on the same platform, but it seems to me that the difference is
bigger on Linux.)

David Olofson
Programmer
Reologica Instruments AB
david.olofson at reologica.se

David_Olofson · November 6, 2000, 4:29pm

Sun, 05 Nov 2000 Mattias Engdeg?rd wrote:

However, as X11
doesn’t support double buffering (that’s the probem if I understand it
correctly), this is quite irrelevant, unless the blits are faster than the CRT
beam. (Which they should be on decent machines, but…)

X11 supports double buffering perfectly well since it uses a software
backing surface. Don’t confuse double-buffering with hardware page-flipping.

Doh! I meant hardware page-flipping, of course.

As for the “where to place data” and blitting vs. software rendering issues,
that’s obviously the complicated part, and unfortunately, I can’t say that I’m
much more motivated to fix it than most other people, unless it turns out
that 3D accelerators doing 2D stuff can’t result in a decent, good looking and
ultra smooth 2D game engine.

Alas, it turns out that they can’t. Also, I refuse to require hardware
3d acceleration for a 2d game that is perfectly feasible with just
basic 2d operations.

Well, it depends on whan kind of visual effects you want to use. If there is
multilevel parallax scrolling and lots of translucency, hardware acceleration
will be required anyway. Why should 2D games look like they did 5 years ago,
just because they’re 2D…?

Not only would it be a display of incompetence,
but it would also impose needless limits to my target audience (and I
do not only include 3-year old machines, but also wearables,
handhelds, wireless gadgets, etc).

Is it being incompetent or being realistic not to write two very different
engines that will most likely require special versions and/or heavy
preprocessing of some or all of the data? At some point, you’ll have to
redesign the game in order to make it run and still be playable on low end
machines… unless you simply ignore the existence of powerful machines and
users who like a massive visual impression. (Remember; frame rate is hardly
negotiable in fast 2D action games. Demolish the graphics and effects, but
never sacrifice the frame rate, because that results in severe loss of
playability!)

But of course, it is usually possible to have both software and hardware
rendering engines, just as many 3D games still have, although this usually
results in the CPU requirement for the software rasterizer being unrealistic in
proportion to the GPU requirements for the accelerated version. Ok, some
people probably have monster CPUs with crappy video cards, but…

I have never seen svgalib being used with anything but memcpy-style
transfers to video memory, which should be considerably slower than
direct transfer even if the MTRR are set to write-combining for the
vidmem area and judicious amount of prefetching hints are used.
I’d like to see a comparison though

Do you mean accelerated blits vs. CPU blits in VRAM, or sysram->VRAM blits
using the CPU vs. DMA?

the latter

Ok…

David Olofson
Programmer
Reologica Instruments AB
david.olofson at reologica.se

Mattias_Engdegard · November 7, 2000, 2:25pm

Well, it depends on whan kind of visual effects you want to use. If there is
multilevel parallax scrolling and lots of translucency, hardware acceleration
will be required anyway. Why should 2D games look like they did 5 years ago,
just because they’re 2D…?

True, but the design space is very far from exhausted, and I think the
variety of hardware in use is greater today than 5 or 10 years ago.
Lowest end today are 486:es, old workstations and Macs (both of which
tend to stay around for much longer than their PC counterparts),
orders of magnitude slower than cutting-edge hardware. And they run
many SDL games just fine (like Maelstrom).

Is it being incompetent or being realistic not to write two very different
engines that will most likely require special versions and/or heavy
preprocessing of some or all of the data? At some point, you’ll have to
redesign the game in order to make it run and still be playable on low end
machines… unless you simply ignore the existence of powerful machines and
users who like a massive visual impression.

Let me get this straight here: I have nothing against the use of openGL
for (visually and/or gameplay-wise) 2D games — in fact, I think it is
good to find some serious use of 3D hardware for a change; otherwise
people will just use them for silly “3D” games.

What I do object to is lazy use of more hardware than the game really
requires; this is no different from bad coding causing a tetris clone
to require a 500MHz Rectium, since that is what the developer had,
though he lacked any sense of proportions. (This is by no means
restricted to games — why do we need lots of cpu/RAM to run a mere
web browser these days?)

And if the game could run perfectly well without OpenGL, except for a
particular cute visual effect that the developer fell in love with,
wouldn’t it be wise to drop that effect, or make it optional, instead
of requiring 3d hardware? It would broaden the target audience, and
give old or small boxes an extra unexpected usefulness.

Design is everything!

David_Olofson · November 7, 2000, 10:32pm

Tue, 07 Nov 2000 Mattias Engdeg?rd wrote:

Well, it depends on whan kind of visual effects you want to use. If there is
multilevel parallax scrolling and lots of translucency, hardware acceleration
will be required anyway. Why should 2D games look like they did 5 years ago,
just because they’re 2D…?

True, but the design space is very far from exhausted, and I think the

Very good point there!

Also, it seems that gameplay is still lower priority than audiovisual effects
in a great deal of the new games; an effect that hit the 16 bit machines real
hard when they arrived, and seems to have returned now, and is continously
maintained by the evolution of 3D technology.

variety of hardware in use is greater today than 5 or 10 years ago.
Lowest end today are 486:es, old workstations and Macs (both of which
tend to stay around for much longer than their PC counterparts),
orders of magnitude slower than cutting-edge hardware. And they run
many SDL games just fine (like Maelstrom).

My reasoning behind hardware scrolling support was to incorporate single level
full screen scrolling games in this class - not to provide faster acceleration
(which is not even possible) for games that need heavy blit acceleration anyway.

Is it being incompetent or being realistic not to write two very different
engines that will most likely require special versions and/or heavy
preprocessing of some or all of the data? At some point, you’ll have to
redesign the game in order to make it run and still be playable on low end
machines… unless you simply ignore the existence of powerful machines and
users who like a massive visual impression.

Let me get this straight here: I have nothing against the use of openGL
for (visually and/or gameplay-wise) 2D games — in fact, I think it is
good to find some serious use of 3D hardware for a change; otherwise
people will just use them for silly “3D” games.

What I do object to is lazy use of more hardware than the game really
requires; this is no different from bad coding causing a tetris clone
to require a 500MHz Rectium, since that is what the developer had,
though he lacked any sense of proportions. (This is by no means
restricted to games — why do we need lots of cpu/RAM to run a mere
web browser these days?)

I absolutely agree here. The reason I want to use 3D acceleration is that I’ve
investigated doing what I want all in software, and realized it’s just not
realistic, if at all possible. Since I’m into fast scrolling games, even
implementing a crappy looking software engine would require heavy
optimization - it’s a lot harder than I first expected when I compared the
power of current machines to what there was in the 8 and 16 bit machines…

And if the game could run perfectly well without OpenGL, except for a
particular cute visual effect that the developer fell in love with,
wouldn’t it be wise to drop that effect, or make it optional, instead
of requiring 3d hardware? It would broaden the target audience, and
give old or small boxes an extra unexpected usefulness.

Well, it could be that smooth scrolling maps are just a “cute visual effect”,
just like this whole 3D perspective thing.

Actually, back in the C64 days, full screen scrolling was not far from what 3D
is today; technically complicated to implement, but considered required to
sell copies. Meanwhile, I had a good time the other day, playing Impossible
Mission on a C64 emulator…

Then again, I had a very good time playing Doom and Doom II (all the way
through both actually; no cheating) - but I’m totally convinced by now that
it’s not because of the 3D perspective. The majority of the newer 3D games are
better looking, but incredibly boring and feel “dead” in some way, like
graphics engine demos.

Design is everything!

Amen.

//David

slouken · November 8, 2000, 6:21am

Pierre suggested the idea some while ago, but it wasn’t pursued since
shaped blits were so slow then. If they are faster now in XFree 4.x,
it would be worth taking up again. Slow pixel access is only a problem
if you need it, and many games don’t need it (or at least not often).

Just for perspective, most of the beautiful graphic effects in the 2D
games Loki has ported are done by pixel level access. Static backgrounds
and sprites are only one class of 2D game.

The real solution here is to
use DGA, and I think I have it working without root priveliges if you
have the frame buffer console enabled, but I need more test platforms…

How does that work, at the low level? By using a kernel driver that
exposes a mmapped window of the video memory?

It uses the framebuffer console to get access to the video memory. Heh.

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

slouken · November 8, 2000, 6:23am

Sam said:

That’s correct. If you ask for SDL_HWSURFACE and get it (possible with
the DirectX, DGA, and framebuffer console drivers), the screen pixels
pointer points directly to display VRAM. If that is true, you can also
create other surfaces with the SDL_HWSURFACE flag,

How do you do this when loading images from disk, for example? >:^)

Use SDL_DisplayFormat().

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

Mattias_Engdegard · November 8, 2000, 11:29am

Just for perspective, most of the beautiful graphic effects in the 2D
games Loki has ported are done by pixel level access. Static backgrounds
and sprites are only one class of 2D game.

Indeed. Maybe the SDL_VideoInfo struct could contain a pixel_access_is_slow
bit, to help with video mode selection when that is implemented

David_Olofson · November 8, 2000, 2:55pm

Wed, 08 Nov 2000 Sam Lantinga wrote:

Pierre suggested the idea some while ago, but it wasn’t pursued since
shaped blits were so slow then. If they are faster now in XFree 4.x,
it would be worth taking up again. Slow pixel access is only a problem
if you need it, and many games don’t need it (or at least not often).

Just for perspective, most of the beautiful graphic effects in the 2D
games Loki has ported are done by pixel level access. Static backgrounds
and sprites are only one class of 2D game.

How about DMA from system memory + 2D or 3D acceleration, when available? Looks
like this memory->VRAM DMA will be needed for interesting effects, even in
games where most of the graphics is done by 2D or 3D blitting from VRAM to
VRAM…

Besides, mixing acceleration with direct framebuffer access is a serious
performance problem, especially when the rendering can’t be split in two
stages, with extra back buffers to keep the CPU and GPU from fighting over the
locks.

//David

David_Olofson · November 8, 2000, 4:58pm

Wed, 08 Nov 2000 David Olofson wrote:
[…]

Besides, mixing acceleration with direct framebuffer access is a serious
performance problem, especially when the rendering can’t be split in two
stages, with extra back buffers to keep the CPU and GPU from fighting over the
locks.

Hey, I just realized that real time generated animations (such as particle
effects) aren’t all that different from video playback. That is, it can be
buffered for one or more extra frames in relation to the display buffers, so
that the hardware blitting won’t have to fight over surface locks to get at the
source data.

Figure illustrating this not-too-revolutionary idea:

      Display
         /\
  ----- /||\ -------> Flip >--------------------
 |  _____||_____   ____________   ____________  |
 |  |          |   |          |   |          |  |
 |  |          |   |          |   |          |  |
  --| Buffer 1 |<--| Buffer 2 |<--| Buffer 3 |<-
    |          |   |          |   |          |
    |__________|   |__________|   |__________|
                     (Queue)           /\
                                      /||\
                                       ||
                                      H/W
                  VRAM surfaces ---> RENDER
                                       ^
                                       |

→ SysRAM buf 3 → SysRAM buf 2 → SysRAM buffer 1 –
| ^ |
-------- | -----------< Flip <--------------------------
|
S/W
RENDER

Indeed, this requires some extra thought when figuring out how to gather input
data (such as sprite positions for particle collisions), as the software
rendering will be two frames ahead of the rest of the rendering engine, but
hey, when did you ever get speed for free!?

//David