WARNING: Potentially boring technical stuff below. Oh and it’s probably unnecessarily long
Whenever I’m feeling a lack of drive to work on a particular project, I tend to stray to something else till that motivation returns. Although I strive to stick to one project, I do need brief diversion to replenish my enthusiasm now and then. Sometimes, that means working on one of my other projects for awhile. Like this week, I took a brief detour back to my Minecraft project. But other times, I just let my more analytical side run wild…..
Besides art, I really enjoy the technical aspects of computer programs. I’m perfectly at home trying to decipher file formats and learn out the hows and whys “behind the curtain”. Sometimes it can give insight into the decision-making that led up to some design choice or the other (e.g. how SET files are mostly walls and floors but the outside ground textures are individual IMG files even though they are used in a “SET”-like fashion). Other times, it just gee-whiz knowledge such as Darkstone can handle high resolution texture or that TES:Arena’s root directory is also the file override directory (overrides the files for the game). I freely admit that I just enough to know I don’t know enough. I can analyze files (e.g. using a hex editor to examine the file byte by byte) but not enough to find the answers I want.
That is how I discover odd things here or there about games that I’m working on. Quite awhile back, I discovered that the Arena executable file (a.exe) was compressed. This immediately led to me wanting to uncompress it. It didn’t take me too long to find a dos unzip tool then I just loaded Dosbox then ran the tool from within the dos environment. It was fun for me just to have gotten that far. The executable still worked but it wasn’t as if that opened a treasure box of discovery. The main thing I found was text inside the executable that is used in game however I don’t know if editing it would cause something to break (might be worth trying sometime). Sometimes compression isn’t about size but speed. The computer can load more into memory then uncompress it on the fly. However, that isn’t really relevant to TES:Arena anymore ;)
Occasionally when I’m bored, I load the Dos debugger version of Dosbox. It’s basically the same program that emulates Dos but with a debugging window so you can see “what’s going on in the background”. While I don’t have nearly enough skillz to understand how to copy memory from registers and other such jazz, it has shown me what files were loaded when particular dungeon or city was entered and that has proven helpful a few times already as I tested my mod. I know it’s possible (in theory) to use the debugger to find the routine for the IMG files that use that difficult compression. Also, one might be able to wait till one of those IMG files are loaded in memory (and thus already uncompressed) and then pull it out of the memory register….no idea how to do it though. (I told you I know enough to know I don’t know enough). I would really like to see if the IMG files would still work “uncompressed” but don’t know how to make that happen.
All TES:ARENA levels are detailed out in the MIF files while the textures, sounds, etc. that they load are listed in the INF files. Think of a MIF as locations outlined out on graph paper. They determine the layout of all locations: cities, dungeons, stores, etc. INFs are more like the map key dictating what the dungeon will look like aesthetically. With preliminary exploring with a hex editor , I found each MIF has a specific INF listed in it’s “code”. So when a MIF is loaded, it searches for the INF and loads all textures and sounds from that particular file. If we ever manage to decode the MIF format, we could theoretically create new levels and hand design them too. Occasionally, I’ll load one up but honestly, but I don’t get far (it doesn’t mean I can’t have fun trying).
INFs on the other hand, are all plain text. You’d think that would make them easy to decipher but the format is only partially obvious. I have fiddled with changing pieces here and there to see the effect in game but only a little and I haven’t found much. There are some odd switches that didn’t seem to have any (obvious) effect on the starter dungeon. I will probably map the INF file structure out at some point when I have more time (ha ha). The bigger problem is that I think the INFs maybe loaded with extraneous junk that doesn’t get used in game. For example, the starting dungeon only has one floor and one exit with no entrance but the file not only list an entrance file but also 6 alternate files sets as well a listing of all the monsters in the game even though only a few are used in that level. My theory is that they used a base template to start with then altered it from there. This confuses the matter if a texture is used in game or not if each level list many textures that aren’t used for that level. It could be trimmed down if I we knew what the structure of the MIF files and could see if those listed IMG files are actually used in that level. Maybe in time.