Thanks. I felt like I had seen them somewhere. I think it's just the pattern that gets changed then. Can you remember if the HEH boxes explode if you spin during the TNT phase? These ones don't
Interesting. When I spin these boxes (e.g. in Toad Village) during the TNT phase they just break without any other effect. They don't appear to be running through any normal pattern either
Not sure if it works the same in the original, but here's how they're programmed in the N. Sane Trilogy: Every crate has two parts: a template, which is used as reference for all crates of that type, and a spawner, which tells the game where to spawn this specific crate and whether it's affected by gravity. With the Roulette Crate, the template contains data for all five states: Blank, ?, Life, Aku Aku, and TNT, and cycles between them in a fixed pattern. But which states can appear is based on a binary value on the spawner.
I honestly didn't even know the game uses timers for the animations. I don't know why it never occured to me, as the enemies work on cycles, but still, never crossed my mind.
these types of glitches that involve ingame data and integers, and can only be understood and broken down by people with dev experience, are my absolute favorite. so intricate and so fascinating, almost like unintentional easter eggs, total surprises in the code
This is such a interesting subject, i've always loved erratic behavior, bugs and glitches in old video games, if possible could you do a even bigger showcase? Or perhaps those were all the examples that didn't crash the game?
I have a hard time believing they used int instead of unsigned type (or it's equivalent in lisp). How did you check it actually goes to negative numbers instead of starting from 0?
When compiling for the PSX, any value typed "int" will be a 32bit signed by default. I don't know about the primitives in GOOL, but lots of Crash 1-3 is native code not interpreted. You can see the negative rollover by updating the value to anything close to 0x7FFFFFFF, and then watching it overflow to 0x80000000+ in your emulator's memory viewer. Immediately after all tracking goes into reverse. This was how I captured the video here. It is actually pretty common in C programs (like most PSX games) to seldom use unsigned ints. There are a few reasons... for one thing signed overflow is UB which provides more scope for compiler optimisation. You also have to think about signed/unsigned conversion less which in C has quite a few footguns.
The TNT state is present in the flashing boxes in the final game, but only in the bonus section of Hang 'em High.
Thanks. I felt like I had seen them somewhere. I think it's just the pattern that gets changed then. Can you remember if the HEH boxes explode if you spin during the TNT phase? These ones don't
@@jbreckmckye I've just tested it on the original, yeah, they explode just as normal
Interesting. When I spin these boxes (e.g. in Toad Village) during the TNT phase they just break without any other effect. They don't appear to be running through any normal pattern either
Not sure if it works the same in the original, but here's how they're programmed in the N. Sane Trilogy:
Every crate has two parts: a template, which is used as reference for all crates of that type, and a spawner, which tells the game where to spawn this specific crate and whether it's affected by gravity.
With the Roulette Crate, the template contains data for all five states: Blank, ?, Life, Aku Aku, and TNT, and cycles between them in a fixed pattern. But which states can appear is based on a binary value on the spawner.
Finally, just 2 more years until I can attempt one Hog Ride platinum run!
I've been playing for 2.2698753244 years so I'm glad you told me this 👍
You'd better reset, wouldn't want any glitches!
"Playing for 830 days breaks -Paper Mario- Crash 3"
Thanks for making a video with no baits or stalling, straight to the point!
This is really cool and interesting. I had no idea timer overflow was a thing in this game.
Its a thing in pretty much every program that keeps some kind of timer or score
I honestly didn't even know the game uses timers for the animations. I don't know why it never occured to me, as the enemies work on cycles, but still, never crossed my mind.
These enemies after listening to Micheal Jackson:
always nice to see more research on the craah bandicoot games
unplayable game smh devs please fix
1:00 - Lab Assitant: "It certainly is time for me to go now."
new Speedrun cathegory incoming: fastest in negative time and back, no deaths.
good to know, now im only gonna play crash 3 for 2.269875344 years!
But that would cause the glitch.
@@SgvSth you dont get the joke
these types of glitches that involve ingame data and integers, and can only be understood and broken down by people with dev experience, are my absolute favorite. so intricate and so fascinating, almost like unintentional easter eggs, total surprises in the code
you need dev experience to understand simple integer overflow?
Huge props to the player who had their PS1 turned on for 2.2698753245 years to record this.
inb4 speedrunners come through with negative overall time runs
Stoked on this information
Short, to the point, showcases everything well, no loud or dramatic narration nor annoying visual elements.
Great video.
Weird, I thought the PS1 couldn't do floating point
I wonder if this is useful in any low% runs
This is such a interesting subject, i've always loved erratic behavior, bugs and glitches in old video games, if possible could you do a even bigger showcase? Or perhaps those were all the examples that didn't crash the game?
challenge accepted
How this guy wait all this years?
Why would I be wondering how long it takes? It says it right in the title.
If you wait another couple of years, does it fix itself?
It would do. But the faster way is to die, which resets the timer
great video, how do you only have 700 subs? subscribed!
Crash 3 is good enough to play for 2. 2698753245 Years
Lol nice video! :D
beeta > baeda
"very roughly 2.2698753245 years".
Geez, you could have at least gone through the effort of trying to be a little bit precise.
I have a hard time believing they used int instead of unsigned type (or it's equivalent in lisp). How did you check it actually goes to negative numbers instead of starting from 0?
When compiling for the PSX, any value typed "int" will be a 32bit signed by default. I don't know about the primitives in GOOL, but lots of Crash 1-3 is native code not interpreted.
You can see the negative rollover by updating the value to anything close to 0x7FFFFFFF, and then watching it overflow to 0x80000000+ in your emulator's memory viewer. Immediately after all tracking goes into reverse. This was how I captured the video here.
It is actually pretty common in C programs (like most PSX games) to seldom use unsigned ints. There are a few reasons... for one thing signed overflow is UB which provides more scope for compiler optimisation. You also have to think about signed/unsigned conversion less which in C has quite a few footguns.