[0.6.0-452-gfc466849ce] Lighting isn't diminishing properly

[mjr4077au]

Interesting. It seems the engine uses negative shades to mess around with its lighting. So the lower clamp to 0 needs to go, but the upper clamp to numshades needs to remain - without that we get undefined behavior in the renderer.

Would you like me to send a PR to change the clamp() to a max()?

EDIT: Implemented via PR #83 as an inline if as max() was not available and thought better not to drag in <cmath> just for this.

[Graf Zahl]

std::max should be available everywhere, I've used it quite a bit. Does this fix the problem?

[mjr4077au]

std::max should be available everywhere, I've used it quite a bit. Does this fix the problem?

I wasn't calling it with the namespace which was where the problem lied. Changed to std::min() and force-pushed. Working well locally.

[sinisterseed]

And now this got fixed as well, I'm surprised how tracing the origin of the issues didn't actually turn into a nightmare honestly, but it's very good that it did not.

Yet there's another issue now - these problems are getting ever more subtle, to the point that spotting the differences becomes very difficult. Frankly I would've probably never noticed the issue with the ship being darker, which is where disabling textures would've come in very handy to make spotting them actually possible. During regular gameplay it would be a nightmare to spot them, if at all.

[mjr4077au]

And now this got fixed as well, I'm surprised how tracing the origin of the issues didn't actually turn into a nightmare honestly, but it's very good that it did not.

I'll be honest, I was expecting a complete shitfight to try and find this which is why I put my hands up last night (was also 3 am lol)

But there's another issue now - these problems are getting ever more subtle, to the point that spotting the differences becomes very difficult. Frankly I would've probably never noticed the issue with the ship being darker, which is where disabling textures would've come in very handy to make spotting them possible. During gameplay it would be a nightmare to notice them, if at all.

I noticed the brightness issues with the theatre in E1L1 first, before I got that CVAR added, then went hunting and found the issue with the space craft. I used it for my demonstration as I thought it was a more compelling example. I'm actually yet to do a playthrough and compare spots without textures.

A big roadblock is most of the games have had changes to their player structs between the last release and head, so I can't even use saves between versions. Because the visibility is based around fviewingrange, changing the look angle changes visibility so you'd have to rely on the crosshair as a guide to ensure you're on target between testing each version.

In saying the above, from a casual playthrough things are looking pretty ship shape to me. Sadly though, I wouldn't be surprised if there were already little issues that have slipped through unknowingly. It's Build after all...

[Phredreeke]

A big roadblock is most of the games have had changes to their player structs between the last release and head, so I can't even use saves between versions. Because the visibility is based around fviewingrange, changing the look angle changes visibility so you'd have to rely on the crosshair as a guide to ensure you're on target between testing each version.

would it be possible to add a console command that teleports the player to specified coordinates?

[mjr4077au]

Possibly, but I think that'd have to be game-side and therefore done for each game. I'll have a think throughout the week.

[sinisterseed]

Indeed, teleporting to coords would be great.

This will be immensely useful for investigating issues, since it removes the need to go all the way back to the specific place where an issue is, would save a lot of time.

[mjr4077au]

I've had a think about this. I can print the coordinates from the engine, so that'll be one CCMD. Teleporting will have to be done game-side. You'd have one CCMD that'd call the respective game-side function via the GameInterface class to perform it. You can't just directly inject coordinates into the engine as the game-side code would just overwrite them the next time it draws the room.

I need to see whether I can make a CCMD that can accept multiple positional parameters. An example of calling the CCMD from the console might be:

Code: Select all

] warpplayer
Warps the player using coordinates in the following order: posx, posy, posz, ang, horiz.

] warpplayer 123, 456, 789, 111, 222

If I can't warp the player's position in one CCMD like that, there's no point in doing it otherwise you'd just telefrag from being stuck in a wall or something.

[Graf Zahl]

CCMDs get an argument array, you can pass as many as you need, just check how others do it. Since this needs to be on the game side I'd recommend to implement it in the game code like those that already exist in the various osdcmds.cpp files.

[mjr4077au]

CCMDs get an argument array, you can pass as many as you need, just check how others do it. Since this needs to be on the game side I'd recommend to implement it in the game code like those that already exist in the various osdcmds.cpp files.

Perfect, thanks for letting me know

[mjr4077au]

This build of Raze for EDuke32 has two new CCMDs: 'printcoords' and 'warptocoords'. Local testing has validated it does what it sets out to do.

If it's felt this could be a good debugging function, I'll implement for all the games and push to the main repo. The only main change I'd likely make is to not have a game-specific 'printcoords' CCMD, but just get the data straight out of the engine to save repetition.

Code: Select all

static int osdcmd_printcoords(CCmdFuncPtr UNUSED(parm))
{
    UNREFERENCED_CONST_PARAMETER(parm);

    auto &pPlayer = g_player[myconnectindex].ps;

    Printf("pos.x: %d\n", pPlayer->pos.x);
    Printf("pos.y: %d\n", pPlayer->pos.y);
    Printf("pos.z: %d\n", pPlayer->pos.z);
    Printf("ang: %f\n"  , fix16_to_dbl(pPlayer->q16ang));
    Printf("horiz: %f\n", fix16_to_dbl(pPlayer->q16horiz));

    return OSDCMD_OK;
}

static int osdcmd_warptocoords(CCmdFuncPtr parm)
{
    if (parm->numparms != 5)
        return OSDCMD_SHOWHELP;

    auto &pPlayer = g_player[myconnectindex].ps;

    pPlayer->pos.x     = atoi(parm->parms[0]);
    pPlayer->opos.x    = atoi(parm->parms[0]);
    pPlayer->pos.y     = atoi(parm->parms[1]);
    pPlayer->opos.y    = atoi(parm->parms[1]);
    pPlayer->pos.z     = atoi(parm->parms[2]);
    pPlayer->opos.z    = atoi(parm->parms[2]);
    pPlayer->q16ang    = fix16_from_dbl(atof(parm->parms[3]));
    pPlayer->oq16ang   = fix16_from_dbl(atof(parm->parms[3]));
    pPlayer->q16horiz  = fix16_from_dbl(atof(parm->parms[4]));
    pPlayer->oq16horiz = fix16_from_dbl(atof(parm->parms[4]));

    return OSDCMD_OK;
}

[Gez]

Why not just [wiki=CCMDs:Debug#warp]warp[/wiki]?

[sinisterseed]

Dang, really, there was already a similar command in the backend?

Hm... can we just make it work for Build games then?

[Graf Zahl]

iNot at all, because player location is not managed by the backend. It has to be done separately for each game