Game-Decompilation/jak-project
1
0
Fork 0
mirror of https://github.com/open-goal/jak-project.git synced 2024-11-23 06:09:57 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs: fix method docstrings and grab @file comment blocks to use as a file description (#2289)

Browse Source
This commit is contained in:
Tyler Wilding 2023-02-27 18:58:01 -05:00 committed by GitHub
parent 87ff182332
commit c3310e1833
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
53 changed files with 551 additions and 408 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.github/workflows/inform-pages-repo.yaml vendored
View File

@ -57,6 +57,10 @@ jobs:
run: |
./build/goalc/goalc --cmd "(begin (make-group \"all-code\") (gen-docs \"${PWD}\"))" --game jak2
- name: Append File Docstrings
run: |
python ./scripts/docs/append-file-docs.py
- name: Upload Docs Artifact
uses: actions/upload-artifact@v3
with:

6
.vscode/launch.json vendored
View File

@ -5,13 +5,13 @@
"version": "0.2.0",
"configurations": [
{
"name": "Python",
"name": "Append File Docs",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}/scripts/gsrc/lint-gsrc-file.py",
"program": "${workspaceFolder}/scripts/docs/append-file-docs.py",
"console": "integratedTerminal",
"cwd": "${workspaceFolder}",
"args": ["--game", "jak2", "--file", "vehicle-control"]
"args": []
},
]
}

2
.vscode/opengoal.code-snippets vendored
View File

@ -20,7 +20,7 @@
"og:update-with-merge": {
"scope": "opengoal",
"prefix": ["og:update-with-merge"],
"body": [";; og:update-with-merge:${1:substr}"],
"body": [";; og:update-with-merge"],
"description": "The file will be updated with a git merge-file instead of naive copy-paste"
},
}

2
common/type_system/TypeSystem.cpp
View File

