Very cool! I made a similar thing[1], but I didn't put as much attention on the controls or the camera concept. I had hoped to gain some intuitive understanding of 4D space, but in the end I did not succeed.
How did you do collision detection and physics here?
Also shameless self promotion - if you're interested in 4D collision detection (and rendering, and rigid body physics), I've made a semi-tutorial-style repo here:
+1 to these books - they have some really interesting worldbuilding. Even the later books have some good parts (quite a good Moria-like sequence, some more exposition on the current state of the insane remnants of Cunuroi society), but they definitely do lose the plot a bit. I'm still not sure myself what really happened in the end.
Yeah it’s very interesting meeting the youngest Elf. But what happened at the end is pretty clear, I thought, and the series is called the Second Apocalypse after all.
This is what I do too, including hacking PuTTY to support it. I offered the patch upstream, but it seems they were not interested due to security concerns (even having it off by default). Fair enough, I suppose, but a man can dream...
This is the explanation that made it click for me, although in my experience it seems like he's wrong about being able to rule out the need for doing certain checks when you already "know" the origin is not in that section due to how you got to where you are. Not sure if my implementation was just shitty, but you'll get weird results when objects are very close if you don't exhaustively check every sector - probably due to numerical imprecision, if I had to guess.
Another nice thing about this one is that in the case where the objects intersect, you can just keep iterating mostly the same algorithm to get the intersection points, rather than needing to use Expanding Polytope as with GJK.
This is pretty cool. I've had thoughts (or dreams, more accurately :) of a language like this every time I get a runtime 'type error in q. I gotta say, I prefer q's syntax, though :)
q with static typing and a sensible pricing model would be amazing.
I do think that q's main strength is not its speed, but the fact that qSQL statements are a first class citizen in the language - no network hops, no awkward marshalling and unmarshalling of data, no awkward mismatch around how to use nulls, nans, tz-aware timestamps etc.
I started Empirical with the goal of "q like Haskell". The end result went in a radically different direction, but the guiding light has always been to have a statically typed language where tables and queries are a first-class operation.
The source code is publicly available under AGPL with the Commons Clause:
I had to figure this out recently, a couple things that really helped me are Erin Catto's GDC lectures (particularly [1]) and Allen Chou's game physics articles [2].
I think of a Jacobian as a way to transform the velocities from however they're stored for the interacting objects into linear world-space velocities.
For example, in 2D rigid body physics, rotational velocity is usually just a single number representing how fast something is spinning. Given a radius from the center of a spinning object (e.g. object origin -> a contact point in world space), the instantaneous linear velocity is the rotation speed times the tangent to that radius. Therefore, the Jacobian is just that tangent vector - multiplication by that vector transforms scalar rotational velocities into 2D linear velocities. The Jacobian for the object's linear velocity is just the identity matrix.
The rotation Jacobian is more complicated in 3D and 4D, but the principal is the same - find a matrix (at a particular point, usually the contact point or the joint location) to multiply with whatever represents rotational velocity to get the linear velocity.
my initial thought was that hyperspace would allow a _shortening_ of the distance traveled from point P0(x,y,z,q) to P1(x,y,z,q). Since I was _really_ into space combat games at the time... that would have been really cool!
However, - and this is obvious when you work through it - when you use Euclidean distance (https://mathworld.wolfram.com/Distance.html - see the General equation), the distance travelled increases, thus obviating a key part of my game, which was to "jump" through hyperspace to shorten the trip. I didn't care to rewrite math enough to make the game work out, and since I'd spent so much time learning math, graphics,and larger-scale program design, I was burnt out. It was a great experience.
One day I might return to the notion, but it'll be around the hyper-dimensionality experience, not as a combat game. I don't like the slice mode of 4D games qua the OP, I far prefer projections from 4D as a way to understand the 4D realm.
How did you do collision detection and physics here?
1. https://beaumayns.github.io/box4d/