Slashdot Mirror
Programming Linux Games
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.
why not write some freaking games? Duh.
EVERY single time gaming on Linux comes up we have everyone post about how easy it is to program for Windows and how much more difficult it is to program for Linux.
.02
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
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?
A feeling of having made the same mistake before: Deja Foobar
Really if you look back, Windows gaming didn't really explode until DirectX was forced upon the world. I remember all the retching and such, but honestly it really stabilized the gaming industry on the PC - ONCE it stabilized itself.
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.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
I am wondering... almost all real games available on Linux are ported (no, I do not mean those games like Tetris, Othello or GNU-chess). Only a few ones are Linux only. What are the chances of developing Linux games and hope that they will run fast and well on Windows, the main market? The problem is that if your games cannot be sold to a sufficient number of people, the game company cannot be sustained for very long.
¦ ©® ±
I bought this book and have thoroghly enjoyed it. As a rather introductory C programmer, I found it to be a helpful reference to general programing techniques with an emphasis on games. I think that this is aimed at the introductory-intermediate crowd and is basically a primer to game programming rather than a complete reference.
Again, I liked the book, but it is one that serious game programmers will probably find less than helpful.
LedgerSMB: Open source Accounting/ERP
"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.
"...today consumers have been conditioned to think of beer when they see a bullfrog..."
Even though SDL and GLUT are different things, I think SDL is a better choice. Comparison of some feaures:
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!).
only testing - sorry
You must be dumb for having your Windows crash every half hour or maybe you're using an ATI video card.
Great and everything but you need Artists to make the 3D Graphics for the game, etc. The question should be. What should the Linux OS do to attract artists?
I read a "sneak peak" of this book which John sent me as a PDF. It was good, and I'll probably buy a hard-copy. SDL has very fragmented and confusing documentation, this book shows some good examples of how to actually USE sdl for your applications.. which can be assisted by the official SDL documentation.
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.
The review stated that the book didn't go into much detail or specifics, but was more of a general overview of theory and practicum with a case-study of implementation...
:) What a great move eh? =)
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
"Just Smile and Nod." --Huck
To some extent, this is already the case.
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
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
The first two chapters were exactly perfect for me. I've done some programming with Python and some other higher level languages, but much of the way Linux and GCC were organized just sort of mystified me. So, even though Hall says that he doesn't mean to provide a tutorial, the walkthrough of using gcc, ar, creating makefiles, cvs, etc. was just the right amount of information so that I could understand what's been going on all this time. The problem with many of the other manuals for this sort of thing suffer from two problems: 1. They provide too much information (the gcc info entries) and 2. they only provide information on a specific tool, they don't wrap it all together.
:) But I wish I had seen the introductory chapters 6 months ago, it would have saved me a lot of frustrating headaches.
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
microsoftword.mp3 - it doesn't care that they're not words...
Still, there's no point giving readers a sense of wistful "What if?" if you don't have to.
Uhh, maybe he knew that real programmers will colour outside the lines, and decided to share what he thought might be a nice direction.
I just bought this book and I'm slowly working through it. I really like how the first sections show to use gcc, make, and CVS. However, it is sort of incongruous how the next chapters immediately jump into code examples that use pointers and structures.
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.
--
Long-term effects of Bush deficits
I'm almost certain that this John Hall isn't the same guy as John "Maddog" Hall. Am I right?
If you celebrate Xmas, befriend me (538
this isn't considered "Flamebait"???
I highly recommend Programming Linux Games to anyone who wants to program anything on any platform. Besides, John Hall is a really cool guy and deserves your money.
;)
-Wade
PS - John, is that good enough?
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
"I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve."
http://kotisivu.raketti.net/wadez/ter.jpg is a screenshot. No, its not a goatse.cx pic.
Heh heh. I've been using the WrinkledShirt handle in several areas for well over a year and a half now. It's just a coincidence.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
I can honestly say as a book author it is incredibly difficult to keep a work whole and cohesive and stick to your guns about 5-10 chapters into the book.
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
People may post that, but they're wrong. The ONLY reason there are more Windows games is that more people are paid to develop those games. And the only reason for that is that there are more Windows users.
Not to start (continue?) the flame war of availability of apps on one platform vs. another, but how often do people add significantly to their programming effort to port to an OS that not too many people use? You write an app for Windows, you get a potential user base of over 90% of the computers out there (assuming it functions across all the different major versions). Why add another 50% to your effort to port to Mac or Linux? ESPECIALLY Linux, with 100s of distros? You could obviously whittle that down to far fewer families, but there is still great diversity out there, which is just one more hurdle for programmers to tackle.
Of course, a good cross-platform IDE helps, but either way, it's still a lot more effort with a terribly reduced ROI. In addition, Linux users don't generally like paying for software, let alone anything that would likely be closed source. Until that attitude goes away, we will be stuck with the current situation.
I've been a professional game developer for over ten years. I've programmed DOS, Windows, N64, Dreamcast, and Playstation 2. I've used DirectX for many years. Through all of this, my complaint about game programming has always been: the tools are horrible! And DirectX (although it's a million times better in its recent incarnations) is no exception to this. Writing games is fun _despite_ the tools, not because of them.
Recently I had the oportunity to use SDL. 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"?
We've got one MAJOR problem that prevents games from invading the linux environment. The 'Out of the box' concept. Most games developped for linux, well most of what i saw, had so many freakin dependencies, installing them is one of the worst nightmare a gamer has to face. That, of course, doesn't help making games more popular under linux at all. ( I double dare anyone to prove me wrong. )
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?"
> You must be dumb for having your Windows crash every half hour or maybe you're using an ATI video card.
Or maybe he's running Windows. It is WELL KNOWN for crashing. I and another MCSE admin an NT network of a few hundred boxes, and you think Windows crashes on your home PC, just try it on a network. Brutal. We're almost positive we're gonna push the bosses to allow us to convert to Macs or BSD or Linux, at least on the server, although 98 on the desktop's no hell either unless you ghost the HD every 3-6 months religiously.
But nice astrotroll anyway.
This book is very good in my opinoin. It is a complete guide to developing linux games. It also discusses important multimedia toolkits (including a very interesting discussion of the Simple DirectMedia Layer) and teaches the basics of linux game programming. Many books don not take about this. You can learn about the linux gaming world, and how to write and distribute Linux games to the Linux gaming community.
Diplomacy is the art of letting people have your way
I tried NT on a network, a year ago, I didn't know much about NT at the time and I was able to build a reliable intranet server and a file server. Almost didn't have to touch either servers, except for patches and to add a HD to the file server. Two months ago I've left that company and if anything happens to the server they have to call me but so far everything is okay. I don't know how you make it crash. Besides, you know it's a server right? You're not installing Quake and stuff on it right? You could've mentioned BSD or Linux but Macs? oh please.
We're taking a hard look at the possibilities of Mac OX X Server. Sorry you disapprove, but we have me and another MCSE who can't easily keep WindowsNT (or 2000, which we also tested) up for the required uptime desired by management.
And don't ask what we do to make Windows crash, we're more interested in what you do to STOP it from crashing. We do *nothing* to it once it's installed, patched, and set up with network printers, etc.
Of course we don't have Quake on it. We have practically nothing on any of our servers, but the minimum required. They basically act as storage for Autocad and Microstation files and a couple for Accounting.
It's fine for a while, then BAM, we're down. Logs show nothing, nobody did anything unusual, and we're not on the net. Windows is just not as reliable as the alternatives claim to be.
I don't do much do stop it from crashing. How come the logs show nothing? How about the blue screen? If none of those are present I can only guess that some people are attempting to hack into your servers. I also suggest that you check your harddisks for bad sectors.
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.
1. The open standards that indrema was trying to push forward are an acceptable substitute for DX. In particular there is no reason to adopt Direct 3D or Direct Draw as they are redundant and less open than OpenGL.
2. I don't think the kernel group has a problem with MESA-GL, or OpenAL. Whether or not the kernel group wants to be directly involved is probably not that important. For e.g., see KDE, Qt, or Gnome.
3. The game market is actually a vitally important cornerstone of the desktop market (which Linus now realizes is the remaining frontier for Linux.) The reason Microsoft created Direct X was to kill *DOS* (prior to this people still booted to DOS to play many of the games that were available at the time.) It will be the same for Linux. If they was to even at least seriously attack Windows, they need to hit them hard in the games/entertainment area of computing.
anytime any moderator sees the words offtopic they moderate it so. twice in this case.
As a graphics programming enthusiast, I really couldn't have asked for more. Kudos to Sam!
rmathew.com
Nope, Windows can and will crash without warning, even Win2000 (although it general slows down to a crawl prior to actually dying).
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
My god carries a hammer. Your god died nailed to a tree. Any questions?
Same here, some laptop users have managed to crash their Win2k Pro machines but it's never happened to me. The worst I was able to do was having my machine freeze from time to time because of lame ATI Radeon drivers. I actually had to install Windows XP to avoid installing the ATI drivers.
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.
You can buy this at a reduced price from Tux Games
Tux Games. Your complete source for native Linux games.
Has anyone noticed that the Linux community asks questions like, "What can we do to attract (programmers, artists, gamers, architects, etc.)?" and "What do we need to improve...?" and "What do we need to work on?" various questions like that. While I'm sure Microsoft asks questions like "What can we do to make more money?" or "What can we do to lock them into our Operating System and software?"
Makes you wish that people would realize that the Linux community thinks a lot about the rest of the world out there, compared to some of these large companies.
I request that you all go and find a game you like at lokigames.com and buy it. Support them, we need more support for Linux gaming, let us get some real game programming on Linux and show them what our community can do.
Now start coding and don't forget about Loki.
Question everything.
And thought it was really good.
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.
I gots ta ding a ding dang my dang a long ling long