Reimpl/simple functions set 1

[gynt]

No description provided.

[gynt]

The cpp linter report is mistaken, there is nothing wrong with the function's formatting.

[gynt]

See comments

[TheRedDaemon]

If this is the entry function, we would kinda need another marker: These thing would only be relevant if we are going for the full/full match. I would consider this infrastructure.

[gynt]

yes I think this is related in: #231
I think I will even just move entry out of the OpenSHC scope in Ghidra.

[TheRedDaemon]

Actually tested these out of curiosity: Just to be sure, these where not tested together with the parent function?
That would be the only idea I had left: A shared file an them being static helpers. Might have caused pressure issues, assuming it does not inline.

[gynt]

I just tried by placing the calling function's body into the same cpp file ( and activating the reimplementation) but it didn't help.

[TheRedDaemon]

Had an epiphany on my way to work today: This works (test since it is easier for me to change the type this way):

    // GLOBAL: STRONGHOLDCRUSADER 0x00EE0FC8
    int test;

    // FUNCTION: STRONGHOLDCRUSADER 0x0053B5E0
    void Version::UpgradeMapUnitsTo_155()
    {
        // DAT_CurrentUnitSlotID::instance = 1;
        for (test = 1; test < 2500; ++test) {
            if (DAT_UnitsState::instance.units[test].logicalState != Units::ULS_INVISIBLE) {
                DAT_UnitsState::instance.units[test].killedFlagUnk = 0;
            }
        }
    }

This also works:

    // GLOBAL: STRONGHOLDCRUSADER 0x00EE0FC8
    int test;

    // FUNCTION: STRONGHOLDCRUSADER 0x0053B5E0
    void Version::UpgradeMapUnitsTo_155()
    {
        test = 1;
        for (int i = 1; i < 2500; ++i) {
            test += 1;
            if (DAT_UnitsState::instance.units[i].logicalState != Units::ULS_INVISIBLE) {
                DAT_UnitsState::instance.units[i].killedFlagUnk = 0;
            }
        }
    }

The compiler knows it adds up to the number and makes it a simple set, since not volatile and no function call is inbetween.

[gynt]

Ah clever! Great so the compiler makes the devs silly code smarter... (or less dumb). I was breaking my brain on why the 2500 assignment was somehow inside the for loop, but now it makes sense...

[TheRedDaemon]

Might also be parent file pressure that could provoke be the change? Also, you do you average on 81, it gets with the unroll a good bit less?

[gynt]

Yes 53% with the unroll. The != 2500 instead of the < 2500 was the good trick to prevent the unroll from happening.

[TheRedDaemon]

See my other comment, might be a similar reason.

[gynt]

Yes! Just the jne vs jl left because of the unroll prevention trick...

[TheRedDaemon]

Shared file.

[gynt]

So this signature (the carry over EDX beyond a call, could also happen to ECX) means /GL.

0x45b7fb : -mov edx, ecx
0x45b7fd : -call <OFFSET1>
0x45b802 : -mov edx, dword ptr [edx + esi*8 + 0x51f20]

yes /GL leads to 100%

[TheRedDaemon]

Yes, I always need to look them up again, but EAX, EDX and ECX are scratch registers. If they are used after a function call in msvc-x86 without being reassigned first, it means:

• For EDX and ECX that the compiler knew the function body.
• For EAX that the function may have returned something... or maybe it knew the function body? Have no example for this.

Of course the compiler may also do other stuff when the body is known, but these are very clear signs.

[TheRedDaemon]

I assume there is some split magic going on if this does not match. Or types?

[gynt]

No dice, I tried char * and:

        BOOLEnum TextureRenderCore::checkIfGfxTgxStartsWithTransparentPixels(int gfxIndex)
        {

            GMFileHeaderColorpalette* gm = (GMFileHeaderColorpalette*)(&(
                ((char*)this->gmAndGfxImageDataBuffer)[this->loadedGfxArray[gfxIndex].offsetInBuffer]));

            return (gm->unknown2 & OpenSHC::IO::Graphics::TT_TGX_PIXEL_HEADER)
                == OpenSHC::IO::Graphics::TT_TRANSPARENT_PIXELS;
        }

But stuck at 40%

[TheRedDaemon]

The magic is actually the return:

BOOLEnum TextureRenderCore::checkIfGfxTgxStartsWithTransparentPixels(int gfxIndex)
        {
            int byteIndex = this->loadedGfxArray[gfxIndex].offsetInBuffer + 8;
            byte checkByte = ((byte*)this->gmAndGfxImageDataBuffer)[byteIndex];
            if ((checkByte & OpenSHC::IO::Graphics::TT_TGX_PIXEL_HEADER)
                == OpenSHC::IO::Graphics::TT_TRANSPARENT_PIXELS) {
                return TRUE;
            } else {
                return FALSE;
            }
        }

They rarely use a direct condition result as return. So both variants are always something one could try.

[gynt]

Awesome. Didn't expect this form though based on the assembly.

[TheRedDaemon]

Please check again, I think these are absolute accesses to this object.
They sometimes do this and it gets hidden if ECX is set in Ghidra.

[gynt]

No, then fit sinks to 15%

[TheRedDaemon]

Yeah, I read Ghidra wrong, sorry.

As an apology, I found the mismatch reason: The signature is wrong. The function returns the entityID it receives again. 🙃

Notice that EAX is assigned after the call again before the return.

[gynt]

hahahaha love it thanks

[TheRedDaemon]

See my other comment, might be a similar reason.

[TheRedDaemon]

Yeah, I read Ghidra wrong, sorry.

As an apology, I found the mismatch reason: The signature is wrong. The function returns the entityID it receives again. 🙃

Notice that EAX is assigned after the call again before the return.

[TheRedDaemon]

The magic is actually the return:

BOOLEnum TextureRenderCore::checkIfGfxTgxStartsWithTransparentPixels(int gfxIndex)
        {
            int byteIndex = this->loadedGfxArray[gfxIndex].offsetInBuffer + 8;
            byte checkByte = ((byte*)this->gmAndGfxImageDataBuffer)[byteIndex];
            if ((checkByte & OpenSHC::IO::Graphics::TT_TGX_PIXEL_HEADER)
                == OpenSHC::IO::Graphics::TT_TRANSPARENT_PIXELS) {
                return TRUE;
            } else {
                return FALSE;
            }
        }

They rarely use a direct condition result as return. So both variants are always something one could try.

[TheRedDaemon]

Yes, I always need to look them up again, but EAX, EDX and ECX are scratch registers. If they are used after a function call in msvc-x86 without being reassigned first, it means:

• For EDX and ECX that the compiler knew the function body.
• For EAX that the function may have returned something... or maybe it knew the function body? Have no example for this.

Of course the compiler may also do other stuff when the body is known, but these are very clear signs.