Dev Diary: John Carmack on RAGE for iOS
bethblog.com
bethblog.com
Quoted for truth.
I learned C++ during the Meyers/Sutter era. Then Andrei Alexandrescu came along and I had Boost libraries sprinkled all over my code. My beard is growing grey and these days my C++ looks more and more like straight up C.
I consider myself a decent programmer but I have more trouble reading template heavy C++ than I do haskell code. To me, restrained C++ means keeping the unreadable bits outside the code base and isolated in their own library, like Boost :)
A popular thought is that any given team or company should pick a particular subset of those styles -- and perhaps a subset of C++'s features -- and use them to the exclusion of others.
You don't need std::vector if you don't need dynamic memory allocations. Game programming and systems programming is a whole lot different than web or desktop development.
For games, you create a memory budget up front. You decide how much memory sound, textures, models, AI will consume up front and then statically allocate that memory up front. http://gamesfromwithin.com/start-pre-allocating-and-stop-wor...
You can statically allocate at the start of a game, level, and frame.
From the original article: OpenAL appears to have a limit of 1024 sound buffers, which we bumped into. We could dynamically create and destroy the static buffer mappings without too much trouble, but that is a reasonable number for us to stay under.
It also sounds like Carmack is loading an entire level as a memory mapped file and then doing reads into specific indexes within the file.
Take a look at the source code that id has open sourced. That's the best way to get a feel how this style of development works. I believe RtCW is their last release. ftp://ftp.idsoftware.com/idstuff/source/ http://github.com/monoid/rtcw-rebirth
I also have never had a need for any formal "design patterns", as every time I've encountered a problem for which it turns out there is named pattern in the books, a few moments thought about the problem has always led me to discover the solution myself.
Now, it could be that this means I'm some kind of programming genius. I wish that were true, but alas I think it is not so much a reflection of how good I am, but rather how mediocre many programmers are today.
IMO, good C++ code is better than good C code, but bad C++ can be much, much worse than bad C code. 10:17 AM Oct 6th
I wish C++ had a "functional" qualifier to enforce no global references or side effects. 11:16 PM Sep 21st
Reading More Effective C++. I have grown to appreciate at least some uses of most C++ features, but I still don't buy in on exceptions. 10:26 PM Aug 13th
Exceptions do have possibly deleterious effects on performance, but then, you can just be judicious about where you use them. Exceptions are at least appropriate for catastrophic failures like, "Oops, the game just crashed," or, "Your network connection died." Thinking about manually unwinding out of a game-over failure like that makes me grimace.
Sigh, game programmers. :)
Games, especially the simulation, must be deterministic. An exception would most likely destroy determinism.
The simulation/AI is a big, hairy, ugly set of if/else and switch statements anyway. Adding extra error checking is not an extra burden.
The visualization sends asynchronous commands from the CPU to the GPU. The error condition won't be known right away. Querying the GPU will cause a flush of your command stream and ruin performance.
Dynamic memory allocation is reduced to a minimum during a frame so you don't get out of memory errors. Strings are allocated in a pool. Network sockets, file handles, and other performance intensive resources are not created mid-frame.
Exceptions are not a win for games. It is usually best to run the entire frame and then check for errors all at once at the end.
For the most part, I agree, which is why I said they're probably only appropriate in games when used judiciously, e.g., for fatal errors.
void Horse::ImOnA()
{
try
{
Giddyup();
if (IsDead())
EX_ERROR("Guess I wasn't on it.");
if (IsFlippingTheFuckOut())
EX_WARN("Safety hazard! Get the f outta the way!");
Feed();
}
catch (CException& ex)
{
ex.Process("Horse::ImOnA() - ", NO_THROW);
}
CleanupAfterHorse();
}
If the horse is dead, then "Horse::ImOnA() - Guess I wasn't on it." will be printed to the console.If the horse is acting like my mother, then "Horse::ImOnA() - Safety hazard! Get the f outta the way!" will be printed to the console.
Etc.
So this is a nice way to report errors. It's basically a typed goto. But don't you dare try to use it for flow control! >:(
You can report various "levels": EX_DEBUG, EX_WARN, EX_ERROR, EX_FATAL
ex.Process() checks what kind of exception it is. And for EX_FATAL, for example, it will terminate the application (after writing the message to a log file).
It's quite nice to use exceptions in this way, because you rarely ever need to even think about making your methods "exception safe" at all.
Exceptions don't just add an overhead when they're thrown, they add overhead for every function call. How else would the exception-handling runtime know to unwind the stack to the correct addresses? It is this performance degradation that we avoid. Why? For the PC, it doesn't really matter. The XBox360 doesn't handle the performance hit very well. The compilers for the Nintendo DS (edit: and the Wii) don't even support exceptions, and the PSP is so crazily architectured that things like floating point numbers or exceptions can cause a framerate to drop from 300 to 12. I've not worked on the PS3. You must understand that these consoles and handhelds are designed very differently from PCs, and are never as powerful.
We do check for errors, we just stay away from exceptions. And dynamic casting, when we can (the DS does a freaking string compare against the vtable!).
With unwind descriptors/exception handling tables, which can be stored in a read-only segment of the executable and don't need to be paged in until an exception occurs. They have no runtime performance cost until an exception is thrown.
Unwind tables are the default exception model on most modern gcc C++ targets. They're also the default exception model in Visual C++ x64, at least.
c.f.:
http://stackoverflow.com/questions/318383/exception-handling...
http://msdn.microsoft.com/en-us/library/1eyas8tf(VS.80).aspx
I do miss smart pointers, but on the other hand, dealing with malloc and friends keeps me honest about what really needs to be written in C.
But I had to solve one interesting problem using some recursive definitions and code, and discovered that once I "freed" the code from classes (made them C functions) I was able to express it properly -- just having them as members prevented me to see that the solution is much more obvious when you actually use plain pointers and don't think about the same "object" even during the life of the function. Add to that in the member "this" can't be null.
When you need real expressiveness, C can't be beaten. C++ syntactic sugar helps sometimes, but limiting to it is... limiting!
Or do you write your own containers
This site requires cookies. Please enable cookies and try visiting this site again.
is this a joke?
"This is the perfect setup for a quintessential first person shooter game play experience — you pick your targets, aim your shots, time your reloads, dodge the bad guys, and try and make it through to the end of the level with a better score than last time. Beyond basic survival, there are pickups, head shots, and hit streak multipliers to add more options to the gameplay, and there is a broad range of skill levels available from keep-hitting-fire-and-you-should-make-it to almost-impossible." -JC
(off to go look...)
Sure enough, part 15 should prevent this app from ever getting to the public (see http://photos.appleinsider.com/App%20Store%20Review%20Guidel... ). I doubt Apple has the eggs to tell Carmack no. Time to see if Jobs' moral views outweigh his greed. (edit: BTW, I think his greed will win)
Apps portraying realistic images of people or animals being killed or maimed, shot, stabbed, tortured or injured will be rejected
Apps that depict violence or abuse of children will be rejected
"Enemies" within the context of a game cannot solely target a specific race, culture, a real government or corporation, or any other real entity
Apps involving realistic depictions of weapons in such a way as to encourage illegal or reckless use of such weapons will be rejected
Apps that include games of Russian roulette will be rejected
How would those guidelines apply to someone's awesome first person shooter?
Maybe the "reckless use of weapons" part. But that's not the spirit of the law --- the spirit was likely to prevent people from e.g. making an app that gives a step-by-step photographic guide to creating a pipe bomb, or something of that sort.
Perfectly encapsulates the essential pain of estimating.
finger johnc@idsoftware.com
[idsoftware.com]
finger: connect: Connection refused
sigh...I toil with silly web development side projects for months on end that evolve into nothing and he's coding complete games, single-handedly (though admittedly using some existing codebases and content) in a couple of months.
That guy is wicked smart.