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

171–180 of 221 posts

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

#171

Post by reactordev »

anthk wrote: post #95
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…

FF VII-IX were reimplemented under a custom engine.

Except I’m looking at the original source, not the remake, the crappy C/C++ Square engine. Not C# unity code.

There are a number of timers and things used. But the claim that it runs slower is absolutely false. It’s just perceived that way because it’s “drawn” slower.

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

#172

Post by Insanity »

simoncion wrote: post #137
Lightkey wrote: post #59

Earlier quoted context omitted.

They missed that window when Sierra was still the publisher for Half-Life. Besides, Valve is not a publicly traded company and Gabe Newell as former manager at Microsoft has no interest in getting back together. Valve is betting everything on Linux right now to be more independent from Microsoft.

> Valve is betting everything on Linux right now... They've been working on Linux support since at least around the time that Microsoft introduced the Windows Store... so for the last twelve years or so. And, man, a couple of months ago I figured out how to run Steam as a separate user on my Xorg system. Not-at-all-coincidentally, I haven't booted into Windows in a couple of months. Not every game runs [0], but nearl…

I used to game on Linux back in the late 2000s through Wine. And I always found the mouse support to be jarring, even if I could get support to a decent level, for some reason the mouse input was never quite as fluid as it should have been.

And now I'm reluctant to move back to Linux for gaming, even though they've clearly come so far. I guess I should just go ahead and give it another shot.

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

#173

Post by ogurechny »

Forgeties79 wrote: post #132
account42 wrote: post #125

Earlier quoted context omitted.

Don't accept devices that limit your ad blocker options.

Does this discussion strike you as one where I’m deliberating whether or not to chuck my smartphone and buy into a new ecosystem to avoid ads on fandom? These types of comments are always very unhelpful.

No, that's just a reminder that you had a choice, and chose empty talk about “ecosystems” over ability to control what you can see on “your” screen. You've stepped on a rake once, you got some experience, why repeat it over and over again?

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

#174

Post by elzbardico »

compiler-guy wrote: post #165
elzbardico wrote: post #129

Earlier quoted context omitted.

It is easy to have to run a bunch of sous vide cooker 24/7 if you have a small restaurant or food delivery business.

In which case one shouldn't be using consumer-grade kitchen equipment.

Call it vibe cooking.

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

#175

Post by [deleted] »

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…

[deleted]

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

#176

Post by aYsY4dDQ2NrcNzA »

ortusdux wrote: post #166
mikepurvis wrote: post #155

Earlier quoted context omitted.

Alan Weisman's lovely book World Without Us speculates a bit about this, basically saying that more recently built structures would be the first to collapse because they've all be engineered so close to the line. Meanwhile stuff that already been standing for 100+ years like the Brooklyn Bridge will probably still be there in another 100 years even without any maintenance just on account of how overbuilt it all had t…

There was an aluminum extrusion company that falsified test records for years. They got away with it because what's a few % when your customer's safety factor is 2. Once they got into weight sensitive aerospace applications, where sometimes the factor is 1.2, rockets starting blowing up on the launch pad. https://www.justice.gov/archives/opa/pr/aluminum-extrusion-m...

Should have resulted in jail time. A monetary fine is no deterrent.

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

#177

Post by jerf »

Insanity wrote: post #172
simoncion wrote: post #137

Earlier quoted context omitted.

> Valve is betting everything on Linux right now... They've been working on Linux support since at least around the time that Microsoft introduced the Windows Store... so for the last twelve years or so. And, man, a couple of months ago I figured out how to run Steam as a separate user on my Xorg system. Not-at-all-coincidentally, I haven't booted into Windows in a couple of months. Not every game runs [0], but nearl…

I used to game on Linux back in the late 2000s through Wine. And I always found the mouse support to be jarring, even if I could get support to a decent level, for some reason the mouse input was never quite as fluid as it should have been. And now I'm reluctant to move back to Linux for gaming, even though they've clearly come so far. I guess I should just go ahead and give it another shot.

It has come lightyears.

ProtonDB has a feature where you can give it access to your Steam account for reading and it'll give you a full report based on your personal library: https://www.protondb.com/profile

And I find if anything it tends to the conservative. I've encountered a few things where it was overoptimistic but its outweighed by the stuff that was supported even better than ProtonDB said.

In the late 2000s, I played a few things, but I went in with the assumption it either wouldn't work, or wouldn't work without tweaking. Now I go in with the assumption that it will work unless otherwise indicated. Except multiplayer shooters and VR.

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

#178

Post by pfdietz »

AzN1337c0d3r wrote: post #146
creaturemachine wrote: post #127

Earlier quoted context omitted.

Porsche was talking about racing, where the primary focus is reaching the finish line faster an anyone else, and over-engineering can easily get in the way of that goal. Back in the real world, no race team would agree that their cars should disintegrate after one race.

> Back in the real world, no race team would agree that their cars should disintegrate after one race. Wasn't F1 teams basically doing this by replacing their engines and transmissions until the rules introduced penalties for component swaps in 2014?

Don't highly optimized drag racers do this? I mean, a clutch that in normal operation gets heated until it glows can't be very durable.

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

#179

Post by FuriouslyAdrift »

delichon wrote: post #102
signalToNose wrote: post #100

Earlier quoted context omitted.

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

I run sous vide cookers 24*7, and they uniformly break within 90 days or less. But they don't like to admit their smaller duty cycle, so they don't, and keep sending me warranty replacements instead. I keep buying different brands looking for one with a longer life. I'll bet most people do that when their gadgets die, and purposely making products that die as soon as sold isn't often a successful business model.

Try a Breville PolyScience... https://www.breville.com/en-us/product/csv750

Or if you want something even beefier: https://sammic.com/en/smartvide-xl

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

#180

Post by zero_shift »

reactordev wrote: post #171
anthk wrote: post #95

Earlier quoted context omitted.

FF VII-IX were reimplemented under a custom engine.

Except I’m looking at the original source, not the remake, the crappy C/C++ Square engine. Not C# unity code. There are a number of timers and things used. But the claim that it runs slower is absolutely false. It’s just perceived that way because it’s “drawn” slower.

Firstly, could you elaborate what code you're looking at? Square have never shared the source code for these titles and were not even practicing real version control at this time (see: Eidos FF7/8 debacle)

Secondly, it absolutely will run slower. Animations will take longer to complete; FMVs will play at a different rate ; controller sampling will be reduced.

My scepticism isn't coming from hearsay or ignorance: I have written PlayStation software, and PSX software is not parallelised, even though it can support threading and cooperative concurrency. The control flow of the title is very locked into the VSync loop, from your first ResetGraph(0) right to your final DrawOTable(*p).

In addition, I have done a bunch of reversing work on the other two PSX games, and they are not monolithic programs. They can't be because there simply isn't enough RAM to store the .TEXT of the entire thing at once. So when you say "the source code", I'm inclined to ask - for which module? The kernel or one of the overlays?

Post reply on HN