Archived

This topic is now archived and is closed to further replies.

cmdkeen

game dev for linux: overview

Recommended Posts

hello linux-game-programming-gurus-and-other-people-that-would-help-me, I recently got a linux distribution. I''ve done some dos + windows(dx) programming so far, now I would like to do a little game in linux to see how it works. Im currently looking up the documentation for linux/kde programming. Where can I get additional game programming info (tuts, references, etc) ? Where can I get an overview of tools/libs that are useful for game programming ? What libs would you recommend ? I think I will use OpenGL for graphic but whats good for sound effects/midi/input ? any help appreciated Jan Rehders

Share this post


Link to post
Share on other sites
Have a look at SDL. It can do sound and input and setup a window for you to draw in (OpenGL compatible) etc...
Unfortunately it doesn''t do ALSA sound, only OSS (at least the version I''ve looked at, perhaps they''ve implemented ALSA sound by now, check it out).

Share this post


Link to post
Share on other sites
SDL is definetaly the way to go if you are used to using DirectX. As for sound, there is a free (for non-commercial use) sound library called FMOD available that supports ALSA, OSS, and other native sound API''s. Check it out, it works wonderfully in Windows and Linux.

-----------------------------
kevin@mayday-anime.com
http://dainteractive.mayday-anime.com

Share this post


Link to post
Share on other sites
Generally, when you''re writing games you don''t go through KDE, it''s somewhat slow. (Not as slow as the GDI, though ) SDL is good, but if it''s not your thing, there are alternatives, like using glut to set up your windows and graphics. It''s only graphics, so you''ll have to dig something else up for sount/input/etc.

Share this post


Link to post
Share on other sites
For sound and midi, you should take a look at
http://wolfpack.twu.net/YIFF

YIFF is one of the most stable and time tested
sound servers for Linux games available.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Some Guy
Ahem... Allegro. It''s opensource, does graphics, sound, input, etc.. And, it can use OpenGL.


I''ll have to second that. Allegro is SOOO much better than SDL.

And AllegroGL just kicks ass.

Share this post


Link to post
Share on other sites
Heh well... the Linux-people are always battling over which is better and which is worse. I personally prefer the SDL API (it''s just the way it''s laid out), but you are of course entitled to your own opinion. And now that I''m already using SDL, and SDL isn''t dieing, I''m sticking with it.

I have to add that while KDE is IMO the best desktop environment on Linux, it''s not exactly the fastest. Pure GDI programming is probably faster than the bulk of KDE/Qt/X. Of course, just like few people write programs for pure Xlib, few people write for pure GDI, and they most often use MFC which makes it slower again.
However, startup times of KDE programs are something that definitely needs work. Anyway... it''s improving all the time, that''s the good thing about Linux stuff (and they actually care about execution speed...)

cu,
Prefect

One line of sourcecode says more than a thousand words.

Share this post


Link to post
Share on other sites
Okay, here's how I see it. For libraries, there are basically three all-in-one choices: SDL, Allegro, and Clanlib (though i'm not sure how Clanlib deals with OpenGL). I myself am an SDL man, but I've heard very good things about Allegro and, especially recently, Clanlib. I suggest you take a look at all three and pick the one that suits you best. There are also individual libraries to help you such as glut, yiff, plib, and hundreds of others that each handle one aspect of your game.

As for additional game programming info, if you're using SDL, libsdl.org has a great number of open source demos. I know some people complain that there's not as much hand holding, but if you're willing to poke around the source, you'll find that there's not as much need for hand holding. For non-SDL things, i don't know. There are plenty of generic programming tutorials that are applicable to game development, and there really isn't anything fundamentally different about programming a game under Linux than any other OS, other than the libraries (or system calls) you're using. Refer to the library's page for liberary specific help, and when all else fails, try IRC and mailing lists. I've gotten better help at #sdl than from anywhere else.

