KarlosTKG now on GitHub

[Karlos]

Originally Posted by viddi

It´s an outstanding achievement.

Just tested the latest version. An immersive experience, especially the large corridors and halls. Much, much cooler than the original.

Thanks. It's very unfinished though as I stopped working on it when I got hold of Quake. I made a mod for that somewhere too, lol. It was just behavioural though.

Now that I have a reasonable workflow, maybe I can finish it.

[Karlos]

Finally getting some retexturing done. I have a candidate wall texture replacement for the old hand-drawn fractured rock, that works reasonably well with the newly added floor. One of the tricks I'm rediscovering is how best to get the right palette selection for walls so that they work well with the lighting.

I've also gotten some of the old vector object project files working again. They are mostly suffering from references to full paths that no longer exist but can be replaced with appropriate assign shortened ones. There's 112 polygons in the rifle... rather more detailed than you might think...

[abu_the_monkey]

nice! I like it. the new textures remind me of another mod I played many moons ago

[Karlos]

Originally Posted by abu_the_monkey

nice! I like it. the new textures remind me of another mod I played many moons ago

It started as this https://github.com/0xABADCAFE/karlos...remapped_2.png

However the engine doesn't do so well with this because it's not super happy with high contrast (picks odd colours for some texels) and to be visible in medium lighting need to be lighter. So you end up with less contrast and saturation to work better across all lighting scenarios:

https://github.com/0xABADCAFE/karlos...512x128-32.png

Still not happy with it, there's quite a bit of trial and error.

This one repeats after 256 pixels but the original one it replaces is 512. I plan to replace the second half with some variations.

It would improve the appearance and performance a lot of we could add MIP mapping to the engine.

[Karlos]

An easter egg I'd totally forgotten about...

[eXeler0]

Originally Posted by Karlos

It started as this https://github.com/0xABADCAFE/karlos...remapped_2.png

However the engine doesn't do so well with this because it's not super happy with high contrast (picks odd colours for some texels) and to be visible in medium lighting need to be lighter. So you end up with less contrast and saturation to work better across all lighting scenarios:

https://github.com/0xABADCAFE/karlos...512x128-32.png

Still not happy with it, there's quite a bit of trial and error.

This one repeats after 256 pixels but the original one it replaces is 512. I plan to replace the second half with some variations.

It would improve the appearance and performance a lot of we could add MIP mapping to the engine.

Is the palette fixed for the entire game like in Quake or is it per Level or how does it work? Regarding luminosity I think it could be a good idea to look at the original versions.
And +1 for the mip-mapping idea. Ever used TexMex testure editor? Has some useful tools

[Karlos]

Originally Posted by eXeler0

Is the palette fixed for the entire game like in Quake or is it per Level or how does it work? Regarding luminosity I think it could be a good idea to look at the original versions.
And +1 for the mip-mapping idea. Ever used TexMex testure editor? Has some useful tools

The game palette is fixed. As far as I can tell from the code so far, it doesn't do RGB (unlike AB3D 1 which does 12 bit), rather it takes time game palette and has a number of brightness steps between very dark and bright (which may be brighter than the original assets, TBC) and for each brightness level has another complete version of the palette where each index is mapped to the nearest value in the fixed palette. That way, you can take an input colour index and an input brightness value, and your output is another colour index that is the closest match for it. I haven't fully confirmed this but I'm sure it's broadly correct.

If true, I'd be interested in two things:
1. Making sure the palette can be loaded at runtime and the brightness variation calculated on startup. This could be done with proper colour theory to get the absolute best match based on HSV rather than shortest RGB distance.
2. Potentially replacing the lookup with a version that directly embeds the calculated output RGB values that could then be used to drive a proper RGB display on a graphics card.

Wall and sprite texture in TKG are weird. They are limited to 32 colour subsets of the game palette and are encoded into a format that packs 3 texels into a 16 bit word. This saves memory but I do have to wonder if the sacrifice was worth it. Floor and model textures are represented as normal 8-bit texels mapped directly to the palette.

[Karlos]

Regarding MIP mapping, if we assume for a moment that the columnar rendering proceeds along familiar doom style methods (where the wall texture is rotated 90 degrees so that as you work along the output column you are sampling the texture at increasing addresses) then a MIP mapped approach could seriously speed up the rendering of distant walls since it would improve cache hit rates. It also serves (when done properly) to filter noise and moiré effects.

However, let's not get ahead of ourselves. The game source code in it's current form is not especially amenable to such modifications. Even if it is updated, the second problem is that the tooling also needs updating.

[eXeler0]

Originally Posted by Karlos

Regarding MIP mapping, if we assume for a moment that the columnar rendering proceeds along familiar doom style methods (where the wall texture is rotated 90 degrees so that as you work along the output column you are sampling the texture at increasing addresses) then a MIP mapped approach could seriously speed up the rendering of distant walls since it would improve cache hit rates. It also serves (when done properly) to filter noise and moiré effects.

