Why is 2D so slow?

Hi, this topic follows the previous one “Tilting or rotating an image”.

I’m still wondering why old hardwares like the Super Nintendo Entertainement System
was able to do fast 2D blits, transformations (Mode 7) and all, with a slow processor (max: 3.58Mhz, you read correctly) and very limited graphical chipset (128Ko VRAM), and that nowadays, with our super fast hardwares we have to use OpenGL or Direct3D to hope having something equal. (exemple: smooth scrolling, David Olofson knows a lot about it ;))
At least, something equal at higher resolutions like 640x480, 800x600.

I’m aware that a PC/Mac runs more than one process at once, but if you use "top"
you see that most of them use very few of the system ressources, beeing “dormant”.

So what is the reason ? Aren’t our favorite operating systems too complex to handle this ?
Why not provide an operating system dedicated to gaming ?

Cheers
Julien

----- Message d’origine ----De : Armond Sarkisian <armond.sarkisian at gmail.com>
? : sdl at libsdl.org
Envoy? le : Vendredi, 25 Juillet 2008, 18h12mn 52s
Objet : [SDL] Tilting or rotating an image

Say you load an image such as a jpg file. How would one go about rotating the
image left or right? Thanks for any info provided.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

  _____________________________________________________________________________ 

Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

Hi, this topic follows the previous one “Tilting or rotating an
image”.

I’m still wondering why old hardwares like the Super Nintendo
Entertainement System was able to do fast 2D blits, transformations
(Mode 7) and all, with a slow processor (max: 3.58Mhz, you read
correctly) and very limited graphical chipset (128Ko VRAM),

The SNES used custom designed hardware acceleration for those
features, so it had nothing to do with the CPU speed. Also, IIRC,
there was no filtering or anything; just plain "nearest pixel"
scaling and rotation, which means all it takes on the hardware level
is some extra addressing logic.

and that nowadays, with our super fast hardwares we have to use
OpenGL or Direct3D to hope having something equal. (exemple: smooth
scrolling, David Olofson knows a lot about it ;))

Actually, smooth scrolling is a hard problem, regardless of hardware
and OS. The only “simple” way to do it is to scroll N pixels per
refresh, and that only works with fixed scrolling speeds on platforms
that allow you to reliably control the display refresh rate. It
breaks down as soon as you want varying scrolling speeds, very low
scrolling speeds, multiple resolution choises or support for multiple
refresh rates.

The “proper” way is to use sub-pixel accurate rendering - but that
isn’t much of an issue either, unless you’re on ancient hardware.
Retrace sync being disabled by default in most drivers seems to be a
bigger problem…

At least, something equal at higher resolutions like 640x480,
800x600.

Resolution is practically irrelevant as soon as you get 3D
acceleration working - and that shouldn’t be much of an issue, as
long as you use Direct3D by default on Windows.

