Slashdot Mirror

Cedega is a non-free version of wine with directx capabilities. You can browse their supported games here.

Of course not all games now-a-days require wine or cedega in order to run on linux. Games like unreal tournament and doom III include fully functional linux versions.

There are several open source games developed for but not limited to linux. torcs, flightgear, tuxracer are some examples.

Projects like libsdl are making cross-platform game development easier.

Probably the biggest problem you'll encounter is building drivers for your video card. I've heard it argued both ways but as I understand it, both nvidia and ati drivers are ass-pains in linux. Nvidia's drivers are free as in beer, not speech. If you don't really care about free-software principles and philosophy then this is not a problem for you. ATI's drivers I understand to perform less than ideally. If you haven't already purchased your video card, I would encourage you to do extensive research beforehand.

In reality, linux distributions have few differences. Any recent, major distribution should be able to accomodate gameplay. I myself use debian unstable for amd64.

As far as performance, it really boils down to hardware. My advice is to install the linux distribution of your choice. Once you get glxgears to run, give ut2004demo a try, and if you like the way it works, then stick with linux.

Yes, but what's stopping a developer from starting out with, say, SDL in the first place? It seems like portability can be trivial if you start the project with portability as a goal.
Valve's probably got more money behind it that Epic, and it certainly has more money than Running With Scissiors, and they have their games ported to Linux. They could have at least started with an OpenGL renderer and then paid Icculus to handle the rest.

I think that Valve owes the community a client because they're more than happy to let us do the server-side grunt work. Let's face it: the more high-quality, dedicated servers out there, the more copies they're going to sell. So what if it won't make them another million bucks? Let the sysadmins play, too!

SDL is a multiplatform solution much like DirectX; it covers controllers, 3D graphics (via OpenGL) and audio. It's quite easy to use, and it's ported to almost everything. Lots of games use it, notably the Unreal series.

The solution is out there, and it's already proven to work.

I beg to differ:

• Direct3D - OpenGL, cross platform.
• DirectSound - OpenAL, cross platform.
• DirectShow - QuickTime, Windows and Mac. I don't know of any truly cross platform (Windows, Mac and *NIX) alternatives.
• DirectPlay - OpenPlay, cross platform.
• DirectInput - SDL, cross platform.

Again, point by point...

There is some (limited) documentation on the project, but most of it is badly out of date (as always :)). The main site for the effort is source.bungie.org; there is also our SF project page, where you can join the developers' mailing list. That's really the best way to get involved. BTW, what sort of coding experience do you have? We need pretty much everything--engine, networking, UI, etc. Do you know anything about coding for Carbon or Cocoa? The engine is in C and C++, if that's relevant.

There is a project called "Marathon|Rampancy" to port the maps/sprites to Unreal Tournament, which is probably what you were thinking of.

SDL is the Simple DirectMedia Layer, a set of multimedia libraries for sound, 2D and 3D graphics, keyboard/mouse, etc., which is used in a lot of open source programs.

The hi-res and 3D substitutes are controlled via an XML language called MML, the Marathon Markul Language, which tells the engine to replace with what.

There were builds for classic, but they haven't really been kept up. The last build is over a year and a half old, and I have no idea if the classic maintainer is still working with us.

It seems to have disapeared off the net, but there was a project on lisdl.org called SymphonieNG Link This project was basically a tracker using SDL & OpenGL which used a 2D OpenGL GUI. AND it was written in standard C. Maybe it is cached somewhere, but I can't find it at present. It was also linked on opengl.org

Just wanted people to realize the diffrence here. irrlicht is is a 3d engine, which is about putting things on screen. For making a full game, much much more is needed. Player control/input handling,

How about
OpenGL,
SDL and OpenAL?

OpenAL for one is something few people seem to know about. I've developed sound systems using both DirectSound/DirectMusic directly as well as OpenAL - and there are worlds of difference between MS's obfuscated crAPI and OpenAL - It's actually a pleasure to write a capable 3D sound system on top of OpenAL.

We have the open standards. What I think we really need is more information for developers starting Linux development. More tutorials, more books, and more publically available (read: web) articles on how to get certain things to work under Linux, to make it easier for software engineers to make the transition and/or port of their software to Linux.