However, let's not get ahead of ourselves. The game source code in it's current form is not especially amenable to such modifications. Even if it is updated, the second problem is that the tooling also needs updating.

In quake, you have the .wad format and when you manipulate wads, adding own textures etc, the mipmaps are stored in that same package. Each textures is saved as 1: original size 2: 1/2 size, 3: 1/4 size and 4: 1/8 size.
If TKG handles individual textures, then yea, you're right, that would require some rewriting of the texture handling code both in game and editor.

[Karlos]

The problem isn't with the data format, that's by an indescribable margin the easiest thing to solve. The problem is that every last line of code in the game engine is written in assembler and all the editor tools are written in AMOS. The assembler code is not particularly clean or well organised which makes it difficult to modify in all but the most trivial ways.

One of the goals pipper set on the repository was to get and get the code into a cleaner, more manageable state. That needs to be done to some extent before trying to extend it.

Even if you do, you still have all the old tooling to update.

[Karlos]

I am having the craziest problem with LevelEd 303. It seems like it must maintain a graphical cache somewhere. I have a replacement texture wad for the rocky one which the game loads just fine but the editor will only allow me to use if it's got the same name. If the name is different (and the whole point of the link file is that you can specify each one), it can't be previewed at all. Yet, if it uses the original name, you can and it shows the correct one.

[Karlos]

Recently I replayed the project Osiris remake of AB3D1. It's so good. The level design compared to the majority of TKG is really night and day. That's not to say TKG doesn't have any good levels, it's just that some of the ones in AB3D are in a different class.

I have a choice to make. Do I continue making the mod just a visually tarted up version of the base game, or do I let it diverge? I already want to replace some of the maps that I felt were lacklustre in the game. I've never been a fan of Level C, for example. It introduces some important concepts like bridges and teleports, as well as several new classes of enemy but... This is supposed to be on a space ship? Even an alien compromised one? Really?

[eXeler0]

Originally Posted by Karlos

Recently I replayed the project Osiris remake of AB3D1. It's so good. The level design compared to the majority of TKG is really night and day. That's not to say TKG doesn't have any good levels, it's just that some of the ones in AB3D are in a different class.

I have a choice to make. Do I continue making the mod just a visually tarted up version of the base game, or do I let it diverge? I already want to replace some of the maps that I felt were lacklustre in the game. I've never been a fan of Level C, for example. It introduces some important concepts like bridges and teleports, as well as several new classes of enemy but... This is supposed to be on a space ship? Even an alien compromised one? Really?

IMHO you actually add replay value if you remake the maps different compared to the original game.
You can call it Special Edition or whatever to highlight the fact that its a modified game not just tweaked assets.

[Karlos]

As I'm in no mental state to contribute to the actual game code after a long and stressful day, I instead decided to revisit a bit of level redesign I'd planned long ago.

I had intended to make the bridge a bit more interesting but my original plan, it turns out, was just too ambitious, causing significant rendering issues. I'm not totally sure which rules I'd violated, but even doing it zone by zone, it just got to the "hall of mirrors" glitch. Probably too many zones visible at once.

Nevertheless, the bridge is now slightly ... Bridgier...

[ Show youtube player ]

[abu_the_monkey]

looking good!

[Reynolds]

Definitely better. I assumed that it is a bridge, now it looks like that much more.

[Karlos]

I've come to the conclusion that, with a few exceptions, any attempt to dither textures used for walls in the game generally looks bad. It may look good as a 2D image especially when mapping back to the game palette, but that's definitely a different use case.

Some of the levels used to create test cases for engine bugs have shown that clean textures generally work a lot better.

With that in mind I'm probably going to start reworking some of the textures I use. I also have a plan to condemn a few existing textures because they are way too overused.

[eXeler0]

@Karlos, whats your texture budget / map?

[Karlos]

Originally Posted by eXeler0

@Karlos, whats your texture budget / map?

It's not as trivial as creating textures for a modern 3D engine.

TKG has 16 wall texture slots, but the game is unstable if all are used.

Each wall texture can be any power of 2 tall up to 128 texels. The width can be up to 640 texels. The game can use any power of 2 width section (min 8 texels IIRC) of a wall texture as a repeating pattern, so you can fit a reasonable amount of variation in a single wall texture. The biggest limitation by far is that the texture has to be 32 colours and those colours should ideally be selected from the games palette. The natural instinct is to dither down graphics to those colours but while it looks OK as a flat 2D image, dithering patterns in textures themselves don't look good in 3D. I've been reworking some as a test, and they already look much better without, but it does make them that much harder to create.

There's a wall "atlas" preview of the mod textures here https://github.com/0xABADCAFE/karlos...view_Walls.png

[Karlos]

I'm planning to "condemn" several of these, in particular the original "brown wall with pipes" and the original "hullmetal tritile". And some of the basic doom derived textures that I'm not even using tbh. The big tritile, shrunk down to 64 will be handy for texturing crates and things that can fill cargo bays and the like.

Freeing up some full new slots will be good for adding some variety.