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

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: [0.6.0-452-gfc466849ce] Lighting isn't diminishing properly

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by mjr4077au » Sat Jul 11, 2020 7:44 am

I've done the other games, but Exhumed is being a shit because the player's Z position gets shifted in the game-side draw code before calling renderDrawRoomsQ16(). It might mean I need to have a game specific printcoords CCMD like I initially had for testing. It's extra code, but if I can't rely on the engine's coordinates to match the player's, then I'll have to. Will look further at it during the week.

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by sinisterseed » Sat Jul 11, 2020 4:47 am

mjr4077au wrote:Just to be sure, you're not entering them with that osdcmd_ prefix from the underlying code? Also, is your Duke 3D in 1.5/RR compatibility mode?

In a clean start up of Duke 3D using the EDuke32 code, you should be able to just type 'printcoords' at the console and get an output that you can use again for 'warptocoords'.

Not sure how one of my .cmd launchers actually got in there but it's absolutely not necessary.
Nah, user error, oops.

I was actually using your Coolie fix build, I thought it was the same but not really. It works correctly now, so if you can implement it in the other games too, this should be ready to go ;) .

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by mjr4077au » Sat Jul 11, 2020 4:15 am

Just to be sure, you're not entering them with that osdcmd_ prefix from the underlying code? Also, is your Duke 3D in 1.5/RR compatibility mode?

In a clean start up of Duke 3D using the EDuke32 code, you should be able to just type 'printcoords' at the console and get an output that you can use again for 'warptocoords'.

Not sure how one of my .cmd launchers actually got in there but it's absolutely not necessary.

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by sinisterseed » Sat Jul 11, 2020 4:09 am

I figured as much, otherwise you'd have said there already was a way provided by the backend but needed to be simply activated in the games.

I've tried testing out the feature in MJ's build but um... I think I'm missing the obvious - because both commands return an "unknown command" in the console. Something to do with that .cmd file I take it?

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by Graf Zahl » Fri Jul 10, 2020 1:23 pm

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

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by sinisterseed » Fri Jul 10, 2020 12:34 pm

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

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

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by Gez » Fri Jul 10, 2020 12:31 pm

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

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by mjr4077au » Fri Jul 10, 2020 6:19 am

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;
}

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by mjr4077au » Mon Jul 06, 2020 7:34 pm

Graf Zahl wrote: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 :)

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by Graf Zahl » Mon Jul 06, 2020 7:31 pm

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.

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by mjr4077au » Mon Jul 06, 2020 5:38 pm

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.

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by sinisterseed » Sun Jul 05, 2020 2:44 pm

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.

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by mjr4077au » Sun Jul 05, 2020 2:26 pm

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.

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by Phredreeke » Sun Jul 05, 2020 1:49 pm

mjr4077au wrote: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?

Re: [0.6.0-452-gfc466849ce] Lighting isn't diminishing prope

by mjr4077au » Sun Jul 05, 2020 5:40 am

lowskill. wrote: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)
lowskill. wrote: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...

Top