(Well, 2560x1600 does tend to bring a normal video card to it’s
knees - but in a system with a display like that, one can usually
expect to find one or two pretty serious video cards. :wink:

I’m aware that a PC/Mac runs more than one process at once, but if
you use “top” you see that most of them use very few of the system
ressources, beeing “dormant”.

That isn’t much of an issue normally, as long as the application is
behaving properly - as in, blocking on the vertical retrace every
frame. Burning 100% of the available CPU time will cause problems
on any normal OS, as the scheduler will have to take measures to
avoid freezing the system.

Anyway, from a technical POV, the “more than one process at once” deal
is no issue whatsoever. On proper PC hardware, the worst case
scheduling latency is in the order of 5 microseconds, despite
inefficient IRQ handling and the massive impact of cache misses.
Anything more than that is either hardware acting up (BIOS super-NMIs
or drivers abusing PCI blocking) or OS scheduling issues.

So what is the reason ?

Aren’t our favorite operating systems too complex to handle this ?

Not really… They’re just not designed for it - though modern Linux
systems and OS X are doing quite well, when configured properly. Not
so sure about Windows on a uniprocessor system, but a few extra CPUs
or cores tend to eliminate “hickups” in games pretty effectively -
and this worked pretty well even back in the NT4 days.

Why not provide an operating system dedicated to gaming ?

Xbox, PlayStation, Wii…?

I don’t think a dedicated game OS, as a software-only solution, is
viable, as it’d have to deal with more or less broken hardware, like
any other OS. Poor 3D acceleration, stupid retrace sync
implementations, power management super-NMIs etc… Most of it can be
dealt with, but it requires careful configuration.

More importantly, people have to install and configure this OS, and in
most cases, they’ll have to reboot just to play some games.
(Otherwise, we’re looking at a general purpose OS, so we might as
well suggest that everyone switches to some “multimedia tuned” Linux
distro.)

I’m using Windows as a dedicated gaming OS (as that’s where the games
are…), and even though it doesn’t take many seconds to reboot, it’s
awkward enough that I don’t do it unless I plan on playing for a good
while. To me, anything else would be equally annoying, as long as it
isn’t the 64 bit Gentoo Linux system I’m using for everything else.

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Saturday 26 July 2008, julien CLEMENT wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(message at the bottom)
julien CLEMENT schrieb:
| Hi, this topic follows the previous one “Tilting or rotating an image”.
|
| I’m still wondering why old hardwares like the Super Nintendo
| Entertainement System
| was able to do fast 2D blits, transformations (Mode 7) and all, with a
| slow processor (max: 3.58Mhz, you read correctly) and very limited
| graphical chipset (128Ko VRAM), and that nowadays, with our super fast
| hardwares we have to use OpenGL or Direct3D to hope having something
| equal. (exemple: smooth scrolling, David Olofson knows a lot about it ;))
| At least, something equal at higher resolutions like 640x480, 800x600.
|
| I’m aware that a PC/Mac runs more than one process at once, but if you
| use “top”
| you see that most of them use very few of the system ressources, beeing
| “dormant”.
|
| So what is the reason ? Aren’t our favorite operating systems too
| complex to handle this ?
| Why not provide an operating system dedicated to gaming ?
|
| Cheers
| Julien
|
| ----- Message d’origine ----
| De : Armond Sarkisian <armond.sarkisian at gmail.com>
| ? : sdl at libsdl.org
| Envoy? le : Vendredi, 25 Juillet 2008, 18h12mn 52s
| Objet : [SDL] Tilting or rotating an image
|
| Say you load an image such as a jpg file. How would one go about
| rotating the
| image left or right? Thanks for any info provided.
|
| _______________________________________________
| SDL mailing list
| SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
| http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Envoy? avec Yahoo! Mail

