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

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.

Just be glad you knew what the bug was before you started. After 2.5 years... "Shit, I forgot to enable debug logging"

Since we've hugged the site to death, have an archive.org link: https://web.archive.org/web/20250916234009/https://lenowo.or...

Sadly it appears that archive.org didn't capture all of the site formatting, but at least the text is there.

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

Notably, DOOM crashed before Windows CE.

2038 is going to be a fun year.

This is a level of testing that exceeds what the testers I know commit to. I myself was annoyed the five or so times yesterday we had to sit and wait to check the error handling after a 30 second timeout in the system I work on.

This headline gave me a heart attack... I misread the site's name as Lenovo, and as I'm responsible for a whole lot of their servers running for years in a critical role... heart attack.

Maybe I need my morning coffee. :)

Seems to be a PocketPC port of Doom, with no source given or even a snippet of the relevant code/variable name/etc. shown at all.

I am going to need to see this replicated before I can believe.

Props again to the id team. No doubt something like that engineered by most folks today would have died long before the 2 year mark due to memory fragmentation if not outright leaks.

Was this specific to the PDA port or the core doom code?

@ID_AA_Carmack Are you going to write a patch to fix this?

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.

I love the post, but your blurry text is hurting my eyes. Looks like it's intentionally blurry but I can't figure out why. This can't be a holdover from older systems, they had razor-sharp text rendering on CRTs.

In games I worked on I use time to pan textures for animated FX.

After a few hours precision errors accumulate and the texture become stretched and noisy, but since explosions are generally short-lived its never a problem.

Yet this keep bothering me..

The easy way to e-Nostradamus predictions:

"See this crash?

I predicted it years ago.

Don't ask me how, I couldn't tell you."

p.s. I had an old iPaq that I wouldn't have trusted to run for longer than a day and stay stable, kudos for that at the very minimum.

Quick! John Carmack needs to be brought into this immediately.

I haven't opened my DOOM software box, it's still in the shrinkwrap. I guess I can take it back and ask for a refund now?

It's good it didn't took a billion years to overflow. That would have been quite a long wait.

Literally unplayable

Has this ever come up in a TAS of custom levels?

Love the look of that board :-)

CNR. Please attach video.

Literally unplayable.

glitchless?

Not a comment on the post, but I sure wish Jira would load even half as quickly as this site.

"I hope someone got fired for that blunder." /s