-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
custom levels: add initial support for ambients #2173
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
xTVaser
approved these changes
Jan 30, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only touches custom level building code
LuminarLight
added a commit
to LuminarLight/jak-project
that referenced
this pull request
Feb 4, 2023
* decomp: `kor-*|kid-*|widow-*|hal-*|atoll-*` files, `spyder`, `sniper`, `juicer` and more (open-goal#2134) Full list: - `atoll-obs` - `atoll-tank` - `juicer` - `sniper` - `transport` - `yakow` - `kid-h` - `kid-states` - `kid-task` - `kid3-course` - `kid` - `kor-h` - `kor-states` - `kor-task` - `kor3-course` - `kor` - `spyder` - `spydroid` - `widow-baron` - `widow-extras` - `widow-more-extras` - `widow2` - `widow` - `flying-spider` - `mammoth` - `mantis` - `nest-obs` - `hal-task` - `hal` - `hal3-course` Manual patches: - `widow`: `handle->process` stack var - `nestb-scenes`: Commented out `nav-network` stuff, was causing crashes in `nest` Also fixes `ginsu` crash (`blade-part` had the wrong type) * Fix test crash on space in filepath (open-goal#2138) Should be only one commit. I broke git if it shows more, whoops * d/jak2: second documentation PR and finish `forest-scenes` and `palace-scenes` (open-goal#2136) Also fixes open-goal#2135 Co-authored-by: water <awaterford111445@gmail.com> * docs: add support for `:override-doc` in method declarations as well as documenting state handlers (open-goal#2139) Adding support for better child-type method docstrings. This is a problem unique to methods. Usually, a child-type will have the same signature and a common name will apply, but the implementation is different. This means, you probably want a different docstring to describe what is happening. Currently this is possible to do via `:replace`. The problem with replace is two fold: - a replaced method ends up in the generated `deftype`...because you usually change the signature! - we don't put docstrings in the `deftype` in normal GOAL, this is just something we do for the `all-types` file (they go in the `defmethod` instead) - more importantly, this means anytime you now want to change the parent's name/args/return type -- you have to apply that change everywhere. So this is a better design you can now just declare the method like so: ```clj (:override-doc "my new docstring" <method_id>) ``` And internally a pseudo-replaced method will be added, but it will inherit everything from the parent (except the docstring of course) Unrelated - I also made all the keyword args for declaring methods not depend on ordering This also adds support for documenting virtual and non-virtual state handlers. For example: ```clj (:states (part-tester-idle (:event "test") symbol)) ``` or ```clj (idle () _type_ :state (:event "test") 20) ``` I will probably add the ability to give some sort of over-view docstring at a later date. Co-authored-by: water <awaterford111445@gmail.com> * goalc: support static arrays of `type`s (open-goal#2140) draft because using the array is a little weird still, don't feel like dealing with window's slow debugging builds today. I get the following weird error: ```clj (define test-array (new 'static 'boxed-array :type type vector)) gr> (-> test-array 0) 1538004 #x1777d4 0.0000 vector gr> (type? (-> test-array 0) type) 1342757 #x147d25 0.0000 #t gr> (new 'static (-> test-array 0)) -- Compilation Error! -- Got 3 arguments, but expected 2 Form: (-> test-array 0) Location: Program string:1 (new 'static (-> test-array 0)) ^ Code: (new 'static (-> test-array 0)) ``` Maybe this is expected though and the `new` method wants a symbol, not a type? Fixes open-goal#2060 Co-authored-by: water <awaterford111445@gmail.com> * d/jak2: finish `consite-obs` and get almost all side-missions working (open-goal#2143) Some side missions require cars, they don't work yet. Also the ring-races and collection ones do not grant orbs. The hoaming beacon collection one causes a `hud` crash * Update target-h ref (open-goal#2153) * jak2: `ocean` renderer (open-goal#2142) Initial implementation of the `ocean-mid`, `ocean-far` and `ocean-near` renderers for Jak 2. There's still a few things to sort out, mainly: - [x] ~Backwards compatibility with Jak 1. The only thing that currently stands in the way of that is figuring out a clean way to "un-hardcode" the texture base pointer in C++ without creating a completely separate `OceanTexture` class for Jak 2. One thing I thought of would be modifying `BucketRenderer`'s virtual `init_textures` method to also pass the `GameVersion`, but I'm not sure if there's a better way.~ - [x] ~The sudden transition from `ocean-near` to `ocean-mid`. Not sure why it's happening or how to fix it.~ - [x] The ocean has two new methods in Jak 2, `ocean::89` and `ocean::79`, one of which seems to be related to time of day sky colors. ~Even without them implemented, the end result looks quite close, so we may be able to skip them?~ `ocean::89` generates `ocean-mid` envmap textures, so it will likely be required, but will not be handled right now. Reverted the VU prologue removals because it made the tests fail. * d/jak2: "finish" `traffic-manager`, `vehicle-util` and `citizen-h` (open-goal#2144) Some more progress on vehicle code, the following files still remain: - vehicle-guard (annoying stack types) - traffic-engine (many issues, some which already have issues made for them, other entirely new confusing things!) * [merc2] Support emerc (open-goal#2147) This adds environment mapping support to `Merc2`, and turns it on for Jak 1 and Jak 2. - The performance is much better - Jak 1 can be toggled back to the old behavior with `(set! *emerc-hack* #f)`. The new environment mapping is identical to the old one everywhere I checked. - Jak 1 still falls back to generic for ripple/texscroll/blerc/eyes - there's still no dynamic texture or vertex updating support. The eye detection stuff will sometimes flag stuff as eyes which is not eyes, which is fine, but means that generic will be used in some places where emerc could be used. For example, the shiny plates on jak's arm will be drawn with generic because jak has eyes. - Jak 2 hasn't been checked super carefully against PCSX2 yet. - Jak 2 still isn't technically using emerc, but instead putting emerc models in the merc bucket. - The interface to merc is a lot different now and totally custom OpenGOAL DMA code. The original merc drawing asm doesn't run anymore. - The FR3 format changed - Something funky going on with foreground lighting in escape, but doesn't seem to be related to this change? Performance comparison, jak 1, in likely the most generic-merc heavy spot: ![image](https://user-images.githubusercontent.com/48171810/213882718-feb2ab59-95a9-44a2-b0e5-95fba860c7b0.png) ![image](https://user-images.githubusercontent.com/48171810/213882736-8dbbf4c9-6bbf-4d0b-96ce-78d63274660c.png) * disable emerc for title effect (open-goal#2156) * Fix F2 screenshots (open-goal#2160) Fixes open-goal#2155 * Add extended environment mapping option to progress and enable it by default + other bug fixes (open-goal#2161) ![image](https://user-images.githubusercontent.com/7569514/214192592-d584e955-9d54-4092-94ee-1cbe12b071e8.png) Note: if you had the option disabled, it will be enabled when you first start the game again. You will have to turn it off again if you want it disabled. Also fixes open-goal#2150 and fixes open-goal#1738 and fixes open-goal#2145 * Fix a few errors in the entity debugger (open-goal#2166) * Hook Jak 1 into ImGUI actor filter (open-goal#2157) * scripts: update gsrc files with modifications using git merge (open-goal#2164) * decomp: `eye` (open-goal#2148) * decomp: `drill-obs`, `drill-obs2`, `drillmid-obs`, `drill-panel`, `drill-spool` (open-goal#2152) Co-authored-by: Tyler Wilding <xtvaser@gmail.com> * decomp: `blerc`, `ripple`, `under-*` files (open-goal#2163) Co-authored-by: Tyler Wilding <xtvaser@gmail.com> * d/jak2: decompile all `*-texture` files except `castle-texture` (open-goal#2149) Fixes open-goal#2051 * decomp: `squid-*` files (open-goal#2170) Co-authored-by: Tyler Wilding <xtvaser@gmail.com> * g/jak2: cleanup `target-board` a bit, add a new feature (open-goal#2154) * d/jak2: get `portrun` working and decompile a bunch of miscellaneous files (open-goal#2169) * jak2: significantly reduce the verbosity of the `game.gp` file (open-goal#2103) * Update Jak2 inputs.jsonc for first time compiles (open-goal#2172) * Jak 1 Checkpoint Select / IL Speedrun support (open-goal#2162) * [extractor] create debug_out (open-goal#2159) Co-authored-by: Tyler Wilding <xtvaser@gmail.com> * custom levels: add initial support for ambients (open-goal#2173) * repl: support game-specific `startup.gc` files (open-goal#2176) * g/jak2: Add missing DGO files to `game.gp` lost in the shuffle (open-goal#2178) When I cleaned up the `game.gp` some DGOs were no longer referenced because my first dependency script omitted them -- thinking they weren't required. From the perspective of the source files they indeed weren't required but we still have to produce the DGO file. also works around open-goal#2177 * [merc2] support vertex updates, use this for blerc in jak 1 and jak 2 (open-goal#2179) This PR adds a feature to merc2 to update vertices. This will be needed to efficient do effects like blerc/ripple/texture scroll. It's enabled for blerc in jak 1 and jak 2, but with a few disclaimers: - currently we still use the mips2c blerc implementation, which is slow and has some "jittering" because of integer precision. When porting to PC, there was an additional synchronization problem because blerc overwrites the merc data as its being read by the renderers. I _think_ this wasn't an issue on PS2 because the blerc dma is higher priority than the VIF1 DMA, but I'm not certain. Either way, I had to add a mutex for this on PC to avoid very slight flickering/gaps. This isn't ideal for performance, but still beats generic by a significant amount in every place I tested. If you see merc taking 2ms to draw, it is likely because it is stuck waiting on blerc to finish. This will go away once blerc itself is ported to C++. - in jak 1, we end up using generic in some cases where we could use merc. In particular maia in village3 hut. This will be fixed later once we can use merc in more places. I don't want to mess with the merc/generic selection logic when we're hopefully going to get rid of it soon. - There is no support for ripple or texture scroll. These use generic on jak 1, and remain broken on jak 2. - Like with `emerc`, jak 1 has a toggle to go back to the old behavior `*blerc-hack*`. - In most cases, toggling this causes no visual differences. One exception is Gol's teeth. I believe this is caused by texture coordinate rounding issues, where generic has an additional float -> int -> float compared to PC merc. It is very hard to notice so I'm not going to worry about it. * d/jak2: cleaning up the remainder of unblocked / unclaimed files (open-goal#2171) Co-authored-by: water <awaterford111445@gmail.com> * More DGOs in Jak2 inputs.jsonc (open-goal#2182) * [jak2] pc-hook for pris texture upload (open-goal#2184) Fixes a bunch of hud textures: ![image](https://user-images.githubusercontent.com/48171810/215919174-b6ff9af7-0408-4e97-b142-0fbbeafa196a.png) * Minor fix for Rock Village IL speedrun (open-goal#2187) --------- Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com> Co-authored-by: EvelynTSMG <96205195+EvelynTSMG@users.noreply.github.com> Co-authored-by: Tyler Wilding <xTVaser@users.noreply.github.com> Co-authored-by: water <awaterford111445@gmail.com> Co-authored-by: water111 <48171810+water111@users.noreply.github.com> Co-authored-by: ManDude <7569514+ManDude@users.noreply.github.com> Co-authored-by: ZedB0T <89345505+Zedb0T@users.noreply.github.com> Co-authored-by: Tyler Wilding <xtvaser@gmail.com> Co-authored-by: BreakPoints <JackHooley7@gmail.com> Co-authored-by: Matt Dallmeyer <2515356+dallmeyer@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allows mappers to place ambient hints in their custom levels.
The syntax is as follows in the custom level JSON:
This has only been tested with ambient hints so far.
One thing that could probably be improved is the way the ambients are added to the
bsp-header
'sdrawable-tree
(inLevelFile.cpp
), I haven't been able to figure out a nicer way to do that.