Game-Decompilation/sotn-decomp
1
0
Fork 0
mirror of https://github.com/Xeeynamo/sotn-decomp.git synced 2024-10-07 02:24:01 +00:00
Code Issues Actions 8 Packages Projects Releases Wiki Activity
049493c95a
sotn-decomp/Makefile.psx.mk

66 lines
3.3 KiB
Makefile
Raw Normal View History

Enhance make extract on PSX (#662) Previously if either the YAML or the symbol list were changed, we were forced to either manually delete the `asm` folder of the specific overlay or to invoke `make clean`, where the latter forced us to re-extract all the overlays via `make -j extract`. That changes with this PR. How `make` works is `target: dep1 dep2` where if one of the dependencies has the last modified date greater than the target, the rule is triggered again. Previously we were extracting overlays doing `make extract_stcen`. But since every overlay extraction generates a linker script I now changed the rules to do `make build/us/stcen.ld` to extract the same overlay. As I explained above, if either the YAML or one of the related symbols changes, the linker modified date will be older and the extraction for that overlay to be trigger again. The above allowed me to stop polluting the repo root with the linker scripts as they are now moved into `build/us` or `build/hd` depending of what you're trying to build. If you do `make extract` twice in a row you will be welcomed with a `make: Nothing to be done for 'extract'.`. There are still some instances where you **might** need `make clean` beforehand, especially when modifying the `segment` section in the YAML or renaming the symbols. A `rm -rf asm/$(VERSION)/$*` can help but I want to see if the current solution will be enough. ### Please try removing `make clean` from your workflow, once this is merged, to quickly detect possible problems with this new approach. I am also planning to make more substantial changes on our build-chain like this PR or #660 in the future. I am aiming to small incremental changes over time in case I break someone's flow or detect design flaws. I am also considering the breaking changes introduced in make 4.4, which will most likely be included in Ubuntu 24.04 LTS. I set March 2024 as a deadline to finish all the new build-chain work. --------- Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>
2023-10-05 08:26:29 +00:00
# configuration
Pass undefined_syms files to linker (#1065) Creating a PR for this, will look at updating splat in a separate PR
2024-02-18 14:57:03 +00:00
PSX_OVLS := dra ric weapon
Enhance make extract on PSX (#662) Previously if either the YAML or the symbol list were changed, we were forced to either manually delete the `asm` folder of the specific overlay or to invoke `make clean`, where the latter forced us to re-extract all the overlays via `make -j extract`. That changes with this PR. How `make` works is `target: dep1 dep2` where if one of the dependencies has the last modified date greater than the target, the rule is triggered again. Previously we were extracting overlays doing `make extract_stcen`. But since every overlay extraction generates a linker script I now changed the rules to do `make build/us/stcen.ld` to extract the same overlay. As I explained above, if either the YAML or one of the related symbols changes, the linker modified date will be older and the extraction for that overlay to be trigger again. The above allowed me to stop polluting the repo root with the linker scripts as they are now moved into `build/us` or `build/hd` depending of what you're trying to build. If you do `make extract` twice in a row you will be welcomed with a `make: Nothing to be done for 'extract'.`. There are still some instances where you **might** need `make clean` beforehand, especially when modifying the `segment` section in the YAML or renaming the symbols. A `rm -rf asm/$(VERSION)/$*` can help but I want to see if the current solution will be enough. ### Please try removing `make clean` from your workflow, once this is merged, to quickly detect possible problems with this new approach. I am also planning to make more substantial changes on our build-chain like this PR or #660 in the future. I am aiming to small incremental changes over time in case I break someone's flow or detect design flaws. I am also considering the breaking changes introduced in make 4.4, which will most likely be included in Ubuntu 24.04 LTS. I set March 2024 as a deadline to finish all the new build-chain work. --------- Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>
2023-10-05 08:26:29 +00:00
PSX_KSTAGES := cen dre mad no3 np3 nz0 sel st0 wrp
PSX_RSTAGES := rwrp
PSX_ALLSTAGES := $(addprefix st,$(PSX_KSTAGES)) $(addprefix st,$(PSX_RSTAGES))
PSX_SERVANTS := tt_000
PSX_US_TARGETS := main $(PSX_OVLS) $(PSX_ALLSTAGES) $(PSX_SERVANTS)
PSX_HD_TARGETS := dra
# immovable
PSX_BASE_SYMS := $(CONFIG_DIR)/symbols.$(VERSION).txt
extract_us: $(addprefix $(BUILD_DIR)/,$(addsuffix .ld,$(PSX_US_TARGETS)))
Extract BIN/F_GAME.BIN (#886) Mostly a proof of concept to extract resources from `BIN/F_GAME.BIN`. There are tons of hacks to make this work: * Tweaked png2s to decode binaries into PNGs * Add a `config/gfx.game.json` that describes how to extract different sprites out of a binary file * Coded the palette location by reading the `clut` parameter in the source code. A clut value of `0x196` corresponds to `"palette": "0x96"` or `"palette": 150`. * Coded the bits per pixel for a couple of 8-bit images * Coded the palette location of those graphics that expects the palette from DRA.BIN instead of F_GAME.BIN * For all the undiscovered palette, I called the files `unk` and defaulted their palette to grey The expectation is that sprites will slowly be documented and added into `config/gfx.game.json` by modders and enthusiasts. This does not yet pack back these PNGs into the binary file. The way these assets are extracted is probably not final or perfect, but we have to start from somewhere. ![image](https://github.com/Xeeynamo/sotn-decomp/assets/6128729/ce12ad2d-d95d-41e8-ac31-186cd36ac965)
2023-12-25 19:23:25 +00:00
$(PNG2S) bdecode config/gfx.game.json disks/us assets/game
Enhance make extract on PSX (#662) Previously if either the YAML or the symbol list were changed, we were forced to either manually delete the `asm` folder of the specific overlay or to invoke `make clean`, where the latter forced us to re-extract all the overlays via `make -j extract`. That changes with this PR. How `make` works is `target: dep1 dep2` where if one of the dependencies has the last modified date greater than the target, the rule is triggered again. Previously we were extracting overlays doing `make extract_stcen`. But since every overlay extraction generates a linker script I now changed the rules to do `make build/us/stcen.ld` to extract the same overlay. As I explained above, if either the YAML or one of the related symbols changes, the linker modified date will be older and the extraction for that overlay to be trigger again. The above allowed me to stop polluting the repo root with the linker scripts as they are now moved into `build/us` or `build/hd` depending of what you're trying to build. If you do `make extract` twice in a row you will be welcomed with a `make: Nothing to be done for 'extract'.`. There are still some instances where you **might** need `make clean` beforehand, especially when modifying the `segment` section in the YAML or renaming the symbols. A `rm -rf asm/$(VERSION)/$*` can help but I want to see if the current solution will be enough. ### Please try removing `make clean` from your workflow, once this is merged, to quickly detect possible problems with this new approach. I am also planning to make more substantial changes on our build-chain like this PR or #660 in the future. I am aiming to small incremental changes over time in case I break someone's flow or detect design flaws. I am also considering the breaking changes introduced in make 4.4, which will most likely be included in Ubuntu 24.04 LTS. I set March 2024 as a deadline to finish all the new build-chain work. --------- Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>
2023-10-05 08:26:29 +00:00
extract_hd: $(addprefix $(BUILD_DIR)/,$(addsuffix .ld,$(PSX_HD_TARGETS)))
extract_disk_us: extract_disk_psxus
extract_disk_hd: extract_disk_pspeu
extract_disk_psp%:
mkdir -p disks/psp$*
7z x disks/sotn.psp$*.iso -odisks/psp$*/
extract_disk_psx%: $(SOTNDISK)
$(SOTNDISK) extract disks/sotn.$*.cue disks/$*
$(BUILD_DIR)/main.ld: $(CONFIG_DIR)/splat.$(VERSION).main.yaml $(SPLAT_APP)
$(SPLAT) $<
$(BUILD_DIR)/dra.ld: $(CONFIG_DIR)/splat.$(VERSION).dra.yaml $(PSX_BASE_SYMS) $(CONFIG_DIR)/symbols.$(VERSION).dra.txt $(SPLAT_APP)
$(SPLAT) $<
$(BUILD_DIR)/ric.ld: $(CONFIG_DIR)/splat.$(VERSION).ric.yaml $(PSX_BASE_SYMS) $(CONFIG_DIR)/symbols.$(VERSION).ric.txt $(SPLAT_APP)
$(SPLAT) $<
$(BUILD_DIR)/stmad.ld: $(CONFIG_DIR)/splat.$(VERSION).stmad.yaml $(CONFIG_DIR)/symbols.beta.txt $(CONFIG_DIR)/symbols.stmad.txt $(SPLAT_APP)
$(SPLAT) $<
$(GFXSTAGE) d disks/$(VERSION)/ST/MAD/F_MAD.BIN $(ASSETS_DIR)/st/mad
$(BUILD_DIR)/st%.ld: $(CONFIG_DIR)/splat.$(VERSION).st%.yaml $(PSX_BASE_SYMS) $(CONFIG_DIR)/symbols.$(VERSION).st%.txt $(SPLAT_APP)
$(SPLAT) $<
$(GFXSTAGE) d disks/$(VERSION)/ST/$$(echo '$*' | tr '[:lower:]' '[:upper:]')/F_$$(echo '$*' | tr '[:lower:]' '[:upper:]').BIN $(ASSETS_DIR)/st/$*
$(BUILD_DIR)/tt_%.ld: $(CONFIG_DIR)/splat.$(VERSION).tt_%.yaml $(PSX_BASE_SYMS) $(CONFIG_DIR)/symbols.$(VERSION).tt_%.txt $(SPLAT_APP)
$(SPLAT) $<
$(BUILD_DIR)/weapon.ld: $(CONFIG_DIR)/splat.$(VERSION).weapon.yaml $(PSX_BASE_SYMS) $(CONFIG_DIR)/symbols.$(VERSION).weapon.txt $(CONFIG_DIR)/symbols.$(VERSION).weapon.txt.in $(SPLAT_APP)
$(SPLAT) $<
Pass undefined_syms files to linker (#1065) Creating a PR for this, will look at updating splat in a separate PR
2024-02-18 14:57:03 +00:00
Extract memory card icons (#166) Extract the memory card icons out of DRA.BIN and SEL.BIN. ![image](https://user-images.githubusercontent.com/6128729/227794798-4dd071f9-512b-4c72-8f5d-fcbf7a615519.png) I also took the opportunity to extract `g_MemcardPortMask` into its own source file `save_mgr_pre.c`. Unfortunately this is required to keep the original data order. This suggests that most likely the icon palette and bitmap were baked into the original `save_mgr.c` as byte arrays. I decided to take a different approach and extracted them as PNGs for better moddability. I had to spin-off Splat into a new fork due to some breaking changes on 0.18.0.
2023-12-12 07:12:13 +00:00
$(BUILD_DIR)/assets/dra/memcard_%.png.o: assets/dra/memcard_%.png
mkdir -p $(dir $@)
Extract BIN/F_GAME.BIN (#886) Mostly a proof of concept to extract resources from `BIN/F_GAME.BIN`. There are tons of hacks to make this work: * Tweaked png2s to decode binaries into PNGs * Add a `config/gfx.game.json` that describes how to extract different sprites out of a binary file * Coded the palette location by reading the `clut` parameter in the source code. A clut value of `0x196` corresponds to `"palette": "0x96"` or `"palette": 150`. * Coded the bits per pixel for a couple of 8-bit images * Coded the palette location of those graphics that expects the palette from DRA.BIN instead of F_GAME.BIN * For all the undiscovered palette, I called the files `unk` and defaulted their palette to grey The expectation is that sprites will slowly be documented and added into `config/gfx.game.json` by modders and enthusiasts. This does not yet pack back these PNGs into the binary file. The way these assets are extracted is probably not final or perfect, but we have to start from somewhere. ![image](https://github.com/Xeeynamo/sotn-decomp/assets/6128729/ce12ad2d-d95d-41e8-ac31-186cd36ac965)
2023-12-25 19:23:25 +00:00
$(PNG2S) encode $< \
Extract memory card icons (#166) Extract the memory card icons out of DRA.BIN and SEL.BIN. ![image](https://user-images.githubusercontent.com/6128729/227794798-4dd071f9-512b-4c72-8f5d-fcbf7a615519.png) I also took the opportunity to extract `g_MemcardPortMask` into its own source file `save_mgr_pre.c`. Unfortunately this is required to keep the original data order. This suggests that most likely the icon palette and bitmap were baked into the original `save_mgr.c` as byte arrays. I decided to take a different approach and extracted them as PNGs for better moddability. I had to spin-off Splat into a new fork due to some breaking changes on 0.18.0.
2023-12-12 07:12:13 +00:00
$(BUILD_DIR)/assets/dra/memcard_$*.png.s g_saveIcon$* \
$(BUILD_DIR)/assets/dra/memcard_$*.pal.s g_saveIconPal$*
$(AS) $(AS_FLAGS) -o $(BUILD_DIR)/assets/dra/memcard_$*.png.o $(BUILD_DIR)/assets/dra/memcard_$*.png.s
rm $(BUILD_DIR)/assets/dra/memcard_$*.png.s
$(AS) $(AS_FLAGS) -o $(BUILD_DIR)/assets/dra/memcard_$*.pal.o $(BUILD_DIR)/assets/dra/memcard_$*.pal.s
rm $(BUILD_DIR)/assets/dra/memcard_$*.pal.s
$(BUILD_DIR)/assets/st/sel/memcard_%.png.o: assets/st/sel/memcard_%.png
mkdir -p $(dir $@)
Extract BIN/F_GAME.BIN (#886) Mostly a proof of concept to extract resources from `BIN/F_GAME.BIN`. There are tons of hacks to make this work: * Tweaked png2s to decode binaries into PNGs * Add a `config/gfx.game.json` that describes how to extract different sprites out of a binary file * Coded the palette location by reading the `clut` parameter in the source code. A clut value of `0x196` corresponds to `"palette": "0x96"` or `"palette": 150`. * Coded the bits per pixel for a couple of 8-bit images * Coded the palette location of those graphics that expects the palette from DRA.BIN instead of F_GAME.BIN * For all the undiscovered palette, I called the files `unk` and defaulted their palette to grey The expectation is that sprites will slowly be documented and added into `config/gfx.game.json` by modders and enthusiasts. This does not yet pack back these PNGs into the binary file. The way these assets are extracted is probably not final or perfect, but we have to start from somewhere. ![image](https://github.com/Xeeynamo/sotn-decomp/assets/6128729/ce12ad2d-d95d-41e8-ac31-186cd36ac965)
2023-12-25 19:23:25 +00:00
$(PNG2S) encode $< \
Extract memory card icons (#166) Extract the memory card icons out of DRA.BIN and SEL.BIN. ![image](https://user-images.githubusercontent.com/6128729/227794798-4dd071f9-512b-4c72-8f5d-fcbf7a615519.png) I also took the opportunity to extract `g_MemcardPortMask` into its own source file `save_mgr_pre.c`. Unfortunately this is required to keep the original data order. This suggests that most likely the icon palette and bitmap were baked into the original `save_mgr.c` as byte arrays. I decided to take a different approach and extracted them as PNGs for better moddability. I had to spin-off Splat into a new fork due to some breaking changes on 0.18.0.
2023-12-12 07:12:13 +00:00
$(BUILD_DIR)/assets/st/sel/memcard_$*.png.s g_saveIcon$* \
$(BUILD_DIR)/assets/st/sel/memcard_$*.pal.s g_saveIconPal$*
$(AS) $(AS_FLAGS) -o $(BUILD_DIR)/assets/st/sel/memcard_$*.png.o $(BUILD_DIR)/assets/st/sel/memcard_$*.png.s
rm $(BUILD_DIR)/assets/st/sel/memcard_$*.png.s
$(AS) $(AS_FLAGS) -o $(BUILD_DIR)/assets/st/sel/memcard_$*.pal.o $(BUILD_DIR)/assets/st/sel/memcard_$*.pal.s
rm $(BUILD_DIR)/assets/st/sel/memcard_$*.pal.s
WIP FT_000
2023-11-20 18:53:43 +00:00
$(BUILD_DIR)/TT_%.BIN: $(BUILD_DIR)/tt_%.elf
$(OBJCOPY) -O binary $< $@
printf '\x00' | dd of=$@ bs=1 seek=40959 count=1 conv=notrunc
$(BUILD_DIR)/FT_%.BIN: disks/$(VERSION)/SERVANT/FT_%.BIN
cp $< $@
Reference in New Issue Copy Permalink