Finding good, clear sources of information on how to get certain things done is what I've found to be the biggest hurdle to start developing software for Linux. Maybe I just didn't know where and how to look, but I imagine I'm not the only one involved in programming, who has had that problem.

Some links: There are a few open source games in development out there that are using the combination of these two OGRE (Open Graphics Rendering Engine) http://www.orge3d.org/ ODE (Open Dynamics Engine) http://www.ode.org/ SDL (Simple DirectMedia Layer) http://www.libsdl.org/

Story-based games, especially, deserve to be presented in a final, polished form. For that reason, I would not expect it to be released early and often. There is also a question of artistic integrity. Game designers, amateur and professional alike, have strong ideas. Can they share authorship with some dude on the Internet?

Probably SDL. Loki uses SDL for some of its stuff, and the GPL'd QuakeII engine has a SDL version.

Yep, SDL has a very effective crash parachute! See?

If you're going at the programming by yourself, I would strongly recommend you use a library to save you from having to write your own low-level access routines (unless you just want to learn about how all these whiz-bang effects are done, but that may distract you from the goal of getting a game finished). Unless you have commerical backing, or are absolutely sure you have the willpower to stick to the project (by "absolutely sure", I mean you've done it before right to the bitter end and want to do it again), I would recommend using as hing-a-level library as possible.

There are several out there with their advantages and dis-advantages. Some of them are Microsoft DirectX., OpenGL, Allegro and SDL. High-level libraries are good for beginners and are useful for rapidly developping games. You can accomplish a lot with a few lines of code, but they can make the executable size bloat, and sometimes, you may want more control over the system. Low-level libraries are useful for control-freaks who want more control of what's going on.They let you access the system with little overhead, but require a lot of work to get to work. DirectX and OpenGL are low-level libraries, Allegro is a high-level library, and SDL is somewhere in the middle.

Also, check to see which platforms the library is available for. DirectX is only available for Microsoft, whereas OpenGL, SDL and Allegro let you write programs that can be ported to a multitude of systems and OS's.

Personally, I use Allegro, but other people may have different requirements or desires to dig down deep into the hardware.

1) Listen to DVDs...I find it's more interesting than music and not more intrusive. I minimize them and just listen to the sound, flipping over for the good parts.

2) Write code. Ever wanted to learn a graphics library? New language? Check out SDL, neat little cross platform graphics library. Write a PacMan clone to learn it.

3) Read news. I read a lot of news during the slow times.

4) Gameboy. The SP is pretty small, would probably go unnoticed or be mistaken for a PDA.

--trb

#include <stdio.h>
#include <stdlib.h>

#include "SDL.h"

int main (int argc, char **argv) {

if (SDL_Init(SDL_INIT_VIDEO) < 0) {
fprintf(stderr, "Could not init SDL: %s\n", SDL_GetError());
exit(1);
}
atexit(SDL_Quit);

SDL_Surface *screen;
screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE);
if (screen == NULL) {
fprintf(stderr, "Could not set video mode: %s\n", SDL_GetError());
exit(1);
}

SDL_Event event;
int quit = 0;
while (quit == 0) {
SDL_Delay(1);
while (SDL_PollEvent(&event)) {
if (event.type == SDL_QUIT)
quit = 1;
}
}

SDL_FreeSurface(screen);

return 0;

}

gcc -Wall -ggdb `sdl-config --cflags --libs` ./SDL_app.c -o SDL_app

#include <stdio.h>
#include <stdlib.h>

#include "SDL.h"

int main (int argc, char **argv) {

if (SDL_Init(SDL_INIT_VIDEO) < 0) {
fprintf(stderr, "Could not init SDL: %s\n", SDL_GetError());
exit(1);
}
atexit(SDL_Quit);

SDL_Surface *screen;
screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE);
if (screen == NULL) {
fprintf(stderr, "Could not set video mode: %s\n", SDL_GetError());
exit(1);
}

