Live data from Hacker News

Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

en.andros.dev

41–50 of 55 posts

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#42

if only i could run django on cloudflare workers guess i could run it on a dedicated server would be nice if we can get django and liveview working without a server

We ran Django on AWS Lambas years ago. Wasn’t fun and caused headaches, but worked

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#43
post #14
post #8

Since Doom renders the image with vertical columns of pixels (floor, lower wall, portal if exists continues rendering the other sector, then upper wall then ceiling) and since browsers are very good at drawing the sprites out of larger textures... You could send vertical divs shaded with the sector light level and picking the correct textures. Instead of hundreds per column you will have like 5 divs on average per co…

I believe he stated in the beginning pretty clearly that the point of this exercise was to stress test the Liveview performance. Making this more efficient would be kinda counter productive

I think the proposal here is to optimize for bandwidth by minimizing number of divs, because there are fewer divs per column per frame. It might actually turn out to be more work for the browser because it has to layout the columns with divs that are not uniformly sized.

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#44
post #8

Since Doom renders the image with vertical columns of pixels (floor, lower wall, portal if exists continues rendering the other sector, then upper wall then ceiling) and since browsers are very good at drawing the sprites out of larger textures... You could send vertical divs shaded with the sector light level and picking the correct textures. Instead of hundreds per column you will have like 5 divs on average per co…

IIRC someone did exactly that around 15 years ago, a game renderer using div strips, first with Wolfenstein and then Doom. It may have been "Jacob Seidelin" who was very active experimenting with early HTML5 tech, but I've lost all links or they've vanished from the web - I only keep two screenshots I used in a lecture back then.

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#48
post #33
post #26

Earlier quoted context omitted.

At that point just run the browser on the server and use proper cloud gaming tech to stream the screen and have low-latency interactivity.

If it's streaming at 60 fps, the bottleneck is in the browser, which is doing what it can :)

My phone and TV can go to 120hz, and my PC can go to 240 with adaptive sync. There’s still plenty of room to improve.

Re: Doom in Django: testing the limits of LiveView at 600.000 divs/segundo

#49

This is more like HTMX+websockets than phoenix liveview. - It's not stateful - There's no html diffing - Handlers return target+fragment instead of updating state

Each user has their ID in the backend; you can save their status... if you want.
Post reply on HN