Mipmapping doesnt work in doom 2 or later chapter 2 of doom

[Cavencruiser]

Doom2 mipmapping doesnt work, only with a few select textures which are shared from doom 1. None of the doom2 exclusive textures seem to mip mapped. Everything from mid chapter 2 of doom and beyond doesnt work with mipmapping either.

[doomhack]

The 'mipmapping' is a performance hack for composite textures (I.e textures that are made of multiple patches) and only where the patches overlap. (Eg a decal drawn over a base texture)

For composite textures we store the column pixels in a 16kb cache. The mipmapping helps improve the hit rate on this cache.

Textures that are made up of one patch (or don't overlap) are drawn directly from ROM and so they are drawn at full horizontal resolution as there is no performance benefit to mipmapping them.

I'm guessing the Doom2 textures didn't use multipatches too much.

[FrenkelS]

Is that the reason for (c >> 1) in CACHE_HASH?

[doomhack]

Yes, that is part of it. We drop the low bit of the texture column when we compute the cache key. (Columns are stored in an associative cache)

The actual 'mipmapping' is done in R_ComposeColumn with the colmask. We drop low bits of the column number as it gets further away from the player by looking at the iscale var.

There is an exception for very narrow textures <= 8px so that stuff like the key colour door texture doesn't get destroyed.

[Cavencruiser]

does the multipatch textures benefit from the use of mipmaps? aren't they also drawn directly from rom too? I'm asking because I decided to remove the check to disable the mipmaps in high detail mode and I seemed to gain 2fps in large rooms that use giant multi patched textures for walls from doing this. Can you please check my work on my fork and verify if I properly did this? Are there other lines of code that also need to be voided or is the only check for high resolution textures in the whole source? I'm new to coding, so I dont know if what I did to the source directly negatively impacted the optimization as a result. Much appreciated if you have the time to check.

https://github.com/Cavencruiser/GBADoom-kippy-retail-gba-controls-merge-

[doomhack]

Multipatch only goes through the column cache if it has patches that overlap each other.

We store this in the overlapped member of texture_t.

Overlapped state is computed in R_LoadTexture().

[doomhack]

A good test case for mip-mapping is here:

On get 15fps. Off and we're down to about 11.

[Kippykip]

The 'mipmapping' is a performance hack for composite textures (I.e textures that are made of multiple patches) and only where the patches overlap. (Eg a decal drawn over a base texture)

For composite textures we store the column pixels in a 16kb cache. The mipmapping helps improve the hit rate on this cache.

Textures that are made up of one patch (or don't overlap) are drawn directly from ROM and so they are drawn at full horizontal resolution as there is no performance benefit to mipmapping them.

I'm guessing the Doom2 textures didn't use multipatches too much.

I always wondered, instead of having multi patch textures, would it help performance by just having a single graphic for each wall texture instead?
Like what the Retail GBA Doom 2 does?

I understand it will probably use more ROM space and require some changes in the WAD itself. But it's something I've thought about.

[doomhack]

Yes. and no. Just flattening out the textures makes no difference to performance (I tried it) as the column cache is stored in VRAM which is faster than ROM.

What flattening out the textures will do however, is free up 16kb of VRAM which could be used to speed something else up a bit.