Deprecated: Function create_function() is deprecated in /home/neverfo4/public_html/fmpbo/include/parser.php on line 811

1 (edited by camthesaxman 2017-11-02 16:59:56)

Topic: Trying to get familiar with the code

I've been reading through the source code lately to get a better understanding of how this all works. There are a few terms thrown around here and there that I don't quite understand what they are.

Lump: A basic convex 3D shape?
Body: A collection of lumps treated as a single rigid object?
Billboard: I'd guess these are flat images that always face the screen, like the inside of the reactor ball.
Varying: Animated bodies whose movement is a function of time? Like the thwomps, moving platforms, and animated ball parts like the atom electrons.
Path: A function that controls the movement of a varying body?

How is the physics update and drawing synchronized? Based on what I can see, it seems that the physics engine updates at a fixed interval DT, which is 1/90 of a second. It seems to max out one CPU core, both on my old Pentium 4, and my significantly faster Core i3.


Re: Trying to get familiar with the code

I'll just correct the wrong bits.

Path is a path_corner entity in the map file.

Billboards are simply textured quads. Sometimes they face the camera, but that's optional.

"varying" isn't a term that is used in the code. There's a thing called s_vary that holds the dynamic simulation state. For example, when we want to update ball position, we don't change the static state (s_base), instead we update the s_vary structure. That way, on level restart, we don't have to read/parse/load the SOL from disk because we've overwritten all its data, we just have to clear the vary struct / dynamic state, which is very fast. This also keeps simulation state out of mapc.

Billboard animations like what you see in most balls and in the backgrounds are NOT dynamic state. All their state is completely defined as a function of time.

The rendering loop is very simple. It runs as often as it can. That's what maxes out your CPU. The rendering loop passes the delta time between its frames to the physics simulation. There's a "lockstep" structure (it's not really lock-step, that name just stuck historically) that accumulates the delta time until a 1/90 of a second has passed, then runs exactly one physics update. Physics updates have to use the same delta time, otherwise the simulation is unstable and may produce wildly different results depending on how fast your particular PC is. To smooth out the resulting 1/90 second jumpy frames, there's a number of lerp structures (from "linear interpolation") that keep 2 updates worth of the vary state and blend between them, depending on how much time is left from the current frame until the next physics update.