SDL_Event event;
int quit = 0;
while (quit == 0) {
SDL_Delay(1);
while (SDL_PollEvent(&event)) {
if (event.type == SDL_QUIT)
quit = 1;
}
}

SDL_FreeSurface(screen);

return 0;

}

gcc -Wall -ggdb `sdl-config --cflags --libs` ./SDL_app.c -o SDL_app

#include <stdio.h>
#include <stdlib.h>

#include "SDL.h"

int main (int argc, char **argv) {

if (SDL_Init(SDL_INIT_VIDEO) < 0) {
fprintf(stderr, "Could not init SDL: %s\n", SDL_GetError());
exit(1);
}
atexit(SDL_Quit);

SDL_Surface *screen;
screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE);
if (screen == NULL) {
fprintf(stderr, "Could not set video mode: %s\n", SDL_GetError());
exit(1);
}

SDL_Event event;
int quit = 0;
while (quit == 0) {
SDL_Delay(1);
while (SDL_PollEvent(&event)) {
if (event.type == SDL_QUIT)
quit = 1;
}
}

SDL_FreeSurface(screen);

return 0;

}

gcc -Wall -ggdb `sdl-config --cflags --libs` ./SDL_app.c -o SDL_app

#include <stdio.h>
#include <stdlib.h>

#include "SDL.h"

int main (int argc, char **argv) {

if (SDL_Init(SDL_INIT_VIDEO) < 0) {
fprintf(stderr, "Could not init SDL: %s\n", SDL_GetError());
exit(1);
}
atexit(SDL_Quit);

SDL_Surface *screen;
screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE);
if (screen == NULL) {
fprintf(stderr, "Could not set video mode: %s\n", SDL_GetError());
exit(1);
}

SDL_Event event;
int quit = 0;
while (quit == 0) {
SDL_Delay(1);
while (SDL_PollEvent(&event)) {
if (event.type == SDL_QUIT)
quit = 1;
}
}

SDL_FreeSurface(screen);

return 0;

}

gcc -Wall -ggdb `sdl-config --cflags --libs` ./SDL_app.c -o SDL_app

MS are giving out their compiler suite for free (as in beer)

So you want an OpenGL version? It's up to you then.

This still doesn't fix the problem of games under linux, unless someone's managed to port DirectX 9 and hardware-accelerated drivers for the major graphics cards...

Ahem, 4 insightful for having no clue that both Nvidia and ATI have started providing Linux drivers for quite some time? That Matrox is supported by MESA's own drivers? That UT, UT2003, UT2004, America's Army and all id games have been ported to Linux? That there even are open source high-res OpenGL versions of Doom for Linux (and Windows) even though the original Doom used 8-bit 320x200 software rendering)? Well, ok...

As for DirectX being ported to Linux, winex is doing this, but for native apps developers can simply use SDL and write games that are 100% portable across an incredible range of OSes.

And/Or some of the other interesting OSS API's ...

Your list will get bigger, though you might have to shuffle a few things around.

In all fairness, I don't think that your second and fourth points are very valid.

Yes, WinXP broke a lot of compatibility with DOS and older Windows apps, and in my opinion, it was far overdue; supporting the legacy APIs was hurting Windows. To put things in perspective, the majority of the software that it broke compatibility with was written for Win95 or earlier; the Linux kernel was still in 1.x in 95, and I doubt that you could find any Linux program compiled for a 1.x kernel that would run on a modern system.

Also, saying that you can't program without spending cash on a compiler and libraries is just wrong. I am familiar with at least two free C++ compilers that run under Windows, DJGPP and MinGW. Dev-C++ is also a fairly popular development environment. You don't even have to use Microsoft's libraries, if you don't want to; while I believe the DirectX SDK can be downloaded for free or bought on CD for a nominal fee, you could, alternatively, use SDL or wxWidgets or any number of other graphical libraries.

LOL! Just so folks aren't confused by this error, if you're curious go Read The Fine FAQ :)

1. SDL has licensing issues. You can't use it for a commercial application since you'd have to include your source code. Thus, it's not of much use unless you are just trying to learn the basics of game development.

???

