Posts Tagged ‘ToeTag’

Energy Returning

Sunday, March 15th, 2009

I finally got some energy up to get back into some of these side projects.

I played around with the renderer a little in LevelEd. I first tried to use a timer to continually draw the viewports and while that worked it had it’s share of issues. For example, whenever I would click and drag the mouse it would stop updating because, obviously, the timer messages were stalled while I was hogging the message queue with mouse updates.

After that I decided to take a shot at putting the rendering on a separate thread. This worked out great once I sorted a few small code niggles out. It isn’t necessarily faster (although it IS in certain cases), but it’s definitely more responsive since the main UI thread doesn’t have to wait anymore for the viewport to draw before processing more user input.

I also looked into creating a Framework for all of my common code. Previously, I was just including all of the common source files into each project that needed them. This worked but it was a hassle since every time I added a new class to the common code directory, I would have to remember to add it into each project that used it. With the Framework created (which loosely explained is sort of like a DLL in Windows only better in several ways), I simply link against that common framework in each project and now I never have to worry about it again. It’s all magically updated! As an added bonus, I don’t have to install this framework on the users machine since it’s embedded inside of each app that uses it. This isn’t the traditional way to use a Framework but it seems the better choice for something where you don’t want the user to have to install anyway, which is what I’m after with the ToeTag suite.

Optimization Woes And Worries

Saturday, December 13th, 2008

I can’t figure out if I’m screwing up in some terrible way or if the compiler really is at fault here. I have 2 spots in my code, both related to loading files, that will not work in Release mode – only in Debug. In Release, they both randomly crash with some sort of s_zone error (memory related, I believe). I can fix this by wrapping the offending areas of code in pragma statements, like this:

#pragma optimization_level 0

...offending code here...

#pragma optimization_level reset

This allows me to turn off optimizations on just the section of code that is crashing and this does seem to fix it. However, I’m not 100% convinced that my code isn’t at fault in some way. It’s hard to stomach the idea that the compiler is doing something wrong – however, I’ll be damned if I can see why or what in my code is causing the issue.

Ahh well…

Code Complete

Thursday, December 11th, 2008

Well, obviously NOT, but we’re getting there. The code base is about as generalized as I can make it right now. There are a few other things that I can, and will, break out over time but enough has been done now that I can continue on with the rest of the ToeTag editing suite.

Next up: PAKEd. This will be an easy to use PAK editor with full drag’n'drop functionality and file previews. Should be fun to work on!

I can’t go too quickly though. WADEd still has a bunch of features that need implementing and there is always more to do with LevelEd. I think the realistic truth is that this suite will never be fully finished. Ever. But as long as it always evolves in a positive direction it should be fun to work on and use.

Reducing Interface Clutter

Wednesday, December 3rd, 2008

I was adding a feature to WADEd this morning when I had a pang of guilt and had to rethink what I was doing.

See, WADEd already supports the importing of textures. So I was adding another menu option called “Import WADs…” which would let you append the contents of an existing WAD to the one you already have loaded. But then it occured to me: instead of adding another menu option, why not make the existing menu option smarter?

So that’s what I did. There is now a single “Import…” option. If you select images to import, it will process them properly. If you select a WAD file, it opens it up and imports the textures inside. Smart and automatic! I like it.

After getting that working I realized that the same mechanism could be used for extracting textures from BSP files. If the user chooses to import a BSP file, crack it open and drag in the textures. I like it when stuff ‘just works’.

WadEd Preview

Saturday, November 22nd, 2008

So I’ve been toying with the idea of a ToeTag editing suite. Something that will be a more comprehensive solution than a level editor with some WAD editing capabilities tacked on. To that end, I’ve spent the last week or so breaking out the WAD editing into a separate application. Quick screenshot of the WAD editor:

This means that the level editing application will no longer be able to edit WAD files but I will add some sort of “Open WAD in WadEd” menu option that will launch it easily so it shouldn’t be an issue.

I plan to add a PAK file editor and potentially an MDL editor if I can muster up enough free time. My ultimate plan is to include some sort of integrated QuakeC editor/compiler and then you’ll be able to create Quake mods entirely from within the ToeTag application suite.

World domination is at hand!

Sometimes Your Own Dog Food Tastes Bad

Tuesday, September 9th, 2008

Writing my own Quake editor (ToeTag) has been a great experience in many ways. One of the good ways, obviously, is that it allows me to work on Quake levels on my Mac! One of the bad things, however, is that when something goes bad or breaks or crashes – it’s my fault. And I have to fix it. Blargh.

Something I’m discovering with my latest level is that ToeTag was a little bit of a memory hog. It was allocating over 1GB of RAM to get that level into memory. I figured out what was wrong this morning and now it fits into about 100MB but those are the kinds of things that you don’t discover until you’re pushing the edges a little bit. Small maps didn’t show this issue. This large map does.

Sadly, it still doesn’t fix the weird WAD related loading crash that I get in release mode. It doesn’t do it in debug at all which makes it super awesome to try and fix. Stupid dog food.

ToeTag 2.15

Saturday, August 9th, 2008

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.

Download it here!

Of course, the source code is available on that page as well. Have fun!

ToeTag 2.0 + Source Code

Saturday, July 5th, 2008

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…”

Garbage Collection Redux

Sunday, June 8th, 2008

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!

GlDrawFastAsHell

Tuesday, April 29th, 2008

I took some time off from my remix level to look at the ToeTag source again. The editor was getting a little choppy when the entire level is visible and I wanted to see what I could do to fix that.

The answer, it seems, is glDrawArrays. Holy crap! It takes some massaging of the data each frame to get it into contiguous arrays but, man, once it’s in there you can blast polygons to the video card. I can now work on my level with the whole thing visible. There are lots of places I can leverage glDrawArrays still so it will only get faster in the future.

Once I get as much as I can drawing through arrays, I’ll post a new version of ToeTag.

Very happy!