Slashdot Mirror

Out-of-the-box Linux 3D support?
by phutureboy

This may be more of a question for everyone else than for Sam (but Sam can feel free to answer also :) I'm not a big gamer, but I would play some if it weren't such a bitch to get the proper libraries working under Linux. Last time I tried was about 6 months ago... After following some really complicated directions and compiling umpteen obscure drivers I finally got SDL and hardware-accelerated OpenGL working. I had to disable it and revert to my previous versions, though, because it locked up my system a lot during games and made X pretty unstable. Anyway, my question is this: is multimedia support for Linux getting any easier to install? Is it possible that someday I will be able to install a distribution and have it automagically configure hardware 3D support, install SDL, etc.? Or is Linux multimedia still too much in the toddler stages?

I'm just a lowly PHP coder. I don't understand all this low-level mumbo jumbo. I just want to fire up a game every now and then and blow shit up. Is there hope for me?

Sam Lantinga: Yes, more and more distributions are starting to set up 3D out of the box. 3D on Linux is always a moving target however, so the best bet is for distribution to both include 3D detection and setup, and also to include information on how to upgrade the drivers to the latest versions.

As anecdotal evidence, Mike "Heimdall" Phillips, who up until recently worked as Q/A and technical support at Loki Software, Inc., installed Mandrake 8 on a box containing a Rage 128 video card, and the installation detected and set up 3D acceleration out of the box. He was up and running with most of Loki's 3D titles immediately.

Graphics Hardware Drivers
by m2

My question is a bit tainted by my personal opinion in this matter, but I'm sure Sam will be able to provide a different (and surely interesting) point of view.

At the risk of being a tad Linux centric, does the availability or unavailability of hardware specifications and technical documentation on graphics hardware affect a Linux game developer and why? With two concrete cases in mind, on one hand NVIDIA who provides binary drivers and "high level" documentation about their cards, and on the other hand, ATI for which there's source code for the drivers with support for half of the features the hardware offers, but neither openly accessible hardware documentation nor much "high level" docs, how do you think this can affect the future development of games for Linux (proprietary or otherwise)?

SL: From my perspective as a cross-platform game developer, the objective is to write a great game, not to have to read technical documentation on particular graphics hardware. With the improvement of the OpenGL API implementations on the Linux platform, the need for game developers to get their hands dirty with the technical details of the graphics drivers is slowly going away. IMHO, this is a good thing. :)

Now, in reality there is always a need to look at the way the driver interacts with the hardware, either to fix bugs, or to improve graphics performance. For this reason, it's a great thing to have the source code and full graphics hardware specifications available - it allows the developer to make smarter choices about graphic implementation, and results in a better game. This is true of Linux as well as Windows, and interestingly Linux is a richer field than Windows when trying to find out how hardware and drivers really interact.

In the specific case of NVidia, I've been impressed with both the quality of their drivers, and the responsiveness and commitment of the company towards Linux as a whole. While it's true that there is no guarantee that this will continue, it's very refreshing now.

What's your status with Loki?
by Mr T

Was your departure good? Daniel Vogel also left. Is Loki in a good position or did you leave because of some problem. What's the deal?

SL: My departure was good. I left because I was very interested in the opportunity to work on original game content at Blizzard Entertainment.

Loki owes me money like all the other employees, but they have stated that they will pay me back, and I am very hopeful that they will do so.

Blizzard Entertainment
by j7953

What are you working on at Blizzard? Do you get paid for continuing your work on SDL, or do you have to do that in your spare time?

SL: I am working on an upcoming unannounced title. It's great fun and I can't wait for it to be announced so I can tell people what it is that I'm working on. As for SDL, I'm still working on it in my spare time. There's a rumor of a super-elite crack team of developers working on the next generation SDL API, but I can't substantiate it. :)

Directx 8 and SDL
by drenehtsral

From playing with it, and noticing what has been conveniently removed from the documentation (but is still in the libraries), it looks like DirectX 8 is trying very hard to do away with directdraw and work purely through the 3d engine. Sprites are just 2d textured polys, etc ...

This leads me to believe that any future enhancements/optimizations/support/testing/etc ... that will happen with directx will be only on the direct3d part, and directdraw is probably going to be unsupported. Do y'all have any plans to deal with that?

SL: The next generation SDL API is leaning towards the concept of a texture manager and a plug-in architecture for operations on those textures. This should for the most part be a natural improvement upon the current design, and will lend itself well to 3D hardware acceleration. This design is for the 2D surface API though. At this point, the plan is to continue to support real 3D through the OpenGL API.

SDL and OpenAL (among others)
by Eugenia Loli

So, I was always wondering if there is going to be a 'real' integration between OpenAL and SDL. Currently, a lot of people are just using SDL_mixer which does a pretty good job for little shareware/oss games, but when it comes to commercial sound, 3D positioning and all these buzzwords, SDL needs OpenAL to break through against the goodies of DirectX has to offer.

