A third-party editor for Total Annihilation
currently being ported to the Macintosh by Bruce Payan
(with many thanks to Kinboat for the PC version)

There are basically two map editors available for Total Annihilation:

This is an ongoing project. I am currently porting Kinboat's VB source code for Annihilator 1.5 to RealBasic and rewriting the low-level routines (largely based on Joe D's HPIUtil Library) using CodeWarrior Pro 5.

I am affectionally calling this effort "Anni". I would very much appreciate some indication of interest, via e-mail, from the Mac TA gaming community as to just how desperately people would like me to continue. I recently posted an item at TAMEC about this.



10/09/03

I have recent, renewed inklings to finish off Anni.

In the meantime, I've decided to let people download a pre-alpha version of Anni. You can download it from here. (*** Use at your own risk ***). It is not entirely functional (it needs a few more days/weeks of work). The intent is to get a "feel" for how people like it. Once it is complete under OS9, I will likely begin the task of porting it into a more recent of RealBasic and Carbonizing the thing.

07/03/02

I've spent a number of hours re-thinking through a portion of Anni code so that we aren't stuck with storing a 32-bit picture of the entire map: Imagine this: A high-quality 32-bit image of the *entire* TA map stored in memory -- can you say "memory hog?" This is in addition to reading the 8-bit image off the disk. It's rather brutal.

I started off by writing a "C"program using Codewarrior that used a 8-bit GWorld to produce a desired off-screen image, and got that working using TA's specific palette. Then I got to manipulating the image using PlotCIcon with this palette (as TA tiles are, coincidentally, the same size as standard icons, 32x32 pixels). Then I got this (mostly) working under Realbasic. Now the question is: do I continue on with Anni and rewriting my hunks of code (memory-slim) or do I leave it as-is (memory hog) for now and finish up the save game code, etc...?

It'll take me a few days to jump back into the RB code for Anni, but it's coming along -- like I say, holidays are here -- hopefully the wifey is very patient with me ;-)

I've also paid out the big $$$ and upgraded to Realbasic 4.0.2. I strongly recommend it for any users of RB 2.1.2.

01/12/01

Carey Adamson wins the prize for steering me in the direction of ResCompare for that byte-level file comparision program. Good stuff. Now I can figure out what the problems are I'm having with my game saving code.

12/31/00

Happy New Year everyone. Been spending a little more time on Anni -- squashed a few long-term bugs (eg. MiniMap update lag) and located a few more in the past couple of days. Been tackling the last of the SAVE game code recently and adding the AI profile ability to Anni.

If anyone knows of a good byte-level file comparision program let me know. Seems that CodeWarrior and BBEdit work only with text files, and Diffy-Doolittle only gives you a YES/NO answer. I want to ensure that a saved (but unchanged) map is identical to its original AND see where any changes may have occurred. I suppose I could whip up my own...

12/18/00

Some further work occurred on Anni today... I got on-the-fly feature loading working fine which was quite the impromptu accomplishment. Also got the height offsets working for newly pasted sections.

12/17/00

I poured a bunch more of the import/export BMP coding into Anni this weekend - managed to get Anni to import and export Sections (eg. from a tileset), and minimap pictures... and holidays are fast-approaching.

12/10/00

WORK HAS RESUMED... Yes... I've picked up on Anni after over 3 months of doing little with her, thanks to some encouraging e-mails (you know who you are).

I spent a couple of hours today working on the BMP exporting code for Anni and perfected it over the PC version. In short, BMP files of the entire map can be quite huge (eg. 12288x12288 = 144MB for Delta-Class Fortresses). The PC code was writing all this data in memory *before* putting it to disk which is quite unreasonable, I think (got a few hundred MB of RAM to spare?). I streamlined the write-to-disk code and removed any sort of RAM requirement.

08/27/00

While the progress on Anni has slowed somewhat of late as I've been enjoying some of my holiday time and I am back to working full-time shortly, I nonetheless hope to spend a little more time on Anni and get the thing out there for interested gamers to start using.

A quick warning: thanks to some limitations of RealBasic (namely, the inability to work with 8-bit graphics in a specific palette), Anni is going to be a memory hog.

08/08/00

