KarlosTKG now on GitHub

[Karlos]

I'm currently working on adding some more verticality to the level. The ludicrous discohall behind the blue door is getting moved down a shaft and I would like to try and alter it to be a bit more like system purge from AB3D1 if possible. Just a section, as a homage.

[Karlos]

I'm embarrassed to admit this, but I've only just realised that the upper and lower wall brightness offset tools actually work. Independent from point brightness, you can bias a wall brighter or darker. Previously trying to do anything with this control always crashed the editor, but if the zone is preselected from a previous tool, it works.

[Tsak]

Originally Posted by Karlos

I subbed to KK's channel when I saw the initial work on dread and saw your work, which is extremely impressive.

For AB3D2, there are some quirky limitations, but considering the constraints of Dread/Grind, they probably won't seem like limitations to you. Basically, all wall textures and sprites are limited to 32 colours from the general 256 colour palette. Wall textures can be almost any width up to 640 pixels and 8, 16, 32, 64 or 128 pixels tall. It is possible that they may be taller and wider, based on what I've seen in the engine code but certainly the tooling limits them to this.

The 32-colour choice is in part to save memory as 3 texels are packed into a single 16-bit word. Floor and object textures can actually be in 256 colours and are stored in the more obvious 8-bit per pixel arrangement.

The engine has 16 wall texture slots (only 15 are safely usable from memory), 16 floor texture slots (sigh) and 32 object texture slots (for 3D models). Floor and object textures are 64x64 pixels.

I am planning to add per level overrides to floor texturing for modding purposes, as having the same 16 floor tiles for the entire game is annoying.

Very interesting stuff. Basically the 32 colors for textures are equally restricting (obviously much less so than 16, but still). Means you also need a very carefully selected palette for optimal results. The cardinal sin of generic fps palettes (in general) is usually overusing grey and having ramps that do not work cooperatively (or can blend easily), which -more often than not- results to textures with almost monochromatic feel. This can also lead to loss of detail (especially when a conversion process comes in place), cause different materials tend to use specific color ramps, which by default are super limited under 32 colors (say a rusty panel vs a stone wall).

Regarding the texture slots, that's for the entire game? Or per level?
In Grind the latest level I made f.e. had 24 textures (64x64px - gets pixel doubled vertically). This includes 'dark' versions, but I'm hand picking them selectively to get more actual designs and wall variants in (like f.e. a dark variant might not be the same design as the full lit counterpart, or I might include less dark variants overall, in favor of other texture types). Other than that, the number of total 'slots' (per level) also varies, depending on the level/map data + assets (enemies, anims and such) used in the level. So it can be much lower (or much higher).

Something I found out btw to increase my texture options (and up the detail at the same time) was blending textures together. And by that I mean either have textures consisting of more than a single material or have them with extra structural parts (like columns and beams or other details) that can also be reused alone/separately. That way you can upgrade the complexity you see per scene, without having to always rely on extra geometry just to increase the detail. Plus it's an upgrade on color as well (usually strict, monochromatic corridors are rarely interesting or appealing), cause the more ranges from the palette the player sees, the easier is to mask that he's looking at 32 or (in my case) just 16 colors.

In regards to floor tiles, given we currently have zero floor/ceiling texturing, even 16 slots would be a massive improvement
Of course if you can override this limitation it's even better. Another thing you could try perhaps would be a palette shift per level, given you can map the floors to it's own subpalette. Using different colors is often more important than the tile design itself to vastly alter the feel of floor/ceilings and add variety.

Something else I'd like to ask. I've noticed that the source tileset atlas uses more colors than 32. I assume there is some conversion process going on to get the textures in-game?

[abu_the_monkey]

Originally Posted by Karlos

I'm currently working on adding some more verticality to the level. The ludicrous discohall behind the blue door is getting moved down a shaft and I would like to try and alter it to be a bit more like system purge from AB3D1 if possible. Just a section, as a homage.

cool

Originally Posted by Karlos

I'm embarrassed to admit this, but I've only just realised that the upper and lower wall brightness offset tools actually work. Independent from point brightness, you can bias a wall brighter or darker. Previously trying to do anything with this control always crashed the editor, but if the zone is preselected from a previous tool, it works.

so this is a bug in leved303, I do have the source code for this and amos pro somewhere, maybe I will see if I can get it to build as is and if so look into it.

[Karlos]

Originally Posted by Tsak

