CSS is DOOMed (nielsleenheer.com)

But there's a lot more CSS features now. While in the past, Turing completeness in CSS required humans to click on checkboxes, now CSS can emulate an entire CPU without JavaScript or requiring user interaction.[1] So I wonder if DOOM could be purely CSS too, in real time.

[0]: https://keithclark.co.uk/labs/css-fps/ [1]: https://lyra.horse/x86css/

EDIT: https://cssdoom.wtf/

CSS started as purely declarative styling, but between things like conditionals, math functions, and now these rendering tricks, it’s slowly creeping into “programmable system” territory. Not because it’s the right tool for it, but because browsers are becoming the real runtime. The interesting question isn’t “can Doom run in CSS”, it’s how much logic we’ll keep pushing into layers that were never meant to handle it.

FYI if you want to use inspect element, the viewport div consumes mouse elements, you can get rid of this with

  #viewport {
    pointer-events: none;
  }
  #viewport * {
    pointer-events: initial;
  }

    IDDQD

    IDKFA

> The problem: CSS can compute a number – 0 for visible and 1 for hidden – but you can’t directly use that number to set visibility. There is a new feature coming to CSS that solves this: if(), but right now it only just shipped in Chrome.

> So I used a trick called type grinding. You create a paused animation that toggles visibility between visible and hidden. Then you set the animation-delay based on the computed value to determine which keyframe is used:

  animation: cull-toggle 1s step-end paused;
  animation-delay: calc(var(--cull-outside) \* -0.5s);

  @keyframes cull-toggle {
    0%, 49.9% { visibility: visible; }
    50%, 100% { visibility: hidden; }
  }

https://www.simplethread.com/new-and-upcoming-css-features-i...

Would that be better or worse for webdev? I don't know. But I like to ponder.

Crazy to see how far we've come.

[0]: https://arstechnica.com/gaming/2006/04/forever/

I think that running Doom on X can also be a criticism of X, certainly the opposite of the intention in some cases. Consider a config mechanicsm, if I prove that I can run Doom on .md or .ini, or notepad.exe, most people should be concerned, not just for bloat, but for security reasons.

The value of some tech is precisely in what it cannot do, not just what it can do.

i think ultimately, there also the world moves aroun the player and cameras are just a concept to make the frustrum etc (maybe modern tools do it differently, im a little out of date)

Use Deutex, GNU make and Pillow for Python to compile.

Then wou will have up-to-date IWADS to be used aywhere. No need to put ID copyrights, just a mention to FreeDoom creators.

In web specs closely rivaled by SVG.

You can pick which one is uglier and you'll be right.

> "I used Claude to create an approximate version of the game loop in JavaScript based on the original DOOM source"

This is the real horror here, Uncanny-Valley gameplay Doom. It's like those Doom maps where people tried to recreate the game levels from memory, but still made a few mistakes and got some details wrong. This is like that, but for the gameplay rather than the level layouts. It's different enough to be wrong.

We have Green Armor that sets your armor to 200%. Health Bonuses that reset your health to 100% if you exceeded that number, too bad if you recently collected a Soul Sphere. Switch-activated doors that are supposed to stay open, but instead automatically close, but then the secret wall unexpectedly activates like a manual door.

Also: a modern CPU is around 10000x faster than the 486 CPU Doom was designed for. Per core.