http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52423/*http://fr.docs.yahoo.com/mail/overview/index.html.
| Une boite mail plus intelligente.
|

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

i would say this is because those consoles were specifically made for
playing games and thus manipulating images. The image manipulation was
done by a PPU which probably had a commandset specialised for image
drawing and manipulation thus it could do these things faster than a
normal CPU.

The only thing that is like those PPUs are graphic cards. And most of
those don’t have 2D acceleration any more - though with the right camera
setting it still will look like 2D and still can use (3D) acceleration.

I may be mistaken though, so correct me if i am wrong.

Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIiv6+uP385A9AI2QRAjhlAJ4wW0D5xfqkDRL+IBKK2ITKSqJHaACeIsFX
FwRdLEkZ96wxejDoMwxV41k=
=XP7C
-----END PGP SIGNATURE-----

From Sat, 26 Jul 2008 09:49:35 +0000 (GMT)
julien CLEMENT wrote:

I’m still wondering why old hardwares like the Super Nintendo
Entertainement System was able to do fast 2D blits, transformations
(Mode 7) and all, with a slow processor (max: 3.58Mhz, you read
correctly) and very limited graphical chipset (128Ko VRAM), and that
nowadays, with our super fast hardwares we have to use OpenGL or
Direct3D to hope having something equal. (exemple: smooth scrolling,
David Olofson knows a lot about it ;)) At least, something equal at
higher resolutions like 640x480, 800x600.
Game consoles often used a limited resolution (256x192 or something like
that), then for platform-scrolling games they often use a special mode
with 8x8 patterns, when the CPU needs to update just
(256/8)*(192/8)=768 bytes for a full frame update. Game consoles with
support for 256-color modes (3.5MHz Z80 CPU) mostly weren’t using
scrolling, just sprites over a static background.

There was also support for full-screen hardware scrolling by changing
the address of the beginning of the video RAM. By the way, PCs have
this feature too, but it’s seldom used (some DOS-based pinball games
come into mind - latest I’ve seen to use this technique). Then on PCs
you have at least 64k colors, most often 16M colors (when you’ve seen a
256-color game on PC last time?). For a 640x480 screen at 64k colors
this is already 600k VRAM to update at every frame (compare to 768
bytes above). Not speaking when you have 1024x768x16M, this is already
3Mb VRAM. See how it adds very quickly :slight_smile: That’s about 122.892.288
times more than the usual game console mode.

Then, often game consoles had a video accelerator chip too. It could do
some simple operations, but sometimes even relatively complex (such as
the 2D blits you’re referring above).–
Andrew
-------------- next part --------------
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20080726/235c81d6/attachment.pgp

[…]

The only thing that is like those PPUs are graphic cards. And most
of those don’t have 2D acceleration any more - though with the right
camera setting it still will look like 2D and still can use (3D)
acceleration.

Basically any PC video card still in use does have the features that
the SNES and others had - it just does the job much better and much
faster than any of those consoles ever did. :slight_smile:

The problem is that the traditional 2D APIs of Windows, X11 etc aren’t
wired to the drivers used for OpenGL or Direct3D, so using those APIs
means you’re basically using legacy fallback code instead of proper
implementations.

Desktop environments are switching to rendering over 3D APIs as we
speak (or already did, years ago, on Mac OS), which is really the
only sensible way to go. Maintaining various incompatible APIs with
their own respective driver architectures is just a waste of
resources, and makes it hard for applications to share resources.
Most of those APIs are just small subsets of a full blown 3D API, and
can be implemented over the latter - and those that aren’t (goes for
some parts of the SDL 2D API, for example) aren’t suitable for
hardware acceleration anyway.

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Saturday 26 July 2008, Karsten Bock wrote:

[…]

There was also support for full-screen hardware scrolling by
changing the address of the beginning of the video RAM. By the way,
PCs have this feature too, but it’s seldom used (some DOS-based
pinball games come into mind - latest I’ve seen to use this
technique).

Actually, it is still supported by most drivers, but it’s normally
used only when you have desktop that’s larger than your physical
display. I believe you could actually make use of that on X11, but
I’m not sure if it’s a “public” feature on Windows. Either way, there
seems to be drivers and/or hardware that don’t support it at all, so
one shouldn’t rely on it…

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Saturday 26 July 2008, Andrew Zabolotny wrote:

And let’s not forget that even simple scrolling games like Gradius III experienced severe, game-breaking slowdown.

Jonny D> From: david at olofson.net

To: sdl at lists.libsdl.org
Date: Sat, 26 Jul 2008 13:30:47 +0200
Subject: Re: [SDL] Why is 2D so slow ?

On Saturday 26 July 2008, Karsten Bock wrote:
[…]

The only thing that is like those PPUs are graphic cards. And most
of those don’t have 2D acceleration any more - though with the right
camera setting it still will look like 2D and still can use (3D)
acceleration.

Basically any PC video card still in use does have the features that
the SNES and others had - it just does the job much better and much
faster than any of those consoles ever did. :slight_smile:

The problem is that the traditional 2D APIs of Windows, X11 etc aren’t
wired to the drivers used for OpenGL or Direct3D, so using those APIs
means you’re basically using legacy fallback code instead of proper
implementations.

Desktop environments are switching to rendering over 3D APIs as we
speak (or already did, years ago, on Mac OS), which is really the
only sensible way to go. Maintaining various incompatible APIs with
their own respective driver architectures is just a waste of
resources, and makes it hard for applications to share resources.
Most of those APIs are just small subsets of a full blown 3D API, and
can be implemented over the latter - and those that aren’t (goes for
some parts of the SDL 2D API, for example) aren’t suitable for
hardware acceleration anyway.

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Let’s also not forget that the vast majority of “ye olde gaming cosoles” were dealing with very small screen resolutions (320x200, maybe!), and that the main characters and things getting rotated were size equivalent(or smaller!) with a 32x32 icon. Also, the bit depth was quite low, 8-bit or 16-bit, with no alpha-blending/anti-aliased edges at all which makes a huge difference in speed. Combine that with the fact that it’s all done in hardware, and that there are no other things going on in the background, and no wonder they could get decent smooth framerates. And no wonder people complain about slow 2D when they try making a 1280x800, 32 bit antialiased/alpha-blended side scroller with real-time filtered rotation and scaling effects with huge sprites.> ----- Original Message -----

From: Jonathan Dearborn
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Saturday, July 26, 2008 9:16 AM
Subject: Re: [SDL] Why is 2D so slow ?

And let’s not forget that even simple scrolling games like Gradius III experienced severe, game-breaking slowdown.

Jonny D


From: david at olofson.net
To: sdl at lists.libsdl.org
Date: Sat, 26 Jul 2008 13:30:47 +0200
Subject: Re: [SDL] Why is 2D so slow ?

On Saturday 26 July 2008, Karsten Bock wrote:
[…]

The only thing that is like those PPUs are graphic cards. And most
of those don’t have 2D acceleration any more - though with the right
camera setting it still will look like 2D and still can use (3D)
acceleration.

Basically any PC video card still in use does have the features that
the SNES and others had - it just does the job much better and much
faster than any of those consoles ever did. :slight_smile:

The problem is that the traditional 2D APIs of Windows, X11 etc aren’t
wired to the drivers used for OpenGL or Direct3D, so using those APIs
means you’re basically using legacy fallback code instead of proper
implementations.

Desktop environments are switching to rendering over 3D APIs as we
speak (or already did, years ago, on Mac OS), which is really the
only sensible way to go. Maintaining various incompatible APIs with
their own respective driver architectures is just a waste of
resources, and makes it hard for applications to share resources.
Most of those APIs are just small subsets of a full blown 3D API, and
can be implemented over the latter - and those that aren’t (goes for
some parts of the SDL 2D API, for example) aren’t suitable for
hardware acceleration anyway.

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

And let’s not forget that even simple scrolling games like Gradius
III experienced severe, game-breaking slowdown.

Jonny D

This is the other important thing to keep in mind about the older game
consoles. They were basically rated at what all they could do. If
you look at GBA or NDS homebrew websites you can find documentation
that kind of explains how older consoles work, because these devices
(especially the GBA) are still rather similar in design to their
predecessors. Basically, you set some variable at a pre-designated
memory address to tell the console which graphical “mode” to run in,
and that determined things like resolution, number of colors, number
of tile layers, number of tiles to choose from when creating maps, and
features available for a given layer. These specifications also
included things like the maximum number of sprites that could be drawn
on-screen and still render at full speed (I think full speed was
considered 60 FPS in the US). There was no inter-frame processing or
checks on time between frames.

So you saved a lot of time not worrying about how long since your last
refresh, for one. As has already been stated, the SNES most famously,
many older consoles had extra graphics processors for things like
hardware-based rotations. Mostly, the thing you see is that
developers knew their system and its limitations and they worked very
hard to make something that looked good but remained within the
processing limitations at all times to get the best posible graphics
with no slowdown.

I highly encourage you to investigate GB/GBA homebrew to get a better
idea of the kinds of hardware limitations that were imposed back then
if you’re still interested. It’s really kind of fun to read about.

Anyway, the point is that now, you have to use the CPU to do things,
and that involves telling it, in code, how, whereas on consoles you
just fed it a command and it shipped it off to a chip that already
KNEW how, and it got done, rather than added to the process stack.
Also, now, you can do a whole lot of whatever you want, you can have
hexagonal tiles, or round tiles, or whatever, because you just have a
set of drawing commands. You don’t even NEED tiles anymore. And ALL
of your drawing routines generally get the same number of colors as
all of the other ones. So with that freedom comes a lot of overhead
that was removed by restricting what you could do on older consoles.

In that way, it’s almost like what we’re seeing now with programmatic
shaders on video cards. Whereas before you set a few variables and
the shader pipeline did its thing, visual demands have gotten high
enough and cards fast enough that they’re opening up even THOSE
restrictions, to produce potentially better looking (though not
necessarily), yet comparatively slower, graphical effects.

Sorry if I rambled. Got excited by seeing a question I knew how to
answer for once! :slight_smile:

– ScottOn Jul 27, 2008, at 12:16 AM, Jonathan Dearborn wrote:

Since most people covered the console side of dedicated hardware and
the fact that it’s brute force on the PC and such…

PC’s do have dedicated graphical processing things, they just tend to
be 3D. Amiga had alot of love, but that’s off topic.

Most of the 2D acceleration is basic blitting with a raster op (vram
to vram), a hardware cursor (mouse pointer like thing), simple
bresenham line drawing (where you still have to do some of the math to
get values to plug in), dac start offset (page flipping, or depending
on hardware, vertical scrolling), and different pattern/flood fills.
Some things might have alpha blending or some kind of overlay color
space conversion (yuv etc) as well.

Scaling ? No.
Rotating ? No.

Standards ? No. With Vesa2/Vesa3, the VESA group wanted to charge an
arm and a leg for their spec for hardware manufacturers to be able to
implement things. As such, it spelled the end for a low level
standard API. And, with things moving to Windows, there wasn’t seen
much of a need for a lower level API – you’d just talk to the windows
driver. Annnnnddd the Win16/32 GDI is more or less just lines, rop
blits, and such… nothing terribly interesting.

So, the PC typically just use it’s plain ole blits and for rotating
and similar it’d just pre-render (either via artist or on startup)
rotated sprites and index them.

Today’s lowest common denominator for 2d graphics is a LFB and
hardware cursor. The rest is up to you.

… so if you want some faster 2d, use OpenGL and set it up to do a
2d-style game. You’ll get lots of free bonuses… subpixel
manipulation, free hardware rotation, free parallax scrolling
occlusion, blendy goodness, etc etc etc etc. The only malfunction
might be the previous thread concerning OpenGL being broken on some
hardware/os things (which I have never hit, fwiw).

-Will

Hey,

Is there a way to make the surface that is returned by SDL_CreateRGBSurface>From actually latch onto the pixel data so that it is freed when I call SDL_FreeSurface (without a workaround)? Is this one of those “private fields not shown here”? If it is, can I reasonably expect it to work for all future (future?) SDL 1.2 versions?

Jonny D

Hey, Is there a way to make the surface that is returned by
SDL_CreateRGBSurface>From actually latch onto the pixel data so that it is
freed when I call SDL_FreeSurface (without a workaround)? Is this one of
those “private fields not shown here”? If it is, can I reasonably expect it
to work for all future (future?) SDL 1.2 versions? Jonny D

On Windows, that would be quite wacky, due to the way they seem to
like to amass large collections of memory allocators (short story: the
DLL/EXE who does the free should be the one that did the malloc).

It’s kind of wasteful, but just do a copy then free the original? Or
you could set up your code to create the surface first, then use its
pixel data…On Mon, Jul 28, 2008 at 6:48 AM, Jonathan Dearborn wrote:


http://pphaneuf.livejournal.com/

PC’s do have dedicated graphical processing things, they just tend to
be 3D.

Except when they don’t. My undead of a game project, Quadra (it just
won’t die, people keep downloading it, playing it, and filing bugs!),
tends to be still popular on computers that do not have 3D hardware at
all. Think five year old computers that someone still fiercely
addicted to Tetris would still have. :slight_smile:

If your game is going to require a minimum amount of CPU, you could
start assuming that since you need a recent enough computer, there is
a better chance of there being 3D hardware. I personally applaud the
Intel chipsets for that: while they are not nearly capable enough for
proper 3D games, they do plenty well for the “2D using 3D” type of
games, letting me forget about such horrors as DirectDraw and DGA2.

Most of the 2D acceleration is basic blitting with a raster op (vram
to vram), a hardware cursor (mouse pointer like thing), simple
bresenham line drawing (where you still have to do some of the math to
get values to plug in), dac start offset (page flipping, or depending
on hardware, vertical scrolling), and different pattern/flood fills.
Some things might have alpha blending or some kind of overlay color
space conversion (yuv etc) as well.

Note that for some of these operations, you need exclusive control of
the video card, which at the very minimum means not being windowed,
and in the worst case means not possible (X11 had DGA, but eww! and
many drivers didn’t get it right, since it wasn’t used much).

Basically, what’s accelerated is stuff that is used in GUI
applications. Which usually means fills (solid color desktop
background), solid blits (scrolling), colorkeyed blits (for icons),
and colour conversions (for video playback). If you’re lucky, you get
alpha blending (for shadows). Since you rarely see windows rotate or
scale (except on a Mac, maybe? hehe!), you don’t get that.

Standards ? No. With Vesa2/Vesa3, the VESA group wanted to charge an
arm and a leg for their spec for hardware manufacturers to be able to
implement things. As such, it spelled the end for a low level
standard API. And, with things moving to Windows, there wasn’t seen
much of a need for a lower level API – you’d just talk to the windows
driver. Annnnnddd the Win16/32 GDI is more or less just lines, rop
blits, and such… nothing terribly interesting.

People should remember that back in the DOS days, each game contained
the drivers for the hardware. If you wanted to use an accelerated blit
(say), which wasn’t in the VGA standard, you had to find out how to
make it work on every card and code a big “switch” statement (or
something) in your game to do that. If you didn’t support my S3 968v2,
then your game DID NOT WORK AT ALL on my computer (or fall back to
software, yet more headaches)! Of course, game developers didn’t use
those non-VGA features very much, because they didn’t have the
man-power to support all these video cards.

Microsoft, though, had either the man-power to do it, or had the
leverage to ask the video card manufacturers to write a chunk of code
for them. In addition, GUI is the kind of thing where a software
fallback is usually tolerable, so it would at least work to a nominal
level, until you could figure out what was wrong.

XFree86 (and now Xorg) is basically the same kind of situation.

Today’s lowest common denominator for 2d graphics is a LFB and
hardware cursor. The rest is up to you.

And what they call a hardware cursor is probably not what you have in
mind (as in, “way crappier”). :wink:

… so if you want some faster 2d, use OpenGL and set it up to do a
2d-style game. You’ll get lots of free bonuses… subpixel
manipulation, free hardware rotation, free parallax scrolling
occlusion, blendy goodness, etc etc etc etc. The only malfunction
might be the previous thread concerning OpenGL being broken on some
hardware/os things (which I have never hit, fwiw).

The other hangup is those people stuck with non-3D hardware, but
they’re becoming quite the rare breed.

An interesting tidbit of history is that DirectDraw used to give you
access to the 2D accelerated hardware in a way that is actually useful
to games, but at some point, it become enough of a hassle that
Microsoft got rid of it, and replaced it with a Direct3D backend
(essentially doing what you described), which works wonderfully,
except if you don’t have actual 3D hardware. If you’re in that
situation, then your game that used to be 80-100 fps is now 2 fps, or
something equally craptacular. The irony is that in the meantime, the
CPU and memory became faster, so using the GDI and doing everything in
software could give you something like 40-50 fps, say (made up
numbers, the important is “probably a chunk slower than 2D
accelerated, but fast enough to be useful”, as opposed to “unusably
slow”, which is what you get with 3D without the hardware).

So on some older computers, the DirectDraw backend of SDL can be
faster than the GDI backend is on a faster computer, but on that
faster computer, the DirectDraw backend would be very slow. If you’re
especially unlucky, your user has an old enough computer that he
doesn’t have 3D hardware, but a new enough machine that he has WinXP
with the recent enough DirectX that doesn’t have the "real"
DirectDraw, in which case there is simply no way to get at the 2D
acceleration (or an equivalent performance faking it with 3D
hardware). Argh.

Again, you just can’t rely on anything.On Sat, Jul 26, 2008 at 11:40 AM, Will Langford wrote:


http://pphaneuf.livejournal.com/