Very interesting stuff. Basically the 32 colors for textures are equally restricting (obviously much less so than 16, but still). Means you also need a very carefully selected palette for optimal results. The cardinal sin of generic fps palettes (in general) is usually overusing grey and having ramps that do not work cooperatively (or can blend easily), which -more often than not- results to textures with almost monochromatic feel. This can also lead to loss of detail (especially when a conversion process comes in place), cause different materials tend to use specific color ramps, which by default are super limited under 32 colors (say a rusty panel vs a stone wall).

The in game palette is not ideal, but it works well enough most of the time. Grey is rather overused and unfortunately it's not easy to change the palette at this time because a lot of pre-baked shading data that's incbin'd into the source assumes it. I haven't yet looked into exactly how it's structured.

Regarding the texture slots, that's for the entire game? Or per level?

It's for the whole game. However, each wall texture can be up to 640*128 and the wall drawing allows a power of 2 wide slice of the wall texture to be used at pretty much any 8-pixel offset. In my mod, I've tried to leverage this to get more variation in, so each wall texture is basically a mini-atlas for things with the same basic colour scheme.

In Grind the latest level I made f.e. had 24 textures (64x64px - gets pixel doubled vertically). This includes 'dark' versions, but I'm hand picking them selectively to get more actual designs and wall variants in (like f.e. a dark variant might not be the same design as the full lit counterpart, or I might include less dark variants overall, in favor of other texture types). Other than that, the number of total 'slots' (per level) also varies, depending on the level/map data + assets (enemies, anims and such) used in the level. So it can be much lower (or much higher).

Something I found out btw to increase my texture options (and up the detail at the same time) was blending textures together. And by that I mean either have textures consisting of more than a single material or have them with extra structural parts (like columns and beams or other details) that can also be reused alone/separately. That way you can upgrade the complexity you see per scene, without having to always rely on extra geometry just to increase the detail. Plus it's an upgrade on color as well (usually strict, monochromatic corridors are rarely interesting or appealing), cause the more ranges from the palette the player sees, the easier is to mask that he's looking at 32 or (in my case) just 16 colors.

Yeah that's basically what I've tried to do. The other thing is to just consolidate a lot of existing smaller textures that were a good colour fit to free up slots for other use. One thing I did was to create some red and blue tinted variations to allow some faked coloured lighting.

Something else I'd like to ask. I've noticed that the source tileset atlas uses more colors than 32. I assume there is some conversion process going on to get the textures in-game?

If you mean the big png image, it's all the wall textures pasted into a 256 colour image that uses the game palette. It's often out of date, but I use it to get an overall view of the assets. Each wall texture in the image is still only 32 of the possible colours. I also keep some 256 colour versions of graphics while they are being worked on, again almost always using the game palette.

[Karlos]

Originally Posted by abu_the_monkey

cool



so this is a bug in leved303, I do have the source code for this and amos pro somewhere, maybe I will see if I can get it to build as is and if so look into it.

The worst bug is that trying to remove a control point that has links just bombs the editor with an "illegal function" dialogue. I assume the intention was that the operation would just remove the links first and then remove the control point. The move control point tool has the same issue.

[Karlos]

Fake as it is, a bit of colour goes a long way...

[Tsak]

Originally Posted by Karlos

If you mean the big png image, it's all the wall textures pasted into a 256 colour image that uses the game palette. It's often out of date, but I use it to get an overall view of the assets. Each wall texture in the image is still only 32 of the possible colours. I also keep some 256 colour versions of graphics while they are being worked on, again almost always using the game palette.

Wait, so each texture can only be 32 colors overall, but can freely choose any color from the 256 palette? If so this is massively different (from what I thought).

The reason I was asking about a possible texture conversion going on was that from snapshots I've compared, some textures in-game seem to miss color detail and have less color bands included vs the ones in the atlas. I'm not sure if this is due to light conditions though and how that affects texturing.

f.e. if you're using the same hexagonal tile in this snapshot as the one in atlas : https://eab.abime.net/attachment.php...7&d=1683326539
it seems it has lost a lot of color detail.

Originally Posted by Karlos

Fake as it is, a bit of colour goes a long way...

That's awesome!

[Karlos]

Originally Posted by Tsak

Wait, so each texture can only be 32 colors overall, but can freely choose any color from the 256 palette? If so this is massively different (from what I thought).

That is exactly correct. In actual fact, you can use any 32 colours you want, but the tooling will try to find the closest 32 matches from the game palette, but it's rather hit and miss. Consequently, I always work within the game palette to avoid such conversion issues.

