 |
Probably related to the same class of problems caused by light conditions controlled via script. ( See attached trackers 3826 and 3840 ) |
 |
This is really an odd one. Both upon starting a new map as well when loading from a saved game the lightgem entity is created anew. All values that correspond to the lightgem value are stored for both the lightgem as well as the player class (the system is a bit redundant). I even tried initializing the values with zero on both classes with no effect. |
 |
I think this is caused by: 1) m_LightgemImgBufferFrontend / m_LightgemImgBufferBackend image double buffer. It is not saved/restored, so when you load a game, the first frame we analyze lightgem image from before loading the game. 2) In RenderBackend::DrawLightgem, I see additional triple buffer lightgemPbos. So after the first frame of simply old image, we get another 0000014:0000003 frames from PBOs with old contents. |
|
|
Why are we saving lightgem data when it is constantly being updated? Cant we just remove all save \ restore functions and force the lg entity to initialize on restore? |
|
|
We don't save lightgem data: in fact, saving it would reduce latency by one frame (our of 4-5). And I think the same problem happens on game start: there is no thing like "initialize lightgem". Moreover, the part of the code is deep inside backend. |
|
|
??? In player.cpp the save and restore blocks have m_LightGemValue, m_fcolval etc all related to phases of lightgem calculation. I tried just tinkering with removing them there but it doesn’t cure the bug. I next tried forcing values on restore but the only one that made a difference was fcolval and it also broke the lightgem after quickload. I also tried performing a buffer free in the restore function in lightgem.cpp but that caused a crash to desktop on quickload. I think the next things to try are: Reset the lightgem FBO every time load operations are called Creat a Boolean that is used the same as tdm_lg_interleave = 0 and have the restore function in player.cpp toggle it then have the lightgem function toggle it off so that at lease one empty lightgem cycle runs ( or use an int and have restore set it to 3 and have the lightgem decrement it ) |
|
|
Decrementing an integer to delay lg processing doesn't work. It breaks the lightgem for some reason... I will continue to tinker... |
|
|
Rev 10221 New cvar "tdm_lg_reload_delay" determines how many lightgem cycles should pass after reload before lightgem begins to render again. |
|
|
Nope, it does not work. First of all, I still see the lightgem blink full-bright, it just happens 3 seconds later. I imagine that this can allow guards to notice the player. Second, during these 3 seconds I can run into full-bright areas and my lightgem would be dark, guards won't notice me. And vice versa: if the save was made in full-bright condition, then lightgem will stay full-bright for 3 seconds after loading, showing me away. So you just inserted a huge delay, but did not fix anything. I think here is what's wrong: 1) You made it so that lightgem is not being calculated after load. Instead, you should make it IGNORED during the delay but still calculated, because you want to flush PBO triple buffer in backend. During the delay, use old lightgem value. 2) Don't put such huge delays. And why did you even set different delay for capped and uncapped FPS?! 5 frames should be enough, 2 frames should be not enough. If your experiments don't confirm this, then more analysis is needed, instead of just bumping the delay. 3) I'd say better save/restore m_LightgemImgBufferFrontend / m_LightgemImgBufferBackend members. That would technically reduce delay to 3 frames for the PBO buffering, and... just why not? Lightgem is a gameplay class, the tradition is to save/restore everything for them, why the exception? |
|
|
The idea was to grant a grace period after quickload. Ideally ( for this delay to work as advertised ) it would remain dark on quickload regardless of where the quicksave was taken (so I guess it only works half way). I guess we need an if condition to force lightgem dark on save but in my previous experiments such a toggle permanently breaks lightgem processing for some reason. I will try again to be sure. In my testing of this change, the blink when lightgem went active was significantly diminished from the original replication so I chalked that up to the restore data becoming active but I guess you are seeing a much brighter blink than I do? If it cures the original issue then I guess we can save\restore the bugger images. Still seems to be a waste of resources to be keeping this dynamic data in the save file. |
|
|
Testing complete. Commenting out the lightgem save\load attributes in Player.cpp does not break the lightgem. // savefile->WriteInt(m_LightgemValue); // savefile->WriteFloat(m_fColVal); // savefile->WriteInt(m_LightgemInterleave); // savefile->ReadInt(m_LightgemValue); // savefile->ReadFloat(m_fColVal); // savefile->ReadInt(m_LightgemInterleave); When you quicksave in a bright area, quickload renders as dark. There is a small blip when lightgem becomes active. I will test without uncapped FPS. Edit: Capped FPS ( com_fixedTic 0 ) behaves the same though the blip lingers longer in this mode. |
|
|
I also removed the shot and shot-spot save \ restore from Lightgem.cpp Has no apparent detrimental effect but does not cure the blip Tried setting the lightgem, color and blend color values to 0 during the decrement: } else { m_LightgemValue = 0 ; m_fColVal = 0; m_fBlendColVal = 0; lg_reload_delay--; Still getting the small blip. Lightgem still works though. |
|
|
Rev 10222 No longer differentiate between capped and uncapped FPS Don't save\load lightgem values in Player.cpp or Lightgem.cpp Directly control delay frames via the tdm_lg_reload_delay Force Lightem.Calculate to return 0.0 ( same as hidden player ) for 5 frames after the delay period has expired Now the reload "blip" is significantly reduced. |
|
|
Still 60 frames pause for no reason, and it seems that the blink still happens. Sorry, but I have replaced the fix in svn rev 10225. The new fix overrides final lightgem value for 6 frames after loading, WITHOUT stopping any kind of computations. I also applied it for starting/restating new game (override to full dark), since there was a bright blink there too. Experimentally, 5 frames override is the bare minimum to get correct behavior. Theoretically: * PBO triple buffering inside backend adds 2-3 frames of delay * frontend/backend double buffering probably adds 1 frame more * lightgem is rendered across two frames: one for top half, one for bottom half; adds 2 frames to overwrite old values if phase does not match Also it means that our lightgem has quite a big latency, something close to 100 ms. |
|
|
The fix works very well! I still think there is an argument for letting players define a delay for lightgem processing after reload but that can go into it's own bug tracker after some forum discussion. |
|
|
This delay is purely technical and it should be exposed to the user only for the case of emergency. We know our problems, we know why we need delay and how much, so we set it to the sufficient minimum or slightly longer. |
- Anonymous