The SDL libraries were developed to port commercial, closed source, games to Linux. Since then, it's become a good cross platform set of tools. Where did you hear that it can't be used in commercial games or in any other closed source program?

The base SDL libs are LGPL-licenced, and even if they were GPLed, it wouldn't be much of an issue (Linux the kernel is GPLed, for example). Check the Simple DirectMedia Layer web site.

The restrictions are important for commercial use, but minimal.

In sum, you *CAN* include the source of whatever you base it on, but you *DO NOT HAVE TO*. If you change the LGPLed libs themselves, *AND SOMEONE ASKS FOR THAT SOURCE* you have to hand over *THAT SOURCE ONLY* -- not your closed application. The restrictions are important for commercial use, but minimal.

I use LibSDL because I want to do more than just sound in a cross-platform application. Did you consider using SDL for sound before you chose OpenAL?

It's called SDL and it's cross platform. ;)

Windows is, has been, and probably always will be the PC gamers OS(As there is still no OS answer for DirectX on Linux).

Hmm... I guess I really should have hit preview.

I meant to say:

Other network layers to look at are OpenPlay and SDL net, both of which are also also free and OpenSource.

I've looked at the torque network layer while it was still part of the torque engine. It's well suited for developers who want a small scale (32 players or so) network game, particularly if its a first person shooter.

I wouldn't even consider it for a mid-size or larger multiplayer game, as it lacks important security features and IMO doesn't give enough control over the actual network protocol due to the emphasis on RMI.

Other network layers to look at are OpenPlay and , both of which are also also free and OpenSource.

Disclaimer -- I contribute to OpenPlay.

I've often heard that SDL ( LibSDL.org ) is comparable to DirectX, and any program written in a nice API like SDL would *seem* easy to translate in such a high-level way. Although I have no experience w/ DirectX or any such translating software, so this is all just speculation.

OpenGL is only graphics, whereas DirectX is also about sound, networking and input devices.

SDL is more comparable to DirectX (and it uses openGL :).

I'm glad this guy is an EE, since he doesn't seem to know wtf he's talking about in _software_ engineering terms. You can't compare DirectX and OpenGL. He's trying to say D3D is a better solution just because it's bundled with DirectX which is tied to Microsoft's IDE. If you want to only do WIN32 development, then sure DX is fine. However consider there is only one game console that uses D3D, and we all know how big a market share it has. Sure not all Playstation 2 titles use an OpenGL based engine, but many do. Where as all gamecube titles use nGL on ATI GPUs. Also if you want to bother to port your application to Linux or Mac OS you must use OpenGL. ( 64bit platforms are nice for addressing more memory for those models. Would you rather run Maya for example with more or less memory? )

I'm so sick of DX vs GL for PCs over the years too. They don't do the same thing. This is why Sam started SDL, and several vendors are making similar frameworks. I admit OGL doesn't support all the wiz, bang features in core. However if you really want performance, then using the vendor EXT ( extentions ) are the only way to go anyhow.

And please, for the love of god, don't use directx. OpenGL all the way baby!

You mean you've never heard of SDL? Wow.

No trolling, but.. something like DirectX wouldn't hurt!

and whats SDL, chopped liver?

A simmilar corss-platform solution exists:
SDL

It's always growing, it's open source (sort of), and it already supports many of the things in DirectX.

Once Linux becomes a viable alternative to Windows for office use things will improve. With office use we will see better driver support for common hardware (not that there is much of a problem currently, other than closed source).

Multimedia support under Linux is not in a bad state. SDL is a good standard set of libraries for handling windowing, OpenGL, input and audio. With projects such as Project Utopia and HAL integrating the kernel with the desktop, things can only get better.

I think the future is bright for Linux gaming.

The key to gaming for linux in my eyes at this point is the not-so-small matter of adopting a good graphics API (like SDL), not the individual games themselves. Specifically, the sound issue of OpenAL vs ALSA vs ESD etc. really hurts quick adoption by industry I think. What would be nice is something like an Architecture Review Board, or working group amoungst the linux muckity-mucks to promote a universal standard.

It already exists. It's called Simple Directmedia Layer, or more commonly libSDL. It supports Mac, Linux and BSD and provides a rich library of multimedia, input and threading functions.

