Slashdot Mirror
Linux Game Programming
Overview There are precious few books which mention programming games under Linux. There even fewer that cover programming games under Linux exclusively. Linux Game Programming is the first published book exclusively dedicated to programming games under Linux. Unfortunately this book was rushed to the publishers just to obtain the dubious distinction of being the first. Worse, this book has many errors and a CD which is next to worthless.
What's good? It's very hard to find anything that's really outstanding in this book. The chapters offer what amounts to little more than a starting point for learning, with just enough to get the reader interested in the topic before moving on to the next topic. The sections on Artifical Intelligence and Porting stick out in my mind as some of the books strong sections, but even those could use some more elaboration. What's Bad? In trying to cover as many aspects of Linux game development, the book ends up giving little more than a synopsis of the material. Also, some of the choices are curious. Why have a chapter on SDL which only deals with using SDL for the input methods? There seems to be a lack of focus for the overall book for what it wishes to accomplish. Also, dedicating whole chapters printing out open source licenses (GPL, LGPL, Artistic, BSD, and Mozilla) is nothing more than fluff for a book like this (although the author does include a chapter discussing the benefits and drawbacks to chosing an open-source license verses a closed source approach.) The code is not complete, and doesn't show how to use it in a full program. Worse, there are no complete working game programs, either in the book or on the CD.
The CD is incomplete and a waste. It includes the examples from the book. Unfortunately, the examples are all in MSDOS format, so the reader will have to convert them in order to get them to run (if they'll even run at all. I had a hard time getting some to even compile). Also included on the CD is the SDL 1.1.8 kit in source and RPM format (the development RPM is missing, though, so you'll need to pick that up as well in order to actually DEVELOP SDL games). There are also source tar files for Mesa3D, OpenAL, and SVGALib. Also included is the Indrema SDK, which might be of interest for some people. There are also some strange additions on the CD. The first weird addition is the Linux Source for kernels 2.2.18, 2.4.0, and 2.4.1. Why include these on a CD for Linux game development? The second odd addition is a directory for PrettyPoly. The software is packaged as a tarball of the author's CVS root directory. How this made it onto the CD in this format is almost as inexplicable as having MSDOS formatted files destined for a Linux machine.
Conclusion This book could have been so much more. If the authors had taken the time to describe designing and developing several Linux games from the ground up, this book would have been better for it. As it is, it's barely good as a reference for what it does cover. I am very disappointed in this book. It could have been so much more, but falls way short of its potential.
There's one gripe I want to air about this series as well. Why does Andre LaMothe get his picture on the back cover of every one of these books as the 'Series Editor'? Also on the spine, his name is at the top. I'll admit that I like LaMothe's writing, but giving him top billing on the Prima Tech Game Developers series seems pretentious to me.
Table of Contents
- Introduction
- Introduction to Game Development
- Linux Development Tools
- The Structure of a Game
- 2D Graphics Under Linux
- Input with SDL
- 3D Graphics for Linux Games
- Using OpenGL in Games
- Sound Under Linux
- Networking
- Artificial Intelligence
- OpenSource: Friend or Foe?
- OpenSource License Agreements
- Porting
- References
- Glossary
- What's on the CD-ROM
You can purchase this book at Fatbrain.
Funny to see the link to purchase the book is still included.
Case in point : the simple choice between two SDKs, Direct3D and OpenGL, has delayed advances in 3D technologies on the Windows platform for a very long time, because developers feared the difficulties of supporting them both in their games, but at the same time feared that building everything with D3D would obsolete their whole codebase if OGL won after all -- or vice versa. Imagine the doubts in game developers minds when they read about the dozen SDKs in this book.
In short, choice is bad for things like this. Competition is a great thing when you're trying to improve things for the customers, but when those customers are actually developers, you want to remove all their doubts by offering one very-well-supported environment rather than ten weak ones (Also see : desktops; component models; IDEs; etc.)
Linux needs to make cold choices and finish them up. Only then will it be possible to write meaningful books about game development / desktop development / component development / etc..
The Programming Linux Games book is SDL focused, so your wish has been granted. Now if I could only find a copy. :)
It's geared for the novice that wants to learn how to write games on the specified platform. Being that it's more geared for novices (realize that even this book is that...), it's not going to appeal to a codehead and will get a generally negative review.
/. crowd should be unsurprising.
Unfortunately, most of the "game programming" books are of this variety- there's notable exceptions, like Game Programming Gems, however.
Everyone should realize that most of the books are published for the lowest common denominator; they're trying to strip-mine the populace for money. That it doesn't work for many of the
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
This book is geared for people for whom have never touched this stuff before. It's for game development novices. If you've dealt with the innards of a 3D driver, you're going to understand OpenGL pretty good. If you've done multimeda apps, you're going to understand SDL pretty well. If you understand these topics, this book is NOT for you- it never was intended for people that are looking for more of a reference to how to develop with these apis or for someone looking for the finer points of game development (I might suggest the algorithms list on SourceForge for trying to glean that sort of thing!)
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
And Andre Lamothe was the author of that one. It's a little thin for a person that's been coding for a while, but it had some pretty good stuff in it buried amongst the novice stuff.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Not to complain, as $100 for a commercial engine rocks- but if I can't give a copy to someone else, it's most definitely NOT Free Software.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
How often do you NEED such a thing under Linux?
How often do you NEED such a thing under Windows?
Windows API's are often complex (moresoand you end up needing more calls to the API to do things than you do under Linux/Unix. Don't bother countering with me not knowing what I'm talking about- I've been doing Windows and Unix coding for 12+ years now. I've written everything from business applications to device drivers under Windows and Linux is very much easier to code for.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I think you are mistaken. If you already know how to program games, then a book on games on Linux is quite good.
I bought the book precisely because I wanted a quick introduction to the various Linux APIs. It served that purpose quite well.
Engineering and the Ultimate
You can find out -- the fatbrain link he gives is actually to the Loki book. Here is a fatbrain link to the book he actually reviewed.
why bother writing a game for linux in the first place. Who would buy it?
There is an increasing number of Linux users out there who are willing to pay for games. Loki seems to be making money out of porting games, and whilst I grant you the market ain't as big as the Windows games market, there is a market. Unix is a growing games market, whereas Windows is a very crowded market where only the best 1 or 2 percent succeed.
A professional windows programmer such as myself will never touch Linux
Why not? Quake and Doom were developed in a Unix environment first, and many games companies use Unix (incl. Linux) workstations for graphics development. If you are going to be a serious games programmer you had better get rid of your misconceptions fast. You should use whatever platform offers the best tools and in some cases those tools are Unix only
The simple fact is that a lot of games programming still requires low level programming in places, and a nice friendly GUI environment isn't always the solution.
And forget the GPL -- that will kill any hope of money
The GPL doesn't kill any hope of money since you don't have to make GPL games on a Linux system. You can make a game using your own libraries and/or libraries which are LGPL'ed) and still keep your source code private if you insist.
Personally I think it would be a good thing if games developers to open source their code after a couple of years so that games which became abandonware could be supported by others.
no chance of making a buck
There's a hell of a lot of contract software engineers who have no trouble taking home $150000+ per year working on Unix systems.
Don't loose sight of what people use computers for -- doing things, not messing with etc directories.
Which is why software which requires stability is run on Unix systems (old joke - I'll grant NT is getting better; I work on both).
[OK the previous message is from a baby troll who hasn't grown up beyond AC posts, but I couldn't resist]
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
I spent around 30 minutes poking through this book last weekend at B&N, and my opinion of it is that it is yet another hastily thrown together book attempting to capitalize on the fact that the market is buzzing for more books on Linux at the moment. The topic of games programming under Linux does need to be worked on more, granted, but I think readers are best waiting until there's an O'Reilly book on the subject, honestly.
If you want to learn OpenGL, your next stop should be NeHe's tutorials on Gamedev.Net.
http://nehe.gamedev.net/
GameDev itself is helpful...
http://www.gamedev.net/
As is Flipcode...
http://www.flipcode.com/
If you're interested in writing a good game, you should learn from those that came before you. Check them out using emulators from Zophar's Domain...
http://www.zophar.net/
Also, no game developer worth his salt can ignore the virtual treasure trove of information archived at GamaSutra...
http://www.gamasutra.com/
And finally, you'll want some cool free video game tunes to listen to while you code. The two best sites for video game remixes are Bart Klepka's remixes and Remix at Overclocked.org:
http://bart.overclocked.org/
http://remix.overclocked.org/
Go to it. I hope to play your games soon.
first off, the majority of the world doesn't care
what The Right Thing is--no offense, but it's
true. they dont care about the linux cause.
I am putting forth the suggestion that until
linux has significantly gained popularity, it
will not flourish in the desktop arena (and yes,
I know that this is a chicken and egg problem).
there IS a need for a screwdriver and the hammer
to co-exist, and linux is certainly NOT monetarily
free when you count the number of hours a non-geek
would spend trying to figure out how to duplicate
the functions performed by just a core windows
system these days -- word, excel, outlook, power-
point, acrobat reader, IE...ad nauseum...
it just isn't going to happen soon! most people
come to the bring af an aneurysm just trying to
figure out how to access basic functionality
in MS office.
but yes, by my reasoning, very few people should
give up windows. *NIX simply was never designed
for non-geeks, and piling GUI tools on top of the
command line isnt doing anyone favors.
the command line is still there, and when the GUI
tools dont work (which is quite often), people
are truly stuck because they never bargained for
learning UNIX command line.
why pull someone who is perfectly happy with
their dell machine and preloaded win2k towards
linux? for 80+% of the people, it causes more
pain than gain. they just want to play games
and geek out with their yuppy friends on AOL.
leave UNIX to the geeks.
A year spent in artificial intelligence is enough to make one believe in God.
I love linux, but here we face one of the most
common problems:
someone wants to play the latest games on the
latest hardware, and doesnt mind using Wine or
VMware to do it, or even binary-only games...
the logical conclusion is that if you are one
of these people, the time has not yet come for
you to give up windows! dual-boot or get another
machine if you want to run linux that badly.
one day, linux will probably be able to do all
of these things, but in the meantime, dont pick
up a hammer when you need a screwdriver!
my $0.02
A year spent in artificial intelligence is enough to make one believe in God.
The criticisms of this review are valid but could benefit from a different perspective. I started writing a networked, 3D game client in the spring, my first such attempt. If I had discovered this book a month earlier, it would probably have saved me a week or more. It did save me some time. I could find no other single source that covered what I wanted to do.
;) But, in the absence of much competition, this book may have some value if you want to write code -- and save a little time -- right now.
A short overview and a brief technical introduction to virtually every technology I have used so far is in this book. When you are struggling with your first 3d game client, this book offers valuable perspective that can save you from wasting a lot of time just trying to figure out what to use. If you are attempting, as I was, to write your first 3d, networked game client, consider this: is a week (or two or three) of your time worth 50 bux? (I think that's what I paid) If so, take a look at the book.
If you are an experienced programmer in most of the technologies covered in this book and already have a good perspective on each of them and what they are useful for, don't buy it.
If you fall in between the extremes above and think that the book isn't for you, wait for something else or dig up the info for yourself -- as I mostly did.
(The client I'm working on is not yet released in source form but will be when I get it cleaned up a bit. It is here and is used to play the web game Starshiptraders which has historically been playable only with a browser or telnet.)
Geeky modern art T-shirts
There is a book that is rather out-of-date now, but follows that format and I'd still recommend it if you can spare the cash - 'Tricks of the game programming gurus'. It is by no means perfect but I'd say that an updated version that was linux-centric and covered vaguely similar material (Though it was written before 3d accellerators et al) could be good.
I can't remember who published it off the top of my head but if you really can't find it on a search then the above email address is valid...
Actually, it is rapidly becoming "Just use SDL" - from the FAQ:
Q: Does SDL support 3D acceleration?
A: Yes, as of version 1.1.0, SDL has full support for the OpenGL API.
Given that it also has support for joysticks, sound, video playback, CD playback, and a host of other things - there isn't much reason to use anything else. Plus, there are a ton of libraries and such that use SDL as the underlying base, allowing you that much more freedom and flexibility...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Unfortunately, no - but I imagine you already knew that - but doesn't ALSA emulate OSS - so that calls to OSS would go through ALSA anyhow? Not as good as the real thing, admittedly...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Hmmm - seems like there may be OpenAL support though? I know very little about all of this. I suppose that if it doesn't, you could just use ALSA directly for the audio backend, and SDL for everything else...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
One of my next projects is going to involve SDL and possibly OpenGL - and never having touched either, I went to the SDL site first. Great info! I had one of the demo programs (load a bmp) up and going in a few minutes. Once I get my SuSE box back in shape (updated it last night to 7.2 from 6.3, and I am having some issues that need ironing out - like, oh, 3D Acceleration) - I plan to try modding that demo (my C is rustier than a 50 year old nail), and going from there.
I saw the NeHe tutorials - those have to be the BEST 3D tutorials I have EVER laid eyes on - covers everything - I dare say you could damn near create a damn good 3D game using that site.
There are a ton of places to find code for gaming - you outlined the best of them - hats off to you!
Worldcom - Generation Duh!
Reason is the Path to God - Anon
As an occasional reviewer myself: Reviewing a book fairly is a lot of work. When reviewing a book, you're usually expected to make certain minimal allowances for it. "Am I really the target audience for this book?" "What if I wasn't an expert in this field?" And so on.
The only reason for writing a bad review is if the book is so egregiously offensive that you have to get rid of the bile it generated. This seems to be in that category.
As Gene Wolfe said (paraphrased): "Some people finish every book they start. This really impresses me. Personally, when I get shit in my eyes, I close them."
Chances are, if someone's gone to the trouble to read the whole book, it's a decent book. How many Linux books don't get reviewed here, anyway?
The Open Directory Project lists several Linux game programming sites. However, there are only six listed and two more waiting to be reviewed. If you are interested in linux game programming and building an open directory, you should apply to maintain the category. Book reviews such as this one and many undiscovered web sites are waiting for somebody like you.
Whenever you see anything entitled [pick an OS] Game Programming move along. Topics like AI, good engine design, 3d rotation mathmatics, sprites, drone scripting, etc are GENERAL GAME TOPICS and don't need a spesific OS. OS topics should be "3D graphic libraries in Linux" or "3D Hardware acceleration in linux" or "2D graphics in Linux" or "Linux Graphics Programming", etc.
Someone you trust is one of us.
Hopefully, Loki's book, Programming Linux Games will be a lot better.
Does anyone know of any early reviews of this book? It's due to be relesed in August.
-Karl
Good points, but I think things are settling out for Linux. At the least, there's no confusion about 3D; it's OpenGL. For input, 2D, and simple audio, it's SDL. Sure, there are plenty of other libraries that sit on top of these, but the same situation exists in Windows.
People tend to confuse GUI's with automation. To use your time effectively, you need to automate a lot of tasks. The modern IDE does this for you. But it's also possible to automate with Perl, Make, and shell. This may not look as glamorous but it's easier to adapt to changing needs.
Anyhow, there are lots of Unix programmers who rarely see a 'command line' - the emacs users.
Bye bye Karma.
using SDL for input, as a graphics substrate for 2D games and for OpenGL-based 3D games, etc. Throw in some coverage of OpenAL as well as generally applicable topics such as AI, Maths, and the like. Garnish with touches of the 'other side' of game development (plot, characterization, artwork) so the code monkeys understand what the writers and artists are talking about.
Result: a book teaching folks how to make games that run on Linux. And windows. And any other platform SDL, OpenGL, and OpenAL work on. If it can be pointed out to the development community that these tools are viable and easy to use, further that they get portability almost for free using them thus expanding their market for low marginal cost, more games might come out that Linux, MacOS, BeOS, *BSD, etc. could play.
Plus SDL is just cool. :-)
Only question in my mind is would O'Reilly publish a book like this; if so what animal would it be? (would a woodcut of Pac-Man work?)
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
Basically alot of the books on programming published by Prima are getting slammed for sucking. Andre LaMothe is supposed to be one of hte editors, so I have no idea how this is happening.
If you're not using gamedev.net or flipcode.com, you may want to give gameinstitute.com a try. It's mostly windows based and a bit pricey, but if there's enough Linux interest (email them, duh) then they'll probably add courses.
Peace,
Amit
ICQ 77863057
[o]_O
bzzzt! wrong!
Games have pushed this industry in every way shape and form. Next to pr0n there is nothing more important than games and in terms of hardware there is NOTHING more important.
Yes there need to be better apps but games are where it is at.
Yes the Amiga struggled without a Word, Excel but it was killed by very poor decisons throughout it's history, not by the lack of Word.
Linux MUST get games and especially network games like UT, NASCAR 4, Half-Life, Combat Sims etc, etc....
---
This
The hardware industry exists in its current form thank wholly to games. The truth of the matter is no one was ever going to need a 64MB video card running Lotus 123.
There is a current movement toward digital video/editing, made feasible by "cheap" high end hardware
---
This
I saw this in a local WaldenBooks store last weekend. I could tell just by the cover (and the thickness, no decent Games Programming book is less than 1.5" :D ) that all the book was was an attempt to sell some dead trees because it had Linux on the cover. (The posted contents of the CD appear to prove me right. MSDOS format? Hello?)
;) )
There shouldn't be a book for Linux games anyway. There shouldn't be a book dedicated to games on ANY OS. They should talk about how things work, and get them to work in as portable a way as possible, so that people can get their games in as many hands as possible, and so that they can have a book that will be beneficial to them no matter their OS (be it Win, Lin, BSD, etc.)
I suppose I'll never see another book I liked as much as Micheal Abrash's Graphics Black Book. (Not the exact title, but it's not exactly in front of me right now
HitScan
With a twinkle in his eye and a skip in his step, RMS slammed his sky-blue Chevette's rusted-out car door and turned on heel toward the MIT Zoo entrance. Today was a Sunday, and RMS had decided the daily stresses of Free Software, the GPL, and his "crazy drug habits" could go away for just one afternoon while he enjoyed the zoo.
"That'll be twenty-five dollars, sir," the lady at the admission booth said glumly. She looked at RMS expectantly.
"I was expecting this zoo to be Free," RMS stated loudly, eyes darting around to gauge onlookers' reactions. There was none. RMS's capital F had went unnoticed. "Can you ensure me that this money will not help fund--"
The admissions lady cut him off. "Twenty-five dollars, or twenty bucks with a Mr. Pibb can," the lady cut in.
With a grumble and shake of his beard, RMS handed over twenty five of his hard-earned dollars. Considering that the GPL works to unemploy programmers, one must wonder where this money came from...
By evening, RMS found himself in front of the penguin exhibit. He felt himself start to sweat, which would have been no surprise-- his thick, full, grizzly beard must be worth a thousand down comforters-- except that he was wearing only a pair of nylon biking shorts and a travel pack around his waist. He stared at his hands. What was wrong?
"AWWWK!" a nearby bird offered. RMS wheeled in the direction the screech had come from. He was met with the steely, unfeeling stares of a penguin. "AWK! Ooooh God, the penguin said AWK... lord, lord lord, it's LINUX. THE PENGUIN IS TUX!" RMS blurted out. He felt dizzy, and cold sweat now washed over his brittle, hairy chest. He looked this way and that. From nearby a bird again squawked.
"AWWWWWWWWWWWWWWWWWWWWWWWWK"
RMS ran as fast as his atrophied hippy-programmer legs could carry him, right thru a gate and into an exhibit. He realized what he had done, and before he could turn around, he heard a low, ominous sound. Like the Devil's riding mower. "MOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO" RMS gasped.
MOOOOOOOOOOOOOOOOOOOOO!!!
He was standing in the Gnu section, and it seemed these bull yaks were in rut and ready to mate with the first hairy thing with a hole in its center they found. Bad luck for RMS and his beard. Just then he felt cloven hooves push him down...
part two soon to follow...
What did the publishers expect. There is no way to discuss such a vast topic as game programming in a single volume. Perhaps if each chapter were it's own book...
there's no way this could have been a good book, really.
Sad though. it would be useful to have quality publications on this subject... I guess we'll have to wait a while longer...
--CTH
--
--Got Lists? | Top 95 Star Wars Line
I'm still waiting for the Allegro C/C++ games library to be included in a major distro. It's in version 3.9.37 now, with 4.0 just around the corner. It's a wonderfully solid and complete gaming library. Zero code changes needed to compile games on numerous platforms. Once I tried this library I never went back.
You are trolling right? I gave up on VC 6 a long time ago in favor of EMACS, when I found that the features in EMACS provided me more of what I needed than the tools in VC6. Funny, my friend Luke has gone to NetBeans, and I know a couple of people who are trying to figure out if theyt can use EMACS as the default editor in VC...
As a student of C, I found the GCC to be far more useful than Microsoft's compiler because it forces a creater distinction between C and C++. My greatest problem is that Microsoft's compiler lets you get away with many things that you should not be able to get away with (of course that explains some things, but we won't go there). I suspect that the basic problem has to do with the structure of some Windows APIs (particulalrly CDO and MAPI, forcing C++ style linking) but I am not sure.
How many times have I had a program not compile because it was missing a bracket or perenthesis? When have I seen VC tell me my parentheses are mismatched? EMACS suits my needs better providing me exactly what I need for the job.
OTOH, I know many people that are really happy with Visual Studio products, an dmore power to them, but that is a far cry from saying that the tools are far superior.
Sig: Tell all your friends NOT to download the Advanced Ebook Processor:
LedgerSMB: Open source Accounting/ERP
I doubt I'm alone in being led down the coders path by the desire to write better games than I could buy at the time.
I must have bought a dozen 'write games in..' books and found every one of them to be too light on detail, too thinly spread, and too badly written to be of use - so ended up buying a couple of 'proper' programming books and just working out the game bits later.
Personally, I think for the many folk that gave up before going to the proper books, there SHOULD be books with 'write games' in the title that start at about 'hello world' move on through 'pong' and end up somewhere about 'quake'. They'd have to do it over a few volumes, but if they were well written (like the OLD animal books) and not £80 a pop I reckon they'd be onto a winner.