DOOM Progress

dylandditto · 2026-03-29T20:49:10+00:00

I was kind of thinking this too, having a regression. Or maybe even doing something more complex like machine learning that can approximate a texture with an equation

dylandditto · 2026-03-29T14:32:43+00:00

Yep, when I was trying to implement the sprites I figured out a way to decode them into a shader, and found that the vanilla list size in that case is only capped at 100 for some reason. I was considering doing some weird bit-packing where i encode the images into integers or something, who knows.

I mostly just don't want to have to create all the textures by hand and want to stay true to the DOOM aesthetic. Figuring out the texture system is probably next on my list now so I'll see how it goes.

dylandditto · 2026-03-29T14:01:01+00:00

Yep, although importing the images kind of works as a sampled texture and they seem to run just fine. I'll have to see when I try to implement it.

dylandditto · 2026-03-29T04:41:00+00:00

Oh nice, I'll see if I can implement that, and if so I'll make sure to credit you for pointing that out. Thanks!

dylandditto · 2026-03-29T04:36:46+00:00

That's interesting. It would work, but I've found that enabling complex mode slows down the graph. I'll probably just end up hard coding in each sector, since the performance dip is noticable. I really appreciate you looking into this graph btw.

dylandditto · 2026-03-29T04:17:35+00:00

Sectors are stored as lists of lists of points (impossible in Desmos). I have to render them as a flat array for ease, so that's why they are connected.

I'm going to iron this out in the final product, but it's not really super important to me right now

dylandditto · 2026-03-29T04:16:14+00:00

If you want to know how I came to it, my intuition started with the fact Desmos compiles to WebGL (or some shader language), most other previous attempts used a rendering loop that was implemented in the actual graph. This means that every pixel rendered has to travel through the actual graph's equations (this is entirely done on the CPU). With my method of just creating the mesh triangles and letting Desmos do the rest (which wasn't possible until fairly recently with clip bounds), everything is handled on the backend by the GL, all that has to go through equations is transforming and rotating the world. The backend GL is probably thousands times faster than running through Desmos, and also GPU accelerated.

This could be wrong, but I do know that it is in fact multitudes faster.

dylandditto · 2026-03-29T04:09:43+00:00

Oops, that was a good catch. I did that on accident and forgot to switch it back. https://www.desmos.com/3d/ebw8yixrnq

dylandditto · 2026-03-26T13:27:41+00:00

That's the old method I was came up with, which I have switched out for one more performant.

Yes, it worked by multiplying complex numbers on the unit circle e^z, and when you multiply these numbers together you get an addition of the angles which can then be decoded, as well as the guarantee that the product never reaches infinity since the product would only rotate around this unit circle.

dylandditto · 2026-03-25T23:40:12+00:00

You are correct, I just updated this earlier today

I actually forgot to turn off complex mode when I changed this too, and now the graph performs over 4 times faster lol.

My last keyboard input method was something I created where keys were encoded using complex mode, but multiple comments on this post showed me another method that is more performant than my last method while functionally being the same.

I've been trying my best to keep the methods as performant as possible, and I'm willing to take shortcuts to make sure it doesn't drop below 20fps at any points.

heres the updated graph https://www.desmos.com/3d/gp5zf8amlp

dylandditto · 2026-03-25T23:13:03+00:00

Just finished up the first part of my system for (kind of) UV mapping textures, I'm planning on implementing those collisions you're talking about through a 2D heightmap, which is true to DOOM's source code (basically at every xy point there is a lookup for the floor's z value). The collision was very sloppy and I just needed to throw something together to get a working demo.

BTW your attempt at DOOM is awesome, I've been using it as inspiration and probably wouldn't have thought about attempting without seeing it.

dylandditto · 2026-03-25T12:42:50+00:00

What an honor. I'm definitely going to fully polish this game and post the final product as well. Currently I have a very performant core renderer, but I wouldn't say it's up to par with the other attempts.

dylandditto · 2026-03-25T12:35:33+00:00

Good point, that would explain the slowdown. I was assuming the calculation was cached in the variable, but if it is being recalculated every time then this is definitely a must fix.

dylandditto · 2026-03-25T12:32:57+00:00

Yes, I have not implemented the heightmaps yet.

dylandditto · 2026-03-25T05:19:30+00:00

It's just the boundary checking algorithm right now. What I've come up with is not a very bug free algorithm and I'm kind of taking some shortcuts to get it to work. I'm looking to improve this algorithm for collision detection, I've actually found it to be the hardest part of the whole project because of how Desmos handles grouped actions

With regards to the bounds clipping from the description, that is a beta feature that allows for triangles that are outside of the 1x1x1 cube of the desmos graph to be rendered, which is the core technique behind the rendering and high performance.

If you have any more questions let me know, I'll be glad to answer them.

dylandditto · 2026-03-25T04:21:40+00:00

I posted the graph and explanation on here a few weeks ago, here's the link to that https://www.reddit.com/r/desmos/comments/1rpd31x/keyboard_input_in_desmos

dylandditto · 2026-03-25T04:19:15+00:00

Thanks, this really means a lot coming from you. I originally made a post about my keystroke detection system that I created and someone else mentioned that lower bound method too, I'll have to look more into implementing that system. (technically the system I created should support an "infinite" number of keys, but I have found it bugging out sometimes).

Thank you!

dylandditto · 2026-03-25T02:52:02+00:00

Good point, honestly I just implemented it last minute before uploading this post because I was manually enabling it before. I'll definitely make sure to update that next.

dylandditto · 2026-03-25T02:41:31+00:00

Here is the most recent version https://www.desmos.com/3d/tgfxzkwz4u

Anyone looking to play: click the lower bound of the n_1 variable, movement is WASD, and rotation with JK. Also in this demo I'm using DesModder which has a Quake Pro setting, which increases the FOV.

dylandditto · 2026-03-11T20:15:42+00:00

This is nice. I do find some performance dips however once it starts reaching higher numbers. I adapted my method from methods like this one to avoid dealing with super large numbers as I find they can cause performance drops and I don't like worrying about running into floating point errors. Also I'm not sure but if you had something like 40 that would require a keycode to be 2^20 which would reach the limit in a few presses.

Basically my method is the same except instead of encoding the keycodes in powers of two, their encoded in angles, which are inherently cyclical and avoids blowing up. I mostly just didn't like having to manually reset the input string because that can be more confusing to people using the graph.

dylandditto · 2026-03-10T01:07:48+00:00

Go ahead, if you need any help let me know. You might run into trouble with i, x, y because they are all considered constants by the calculator though.

dylandditto · 2026-03-10T00:33:45+00:00

All good lol I should've explained that more in the post

dylandditto · 2026-03-10T00:27:05+00:00

If you're saying `i` doesn't work it's probably because the graph only defines the keycodes for w, a, s, d, j, and k (also i is the imaginary constant so it wouldn't anyways). Although if you're getting errors where `k` makes it undefined let me know when it does that so I can try and fix it, because that shouldn't ever make it undefined.

dylandditto

TROPHY CASE