SDL is what you're looking for; it's been around for several years. It's mature and in use in many projects. I don't know everything that DirectX does, but I believe most of it can be handled by SDL combined with OpenGL. Not only does SDL run on many platforms (including Windoze), it has bindings for various high level languages, so one isn't stuck with C or C++.

by having all the features that desktop Linux needed, which in my view is basically Fedora

Just to make a point, so bear with me ... Fedora is the wrong choice. You should use SuSE. Why? Well, Novell's pushing it for the desktop, Sun's pushing it for the desktop, and SuSE's pushing it for the desktop. RedHat (nee Fedora) has abandoned the desktop, remember? Also, SuSE, like RHEL, is LSB certified.

See what I'm getting at? That comment on SuSE hanging on the tip of your tongue? To put it more bluntly, you'll never get people to give up Debian, Gentoo, Mandrake, SuSE, Knoppix, etc for another *existing* distro because that would imply they were "wrong" in not choosing said distro (Fedora, whatever) in the first place. Anyhow, it's a moot point, our energies would be better focused on improving and expanding SDL that on starting yet-another-distro.

The reason why more games aren't ported to Linux is that they're written in DirectX. If we can get SDL to the point where it's a 95% drop in replacement for DirectX (memory/thread management and win-specific crud are the other 5%) then we've paved the way for porting games to Linux. Anyhow, I'm not trying to be a jerk, I'm just trying to put that "let's go with Fedora" thing into perspective for you.

Why doesnt the OSS community collaborate with Apple to make a robust *well marketed* alternative to DirectX for *nix?

Here's SDL. It's an interesting idea. Go do it!

It seems to me that a solid cross-platform API is worth two gaming distros. As it is, I can whip up a little demo in SDL and run it under linux or windows or a host of other operating systems. I think if we could get good industry support for OpenAL and OpenGL to supplant less compliant libraries, that a good API like SDL could serve the purpose rather than devoloping a whole distro around games.

depends on what libraries you use but you arnt going far without some form of interface which natively ties you to a platform - MFC, WFC, Win32, you pick your poision

wxWidgets
SDL

Exactly, there will be "kind of" a functional language - which has to use the same libraries everyone else does, which are all just like the Java libraries. So people using this pseudo-functional language will be hard-pressed to really see the advantages of a functional language as you would if you had a real function language with a set of libraries as broad as that offered by Java.
I heard F# was supposed to be based on OCaml.
OCaml already comes with a nice set of libraries, not to mention parser tools (which I heard were missing from C#). It even has bindings for SDL!
And I don't know why you call it "pseudo" functional.
Although I agree on the fact that the syntax for .NET bindings would probably have to be weird.

about the only thing we couldn't do with SDL + OpenGL that DirectX provides is the network coding/matchmaking stuff from DirectPlay

Here comes the SDL_net

(Not to the parent poster): In case you are curious, there're plenty userful and commercial-quality libs out there, such as SDL_image, SDL_mixer, SDL_ttf...They just rock, some of them had been used in commercial titles (remember Lokigames?)...forget about DirectX, and screw MS.

about the only thing we couldn't do with SDL + OpenGL that DirectX provides is the network coding/matchmaking stuff from DirectPlay

Here comes the SDL_net

(Not to the parent poster): In case you are curious, there're plenty userful and commercial-quality libs out there, such as SDL_image, SDL_mixer, SDL_ttf...They just rock, some of them had been used in commercial titles (remember Lokigames?)...forget about DirectX, and screw MS.

Go Check out SDL[libsdl.org]. 'Nuff said.

--vranash

OpenGL and SDL can interact directly with the framebuffer bypassing the OS layer for graphics meaning more portability.
SDL intereacts with DirectX or the Win32 API if DX isn't available.
see here
If it could bypass the OS it would have to have a driver level component. Something that runs in ring 0 (i.e. at the kernel level).

Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. There is also code, but no official support, for Windows CE, AmigaOS, Dreamcast, Atari, NetBSD, AIX, OSF/Tru64, and SymbianOS.