Also, what about a wrapper against D3D? There is currently a nice integration with OpenGL, when SDL needs to use 3D acceleration, but under Windows (where a lot of SDL games already exist) most of the coders are using D3D. Also, based on the fact that D3D 8 is not as bloated as previous versions, a wrapper for other OSes could be easily achieved (IMHO).

Last question, again on the spirit of 'SDL Vs DirectX', are there any plans for more support for more input devices, like force feedback wheels etc.

Take care and thank you for all the hard work you have put on SDL the last few years. (and also greatly thank you for the BeOS port! :)

SL: Okay, there are several questions here. First, thanks for the appreciation! It should go to all the developers who have contributed to SDL and to products using it, because without them, it would not have become the great API that it is.

As for integration between SDL and OpenAL... SDL audio is fairly lightweight and designed to have mixer implementations be built on top of it. OpenAL is a heavy-weight 3D audio API. Different applications have different needs, and one audio API may suit a particular use better than another. You can always choose to use SDL for video and OpenAL for audio, or SDL for audio and another API for video, etc., you have many choices in the design of your game.

As an aside, there is support in the Linux implementation of OpenAL for using SDL as a back-end, and in fact this was used at one point to get the Linux implementation working on Windows. However, this isn't generally needed because of great native audio support.

There are no plans for a Direct3D wrapper for SDL. OpenGL works well on Linux, Windows, MacOS, and many other platforms.

Finally, yes, the device support and event model in SDL 1.3 will handle a much wider range of devices. Whether or not force feedback support will be included will depend on the state of the drivers for these devices across the range of platforms that SDL supports.

Gamecube, Xbox?
by evilMoogle

With SDL for PS2, are there any plans to do the same for the other next-gen platforms, the Gamecube and the Xbox?

SL: I don't know of any plans, but I'm sure somebody will do something as an exercise at some point. That's one of the great things about open source software. I'm constantly surprised at what people are doing with SDL.

higher level?
by magic

With X-Box supporting DirectX only (and a special version at that) and PS2 not supporting OpenGL in general, some of the utility of SDL is lost. For example, I can write a SDL & OpenGL game that compiles and runs on OSX, Linux, and Win32. But window, input, thread and audio management are the least of my problems when moving to X-Box or PS2... I have to rewrite my whole graphics pipeline!

There are, of course, some very good commercial 3D API's that will abstract over this problem. One of the strengths of SDL has been that you have abstracted over the low level and have avoided getting into the sticky business of fighting OpenGL and Direct3D for the 3D API. This also limits the utility of SDL, however, because of the lack of a solid, free API for abstracting the 3D API.

Do you see SDL moving higher up the graphics pipeline in the future, or is it your intent to continue to avoid higher level 3D calls?

SL: I like side-stepping the 3D API issue. :)

I don't plan on adding a 3D API abstraction at this point, however I'm open to the idea of getting a single working 3D API that would cover the platforms you mention. My suspicion, with my limited experience with the PS2 hardware, is that it would take longer to write a functional API that could cover the differences in platforms than it would to get a working subset of OpenGL implemented. There's a reason that many PS2 developers write directly to the hardware.

Sony Development Costs
by debrain

Sony charges stiff fees for Playstation (2) development licenses. Was one of the primary focuses of SDL a way to circumvent these fees, broaden the PS2 platform, broaden the SDL platform, or broaden Linux as a viable game platform?

SL: Mostly the port was done as a fun toy. The intention was to broaden the SDL platform, and possibly allow the average person to write games that would run on the Sony Playstation.

End-user availability?
by DeadMeat (TM)

I brought this up before when the port was announced, but nobody knew the exact answer, so maybe I can get it straight from the horse's mouth ...

From what I understand, the PS2 Linux distro uses a proprietary, binary-only driver/library/program to allow programmers to access the PS2's graphics chip. My question is, how will this hinder end users' ability to get their hands on SDL-based PS2 games?

Does this mean they'll have to buy a copy of the $200 Linux development kit? Or are developers allowed to freely redistribute the graphics runtimes? (Or have you found some other way around this, perhaps by accessing the PS2 hardware without the binary runtime?)

I'm just afraid that most PS2 gamers (read: non-geeks) won't find SDL games too attractive if they have to buy a $200 Linux kit to play them.

SL: The SDL port runs on Sony's Public Beta of Linux on the Playstation 2. This public beta is loosely based on a derivative of RedHat Linux, and works just like any other Linux system. It boots from a memory card, but once booted, it can access the network and hard drive like a UNIX workstation. You can download software RPM archives that were built on Linux for the PS2 and install them normally. This is the way I distribute the SDL runtime packages and Maelstrom for the PlayStation 2.

Since the Linux beta is publicly available only in Japan, I'm not sure what would be included in a commercial product that would be released in the U.S..