19+ year gamedev here. The way we did this in the PS2 era was to treat every timer as a countdown. Our games also used variable tick rates, so the epsilon method would not have worked for us.
Is there even a reason to use floating point values for time instead of integers? This bug wouldn't have happened if timer was just an unsigned 32-bit integer that counted milliseconds. And the threat of overflow isn't something you should worry about, as it would take 50 days for overflow to occur.
@@danpc8685 30Hz and 60Hz tick rates cannot be accurately represented by using a 32-bit integer as milliseconds. Neither can Doom's 35Hz tick rate. Floating point can be tricky, but not unknowable. A 32-bit float with an exponent equal to 0 is essentially equivalent to a 23-bit integer. The step between representable values at that point is 1. Higher/lower exponents change the step between values, and being based in binary (ie powers of 2) means that representing 0.1 exactly is not possible. Also critical for understanding floating point is that it's just an encoding of a value. On the x87 coprocessors in use at the time Serious Sam was released internal calculations were performed at 80 bits of precision, not the 32 that the values are stored in. Using the SSE pipeline that x64 processors default to will result in different values for the same calculation. Controlling CPU flags is also critical to make floating point behave. The number of middlewares that mess with CPU flags and don't reset them when exiting their functions is annoyingly high. Denormals are the bane of my existence. Just about everyone has moved to double-precision for timers these days. Larger exponent support means you can get way way closer to that 0.1 value, so you need to be running for years to hit these problems (which isn't necessarily out of the room of possibility for a server-based multiplayer game with a strong community).
@@TheRealGooberMan this is Serious Sam though, and the tick rate is 20Hz, which is quite easy to represent with integers. But yeah pretty much anything else would be quite tricky to do with ints. I wonder if you could do something dumb like storing time in a fixed point format, that would both let you represent fractions while also not suffering from precision loss since it's fixed.
@@danpc8685 That's one of the common misconceptions for fixed point. It's still a binary representation, based in powers of two. The 16.16 fixed format that Doom uses means that the step between representable values is 1/(2^16), or 0.0000152587890625. Divide 0.1 by that for example, you still don't get a whole number and thus 0.1 is not representable in fixed point. The major reason fixed point is seen as more accurate is because floating point standards do not define implementation for most operations (hence hardware differences I mentioned earlier). Integer operations are very well defined by standards, and fixed point operations are done in software allowing complete control.
I never knew about this bug but just hearing the laser gun firing at the start I could clearly tell I had experienced it as I recall the sounds of the two different rates of fires.
Blast from the past, I remember me and my little brother playing the campaign in split screen and noticing this, but we were rocket and cannonball nerds so it never really annoyed us much.
It seems to be a really bad decision to use a floating point value to store the game tic like that. An integer completely avoids this issue; even a 32-bit integer has enough range for over 6 years of playtime at 20 tics per second. About the only advantage a float might have is that time values are written by developers in terms of seconds rather than tics, making it easier to change the tic rate during development, but even then, converting those values to integer tics at the first opportunity in the code is probably a better solution.
or just count the number of milliseconds since the start of the game. This gives 43 days before it overflows, and I think is a good compromise between the ease of specifying times in seconds and being "fixed point" and eliminating accumulated floating point error.
@@jinyuliu2871 **49** days using uint32_t or 24 days using int32_t And after 49 days there will be a single hickup and everything will probably work fine afterwards. With signed integers however, the compiler may legally make your program play Never Gonna Give You Up by Rick Astley.
Honestly, 6 years is probably longer than what floating point would realistically handle. The gap between each value floating point can represent grows as you move away from 0. And assuming that the float used in game rounds to the nearest value when adding. Once the gap between each value grows to more than twice the size of the value the game adds to the timer to progress it, the timer will just stop. As it will try to add 50 milliseconds, and then it will round to the closest value, which would be down to the value it started on. And then that will just repeat, never progressing the timer. I would love to see what it looks like in game when the timer reaches that point! :D My guess? Ai will probably stop working, every gun except the minigun will only fire one shot, (The minigun doesn't use the timer.) and the player might not even be able to move anymore.
Amusingly, IEEE-754 floating point numbers have always been a pain in the butt for computers and have best been avoided where possible. In the 80386 era, you needed a whole, separate co-processor to handle floating point operations. People grew too complacent. They're only really useful for quick approximations, and one must always remember that they *are* merely approximations when working with them. Using them for calculating anything involving money is a common, rookie mistake.
Weird how I remember playing this game years ago, and being vaguely aware of this happening, but just dismissing it in the back of my head as the weapons overheating or something, haha
Same. I loved Lasergun, but this bug was a buzz-kill. I thought that slow rate of fire was some kind of game balance that activates during gameplay to make this weapon not OP.
That's the whole job of a troubleshooter. The fix is easy, but getting to it is way worse. And trust me, I've worked quite few years in code maintenance.
One time when I was testing something (Doom-related, actually) the entire game collapsed into a hot mess for everyone after a new feature was added, though it worked fine from default settings. I spent over two hours looking for patterns in the mess, developing a hunch, and then making minor changes until I found how to replicate it. I refined that down to being able to turn on and off the bug in seconds. I turned in my report to the coders, who wrote back an hour later: It was a fencepost error. The system started counting from zero, the human interface started counting from one. All it took was a -1 in the right place to fix it.
There's more to the bug than this - if it was just a matter of floating point error in the time tick, you would have one shot fire one tick late, and then all subsequent shots would be at the regular rate, but one tick late relative to the beginning of the game. The other part of the bug is that the target times are not calculated correctly. Instead of adding the time delay to the previous time target to get the next shot, it adds it to the time at which the weapon was actually fired, resulting in each subsequent target time being almost a full tick late relative to the last one (because the actual time of firing was late). This is why the bug doesn't appear to "fix itself" after one shot being delayed by a single tick, but rather has a additional delay for every single shot.
the exact values where it bugged were interesting. 4096, 65536, 1048576 That is directly after surpassing 2^12, 2^16 and 2^20, or 4 binary digits apart, lasting until the most significant bit flips again. I assume there will be another instance at 16 777 216 or 2^24 and another one on 168 435 456 or 2^28 and on 4 294 967 296 or 2^32 (but the latter might already hit worse issues when hitting the signed 32 bit limit)
@@HappyBeezerStudios i'm pretty sure that no, you will not get that error anymore at 2^20: The error happens cause floating-point arithmetic has certain rounding-rules and while it can store from very tiny to very large numbers the precision is limited to 23 bits - that gives you about 7 digits in precision. But we are dealing with adding fractions to that number. At 2^20 trying to add 0.05 seconds will NOT add anything so at that point those weapons fully break down.
@@daimonmau5097 As i said - at the point where the time is that large already trying to add a small fraction of a second does literally nothing - the value no longer changes, so the weapons would not fire at all.
@@ABaumstumpf Aaahh, understood now. You said the value would not change anymore, so the weapon would just be waiting for a validation to fire, that would not come. Thanks.
this explains why so many rooms of Serious Sam felt completely unfair. I tend to take my time and I would probably have ended up just reaching the 3rd stage or so around when this bug shows up. I definitely noticed the sound of the laser gun changing, but I had/have so little experience with Serious Sam that I never noticed the weapon was actually firing slower! It's crazy how nobody on their team noticed it before releasing!
This is why its absolutely crucial that when you're doing floating point comparisons to pick an epsilon that makes sense with regards to the units of change you expect to happen between each check. The 0.04 epsilon makes sense because of the tick rate they chose, whereas 0.01 is kind of a nonsense epsilon. Its a very easy mistake to make with regards to floating point comparisons, however, and I've seen even very experienced programmers make it. That's why I try my best to avoid floating point altogether.
Good find and explanation decino. I used to be a software developer and in the late 80's, I used a Pascal library for a b-tree database. It included a database browser that would every so often not step correctly and/or not fill the screen with populated records. It turned out to be a _magic number_ in a routine used to populate the browser with updated records that was set too low (1 instead of 4). I was able to find this because I had the source code and after much testing I determined that my change fixed the issue. I emailed the company that developed the library and they silently updated the code a month or two later without any credit given or at the very least; acknowledgement. _Come on, I was young and wanted my 2 seconds of fame!_ Another time (during the early times of Windows 7), I developed a custom control for Borland's Delphi 7 to support Windows Task Dialogs which would use native calls for systems that supported Task Dialogs (Vista and newer) and emulate it on earlier systems (Windows XP and earlier). As I had to dissect the functionality and behaviour of this dialog, I kept coming across a bug that would clip the dialog under certain conditions (which I made sure didn't happen with my emulation). I wrote up a paper detailing when I had discovered and what conditions triggered the clipping bug and submitted it to Microsoft. After 3 months I got a reply which consisted of a single sentence... "Thanks for bringing this to our attention". This was the only correspondence I ever received and I could still reproduce the bug in Windows 8 (never checked for the bug under Windows 10).
That is why in banking systems it is usually recommended to not use it and to use workarounds if you need to display it. Ever noticed that in banking terminals where cashier manually inputs sum they don't input point between dollars and cents (or insert your local currency with it's part-showing currency)? That is inserting smaller currency and displaying it with workarounds/ When I was in school, that actually was part of our programming course to make such program, and part of testing was with big numbers to see who used floating point and who used only integers and to teach about this problem.
@@Xeotroid double precision floating points are just that, double precision. The errors are smaller and you might get away with it in more situations, but it still isn't safe with repeated multiplications and perhaps extremely repeated additions too. I'd expect performance to be exactly the same nowadays in most cases, with 64-bit processors everywhere. And if you really, really want performance, in a lot of cases you can use integers as if they were fixed point decimals, getting better performance AND perfect precision.
This also happens when you go too far in some games, polygons start distorting wildy because of the floating point error. I also remember my first encounter with this bug when I was making an inventory for a game.
@@HappyBeezerStudios No, not at all, not even close. Seriously - why are you spouting such pullshit? The PS1 famouse texture-warping comes from the lack of a z-buffer. There is no perspective for texture coordinates and as such triangles are treated as 2D and hence have wrong texture coordinates along the depth-axis.
It's a good reminder - never use floating point variables if you need precision or may workaround without them. They could just count milliseconds in Int64 and this bug would have never occured.
I know you hate SS2 and SS3, but I would hope one day you still analyze and play through them. Your videos on broken spawners are among my favorite, that kind of analysis is superb
That's a shame cause I really liked SS2, yeah the artstyle they took sam wasn't good but the gameplay is the same. I haven't played SS4 but I really didn't like 3.
@@YellowDice I feel the same way. The artstyle understandibly throws people off and I agree, it's really odd, but it doesn't ruin things for me because the gameplay isn't bad. SS3 on the other hand... oh my. Great graphics but man, it's just not fun for me. At all.
Really interesting video - it's interesting to see under the hood. It would be cool if CroTeam actually used this fix. I am kind of surprised that they did not use a tick-based integer counter for this.
Very cool analysis video. Watching your whole process for tracking down whats causing a bug to occur and then trying out a fix was awesome. Keep up the great work!!
I remember when the hype for Serious Sam 2 was hot. The polygon count was to be 1000x higher per monster, plus this and that. It was buggy, load times were atrocious, and it didn't work with some video cards at the time (mine included). By far, Serious Sam (the original) is the best in the series and gives me many good memories during a time when FPS were going through the "Anything like the Id Software formula sucks" phase.
I remember playing Serious Sam 2 and thinking how goofy and cartoonish it became. Still, I decided to play through the entire thing, and funnily enough feel nostalgic about it nowadays
Not sure if I have ever "encountered" that bug playing The Second Encounter. I played so much multiplayer back in the mid 2000s that the lag would slow down the weapon speed at times. Now, that I am not sure if the bug has a part of.
Ah yes, the weapon slow down bug which got me on my first playthrough of classic TFE and TSE. Glad to know there IS a way to fix it. Also, I wonder if you're going to do an analysis on the Cannon and how much damage its cannonballs lose while they're on the ground.
The same thing happens with the global timer (also counting seconds as a single-precision float) on Source games as well, but they probably got the floating-point comparison right so things only start to break down after months when firing intervals themselves get rounded due to lack of precision: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-RdTJHVG_IdU.html
I am interested. Your Serious Sam “Broken Kill Counts” videos are some of my favorites from you. I think there’s some potential covering more of Serious Sam and Quake in the future whenever you get burned out by DOOM but want to keep the content rolling.
A bug caused by the programmers at Croteam doing what tons of other programers have done for years. Overusing floating point. :> Though honestly, a lot of situations where floating point is used, could be better handled by integers or fixed point. (Which is just an integer with a portion of the bits representing the decimal. Much more efficient than the crazyness that is floating point. Not exponential though, but you don't need that the majority of the time.)
Floating point, so that Intel may thrive :D The competition was weaker at float for the longest time, which is why all the 5x86, K5, K6, 6x86, C3, etc did so much worse in games than they did in office workloads.
Both have their use and for many things floating-points are just way easier to use and more than precise enough. Take for example character movement. With floats you can store the position of a character quit nicely without having to constantly shift around the scale. You can have 1 being 1 meter and still go down to the 1 cm - only with very large open areas would the precision ever be a problem (like 8x8 km ). Things like vertex-positions, texture-colors etc can nicely are prime examples for were floating-point arithmetic is nice and simple. Of course you need to be aware on were to use them otherwise it can lead to such problems. But same goes for integers. I have seen problems were people used integers and it lead to some rather bizzar bugs - like when calculating the volume of objects. They stored the size in Millimeter and wanted to know how many of that object they could fit in X containers. Sure - IF the measurements are accurate and of a decent size everything is fine. But once you got small objects and many large containers - yeah, suddenly you need small and large numbers at once and the integer-number just is just silently overflowing. The hotfix was to calculate the same number with floats and compare if they at least agree on the order of magnitude as floats have no problem with those larger numbers. Now if those 2 results disagree it goes to a save integer-limit and displays the float-result with some warnings. @@HappyBeezerStudios Ah yes - the conspiretards with no clue.
Here's a fun fact. Your video was mentioned on a polish YT channel arhneu. It's in their latest "System error" thing. They basically simplified your explanation as a setup for the 1991 Patriot missile failure that happened due to the same floating point inaccuracy accumulating over time. Cheers from Poland!
This certainly is a surprise to see a serious sam analysis video, but a very welcome one. Pretty interesting too, im always fascinated how you dig into the game code to find all these mechanics and issues. Never before have i been interested in game coding, but your analysis videos kinda changed that☺
Just make sure that your assumptions and data-types are correct. With float even 1 might not be representable if it is part of a calculation: If the number is large enough (which really is not all that large) than adding 1 can either add more or less to the result. So - if you know that you have fixed timesteps then use a fixed format to represent that - like integers.
it may have taken 20 years, but someone FINALLY explained this very annoying bug, thank you very much for this! What's funny about floating point precision errors is this continues into the later games too, hell, in the 1st France level in Serious Sam 4 you can SEE it yourself as your gun appears to jitter by you looking around. This gets far worse if you head out to the secret radio at the end of the road.
Interesting! I do a lot of programming with real time simulations and I find these kind of floating point issues quite annoying. If there are no performance differences, I just use milliseconds or microseconds as unsigned integers instead of seconds as floating point. I think there is a bit of art to know when and what format to use and how to correctly convert between them when needed. :)
If all the automatic weapons fire at rates of multiples of 0.05s they could have just defined the wait time in tics, they could have avoided the floating point shenanigans like that. Or maybe I'm too used to tics being the shortest possible time in my doom mods. Most modern games use 0.1s for automatic fire rate, so I use a lot of 3-4-3-4 tic gallopps in gzdoom, that runs at 35 tics/sec.
I haven't watched any of your Serious Sam videos before, but decided I'd give this one a try, and you were right! It was a pretty interesting video... thanks again for another analysis vid Decino
I love the deep dive videos you do like this on weird niche bugs and oddities in games. I think it would be really neat if you expanded this type of video into other games. You definitely captured lightning in a bottle with this content.
It baffles me that Croteam decided to use floating point for a value that clearly could have done without a decimal to begin with, or could have used fixed point if they really wanted it. Since the timer should never go outside of multiples of 1/20, they could have had a fixed point and the decimal be represented as 5 bits, and increment the timing integer every time the decimal hit 20.
I've spotted floating point imprecision in one of my last projects in UPBGE, where a created a function to truncate flotaing point variables that have more then a specific number of digits. Depending on how I call this function, I can spot the imprecision, and it even causes some funny glitches.
decino: Verify the integrity of your game files through Steam. Me, a pirated gamer: *Sweats nervously*. Okay fr tho decino, i am glad to see u still treat Serious Sam and not just let it die.
Hey Decino, been watching you from the very early beginnings, your editing style and narration have gotten better and better and its Seriously impressive ( pun maybe intended). You make hard concepts like game engine breakdowns like this actually interesting. Congrats on 150k subs!
Cee cool too see a classic Sam video! I remember this bug very well, happened to me a lot growing up. Those games were my childhood. I still enjoy the modern games too despite the issues.
another way of fixing this could be by numbering every game tick and using that for the timer checks instead of the clock that uses floating point numbers. simply increment a global game tick timer every time the main loop...loops and schedule the next laser beam for the current tick + 2
Much cleaner but also requiring much more work, to adapt all the code using the counter. This dirty fix here is literally just changing one constant and in a pinch can even be done with a hex editor.
DUDE that was an amazing analysis!!! I loved it, especially because I just took the floating point representation class recently. That's the mark of a real programmer; finding bugs and fixing them. The way you approached it was very fun to watch and learn. Keep making great content like that.
So this is how PTSD works. I didn't remember this bug, but when I heard the sound of the lower fire rate, I started to feel myself very uncomfortable... Also, this video is very interesting. I had so much problems with float during my career, but this is still now to me.
I still don't know why but there's an immense satisfaction to these analysis videos even when i know about the topic they're analyzing already. They're really well made, you should feel proud.
Hey , a serious sam analysis after quite a while , really cool game tbh. Anyways , i once had a glitch that made me play in player 1 instead of player 0 which is default , I checked the settings everytime and it was always showing that I selected player 0 , this glitch was very very very infuriating , this not only means i had less ammo but i also had no Armor. This made me kill many of them save files and never got past elephant atrium . Sad 🙂
Hey, when I played a level from a save file, it spawned two Sams. One was controlled by me and other was stuck in mid air. As if the avatar that load the player was visible. Strangely though, he was the main target, not me. I didnt play long enough to see what happens next.
Very cool. I had no idea about this bug but it was obvious I was dealing with it in my current game that I had just reloaded for the first time in about a year. I thought the blue robot dudes were shooting really slowly, but I just figured I was misremembering. Time to work my way through more of this game though I guess!
I've hardly ever played Serious Sam but your explanation of game code is always wonderfully interesting :) Thanks also for providing some alternative options for fixing it!
Thank you for the analysis Decino, this bug is been bothering me since I was a kid, I can finally leave that ghost behind and enjoy the classic laser gun's star wars(c) firing sound without a slowdown
IIRC this is a pretty common bug in ports of games. I know for a fact that Super Mario 64 on the Wii had some strange issues with floating point calculations diverging, leading to platforms going out of patters and slowly raising into the sky. Leading to some pretty fun challenge run shenanigans.
That would also work, but I believe plenty of timing variables are dependent on 32-bit calculations (x.0f versus x.0) so you'd have to change several things in the code. For example, a simple TIME typedef change from float to double didn't work either without getting compilation errors.
I'm not that involved in the Serious Sam community, but I remember playing Revolution and it seemed like a pretty good technical/QoL update. What's wrong with it? What made decino make a joke with hiding it from his library?
Finally another Serious Sam! I love Serious Sam's analysis videos. It's not a bug, it's a feature. Guess you'll be punished if you're taking tok long xD 6:26 Lol. Wait what about the HD version? Also same bug? Does this mean we can become a hacker after modifying the game? Yeah, we're hackermen 😂
Personally, I would use an integer instead of a floating point just because of floating point imprecision. Also at a certain point adding such a small number to a floating point won't have an effect on the value of the floating point number itself. There's a reason databases usually store timestamps as integers.
Which databases are running timestamps as 64-bit integers by now? Will be necessary soon, no matter which format is used, so batter start the transition earlier than later. I know excel is not a database, but the 16-bit float precision of data in it is pretty obvious. (it uses days since 1.1.1900 for dates btw. With hours, minutes and seconds as decimals of the day)
I guess this is why Quake kept the time in double precision... except when it came to QuakeC. There everything is a float, so interesting things can happen with the order the entities get to think. This wouldn't really matter, but many of them sets up a "constructor" think function with a 0.1 timer that's supposed to run after everything spawned. Anyway, nice analysis video, long live fixed point!
While I liked the video and explanation, i have one question: what's the deal with not talking about SS:R? I thought it gave online multiplayer when SS resurgence came and when it was asked for.
I don't know if I mentioned it, but I enjoy you analyzing stuff and so have watched many of your videos just to hear you talk about niche things that otherwise haven't end up in your analysis videos. I'm still going through your serious Sam runs but enjoying them very much. I play them when I cook sometimes lol
Isn't making the episilon bigger just delaying the bug? Isn't it going to still happen if you play for a billion years? Also, what about a situation where the timing between ticks is unpredictable (like most modern games)?
The bug won't happen as the game simply stops working after ~292 hours of playtime. The better solution is to either use double precision or use a separate integer to track down ticks.
And I thought I was imagining things when I fired the laser gun... I didn't know it was a bug, I just thought it was because I used it too much ! Thank you for the explanation and thanks even more for the bug fixing method ! You rock
A new Serious Sam analysis video. This must have been really hard to find. It would be very interesting to see how does the immortal scorpion bug or glitch works in Serious Sam 3. I know it is there when the game is pirated and not bought legally. Croteam nailed it with that. It is also creepy to see the scorpion moving to you but the sprites aren't really moving
