ProjectOutFox
patreon
Weekly Dev Update!
🕑 Added 2020-12-08 12:19:20 +0000 UTCA day late as i forgot to post this yesterday, we were testing stuff i wanted to ensure worked before being excited for it!
Those of you who know the pain and dedication of playing stamina, or wondering why there is a slight issue with accuracy or looking at the timing and then checking the graphs in evaluation to see how you did will understand the importance of the above image in the title.
There has been a complete rewrite of the way threads are called and set in the next alpha of OutFox. I will explain a little about this for those who do not follow - in windows, there are several ways to call commands when the vsync system is set up. In 5.1/5.0 these were all set to be a specific call per operating system, and had not been updated for over 12 years, however, they worked somewhat even if they were hacks or 'patches' to make this happen.
In 5.3 we were forced to rewrite most of the input and window system to use modern practices (primarily due to MacOS 10.14, but it's been found that linux and windows also benefitted) and this resulted in a unified driver that works as designed across all operating systems and something we had a lot more control over, as well as providing a much easier streamlined codebase to debug. This resulted in two things: massive support of controllers and devices, but introduced a quirk we were not expecting, which was Lua's Message Loop. Due to old arch code, this runs at the frame rate on the system at any one particular time, and we did not notice that there were snippets of code from the SM4/3.95 days which still interfered with this loop even today.
We had several reports of 'polling' errors in OutFox, which was odd, as when we wrote the new input system, we could see the millisecond timing, and the fact it was not being set to a poll/frame rate time, so at the time it was incredibly difficult to work out why this was a problem. It's been an open bug on our issues tracker for some months.
Example of a "polling" error - note the spikes, and the average (mean) error. (1000/60 =16.67ms ish, so this is considered a frame rate fixed update issue)
There are cases where actual devices CAN cause polling errors, but the users reporting this were not on any of those, so it was quite confusing. We didn't completely dismiss it, and kept it in the back of our minds. In November, Jous began work on pandathreads, which was to fix a lot of the mutex errors in the game (in english, a mutex is when something can run or not, and can be locked or unlocked). We found out once the initial work for this was completed, that Lua was the issue on what appeared on this input block.
We did some testing last night on this one, and removing the block of code from 2007 fixes the final missing piece of the puzzle. This bug also affected modfiles and some animation effects, so it is a boon that it's removed. We are preparing to move to a brand new 64bit build, and the changing of the thread quirks in the old codebase was long overdue.
We also identified two more stutter sources in the game, and sadly they are all due to the sound driver. This is somewhat due to be expected as they are extremely old, and as a result tend to not follow modern requirements. ALSA on Linux is a prime example of this, and will be updated in due course.
Fixing this message loop and the threading issue with lua finally means vsync will work on the windows and linux system without problem, and we hope to have this concluded for 4.9.6's hotfix release.
Hope you all had a good weekend, and stay safe my friends
