-
Notifications
You must be signed in to change notification settings - Fork 19
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
Legacy opengl renderer #420
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A bunch of spectator frags were being caused by processing the spectator's scout controls and/or not respecting the scout controls of players still in the game.
The crux of abort/frag problems is/was that the notification of the abort was asynchronous. But the other players in the game don't need to get the async message because they will get the abort key press so stop sending that message to active players. Also, there's no good reason to keep updating the frag checksum for players who are out of the game. This was also related to the previous problem where players were adding in the location checksum and stopping that addition at different times. This fix is really extra insurance that an aborted or dead player won't cause frags.
In fact, all objects with "angle" would just pull the last value parsed, for any object. This will set it to zero if not set in the current ALF node.
the solid logo in the middle of the hill seems to be the only difference between this level and the other levels that don't frag. Temporarily elevating them out of the way. Also I used Holograms for some but the Hologram doesn't respect "pitch". If Holograms work, we might consider adding pitch to CHologramActor similar to CSolidActor.
/dbg bsp --> outputs the bounds for all BSPs as they are loaded /dbg bsp 666 --> outputs bounds plus all points for BSP 666
Also fixed a minor bug with how grenade radius was being added to classic instead of fps ray distance. Not sure this will make any noticeable difference but it should be a faster calculation since it searches a smaller volume on each frame.
since smart missile movement is still interpolated, the RayTest needs to stay in the classic units.
Well, this is embarrassing. Most of the time FrameFromNow() is passed an integer. But there's an important call that passes a float on this check: while (FramesFromNow(latencyTolerance) > topSentFrame) { itsNet->FrameAction(); } Passing latencyTolerance as an integer was truncating the LT. For example, an LT=1.5 would be treated as LT=1 and result in less than the full LT of frames being sent on time.
* fix FramesFromNow usage many frame number checks were of the form if (doSomething < frameNumber) { doSomething = FrameFromNow(3) } For classic mode that means to doSomething at most every 4th frame. But for high-FPS, this code would start doing something on frame 13 instead of on frame 16... faster than classic. Changing code to work across frame rates like this: if (doSomething <= frameNumber) { doSomething = FrameFromNow(3+1) } * fix tests and bugs found by tests The HECTOR.Boost* tests had to be fixed because they were actually boosting on frame 1 since boostEndFrame inits to 0. * added 1 classic-frame limiter to the plasma shot so that all frame rates behave the same on shooting rate
When new levels are loaded the Hull and Level/Set menus are re-created from scratch. This would leave dangling pointers in nanogui::Screen (mDragWidget and mFocusPath). The "best" fix would probably be to replace all Widget pointers with shared_ptr<Widget>. But this is a quick fix that gets the job done. I also added "/dbg rload X" which will load a new level every X seconds. This was useful for recreating this bug but also might be useful for discovering other random level-load issues in the future so I left it in.
Update the FrameBuffer during the Window Resize event
…ng the GL FBO Window Resize event is ignored if the resolution didn't actually change The HUD bump magnitude is a lot lower when damage taken is low
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.