Very cool. Don't take this as criticism, I am just curious, what do you get out of React with this?
You have written a lot of it in pure JS so I can see you're not using it as a crutch, but I am not familiar enough with React at it's edges to know why you would bring it in to the toolbelt here.
React actually makes sense to me here. Op would have to manually update the dom constantly using vanilla JS. React allows them to worry about the programming side but not have to worry about how they are going to propogate those changes to the view layer.
Yeah. It allows the programmer to code using a similar mental model to coding with the canvas tag, where one would probably just draw the entire frame from scratch every frame.
Granted, with the speed of modern browsers and the relative simplicity of this rendering, one could probably literally wipe the DOM layer and rewrite it every frame without having any performance issues. But if the rendering became more complicated it’s conceivable that React’s virtual DOM stuff could noticeably improvement performance.
React would make little to no sense here if canvas or webgl were being used. But given that polygons are rendered as elements, using React makes a ton of sense
1. Read title
2. But why?
3. Click link
4. No <canvas> tag? Just html and react? How?
5. Open demo
6. Inspect elements
7. Oh... Gentle chuckle. But why?
8. Remembers Atwood's Law
If you find this sort of thing interesting, I implemented a "Portal" raycasting engine akin to Valves portal game. You can read more about how it works here: https://github.com/gh123man/Portal-Raycaster
So many DOM elements, if you inspect a wall it's made from thin slices. Wonder if they could be merged to form complete 'walls' and then use gradient effect... heck, SVG may be more effective.
It's because CSS transforms that don't affect layout happen on the GPU, so they may as well be polygons. In fact ThreeJS, the most prominent JS library for 3D rendering in WebGL, can work in DOM rendering mode instead of WebGL :)
I've been playing around with some very extreme forms of server side rendering, and have come to discover that all modern browsers can actually decode and display 1080p+ jpeg images streamed over websocket fast enough to be indistinguishable from a x264 video playing at the same frame rate (60fps in my testing). I have tried on ARM/mobile and it's the same success story there. Latency almost feels lower on my S10 than my Threadripper 2950X.
There's lots of things a browser can do that would surprise a lot of developers.
Such a classic! I remember writing a raycasting engine in DJGPP (GCC for DOS), when I was teenager... Fast forward 25 years and hey, it can be done in TypeScript on a $2 microcontroller ;) (though it did take some effort to get TypeScript to run fast enough...)
Same but in TP7 by following a tutorial found on a CD shipped with a magazine. Very satisfied with the result but never managed to get the version with textures right.
23 comments
[ 2.6 ms ] story [ 44.5 ms ] threadYou have written a lot of it in pure JS so I can see you're not using it as a crutch, but I am not familiar enough with React at it's edges to know why you would bring it in to the toolbelt here.
But you're right, vanilla JS would easily do the job.
Granted, with the speed of modern browsers and the relative simplicity of this rendering, one could probably literally wipe the DOM layer and rewrite it every frame without having any performance issues. But if the rendering became more complicated it’s conceivable that React’s virtual DOM stuff could noticeably improvement performance.
1. Read title 2. But why? 3. Click link 4. No <canvas> tag? Just html and react? How? 5. Open demo 6. Inspect elements 7. Oh... Gentle chuckle. But why? 8. Remembers Atwood's Law
Don't tell that to a game dev
Also, I'm pretty sure there are many websites out there pushing around way more divs than this is.
There's lots of things a browser can do that would surprise a lot of developers.
https://arcade.makecode.com/14009-57824-16954-25349 https://forum.makecode.com/t/3d-raycasting-in-arcade/474