[All Versions] IF: Clipping issues in 1st room in 1st level

[mjr4077au]

In the room you start the game in where the explosion takes place, if you strafe into any of the angled walls, you sort of sink down into the ground. It's as if the angled part is some kind of facade, etc.

Not entirely sure what the 'clip map' that loads on initialisation, but perhaps that's not loading right? Issue does not occur in latest upstream build.

Also noted that the initialisation of IF is a lot slower than in EDuke32. Once it compiles CON files and loads the DEF file, the aforementioned clip file load takes excessively long to load, so I wonder if that's part of it also?

[mjr4077au]

The latest git head doesn't have this issue anymore. One of the upstream cherry picks must have sorted this out .

[Graf Zahl]

Scary how volatile this is, isn't it?

[mjr4077au]

Yeah it certainly is, feels like a good breeze could blow it over! It has to be c110c1018d14e32a9ef57a11564c09daefd7d9c2 that's fixed it from what I can tell.

I'm still articulating how you would/could redo this cleanly. Both EDuke32 and Redneck are full of if statements to slither in special conditions/hacks. RR is the worst, it's full of functions like these:

Code: Select all

void sub_299C0(void)
{
    dword_A99D8 = 0;
    dword_A99DC = 0;
}

int sub_299D8(void)
{
    if ((int)totalclock - dword_A99D8 >= 30 && buttonMap.ButtonDown(gamefunc_Crouch))
    {
        dword_A99D8 = (int)totalclock;
        dword_A99DC ^= 1;
    }
    return dword_A99DC;
}

Seriously, what the fucking fuck are they and how could they mean anything tangible to anyone else beside the author?

[sinisterseed]

Welcome to Build wonderland, where hacks and nonsense are at home .

Browsing through commits, some of the recent merges that added cleaner implementations of things made it pretty apparent just how much "if" and "else" are loved, noticed like 5 or 6 consecutive that got replaced!

[Rachael]

The naming nomenclature looks like autogenerated functions based on an approximate decompile of the code. My guess is at the time those functions were written (from the decompiled source) it was not known exactly what they did, so the names based on their address offsets remained in place.

[mjr4077au]

That would make sense given the reverse engineed nature of the game.

I'm a bit green at this, but wouldn't you be best to use the decompiled code to interpret how the game works, then write clean code based on the interpretation?

[Rachael]

Raw decompiled code almost never works, but that also depends on how good your decompiler is, so I would imagine it's a bit of a mix. What works without modification probably gets copy-pasted in and what kicks the compiler out of the loop gets rewritten as closely as possible. If you have debug symbols it makes things even easier because then you have some idea what each function does. (Debug symbols would preserve these function names, it is common practice to strip them for a release to prevent exactly this kind of reverse engineering, and also to save space as well)

Personally I've never done this successfully myself, but I have read some guides on the process and have attempted it with some even older games.

[Graf Zahl]

That would make sense given the reverse engineed nature of the game.

I'm a bit green at this, but wouldn't you be best to use the decompiled code to interpret how the game works, then write clean code based on the interpretation?

Yes, but don't forget that Nuke's overarching goal was not clean code but demo compatible code!

[mjr4077au]

That would make sense given the reverse engineed nature of the game.

I'm a bit green at this, but wouldn't you be best to use the decompiled code to interpret how the game works, then write clean code based on the interpretation?

Yes, but don't forget that Nuke's overarching goal was not clean code but demo compatible code!

pDwWl8d.jpg