The pace has slowed a little on Anni -- I made a resolution to actually try and enjoy some of my holiday time. Spent one day last week with friends "yacking in kayak" while cruising down the river... so far removed from Anni.

08/03/00

Got a number of e-mails today encouraging me onward, likely from the fact that MacLedge reported a link to this page. Good stuff.

Squashed a number of long-standing irritating bugs -- there was a biggie I found during map-load time. Turns out I was writing an extra few bytes to memory willy-nilly which caused a number of subsequent errors which I couldn't really explain.

08/01/00

I spent a good part of yesterday working on the Save Game code and got most of it done. I reworked a lot of the save code -- on the PC version of Anni, when you save a map, it recreates disk-savvy copies of its data structures, dumps that into yet another chunk of memory for writing to the disk, encrypts/compresses then writes it. In other words, if you're using 30mb of RAM, you could see your RAM requirements skyrocket to about 90mb momentarily. Anyway, I reworked this code so that you only need 60mb temporarily -- there would appear to be no easy way around this.

Spent a good deal of the day "experimenting" with offscreen Graphics worlds and the Mac toolbox. I am trying to get Anni to draw its tiles directly off the 8-bit data that is read of the disk. I kind of got it working, but the color palette is mysteriously "off" (things are quite dark), the speed drop is significant, and it likes to leave screen artifacts. Hope to look into this more in the coming days. It may be that an "option" would be to have a less screen-friendly rendering at the expense of RAM, though this should not be the case.

It would appear that my ETA for Anni is going to slip -- there is just too much left to do.

07/30/00

Worked on the save game code today, and got the File...Export Map (to TNT format) working. In the sample files I used, the resulting TNT file was *identical* to the original in size and content.

Thought more about memory requirements, and investigated (without much success) the RB <--> 8-bit issue. I may even end up resorting to using a disk-caching system (a-la Photoshop).

07/29/00

A short day with Anni. Got the Edit Section Group Hierarchial List Box working (thought about it last night, slept on it and awoke to whip that baby up in under an hour).

Located the source of my "blotch" problem and rectified that nicely. Also optimized copying Sections around. I was previously pixelating everything from the main map, onto the selected section, then back to the map once it was placed (pixelating is me going through 1024 pixels on a 32x32 tile and setting the color values of each pixel). Rather time consuming. Instead, I figured out the already-pixelated tile location on the main map and tiledrew those over (much, much faster).

Anni's memory requirements continue to cause me concern. Seems that even a smaller map is eating up gobs of RAM. Still thinking about ways of getting around this -- looked into low-level Toolbox routines that blit 8-bit pixel data through "creative" methods (can you say grab RB's WindowPtr and blit directly to the screen without RB even knowing about it?). Eliminating that memory-hogging 16-bit RGBSurface would be *so* nice.

07/28/00

Still trying to track down the source of the white splotch. Gave up on that for a bit and managed to get "3do" features to load just fine (they were disabled up until now). Took a run a code cleanup (removing original commented lines of code for my reference), and looked at project-wide profiling code.

Also monkied with the ToolWindow a bit to get it to resize to display three full sections at a time rather than two-and-a-half. Implemented the "Grid Size Options" and "Fill Options" dialogs.

