-
Notifications
You must be signed in to change notification settings - Fork 130
fix(input): Fix double-click fast drive timing in ParticleUplinkCannon #2012
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
fix(input): Fix double-click fast drive timing in ParticleUplinkCannon #2012
Conversation
bedd3a9 to
4718d05
Compare
|
I could do a bit of testing and review for this For both 30hz and 60hz :
Does that seem right? |
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/ParticleUplinkCannonUpdate.cpp
Show resolved
Hide resolved
| Real speed = data->m_manualDrivingSpeed; | ||
| if( m_scriptedWaypointMode || m_lastDrivingClickFrame - m_2ndLastDrivingClickFrame < data->m_doubleClickToFastDriveDelay ) | ||
| #if !RETAIL_COMPATIBLE_CRC | ||
| if( m_scriptedWaypointMode || (m_lastDrivingClickTimeMsec != 0 && m_2ndLastDrivingClickTimeMsec != 0 && m_lastDrivingClickTimeMsec - m_2ndLastDrivingClickTimeMsec < data->m_doubleClickToFastDriveDelay) ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
m_lastDrivingClickTimeMsec != 0 && m_2ndLastDrivingClickTimeMsec != 0
Do we need to check this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If either of them are 0 we could get weird results right? Eg huge timestamp - 0 = big number, and if both are, 0 - 0 = 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't that also apply to the original code with frame numbers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, yes, added the null checks to the RETAIL_COMPATIBLE_CRC code too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't understand why it's needed, though. Is there a bug without this in the original code, or does the change to msec make it necessary to have these != 0 checks?
GeneralsMD/Code/GameEngine/Include/GameLogic/Module/ParticleUplinkCannonUpdate.h
Show resolved
Hide resolved
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/ParticleUplinkCannonUpdate.cpp
Show resolved
Hide resolved
GeneralsMD/Code/GameEngine/Include/GameLogic/Module/ParticleUplinkCannonUpdate.h
Show resolved
Hide resolved
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/ParticleUplinkCannonUpdate.cpp
Outdated
Show resolved
Hide resolved
4718d05 to
fdb318e
Compare
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/ParticleUplinkCannonUpdate.cpp
Outdated
Show resolved
Hide resolved
…l-time milliseconds
…non retail builds
fdb318e to
d3e0024
Compare
|
Replicated to Generals in the most recent commit, which differs slightly and is worth giving a quick look |
f33000d to
8e53756
Compare
…ing, add debug assertions
8e53756 to
c01dbb2
Compare
|
Tested this by making a savegame of a skirmish at max gamespeed, then loaded it back at regular gamespeed. Trajectory of the beam and beam duration appeared the same also using fast drive Using the compatibility flags I loaded a retail gamesave, and also saved a game and loaded that in retail. That works fine I thought it would be interesting to test 30hz and 60hz with the same gamespeed the way GO does it, stephanmeesters@7491c32 Double click felt the same, trajectory and duration the same It did have problems with the replay as the beam duration was no longer the same, but the gametime was also reported wrong, so that's probably just because I hacked that GO code in |
Closes #2011
Testing (TODO)
Fast drive mode activation via double-click now works consistently at any frame rate and logic time scale setting.