The reason I was asking about a possible texture conversion going on was that from snapshots I've compared, some textures in-game seem to miss color detail and have less color bands included vs the ones in the atlas. I'm not sure if this is due to light conditions though and how that affects texturing.

That area is at maximum brightness, which skews things a bit. The atlas file is slightly out of date but that floor hexagon is still the same. Worth noting that floor / ceiling textures use the full palette, not a 32-colour subset. Just another quirk.

... it seems it has lost a lot of color detail.

That will in part be due to the overbright lighting.

[abu_the_monkey]

I do have the source code for this and amos pro somewhere, maybe I will see if I can get it to build as is and if so look into it.

I think I found all the bits but am having no luck installing AmosPro at the mo, probably just tired and missing something obvious. I will try again tomorrow.

Fake as it is, a bit of colour goes a long way...

yes it does

[Karlos]

Originally Posted by abu_the_monkey

I think I found all the bits but am having no luck installing AmosPro at the mo, probably just tired and missing something obvious. I will try again tomorrow.

I am afraid I'll be no help there - I haven't used any basic dialects since Blitz Basic back in the 90's. Ideally, some day I'd like to start a replacement in C or C++ which are my goto tools for applications.

yes it does

Thanks. Just the hall of mirrors on the other side to deal with, lol

[Karlos]

Pushed some more changes to the retexturing branch for level C, if anyone wants to test it. The first corridor on the left that led to the blue key door is now behind a touch door to separate out the visual style a bit. There is some experimental lighting animation for it too, seems to work pretty well.

[Karlos]

Done messing with C for the moment as I'm neglecting the task at hand, which is to "deconaminate" the levels of the old hullmetal and stone step textures. I will come back to trying to make this level sensible at some point in future.

[Karlos]

Half way through replacing deprecated textures in level J. There shouldn't be any bright green grids in levels A-I by now.

[abu_the_monkey]

I am afraid I'll be no help there - I haven't used any basic dialects since Blitz Basic back in the 90's. Ideally, some day I'd like to start a replacement in C or C++ which are my goto tools for applications.

had a mare of a day, so the only thing I got done was installing and updating AmosPro to version 2.0. what an arse about face way of installing a piece of software that is... not very friendly

you have to use a .hdf and it needs to write a bunch of stuff to the boot partition ugh...

ended up just making a 20mb vanilla 3.1 .hdf and installed it to that.

now need to setup the numerus extensions that are required

all good fun

[abu_the_monkey]

Originally Posted by Karlos

Half way through replacing deprecated textures in level J. There shouldn't be any bright green grids in levels A-I by now.

are these changes on you git already? need something less irritating to do than fight with AmosPro tonight.

[Karlos]

Originally Posted by abu_the_monkey

are these changes on you git already? need something less irritating to do than fight with AmosPro tonight.

Yes, it's all pushed to the F for Fun branch, because I can't git very bestly.

[Karlos]

There's a PVS glitch in my Arena level which I'm classing as an engine but for now but it's more likely a clips generation bug in leveled. I haven't fixed it as it's more of a visual annoyance than anything. You'll know it when you see it.

[Karlos]

Originally Posted by abu_the_monkey

had a mare of a day, so the only thing I got done was installing and updating AmosPro to version 2.0. what an arse about face way of installing a piece of software that is... not very friendly

you have to use a .hdf and it needs to write a bunch of stuff to the boot partition ugh...

ended up just making a 20mb vanilla 3.1 .hdf and installed it to that.

now need to setup the numerus extensions that are required

all good fun

I know Amos is much loved, but I never got away with it. It was just too alien (irony bonus for being the tooling language of choice for Alien Breed). Blitz seemed a lot better. Never did try HiSoft, but I believe it was well regarded. I just knuckled under and chose C. If there is one thing I'm hoping that can be learned from the editor sources it's how the map data are actually arranged. Once we know that, we are free to break away from this particular dependency.

[Tsak]

Originally Posted by Karlos

That area is at maximum brightness, which skews things a bit. The atlas file is slightly out of date but that floor hexagon is still the same. Worth noting that floor / ceiling textures use the full palette, not a 32-colour subset. Just another quirk.

Well in this case it seems the light system absolutely killed the texture cause I'm counting 11 colors (in actuality they seem half that amount, as it's extremely close hues overall - extremely hard to distinguish) while the original has 23.

Do you know how lighting works in general? Is it real-time or baked in? And if it's real-time, does the total color count per texture fluctuates or stays the same?