Thinking more and more about how I might implement UNDO (as it's not in the PC version).

07/26/00

I got the Anni options menu working like a charm so that you can also edit your Startup Locations very nicely. You can even temporarily disable the reading of a folder at startup (can't be done on PC version). Added a few other options (see screenshot below) which are present in Anni 1.6 for the PC. Also got the Anni prefs file working wonderfully.

Feature loading is blindly fast now that I've improved a few things. Previously, Anni was going off to the disk to load your features every time you changed menus. Also sped up the disk-read significantly too. Also started on some BMP import/export code -- anything to avoid the Save Game code!

Two big things to do for tomorrow: find out why I get a big white splotch after I'm finished placing a copied section, and work on the Save Game code!

07/25/00

I got a few things going today: fixed many canvas cursor bugs and anomolies, fixed a bug where tiles were jumbling after being selected (another bug still exists upon placement), and added an option to number *all* the tiles on the map.

07/23/00

The pace has been frantic ;-)

Cured the minimap problems -- things are much better now and *much* more elegant. Got the resize code working along with its dialog box. Also got the massive Map Settings dialog (and its code) incorporated, spent a little time kayaking, and added in a few more menu options.

I tried doing some copying/pasting/filling etc... and the results were not quite what I expected (need I say more?). Dreading that save game code.

07/22/00

I started off the day with some really nice cleanup on the startup window (screenshot below), it's now threaded too without the OK/Quit buttons. I also reintroduced the progress indicators (using threads).

I spent some time trying to optimize the scrolling speed, but was rather unsuccessful. What I did find out, however (after writing some code profiling routines) was that drawing the minimap was brutally slow and unwieldy, often repeatedly calling the same thing. Hope to optimize this tomorrow.

Still on the to do list...

  • Game save code (a biggie)
  • Import/Export code (BMPs, Sections, Heights, etc...)
  • some options dialogs
  • cursor usage cleanup
  • minor interface glitches, include progress boxes + cancel options

07/21/00

Got all the code working for loading UFO files today, which was a big job. Also started off on the code for keeping multiple maps open at once, and have the unique interface done for opening/saving files.

I located an interesting "bug" in my C program files. I had accidently left a debug switch on with the result being that my HPIUtilLib was producing a logfile of 60mb in size each time I ran Anni. No wonder it was slow -- much much zippier now.

07/20/00

Added a few cool things today. I got Anni to actual display the feature/section picture in the canvas cursor, and it shimmers onto the screen, starting out translucent. Very cool and very much not available in the PC version ;-) Now you can really tell what you're placing and where -- no guessing allowed. Updated screenshot below.

Both features and sections are placing fine now, which is great. I slogged through the code to load a section -- turned out to be quite easy though I tracked down a nasty bug that was messing up my cursor-shimmered image on sections with repeating tiles. Turns out, though, that yesterday's section-pasting code works great unaltered.

Also added a numeric tile-counter to the tile palette screen that shows you the top-left tile number and the selected tile number (for your reference).

07/19/00

I was delighted today to have Anni start placing features on the map -- you can even fill an area of a given radius/density with multiple features. I was a little surprised at the high density with which Anni places things, but it matches the PC version.

Sections are also now selectable in the tool window, and otherwise the tool window is essentially complete (nothing new to add there). Deleting any features/tiles after selecting them, though, still needs some work -- my selection areas don't scroll with the main map as they should.

I've also roughed in the code for copying the tiles from the sections onto the main map, which requires some serious consultation with the off-screen master tile bitmap (code that wasn't in the PC version). I think I've got it licked and it'll be kickin' fast, thanks to some low-level help from the Mac toolbox's BlockMove. There's actually a huge hunk of HPI-dependent code to load the tile sections which I am truly dreading :-|

07/18/00

Got a small number of things done today. The cursors are quite fluid now and I've even implemented some "crawling ant" selection boxes (aka "marquees") for them. I incorporated some overlaying code, but didn't get too far on this.

Some of you have been inquiring about the recent appearance of Annihilator 1.6 for the PC. It's real deluxe feature is, thanks to CAP, the ability to edit your AI profile without tearing the UFO file apart. I intend to incorporate this into the Mac version.

07/17/00

A great day for Anni -- I got the Tile Palette working so you can place individual tiles right on the map, as well as edit the starting positions. I also spent some time working on the height editing, ran it and discovered that it all worked quite unexpectedly. A pleasant surprise.

Some of the upcoming things to work on include making the canvas cursors a little more fluid, work on overlaying sections and features on the map, and those dreaded .UFO maps.

07/16/00

I'm back and hope to put some more time in on Anni this week. I received a great e-mail response from Adam "Kinboat" Swensen in which I asked him a number of technical questions, and also an encouraging e-mail from Chris Taylor, the original mastermind behind TA. Cool. Good to see, too, that the Mac version of Sims went gold, as that'll mean Phil Sulak's work on the TA 3.1.2 update will likely progress nicely.

I got the sea level slider working today -- it updates contour/height meshings on-the-fly too. Also did some work on set up an "Anni prefs" file. Finally.

07/07/00

The final day of work before I'm off. I fixed up some minimap stuff, added a new memory meter to Anni, and managed to load Emperor Dracula's 63x63 map "Real Earth V1". See the cool screenshot below which includes the memory bar.