@ -645,6 +645,8 @@ MethodInfo TypeSystem::define_method(Type* type,
bool got_existing = try_lookup_method(type, method_name, &existing_info);
if (got_existing) {
// Update the docstring
existing_info.docstring = docstring;
int bad_arg_idx = -99;
// make sure we aren't changing anything that isn't the return type.
if (!existing_info.type.is_compatible_child_method(ts, type->get_name(), &bad_arg_idx) &&

4
goal_src/jak2/engine/collide/collide-frag.gc
View File

@ -5,7 +5,9 @@
;; name in dgo: collide-frag
;; dgos: ENGINE, GAME
;; Note: this is probably not used in jak 2 - this is the old tree-based background collision stuff.
#|@file
Note: this is probably not used in jak 2 - this is the old tree-based background collision stuff.
|#
;; DECOMP BEGINS

25
goal_src/jak2/engine/collide/collide-func.gc
View File

@ -5,20 +5,21 @@
;; name in dgo: collide-func
;; dgos: GAME, ENGINE
;; This file contains the primitive intersection functions used for collision.
;; Most take a description of primitive and a "probe"
;; The probe has an origin and a direction. The length of the direction vector is the length
;; of the probe.
#|@file
This file contains the primitive intersection functions used for collision.
Most take a description of primitive and a "probe"
The probe has an origin and a direction. The length of the direction vector is the length
of the probe.
;; Generally, collision functions will return the fraction of the probe to reach the primitive.
;; For example, if the probe is 5.0 long, and hits the primitive 2.0 away from the probe origin,
;; the return value (u) would be 0.4.
;; If (u) would be > 1.0, then it counts as "not intersecting" (object too far away)
;; If (u) would be < 0.0, then it counts as "not intersecting" (object behind probe)
;; If there's a miss, return COLLISION_MISS, a large negative number.
;; If we are inside of the primitive, return 0.0
Generally, collision functions will return the fraction of the probe to reach the primitive.
For example, if the probe is 5.0 long, and hits the primitive 2.0 away from the probe origin,
the return value (u) would be 0.4.
If (u) would be > 1.0, then it counts as "not intersecting" (object too far away)
If (u) would be < 0.0, then it counts as "not intersecting" (object behind probe)
If there's a miss, return COLLISION_MISS, a large negative number.
If we are inside of the primitive, return 0.0
|#
(defconstant COLLISION_MISS -100000000.0)

38
goal_src/jak2/engine/collide/collide-mesh.gc
View File

@ -5,26 +5,30 @@
;; name in dgo: collide-mesh
;; dgos: ENGINE, GAME
;; note: this file has patched functions
#|@file
note: this file has patched functions
;; this file has functions for foreground mesh collision functions. This is for stuff like jak being on a platform, or a
;; platform pushing jak away.
this file has functions for foreground mesh collision functions. This is for stuff like jak being on a platform, or a
platform pushing jak away.
The "collide-mesh" is the foreground collision mesh type. These can be used as part of a collide-shape.
These can be added to the normal "collide-cache" and work with the most common collision queries.
However, there are a few special case collision queries that use a separate collide-mesh-cache.
The intented use is something like this:
- a mesh is unpacked to the collide-mesh-cache
- primitive vs. mesh tests are done using the unpacked data, reusing the data.
This collide-mesh-cache is limited compared to the real collide cache - this can only hold
a single mesh, so it's limited to tests like single foreground mesh vs. sphere.
Another limitation is that triangles don't have per-tri pat info.
|#
;; og:update-with-merge
;; DECOMP BEGINS
;; The "collide-mesh" is the foreground collision mesh type. These can be used as part of a collide-shape.
;; These can be added to the normal "collide-cache" and work with the most common collision queries.
;; However, there are a few special case collision queries that use a separate collide-mesh-cache.
;; The intented use is something like this:
;; - a mesh is unpacked to the collide-mesh-cache
;; - primitive vs. mesh tests are done using the unpacked data, reusing the data.
;; This collide-mesh-cache is limited compared to the real collide cache - this can only hold
;; a single mesh, so it's limited to tests like single foreground mesh vs. sphere.
;; Another limitation is that triangles don't have per-tri pat info.
(defmethod asize-of collide-mesh ((obj collide-mesh))
(the-as int (+ (-> collide-mesh size) (* (+ (-> obj num-tris) -1) 8)))
@ -656,4 +660,4 @@
(label cfg-7)
#f
)
)
)

8
goal_src/jak2/engine/collide/collide-probe.gc
View File

@ -5,10 +5,12 @@
;; name in dgo: collide-probe
;; dgos: ENGINE, GAME
;; DECOMP BEGINS
#|@file
this file is unused in jak 2.
a number of functions require a bunch of annoying casts/mips2c stuff, but are unused.
|#
;; this file is unused in jak 2.
;; a number of functions require a bunch of annoying casts/mips2c stuff, but are unused.
;; DECOMP BEGINS
(defun creates-new-method? ((arg0 type) (arg1 int))
(let ((v1-1 (-> arg0 parent allocated-length)))

32
goal_src/jak2/engine/collide/collide-shape.gc
View File

@ -5,26 +5,30 @@
;; name in dgo: collide-shape
;; dgos: ENGINE, GAME
#|@file
## Pushers
"pushers" are things that push things out of the way. For example, if a platform hits jak, it pushes him out of the way.
Nothing can ever push back against a pusher - they move on some fixed path and cannot be disturbed.
these are done by pairs of collide-shape's, and don't involve the main collide-cache.
Using the main collide cache wouldn't really make sense because a pusher never interacts with the background
and there's just one check per pair per frame.
the do-push-aways function is what actually does all the tests for all the objects.
there's a "pusher-pool" to make all pushers run at the end of a frame.
the "should push away test" (SPAT) checks to see if the movement of a pusher should push away another collide shape.
it returns a triangle and normal direction to push in.
|#
;; DECOMP BEGINS
;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; PUSHER
;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; "pushers" are things that push things out of the way. For example, if a platform hits jak, it pushes him out of the way.
;; Nothing can ever push back against a pusher - they move on some fixed path and cannot be disturbed.
;; these are done by pairs of collide-shape's, and don't involve the main collide-cache.
;; Using the main collide cache wouldn't really make sense because a pusher never interacts with the background
;; and there's just one check per pair per frame.
;; the do-push-aways function is what actually does all the tests for all the objects.
;; there's a "pusher-pool" to make all pushers run at the end of a frame.
;; the "should push away test" (SPAT) checks to see if the movement of a pusher should push away another collide shape.
;; it returns a triangle and normal direction to push in.
(defmethod pusher-init collide-shape ((obj collide-shape))
"Initialize a collide-shape as a pusher and move it to the pusher pool."
(when (logtest? (collide-spec pusher) (-> obj root-prim prim-core collide-as))

10
goal_src/jak2/engine/collide/collide.gc
View File

@ -5,6 +5,12 @@
;; name in dgo: collide
;; dgos: ENGINE, GAME
#|@file
this is some vif setup stuff that was in jak 1 as well - some code in collide-cache
uses VIF's unpack/upload to modify collision data. This gets ported to c++, just
keeping it here for reference.
|#
(deftype collide-query-with-vec (structure)
"A custom type added because of weirdness discovered in task-arrow::23"
((cquery collide-query :inline)
@ -19,10 +25,6 @@
)
)
;; this is some vif setup stuff that was in jak 1 as well - some code in collide-cache
;; uses VIF's unpack/upload to modify collision data. This gets ported to c++, just
;; keeping it here for reference.
;; DECOMP BEGINS
(define *collide-vif0-init* (new 'static 'boxed-array :type uint32

6
goal_src/jak2/engine/debug/debug-sphere.gc
View File

@ -5,8 +5,10 @@
;; name in dgo: debug-sphere
;; dgos: ENGINE, GAME
;; Functions for drawing wireframe spheres made up of debug lines.
;; Do not call these functions unless *debug-segment* is set.
#|@file
Functions for drawing wireframe spheres made up of debug lines.
Do not call these functions unless *debug-segment* is set.
|#
;; DECOMP BEGINS

8
goal_src/jak2/engine/debug/debug.gc
View File

@ -5,9 +5,11 @@
;; name in dgo: debug
;; dgos: ENGINE, GAME
;; This file contains functions for debug drawing.
;; In general, the 3d functions draw using the camera and the 2d functions draw in screen coordinates.
;; Most functions take a boolean as their first argument. If the boolean is set to #f, it will skip drawing the point.
#|@file
This file contains functions for debug drawing.
In general, the 3d functions draw using the camera and the 2d functions draw in screen coordinates.
Most functions take a boolean as their first argument. If the boolean is set to #f, it will skip drawing the point.
|#
(define-extern draw-string (function string dma-buffer font-context draw-string-result))
(define-extern debug-set-camera-pos-rot! (function vector matrix vector))

4
goal_src/jak2/engine/debug/nav/nav-graph-editor.gc
View File

@ -13,8 +13,6 @@
;; DECOMP BEGINS
(deftype nav-graph-command (structure)
((com-type uint32 :offset-assert 0) ;; TODO - enum
(id int32 :offset-assert 4)
@ -124,4 +122,4 @@
;; stub
(defun get-nav-graph-editor ()
(the nav-graph-editor #f)
)
)

51
goal_src/jak2/engine/dma/dma-bucket.gc
View File

@ -5,33 +5,34 @@
;; name in dgo: dma-bucket
;; dgos: ENGINE, GAME
#|@file
A dma-bucket is used to organize dma data into groups called buckets.
Each bucket is a linked list of DMA. At DMA time, the buckets are sent in order.
A dma-bucket is a 16 byte thing that lives in the dma-buffer.
buckets live consecutively in the dma-buffer, and can mark the start of a DMA chain
location anywhere.
The bucket doesn't own the data, but rather is a beginning of a linked list of DMA data associated with that bucket
that's stored somewhere else.
At the end, all the buckets are spliced together.
The typical process is:
- empty buckets are allocated with add-buckets
- tags are put somewhere and added to the appropriate bucket with insert-tag, updating last as needed.
- buckets are patched to link to each other with dma-buffer-patch-buckets.
the idea here is that you can build the buckets in whatever order you want, but the buckets
will be DMAd in the bucket allocation order.
Each bucket contains:
a tag, (64-bits), to point to the chain of the bucket
last, a pointer to the last tag of this bucket, so that the bucket can be patched to point to the next.
|#
;; DECOMP BEGINS
;; A dma-bucket is used to organize dma data into groups called buckets.
;; Each bucket is a linked list of DMA. At DMA time, the buckets are sent in order.
;; A dma-bucket is a 16 byte thing that lives in the dma-buffer.
;; buckets live consecutively in the dma-buffer, and can mark the start of a DMA chain
;; location anywhere.
;; The bucket doesn't own the data, but rather is a beginning of a linked list of DMA data associated with that bucket
;; that's stored somewhere else.
;; At the end, all the buckets are spliced together.
;; The typical process is:
;; - empty buckets are allocated with add-buckets
;; - tags are put somewhere and added to the appropriate bucket with insert-tag, updating last as needed.
;; - buckets are patched to link to each other with dma-buffer-patch-buckets.
;; the idea here is that you can build the buckets in whatever order you want, but the buckets
;; will be DMAd in the bucket allocation order.
;; Each bucket contains:
;; a tag, (64-bits), to point to the chain of the bucket
;; last, a pointer to the last tag of this bucket, so that the bucket can be patched to point to the next.
(defun dma-buffer-add-buckets ((arg0 dma-buffer) (arg1 int))
"Add count buckets. Each bucket is initialized as empty and won't transfer anything."
(let ((v0-0 (-> arg0 base)))

33
goal_src/jak2/engine/dma/dma-buffer.gc
View File

@ -5,25 +5,26 @@
;; name in dgo: dma-buffer
;; dgos: ENGINE, GAME
#|@file
DMA buffers store data to be sent over DMA.
They are a very simple wrapper around the data.
Typically a dma-buffer will store dma-buckets or other more complicated data structures.
;; DMA buffers store data to be sent over DMA.
;; They are a very simple wrapper around the data.
;; Typically a dma-buffer will store dma-buckets or other more complicated data structures.
The main display list uses a "chain transfer". In this mode, the DMA system reads dma-tags which
tell it what to transfer next. This can be used to construct linked lists of DMA data.
;; The main display list uses a "chain transfer". In this mode, the DMA system reads dma-tags which
;; tell it what to transfer next. This can be used to construct linked lists of DMA data.
If the DMA is configured correctly, it is possible to make the first quadword contain
both a dma-tag and a tag for the peripheral. This allows you to have a single quadword
tag that controls both the DMA and peripheral. We call these a "dma-packet" for some reason.
;; If the DMA is configured correctly, it is possible to make the first quadword contain
;; both a dma-tag and a tag for the peripheral. This allows you to have a single quadword
;; tag that controls both the DMA and peripheral. We call these a "dma-packet" for some reason.
;; Ex:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 32-bit vifcode ;; 32-bit vifcode ;; 64-bit dma-tag ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; in this case, the vifcodes will be sent to the vif, if
;; the dma transfer has tte set.
;; note that the second vifcode can also hold other stuff depending on the mode.
Ex:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
32-bit vifcode ;; 32-bit vifcode ;; 64-bit dma-tag ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
in this case, the vifcodes will be sent to the vif, if
the dma transfer has tte set.
note that the second vifcode can also hold other stuff depending on the mode.
|#
;; DECOMP BEGINS

6
goal_src/jak2/engine/dma/dma-disasm.gc
View File

@ -5,9 +5,11 @@
;; name in dgo: dma-disasm
;; dgos: ENGINE, GAME
;; DECOMP BEGINS
#|@file
Debug tool to print out a DMA list.
|#
;; Debug tool to print out a DMA list.
;; DECOMP BEGINS
(declare-file (debug))

22
goal_src/jak2/engine/dma/dma-h.gc
View File

@ -5,18 +5,20 @@
;; name in dgo: dma-h
;; dgos: ENGINE, GAME
#|@file
Constants/type for the PS2 DMA hardware
There are a number of DMA channels.
The PS2 supports several types of DMA, including simple chunk transfer and more complicated
"chain" transfers, where the hardware can follow a linked data-structure.
The code is organized into dma, dma-buffer, and dma-bucket
- dma interacts with the hardware and actually sends the DMA data.
- dma-buffer is memory management for the data to be sent
- dma-bucket is organization of all the frame's DMA data in the correct order
|#
;; DECOMP BEGINS
;; Constants/type for the PS2 DMA hardware
;; There are a number of DMA channels.
;; The PS2 supports several types of DMA, including simple chunk transfer and more complicated
;; "chain" transfers, where the hardware can follow a linked data-structure.
;; The code is organized into dma, dma-buffer, and dma-bucket
;; - dma interacts with the hardware and actually sends the DMA data.
;; - dma-buffer is memory management for the data to be sent
;; - dma-bucket is organization of all the frame's DMA data in the correct order
;; DMA Channel Control Register. This starts the DMA and can be checked to see if it's done.
;; There is one CHCR per DMA channel.
(deftype dma-chcr (uint32)

29
goal_src/jak2/engine/engine/connect.gc
View File

@ -5,22 +5,23 @@
;; name in dgo: connect
;; dgos: ENGINE, GAME
#|@file
This extremely confusing "connection system" allows the connection between
"engines" and "processes". Basically, a process can "register" itself with any number of "engines".
The "engines" can then iterate through all the connected processes. If a process is destroyed, it will
be removed from all engines. It is okay to connect a process to multiple engines, or even to the same engine
multiple times.
Some example uses:
- a "foreground-engine" has connections to all foreground objects that need to be drawn on each frame.
- when a process wants to change a game setting, it opens a connection to the settings engine to request a change.
when the process is killed (or it stops requesting the change), the setting change is reverted.
A "connection" is really just a function that gets called when the engine runs, or a set of parameters that the engine can iterate through.
|#
;; DECOMP BEGINS
;; This extremely confusing "connection system" allows the connection between
;; "engines" and "processes". Basically, a process can "register" itself with any number of "engines".
;; The "engines" can then iterate through all the connected processes. If a process is destroyed, it will
;; be removed from all engines. It is okay to connect a process to multiple engines, or even to the same engine
;; multiple times.
;; Some example uses:
;; - a "foreground-engine" has connections to all foreground objects that need to be drawn on each frame.
;; - when a process wants to change a game setting, it opens a connection to the settings engine to request a change.
;; when the process is killed (or it stops requesting the change), the setting change is reverted.
;; A "connection" is really just a function that gets called when the engine runs, or a set of parameters that the engine can iterate through.
;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; connectable
;;;;;;;;;;;;;;;;;;;;;;;;;;;

2
goal_src/jak2/engine/entity/res.gc
View File

@ -5,7 +5,7 @@
;; name in dgo: res
;; dgos: ENGINE, GAME
#|
#|@file
res is a generic storage system for not very large data, used mostly for the game entities.
These res files store collections of data, which can be as values (int8, int16, int32, int64, uint8, uint16, uint32, uint64, float, vector), or any structure (as references), which are tagged and identified with a res-tag.
The data is stored similar to an unboxed inline-array, the type of the data is stored in the res-tag.

6
goal_src/jak2/engine/geometry/bounding-box.gc
View File

@ -5,8 +5,10 @@
;; name in dgo: bounding-box
;; dgos: ENGINE, GAME
;; Implementation of bounding box functions.
;; These boxes are used as a primitive in the foreground collision system.
#|@file
Implementation of bounding box functions.
These boxes are used as a primitive in the foreground collision system.
|#
;; DECOMP BEGINS

49
goal_src/jak2/engine/gfx/foreground/bones.gc
View File

@ -5,33 +5,34 @@
;; name in dgo: bones
;; dgos: ENGINE, GAME
;; DECOMP BEGINS
#|@file
bones, joints, cspace, matrix, joint-anim-frames...
The "joints" define the structure of the skeleton, just storing a bind pose, and parent info. These don't change,
and are loaded as part of the skeleton. The actual joint objects are stored in the art-joint-geo.
The "do-joint-math" method of process-drawable is responsible for computing the joint-anim-frame and the bones.
The "cspace" system is used to compute bones from joint-anim-frames.
The "joint-anim-frame" is a list of transformqs for the relative transform between bones.
The "bones" are the world space transform of each 'bone'
The "do-joint-math" function does:
- call the generate-frame-function callback to generate a joint-anim-frame (does the joint anim decompress/blending)
- call the prebind-function which can modify the relative transforms (eg: joint-mods)
- walk the tree of joints, computing bones using the cspace
- call the postbind-function, for other effects.
The "bones" system creates matrices for foreground renderers from bones/joints.
The inputs are bones/joints, and the output is pris-mtx, which is a 4x4 "t-mtx" for transforming, and a 3x3 (stored in 3 vec4's)
n-mtx for rotating normals.
all matrices are calculated at once, and shared between merc/emerc/gmerc/shadow
this is done by a linked list of "bone calculations", which is stashed in the dma buffer.
|#
;; todo check bad reference.
;; bones, joints, cspace, matrix, joint-anim-frames...
;; The "joints" define the structure of the skeleton, just storing a bind pose, and parent info. These don't change,
;; and are loaded as part of the skeleton. The actual joint objects are stored in the art-joint-geo.
;; The "do-joint-math" method of process-drawable is responsible for computing the joint-anim-frame and the bones.
;; The "cspace" system is used to compute bones from joint-anim-frames.
;; The "joint-anim-frame" is a list of transformqs for the relative transform between bones.
;; The "bones" are the world space transform of each 'bone'
;; The "do-joint-math" function does:
;; - call the generate-frame-function callback to generate a joint-anim-frame (does the joint anim decompress/blending)
;; - call the prebind-function which can modify the relative transforms (eg: joint-mods)
;; - walk the tree of joints, computing bones using the cspace
;; - call the postbind-function, for other effects.
;; The "bones" system creates matrices for foreground renderers from bones/joints.
;; The inputs are bones/joints, and the output is pris-mtx, which is a 4x4 "t-mtx" for transforming, and a 3x3 (stored in 3 vec4's)
;; n-mtx for rotating normals.
;; all matrices are calculated at once, and shared between merc/emerc/gmerc/shadow
;; this is done by a linked list of "bone calculations", which is stashed in the dma buffer.
;; DECOMP BEGINS
;; list node for pending bone calculations. These are terminated by 0's.
(deftype bone-calculation-list (structure)

20
goal_src/jak2/engine/gfx/hw/display-h.gc
View File

@ -5,16 +5,18 @@
;; name in dgo: display-h
;; dgos: ENGINE, GAME
;; DECOMP BEGINS
#|@file
At any point in time, there are 3 frames in progress:
- one frame is fully rendered and being drawn on the screen.
this frame just sits in the frame buffer, and isn't tracked by the display system.
- one frame is being rendered
(frame buffer is being written to by GS, VU1 sending tris to GS, VIF1 feeding VU1)
this frame needs a DMA buffer that is full, and being read by VIF1
- one frame is being set up. The engine is running gameplay code and generating DMA data
this frame also needs a DMA buffer, which is being filled up.
|#
;; At any point in time, there are 3 frames in progress:
;; - one frame is fully rendered and being drawn on the screen.
;; this frame just sits in the frame buffer, and isn't tracked by the display system.
;; - one frame is being rendered
;; (frame buffer is being written to by GS, VU1 sending tris to GS, VIF1 feeding VU1)
;; this frame needs a DMA buffer that is full, and being read by VIF1
;; - one frame is being set up. The engine is running gameplay code and generating DMA data
;; this frame also needs a DMA buffer, which is being filled up.
;; DECOMP BEGINS
;; per-frame DMA buffers, timing, and profiling info.
(deftype display-frame (basic)

20
goal_src/jak2/engine/gfx/math-camera-h.gc
View File

@ -5,16 +5,18 @@
;; name in dgo: math-camera-h
;; dgos: ENGINE, GAME
#|@file
The "math-camera" is responsible for computing the projection matrix used in the renderer
from the position of the in-game camera. It also computes some other common camera info.
See cam-update.gc for how the game camera updates the math-camera.
It also contains some GIF stuff, but these seem to be wrong/unused.
Some of the code here may be extremely old and unused, but this does compute the camera projection
matrix used almost everywhere.
|#
;; DECOMP BEGINS
;; The "math-camera" is responsible for computing the projection matrix used in the renderer
;; from the position of the in-game camera. It also computes some other common camera info.
;; See cam-update.gc for how the game camera updates the math-camera.
;; It also contains some GIF stuff, but these seem to be wrong/unused.
;; Some of the code here may be extremely old and unused, but this does compute the camera projection
;; matrix used almost everywhere.
;; unused...
(deftype vis-gif-tag (structure)
((fog0 uint32 :offset-assert 0)
@ -118,4 +120,4 @@
:method-count-assert 9
:size-assert #x634
:flag-assert #x900000634
)
)

36
goal_src/jak2/engine/gfx/math-camera.gc
View File

@ -5,27 +5,29 @@
;; name in dgo: math-camera
;; dgos: ENGINE, GAME
#|@file
;;;;;;;;;;;;;;;;;;;;
math camera basics
;;;;;;;;;;;;;;;;;;;;
the math camera computes the perspective matrix, hvdf offset, and hmge scale.
multiplying a point by the perspective matrix, doing the persepctive divide, then adding hvdf offset gives you:
H : horizontal position (in GS coordinates)
V : vertical position (in GS coordinates)
D : depth (as a 24-bit integer for the z buffer)
F : fog
Multiplying by hmge then checking the clipping flags can be used to see if a point is outside the view frustum.
The "camera-temp" matrix is the perspective matrix multplied by the camera tranformation and is used
renderers that want a single matrix.
|#
(define-extern sprite-distorter-generate-tables (function none))
;; DECOMP BEGINS
;;;;;;;;;;;;;;;;;;;;;;
;; math camera basics
;;;;;;;;;;;;;;;;;;;;;;
;; the math camera computes the perspective matrix, hvdf offset, and hmge scale.
;; multiplying a point by the perspective matrix, doing the persepctive divide, then adding hvdf offset gives you:
;; H : horizontal position (in GS coordinates)
;; V : vertical position (in GS coordinates)
;; D : depth (as a 24-bit integer for the z buffer)
;; F : fog
;; Multiplying by hmge then checking the clipping flags can be used to see if a point is outside the view frustum.
;; The "camera-temp" matrix is the perspective matrix multplied by the camera tranformation and is used
;; renderers that want a single matrix.
;;;;;;;;;;;;;;;;;;;
;; fog correction
;;;;;;;;;;;;;;;;;;;

52
goal_src/jak2/engine/gfx/sky/sky-tng.gc
View File

@ -5,37 +5,39 @@
;; name in dgo: sky-tng
;; dgos: ENGINE, GAME
;; DECOMP BEGINS
;; Sky renderer.
;; this render is much more complicated than the jak 1 version.
;; there's a lot of weird tricks to store values in the VF registers, and a lot of asm,
;; so a lot of this is in C++.
#|@file
Sky renderer.
this render is much more complicated than the jak 1 version.
there's a lot of weird tricks to store values in the VF registers, and a lot of asm,
so a lot of this is in C++.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Large Polygon Renderer
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; there's a special "large polygon renderer" that handles clipping
;; and ps2-specific texture perspective stuff.
;; the way it subdivides is extremely strange, and not well understood, but it works well with the
;; Direct renderer in C++.
;; this renderer is also used for drawing debug regions and some parts of the ocean near the horizon.
there's a special "large polygon renderer" that handles clipping
and ps2-specific texture perspective stuff.
the way it subdivides is extremely strange, and not well understood, but it works well with the
Direct renderer in C++.
this renderer is also used for drawing debug regions and some parts of the ocean near the horizon.
;; there's a lot of state stored in vf registers, so we have to be very careful with this.
there's a lot of state stored in vf registers, so we have to be very careful with this.
;; VF registers for large polygon
;; vf13: fog
;; vf14: hmge
;; vf23: 0?
;; vf24: texture offset (stored in xy, zw are 0),
;; vf25: hvdf-offset
;; vf26: inv-hmge
;; vf27: giftag
;; vf28: cam 3 (premultiplied by hmge)
;; vf29: cam 2 (premultiplied by hmge)
;; vf30: cam 1 (premultiplied by hmge)
;; vf31: cam 0 (premultiplied by hmge)
VF registers for large polygon
vf13: fog
vf14: hmge
vf23: 0?
vf24: texture offset (stored in xy, zw are 0),
vf25: hvdf-offset
vf26: inv-hmge
vf27: giftag
vf28: cam 3 (premultiplied by hmge)
vf29: cam 2 (premultiplied by hmge)
vf30: cam 1 (premultiplied by hmge)
vf31: cam 0 (premultiplied by hmge)
|#
;; DECOMP BEGINS
;; set the xy component of vf24 (texture offset for large poly renderer) to values / 65,536
(def-mips2c set-tex-offset (function int int none))
@ -1257,4 +1259,4 @@
)
0
(none)
)
)

22
goal_src/jak2/engine/gfx/sprite/sprite-distort.gc
View File

@ -5,17 +5,19 @@
;; name in dgo: sprite-distort
;; dgos: ENGINE, GAME
;; Works just like Jak 1 with some exceptions:
;; - Sprite texture source doesn't seem to be the current framebuffer, instead tbp0 is hardcoded to #x3300.
;; - The sprite-aux-list contains more than just distort sprites. Instead of containing sprite-vec-data-2d's
;; directly, it's now a list of sprite-aux-elem. If the aux-type is 0, then that element is a distort sprite.
;; - No longer takes *video-params* screen-sy into account.
#|@file
Works just like Jak 1 with some exceptions:
- Sprite texture source doesn't seem to be the current framebuffer, instead tbp0 is hardcoded to #x3300.
- The sprite-aux-list contains more than just distort sprites. Instead of containing sprite-vec-data-2d's
directly, it's now a list of sprite-aux-elem. If the aux-type is 0, then that element is a distort sprite.
- No longer takes *video-params* screen-sy into account.
;; Sprite distort works by drawing a circle for each sprite whose texture is the framebuffer contents of what's
;; been drawn so far. The texture coordinates are off slightly to give a "distortion" effect as the sprite moves
;; across the screen. The resolution of the circle is defined by the number of "turns", which can range between
;; 3 and 11. Turns basically define the number of edges that make up the circle, so 3 turns will create a triangle,
;; 5 will create a pentagon, etc. The sprite-vec-data-2d 'warp-turns'/'flag' field contains the number of turns.
Sprite distort works by drawing a circle for each sprite whose texture is the framebuffer contents of what's
been drawn so far. The texture coordinates are off slightly to give a "distortion" effect as the sprite moves
across the screen. The resolution of the circle is defined by the number of "turns", which can range between
3 and 11. Turns basically define the number of edges that make up the circle, so 3 turns will create a triangle,
5 will create a pentagon, etc. The sprite-vec-data-2d 'warp-turns'/'flag' field contains the number of turns.
|#
;; DECOMP BEGINS

5
goal_src/jak2/engine/gfx/sprite/sprite.gc
View File

@ -5,7 +5,10 @@
;; name in dgo: sprite
;; dgos: ENGINE, GAME
;; the sprite renderer draw 2D or 3D sprites
#|@file
the sprite renderer draw 2D or 3D sprites
|#
;; TODO: glow is commented out.
;; TODO: distort is commented out.

4
goal_src/jak2/engine/gfx/texture/texture-upload.gc
View File

@ -5,7 +5,9 @@
;; name in dgo: texture-upload
;; dgos: ART, GAME
;; this file is loaded immediately before boot textures are loaded.
#|@file
this file is loaded immediately before boot textures are loaded.
|#
;; DECOMP BEGINS

83
goal_src/jak2/engine/gfx/texture/texture.gc
View File

@ -5,56 +5,59 @@
;; name in dgo: texture
;; dgos: ENGINE, GAME
;; Jak 2 texture system:
;; At a high level, the responsibility of the texture system is to make sure that each renderer
;; can use the textures it needs: the texture should be in VRAM at the right point in time, and
;; the renderer must know where the texture is in VRAM.
#|@file
Jak 2 texture system:
At a high level, the responsibility of the texture system is to make sure that each renderer
can use the textures it needs: the texture should be in VRAM at the right point in time, and
the renderer must know where the texture is in VRAM.
;; An oversimplified explanation is that each "bucket" in the rendering system needs a single
;; "texture page" (tpage) loaded into VRAM. Each level has a tpage for each category, where the
;; categories are:
An oversimplified explanation is that each "bucket" in the rendering system needs a single
"texture page" (tpage) loaded into VRAM. Each level has a tpage for each category, where the
categories are:
;; tfrag (background tie/tfrag)
;; pris (foreground)
;; shrub (background shrub)
;; alpha
;; water
;; warp
;; pris2
;; sprite
;; map
;; sky
tfrag (background tie/tfrag)
pris (foreground)
shrub (background shrub)
alpha
water
warp
pris2
sprite
map
sky
;; From the point of view of the rendering code, this oversimplification is basically true.
;; Renderers use textures by sending "adgif shaders" to the GS. These tell the GS how to use
;; the texture (mipmapping, size, format) and the location of the texture in VRAM (tbp).
;; When levels load, they must "log in" their adgif shaders with the texture system, and the texture
;; system will modify these in place so that things work.
From the point of view of the rendering code, this oversimplification is basically true.
Renderers use textures by sending "adgif shaders" to the GS. These tell the GS how to use
the texture (mipmapping, size, format) and the location of the texture in VRAM (tbp).
When levels load, they must "log in" their adgif shaders with the texture system, and the texture
system will modify these in place so that things work.
;; However, behind the scenes, there are many tricks.
However, behind the scenes, there are many tricks.
;; Texture data falls into two categories:
;; - boot
;; - common
Texture data falls into two categories:
- boot
- common
;; "boot" textures are ones that are loaded on boot, transferred to VRAM, and live there forever.
;; "common" textures are ones that are loaded as they are needed. There's an area in VRAM
;; called the "common segment" that holds these.
"boot" textures are ones that are loaded on boot, transferred to VRAM, and live there forever.
"common" textures are ones that are loaded as they are needed. There's an area in VRAM
called the "common segment" that holds these.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; basic texture page methods
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
basic texture page methods
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; each "texture page" is a group of textures that are (from the point of view of renderers)
;; loaded all at once to vram, and contain all the textures needed for one category in one level.
each "texture page" is a group of textures that are (from the point of view of renderers)
loaded all at once to vram, and contain all the textures needed for one category in one level.
;; however, the texture system does some tricks:
;; texture pages are divided into three "segments". The smaller number segments contain high
;; resolution mipmaps of textures (needed for close up), and the high number segments contain lower ones.
;; by looking at the distance to the closest object, we can figure out if the near textures
;; are needed or not, and skip segments if needed.
however, the texture system does some tricks:
texture pages are divided into three "segments". The smaller number segments contain high
resolution mipmaps of textures (needed for close up), and the high number segments contain lower ones.
by looking at the distance to the closest object, we can figure out if the near textures
are needed or not, and skip segments if needed.
additionally, some texture pages have a chunk system that allows more specific control.
|#
;; additionally, some texture pages have a chunk system that allows more specific control.
(defmethod print texture-page ((obj texture-page))
"Print a texture page with name and size."

24
goal_src/jak2/engine/gfx/vu1-user-h.gc
View File

@ -5,20 +5,22 @@
;; name in dgo: vu1-user-h
;; dgos: ENGINE, GAME
;; this file contains shared enums for the various renderers.
#|@file
this file contains shared enums for the various renderers.
;; Renderers will output data to "buckets", which are later spliced together into a single
;; very large dma chain.
Renderers will output data to "buckets", which are later spliced together into a single
very large dma chain.
;; With the exception of a few special case buckets, there's a bucket for
;; <renderer>-<special_modes>-<draw-level>-<tpage>
;; unlike jak 1, the "draw level index" is separate from the normal level index.
With the exception of a few special case buckets, there's a bucket for
<renderer>-<special_modes>-<draw-level>-<tpage>
unlike jak 1, the "draw level index" is separate from the normal level index.
;; for example: tie-s-l1-tfrag
;; - will be filled by the TIE renderer
;; - special "s" (scissor) variant of TIE
;; - using geometry of level 1
;; - while the tfrag tpage is in VRAM
for example: tie-s-l1-tfrag
- will be filled by the TIE renderer
- special "s" (scissor) variant of TIE
- using geometry of level 1
- while the tfrag tpage is in VRAM
|#
;; <what renderer>-<what level>-<what tpage>
(defenum bucket-id

4
goal_src/jak2/engine/level/bsp-h.gc
View File

@ -5,7 +5,9 @@
;; name in dgo: bsp-h
;; dgos: ENGINE, GAME
;; the bsp-node class seems broken - it has int16's that get used a pointers.
#|@file
the bsp-node class seems broken - it has int16's that get used a pointers.
|#
(declare-type entity-camera entity)
(declare-type entity-race-mesh entity)

8
goal_src/jak2/engine/level/bsp.gc
View File

@ -5,10 +5,12 @@
;; name in dgo: bsp
;; dgos: ENGINE, GAME
;; DECOMP BEGINS
#|@file
The "bsp" is the main level data structure: the bsp-header contains references to all static level data.
The "bsp-tree" is a bsp used to associate camera positions with lists of visibible objects.
|#
;; The "bsp" is the main level data structure: the bsp-header contains references to all static level data.
;; The "bsp-tree" is a bsp used to associate camera positions with lists of visibible objects.
;; DECOMP BEGINS
(defun-recursive mem-usage-bsp-tree none ((arg0 bsp-header) (arg1 bsp-node) (arg2 memory-usage-block) (arg3 int))
"Compute the memory usage of the bsp-tree part of a bsp-header"

22
goal_src/jak2/engine/level/level.gc
View File

@ -5,19 +5,25 @@
;; name in dgo: level
;; dgos: ENGINE, GAME
#|@file
the level heap is a giant block of memory which is seperated into "pages" so that it can easily
be split into different sizes for the different kinds of level sizes.
it is split into 6 sections, 24-24-25-25-24-24 pages large.
this means the "center" portion of the main level heap is actually "larger"
which is why there is a special small-center level memory mode for two-section
levels that want to be placed in the middle of the heap for that slight size boost.
some code checks for 7 bits in the memory mask, indicating the heap was originally split
into 7 sections, which might explain the weird sizes in the center.
|#
;; DECOMP BEGINS
(define-extern level-update-after-load (function level login-state level))
(define-extern *level-type-list* type)
;; the level heap is a giant block of memory which is seperated into "pages" so that it can easily
;; be split into different sizes for the different kinds of level sizes.
;; it is split into 6 sections, 24-24-25-25-24-24 pages large.
;; this means the "center" portion of the main level heap is actually "larger"
;; which is why there is a special small-center level memory mode for two-section
;; levels that want to be placed in the middle of the heap for that slight size boost.
;; some code checks for 7 bits in the memory mask, indicating the heap was originally split
;; into 7 sections, which might explain the weird sizes in the center.
(defglobalconstant NUM_LEVEL_PAGES 146)
(defglobalconstant LEVEL_PAGE_SIZE_KB 126) ;; original value
(defglobalconstant LEVEL_PAGE_SIZE (* LEVEL_PAGE_SIZE_KB 1024)) ;; original value

14
goal_src/jak2/engine/load/decomp.gc
View File

@ -5,11 +5,15 @@
;; name in dgo: decomp
;; dgos: ENGINE, GAME
;; This file has compression/decompression functions used for compressed visibility data, bigmap data, and
;; joint animations (not the joint-anim-compressed stuff, an outer layer of lzo compression of those)
;; It also has the update-vis! method of level, which handles the details of decompression.
;; Luckily for us, the IOP ramdisk vis stuff from Jak 1 is gone!
;; It's not super clear to me why they ditched this system. Maybe the visibility data is a lot smaller in jak 2.
#|@file
This file has compression/decompression functions used for compressed visibility data, bigmap data, and
joint animations (not the joint-anim-compressed stuff, an outer layer of lzo compression of those)
It also has the update-vis! method of level, which handles the details of decompression.
Luckily for us, the IOP ramdisk vis stuff from Jak 1 is gone!
It's not super clear to me why they ditched this system. Maybe the visibility data is a lot smaller in jak 2.
|#
;; DECOMP BEGINS

27
goal_src/jak2/engine/load/file-io.gc
View File

@ -5,20 +5,21 @@
;; name in dgo: file-io
;; dgos: ENGINE, GAME
;; GOAL File I/O
;; This is mostly not used in the retail game and was more for loading stuff during development.
;; The file-stream is an inefficient way to load data, but is flexible and can load
;; from the CD, or over the network in development.
;; The file-info type is used in actual game data for checking versions.
;; represents a file that can be read/written, similar to FILE* in C.
;; NOTE: this is a special type in three ways:
;; 1). It is used in the C runtime. This must be kept in sync with kmachine.h's FileStream
;; 2). This type is built-in to the compiler (see TypeSystem.cpp, add_builtin_types)
;; It must be kept up to date with that definition as well.
;; 3). The C runtime constructs this type before anything is loaded. The sizes
;; must be kept up to date there as well.
#|@file
GOAL File I/O
This is mostly not used in the retail game and was more for loading stuff during development.
The file-stream is an inefficient way to load data, but is flexible and can load
from the CD, or over the network in development.
The file-info type is used in actual game data for checking versions.
represents a file that can be read/written, similar to FILE* in C.
NOTE: this is a special type in three ways:
1). It is used in the C runtime. This must be kept in sync with kmachine.h's FileStream
2). This type is built-in to the compiler (see TypeSystem.cpp, add_builtin_types)
It must be kept up to date with that definition as well.
3). The C runtime constructs this type before anything is loaded. The sizes
must be kept up to date there as well.
|#
;; DECOMP BEGINS

44
goal_src/jak2/engine/math/matrix.gc
View File

@ -5,32 +5,34 @@
;; name in dgo: matrix
;; dgos: ENGINE, GAME
;; This file implements the GOAL matrix library.
#|@file
This file implements the GOAL matrix library.
;; In general, a vector is always treated as a row vector.
;; Chaining transformation is done like v_row * T1_goal * T2_goal, which means do T1 before T2.
;; This is the opposite of the usual convention:
;; T2_normal * T1_normal * v_col
;; However, there is good news:
;; T1_normal = T1_goal ^ T
;; T2_normal = T2_goal ^ T
;; This is due to the property
;; (A * B)^T = B^T * A^T
In general, a vector is always treated as a row vector.
Chaining transformation is done like v_row * T1_goal * T2_goal, which means do T1 before T2.
This is the opposite of the usual convention:
T2_normal * T1_normal * v_col
However, there is good news:
T1_normal = T1_goal ^ T
T2_normal = T2_goal ^ T
This is due to the property
(A * B)^T = B^T * A^T
;; So a homogeneous transformation is:
;; R_xx R_xy R_xz 0
;; R_yx R_yy R_yz 0
;; R_zx R_zy R_zz 0
;; T_x T_y T_z 1
So a homogeneous transformation is:
R_xx R_xy R_xz 0
R_yx R_yy R_yz 0
R_zx R_zy R_zz 0
T_x T_y T_z 1
;; which is probably the transpose of what you're used to.
which is probably the transpose of what you're used to.
;; note that they also used row-major storage, so the 3rd qword of a matrix is the translation
;; part of the affine transform.
note that they also used row-major storage, so the 3rd qword of a matrix is the translation
part of the affine transform.
;; In general, be careful with using these functions as they often have strange
;; requirements for the form of the input matrix or if the input/output matrix are
;; allowed to be the same memory.
In general, be careful with using these functions as they often have strange
requirements for the form of the input matrix or if the input/output matrix are
allowed to be the same memory.
|#
;; DECOMP BEGINS

25
goal_src/jak2/engine/math/trigonometry.gc
View File

@ -5,20 +5,21 @@
;; name in dgo: trigonometry
;; dgos: ENGINE, GAME
;; The "rotation" unit stores an angle in a float, where 1.0 = 1/65,536 (1/2^16) of a rotation.
;; Use the ~r format specifier to print rotations as degrees.
;; In general, functions which use these units will only be accurate to within 1/65,536th of a rotation,
;; as they often internally convert the float to an integer. These function also handle wrapping
;; correctly, and will output angles in the range -32768 to 32768 (+/- one half of a rotation)
;; Functions with these units have deg or nothing special in the name.
#|@file
The "rotation" unit stores an angle in a float, where 1.0 = 1/65,536 (1/2^16) of a rotation.
Use the ~r format specifier to print rotations as degrees.
In general, functions which use these units will only be accurate to within 1/65,536th of a rotation,
as they often internally convert the float to an integer. These function also handle wrapping
correctly, and will output angles in the range -32768 to 32768 (+/- one half of a rotation)
Functions with these units have deg or nothing special in the name.
;; Some functions use radians. These typically have rad in the name, and they don't handle wrapping.
;; The input must be in the range -pi to pi
;; General note on floating point constants: to avoid ambiguity/rounding issues related to printing/parsing, weird
;; constants are stored as hex. Commonly used constants that are exactly represented (1, 0.5, etc) will appear
;; normally.
Some functions use radians. These typically have rad in the name, and they don't handle wrapping.
The input must be in the range -pi to pi
General note on floating point constants: to avoid ambiguity/rounding issues related to printing/parsing, weird
constants are stored as hex. Commonly used constants that are exactly represented (1, 0.5, etc) will appear
normally.
|#
;; There is a bug in some of the cosine functions that can be fixed by toggling this flag.
(defglobalconstant FIX_COSINE_BUG #f)

8
goal_src/jak2/engine/math/vector-h.gc
View File

@ -5,8 +5,10 @@
;; name in dgo: vector-h
;; dgos: ENGINE, GAME
;; Changes:
;; - vector+!, vector-!, vector-dot, vector4-dot replaced with actual implementations.
#|@file
Changes:
- vector+!, vector-!, vector-dot, vector4-dot replaced with actual implementations.
|#
;; DECOMP BEGINS
@ -756,4 +758,4 @@
(set! (-> vec quad) (the-as uint128 0))
vec
)
)
)

10
goal_src/jak2/engine/ps2/pad.gc
View File

@ -5,10 +5,12 @@
;; name in dgo: pad
;; dgos: ENGINE, GAME
;; Interface for game controllers.
;; the *cpad-list* contains both game controllers.
;; Use the service-cpads functions once per frame to update the data and vibration control
;; The cpad-set-buzz! function can be used for vibration.
#|@file
Interface for game controllers.
the *cpad-list* contains both game controllers.
Use the service-cpads functions once per frame to update the data and vibration control
The cpad-set-buzz! function can be used for vibration.
|#
(define-extern get-current-time (function time-frame))
(define-extern get-integral-current-time (function uint))

10
goal_src/jak2/engine/ps2/timer-h.gc
View File

@ -5,11 +5,13 @@
;; name in dgo: timer-h
;; dgos: ENGINE, GAME
;; DECOMP BEGINS
#|@file
There are two sources for timing:
- EE TIMER1, used for the frame profiler. There are 9765 counts of this per frame. It gets reset in drawable.
- The "stopwatch" system, used for reading the CPU clock cycle counter, at 300 MHz (32-bit)
|#
;; There are two sources for timing:
;; - EE TIMER1, used for the frame profiler. There are 9765 counts of this per frame. It gets reset in drawable.
;; - The "stopwatch" system, used for reading the CPU clock cycle counter, at 300 MHz (32-bit)
;; DECOMP BEGINS
;; The Emotion Engine has 4 hardware timers, timer1 is used as the
(defconstant TIMER0_BANK (the timer-bank #x10000000)) ;; has HOLD register!

16
goal_src/jak2/engine/ps2/vif-h.gc
View File

@ -5,14 +5,16 @@
;; name in dgo: vif-h
;; dgos: ENGINE, GAME
;; DECOMP BEGINS
#|@file
Types related to VIF: the PS2's Vector Interface.
Each of VU0 and VU1 has a VIF which is used to sent/receive data.
The VIFs are controller by registers and fed data using DMA
the vif registers defined here are used extremely rarely, usually they are sent DMA
(during gameplay, everything is synchronized by DMA, so code generally does not know when
it is safe to mess with VIF registers.)
|#
;; Types related to VIF: the PS2's Vector Interface.
;; Each of VU0 and VU1 has a VIF which is used to sent/receive data.
;; The VIFs are controller by registers and fed data using DMA
;; the vif registers defined here are used extremely rarely, usually they are sent DMA
;; (during gameplay, everything is synchronized by DMA, so code generally does not know when
;; it is safe to mess with VIF registers.)
;; DECOMP BEGINS
;;VIF0_STAT or VIF1_STAT bitfields
(deftype vif-stat (uint32)

13
goal_src/jak2/engine/ps2/vu1-macros.gc
View File

@ -5,14 +5,15 @@
;; name in dgo: vu1-macros
;; dgos: ENGINE, GAME
#|@file
this file has no code, just macros for vector-unit stuff.
in OpenGOAL we're also using this for VU0 macros to help with VU0 operations that are not
directly implemented by the OpenGOAL compiler
|#
;; DECOMP BEGINS
;; this file has no code, just macros for vector-unit stuff.
;; in OpenGOAL we're also using this for VU0 macros to help with VU0 operations that are not
;; directly implemented by the OpenGOAL compiler
(defmacro vu-clip (vfr cf)
"Returns the result of VCLIP.
NOTE: this implementation is pretty inefficient.

30
goal_src/jak2/engine/spatial-hash/collide-hash.gc
View File

@ -5,22 +5,24 @@
;; name in dgo: collide-hash
;; dgos: ENGINE, GAME
#|@file
collide-hash is the broad phase collision detector for background collisions.
It esssentially answers the question "what collide fragments are near X"?
and this answer is passed down to lower level collision checks.
unlike jak 1, this uses a "spatial hash". The idea is to divide space into a grid, then map
cells in this grid to a smaller number of buckets using a hash function.
hash collisions are probably not too common, as most space is empty, and can be reject relatively quickly
by doing a bounding sphere check with the collision fragments.
in this file, boxes are commonly represented as a vector, with xyz being the origin, and w being half
the side length.
|#
;; DECOMP BEGINS
;; collide-hash is the broad phase collision detector for background collisions.
;; It esssentially answers the question "what collide fragments are near X"?
;; and this answer is passed down to lower level collision checks.
;; unlike jak 1, this uses a "spatial hash". The idea is to divide space into a grid, then map
;; cells in this grid to a smaller number of buckets using a hash function.
;; hash collisions are probably not too common, as most space is empty, and can be reject relatively quickly
;; by doing a bounding sphere check with the collision fragments.
;; in this file, boxes are commonly represented as a vector, with xyz being the origin, and w being half
;; the side length.
(defun add-collide-debug-box ((arg0 vector) (arg1 rgba))
"Debug draw a box represented as (origin, half-side-length)."
(rlet ((vf1 :class vf)

16
goal_src/jak2/engine/util/profile-h.gc
View File

@ -5,14 +5,16 @@
;; name in dgo: profile-h
;; dgos: ENGINE, GAME
;; The Jak 2 profiler is a significant improvement over Jak 1's.
;; VU segments are categorized by renderer, and the EE profiler allows nesting of events.
;; The EE profiler also allows events with the same name to be "collapsed" into a single
;; category.
;; The profiler can display results as bars, or as a text display by category.
#|@file
The Jak 2 profiler is a significant improvement over Jak 1's.
VU segments are categorized by renderer, and the EE profiler allows nesting of events.
The EE profiler also allows events with the same name to be "collapsed" into a single
category.
The profiler can display results as bars, or as a text display by category.
;; Each "event" is called a "segment". It stores a time and also a "count".
;; The "count" can be used for whatever you want (ex: fragments, VU calls, etc)
Each "event" is called a "segment". It stores a time and also a "count".
The "count" can be used for whatever you want (ex: fragments, VU calls, etc)
|#
;; DECOMP BEGINS

5
goal_src/jak2/examples/collide-hash-debug.gc
View File

@ -1,4 +1,5 @@
;;-*-Lisp-*-
(in-package goal)
(define *collide-hash-test-origin* (new 'global 'vector))
(define *collide-hash-test-size* (new 'global 'vector))
@ -84,4 +85,4 @@
)
)
proc)
)
)

3
goal_src/jak2/examples/debug-jak2.gc
View File

@ -1,3 +1,6 @@
;;-*-Lisp-*-
(in-package goal)
(defun hack-update-camera ((location vector) (inv-rot matrix))
"Debugging function to set the camera's position and orientation"
;; update to compute the perspective matrix.

10
goal_src/jak2/kernel/dgo-h.gc
View File

@ -5,11 +5,13 @@
;; name in dgo: dgo-h
;; dgos: KERNEL
;; DECOMP BEGINS
#|@file
I suspect that these are unused, and were for an older version of DGO.
All DGO stuff is handled on the IOP.
see also load-dgo.gc's dgo-header.
|#
;; I suspect that these are unused, and were for an older version of DGO.
;; All DGO stuff is handled on the IOP.
;; see also load-dgo.gc's dgo-header.
;; DECOMP BEGINS
(deftype dgo-entry (structure)
((offset uint32 :offset-assert 0)

7
goal_src/jak2/kernel/gstate.gc
View File

@ -5,9 +5,7 @@
;; name in dgo: gstate
;; dgos: KERNEL
;; DECOMP BEGINS
#|
#|@file
Summary of state system:
A process can be put into a state, using enter-state, or the go macro.
@ -49,9 +47,10 @@ with the appropriate state type.
The go-hook calls enter state and sets (-> proc next-state) for the given process.
It type checks the arguments for the entry function.
|#
;; DECOMP BEGINS
(defmacro go (next-state &rest args)
"Change the state of the current process.
This will only return if this is called within the post thread.

15
goal_src/jak2/kernel/pskernel.gc
View File

@ -5,8 +5,13 @@
;; name in dgo: pskernel
;; dgos: KERNEL
;; in the original game, they had ways to hook into the PS2's kernel and install
;; debug handlers. This file had utilities to read/write kernel memory deal with
;; R5900 exceptions.
;; This file contained an error string referencing an additional
;; debug-handlers.gc, which probably contained the actual interesting handlers.
#|@file
in the original game, they had ways to hook into the PS2's kernel and install
debug handlers. This file had utilities to read/write kernel memory deal with
R5900 exceptions.
This file contained an error string referencing an additional
debug-handlers.gc, which probably contained the actual interesting handlers.
|#
;; DECOMP BEGINS

2
goalc/compiler/compilation/CompilerControl.cpp
View File

@ -820,4 +820,4 @@ Val* Compiler::compile_gen_docs(const goos::Object& form, const goos::Object& re
Val* Compiler::compile_gc_text(const goos::Object&, const goos::Object&, Env*) {
m_goos.reader.db.clear_info();
return get_none();
}
}

5
goalc/compiler/compilation/Define.cpp
View File

@ -77,7 +77,10 @@ Val* Compiler::compile_define(const goos::Object& form, const goos::Object& rest
}
}
m_symbol_info.add_global(symbol_string(sym), form, sym_meta);
if (!as_lambda) {
// Don't double-add functions as globals
m_symbol_info.add_global(symbol_string(sym), form, sym_meta);
}
env->emit(form, std::make_unique<IR_SetSymbolValue>(sym_val, in_gpr));
return in_gpr;

8
goalc/compiler/compilation/Type.cpp
View File

@ -480,8 +480,9 @@ Val* Compiler::compile_defmethod(const goos::Object& form, const goos::Object& _
// todo, verify argument list types (check that first arg is _type_ for methods that aren't "new")
lambda.debug_name = fmt::format("(method {} {})", method_name.print(), type_name.print());
// TODO - docstring - do something with the docstring!
std::optional<std::string> docstring;
if (body->as_pair()->car.is_string() && !body->as_pair()->cdr.is_empty_list()) {
docstring = pair_car(*body).as_string()->data;
body = &pair_cdr(*body);
}
@ -612,12 +613,13 @@ Val* Compiler::compile_defmethod(const goos::Object& form, const goos::Object& _
}
place->set_type(lambda_ts);
auto info =
m_ts.define_method(symbol_string(type_name), symbol_string(method_name), lambda_ts, {});
auto info = m_ts.define_method(symbol_string(type_name), symbol_string(method_name), lambda_ts,
docstring);
auto type_obj = compile_get_symbol_value(form, symbol_string(type_name), env)->to_gpr(form, env);
auto id_val = compile_integer(info.id, env)->to_gpr(form, env);
auto method_val = place->to_gpr(form, env);
auto method_set_val = compile_get_symbol_value(form, "method-set!", env)->to_gpr(form, env);
m_symbol_info.add_method(symbol_string(method_name), lambda.params, info, form);
return compile_real_function_call(form, method_set_val, {type_obj, id_val, method_val}, env);
}

44
scripts/docs/append-file-docs.py Normal file
View File

@ -0,0 +1,44 @@
import os
import json
def get_file_comment(path):
full_path = "./goal_src/{}".format(path)
if os.path.exists(full_path):
with open(full_path, 'r') as f:
lines = f.readlines()
parsing_comment = False
comment = []
for idx, line in enumerate(lines):
if parsing_comment is False and idx >= 100:
return None
if "#|@file" in line.lower():
# We found it, parse the lines
parsing_comment = True
continue
if parsing_comment and "|#" in line:
parsing_comment = False
break
if parsing_comment:
comment.append(line)
if len(comment) > 0:
return "\n".join(comment)
return None
def append_file_docs(game_name):
with open('./{}-file-docs.json'.format(game_name), 'r') as f:
file_docs = json.load(f)
for file_path, file_info in file_docs.items():
# Go and find the file in goal_src
# Check to see if it has a #|@file line (within the first 100 lines)
# If it does, parse out the description from that block comment and update the json
comment = get_file_comment(file_path)
if comment is not None:
file_info["description"] = comment
with open('./{}-file-docs.json'.format(game_name), 'w') as f:
json.dump(file_docs, f)
append_file_docs("jak1")
append_file_docs("jak2")