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.
@@semicolontransistor **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.
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.
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.
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.
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!
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.
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).
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!
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.
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 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.
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.
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
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 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.
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.
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.
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.
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.
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.
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.
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. :)
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: th-cam.com/video/RdTJHVG_IdU/w-d-xo.html
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!!
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☺
I FREAKING KNEW IT. When I was a wee scrub I loved the Laser Gun (still do tbh) and everytime it started to slow down I just convinced myself that IT GOT DIRTY BECAUSE OF THE SAND. Talk about being stupid, but back then even a 6 year old me noticed that the gun doesn't work like it's supposed to be working.
After hearing the problem statement I instantly suspected some rounding error with floats - pretty much any bug where something doesn't work after waiting a while is either misused floats, integer overload or some memory leak. It is however impressive that the problem later just disappears again.
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.
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.
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.
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.
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.
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!
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.
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.
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.
I am impressed, normally these sorts of videos are 99.9% fluff you have to scrub through to find the tenth of a percent of information. This video actually has meat on it. Very nice.
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
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?
I'll be honest, I don't play first person shooters and have no real training or education in software development. But I am a gamer (simracer, specifically) and make a living as a mechanical design engineer, and watching your game mechanic analysis videos is always enjoyable. You have a gift for explaining complicated topics in a straightforward and understandable way, something I've always seemed to struggle with. A pleasure as always
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)
That's exactly why, when I was debugging this project, I started using numbers of the power of two. If we take for example the number of ticks 64, and divide 1/64, we get 0.015625, and if we increase the total number of ticks by 1/64 each tick, then there will be no problems with the accuracy of the floating numbers.
I only took 1 year of programming back in highschool, and I barely remember a thing, but every time I watch one of these a little nugget of knowledge resurfaces. Its like "oh hey I actually know what that is"
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!
oh I never knew this was a bug.. i remember this back when I played serious sam, and just attributed it to slowdown from lag in certain levels or areas from the sheer number of enemies/projectiles, or whatever that's going on in the massive levels..
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 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
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 😂
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.
Hearing you say "Beaks make me coom" every time makes me laugh and laugh. I'm not that guy, I don't know him or know anything about him, but just hearing it in that perfunctory, matter-of-fact way is hilarious.
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
Honestly decino, you could do this kinda video with any game and I'll watch it. It's because it's vicarious. When anyone encounters a bug they wish they could fix it, so when we see you discover a bug, diagnose it, and fix it it's like we ourselves vicariously fixed it and it's pretty satisfying.
You seem to be very code savvy. Can you make a video where you talk about your technical background (education plus the kind of jobs you did after graduation) in the future? It would be interesting to see how you became so good at analyzing code from open-source projects.
As someone who also has interest in the Source engine and TF2, the very instant you described the bug, I could immediately point my finger at floating point precision and timer systems.
By coincidence (probably) Doom 2 and Serious SAM FE + SE were my childhood. I recognized that slowed xl lasergun firing sequence from anywhere. I also remember a "weapon reset" bug as a kid where if you used a macro to fire it the bullets became a solid laser beam an infinite firerate as fast as you can pull the trigger. Also lmao what it went open source? That's actually awesome. Loved the OST playing in the background and lmao 6:29 floating point legs
Wow. My experience with Serious Sam is very limited as I struggled to play it for extended periods of time, but from being unaware of this bug, to watching this video and listening to you go in-depth about it, this was incredible. I hope no one has criticized you for this not being a Doom analysis video, I have all the confidence in the world that you could analyze anything and make it interesting, just by talking about it. As always, thank you for being you.
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
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 variable tick rates are a pretty major one
@@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.
THIS, hearing that again opened a lot of old vaulted memories I had of that time, jesus!
Yeah I always thought it was my oldass computer slowing down to deal with the higher enemy count that happens an hour in
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.
Same here. I remember noticing it, but always assumed it was related to the audio system somehow
same here!
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.
@@semicolontransistor **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.
One of the times where fixed point work better.
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
Hey, it's not a bug, it's a feature!
@@Folisaa many such cases! So many inventions innovated by "accident"...
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.
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.
@@ABaumstumpf break down how? They would stop working or freeze the game?
@@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.
Surprised how interesting I found this one! Looks like finding the issue was more difficult than fixing it.
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.
That is so true. Whenever I try to fix the code, I can't find the error, but fixing found error takes a really short time.
Welcome to software development
@@ivailok3376 TFW you spend the whole day debugging and the fix is a single line of code.
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.
Unlike the floating points, we were precise in finding the reason for the bug.
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.
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!
I've always been a bit sus of floating point. Feels like should avoid it if you're not really using it to show floating point numbers to users.
Or you can use double precision floating point numbers. No clue how they affect performance when there's a lot of them, though.
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.
Yeah fixed point is a lot better
@@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.
@@Xeotroid i think that serious sam would be 32 bit, so it wouldn't work. unless doubles are 32 bits
Decino could figure out all of life's problems if he could just get access to the Open Source for life.
thats cool, I never thought that floating point numbers can affect the game THIS way
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).
Amazing knowledge
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!
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.
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.
That basically describes why graphics on the PS1 are warping around. lack of floating point precision.
@@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 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.
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
Agree. Seeing a 100% walkthrough and analyzis of bfe (fusion and vanilla) would be rly rly nice.
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 the gameplay in ss2 is not the same at all. Completely braindead.
@@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.
Idk if we can even check all of the spawners for SS2, as for SS3 there is only one broken spawner in the entire game, a kleer in the dark bride level
I really hope Agonizing Rectal Pain never unsubscribes so you have to keep reading his name at the end of each video
Some of us are actually happy to see you do Sam-related stuff again. We miss those days :)
I laugh every time decino is forced to say "AGONIZING RECTAL PAIN"
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.
There is a chance it might be. Decino's video on broken kill counts had them fixed in Revolution.
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
Serious Sam 2 is my favorite in the series
@@MrCh0o first time i saw it i was just blown away by the graphics. it was the first game with xbox360-level graphics (even if on the low end of that)
Do you mean Serious Sam 2, or 2nd encounter,
Lesson: never use constant values in your code that are not exactly representable.
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 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.
Same bug occured in the guiding system of a missile. Over years the actual time got so screwed the missile missed the target by 70 meters.
the moral of the story: just because it has a decimal, doesn't mean you should make it a float
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.
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.
And how much time it's required to destroy a ground cannon via Rocket Launcher or Grenade Launcher.
You could create an entire mathematical graph of damage-per-time about the Cannon. I'm into it.
If you're playing HD, then 0?
Doooo....eeeeeettttt...Decinnnooo...
This is AMAZING. I can only vaguely recall this bug back when I played it more often. It's a weird oddity!
I'd definitely love to see more Serious Sam analysis and mechanics explained in the future!
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.
I guess this is Serious Sam's "You Suck" taunt after 1 hour, except now it comes with a physical penalty. Cool video. :)
what can we say, sometimes you just gotta be a gamer for more than 1.5 hours
Fancy seeing you here
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.
Using floating values for game tics, which are in their essence integer... cursed.
I don't understand either. Probably so they can interpolate stuff between ticks? I don't know.
5:35 It's actually a 33% decrease. You have 67% speed left. ;)
Yeah, I noticed that too late. Whoops.
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.
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.
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. :)
Where does it get the timer from?
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: th-cam.com/video/RdTJHVG_IdU/w-d-xo.html
Oh yeah, I've seen this happen in Quake II back in the day as well.
@@decino How long were your Quake II sessions my man, holy moly.
@@nooneinparticular3370 In tf2 people sometimes host servers 24/7 without restarts (or even the round ending), which is how I encountered it.
Ah yes shounic, the decino of TF2.
The step isn't that hard from Quake to GldSrc to Source.
I wonder if the bug is still there in CS:GO, Apex and whatever the current CoD is.
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!!
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☺
I remember your SS playthroughs being really fun and relaxing to watch. More SS content is always appreciated!
I didn't expect such a deep look into this. Very good video and I appreciate the extra steps of explaining how to fix it. Great work Decino!
I FREAKING KNEW IT.
When I was a wee scrub I loved the Laser Gun (still do tbh) and everytime it started to slow down I just convinced myself that IT GOT DIRTY BECAUSE OF THE SAND. Talk about being stupid, but back then even a 6 year old me noticed that the gun doesn't work like it's supposed to be working.
Hol up, 3 days ago? 78k views? That's what it has right now!
After hearing the problem statement I instantly suspected some rounding error with floats - pretty much any bug where something doesn't work after waiting a while is either misused floats, integer overload or some memory leak. It is however impressive that the problem later just disappears again.
It's not a Doom video, but it is a floating point precision video, so I'll allow it.
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.
If they used 0.125f, a power of 2, then it wouldn't be a problem at all.
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 🙂
Did anyone else experience this or am I the only one? Also if anyone knows , can they try to explain this glitch
Never heard of that glitch before. Curious if anyone else has.
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.
The game has splitscreen and network play splitscreen so some arcane combination of either can probably lead to what you're describing
@@radicalone2458 ya exactly
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.
The analysis videos are my favorite videos to watch from you, no matter the game.
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.
That's one Doomed Serious Sam bug.
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.
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!
Many users that remember meeting this channel with Serious Sam video uploads are dropping a nostalgic tear
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
Nice, much cleaner solution! And use it modulo of the max value of the (unsigned) integer type for overflows resetting back to 0
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.
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.
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.
I am impressed, normally these sorts of videos are 99.9% fluff you have to scrub through to find the tenth of a percent of information. This video actually has meat on it. Very nice.
Makes perfect sense. Very good find and really nicely explained. Once again, another brilliant video by the legend.
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
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?
The performance and netcode is worse than the classics.
@@decino this calls for an in-depth analysis! ;)
@@decino as a non serious Sam player, please explain. Performance is very broad.
Performance as in FPS?
I'll be honest, I don't play first person shooters and have no real training or education in software development. But I am a gamer (simracer, specifically) and make a living as a mechanical design engineer, and watching your game mechanic analysis videos is always enjoyable. You have a gift for explaining complicated topics in a straightforward and understandable way, something I've always seemed to struggle with.
A pleasure as always
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)
That's exactly why, when I was debugging this project, I started using numbers of the power of two. If we take for example the number of ticks 64, and divide 1/64, we get 0.015625, and if we increase the total number of ticks by 1/64 each tick, then there will be no problems with the accuracy of the floating numbers.
So glad to see some Serious Sam content.
And also really interesting one.
I only took 1 year of programming back in highschool, and I barely remember a thing, but every time I watch one of these a little nugget of knowledge resurfaces. Its like "oh hey I actually know what that is"
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!
oh I never knew this was a bug.. i remember this back when I played serious sam, and just attributed it to slowdown from lag in certain levels or areas from the sheer number of enemies/projectiles, or whatever that's going on in the massive levels..
Great video! Would changing the timer from a float to a double or long double be another way to solve this?
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.
Oh good point. I remember being told by a croteam dev that changing the sizes of types would introduce lots of bugs.
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
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 😂
HD versions don't have the weapon slowdown bug.
trojan horsing in some light compsci in these videos and keeping it entertaining is masterful mate - top work
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.
The performance and netcode is not as good as the classic Steam version, that's all. Also Bright Island is a joke.
Can confirm that the load times are atrocious. I should not have to wait multiple seconds during a “quickload.”
Hearing you say "Beaks make me coom" every time makes me laugh and laugh. I'm not that guy, I don't know him or know anything about him, but just hearing it in that perfunctory, matter-of-fact way is hilarious.
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.
@@decino Would there be enough content to make a video on that? That sounds interesting.
@@decino I remember playing on a server and it was acting like this, you should do a video it looks cool
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
I swear the Devs of this series are on crack
I dont know whats going on but its relaxing. I often watch your videos in bed or while having a midday nap, never stop
Can you do a analysis of why my marriage is not working?
I know this is a joke, but damn if I wouldn't love to see decino do that video.
a decino Serious Sam analysis video in 2022? A surprise to be sure, but a welcome one!
I'd like you to branch out to a few more games, DOOM is great and all, but there are other stuff from other games just as interesting
Honestly decino, you could do this kinda video with any game and I'll watch it. It's because it's vicarious. When anyone encounters a bug they wish they could fix it, so when we see you discover a bug, diagnose it, and fix it it's like we ourselves vicariously fixed it and it's pretty satisfying.
Not Doom? Unsubbed.
Omg so true!
I've never played Serious Sam, but what a nice find. Well done. I love that their code is so easy to work with, speaks to the integrity of Croteam.
That is why choosing the right data-structure and data-type can be just as important as choosing the right algorithm - it is part of the design.
Wow, a Serious Sam analysis video!?! Wasn't expecting that.
Noticed this 15-20 years ago, and I thought I was crazy! Thanks for putting my mind at ease after so much time! :)
This video just surprised me, and I'm happy to see someone analyze one of my favorite games ever
Videos like this are what make me wanna go back to this epic game after 20 years.
You seem to be very code savvy. Can you make a video where you talk about your technical background (education plus the kind of jobs you did after graduation) in the future? It would be interesting to see how you became so good at analyzing code from open-source projects.
As someone who also has interest in the Source engine and TF2, the very instant you described the bug, I could immediately point my finger at floating point precision and timer systems.
By coincidence (probably) Doom 2 and Serious SAM FE + SE were my childhood. I recognized that slowed xl lasergun firing sequence from anywhere. I also remember a "weapon reset" bug as a kid where if you used a macro to fire it the bullets became a solid laser beam an infinite firerate as fast as you can pull the trigger.
Also lmao what it went open source? That's actually awesome. Loved the OST playing in the background and lmao 6:29 floating point legs
the comedic timing of "peeeeeeeee" as it scrolled up the screen, thumbs up decino
Wow. My experience with Serious Sam is very limited as I struggled to play it for extended periods of time, but from being unaware of this bug, to watching this video and listening to you go in-depth about it, this was incredible. I hope no one has criticized you for this not being a Doom analysis video, I have all the confidence in the world that you could analyze anything and make it interesting, just by talking about it.
As always, thank you for being you.
I swear i cant understand like 80% of what these videos speak about but i freaking love em HELL YEA MORE SERIOUS SAM CONTENT !! Incredible work
This variable math is also why Minecraft gets super jittery and whatnot the further away you get from 0.x.0 (spawn)
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
Well neither do I know about doom, but that didn't stop me from watching your technical videos about it. Very interesting stuff!