Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doom crash after 2.5 years of real-world runtime confirmed on real hardware

lenowo.org

Post reply on HN
Print view View original

91–100 of 221 posts

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#91

Post by Forgeties79 »

jsheard wrote: post #13
zero_shift wrote: post #12

About a year ago I was looking at Crash Bandicoot timer systems and I found that Crash 3 has a constantly incrementing int32. It only resets if you die. Left for 2.26 years, it will overflow. When it does finally overflow, we get "minus" time and the game breaks in funny ways. I did a video about it: https://youtu.be/f7ZzoyVLu58

There's a weapon in Final Fantasy 9 which can only be obtained by reaching a lategame area in less than 12 hours of play time, or 10 hours on the PAL version due to an oversight. Alternatively you can just leave the game running for two years until the timer wraps around. Slow and steady wins the race. https://finalfantasy.fandom.com/wiki/Excalibur_II_(Final_Fan...

Lord have mercy fandom really has become unbearable with the ads and pop ups.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#92

Post by reactordev »

zero_shift wrote: post #85
reactordev wrote: post #73

Earlier quoted context omitted.

Incorrect. I’m looking at the source code. It’s not perfect but it’s not just “slowed down to 50hz” like people claim.

When you say looking at the source code, what do you mean here? AFAIK the source for FF9 PSX (and all the PSX ff games) has been lost as Square just used short term archives Also, FF9 does not run at a constant framerate. Like all the PSX FF games it runs at various rates, sometimes multiple at a time (example: model animations are 15fps vs 30 for the UI) In terms of timers, the bios does grant you access to root tim…

It’s definitely not lost…

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#93

Post by phkahler »

Sharlin wrote: post #89
shultays wrote: post #76

Does that hardware traps overflows or something? I had read an article about how DOOMs engine works and noticed how a variable for tracking the demo kept being incremented even after the next demo started. This variable was compared with a second one storing its previous value Doesn't sound like something that would crash, I wonder what was the actual crash

Signed overflow is undefined behavior in C, so pretty much anything could happen. Though this crash seems to be deterministic between platforms and compilers, so probably not about that. TFA says the variable is being compared to its previous value, and that comparison presumably assumes new < old cannot happen. And when it does, it could easily lead to eg. stack corruption. C after all happily goes to UB land if, fo…

That doesn't make sense. If new < old cant happen there is no need to make a comparison. Stack corruption? Nah, its a counter not an index or pointer or it would fail sooner. But then what is the failure? IDK

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#94

Post by WJW »

Gravityloss wrote: post #90
jsheard wrote: post #13

Earlier quoted context omitted.

There's a weapon in Final Fantasy 9 which can only be obtained by reaching a lategame area in less than 12 hours of play time, or 10 hours on the PAL version due to an oversight. Alternatively you can just leave the game running for two years until the timer wraps around. Slow and steady wins the race. https://finalfantasy.fandom.com/wiki/Excalibur_II_(Final_Fan...

Am reminded by this quote from Ferdinand Porsche: "The perfect racing car crosses the finish line first and subsequently falls into its component parts." Games fit this philosophy, compared to many other pieces of software that are expected to be long-lived and receiving a lot of maintenance and changes and evolve.

The Porsche quote reflects a wider design philosophy that says "Ideally, all components of a system lasts as long as the design life of the entire system and there should be no component that lives significantly longer. If there is such a component, it has been overengineered and thus the system will be more expensive to the end consumer than it needs to be.". It kinda skips over maintenance, but overall most people find it unobjectionable when stated like this.

But plenty of people will find complaints when they try to drive their car beyond its design specs and more or less everything starts failing at once.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#95

Post by anthk »

zero_shift wrote: post #85
reactordev wrote: post #73

Earlier quoted context omitted.

Incorrect. I’m looking at the source code. It’s not perfect but it’s not just “slowed down to 50hz” like people claim.

When you say looking at the source code, what do you mean here? AFAIK the source for FF9 PSX (and all the PSX ff games) has been lost as Square just used short term archives Also, FF9 does not run at a constant framerate. Like all the PSX FF games it runs at various rates, sometimes multiple at a time (example: model animations are 15fps vs 30 for the UI) In terms of timers, the bios does grant you access to root tim…

FF VII-IX were reimplemented under a custom engine.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#96

Post by zero_shift »

reactordev wrote: post #92
zero_shift wrote: post #85

Earlier quoted context omitted.

When you say looking at the source code, what do you mean here? AFAIK the source for FF9 PSX (and all the PSX ff games) has been lost as Square just used short term archives Also, FF9 does not run at a constant framerate. Like all the PSX FF games it runs at various rates, sometimes multiple at a time (example: model animations are 15fps vs 30 for the UI) In terms of timers, the bios does grant you access to root tim…

It’s definitely not lost…

What code are you looking at?

FFIX for PSX would have been written in C (or possibly C++) with PSY-Q. It will not be one program - those games were composed of multiple overlays that are banked in / out over the PlayStation's limited memory.

From what I know the PC release was a port to a new framework, which supports the same script engines, but otherwise is fresh code. This is how it can support mobile, widescreen, Steam achievements etc.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#98

Post by doubled112 »

WJW wrote: post #94
Gravityloss wrote: post #90

Earlier quoted context omitted.

Am reminded by this quote from Ferdinand Porsche: "The perfect racing car crosses the finish line first and subsequently falls into its component parts." Games fit this philosophy, compared to many other pieces of software that are expected to be long-lived and receiving a lot of maintenance and changes and evolve.

The Porsche quote reflects a wider design philosophy that says "Ideally, all components of a system lasts as long as the design life of the entire system and there should be no component that lives significantly longer. If there is such a component, it has been overengineered and thus the system will be more expensive to the end consumer than it needs to be.". It kinda skips over maintenance, but overall most people…

When the design spec seems to be a 3 year long lease I can see why people get bothered.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#99

Post by jraph »

phkahler wrote: post #93
Sharlin wrote: post #89

Earlier quoted context omitted.

Signed overflow is undefined behavior in C, so pretty much anything could happen. Though this crash seems to be deterministic between platforms and compilers, so probably not about that. TFA says the variable is being compared to its previous value, and that comparison presumably assumes new < old cannot happen. And when it does, it could easily lead to eg. stack corruption. C after all happily goes to UB land if, fo…

That doesn't make sense. If new < old cant happen there is no need to make a comparison. Stack corruption? Nah, its a counter not an index or pointer or it would fail sooner. But then what is the failure? IDK

Assuming new > old doesn't mean you actually make the comparison, but rather that the code is written with the belief that new > old. This code behaves correctly under this assumption, but might be doing something very bad that leads to a crash if the new An actual analysis would be needed to understand the actual cause of the crash.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#100

Post by signalToNose »

WJW wrote: post #94
Gravityloss wrote: post #90

Earlier quoted context omitted.

Am reminded by this quote from Ferdinand Porsche: "The perfect racing car crosses the finish line first and subsequently falls into its component parts." Games fit this philosophy, compared to many other pieces of software that are expected to be long-lived and receiving a lot of maintenance and changes and evolve.

The Porsche quote reflects a wider design philosophy that says "Ideally, all components of a system lasts as long as the design life of the entire system and there should be no component that lives significantly longer. If there is such a component, it has been overengineered and thus the system will be more expensive to the end consumer than it needs to be.". It kinda skips over maintenance, but overall most people…

Consumer protection laws prevents businesses following this to it’s extreme. For many businesses the ideal would be to just sell stuff that immediately breaks down as soon as it’s sold. It has the fulfilled its purpose from their point of view
Post reply on HN