Also, i might as well plug Programming Linux Games (not to be confused with Linux Game Programming), which really covers basically everything you're asking for. It's at http://www.nostarch.com/plg.htm I didn't write it, i've just heard good things.

There aren't too many overviews of tools since everyone has an oppinion. Some people love KDevelop. Some people love CodeWarrior. I myself, and a great number of others use the normal *nix tools. I write code in vim (though i could be using emacs or nedit, if that were my thing), compile with g++ (which is part of gcc), build using make (and autoconf), debug with ddd using gdb as a backend, and profile using gprof. CVS is also a life saver. It may seem like CVS is only for projects with many developers, but i use it for everything i do that's more than just a file or two. There's a free book on CVS on the web, that i highly suggest. There are a few other tools such as gperf for the occational odd job, in this case finding a perfect hash function, that i'll use occasionally, in addition to gold old homebrew tools. I use gimp for most of my 2D graphics work. 3D modeling is a bit tougher. If you're willing to put in the time to learn it, i hear Blender is great, but it's a bit on the impossible side for the newbie, even more so than most modelers. Maya is available for Linux if you're willing to blow a chunk of change on it. It doesn't really get much better or more professional than that.

Finally, as long as you're doing game programming, i wouldn't bother learning KDE specific stuff. Games shouldn't tie themselves to one window manager or desktop enviroment or another, in my oppinion. There's really no need to for most games, and even if you need some windowing, you can get it without using Qt or gtk.

Good luck!
ben.c

Edited by - shelrem on August 13, 2001 5:00:29 PM

Share this post


Link to post
Share on other sites
thank you for your answers

this are really much more answers than I expected

I hope I will be able to start soon because I just mixed up my modules.conf when I tried to install DSL drivers

I asked for KDE progging because I like to make enhanced editors for my games. So it would be useful to know about it.
I recently heard Borland gives away a free version of Kylix, I''ll have a look at it.

And again a big thanks to you, this will give me some work for the next months

btw: which of these apis are cross-platform ? It would be nice to be able to release windows and linux versions.

[ad]
You might have a look at www.turtlegame.f2s.com to see my last game (win/dx)
[/ad]

Jan Rehders
http://www.turtlegame.f2s.com

Share this post


Link to post
Share on other sites
Most of the SDL''s are cross platform, even glut is.
As long as you stick to an SDL you can worry only
about design towards the SDL''s API procedures.

There are two points I''d like to stress here,
portability libraries are a major help in the learning
process, but they don''t really teach you about Windows
or Linux to take advantage of each OS''s features.
They''re the MIN of all the platforms they are ported to.

So keep in mind that there''s a performance cost with
portability. One that isn''t an issue as long as your
audiance has the latest cpu''s.

Share this post


Link to post
Share on other sites
Most of the SDL''s are cross platform, even glut is.
As long as you stick to an SDL you can worry only
about design towards the SDL''s API procedures.

There are two points I''d like to stress here,
portability libraries are a major help in the learning
process, but they don''t really teach you about Windows
or Linux to take advantage of each OS''s features.
They''re the MIN of all the platforms they are ported to.

So keep in mind that there''s a performance cost with
portability. One that isn''t an issue as long as your
audiance has the latest cpu''s.

Share this post


Link to post
Share on other sites
You don''t really miss out that much on performance - there are of course one or two additional function calls inside the wrapper API, but that shouldn''t hit you too much.

What can be a problem is that you might miss the latest features of 3D hardware etc...

cu,
Prefect

One line of sourcecode says more than a thousand words.

Share this post


Link to post
Share on other sites
One big bitch amoung advanced programmers are
get()s, and SDK''s introduce a ton of them per cycle
and that causes lots of halts on the pipeline.

Looking at SDL''s design I can spot a few serious
ones in the data request callbacks.

But not loosing sight of the goal, a porability
library is a good way to start on a first pet game
or for the casual programmer. But if you get serious
on the issues of performance, you''re going to have
to grow up and code directly for the OS.

