Files
jak-project/goal_src/jak1/engine/physics/trajectory.gc
T
Tyler Wilding d1ece445d4 Dependency graph work - Part 1 - Preliminary work (#3505)
Relates to #1353 

This adds no new functionality or overhead to the compiler, yet. This is
the preliminary work that has:
- added code to the compiler in several spots to flag when something is
used without being properly required/imported/whatever (disabled by
default)
- that was used to generate project wide file dependencies (some
circulars were manually fixed)
- then that graph underwent a transitive reduction and the result was
written to all `jak1` source files.

The next step will be making this actually produce and use a dependency
graph. Some of the reasons why I'm working on this:
- eliminates more `game.gp` boilerplate. This includes the `.gd` files
to some extent (`*-ag` files and `tpage` files will still need to be
handled) this is the point of the new `bundles` form. This should make
it even easier to add a new file into the source tree.
- a build order that is actually informed from something real and
compiler warnings that tell you when you are using something that won't
be available at build time.
- narrows the search space for doing LSP actions -- like searching for
references. Since it would be way too much work to store in the compiler
every location where every symbol/function/etc is used, I have to do
ad-hoc searches. By having a dependency graph i can significantly reduce
that search space.
- opens the doors for common shared code with a legitimate pattern.
Right now jak 2 shares code from the jak 1 folder. This is basically a
hack -- but by having an explicit require syntax, it would be possible
to reference arbitrary file paths, such as a `common` folder.

Some stats:
- Jak 1 has about 2500 edges between files, including transitives
- With transitives reduced at the source code level, each file seems to
have a modest amount of explicit requirements.

Known issues:
- Tracking the location for where `defmacro`s and virtual state
definitions were defined (and therefore the file) is still problematic.
Because those forms are in a macro environment, the reader does not
track them. I'm wondering if a workaround could be to search the
reader's text_db by not just the `goos::Object` but by the text
position. But for the purposes of finishing this work, I just statically
analyzed and searched the code with throwaway python code.
2024-05-12 12:37:59 -04:00

120 lines
3.8 KiB
Common Lisp

;;-*-Lisp-*-
(in-package goal)
(bundles "ENGINE.CGO" "GAME.CGO")
(require "engine/math/vector.gc")
(require "engine/physics/trajectory-h.gc")
(require "engine/debug/debug-h.gc")
;; name: trajectory.gc
;; name in dgo: trajectory
;; dgos: GAME, ENGINE
;; DECOMP BEGINS
(defmethod eval-position! ((this trajectory) (time float) (result vector))
"Evaluate the position of the object at a give time"
(set! (-> result quad) (-> this initial-position quad))
(+! (-> result x) (* time (-> this initial-velocity x)))
(+! (-> result y) (* time (-> this initial-velocity y)))
(+! (-> result z) (* time (-> this initial-velocity z)))
(+! (-> result y) (* 0.5 time time (-> this gravity)))
result
)
(defmethod eval-velocity! ((this trajectory) (time float) (result vector))
"Evaluate the velocity of the object at a given time"
(set! (-> result quad) (-> this initial-velocity quad))
(+! (-> result y) (* time (-> this gravity)))
result
)
(defmethod setup-from-to-duration! ((this trajectory) (from vector) (to vector) (duration float) (grav float))
"Set up a trajectory that goes from->to in the given duration"
(set! (-> this initial-position quad) (-> from quad))
(set! (-> this gravity) grav)
(set! (-> this time) duration)
;; the velocity we need in xz to make it in time
(let ((xz-vel (/ (vector-vector-xz-distance to from) duration)))
;; our velocity will point along from -> to
(vector-! (-> this initial-velocity) to from)
;; but have magnitude that we calculated above.
(vector-xz-normalize! (-> this initial-velocity) xz-vel)
)
;; solve for the y velocity that makes us land at the right height.
(set! (-> this initial-velocity y)
(- (/ (- (-> to y) (-> from y)) duration) (* 0.5 duration (-> this gravity)))
)
0
(none)
)
(defmethod setup-from-to-xz-vel! ((this trajectory) (from vector) (to vector) (xz-vel float) (grav float))
"Set up a trajectory that goes from->to with the given velocity"
;; just solve for the duration and use the previous
(let ((duration (/ (vector-vector-xz-distance to from) xz-vel)))
(setup-from-to-duration! this from to duration grav)
)
0
(none)
)
(defmethod setup-from-to-y-vel! ((this trajectory) (from vector) (to vector) (y-vel float) (grav float))
"Set up a trajectory with the given initial y velocity."
(let* ((f0-0 y-vel)
(f1-3 (- (* f0-0 f0-0) (* 2.0 (- (-> from y) (-> to y)) grav)))
(f0-3 900.0)
)
(when (>= f1-3 0.0)
(let ((f0-4 (sqrtf f1-3)))
(set! f0-3 (fmax (/ (- (- y-vel) f0-4) grav) (/ (+ (- y-vel) f0-4) grav)))
)
)
(setup-from-to-duration! this from to f0-3 grav)
)
0
(none)
)
(defmethod setup-from-to-height! ((this trajectory) (arg0 vector) (arg1 vector) (arg2 float) (arg3 float))
"Setup a trajectory that reaches a given height"
(let* ((f1-2 (+ arg2 (fmax (-> arg0 y) (-> arg1 y))))
(f1-5 (* 2.0 (- (-> arg0 y) f1-2) arg3))
(f0-3 4096.0)
)
(if (< 0.0 f1-5)
(set! f0-3 (sqrtf f1-5))
)
(setup-from-to-y-vel! this arg0 arg1 f0-3 arg3)
)
0
(none)
)
(defmethod debug-draw! ((this trajectory))
"Draw the trajectory"
(let ((prev-pos (new 'stack-no-clear 'vector))
(pos (new 'stack-no-clear 'vector))
(num-segments 10)
)
(set! (-> pos quad) (-> this initial-position quad))
(dotimes (s2-0 num-segments)
(set! (-> prev-pos quad) (-> pos quad))
(let ((t-eval (* (-> this time) (/ (+ 1.0 (the float s2-0)) (the float num-segments)))))
(eval-position! this t-eval pos)
)
(add-debug-line
#t
(bucket-id debug-no-zbuf)
prev-pos
pos
(new 'static 'rgba :r #xff :a #x80)
#f
(the-as rgba -1)
)
)
)
0
(none)
)