mirror of
https://github.com/open-goal/jak-project.git
synced 2024-10-20 11:26:18 -04:00
d1ece445d4
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.
57 lines
1.6 KiB
Common Lisp
57 lines
1.6 KiB
Common Lisp
;;-*-Lisp-*-
|
|
(in-package goal)
|
|
(bundles "BEA.DGO")
|
|
|
|
(require "engine/math/vector-h.gc")
|
|
|
|
;; name: air-h.gc
|
|
;; name in dgo: air-h
|
|
;; dgos: BEA, L1
|
|
|
|
;; DECOMP BEGINS
|
|
|
|
(deftype air-box (structure)
|
|
((vecs vector 2 :inline)
|
|
(x-pos float :overlay-at (-> vecs 0 x))
|
|
(height-level float :overlay-at (-> vecs 0 y))
|
|
(z-pos float :overlay-at (-> vecs 0 z))
|
|
(cos-angle float :overlay-at (-> vecs 0 w))
|
|
(x-length float :offset 16)
|
|
(z-length float :offset 24)
|
|
(sin-angle float :offset 28)
|
|
)
|
|
)
|
|
|
|
|
|
(defun point-in-air-box-area? ((arg0 float) (arg1 float) (arg2 air-box))
|
|
(let ((v0-0 #f))
|
|
(let ((f0-2 (+ (* arg0 (-> arg2 cos-angle)) (* arg1 (-> arg2 sin-angle))))
|
|
(f1-5 (- (* arg1 (-> arg2 cos-angle)) (* arg0 (-> arg2 sin-angle))))
|
|
)
|
|
(if (and (>= f0-2 0.0) (>= f1-5 0.0) (< f0-2 (-> arg2 x-length)) (< f1-5 (-> arg2 z-length)))
|
|
(set! v0-0 #t)
|
|
)
|
|
)
|
|
v0-0
|
|
)
|
|
)
|
|
|
|
(defun point-in-air-box? ((arg0 vector) (arg1 air-box))
|
|
(when (< (-> arg1 height-level) (-> arg0 y))
|
|
(let ((f1-2 (- (-> arg0 x) (the-as float (-> arg1 x-pos))))
|
|
(f2-1 (- (-> arg0 z) (-> arg1 z-pos)))
|
|
(v1-0 arg1)
|
|
(v0-0 #f)
|
|
)
|
|
(let ((f0-5 (+ (* f1-2 (-> v1-0 cos-angle)) (* f2-1 (-> v1-0 sin-angle))))
|
|
(f1-4 (- (* f2-1 (-> v1-0 cos-angle)) (* f1-2 (-> v1-0 sin-angle))))
|
|
)
|
|
(if (and (>= f0-5 0.0) (>= f1-4 0.0) (< f0-5 (-> v1-0 x-length)) (< f1-4 (-> v1-0 z-length)))
|
|
(set! v0-0 #t)
|
|
)
|
|
)
|
|
v0-0
|
|
)
|
|
)
|
|
)
|