517
I wrote a dice rolling script with 3d rendering, collisions and friction in bash because why not [edit: code available now]
(files.catbox.moe)
Daddy needs a new pair of RAM!
edit: the fps are way better in smaller terminal windows with lower character count but then it's hard to make out the dice. D:
edit2: code here (expires in 2 weeks)
I'm curious why it seems the time slows down at the end compared to reality? Because more computation is needed to check if it's a stable state?
the final resolution stage was a huge headache and as you can see, one I didn't fully solve. Basically when the dice finally settle, particularly those with more sides, lots and lots of micro collisions happen in close sequence, each one having to apply friction and bounce back. As velocities come close to be rounded to 0, the bounce back effect and force of gravity no longer provide movement, but the final angle of the bottom face may not be fully settled on the floor. So basically if i don't ignore all these tiny collisions I get the frame rate drop you see and if I do, I can arrive at not fully settled states which can become ambiguous result-wise in, say, the 20-sided die.
why not save the state of the di(ce) in the settling phase and choose (or allow user assignable) value for how many consecutive identicle states before freezing the di(ce) and reporting the result?
my only concern would be a "spinning" di but short of colliding with other dice, that seems technically solved
that's one of the aspects of the current implementation