Supermodel Forum

If you want to skip some repeated math you can do:

Code: Select all

            indexByte1 = (yy^1) * tileX + ((xx + 0)^1);
            indexByte2 = (yy^1) * tileX + ((xx + 1)^1);


before the series of "if (TileX ==..." and substitute accordingly. And when (tileX == 1) use indexByte2

HarryTuttle wrote:I've to add that it's not the first time Supermodel compiled with gcc doesn't crash for out of bounds array indices. The last case was an off-by-one-error that should give, as I've read, unexpected results.

There are only three really hard problems in computer science:

1. Naming things.
2. Off-by-1 errors.

Someone here suggested to compile with these arguments: -fsanitize=address -ggdb, explanation here.

I've tried that but when linking it throws out an insane amount of errors relating to m68kmake.c, PPCDisasm.cpp, Z80Debug.cpp, etc... plus some other MSYS2 includes...

I don't want to even remotely mess with those things.

One day I'll go through and fix these issues. Musashi 68K is really old code and probably not standards compliant anymore. Shouldn't be too hard to fix, though.

If you use std::array instead of just array[1]
You get checked interators in debug mode, which is kind of handy. But it's also very slow in debug mode.

PATCH for r684:

- Improved/Simplified algorithm for 8 bit textures in StoreTexture function
- Deleted StoreTexelByte function
- Fixed the smallest texture lods (1x1, 1x2, 2x1) for 8 bit textures, now they're graphically correct.

HarryTuttle wrote: The performance impact is almost imperceptible. Patch pending.

does it means more fps harry?

scd wrote:does it means more fps harry?

Well, actually means that there's a little, if any, fps loss. But considering that soon I'm going to post a new patch to improve texture uploading mechanism, I think in the end there will be a general gain in fps.

HarryTuttle wrote:

scd wrote:does it means more fps harry?

Well, actually means that there's a little, if any, fps loss. But considering that soon I'm going to post a new patch to improve texture uploading mechanism, I think in the end there will be a general gain in fps.

sound very promising. there is any name for this patch? i will look forward too.

scd wrote:there is any name for this patch? i will look forward too.

Keep looking at this topic, since I created it for everything I'm working on related to texture. I'll also update from time to time the first post which contains a summary of this subproject.

thanks harry

PATCH for r700 (1st of two "interim" patches before next big update):

- Reworked micro texture scaling factor, now it matches the arcade.
- Removed from SetMeshValues() two checks for "textured" and "microTexture" state, since it's always ok to fetch those values from polygon header. Shader uniforms, in this case "microTextureScale", will receive valid values anyway.

Micro texture mapping coordinates are scaled by a certain factor before fetching texture data. It turns out that the scale is the ratio between the base texture size and the micro texture size (which is assumed to be always 128x128) *pre-divided* by "2" for "N" times. This "N" is the value obtained with 2^ph.MicroTextureMinLOD().

In pseudo-code:

Code: Select all

microTexCoord = baseTexCoord * (baseTexSize / (128 >> (1 << ph.MicroTextureMinLOD())))

This is apparent in Daytona 2 because ph.MicroTextureMinLOD() is "0", "1" or "2". Other games usually set only "0". Skichamp also uses many values and could be a good reference but there're no good quality videos around.