Sometimes it’s easier to walk around then straight through


Quite of few TES:Arena IMG files are compressed in a crazy-wack-funky format that only the executable can decipher. No one has successfully found a way to decompress them. I had, quite a long time back, experimented with trying to replace them with uncompressed images but didn’t succeed.

Character screen

EXAMPLE: The character screen is two parts: stats on the left and character image/provincial background on the right. Each section is it’s own IMG file that is unfortunately undeciphered as of yet.

The “method”

I picked the “QUOTE.IMG” texture to edit because it was quick to find in-game and had clearly defined dimensions (full screen at 320×200). I loaded Arena in DOSBOX and waited for the quote to load (it’s the second screen after loading). Then I took a screenshot and since DOSBOX already uses native resolution, I didn’t need to alter the image. However, when I replaced the “compressed” version with the new one, it didn’t show up in game (it stayed black until the next screen loaded).

The screenshot version of the Quote image

The screenshot version of the Quote image

Wait there’s more

However today, Hallfiry (the maker of the Arena mod suite I use) revealed to me that it was indeed possible to do what I had attempted. Reinvigorated, I retried my previous method and almost instantly found a flaw in my method involving his program. Basically, his program translates uncompressed image files from Bethesda’s non-standard image format to PNG files for easy editing. When it does the conversions it creates two additional files, .MET and .PAL, containing color and format information to be used when reconverting back to the original format (repacking the archive). I failed to accountfor his program needing these files to successfully convert back the image. So this time I copied a .MET and .PAL from a similar “uncompressed” fullscreen image and renamed them both to match the “QUOTE” image.


This time it worked although it looked normal because I hadn’t edited it’s appearance. What this means is that all full screen IMG files could easy be redone using the “improved” method above. However, I wondered about partial full screen images such as the character screen.  Using DOSBOX debug, I quickly found that the character screen images and made a screenshot. NOTE: Dos debug shows what images are loaded so I also knew which image to replace. The character screen is composed of two images. On the left is the blue-ish stat background and the right is the province background with the character image overlaid on it. I chose the stat background due to simplicity. Using the method above, I only had to add one step. Knowing that the CHARSTAT.IMG covered only a portion of the image, I had to crop the DOSBOX screenshot to just encompass that side. I did some messy edits to test a few things and the results are below…

Now I can replace fullscreen graphics

Now I can replace fullscreen graphics


NOTE: I confirmed my suspicions that not only were the DONE and NEXT PAGE buttons were just part of the background, but the stat names and other misc “yellow” text was too.

Basically, this means I’m one step closer to a complete retexture. Fullscreen and partial fullscreen graphics are now replaceable to include: the title screen, the quote, all the image scrolls (yes this includes the text and I CAN fix the Uriel Septim typo), character sheets and backgrounds and what ever else is full screen. The only one I’m not sure about is the MAP. I’ll save that experiment for another day.

– Martin

Picking back up steam


I haven’t had a lot of time this summer but I have made tweaks here and there. There are a few textures I’ve done on another computer that I have yet to transfer over to my master files. Things have settled a little and I should be able to refocus my efforts on finishing the SET files as soon as possible.


