Slashdot Mirror
Ask Sam Lantinga About SDL On PS2 And More
Sam Lantinga is the author and project lead of the Simple DirectMedia Layer (SDL), which was recently ported amid general acclaim to the Sony PS2. People have been curious about SDL for a long time (it's been around for a while, and used in quite a few games). He's not just a library programmer though; he also designs games (in this case, working with Lauren MacDonell) and thinks hard and lucidly about the intricacies of information display within them. Here's your chance to ask Sam directly what's on your mind about SDL, game design and more. Note -- many questions are answered within the links already given, so hit those first. One question per post, please (but as many posts as you'd like) -- we'll forward the highest-rated questions on to Sam, and post his answers soon after.
the gpl is referred to as "viral" because anything that is derived from a gpl'd product must be gpl'd. it spreads. like a virus. hence the term "viral".
Every once in a while I like to masturbate a new word into my vocabulary, even if I don't know what it means.
To what extent do the games compiled with SDL for PS2 are slower than the analogous native versions? If a programmer uses a special programming style, does that improve the performance?
Also, does the overhead of SDL grow since there are so many platforms/tricks to be supported (i.e. if a feature of PC hardware leads to a certain architectural solution, the same feature does not necessarily exist or is relevant to the PS2 architecture).
If you get the Linux distribution from Sony, you must have a hard drive. Or rather in their Linux PS2 package that you purchase (only in Japan), you get a hard drive, PS2 Linux CD, a brief manual, and I believe a network ethernet adapter. I would imagine that since you do have a network adapater of some sort you could just send/receive the games over a network of sorts and then just save it to the hard drive. While this is a perfectly valid question for the PS2 Linux distribution, I don't think it should be asked of someone who "just" writes a library.
That's mostly hardware.
1024x768 at, say, 32bpp is 3.1MB. About 50MB per second if you get 16fps. This really doesn't sound like alot, until you consider that you're blitting to the buffer as well -and- you sit around waiting on the bus to 'flip' the buffer; and the bus is an awful lot slower than direct memory access.
You can get around this by using a hardware buffer and hardware surfaces, but you're stuck with using just images and usually color key that way; no primitives for the time being, and alpha blend isn't always supported in hardware.
As far as full screen page flipping goes, you need to use a hardware surface. You won't always get one; check the flags on the surface that is returned. May also need SDL_DOUBLEBUF, it's been awhile since I messed with that.
- aoiushi, #sdl
I've worked on all four platforms you've mentioned here, and as far as I can see the main difference is that of programmability.
On a PS2 you have the ultimate level of control, of course at the expense of ease of programming. If you're not using any middleware then you have to write your own clipping code, and decide where you want the clipping to take place. Generally you want the clipping to happen after you've done your transforms on VU1, and the two approaches I've seen have been to do the clipping on VU1 or (the approach I favour) to have the main CPU assist VU1 in the clipping.
Although having to write your own clipping is a pain, it does allow you to generate new vertices late on in the pipeline. This means you can do things like procedural geometry (eg trees, bezier patches) without taking a CPU hit.
OpenGL allows you to write portable code at the expense of taking advantage of specific options your hardware might have. Having the extensions though allows you to target specific hardware options quite easily. For example, if you want to use pixel shaders then you use the NVidea extensions that expose this, but you'll still need to write a different renderer to support devices that don't have these extensions.
Direct3D attempts to encapsulate all these extensions as part of its API. So you still end up writing a different renderer if the driver doesn't support the CAPS you need, but you should only need to write one version of say your vertex shader that'll run on any hardware that supports these. It also gives the software emulation of vertex shaders which is nice. Vertex shaders are less flexible than VU1 programming on the PS2, but in most cases they're nice to use.
The XBox gives you lower-level access to the hardware than you get with DirectX giving you even more flexibility.
In short, the pipeline doesn't differ all that much between the different things you're using. OpenGL and Direct3D are better suited to different things (ie workstation style graphics and game graphics), while the PS2 and Xbox are definitely geared up for rendering game graphics!
Where it really gets different is with texture management. On the PS2 this is a total nightmare -- lots of hard work just to get yourself with a decent amount of textures per frame. On the Xbox this is pretty much all done for you, and on top of that you get texture compression.
Sorry for posting anonymously...I'm sure some will understand why!
SDL is for PS2 Linux.
PS2 Linux has a version of Mesa (OpenGL clone)
that ships with it.
Unfortunately texture mapping isn't optimized with that release so the performance isn't
what it could be.
But if you're using OpenGL you're missing all the strengths of the PS2. I'd only use SDL for a frame buffer application or some port of an emulator or something.
If you're going to code anything brand new just go straight to low-level. Otherwise you'll be wasting most of the machines power.
Rats would be more funny if they could fart.
correct me if I'm wrong
Okay.
The TOOL system is a plain ol' PS2 with a minor modification... it can run uncertified games (used for testing). The DevKit is a whole different kettle of sheep dung.
As to CodeWarrior, where the hell did you get that idea? CW is just one of several compilers that can come up with PS2 binaries. The PS2 Devkit itself comes with a version of gcc, and Codeplay (the company I work for) is about to release vectorC {PS2}.
And a note to anyone thinking having a PS2 version of SDL will allow you to write PS2 titles, guess again. A PS2 will only run certified software (unless you have the aforementioned TEST kit), so being able to compile for the box is only half of the problem. You also need to fork out cold-hard-cash for the certification.
Of course, PS2 Linux will let you run your own titles, but only other people with PS2 LInux will be able to use it.
"Faith is the last resort of a desperate man" - Me
This includes how he dealt with using the native Mac resources, X video issues, timing and network synchronisation. All are entertaining and highly informative and answer your questions :)
--- Hot Shot City is particularly good.
- Andreas
GLtron: cross-platform gaming on Linux, Win32, MacOS, MacOS X. Soon with networking
SDL is not limited to XFree86. It also targets SVGAlib amongst other things (such as aalib - thats trippy)