07/06/00

Got minimaps largely working (a few bugs still) -- you can navigate with your minimap and generate draft/final versions. Also added the menu buttons you see (for viewing contours, features, etc...) and they mostly work. Not only that, but a large majority of the menu items are now functional. This may, however, be the last real day of work for about 10 days (taking a real holiday). See below for the latest screenshot.

07/05/00

Another great day. Got the contour meshing and height mapping working just fine -- it matches the PC version pixel-for-pixel along with colour gradients. Very cool and still very snappy. Also got autoscrolling to work as well as boundary drawing. I also ported in probably 25% of the code base that I am not really using yet. A great day.

07/04/00

Now, the maps are not only scrollable but I've also managed to include features (eg. trees, spires, metal, rocks, etc...) and starting positions on the map. See the screenshot below of Cavedog's "Lost Civilization" map. Currently, only the TNT/OTA files are loading -- HPI maps are to come shortly. But I can't believe I spent 2-3 hours tonight tracking down a byte-swapping bug that caused features to disappear from TA:CC maps. Unbelieveable.
At this rate, what will come first? -- my map editor or TA Update 3.1.2 ;-)

07/03/00

Well, summer holidays are now here and I found some time to spend on Anni. This evening, I was very happy to implement my off-screen buffers (@ 16-bits thanks to RB 2.1.2) for drawing the map and to get a scrollable map appearing in the editing window. She scrolls pretty smoothly, too. Ah, the wonders of blitting.

04/30/00

The recent release of RealBasic 2.1 now allows manipulations of 16-bit surfaces, so the 5kb/tile requirement can be relaxed now to be only 3kB/tile, which is a little nicer. Regardless, the memory requirements for Anni are going to be steep.

02/17/00

Little nephew continues to pester about my map editor -- he wants it done by his birthday (in March). Then he wants it by Easter. Neither date seems likely. This limitation of RealBasic is troubling me.

01/05/00

Little progress has been made. The full-time job has been taking its toll and when holidays do come, I really don't feeling like programming.

12/20/99

 

Started to delve into the code that loads a map and displays it on-screen. I have been a little stumped by this as Anni stores a map as a set of tiles (32x32 pixels of 8-bit depth), for a total of 1kB/tile. RealBasic 2.0 does not allow fast pixel manipulations on 8-bit surfaces (only 32-bit surfaces are possible). This would mean I'd have to keep an 8-bit copy around (for PC compliance), and a 32-bit copy -- with a tile now being 5kB in size (talk about a memory hog particulary when there are often thousands of tiles in a map!). Troublesome.

12/15/99

The features and sections menus of Anni are done. The program starts up and will read all of the features and sections present in any HPI/UFO files that it can find, and you can display lists of these items (via pop-up menus) from different worlds. Dialogs and menu bars are essentially complete.

11/27/99

The low-level HPIUtilLib stuff is mostly complete -- in other words, the overseeing (RealBasic) application can properly read and write files and deal with compressed HPI/UFO files and with the Intel-Power PC endian ordering issue. There is some porting to do still here to deal with GAF (vector-based XYZ graphics) files.

11/20/99

I got tired of trying to find specific portions of Kinboat's code using CodeWarrior as my code bank, so I ported all 17,000 lines of it into FileMaker.

11/17/99

Became very frustrated with the results of VBCleaner. Going back to copying/pasting code into RealBasic manually.

11/13/99

Started the project. This included grabbing all the source code, converting it with VBCleaner, and started with the RB visual objects.




Above is a screen shot of the features and sections loading (users of Annihilator on the PC will recognize this):

 


Above is a screen shot of the features and sections pop-up menus being utilized. The actual map editing screen (though present in this screenshot), was non-functional.

 


Above is a screen shot of the map editing screen finally becoming scrollable along with the features and starting positions showing. You may wish to save this image and view it @ 1024x768 for the full effect...

 


This was just too cool to pass up -- part of a map showing the features and the contour mesh. The map boundary is also drawn. Hmm -- maybe I should put the mesh underneath the features..... (later fixed)

 


