I’m curious - is anyone currently working on making it faster?
Perhaps the same kind of benefit SDL will see on accelerated video cards
from the SDLgl[*] project could be done on the PS2…
The speed limitations that they are talking about in the article are twofold.
First, SDL supports OpenGL through Mesa, and the only full OpenGL
implementation that ships with the Linux Kit is Mesa, which is software-only
on the PS2. This means that any true OpenGL apps will be very slow.
There is a “ps2gl” library (sp?) that provides an API similar to OpenGL,
but the API is different from standard OpenGL, and you will have to modify
your program to use it.
I don’t happen to have the PS2 Linux kit currently, it should be
purchasable now, but financial priorities have put enhancing the game
console to be hackable low on the list. =/
How far is the ps2gl lib from OpenGL? If it provides the same basic
functions with a similar API (discrete polygons, poly strips, vertex
arrays, other things) it should be fairly trivial to port things to it or
put together a MiniGL wrapper. It’s long-established that I hate MiniGLs,
but this is primarily because they tend to implement exactly what is
needed for a single game. That doesn’t have to happen here.
More modern games seem to be using less OpenGL rather than more. We’ve
given up on things like OpenGL fog because of how many people have it
broken in hardware/drivers. Even my own baby Project Twilight uses around
fifty OpenGL functions (there are some 600 of them available) and we’re
working to reduce that number as we further abstract the rendering core
into a simple box which … draws stuff, regardless of what stuff that
happens to be. =) As this continues, PS2 ports of these games become
increasingly more simple. Hell, we could do a DX8 port and nobody would
be able to tell the difference in Win32, except that the DX8 port could
not be quite as fast (higher overhead…)
Second, there are two basic styles of 2D video output. One consists of
rendering the entire screen in a software back buffer and then displaying
the screen all at once, and the other consists of saving a bunch of textures
in video memory and then telling the video hardware where to put them on the
screen. As with any other modern graphics hardware, the PS2 is relatively
slow at the first style, and relatively fast at the second style. However
SDL only provides a single back buffer and uses optimized DMA calls to send
the changed portions of the screen to the graphics hardware. For the record,
this is still pretty fast, probably equivalent to a P300 and the graphics
hardware of the time, but as mentioned in the article, you’ll get the best
performance by designing your game for the style of graphics access that the
PS2 does best, and then writing directly to the hardware.
The world is moving to the second type, if you ask Microsoft. The DX8 API
lacks support for that legacy 2D stuff. 
The stated reason is that we
are now at a point where just about everybody has 3D hardware and it’s
actually easier/faster to draw even 2D using the hardware designed for 3D.
Which is a nice prospect really. Suddenly things like vertical retrace,
scaling surfaces various expensive effects, etc, are very easy and very
cheap. Unfortunately other previously somewhat cheap effects (the wavy
screen effect in Heroes, for example) are almost prohibitively expensive
all of a sudden. But it lowers the barrier to entry all the same by
making the graphics setup code no longer a black art. And effects which
act on the framebuffer are getting cheaper again with the latest set of
OpenGL extensions from the likes of NVIDIA, I assume DX9 will probably
feature more of these things as well.
The limiting factor here is that not everyone does have 3D hardware,
naturally. Oh sure everyone Microsoft cares about selling games to has
one these days, but that’s hardly everyone and certainly doesn’t reflect
the state of the world outside of Redmond.
Another thing to consider is that with some minor issues (and one not so
minor one that comes to mind), a strictly 2D API designed for rendering to
3D hardware would not have much trouble rendering to 2D hardware either.
The big issues are alpha and scaling. We should know what sorts of alpha
are likely to be accellerated or at least what’s likely to be fastest,
which takes away one issue. Texture managment isn’t trivial, but isn’t
real difficult either; this won’t be a problem. The one that is a real
problem is texture scaling.
Just about all of the 2D implementations on 3D hardware make an assumption
that drawing textures at literally any size you want is cheap. Of course
without hardware scaling, it’s anything but. Lerping an image up or down
by a power of two is not difficult but not instant. Nearest pixel scaling
isn’t real difficult either, but still too slow for realtime. But you
can’t ignore the problem either. Maybe a query to find out whether or not
we can scale at draw time or not and an exported function to do it
ourselves at load time if we need to? As an OpenGL programmer myself, I
think nearest and linear interpolation would be absolutely useful to have
in SDL (hey, gotta mipmap!), especially if the power-of-two case was
optimized well.
The next generation SDL API will have a much better architecture for the
second style of graphics access, and will support acceleration on the
PS2. The real problem with this, and one of the things holding up the
design, is what to do with games that use some graphics options that are
accelerated by the underlying OS drivers, and some that are not. A
really good example of this is color fill and colorkey blitting, two
common 2D graphics operations:
I for one am really looking forward to this. =)
Case 1. X11, hardware color fill is supported, colorkey blit is not.
The best solution here is use a shared memory image between
client and server and perform softare RLE accelerated blits.
Case 2. Matrox Millenium framebuffer console, both hardware color fill
and colorkey blits are supported.
The best solution here is to put as many textures as possible
in video ram and use a caching scheme to minimize vram access,
and use hardware acceleration for all options.
Case 3: DirectX 8 on NVidia hardware
The best solution here is to convert all textures to RGBA and
fill the alpha channel with the color key information and use
textured quads to place 2D graphics.
So, this isn’t so bad, it could be done well. The trick is that the
library needs to know up front that the application is going to be using
this kind of graphics access, so it can be set up in the most optimal way.
For example, an application that does lots of dynamic pixel updating would
use very different graphics access setup in cases 2 and 3, and the library
would need to know up front to set this up correctly.
As noted above, the generalisation of the third case is probably the
safest bet all around for the interface given to the program. Use
whatever alpha method works best for the situation, color depth,
acceleration, etc. Then we just give SDL our textures and tell it where
to put them. As noted, the scaling case is what worries me about this,
but I don’t pretend I have a solution to the problem, certainly not one I
consider good.
It’s nice to say the other details are up to SDL, but it’s not so nice
when you’ve gotta make those details just work inside of SDL. Still, the
interface decisions will make that a little easier.
This is still doable, just have the application tell you, “hey, this is
the kind of graphics access I will be doing”. Lots of work to handle
everything correctly, but possible.
What gets really hairy is when an application does a mix of say color
fill, colorkey blitting, alpha blending and direct pixel manipulation.
The optimal setup depends on the frequency of different graphics access,
and the speed of each operation for each combination of underlying graphics
hardware and graphics access configuration. How do you choose, and how do
you fully test the possible combinations?
I pity anyone trying to do 2D without SDL_DisplayFormat. You should not
be messing with textures you’ve given to SDL once you’ve given them over,
it could be … very slow. Those textures could be stored in video RAM,
after all. I suppose if you care you can check this, make a software
surface, screw with the raw bits on that, and then stuff the results out
to video memory when you’re done, and that’d work well enough. Again as
an OpenGL programmer who already has to deal with this sort of situation,
I caution game developers: You care. If you don’t care, you will when you
see your framerate.
Messing with individual pixels is somewhat of a special case though.
To make things more complicated is that the correct optimization setup
varies depending on whether you are in fullscreen or windowed mode on
most platforms.
One possible solution is for the application to enumerate all available
video drivers and graphics access configurations, and run a test that
closely mimics the applications graphics access pattern, and choose the
best combination for that hardware and driver combination. I dread the
hardware/configuration specific bugs that would arise from this method.
I don’t think this is tenable. The database of best configurations for a
given set of circumstances is almost guaranteed to grow exponentially, if
not at least linearly. There really are only a few options to mix, and in
nearly all cases it’s not hard to find out what’s available/fast from what
we know about where we’re running. The rest is just a matter of programs
telling SDL what they want in some cases and querying SDL to find out if
other things they would like are available.
I really think handling alpha channels are probably the least of your
worries. Although, somehow I suspect saying that isn’t helping even a
little bit…
Another possible solution is to punt and say that only a particular type
of graphics access will be supported. DirectX 8 went this route, saying
that all cards will support 3D geometry, and that is the only way to get
something onto the screen. However, this translates really badly for many
of the platforms that SDL supports, like older UNIX and embedded systems.
Indeed, that’s a bad thing.
I have a third possible solution that might work:
You could query for operations that could be hardware accelerated, and you
could specify the operations that you want to use, and then SDL would set
up the graphics configuration to the optimal state. You might then set up
either a back buffer in software, or an inaccessible framebuffer that you
would upload textures to, and perform operations on those textures to get
them to the screen. You would then trigger an “update”, flushing all the
operations to the screen (either by copying from the back buffer to the
video card, or by triggering the graphics operations in the video hardware),
and you could request that this be done synchronized with vertical retrace.
The trick there is, as I suggest, figuring out what to query and SDL
should be able to provide always. Alpha is one of the things SDL can’t
always provide, at least not in a consistant manner if you want it fast.
You also can’t guarantee scaling will be fast. I don’t think you’ll have
much problem with other stuff though, like figuring out where textures go
after the program hands them to SDL, what to do if you have more textures
than video RAM (how the hell this happens with 2D graphics I can’t fathom,
but it’s possible for sure), and how best to get things put onto the
screen.
Actually, the above problem about direct pixel manipulation… You might
want to invent the concept of a shadow surface. If the thing you want to
modify is in video RAM, it’s modifyable but slowly. If the thing is in
OpenGL, it’s gonna be very slow to modify for sure. That’s where a shadow
surface comes into play. If a texture is slow to modify, and the program
wants to do it, offer to keep a copy of the texture in normal RAM for
tweaking purposes. The program tweaks it, tells SDL where it did so, and
SDL can then blit the changed portion back to video RAM or glTexSubImage2D
or whatever…
So… comments are welcome. 
Good, I always have those. No guarantee they’re coherent or helpful, but
the comments themselves I have!
One more OpenGL comment: The nice thing about working with 2D in OpenGL is
that you never really need to worry about mipmapping anything. That
sounds like an insignificant detail, until you want to update textures as
described above. glTexSubImage2D is nice and fast for what it does, but
it doesn’t automatically update mipmaps. But handling 3D rendering is far
beyond SDL’s realm anyway - SDL couldn’t keep up with the ever-evolving
techniques and technologies even if Sam wanted to try.On Fri, May 24, 2002 at 02:37:34AM -0700, Sam Lantinga wrote:
–
Joseph Carter The guy with a rocket launcher
“… you will more than likely see all kinds of compiler
warnings scrolling by on the screen. These are normal and can
be safely ignored.”
Knghtbrd: is that a note attached to some M$ code?
No, it’s a note about a bunch of GNU stuff.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020524/86b6c214/attachment.pgp