Commit Graph

463 Commits

Author SHA1 Message Date
Tyler Wilding
8b08d7d266
lint: linter fixes 2024-06-02 15:03:23 -04:00
Tyler Wilding
a657d6b4bf
lint: formatting 2024-06-02 12:54:17 -04:00
Tyler Wilding
690d7016bf
goalc: allow symbol re-definitions if the flag is enabled 2024-06-02 12:53:51 -04:00
Tyler Wilding
eebae4c524
nrepl: default to a single port, nothing breaks if the port is already bound to 2024-06-02 12:52:46 -04:00
Tyler Wilding
3bc7662cc1
repl: cleanup startup logs when opening the REPL 2024-06-02 12:51:14 -04:00
Tyler Wilding
2a0a7dc862
common: rename repl_wrapper files 2024-06-02 12:50:28 -04:00
Aloqas
cefb371681
[jak2] new subtitle speakers (#3536)
for specific cutscene scenarios

---------

Co-authored-by: Tyler Wilding <xtvaser@gmail.com>
2024-05-30 22:02:44 -04:00
Hat Kid
c64eea6337
[buildactor] support generating collide-meshes for custom models (#3540)
This adds support for generating collide meshes when importing custom
models. A couple of things to keep in mind:

- A single `collide-mesh` may only have up to 255 vertices.
- When exporting a GLTF file in Blender, a `collide-mesh` will be
generated for every mesh object that has collision properties applied
(ideally, you would set all visual meshes to `ignore` and your collision
meshes to `invisible` in the OpenGOAL plugin's custom properties).
- Ensure that your actor using the model properly allocates enough
`collide-shape-prim-mesh`es for each `collide-mesh` ([example from the
original game that uses multiple
meshes](f6688659f2/goal_src/jak1/levels/finalboss/robotboss.gc (L2628-L2806))).

~One annoying problem that I haven't fully figured out yet (unrelated to
the actual functionality):
`collide-mesh`es are stored in art groups as an `(array collide-mesh)`
in the `art-joint-geo`'s `extra`, so I had to add a new `Res` type to
support this. The way that `array`s are stored in `res-lump`s is a bit
of a hack right now. The lump only stores a pointer to the array, so the
size of that is 4 bytes, but because we have to generate all the actual
array data too, the current `ResLump` code in C++ doesn't handle this
case well and would assert, so I decided to omit the asserts if an
`array` tag is present and "fake" the size so the object file is
generated more closely to how the game expects it until we figure out
something better.~
This was fixed by generating the array data beforehand and creating a
`ResRef` class that takes the pointer to the array data and adds it to
the lump.
2024-05-29 06:09:20 +02:00
Hat Kid
62ef9fe49d
[wip] build actor tool (#3266)
This does a couple of things:

- The `custom_levels` folder was renamed to `custom_assets` and contains
`levels`, `models` and `texture_replacements` folders for Jak 1, 2 and 3
in order to keep everything regarding custom stuff in one place.
- With this, texture replacements now use separate folders for all games
- A build actor tool was added that generates art groups for custom
actors
- Custom levels can now specify what custom models from the `models`
folder they want to import, this will add them to the level's FR3.
- A `test-zone-obs.gc` file was added, containing a `test-actor` process
that uses a custom model as an example.

The build actor tool is still very WIP, the joints and the default
animation are hardcoded, but it allows for importing any GLB file as a
merc model.
2024-05-18 18:18:25 +02:00
Hat Kid
a61f24a168
jak3: custom level support (#3522) 2024-05-16 21:15:54 +02:00
Tyler Wilding
456d1ba536
goalc: add a performance report feature (#3519)
Adds a quick perf report feature to `goalc` that lets you compare how
much faster / slower it takes to compile the projects, with some simple
features like filtering the files, adjusting for how large of a margin
of error in the speeds you care about, and which test iteration you want
to compare against.

This is something I plan to use as I work more in `goalc` as an easy way
to track / show the results.


![image](https://github.com/open-goal/jak-project/assets/13153231/26f140c7-66d7-4162-994a-a71061e22857)
2024-05-15 22:52:16 -04:00
Tyler Wilding
d1ece445d4
Dependency graph work - Part 1 - Preliminary work (#3505)
Relates to #1353 

This adds no new functionality or overhead to the compiler, yet. This is
the preliminary work that has:
- added code to the compiler in several spots to flag when something is
used without being properly required/imported/whatever (disabled by
default)
- that was used to generate project wide file dependencies (some
circulars were manually fixed)
- then that graph underwent a transitive reduction and the result was
written to all `jak1` source files.

The next step will be making this actually produce and use a dependency
graph. Some of the reasons why I'm working on this:
- eliminates more `game.gp` boilerplate. This includes the `.gd` files
to some extent (`*-ag` files and `tpage` files will still need to be
handled) this is the point of the new `bundles` form. This should make
it even easier to add a new file into the source tree.
- a build order that is actually informed from something real and
compiler warnings that tell you when you are using something that won't
be available at build time.
- narrows the search space for doing LSP actions -- like searching for
references. Since it would be way too much work to store in the compiler
every location where every symbol/function/etc is used, I have to do
ad-hoc searches. By having a dependency graph i can significantly reduce
that search space.
- opens the doors for common shared code with a legitimate pattern.
Right now jak 2 shares code from the jak 1 folder. This is basically a
hack -- but by having an explicit require syntax, it would be possible
to reference arbitrary file paths, such as a `common` folder.

Some stats:
- Jak 1 has about 2500 edges between files, including transitives
- With transitives reduced at the source code level, each file seems to
have a modest amount of explicit requirements.

Known issues:
- Tracking the location for where `defmacro`s and virtual state
definitions were defined (and therefore the file) is still problematic.
Because those forms are in a macro environment, the reader does not
track them. I'm wondering if a workaround could be to search the
reader's text_db by not just the `goos::Object` but by the text
position. But for the purposes of finishing this work, I just statically
analyzed and searched the code with throwaway python code.
2024-05-12 12:37:59 -04:00
water111
5b04be2fa0
Add hfrag, clean up some background renderer stuff (#3509)
This adds hfrag, but with a few remaining issues:
- The textures aren't animated. Instead, it just uses one texture.
- The texture filtering isn't as good as at it could be.

I also cleaned up a few issues with the background renderers:
- Cleaned up some stuff that is common to hfrag, tie, tfrag, shrub
- Moved time-of-day color packing stuff to FR3 creation, rather than at
level load. This appears to reduce the frame time spikes when a level is
first drawn by about 5 or 6 ms in big levels.
- Cleaned up the x86 specific stuff used in time of day. Now there's
only one place where we have an `ifdef`, rather than spreading it all
over the rendering code.
2024-05-09 20:11:43 -04:00
Hat Kid
cbf75a96f7
custom levels: don't uppercase FR3 filename (#3496) 2024-04-30 22:51:36 +02:00
ManDude
8344ac6963
use only the real level name in the Loader (#3495)
This fixes issues with certain Jak 3 levels not rendering because there
is a mismatch between the DGO name, nickname and real level name (bsp
name).

FR3s use a different filename, so you can delete the ones you have after
this is merged.

This affects custom levels, but I don't have that toolchain set up so
someone else will have to test that.
2024-04-30 17:12:57 +01:00
Tyler Wilding
fee0a435fc
extractor: support extracting using a folder path (#3422)
Patching up the extractor while working on the launcher, fixes:
- makes it so you can compile successfully given a folder path
(currently assumes your project path contains `iso_data`)
- ignore `buildinfo.json` from validation code.
- fixes an edge-case that could recursively fill up your entire
hard-drive!
- allows overriding the decompilation configuration via flag
- adds a way to specify where the ISO should be extracted to
2024-04-28 15:02:29 -04:00
ManDude
bcab625864
debugger: reverse the order the backtrace is printed (#3474) 2024-04-16 05:22:31 +01:00
ManDude
8e5830321c
[jak3] fix process stack overflow + collision renderer (#3473) 2024-04-16 04:26:01 +01:00
water111
0124a0b9a1
[jak3] Support jaextern.str, stub for blue fog fix (#3455) 2024-04-07 11:09:56 -04:00
water111
cc8801a27b
[goalc] speed up jak3 compilation (#3454)
I noticed that jak 3's compilation was spending a lot of time accessing
the `unordered_map`s we use to store constants and symbol types.

 
I repurposed the `EnvironmentMap` originally made for GOOS for this. It
turns out that we were copying the entire constant map whenever we
encountered a `deftype`, and fixed that too.

This speeds up jak3 compiles from ~16 to 11 seconds for me.
2024-04-06 16:01:17 -04:00
water111
376194a3e7
Jak 3, fixes for animation issues, rm debug print (#3453) 2024-04-06 15:09:02 -04:00
Tyler Wilding
0a15ac1669
goalc: Fix new symbol trie's performance inefficiencies (#3443)
I believe this brings things back in line to where it was before:
Here are the first handful of files before the changes:
```
0.014 | gcommon.gc
0.006 | gkernel-h.gc
0.025 | gkernel.gc
0.002 | pskernel.gc
0.01 | gstring.gc
0.004 | gstate.gc
0.001 | kernel.gd
0.001 | types-h.gc
0.002 | vu1-macros.gc
0.003 | math.gc
0.01 | vector-h.gc
0.001 | gravity-h.gc
0.001 | bounding-box-h.gc
0.001 | matrix-h.gc
0.001 | quaternion-h.gc
0.001 | euler-h.gc
```
> first compile
```
0.161 | gcommon.gc
0.126 | gkernel-h.gc
0.174 | gkernel.gc
0.046 | pskernel.gc
0.08 | gstring.gc
0.048 | gstate.gc
0.001 | kernel.gd
0.052 | types-h.gc
0.009 | vu1-macros.gc
0.059 | math.gc
0.228 | vector-h.gc
0.026 | gravity-h.gc
0.006 | bounding-box-h.gc
0.002 | matrix-h.gc
0.028 | quaternion-h.gc
0.026 | euler-h.gc
```
> make a change in gcommon and recompile

With the changes:
```
0.015 | gcommon.gc
0.018 | gkernel-h.gc
0.039 | gkernel.gc
0.006 | pskernel.gc
0.015 | gstring.gc
0.009 | gstate.gc
0.005 | kernel.gd
0.006 | types-h.gc
0.006 | vu1-macros.gc
0.008 | math.gc
0.017 | vector-h.gc
0.004 | gravity-h.gc
0.004 | bounding-box-h.gc
0.005 | matrix-h.gc
0.005 | quaternion-h.gc
0.003 | euler-h.gc
```
> First compile, no difference expected

```
0.016 | gcommon.gc
0.008 | gkernel-h.gc
0.023 | gkernel.gc
0.002 | pskernel.gc
0.01 | gstring.gc
0.043 | gstate.gc
0.001 | kernel.gd
0.002 | types-h.gc
0.002 | vu1-macros.gc
0.003 | math.gc
0.013 | vector-h.gc
0.001 | gravity-h.gc
0.002 | bounding-box-h.gc
0.002 | matrix-h.gc
0.001 | quaternion-h.gc
0.001 | euler-h.gc
```
> Compile times seem to be back within margin of error -- some are
faster than the first compilation time.
2024-04-01 18:56:55 -04:00
Tyler Wilding
53277a65ad
LSP: A bunch of new OpenGOAL language features (#3437)
- Integrate the AST into the LSP, this makes parsing and tokenizing the
files much easier
- Consolidate most of the symbol info tracking in `goalc` to a single
map. Fixed some issues where the old map would never evict symbols when
re-compiling files. There is still some more to cleanup, but this now
can be used as an incrementally updated source-of-truth for the LSP
- re-compile files when they are saved. Ideally this would be done
everytime they are changed but that:
  - may be too aggressive
- goalc doesn't compile incrementally yet so it likely would be a worse
UX

Features added, see
https://github.com/open-goal/opengoal-vscode/issues/256
- Hover

![image](https://github.com/open-goal/jak-project/assets/13153231/58dadb5d-582c-4c1f-9ffe-eaa4c85a0255)

![image](https://github.com/open-goal/jak-project/assets/13153231/b383adde-57fc-462c-a256-b2de5c30ca9a)
- LSP Status fixed
- Type Hierarchy

![image](https://github.com/open-goal/jak-project/assets/13153231/8e681377-1d4e-4336-ad70-1695a4607340)
- Document Color

![image](https://github.com/open-goal/jak-project/assets/13153231/4e48ccd8-0ed1-4459-a133-5277561e4201)
- Document Symbols
![Screenshot 2024-03-27
004105](https://github.com/open-goal/jak-project/assets/13153231/8e655034-43c4-4261-b6e0-85de00cbfc7f)
- Completions
![Screenshot 2024-03-30
004504](https://github.com/open-goal/jak-project/assets/13153231/d123a187-af90-466b-9eb7-561b2ee97cd1)

---------

Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2024-03-30 19:49:07 -04:00
Hat Kid
dacb704ef6
decomp3: more engine stuff, fix ja macro detection for jak 2/3, unmerged let matcher, part-tracker-spawn macro (#3436)
- `aligner`
- `effect-control`
- `pov-camera`
- `powerups`
- `los-control-h`
- `airlock`
- `water-anim`
- `blocking-plane`
- `proc-focusable-spawner`
- `idle-control`
- `enemy-h`
- `nav-enemy-h`
- `enemy`
- `enemy-states`
- `particle-curves`
- `base-plat`
- `plat`
- `bouncer`
- `elevator`
- `rigid-body`
- `rigid-body-queue`
- `process-taskable`
- `scene-actor`
- `warp-gate`
- `guard-projectile`
- `metalhead-projectile`
- `los-control`
- `joint-exploder`
- `ragdoll-test`
- `debris`
- `shield-sphere`
- `text`
- `target-launch`
2024-03-30 10:28:02 -04:00
water111
ee015e3b22
[jak3] A bunch of small fixes to get game.cgo to load (#3435)
The `test-play` macro is back, though it doesn't call `play` yet. We can
at least load all of `game.cgo`, which involves loading a lot of the
code we've decompiled, loading/linking objects files compiled by
OpenGOAL (like dir-tpages), and loading/linking Jak's art-groups (for
jak 3 they are stored v5 format that I added to the linker).

There were no major issues - just a few forgotten mips2c entries and
minor bugs/functions that needed stubs. Most of the work was updating
the linker. Hopefully I'll never have to touch that code again - I think
it supports everything we need for jak 3!
2024-03-24 16:30:28 -04:00
water111
9b4b54978a
decomp drawable, main (#3434) 2024-03-24 12:27:04 -04:00
water111
ffe01a352d
Decompile level (#3433) 2024-03-23 13:03:01 -04:00
Hat Kid
99866cec88
decomp3: more engine files, get-texture macro, use print method in autogenerated inspect, fix bitfield float print (#3432)
- `fma-sphere`
- `prim-beam-h`
- `cam-start`
- `ragdoll`
- `light-trails-h`
- `light-trails`
- `menu`
- `water`
- `water-flow`
- `hud`
- `hud-classes`
- `progress`
- `progress-draw`

---

The `get-texture` macro replaces calls to `lookup-texture-by-id` and
`lookup-texture-by-id-fast`. The `defpart` macro detection was modified
to print a pair like `(texture-name tpage-name)` for the texture field
that gets turned into a `texture-id` constant. Only used in Jak 3 at the
moment, I'll probably go through the other games at a later point.
2024-03-23 09:25:11 -04:00
water111
82fb2cc26a
Port bones.gc math to GOAL (#3425)
Reverse engineer the skinning matrix calculation and port to GOAL. This
is about 3x faster than the MIPS2c version.

As usual, there is a `*use-new-bones*` flag to go back to the old
version.

Fix for a bug in the compiler's `.div.vf` implementation (only happens
if src/dst are the same), and fix for a typo in the register allocator
that would sometimes cause it not to consider xmm8-xmm15.
2024-03-15 20:31:11 -04:00
Hat Kid
5a8b4e81f9
decomp3: more engine stuff, support boxed stack arrays in compiler (#3424)
- `sync-info`
- `trajectory`
- `camera`
- `cam-update`
- `cam-states`
- `cam-states-dbg`
- `cam-master`
- `cam-layout`
- `cam-interface`
- `cam-combiner`

Closes #2016
2024-03-15 20:28:26 -04:00
Tyler Wilding
60db0e5ef9
deps: update fmt to latest version (#3403)
This updates `fmt` to the latest version and moves to just being a copy
of their repo to make updating easier (no editing their cmake / figuring
out which files to minimally include).

The motivation for this is now that we switched to C++ 20, there were a
ton of deprecated function usages that is going away in future compiler
versions. This gets rid of all those warnings.
2024-03-05 22:11:52 -05:00
Ziemas
4afefc5a82
Update to C++20 (#3193)
Just putting this here for consideration, I'm personally not in a big
rush to get it.

---------

Co-authored-by: Tyler Wilding <xtvaser@gmail.com>
2024-02-17 14:14:23 -05:00
Hat Kid
3eb6cfcb17
custom levels: add support for symbol, type, and string lumps (#3337) 2024-01-25 23:20:32 +01:00
water111
638bf1d3d9
[gltf] Support either u16 or float for colors (#3322)
It seems like this depends on the version of blender, so we should
support both.
2024-01-21 11:03:26 -05:00
Hat Kid
2bb1d53752
custom levels: cell-info and buzzer-info lumps (#3324)
Adds two new lump types: `cell-info` and `buzzer-info`.

`cell-info` takes a `game-task` enum value and defines an `eco-info`
lump for power cells.

`buzzer-info` takes a `game-task` enum value and an integer and
automatically calculates the required value for the buzzer task with the
formula `task + buzzer * (1 << 16)`.
2024-01-21 03:49:55 +01:00
Hat Kid
b06d63ba83
custom levels: sort actors by aid and check for duplicates (#3315)
When giving entities custom actor IDs in your level JSON, it is possible
to break entity lookups by actor ID if the actors are not sorted by ID
because `entity-by-aid` expects them to be in order.

This sorts the actor list by ID before generating the level file and
also checks for any duplicates.
2024-01-18 10:29:30 +01:00
water111
4f537d4a71
[jak3] Set up ckernel (#3308)
This sets up the C Kernel for Jak 3, and makes it possible to build and
load code built with `goalc --jak3`.

There's not too much interesting here, other than they switched to a
system where symbol IDs (unique numbers less than 2^14) are generated at
compile time, and those get included in the object file itself.

This is kind of annoying, since it means all tools that produce a GOAL
object file need to work together to assign unique symbol IDs. And since
the symbol IDs can't conflict, and are only a number between 0 and 2^14,
you can't just hash and hope for no collisions.

We work around this by ignoring the IDs and re-assigning our own. I
think this is very similar to what the C Kernel did on early builds of
Jak 3 which supported loading old format level files, which didn't have
the IDs included.

As far as I can tell, this shouldn't cause any problems. It defeats all
of their fancy tricks to save memory by not storing the symbol string,
but we don't care.
2024-01-16 19:24:02 -05:00
jabermony
07427799a6
Jak3 Build Environment (#3098)
This sets out the bones of a Jak 3 build, many things are stubbed out,
guessed, or copied from Jak 2 but it should at least be good enough to:
run `task set-game-jak3`
launch the repl
run builds from the repl

build outputs themselves are untested but the build itself runs without
errors

---------

Co-authored-by: Tyler Wilding <xtvaser@gmail.com>
2024-01-15 20:37:16 -05:00
Tyler Wilding
637b043293
deps: update zydis to latest commit (#3306)
Updates Zydis to it's latest commit, this should fix building the
project on intel macs with a more recent version of macOS. This likely
needs some sanity checks that the debugger stuff still works as
expected.
2024-01-15 16:56:14 -05:00
Hat Kid
619f39d3b7
custom levels: enum lump support (#3305)
This adds support for using enums in lumps using the new lump types
`enum-int32` and `enum-uint32`. Also adds these other new lump types:

- `water-height` (takes 3 meter floats, an enum and another optional
meter float)
- `eco-info` (takes an enum and an int)
- `vector3m` (3 meter floats + `w` set to 1.0)
2024-01-15 12:46:42 +01:00
Matt Dallmeyer
2071c98b55
Fix cases of string formatting with non string literals (#3304)
The logger used in `goalc` tries to print an already-formatted string
`message` using `fmt::print(message);` Usually this doesn't cause
problems, but if you try to print, for example, an exception that has
special characters (notably `{`) it will try to do another round of
formatting/replacements, despite not having any args to replace with,
which ends up throwing another exception. This is why errors when
parsing custom level JSON cause the REPL to exit.

I've hopefully identified all the various instances of this across the
codebase
2024-01-14 12:02:08 +00:00
EvelynTSMG
12118e57cb
Impr: Make mesh extract compatible with gLTF 2.0 (and Blender 4.0) (#3268)
:3
2024-01-01 16:30:48 -05:00
ManDude
cd68cb671e
deftype and defmethod syntax major changes (#3094)
Major change to how `deftype` shows up in our code:
- the decompiler will no longer emit the `offset-assert`,
`method-count-assert`, `size-assert` and `flag-assert` parameters. There
are extremely few cases where having this in the decompiled code is
helpful, as the types there come from `all-types` which already has
those parameters. This also doesn't break type consistency because:
  - the asserts aren't compared.
- the first step of the test uses `all-types`, which has the asserts,
which will throw an error if they're bad.
- the decompiler won't emit the `heap-base` parameter unless necessary
now.
- the decompiler will try its hardest to turn a fixed-offset field into
an `overlay-at` field. It falls back to the old offset if all else
fails.
- `overlay-at` now supports field "dereferencing" to specify the offset
that's within a field that's a structure, e.g.:
```lisp
(deftype foobar (structure)
  ((vec    vector  :inline)
   (flags  int32   :overlay-at (-> vec w))
   )
  )
```
in this structure, the offset of `flags` will be 12 because that is the
final offset of `vec`'s `w` field within this structure.
- **removed ID from all method declarations.** IDs are only ever
automatically assigned now. Fixes #3068.
- added an `:overlay` parameter to method declarations, in order to
declare a new method that goes on top of a previously-defined method.
Syntax is `:overlay <method-name>`. Please do not ever use this.
- added `state-methods` list parameter. This lets you quickly specify a
list of states to be put in the method table. Same syntax as the
`states` list parameter. The decompiler will try to put as many states
in this as it can without messing with the method ID order.

Also changes `defmethod` to make the first type definition (before the
arguments) optional. The type can now be inferred from the first
argument. Fixes #3093.

---------

Co-authored-by: Hat Kid <6624576+Hat-Kid@users.noreply.github.com>
2023-10-30 03:20:02 +00:00
ManDude
09536c68ac
[compiler] asm-only disasm output + fix spacing bug (#3104) 2023-10-29 10:16:14 +00:00
Hat Kid
c7c615a043
custom levels: refactor level building code and jak 2 support (#3090)
Co-authored-by: water <awaterford111445@gmail.com>
2023-10-21 06:07:43 +02:00
Hat Kid
e6b73f1058
custom levels: support for packing textures (#3089) 2023-10-15 16:36:14 +02:00
water111
395c98db19
[goalc] Cleaned up speedups (#3066)
Started at 349,880,038 allocations and 42s

- Switched to making `Symbol` in GOOS be a "fixed type", just a wrapper
around a `const char*` pointing to the string in the symbol table. This
is a step toward making a lot of things better, but by itself not a huge
improvement. Some things may be worse due to more temp `std::string`
allocations, but one day all these can be removed. On linux it saved
allocations (347,685,429), and saved a second or two (41 s).
- cache `#t` and `#f` in interpreter, better lookup for special
forms/builtins (hashtable of pointers instead of strings, vector for the
small special form list). Dropped time to 38s.
- special-case in quasiquote when splicing is the last thing in a list.
Allocation dropped to 340,603,082
- custom hash table for environment lookups (lexical vars). Dropped to
36s and 314,637,194
- less allocation in `read_list` 311,613,616. Time about the same.
- `let` and `let*` in Interpreter.cpp 191,988,083, time down to 28s.
2023-10-07 10:48:17 -04:00
water111
0e31a9c407
[decompiler] Handle find-parent-method (#3018)
This change adds a few new features:
- Decompiler automatically knows the type of `find-parent-method` use in
jak 1 and jak2 when used in a method or virtual state handler.
- Decompiler inserts a call to `call-parent-method` or
`find-parent-state`
- Removed most casts related to these functions

There are still a few minor issues around this:
- There are still some casts needed when using `post` methods, as `post`
is just a `function`, and needs a cast to `(function none)` or similar.
It didn't seem easy to change the type of `post`, so I'm not going to
worry about it for this PR. It only shows up in like 3 places in jak 2.
(and 0 in jak 1)
- If "call the handler if it's not #f" logic should probably be another
macro.

Fixes #805
2023-09-30 11:06:09 -04:00
ManDude
170cbd7e6c
misc low hanging fruit fixes (#3034)
Fixes #2235 
Fixes #2236 
Fixes #2963 
Fixes #3027
2023-09-27 00:59:07 +01:00
ManDude
9b60afe6e6
[compiler] fix compile_condition not attempting macro expansion (#3030)
Ancient bug! Resulted in a 1%-2% decrease in code object file size (and
more importantly the asm is more readable).

Fixes #3029
2023-09-25 23:49:12 +01:00