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

201–210 of 221 posts

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

#201

Post by Spoom »

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.

Stating my bias up front, I've been using Linux since Windows Vista, and I'm a fan. That said, I have experienced the same things you did whenever I needed to run Wine for... well, anything. It was clunky as hell.

You should absolutely revisit. Proton has changed the game. Literally the only game I've tried that was remotely difficult to play in SteamOS is Minecraft, likely because Microsoft owns it now. But I was able to get that working too (if anyone's wondering: you want Minecraft Bedrock Launcher, which is in the Discover store if you're on the Steam Deck and here[1] if you're somewhere else; basically it downloads and runs the Android version of Minecraft through a small translation layer, which is essentially identical to the Windows version).

Speed also is greatly improved from previous solutions. Games played through Proton are often very close in terms of performance to playing them natively.

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

#202

Post by rybosome »

jonhohle wrote: post #27
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

I think many games were that way. SotN definitely has a global timer. On a native 32-bit system it makes sense, especially when the life of a game was a few months to a few years on the retail shelf. No player is going to leave their system running for 2.27 years so what’s the point of even tesing it? Who knew at the time they were creating games that would be disassembled, deconstructed, reverse engineered. Do any o…

It’s a totally reasonable choice in that context.

I wonder if any sense this is criticism (or actual criticism) is based on implementers of SaaS who have it so deeply ingrained that “haha what if the users of this software did this really extreme thing” is more like “oh shit what if the users of this software did this really extreme thing”.

When I worked on Google cloud storage, I once shipped a feature that briefly broke single-shot uploads of more than 2gb. I didn’t consider this use case because it was so absurd - anything larger than 2mb is recommended to go through a resumable/retryable flow, not a one-shot that either sends it all correctly the first time or fails. Client libraries enforced this, but not the APIs! It was an easy fix with that knowledge, but the lesson remained to me that whatever extreme behaviors you allow in your API will be found, so you have to be very paranoid about what you allow if you don’t want to support it indefinitely (which we tried to do, it was hard).

Anyway in this case that level of paranoia would make no sense. The programmers of this age made amazing, highly coreographed programs that ran exactly as intended on the right hardware and timing.

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

#203

Post by lapetitejort »

jama211 wrote: post #48
Insanity wrote: post #31

Literally unplayable, someone should fix that. Doom is actually such a good game, I always go back to it every few years. The 2016 reboot is also pretty fun, but the later two in the series didn’t do it for me.

Same. Something about the metroidvania design with the home hub of the later ones didn’t give the same feeling. It should be run, kill, find secrets, end, next level.

> find secrets

I'll be honest, I don't like this part. I'm a rabid collector. If the game gives a metric to an item, I must have all of the items. I end up killing the flow by scouring the level looking for secrets. This is entirely my fault of course

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

#204

Post by tekne »

zero_shift wrote: post #199
xhrpost wrote: post #117

Earlier quoted context omitted.

Is it common to default to a signed integer for tracking a timer? I realize being unsigned it would still overflow but at least you'd get twice the time, no?

Some C programmers take the view that unsigneds have too many disadvantages: undefined behaviour for overflows, and weird type promotion rules. So, they try and avoid uints.

Umm, signed integers are UB on overflow; unsigned is always fine.

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

#205

Post by abbeyj »

cestith wrote: post #135

Once upon a time, Windows NT 4 had a similar bug. Their counter was high precision, though, and was for uptime of the system. Back before Service Pack 3 (or was it SP2?) we had a scheduled task reboot the system on the first of the month. Otherwise it would crash after about 42 days of uptime, because apparently nobody at Microsoft tested their own server OS to run for that long.

Are you thinking of https://web.archive.org/web/19990508050925/http://support.mi... ? Or was there a different bug in NT 4?

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

#206

Post by JustExAWS »

Forgeties79 wrote: post #168
mrguyorama wrote: post #154

Earlier quoted context omitted.

You are on iOS. There is only safari. Any other "web browser" is just a skin over safari

Yes I know everything is wrapped around safari. But I like having Firefox syncing across devices. Edit: ah forgot my vpn was off, usually clears all that up for me. Much better now

Just a note: If you have a Windows computer, Apple has a plug in for Firefox and Chrome that syncs bookmarks to iCloud and Safari.

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

#207

Post by Forgeties79 »

JustExAWS wrote: post #206
Forgeties79 wrote: post #168

Earlier quoted context omitted.

Yes I know everything is wrapped around safari. But I like having Firefox syncing across devices. Edit: ah forgot my vpn was off, usually clears all that up for me. Much better now

Just a note: If you have a Windows computer, Apple has a plug in for Firefox and Chrome that syncs bookmarks to iCloud and Safari.

Linux machine but maybe it works anyway?

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

#208

Post by reactordev »

zero_shift wrote: post #180
reactordev wrote: post #171

Earlier quoted context omitted.

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 ha…

Good for you. When I say the source, I mean all modules, the kernel, the graphics, everything. Cheers. While we didn’t use version control the way we do today, we still had it… some of us also made copies.

It’s not lost except to maybe Square Enix’s corporate but they don’t know where anything is.

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

#210

Post by woliveirajr »

ortusdux wrote: post #121
WJW wrote: post #94

Earlier quoted context omitted.

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…

Anyone can build a bridge, but it takes an engineer to barely build a bridge.

In my county, a company asked the Mayor if it was possible to improve some bridge because they need to carry 40t and the bridge had a sign telling it would only allow up to 32t. Their proposal was to do the construction and get tax rebates.

After two weeks, the Infrastructure department changed the sign allowing up to 45t.

Post reply on HN