Files
jak-project/goal_src/jak1/engine/entity/res-h.gc
T
Tyler Wilding c162c66118 g/j1: Cleanup all main issues in the formatter and format all of goal_src/jak1 (#3535)
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:

![Screenshot 2024-05-25
132900](https://github.com/open-goal/jak-project/assets/13153231/015e6f20-8d19-49b7-9951-97fa88ddc6c2)
> 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:

![image](https://github.com/open-goal/jak-project/assets/13153231/0edfaba1-6d36-40f5-ab23-0642209867c4)
2024-06-05 22:17:31 -04:00

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)