Share this post


Link to post
Share on other sites
I don''t pretend that SDL on Win32/DirectX is faster than barebone DirectX. That would be nonsense.

But I do have to wonder whether you actually occupied yourself with the SDL API? Many APIs I''ve seen use fancy stuff like C++, where the GetXXX()-methods you mentioned are everywhere. With SDL, you get barebone C, and the GetXXX()-functions are nowhere to be seen. You''re free to access SDL_Surface directly, for example (in fact, you have no way to read the pixel format apart from accessing the structure members directly).

And of course any blitting with an intermediate API will take at the very least one function call more than barebone DX. However, I''d like to get my hands on the DirectX source code and the driver source code and have a look at how many function calls are in there. I don''t think two or three additional function calls do that much damage. Of course - it''s not perfect.

So yea, using an API like SDL is not _that_ fast. But don''t expect to get kick-ass performance simply because you use barebone DirectX instead of SDL.

cu,
Prefect

One line of sourcecode says more than a thousand words.

Share this post


Link to post
Share on other sites
Learfox said, "Not loosing sight of the goal, a porability
library is a good way to start on a first pet game
or for the casual programmer. But if you get serious
on the issues of performance, you''re going to have
to grow up and code directly for the OS."

This just ain''t right, unless you consider SM''s Alpha Centuri or Tribes 2 to be "pet games." Same for Dues Ex, Myth 2, and any number of other games that Loki Software has ported. I''m not saying that SDL is faster than coding directly for the target OS, but it''s fast enough for professional, commercial games.

ben.c

Share this post


Link to post
Share on other sites
hmm its interesting but I''m not looking for something to learn programming. I''ve already done games in windows and I''m curious about linux. I want to use a portable SDK because of the portability.

Some words about the C++/GetXXX() thing: the GetXXX functions dont have to be slower than directly accessing some structs. If they are done as inline and only return a reference to the struct they arent slower. Its the same speed. And I prefer a nice object oriented interface beacaus oop is a great aid in developing if used right.

Jan Rehders
http://www.turtlegame.f2s.com

Share this post


Link to post
Share on other sites
cmdkeen: It''s true that if you got the source to the API (as with SDL etc...), Get()-functions tend to be inline, thus you don''t loose speed.

However, when it comes to COM-ish things like DirectX and closed APIs, Get()-functions can''t be implemented inline...

cu,
Prefect

Share this post


Link to post
Share on other sites
Shelrem, those games as you said were ported.

Using a portability library is obviously an efficient
way to do that.

But the thread is not about portability but writing
Linux games with DOS/Windows background.
That''s why I pointed out that if you really want
to get into Linux programming at advanced stages
you''ll need to put aside portability libraries.

Loki is also a big sponsor of said libraries so its
consistant for their image to use them.

Share this post


Link to post
Share on other sites
Prefect, the get()s that I was reffering to were
in response to a question about sound. SDL needs
a callback for sound data, that''s where that round
trip occures.

But you can always use sound and other roundtrip
procedures elsewhere, but then you loose some portabitiy.

Share this post


Link to post
Share on other sites
Learfox: It doesn''t really matter that SDL is a portable library or a Linux-only one. The point is that you can make professional or professional-quality games with it. And yes, if you want to get into the finer points of Linux programming, you can''t do it all through SDL, but it''s not like you can''t access the underlying system when you use SDL; your program just won''t be portable anymore.

My point is that it doesn''t matter whether the games were originally written with DirectX and then changed to SDL or written in SDL originially, SDL still drives some AAA titles out there. And given that the original poster has experience with directx, a library that is used to port directx games seems only natural.

But yes, if you''re determined to write games that specifically *don''t* port to non *nix platforms, then you''ll have to go out of your way when using SDL.
ben.c

Share this post


Link to post
Share on other sites