EDIT: https://cssdoom.wtf/
Interestingly, it was more choppy in Chromium.
I could not find a key for moving sideways ("strafing").
All in all, quite mind-boggling.
Firefox's WebRender is truly a great creation. While Chrome is faster at most things especially involving JS, Firefox puts so much of its rendering on the GPU so moving elements around is incredibly fast.
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.
at what point is CSS powerful enough to become a malware vector.
For static content like documents the distinction is easy to determine. When you think about applications, widgets, and other interactive elements the line starts to blur.
Before things like flex layout, positioning content with a 100% height was hard, resulting in JavaScript being used for layout and positioning.
Positioning a dropdown menu, tooltip, or other content required JavaScript. Now you can specify the anchor position of the element via CSS properties. Determining which anchor position to use also required JavaScript, but with things like if() can now be done directly in CSS.
Implementing disclosure elements had to be done with a mix of JavaScript and CSS. Now you can use the details/summary elements and CSS to style the open/close states.
Animation effects when opening an element, on hover, etc. such as easing in colour transitions can easily be done in CSS now. Plus, with the reduced motion media query you can gate those effects to that user preference in CSS.
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;
}> 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; }
}[1] Can Doom Run It? An Adding Machine in Doom https://blog.otterstack.com/posts/202212-doom-calculator/
Would that be better or worse for webdev? I don't know. But I like to ponder.
Good question, I personally think that seperating by concerns is good. But when problems arise like boundaries that get crossed or compilers implementing language features into css like Sass, maybe it proves that those things are actually not two concerns but one.
Lately I am using Catch2 (a c++ testing framework) and wanted to benchmark some code. My first instinct was looking for a benchmark framework. But to my surprise Catch2 does also have a benchmarking framework included!.
Most people would argue that a testing framework should not include a benchmarking framework. But using it myself it showed me that both concerns of benchmarking for performance regressions and testing are similar.
Similar enough that I would prefer both of them together.
Most people, me included, are asking: "Should this be split into more?" But seldom, we ask: "Should this be merge into one?"
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)
https://www.simplethread.com/new-and-upcoming-css-features-i...
The post here could really use it though. The main content is pushed to the bottom of the page!
Crazy to see how far we've come.
In web specs closely rivaled by SVG.
You can pick which one is uglier and you'll be right.
As others pointed out: the fact you can do this in CSS tells you everything you need to know if you consider what CSS is for. Even w/o ever looking at the spec or understanding how it came to be.
i guess if you're someone still stuck on the "web browsers are for displaying static documents" and "css is for prettifying markup" thing, then sure, I bet what you said sounds real witty
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.
> "Once I’ve proven to myself that rendering was feasible, I used Claude to create an approximate version of the game loop in JavaScript based on the original DOOM source, which to me is the least interesting part of the project"
This post is about whether you can render Doom in CSS not whether Claude can replicate Doom gameplay. I doubt the author even bothered to give the game loop much QA.
Looks like it is, though? https://news.ycombinator.com/item?id=47558097
Also if I want I can cross-compile a static build of Frotz for Linux/Misc and emulate it under a RISC interpreter for Linux syscalls written in... Perl, runable in every modern Perl port out there. Linux/RISC binary under Perl for NetBSD/Vax? Yes. Slow? Not much, it's a text game in the end.
But, as for the ZMachine, you can run text adventures in Android, Game Boy, Amiga, MSDOS, Windows, Palm PDA's... anything 8bit and up.
Also, damn Sokoban under Eforth written in Subleq, a VM which can just:
- set up a 2^16 RAM size
- single opcode: substract A from B, if less than 0, go to addr in C. - A < 0? Get ASCII input in B - B < 0? Put ASCII output in B - C < 0? End
This, just this, and people wrote Subleq simulators in C, AWK, Python, TCL, FPGA's and whatnot. And it will run Eforth, and that means... you can write a ZMachine interpreter on it and be really slow if emulated in a Pentium 4 (maybe 3/5 seconds per command with a ZMachine on top of Eforth for Muxleq instead of Subleq), but the game will be playable and a great exercise on Turing completeness.
If a Mandlebrot render under Muxleq+EForth (with no floats used, just integers) is as fast as a C64/Amiga with a native Forth. then having that tiny EForth+Muxleq is not that useless.
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.
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.
Also: a modern CPU is around 10000x faster than the 486 CPU Doom was designed for. Per core.
We detached this comment from https://news.ycombinator.com/item?id= and marked it off topic.
Or is it proof that CSS has "jumped the shark", adding in a plethora of features that have no place in a "stylesheet"?
I guess I am asking, if modern CSS is so awesome, it's awesome compared to what exactly?
Duct tape is awesome for the same reason -- even though there are several effective use cases for duct tape where a different tool would technically be "better" for the job.
No doubt the very loudly opinionated not-web-dev community, who have So Much To Say about web devs and web tech, have produced an uncontroversial, perfect layout system, styling system, and language to produce the replacement for this awful web tech. Where is it? What is it? Please provide (the better version of) a hyperlink to the docs.
So yes I will argue that Qt6 and GTK are better than flexboxes.
Because you asked for it, here's some documentation to a UI framework which I believe to work better than the web stack: https://doc.qt.io/qtforpython-6/PySide6/QtWidgets/index.html
You can keep it high level but your comment makes me think you have something in mind, and I'm honestly curious.
In CSS on the web, just centering a div has historically been a problem. We have flexbox now, but what if CSS was designed with our current needs from the get-go?
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/
> Yes, Lyra Rebane build a x86 CPU completely in CSS, but that technique is simply not fast enough for handing the game loop. So the result is something that uses a lot of JavaScript.