mirror of
https://github.com/open-goal/jak-project
synced 2026-08-07 10:16:45 -04:00
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: 
58 lines
2.4 KiB
Common Lisp
58 lines
2.4 KiB
Common Lisp
;;-*-Lisp-*-
|
|
(in-package goal)
|
|
(bundles "ENGINE.CGO" "GAME.CGO")
|
|
(require "kernel-defs.gc")
|
|
|
|
;; res is the very generic resource storage system. See res.gc for more information.
|
|
|
|
;; DECOMP BEGINS
|
|
|
|
;; the res-tag describes some data
|
|
(deftype res-tag (uint128)
|
|
((name symbol :offset 0) ;; name used for lookups
|
|
(key-frame float :offset 32) ;; if it has a time value associated with it
|
|
(elt-type type :offset 64) ;; the type of the data stored
|
|
(data-offset uint16 :offset 96) ;; offset to our data within our lump
|
|
(elt-count uint32 :offset 112 :size 15) ;; if we're an array
|
|
(inlined? uint8 :offset 127 :size 1) ;; if our data is an inline array or not.
|
|
))
|
|
|
|
;; the indices of two res tags. If the specific key-frame time is in between two
|
|
;; res-tags, this type is used to return the indices of the first res tag before and after
|
|
;; the specified time.
|
|
(deftype res-tag-pair (uint64)
|
|
((lo int32 :offset 0)
|
|
(hi int32 :offset 32))
|
|
;; made-up type
|
|
)
|
|
|
|
;; a res-lump is a collection of res-tags and the associated data.
|
|
;; it's used as the base type for entities where the res stores various parameters.
|
|
(deftype res-lump (basic)
|
|
((length int32)
|
|
(allocated-length int32)
|
|
(data-base pointer)
|
|
(data-top pointer)
|
|
(data-size int32)
|
|
(extra entity-links)
|
|
(tag (pointer res-tag)))
|
|
(:methods
|
|
(new (symbol type int int) _type_)
|
|
(get-property-data (_type_ symbol symbol float pointer (pointer res-tag) pointer) pointer :no-virtual)
|
|
(get-property-struct (_type_ symbol symbol float structure (pointer res-tag) pointer) structure :no-virtual)
|
|
(get-property-value (_type_ symbol symbol float uint128 (pointer res-tag) pointer) uint128 :no-virtual)
|
|
(get-property-value-float (_type_ symbol symbol float float (pointer res-tag) pointer) float :no-virtual)
|
|
(get-tag-index-data (_type_ int) pointer)
|
|
(get-tag-data (_type_ res-tag) pointer)
|
|
(allocate-data-memory-for-tag! (_type_ res-tag) res-tag)
|
|
(sort! (_type_) _type_)
|
|
(add-data! (_type_ res-tag pointer) res-lump)
|
|
(add-32bit-data! (_type_ res-tag object) res-lump)
|
|
(lookup-tag-idx (_type_ symbol symbol float) res-tag-pair :no-virtual)
|
|
(make-property-data (_type_ float res-tag-pair pointer) pointer)
|
|
(get-curve-data! (_type_ curve symbol symbol float) symbol)))
|
|
|
|
(define *res-key-string* (new 'global 'string 64 (the-as string #f))) ;; why 64?
|
|
|
|
(define-extern *res-static-buf* pointer)
|