For me, one benefit of extended “down time” on a project is that when I finally am able to return, I have regained a lot of my motivation. Additionally, I come back with “fresh eyes” and see ways to do things differently or better. While it’s a bummer to have to delay working on a project, I know I will always return because I love doing it and to me it’s very relaxing (even when I’m replacing every @#$% pixel in 1994 game with only 256 colors, 64×64 image dimensions and cryptic/bizarre file formats)


Here are some photos showing some changes and things I am working or have noted.



Bring marshmellows and a stick…

For this texture set, I wanted to retain the fire/lava vein effect in the walls. Although I had mapped it out from my previous run through all the textures as covered in a previous post, I ended up making quite a few changes. Click the picture below for a closer look.

Here’s a breakdown of the sequence of events from start to finish.

1. Create an outline – To do this I selected a dark color and outlined all the rocks letting anything outside the outline be designated for the fire/lava. I followed the source fairly closely but did take some liberties to make some a little bigger.

2. Fill in the rocks – I initially selected a tan color for the rocks since the original was largely tan-ish. I colored in every rock, one by one. There are easier ways but I enjoy it so I don’t mind using the color every pixel method.

3. Make tiling template – Since any texture in the set could be next to the other, I had to make sure that they match up naturally and didn’t have any obvious seams. I copied the first 3 left-side columns of pixels in the top most texture and pasted them on each image all the way down. Next, I repeated the process but for the right side. This made all 4 textures (this SET is 4 textures in a column) have the exact same sides. Since the top one was seamless, they now all are seamless.

4. Make duplicate of image in new layer – The duplicate layer is what I used to create a uniform and consistent lava pattern. To duplicate a layer, right-click on the layer in the layer toolbox, then select duplicate layer. An exact copy of that layer will be placed right underneath the original.

5. Remove fire/lava from top layer – First, I turned off the bottom layer and make sure the top layer is selected. Then, using the eraser tool, I erased all the fire/lava and miscellaneous areas not already designated as rocks (and thus colored in). This made the lava area transparent but it is still preserved in the bottom layer which is “hidden” from view when turned off.

6. Create lava layer – First, I turned the bottom layer back on and the top layer off. Then I started with the top image and hand created a gradient covering the whole image starting with yellow at the bottom and working to dark purple(ish) on the top. Then I copied this completed lava gradient and pasted it over the 3 bottom images.

7. Merge the two images – I “turned on” the top layer (making both layers on), then right clicked on the top layer in the layer toolbox. From there I selected “merge down” so the top layer and bottom layer become a single image with both the new rocks and lava together.

8. Revise – At this point, I decided that the lighter color rocks didn’t contrast well enough or give the lava the pop I wanted. I loaded another copy of the original texture in GIMP, picked out a new brown but then decided on a slightly lighter color than the original rock outline. Using the bucket paint tool, I filled in all the rocks with the new color. In this process, I also caught a few miscolored pixels and fixed them.

9. Create depth – Next, I added a lighter faded version of the rock color to the left side of all of the rock outlines. This created a highlight and adds the impression of depth to the rocks.

10. Touchup – Lastly I offset the image 1/2 on the horizontal plane so I can see how the whole file tiles sideways. Since dungeons and interiors don’t exceed 1 tile in height, I didn’t have to worry about this texture set tiling vertically. To offset in GIMP, press Ctrl + Shift + O and in the “X” box typing 32 which is half the total width of the texture. After clicking the “offset” button, the whole image will shift 32 pixels to the right and placed the edges of the image in the middle. I scanned and fixed any mismatchs or slight errors then shifted the whole image 32 more pixels returning it to its original place.

Line them up and knock them down

Start strong

As I have stated in the past, one of the most taxing aspects of editing the TES:Arena textures is coming up with a unique take on the image within the constraints of the limited pixel and color count. While I was thinking about my methods and ways to be more efficient, it occurred to me that I don’t appropriately leverage my motivation. For the last 1 1/2 I have been working one texture at a time. This would exhaust my creativity for the day too quickly. I would waste a bulk of my time “finishing” said texture after I decided how I wanted it to look. All of the “fresh mojo” that I had when I started for the day was worn away by the time I got through a few (sometimes one) SET files. This is especially true with the most of the remaining SET files that have no defined look or image (i.e. barely recognizable as any thing but random colored pixels).  Not only was that detrimental to the quantity of work completed in any one sitting, but it also deterred me altogether. There were days that I just didn’t have the energy or initiative to try and figure out a new take on what looked like white noise so I just wouldn’t decide to spend my efforts elsewhere.

Shotgun effect

To better capitalize on that “creative fronted”, I tried an experiment. I loaded up 18 SET files in GIMP. Then one by one, I worked on just getting the look I wanted for a small portion, enough to establish the look. I didn’t waste time completing the whole texture as that is really the easy and mostly mundane part. It worked quite well. Using this method, I was able to solidify my design for 16 SET files in just one day (really just a couple of hours). As I said the design is the hardest part with this project, and I wiped out almost half of the remaining SET textures left. Now, if I don’t feel particularly creative but still want to make progress, I can just finish up some of the ones I have already started (template on itself) and if I do…I may just be able to finish the other 16 or so.

– Martin

Ooh…Shiny keys

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.