See the minimap there -- it's there and it works (mostly) and can even be used to navigate the big map. Notice, too, how the menu bars are now enabled. I also added 8 of the toolbar buttons from the PC version (the first 5 are fully functional). (Left to right: View Grid, View Heights, View Contour, View Features, View Starting Positions, Default, Selection, Selection Filters.)

So, why is it that the PC version of Anni also produces horrible Final MiniMap Pictures (I thought it was a bug in my program)? At any rate, Mac users can take solace in the fact that it takes Virtual PC less than 5 seconds to restore itself to its previous state (yes, including a fully-loaded set of features running under Anni). What a timesaver for flipping back and forth! Yeah!

One last thing -- see the glaring error in the height data for this Cavedog map -- *cough*


Like the memory bar with the nice colour gradient? I think it's cool -- I'm living on the hairly edge with this map, though. The meter was inspired by a (successful) attempt to load Emperor Dracula's huge 63x63 map (it used 140mb of RAM). I was quite surprised to find out, however, how little RAM loading of features takes. Turns out the big memory hogs are a semi-bogus checksum array for the tiles (to speed comparison) and my RealBasic off-screen bitmap for drawing. I allocate 4096x4096 @ 16 bits which equates to 32mb of RAM -- enough for 16384 tiles (2kb/tile). I'll likely adjust this dynamically to be some function of available memory -- the Real Earth map needed 72mb off-screen.

The development of the colour gradient was interesting -- I started with a combination of a parabolic and cubic function that would determine the green-to-red colour values (as a linear ramp didn't show enough yellow) that took about an hour to perfect. Eventually ditched it in favour of a static gradient image whipped up in Photoshop and integrated in about 10 minutes that just simply gets clipped at the rightmost edge. Way faster. Boy, do I feel silly.


Here's the latest screenshot showing a rather unorthodox placement of a hunk of metal on a Mars map (hey, the sections HPI file "Special Tiles.hpi" was small, so what the heck). Note the red outline on the selected section -- the full-size section (384x192) on the right is fully fluid/movable and originally translucent over the landscape. Note that the view box is now appearing properly in the MiniMap window (gotta get the section to appear fluidly on the minimap too -- hmmm). I've also got Anni arranging windows properly now upon startup, based upon your current screen resolution. Minimap is in the bottom left, people.


The new and improved startup splash screen caught in action -- there's a lot of tidying up going on with this behind the scenes, too.


The Anni options screen -- beauty in action. The color chips bring up color picker dialog and the Search location dialogs are rather bulletproof even if you do delete your Prefs file.

I got in touch with RealBasic today on some memory management issues. I am quite concerned that large maps will misbehave if memory is fragmented at all, so I've been careful to use relocatable Handles where appropriate up until now. This is the suprising response I got from RealBasic:

>(1) Are these any RB issues surrounding the use of user-allocated
> Handles that I should be aware of? I assume that RealBasic is
> OK with this as things seem to be running well.

Hello,

I can't think of anything that you need to be aware of especially if it is running well!

>(2) Please confirm that RB's garbage collection and internal
> memory allocation is entirely based upon the use of Handles so
> as not to fragment memory.

Nope. It's based entirely on pointers and does fragment memory.
But, RB also uses a custom memory manager that allocates large blocks
and carves (and recycles) small blocks out of that. So fragmentation
is rarely a serious problem in practice.

>(3) If the answer to (2) is in the negative, are there any statements
> in RB (apart from the use of memoryBlocks) I should avoid (or
> preallocate) that use pointers and/or fragment memory.
> Toolbox windows are even PICTs were notorious for causing
> problems as they using Pointers rather than Handles.

MemoryBlocks are no different from any other RB object; that is a
myth, plain and simple. Don't avoid them unless you're also going to
avoid strings, windows, objects, etc.

All objects use pointers. But fragmentation is kinda like screen
burn-in; many people believe it's a problem, but in reality it hardly
ever is. My advice is to not worry about it (and under both Windows
and Mac OS X, the problem goes away completely).

>(4) Any hints on any specific nilification of objects that I should
> be doing (eg. Nil-ing one picture before allocating a new one?)
> to help out garbage collection? Neuberg offers a few hints on
> this -- are there "official" ones?

Although Matt Neuburg cannot give an official answer I would tend
to believe what he says. I usually find that he is on target.