Hey, a new version of ToeTag is available! This version fixes the problems that 2.00 was having with WAD loading/saving and improves the CSG code quite a bit.
Of course, the source code is available on that page as well. Have fun!
I’ve been working on the main page for the site in my minimal amounts of spare time. It now has a section for links to any games or applications I write on this site. ‘Shooter in the Abstract‘ also has a nice web page to hold it now.
No garden is really complete without a zombie. Here’s ours:
If you want one of your own, click here!
I stumbled over this great article from 2006 that outlines a really easy to use method of grabbing command line arguments in a Cocoa application.
I threw this into a test application and it works great! Amazing what you can find on the web sometimes.
So my Sparkle framework and appcast decided that they weren’t going to talk to each other anymore so I hit the reset button. ToeTag is now kicking off from version 2.0 and now includes a download link for the source code! The appcast still seems fucked up for whatever reason but I’ve decided to stop caring. Anyway, download ahoy!
Download ToeTag 2.0 + Source Code (optional)
The download for the source code is at the bottom of that page. It’s an XCode3 project written entirely in Objective-C using the Cocoa framework. It’s a native OSX application and compiles to a universal binary. Enjoy!
This doesn’t mean that I’m going to stop developing ToeTag. I intend to continue adding features and polishing it up until I reach a point where I can use it for level work and not ever have to think, “Man, it would be cool if ToeTag could do X…”
Work is whipping itself into a frenzy in the push to get Gears 2 out the door so updates here will be slower until that is done. I won’t have time during the week to do anything on home projects and on the weekends I’ll probably want to go outside and refresh my memories of what it looks like.
See you on the other side!
OK, so I’m back to NSAllocateCollectable as my weapon of choice instead of using NSMutableData objects. I was getting weird errors with NSMutableData here and there so I thought, well, why not see what was actually wrong with my NSAllocateCollectable implementation?
The problem I was having that loading a large map would completely blow out my 2 GB of RAM and stall the machine. That didn’t seem right for a Quake map. So I looked into it and the problem was two things.
First, the garbage collector wasn’t getting any time to run during the map load sequence. So while I’m creating verts and brushes and planes like crazy the GC is sitting there patiently waiting for a processor break to do it’s job - which doesn’t come until the end. So I stuck in some strategic calls to [[NSGarbageCollector defaultCollector] collectIfNeeded] and that’s happy now. Map loading only allocates a few hundred MB in total.
Secondly, my render array implementation was doing a lot more work than it needed to. What I wrote for speeding up rendering was an array of vertices, uv coordinates and colors represented by a blob of float data in RAM. It allocates a new blob within the greater blog for each new vert/uv/color that the editor wants to draw (these are grouped by texture, so all of the verts that use the same texture are drawn as one OpenGL call). It tried to optimize performance by keeping a chunk allocated that represented the maximum number of verts that were ever requested for that particular texture. This meant that it could save itself from allocating the data blob every frame for every texture. The trouble was that when it came time to resize the array to accommodate more verts, it wouldn’t allocate very much so it was constantly resizing the array during a map load. This ate time like crazy. Once I changed my “grow array by” value to something much larger, it took maybe 45% off of the load time for large maps. It wastes a little more RAM now but since we’re talking about a few hundred MB at the most here, I’m not concerned.
So I’m fully garbage collected now. Hooray!
As a heads up to any Mac users out there, the SVN (Subversion) front end called ‘Versions’ is in BETA and available for free download:
I grabbed a copy and it looks -really- slick!
So I decided to be a smarty man and change ToeTag so that every piece of memory allocated would be handled by the garbage collector. I had several spots in the code where I was allocating standard C style memory chunks (via malloc and free) and that never sat right with me seeing as this is 2008 and all. I suppose when dealing with a game engine and data structures from over 10 years ago (Quake) it’s understandable but I wanted to do better.
I picked up a copy of the latest revision of Aaron Hillegass’s excellent book, Cocoa Programming for Mac OSX. Within it’s pages, I found the garbage collection section which was newly added as of this version of the book. It mentioned using the function call NSAllocateCollectable as a way of getting C style chunks of memory allocated that would be garbage collected. Marvelous, I thought! Unfortunately, either something is wrong or I’ve coded ToeTag in some retarded fashion that breaks this idea. ToeTag, when loading large maps, would allocate 2+ gigs of RAM and stall the machine until I killed the process. Just loading DM1 was taking upwards of 750 MB. Something was wrong.
So I ditched that idea and noticed a class called NSMutableData. This class gives you a beautiful object oriented way to allocate chunks of memory and get a pointer to that memory quickly and easily. Eureka! I changed all of the NSAllocateCollectable code to use this class instead and everything works great!
Not sure what was wrong with the former but the latter works perfectly. Now ToeTag no longer has those ugly C warts on it.
So I decided to take a look at multithreading QBSP since I already set up LIGHT and VIS to do it. In looking at the code, it seems Carmack set it up to fork() the process twice instead of threading the hull building. I assume this is because QBSP uses a ton of global variables which makes threading a major hassle without a lot of code refactoring.
At any rate, this worked straight away on Mac OSX once I enabled that code path. What that means is that ToeTag’s QBSP will build all 3 hulls (small collision, large collision and drawing hulls) simultaneously instead of sequentially. It’s not a huge savings but, hey, it’s something right? It was getting nasty with my remix map which now takes upwards of 30 seconds to QBSP itself. That’s been cut down to about 17 seconds now so I’m happy!