Makaqu

There is no way to dither run-lenght encoded TGA images on the fly. Dithering them would require decoding the whole image into an intermediary buffer first, and this would temporarily increase the memory consumption by a significant amount.

Maybe later, but not now. This means that uncompressed TGAs will be dithered, and that run-lenght encoded TGAs won’t.

By the way, the non-dithered borders mentioned in the previous post have been fixed.

Hmm, how stupid. I just found out that the memory for the textures of the skybox was always being allocated… even when no skybox was being used!

Plus, it always corresponded to the necessary amount of memory for a 512x512 skybox, which is 1.572.864 bytes. What a huge waste of memory.

Added loading of 24-bit and 32-bit TGA files, finally.

Both are converted to 8-bit textures using the game’s palette, which makes them lose a lot of detail. This should be alleviated when implementing dithering into the conversion algorithm.

I’m still going to implement 24-bit color rendering in the future, but it’s nice to keep the 8-bit color software renderer able to do mostly everything.

And while working on the TGA loading code, I’ve noticed that both it and the PCX loading code never frees the previously used memory before allocating memory for the new files, so it’s a big memory leak that may crash the engine after loading several skyboxes.

Besides that, I’ve also got to properly implement support for Saturn PIC images, and to create a flexible in-memory image format that will make it easier to replace textures.

Memory usage reduced to 15.268 KB, and it’s still running.

After running it for about 22 hours straight, it’s probably safe to assume that Makaqu is more stable than before, though there still are several bugs left.

It’s still running, and no crashes. Memory usage reduced to 19.880 KB.

Currently running the starting demos on loop to see how long it takes until the engine crashes.

So far, no crashes, and a memory usage of 24.656 KB. I don’t remember doing anything too special to fix the crashes, so let’s wait and see.

I’m still sure that there must be a few memory leaks in the input and/or in the console code, so maybe the fact that I haven’t used the console or played the game for a while before playing the demos is a factor.

I’ve also double-checked my screenshot enumeration algorithm, and there are no bugs in it. It was coded in a hurry, and hadn’t been properly checked for bugs before.

Now the mouse won’t be locked in the window when playing demos using a windowed video mode, and now the engine also recognizes mouse clicks when the mouse isn’t locked, so the mouse clicks can be recognized by the menus.

Skyboxes supports textures of any size (of at least 8*8 pixels) now.

The MDL model code is being reorganized, and I’m studying it to improve it, but right now I’m more interested in fixing the bugs regarding the BSP model translucency, and in finishing a few other features.

By the way, skyboxes aren’t blocking the world’s geometry; this must be fixed, but I’m afraid that fixing it will make it slower to render.

Another thing I may be going to research is outline rendering for BSP models.

In theory, it should be possible to render them very quickly, by using the VIS data to precalculate, cache and export a list of the visible lines on each point of the map. In practice, this requires a deeper knowledge of the BSP model format and renderer.

I’m not sure if this would work for BSP models used by entities other than the world, but since they’re usually simple it shouldn’t affect the framerate too much to let the renderer try to render all of their outlines.

Some future plans:

One of the first things I’m going to make on the next version is to modularize the engine more. Specifically, I want to abstract and split things like the MDL and SPR model code out of the rest of the engine. This should help me to isolate and fix more bugs.

It would be great to also abstract the BSP model code, but this should be harder. The fact that entities are defined by the world’s BSP file is the first issue that comes to mind. But anyway, there are a few other things that can be done to make its coding easier.

The whole menu system should also be rewritten. I’m getting quite tempted to port it to C++, and if this happens, more should follow.