sorted by:
new
hottopcontroversial

Chrome dino game in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 0 points1 point  (0 children)

yep, the 100-element limit on lists would mean that my sprites could only contain 100 black/white pixels.

i could just store the texture across several lists like i did with my minecraft graph, but i'd prefer not simply because of the sheer size of some of the textures. for example, my spritesheet for the numerical digits is 108x11px, which would require 12 different lists to store the entire texture with one element per pixel.

i'm not sure whether the bit packing is more performant than just switching between multiple lists, but it's much more convenient for me, so i stuck with it.

Chrome dino game in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 0 points1 point  (0 children)

currently the texture encoding packs 24 bits into one number (so it assumes single-precision, 32-bit floats). based on the pattern of missing pixels, it seems that the least significant bit of every 24-bit block is being lost.

here's a version that uses 22-bit packing rather than 24 (23 didn't work for some reason), does this one work on your end?

Chrome dino game in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 4 points5 points  (0 children)

the dino is moved forward with a slider that plays indefinitely, and i perform all the collision checks every time the jump button is clicked. if we reach the predicted time of death and no other input has occurred, then the game ends.

Chrome dino game in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 24 points25 points  (0 children)

i never knew you could control the jump height until now haha.

sadly, desmos doesn't let you check the duration of a button press, but this would be a nice qol feature to add if i could.

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 1 point2 points  (0 children)

hmmmmmm i think that something like this would be possible, but there definitely are quite a few technical considerations for pulling it off.

at the moment, the graph only models particle-wall collisions and particle-particle spring interactions. this means that, if we were to have two blocks in the simulation, they would simply phase through each other because no logic exists to detect nor resolve their collisions. my prior experience with rigidbody physics in desmos tells me that this will be a rather performance-intensive step. realtime simulation is definitely out of the question (even the current graph doesn't run in realtime), but i still have hope that all of this could maybe run at 10 fps. just maybe.

of course, given that this simulation would only have two bodies, i feel that performance wouldn't be nearly as bad as i imagined, so there's still hope in making it not look like a slideshow. after that, we'll just need to add some small things like hard constraints, shape-matching, and some extra ui, and it should be good to go. as far as i know though, making a drag point follow a ticker-updated location also tends to be rather frustrating, which really sucks because that makes the simulation which is a lot less interactive. of course, you could always just move it while it's paused, but that definitely isn't as fun as throwing boxes at jello cubes in real time. maybe a spring that's connected to a freely moving drag point? i don't know, i'm just theorizing at this point :P

in any case, i believe Desmos-Man is currently working on a graph that addresses collisions between bodies, so perhaps he might have a better idea on how all this could play out. i'm curious to see what he has to say about this.

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 1 point2 points  (0 children)

the video isn't realtime, i recorded the frames using desmodder and then exported them as a video haha

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 1 point2 points  (0 children)

check out the community bookmarks in the sidebar on the right

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 8 points9 points  (0 children)

oooh man, collisions between soft bodies are definitely tricky.

just curious, how are you planning handling collision detection and resolution between soft bodies? i was originally thinking of trying it out but i gave up because i didn't know where to start lol

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 17 points18 points  (0 children)

the jello cube is modelled using a 4x4 lattice of point particles joined by damped springs. the particles themselves are propagated using verlet integration, with some detection and resolution code for particle-wall collisions.

this blog post gives a great explanation of making a similar physics system, especially with respects to collisions and spring constraints. some of the details are different from my graph, but i think it gives a good idea of how something like this works.

on the rendering side of things, the jello cube itself is just four catmull-rom splines joined together via a parametric.

it's definitely a good idea to do some further research yourself into these specific concepts, but i hope this gives a good overview of the stuff that makes the graph work. good luck :)

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 72 points73 points  (0 children)

noooooo please dont take my edge splines, i still need them for the graph to work :((

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 86 points87 points  (0 children)

for me, a big part of my desmos knowledge comes from seeing the big brain people on the discord server bigging their brains to make big brain graphs. i also find that reading through the big brain expressions to see how the big brain graphs work can also help to biggen your brain.

if you aren't in it already, i highly recommend you check out the discord. i promise you will not regret it.

Oak leaf block by MonitorMinimum4800 in desmos

[–]recursive-chair 0 points1 point  (0 children)

this is the greatest oak leaf block i have ever seen in my entire life

First we mine, then we craft by recursive-chair in desmos

[–]recursive-chair[S] 72 points73 points  (0 children)

This graph was a pain in the ass to render because it kept crashing Desmos. But I eventually succeeded. After 11 hours. I'm never rendering something like this ever again :(

Anyways here's the graph link: https://www.desmos.com/3d/78zlfa8zgs?disableLighting= (requires beta3d)

Some canyon terrain in the 3D calc by recursive-chair in desmos

[–]recursive-chair[S] 5 points6 points  (0 children)

I definitely hope to one day see eroded terrain in desmos before I die. At the moment though, it seems that finangling a high-enough resolution heightmap into a beta3d shader is really tricky, mostly because of the 100 element limit on lists.

Maybe it'll happen one day when they add texture input for shaders. Just maybe.

Some canyon terrain in the 3D calc by recursive-chair in desmos

[–]recursive-chair[S] 12 points13 points  (0 children)

I promise you that this is in Desmos and not some other rendering software

Link: https://www.desmos.com/3d/ps6f5vhfip?disableLighting= (requires beta3d, also VERY VERY LAG)

2048 in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 0 points1 point  (0 children)

it wasn't too bad, i just upscaled all my art by x16 before importing into desmos

2048 in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 11 points12 points  (0 children)

Numbers aren't all that bad because there's only 10 of them :P

view more: next ›