mirror of
https://github.com/open-goal/jak-project
synced 2026-06-22 00:56:36 -04:00
Tyler Wilding
c162c66118
This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same:  > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: 
35 lines
1.2 KiB
Common Lisp
35 lines
1.2 KiB
Common Lisp
;;-*-Lisp-*-
|
|
(in-package goal)
|
|
(bundles "ENGINE.CGO" "GAME.CGO")
|
|
(require "engine/draw/drawable-inline-array-h.gc")
|
|
|
|
;; DECOMP BEGINS
|
|
|
|
;; A "draw-node" is a way to group together a bunch of drawables (possibly other draw-nodes) in a BVH
|
|
;; This BVH is used for sphere-in-view culling and the broad phase collision detection.
|
|
;; _most_ uses of draw-node are in a special tree with these properties:
|
|
;; - between 1 and 8 roots.
|
|
;; - each child has between 1 and 8 children
|
|
;; - all leaves are stored at the same depth
|
|
;; - all nodes and leaves have visibility IDs
|
|
|
|
;; shrub does not have these properties - it supports arbitrary children counts, leaves
|
|
;; may occur at any depth, and nothing has visibility ids.
|
|
|
|
(deftype draw-node (drawable)
|
|
((child-count uint8 :offset 6)
|
|
(flags uint8 :offset 7)
|
|
(child drawable :offset 8)
|
|
(distance float :offset 12)))
|
|
|
|
;; for non-shrub uses of draw-node, this is used to store all the draw-nodes at a given depth.
|
|
(deftype drawable-inline-array-node (drawable-inline-array)
|
|
((data draw-node 1 :inline)
|
|
(pad uint32)))
|
|
|
|
;; the types of these fields are a guess for now.
|
|
;; used for draw-node-cull function
|
|
(deftype draw-node-dma (structure)
|
|
((banka draw-node 32 :inline)
|
|
(bankb draw-node 32 :inline)))
|