Programming Linux Games 103
| Programming Linux Games | |
| author | John Hall |
| pages | 415 |
| publisher | No Starch Press |
| rating | 7.5 |
| reviewer | WrinkledShirt |
| ISBN | 1-886411-49-2 |
| summary | Well-written guide to a wide range of game-writing tools for Linux, but not a definitive reference work for any single task. |
Introduction
The potential for linux gaming has really exploded in the last couple of years. In many cases, the potential has been realized -- Unreal Tournament, SimCity 3000, Tribes 2, Quake 3, Alpha Centauri, and many other successful Windows titles, have all been brought to Linux, with Loki leading the charge. Judging by the bottom line, there's a definite shortage of true cash-cow success stories in this enigmatic part of the industry, and hence, a shortage of good reference material for naive people hoping to produce that next cash cow.
However, we've reached such a point of critical mass of knowledge and technology that books had to start appearing sometime. So, despite the fact that there's no overwhelming market demand for Linux games and a high ratio of hobbyists to dedicated game developers for the OS, here we have a book aiming at taking amateur Linux game development to the next level.
However, much of the technology out there for game programming in Linux is still heavily in development, with many of the APIs and libraries still a long way away from a 1.0 release. Allegro and Clanlib are a couple of exceptions to this trend -- both are popular APIs that sadly don't get much more than a passing mention in the book. Their sexier counterpart, Sam Lantinga's SDL, gets a fair amount of treatment (no surprise there, considering John Hall was the lead author for a team based within Loki) -- but even this fairly feature-complete library, which Loki uses to port its games over from Windows, isn't explored in its entirety.
Instead, there are also crash courses in BSD sockets, package management, TCL, the framebuffer and various sound APIs, and what we end up with here is the consummate cookbook, a jack-of-all-trades-and-master-of-none tome that introduces us to a wide variety of Linux gaming topics while stopping short of being a definitive reference for any of them. Such is John Hall's work, an interesting, wide-ranging introduction to game programming for an operating system that few believed was capable of it not too long ago.
John Hall, an experienced game developer, participated in Loki's Civilization, Call to Power game hack, and is currently working for Treyarch developing that company's Spider-Man title for the PS2.
The Good
As far as cookbooks go, this is a good one, and there isn't much concerning Linux game API programming that isn't touched on. There's an ongoing case study (Penguin Warrior) that is developed over the course of the book. Each chapter introduces a fairly deep concept, gives a decent function reference related to the concept, then incorporates the knowledge into proof-of-concept code, and then uses the new-found knowledge to enrich the case study. The tone is straightforward and the execution is solid. The final game works well enough to give confidence that the reader could take the knowledge in this book and apply it to his or her own project, either to add new features or re-think old ones.
The book is also well-written -- the sample code is extremely well-commented and good error-handling is in place. He makes no assumptions about the knowledge of the reader, dealing with such introductory topics in Linux programming as vi vs Emacs, the FSH and make, although he never gets annoying or patronizing. *cough cough* LaMothe *cough*
Individual chapters stand out as being great introductory resources for material that doesn't have much in the way of documentation. The important aspects of SDL get good treatment in one complete and comprehensive unit. There's also a thorough chapter on audio programming, comparing and contrasting OpenAL, OSS, ALSA, Ogg Vorbis, and ESD (among others), and all this after showing off SDL's sound capabilities one chapter earlier. Many of the pitfalls associated with each of the different technologies, as well as the pitfalls of sound programming in general, are covered here. It's a great jumping-off point for those who don't know much about the audio end of things.
There's even a really neat chapter on incorporating TCL script interpretation within a program written in C. For anyone who's had trouble throwing together their own text parser for initialization scripts, or who's fed up with the constant recompiles needed when tweaking for the most arbitrary of changes of the game's AI, the information in this chapter is a godsend. In the Penguin Warrior case study, it's almost spooky how effective TCL turns out to be in making the computer ship chase and evade the human player.
Finally, I want to reiterate the effective use of the case study, Penguin Warrior. Having seen the way other game programming texts handle using samples to illustrate game programming concepts -- which is often a mish-mash, to say the least -- the way this book approached the issue is refreshing: there's one major project, and each chapter brings us closer to that project's completion. The code works as intended and goes a long way to convince the reader that the libraries and techniques explored in this book are near-commercial-level quality. (Networked games turned out to be choppy on my machine, but that was the only real black mark I could find in the program's execution.) If nothing else, John Hall deserves a good deal of thanks for proving that game development on Linux is a realistic and rewarding endeavor.
The Not So Good
At times, the generalist nature of the book left me wondering if Hall couldn't have gone just a little bit further in some of the topics. There's a decent enough synopsis about deployment using Loki's install tool, as well as packaging in general, although nothing related to the Penguin Warrior game itself, so we don't get to see the theory in practice as much as it could have been. Also, he teases us by early on by starting with the compiler, moving to the make utility, talking a bit about package management, and then mentions automake, but he stops short of really explaining how to bring that into an existing project. Considering all the fun little dependencies needed for multimedia programming in Linux, this would have been a valuable bit of information for anyone not used to deploying on the platform.
Another instance of this so-close-yet-so-far approach occurs when he talks about incorporating Mesa into an SDL program. He tantalizes us with a code sample illustrating how to use the SDL as a replacement for glut, but that's all -- the material doesn't really get deep enough to convince readers that a 3D neophyte really can abandon glut for the SDL, particularly when many OpenGL reference materials out there rely heavily on glut as a teaching aid for windowing and other utility functions. Loki primarily used SDL to handle its 3D utility programming, so at least we know it's possible, but given the exploding popularity of 3D games it's too bad this wasn't covered more.
It's sometimes hard to tell exactly who the book is intended for. The introductory chapters include discussions on topics such as the different gaming genres out there, despite the fact that game programming hopefuls who don't know that Quake is a first-person shooter must make up a really narrow audience. Also, it's almost enough to give one whiplash to see how quickly he dives into using ioctl() when only a couple of chapters earlier he was explaining the basics of using gcc. Next up soon after that? Strap yourself in, we'll be writing straight to /dev/fb0! It's almost comical to think about how much dangerous knowledge a newbie's been given over the course of the book. Still, like I said earlier, he never talks down to the reader, who because of this might feel compelled against better judgement to be whisked along into subject matter that really needs other support material to be of any real use.
Hall's a humble enough guy, which is great insofar as writing style is concerned, but in one of the last chapters, he starts questioning some of the choices he made while coding Penguin Warrior throughout the book. Specifically, he says he probably should have used C++ instead of C, Scheme instead of TCL, and UDP instead of TCP for the networking, and this is cold comfort for people who would have hoped that the author would have picked the best plan of attack from the beginning. That said, C, TCL, and TCP are appropriate choices due to the simplicity of execution and the fact that they introduce useful techniques from a design point of view. Still, there's no point giving readers a sense of wistful "What if?" if you don't have to. It also highlights that this book is more a beginner's API reference than a game programming book per se.
To take that point further, there also really isn't much in the way of abstract game programming theory. This book could have really distinguished itself as special if some content related strictly to game development was here. There's a mention of Gamasutra here, a method of quick division there, the equation of a distance from a point to a line thrown into the mix, and that's pretty much all there is. Topics not really covered include optimization, pathfinding, and cracker-proofing your code, and what is talked about on the subjects of artificial intelligence design, collision detection, and physics is all rudimentary ... For coverage on these sorts of topics, you'll have to look elsewhere.
Finally, and this is really not the fault of the author or the book, but one wonders if the time was right for much of this material -- or, at the very least, its highly generalist approach. DRI is making its presence felt, the various audio APIs out there are improving all the time, and the LSB is coming along nicely, but until there's a proven and stable multimedia base to work from, no definitive guide can be written, and this sort of organized dogpile is really the best we can hope for with so much stuff to cover. The SDL is a top-notch library for graphics programming, and it's likely an entire book could have been spent strictly on graphics programming using it, and the depth that such a book could have attained far surpasses what we're given here. Plus, in a year from now, who knows where any of these sound APIs will be? Of course, these might prove to be just esoteric issues in the grand scheme of this book.
Conclusion
Despite the criticisms I have of this book, I really don't want the message that is conveyed here to be anything but positive. There's a lot working for this book -- the chapters on SDL, sound programming and incorporating TCL and C are excellent, and will be especially helpful for people who are novices in these areas. Considering the alternatives (hitting dryly-written online docs or constantly shaking your Google to see what falls out), this book is a very attractive option. Programming a fully-functional multiplayer game would probably require more effort than might be suggested by the brevity of the chapter on socket programming, but that chapter is a solid introduction as well. The book as a whole is well-written and succeeds for the most part in its endeavor to make the best of a chaotic situation. I'd recommend this book to anybody who appreciates the messy-kitchen style of learning, or to anyone with decent hacking skills who just needs to break the ice when it comes to the Linux game APIs. And even though it gets slightly schizophrenic in its attempt to be both an introductory text and a definitive reference, this is the sort of book that could kickstart a new movement in Linux game development.
Table of Contents
(exploded version here)- The Anatomy of a Game
- Linux Development Tools
- Linux Gaming APIs
- Mastering SDL
- Linux Audio Programming
- Game Scripting Under Linux
- Networked Gaming with Linux
- Gaming with the Linux Console
- Finishing Penguin Warrior
- To Every Man a Linux Distribution
- Glossary of Terms
- Bibliography
Related Links
Sample Code
No Starch Press
Loki
SDL (List of SDL games)
OpenAL
DRI
Mesa
libsndfile
Gamasutra
You can purchase this book from Fatbrain.
Instead of writing a book (Score:2, Funny)
Re:Instead of writing a book (Score:4, Insightful)
might spark some interest? (Score:5, Interesting)
Until there is some sort of Linux-DX package I really don't see gamers/coders switching over to Linux. Q3 failed pretty bad (mostly due to Linux gamers grabbing the Windows version AFAIK), Loki is going under (Warez, non-interest, etc), and the fact that 3D is a pain in the ass plus all the other problems.
I am glad that someone spent the time to try and teach others but I doubt that there is a large group seriously interested in it.
Just my worthless
Re:might spark some interest? (Score:2)
Windows programmers, in general, dislike DirectX. It is standard, and it is well-supported, and it has the features that are needed, but it is poorly designed. It has improved over the years, but even using DirectX for 2D graphics is significantly more painful than it should be. SDL, even under Windows, is much preferable. The mistakes of DirectX, especially its reliance on COM, should not be propagated to other operating systems,
Re:might spark some interest? (Score:1)
-- Brian
Re:might spark some interest? (Score:3, Informative)
A. It pointlessly complicates the interface by bringing COM into the picture.
B. It makes it difficult to access DirectX from the language of your choice. Not all languages have COM support.
Re:might spark some interest? (Score:1)
A. It pointlessly complicates the interface by bringing COM into the picture.
But COM isn't "pointlessly complicated". It provides a necessary function (OO components). Are you saying that components are not necessary in graphics programming? Or are you saying that COM is just inherently "pointless"? If the former, I'm curious why; if the latter, I think you're just wrong.
It makes it difficult to access DirectX from the language of your choice. Not all languages have COM support.
The whole point of COM is to enable language-independent OO APIs. Granted, not all languages support COM, but is there a decent OO alternative that they should have used instead? Or are you advocating a plain C API instead? Personally, I find most C API's hopelessly antiquated when OO approaches like COM are available.
-- Brian
Re:might spark some interest? (Score:1)
Windows programmers, in general, dislike DirectX.
Um... not quite. The first six versions were horrible... but DX 8.x is a dream to work with... Only a few guys at our shop dislike DX, and they're totally Anti-MS-Anything, so their opinions may be tainted. ;)
SDL, even under Windows, is much preferable.
I've never met a professional who actually considered SDL viable.
Re:might spark some interest? (Score:1)
MFC code? it's HIDEOUS! I can't believe people
make a living writing that kind of garbage
Yes, but with MFCs development environment you hardly have to write anything at all, which is probably the only reason why anything is produced using MFC.
I'm not sure a DirectX type package is required for Linux so much as a GUI IDE (Integrated Development Environment) that makes writing and developing such programs relatively simple. Then, hopefully, this will cause games developers to move over or at least port onto Linux.
Re:might spark some interest? (Score:3, Insightful)
This needs clarification.
Some Windows programmers want to try to code for Linux. They realise that before they start you have to know what a makefile is, possibly learn automake/autoconf, command line compiling and debugging. This has scared more than one windows programmer. Some of them need a full featured IDE if they are going to touch Linux.
I'm not talking about every win coder here, more the general attitude.
I don't for one minute think that the libraries available in Linux is any worse then the libs in Windows. But those "need-to-get-the-shit-going-now" programmers never makes the point to actully use them.
What I think is needed is a good IDE for the persons that prefer them. KDevelop and Anjuta is looking good but possibly not quite yet up there with Visual Studio.
If you have ever programmed with SDL I can tell you that a programmer would have to understand much more tricky stuff than that if he want to be in the bussines. I'm not a game programmer myself but I have used SDL to port a DOS game once. It took a couple of hours to grip the basics. Not much if you planning a carrer on game programming.
Re:Ask Mac users about it (Score:1)
It doesn't take another 50% investment to target another platform. All your database work is already done for all platforms, all your music, etc. It's been awhile since I've seen the numbers but it's really only about 5% more to port to Mac.
Of course, the worse the original work, the harder it will be to port. Most PeeCee Windoze game coders have the programming skills of a retarded duck. At one shop I worked at, the idiots didn't even know the C Standard Library! I'm serious, they wanted to know if they had to write fopen() and printf() to port to Mac!
Of course PeeCee programmers are ignorant: look at their OS of choice!
-toddhisattva
(Full Tilt! 1 & 2, Total Annihilation)
Re:might spark some interest? (Score:1)
Also, what was so good about Visual Studio, i thought it was rather poor, there is much better for Windows than VS (Dev C++ is my personal favorite when i am working under Windows). The only thing that VS offers that it offers best is Visual Basic and we all know that VB isn't a real programming language now don't we
Also, on a side note i find Windows a bit more irritating to write for than Linux/Unix. (actually a bit more irritating in general, but that is a different story)
Re:might spark some interest? (Score:2)
As a long-time Windows gamer who recently switched to Linux, I recently ordered 3 titles from Loki to run on my reasonably-vanilla RedHat 7.1 system (Q3 Arena, SimCity 3000, Myth II). I assumed that in the rock-solid Linux environment, I'd be up and playing in minutes.
Foolish mortal.Q3 runs like molasses for no discernible reason, and SimCity and Myth won't even start. Other than the nifty metal Q3 box, I don't have a lot to show for all this.
Now, I'm no genius, but I managed to load Q3, Half-Life, plus all of their point releases, patches, expansions and several major mods (including Team Fortress Classic, Rocket Arena 3, Quake 3 Team Fortress and so on) onto my former Windows box without incident. The question of looking for support never really came up. But trying to resolve conflicts in Linux is a nightmare. Who do I ask for help, with Loki in shambles?
Re:might spark some interest? (Score:2, Informative)
Loki support [lokigames.com]
Re:might spark some interest? (Score:2)
-
As a long-time Windows gamer who recently switched to Linux, I recently ordered 3 titles from Loki to run on my reasonably-vanilla RedHat 7.1 system (Q3 Arena, SimCity 3000, Myth II). I assumed that in the rock-solid Linux environment, I'd be up and playing in minutes.
It took me about 2 hours to figure out how to install nVidia's GLX and kernel drivers, and after that Quake III was a breeze to install... load X, login as root, rin the shell script, click a few buttons... and it was done. It even made a menu item for me in KDE. I get virtually identical framerate to Win98 on the same hardware (yes, I'm using updated drivers on both OS's, and Win98 is about 1-2 FPS faster, but Quake hangs the system occasionally under Windows. Not under Linux)Foolish mortal.Q3 runs like molasses for no discernible reason, and SimCity and Myth won't even start. Other than the nifty metal Q3 box, I don't have a lot to show for all this.
What Linux REALLY needs is more high-quality drivers like nVidia provides.
Programming ease... (Score:2)
Didn't we already have a review of this? (Score:1, Offtopic)
The only games I care about are Roguelike games, like NetHack, Larn, uMoria, Omega. We could use a few more of these.
However, I'm probably not going to be in much of a game playing mood for a while, considering yesterday. Fighting, blowing things up, killing, etc., just doesn't do much for my spirit or ego in the face of such reality.
I'll probably just go on bike rides for a while. How about a book on managing a bicycle with Linux? I'm planning to get a GPS and interface with maps and do profiles of my rides. Any good maps, like DeLorme, for Linux?
Re:Didn't we already have a review of this? (Score:1)
Games and Linux, isn't that what my Windows is for (Score:5, Insightful)
If Linux really wants to move forward with it then I see a few choices.
1. Write a call level capatible equivalent to DX
2. Write an API with official support of the kernel managing group.
then again, perhaps they should leave the games to Microsoft and try to be all the business they can be.
Re:Games and Linux, isn't that what my Windows is (Score:1)
"then again, perhaps they should leave the games to Microsoft and try to be all the business they can be."
who do you mean when you say "they"? Do you mean Linux programmers? That would seem to be a narrow view of what the linux community is. It's very diverse. A lot of them are working on different things, and I certainly think it can be more than just "all the business they can be."
Games is NOT what windows is for. It's for crashing my computer every fricken half hour, DX or no DX. Once gaming on Linux improves, I'm dumping Windows altogether.
Re:Games and Linux, isn't that what my Windows is (Score:1)
Re:Games and Linux, isn't that what my Windows is (Score:1)
Re:Games and Linux, isn't that what my Windows is (Score:1)
I don't think that using Mac OS X Server is a wise decision. Go ahead but don't say I didn't warn you.
Re:Games and Linux, isn't that what my Windows is (Score:1)
I've been working with networks for more than a decade - in fact, I manage a couple of hundred Win machines right now - and random crashes happen every day. Not many, since I tend to hunt down those that install their own software, but Win *just isn't stable*. It's a 'shit happens' OS, and after trying to find a problem with various networks for years you eventually come to realize that *Windows itself* is the problem.
Especially when you run a Linux network side-by-side with the Win network and see how little maintenance it requires in comparison, when properly set up. I haven't seen a Linux crash now in *three years*. This despite some rather interesting instances of 'imaginative user intervention'.
Max
Re:Games and Linux, isn't that what my Windows is (Score:1)
We're still running on NT4 servers and never really had problems. The only problem I can recall is a hard disk failure, that was like 5 months ago. Maybe it's the fact that we're only serving 300 users? I don't know.
Re:Games and Linux, isn't that what my Windows is (Score:3, Interesting)
1. Minor quirks aside, OpenGL is the same on any platform. OpenGL games can usually be ported to Linux with relatively little effort. Although GL has recently lost some ground to Direct3D, hopefully the OpenGL 1.3 specification will improve its acceptance (1.3 was intended specifically to make GL's model of operation more compatible with Direct3D).
2. DRM (support for DRI (3D acceleration)) and fbdev are accepted kernel-level interfaces. You really don't WANT something like SDL or DX in the kernel -- that's just bad design. Much better to use the kernel for minimal hardware interfacing code and leave the rest to userspace, which is exactly what DRI and SDL do.
There's really nothing stopping anyone from implementing a DX-compatible API for Linux on top of the provided kernel services, and in fact WINE is working on just that. I'd rather use SDL myself, though; it's simpler and much lighter than DX, and still has just about everything you need for game programming.
Linux will never be a better Windows than Windows, nor do I think our role as developers should be reduced to simply trying to copy MS. We can do better, even if it means breaking compatibility.
For the record, SDL is a highly portable API. It works on Windows, Mac OS (incl. OS X), BeOS, and just about every modern UNIX.
-John
Linux game programming... (Score:2, Interesting)
Re:Linux game programming... (Score:2, Informative)
If you develop a game using SDL and if required OpenGL, then it will run just fine on Windows, probably faster than it goes on Linux. Windows has better support for accelerated 2D graphics and the OpenGL drivers are much better supported by the manufacturers. There are very few reasons for using unportable OS features as SDL can do all the tricky cross platform stuff for you, and is available for every platform under the Sun.
Re:Linux game programming... (Score:2)
If you design carefully, you can end up with most of your code completely independent of the platform it runs on.
I liked this book (Score:3, Insightful)
Again, I liked the book, but it is one that serious game programmers will probably find less than helpful.
GLUT vs SDL (Score:2, Informative)
SDL:
1. Direct framebuffers (as opposed to pure OpenGL)
2. OpenGL
3. Timers (realtime systems)
4. Sound (but external sound systems can be used)
GLUT:
1. OpenGL
2. Timers?? (probably)
Direct framebuffers and sounds don't belong to GLUT.
SDL combines different features into a nice packet while still allowing use of external resources. GLUT forces system to be purely OpenGL based, while SDL also allows using direct framebuffers. You can use external sound systems with both of them. I don't know about timers in GLUT, but at least SDL has them (I like them in SDL!).
Re:GLUT vs SDL (Score:2, Informative)
One significant advantage SDL has over glut is that it does not take control of the main application loop. This gives you lots more flexibility. I know many Windows programmers who use SDL instead of glut for this reason, among others. This combined with the extra portability and utility features provided by SDL make it very attractive. Long live Sam Lantinga.
Re:GLUT vs SDL (Score:2)
Note that I don't mean any of this as any kind of personal attack against Mark Kilgard (GLUT's author). GLUT is fairly old, and I'm sure many of its quirks and apparent shortcomings are due to the number of operating systems it has been designed to run on. It's the least common denominator situation.
Artists? (Score:4, Insightful)
Re:Artists? (Score:1)
There are basically only two packages which are taken seriously in 3D modelling for games, Maya and 3D Studio Max. Maya is available for Linux, but costs more than a house. 3D Studio Max has most of the market because it is so much less expensive, and it is nearly impossible, and probably not desirable to persuade 3D Studio users to use anything else.
When it comes to attracting 3D artists to Free Software or Open Source projects, the problem is even harder. Most artists have little understanding of the hacker ethic, and are protective of the copyright on their work. However, you should not be disheartened. I have very little artistic talent, but have found that I can create quite passable looking models using Blender. Blender is quite widely criticised for its interface, but I found that the interface is extremely powerful once learned, and is no more difficult to learn than vi or emacs. Any capable coder should have no problem with it once they get past the initial frustration.
Re:Artists? (Score:1)
Re:Artists? (Score:2)
Exactly what it's doing. Linux is taking over the animation market, why? Because artists are more productive [linuxjournal.com] with Linux.
OK there's more we can do: keep focussing on making the gui interface better, port more tools, keep improving the rendering quality, dual head support, etc., but believe me, artists are not dummies. Artists use the best tool, artists are willing to put in the effort to perfect their skills to use that tool.
I read it, not bad. (Score:2, Interesting)
One major flaw of this book, as of the copy I recieved over 6months ago, is that all the examples assume the developer is using a little-endian processor. I do the majority of my programming on PowerPC and was sorely dismayed by this.
Re:I read it, not bad. (Score:1)
-John
Re:I read it, not bad. (Score:1)
If it works now, great.. I'll probably pickup a copy once I have the cash
The NOT-SO-GOOD is great! (Score:3, Insightful)
Exactly what BEGINNING or aspiring if you will,
programmers NEED to develop their knowledge base.
ALSO!!! This sets the man up for a sequel...or someone else who knows the specifics and detailed aspects of the APIs etc...thus he gets royalties on TWO book
Personally I feel he should hook up with RedHat or Suse(take your pick of Linux Dist.) and bundle his book with their packaged products =)
*shrugs* Just a thought.
--Huck
Lack of Game Programming Theory is OK (Score:2, Interesting)
If someone really wants Game Programming Theory, they can find it elsewhere or even within themselves. This is a fairly wide-open topic, and a deeper coverage of these topics might have been interesting, but in the end, it would have made this book less focused on the main objective of this book: To show people how to program games in the context of Linux
I bought this book and... (Score:3, Informative)
As far as the games/SDL part of the book, I don't have much to add since I haven't gotten that far yet
Bryon
There oughtta be a newsgroup for the readers (Score:1)
Anyway, it'd be nice if there was a newsgroup or a BBS for people reading this book. I, for one, haven't had the easiest time getting SDL working.
Maddog? (Score:2)
this book rocks (Score:1)
-Wade
PS - John, is that good enough?
Re:this book rocks (Score:1)
-John
I smell Conflict of Interest (Score:3, Funny)
WrinkledShirt reviewing a book from No Starch Press?
/. book review to shamelessly promote your product."
Come on now. Not that it's not a good book, it may be, but let's have reviewers without a vested interest, so as not to give the "impression of impropriety", or should I say the "impression of using a
snort (Score:1)
As an author... (Score:1)
While it may not be the greatest idea to say in a later chapter this project might have been better done differently it certainly is not a fault. As an author I constantly revise and revise and have to stop myself because I am on a deadline and the reality is with a deadline the work won't even come close to perfect and you have to pick your battles wisely.
It is HARD to write so that you are not talking down to a reader. It is HARD to keep on subject and make sure there are no gaps in a readers knowledge before skipping on the the next subject. It is hard to peg an audience and choose what skill level readers will have with "xyz things". You want a book to sell and sell well, so you want to appeal to as wide an audience as you can. You also don't want to seem to "boring" for your advanced readers or to "complex" for your new readers.
Writing is such an art that it is difficult to appreciate some of the time without having written large works yourself.
I have read so many books in my career as a writer/developer. I can say that now I reread books and look at them completely differently. While less critical in general, I am still more appreciative of a well written book. I think one of the finest examples of written books on programming are by Bruce Eckel. His writing style is refreshing and admirable to me. He has a LOT of experience actually teaching and helping people learn.
Anyhow to my main point, writing is difficult and authors tend to strive for perfection and a wide audience and that can some of the time affect how much certain groups of readers take away from the end product. A good author can let readers of any skill level take away a lot.
Jeremy
Professional game developer says: There is! (Score:3, Insightful)
Recently I had the oportunity to use SDL [libsdl.org]. It took me less than five minutes to have a program running which displayed a 24-bit BMP, full screen, on my Linux box. About fifteen minutes later, I had put together a small Tetris clone. I was stunned. SDL rocks the hell out of anything I have used on any other platform - and that includes five years of developing on Windows, and using the $20,000 Sony PS2 dev kit.
Best of all, SDL is portable to all other UNIXes, Windows, BeOS, MacOS 9, and Mac OS X. I can't vouch for how well it works on those other platforms, but if it's as easy as I suspect, then any game developer should be in heaven using it.
So perhaps by saying "there is no DirectX equivilent" you mean to say that "there is no graphics/input/sound/3D toolkit for Linux which sucks balls"?
Re:Professional game developer says: There is! (Score:1)
No kidding. I was nearly pulling my hair out when I was trying to get things working under both X11 and DirectX, and had all sorts of messy implementation layers and whatnot, and the ugliness of it all still makes me physically cringe.
Then I tried SDL out, and I think the first words out of my mouth were "SOMEONE GOT IT RIGHT!" Had the whole layer ported to SDL in about 30-40 minutes and it worked like a charm. My only qualms now really only deal with poor file i/o (no directory support) and lack of decent WM functions.
Rereading that makes it sound like a religious experience, or a really horrible advertisement. May have been. ;)
The main complaint I hear about a lack of a DirectX equivalent is that sound has quite some ways to go, and there are no rendering functions for SDL. Audio is looking more and more like OpenAL will be the way to go, and if I ever finish my current work [sandwich.net] I'll probably try to work on rectifying the renderlib. (Like I'll ever get around to that. Heh.)
Linux and games, i don't know... (Score:1)
We'll have to realize someday that reusing common APIs for our projects is great, but sometimes the wheel has to be reinvented to prevent complications and a shitload of dependencies. Anyway if the wheel had not been reinvented, we would still be traveling in wooden chariots. So what's the point of reinventing the wheel? MAKE IT FREAKIN BETTER!
Of course, we could always make us a full standard DX clone and try the gaming experience again, however we would still have freakin problems with hardware support and all that shit.
A small opinion in a small world, here's another one for a short conclusion:
Linux = 'for workin';
Windows = 'for playin';
BTW: I have yet to see Tribes 2 run correctly on Linux. That maybe is because i tried running it with a Matrox Card or just because i have no clue on how to configure DRI properly, but it still points back to the beginning of my comment: "Where is the out of the box?"
Linux Gaming (Score:2)
OpenGL and SDL (Score:1)
As a graphics programming enthusiast, I really couldn't have asked for more. Kudos to Sam!
Available at Tux Games (Score:2)
I bought this book... (Score:2)
All the detail you need is out there on the web, but often, the detail is not what you need.. you need a broader overview, and a reasonably complete, heavily documented example so you can make your own decisions and avoid the obvious problems.
And thats exactly what 'Programming Linux Games' provides.
I recommend this book to anyone looking at doing games or multimedia programming under linux, and the chapters on sound are particularly interesting.