Game-Decompilation/sotn-decomp
1
0
Fork 0
mirror of https://github.com/Xeeynamo/sotn-decomp.git synced 2024-11-23 13:09:44 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity
af89c6247c
sotn-decomp/CMakeLists.txt

471 lines
12 KiB
CMake
Raw Normal View History

Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
cmake_minimum_required(VERSION 3.10)
project(Sound)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
Add macOS agent to the CI (#968) `AppleClang` has `-Wimplicit-function-declaration` and `-Wreturn-type` defined by default. I had to disable them to have parity between non-Apple default compiler flags.
2024-01-11 22:46:35 +00:00
if (WIN32)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake)
endif()
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
Add macOS agent to the CI (#968) `AppleClang` has `-Wimplicit-function-declaration` and `-Wreturn-type` defined by default. I had to disable them to have parity between non-Apple default compiler flags.
2024-01-11 22:46:35 +00:00
if (CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang|AppleClang")
Load VB,VH files, fix memory bugs (#958) This turns on address sanitizer, prevents a bunch of memory corruption bugs, and loads the VB/VH files.
2024-01-11 00:34:12 +00:00
set(CMAKE_BUILD_TYPE Debug)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address")
set(CMAKE_LINKER_FLAGS "${CMAKE_LINKER_FLAGS} -fsanitize=address")
Fix fake symbols and solve runtime issues (#1241) Cherry-picking a few floating fixes from a testing branch as they're good enough to be merged into `master`: * With cmake 3.29.3 and GCC 14.1.1 I am personally having some compilation issues. I disabled some error checks to make the executable running locally on my machine. This might fix potential compilation issues if we upgrade the CI agent. * Fix the use of a fake symbol in WRP * A few signature adjustments * `HitDetection` with a simulated scratch-pad
2024-06-02 19:52:27 +00:00
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-implicit-function-declaration")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-incompatible-pointer-types")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-int-conversion")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-return-mismatch")
Load VB,VH files, fix memory bugs (#958) This turns on address sanitizer, prevents a bunch of memory corruption bugs, and loads the VB/VH files.
2024-01-11 00:34:12 +00:00
endif()
Add macOS agent to the CI (#968) `AppleClang` has `-Wimplicit-function-declaration` and `-Wreturn-type` defined by default. I had to disable them to have parity between non-Apple default compiler flags.
2024-01-11 22:46:35 +00:00
if (CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-implicit-function-declaration")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-return-type")
endif()
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
find_package(SDL2 REQUIRED)
set(SOURCE_FILES_PC
src/pc/log.c
src/pc/stubs.c
src/pc/sotn.c
src/pc/pc.c
Refactor File helper functions (#1471) Use the following input endpoints `FileOpenRead`, `FileReadToBuf`, `FileAsString` and `FileUseContent`. There was a lot of redundant and inconsistent code scattered across all the functions responsible of opening and processing files. I also realised the purpose of some File helpers was not entirely clear, so I spent some effort to document them. This is a small part of a bigger effort on refactoring `sim_pc.c`. I am also planning on adding support for paths such as `disk://` to load from `disks/us/`, `asset://` to load from `asset/`, `card://` to start adding support for simulated memcards and so on. This is setting the very basics to plan that out.
2024-08-04 16:36:43 +00:00
src/pc/io.c
Add support for Japanese characters (#1005) This took me A LOT of time, mainly because I am not aware of any good dictionary/map implementation in C. One of the time consuming parts was adding the special characters due to how the game uses the dakuten and handakuten. The function `AnsiToSotnMenuString` is still very fast as I am searching the characters via a binary search. If you have any suggestion for a O(1) implementation please let me know. This fixes some buffer overflows when rendering Japanese strings.
2024-01-22 19:29:45 +00:00
src/pc/str.c
Texture render support (#934) Technically unimpressive, but I had to go through quite a good amount of changes. Here is the full changelog to make everything work: * Ensure `ResetPlatform` is always called to avoid memory leaks * Add `g_RawVram` to emulate the PS1 VRAM * ~~The engine will load the optional file `disks/vram.bin`, a RAM dump from an emulator~~ * SDL2 will create 256x256 textures on-the-fly whenever a specific tpage is requested via `GetVramTexture` * The function `GetVramTexture` caches the last called tpage to avoid tanking the performance * `GetVramTexture` for only renders 4bpp and 8bpp textures with their specified palette * Remove `SDL2_image` as the font is now loaded straight from the VRAM * Calling `VSync` will call the set callback, which the game uses for DMA operations * `MyLoadImage` is not yet implemented, but it is a placeholder to then interact with `g_RawVram` * The menu font now uses the texture found in the VRAM * Plugged a custom version of `LoadFileSim` * The file `sim_pc.c` is similar to the original game's code but it is used here to load files from custom paths * Using F5, F6 or F7 can dump the VRAM content on-screen, respectively in 16bpp, 8bpp and 4bpp There are new graphical glitches on the font. In some occasions it appears black. It seems to be related to a flag in `P_TAG.code`. I plan to dig into it when I can render entities on screen to avoid potential mistakes. The same problem is present for the first half of Alucard's portrait. It seems to be related when a texture is transparent? 🤷 I am not sure why the font is completely corrupted when entering in the Equip menu. It is hard to understand if I introduced any regression. Maybe the glitch was always there but it was hidden since I was always forcing the font texture to be rendered. EDIT: Implemented `LoadImage`, `SaveImage` and `ClearImage`
2024-01-01 23:31:56 +00:00
src/pc/sim_pc.c
Add Alucard sprite support (#1272)
2024-06-06 22:11:18 +00:00
src/pc/pl_arc.c
Misc fixes for the test build (#1015) Please refer to the commit title for a comprehensive list of changes. Thanks to @ser-pounce for cracking down `RenderPrimitives`. It is still not matching, but I am submitting anyway as `NON_MATCHING` as the only thing missing is a silly regswap.
2024-02-01 00:04:05 +00:00
src/pc/pl_ric.c
Adding ghost to buildlist (#1764) Adding ghost to build list In order to get the build to work, I needed to mark all of the shared functions between tt_000 and tt_001 as static as it was causing linking issues. Because of this, I needed to combine the two C files for tt_000. Probably want to look at splitting those up into servant specific and shared, but for now, I just wanted to get this working. The issue was msvc didn't like that we were declaring a static function that was not being implemented because part of the shared functions were being implemented in another file. There may be something we can do with function declarations to clean that up if/when we split it again, but I don't know enough about C static functions to figure it out.
2024-10-08 17:56:45 +00:00
src/pc/servant_pc.c
Add blueprint support (#1271) I had to cherry-pick some existing changes from another branch, but that part is tested and working. For the blueprint stuff, I changed the fields from the strings `"TRUE"` and `"FALSE"` to native JSON boolean values `true` and `false`. That made things much easier to parse. The parsing mechanic is straightforward. I'd like to have @bismurphy review on the blueprint parser and asset changes specifically.
2024-06-06 21:21:03 +00:00
src/pc/stages/stage_loader.c
src/pc/stages/stage_dummy.c
Progress towards linking/loading weapons (#1384) This links w_000 and allows the texture to be loaded to vram, as well as the functions executed. g_Cluts was renamed since the stages also have g_Cluts. A macro and preprocessor defines are used to allow unique weapon function names. This doesn't load the animsets since it seems like that stuff is getting redone with the asset manager.
2024-07-10 20:53:04 +00:00
src/pc/weapon_pc.c
Import gte code, candle test button (#1422) This imports the psycross gte code and hooks it up. I added a hotkey to create a candle with a subweapon. As far as I can tell you can't give yourself a subweapon directly without breaking stuff since EntityBreakable and the entity it spawns set up various things. I used this to test the gte. This also fixes a couple of function pointers like CheckCollision to fix the cross animation. This removes a few gte functions we previously implemented in favor of their versions, I'm not sure about the tradeoffs there.
2024-07-22 21:20:01 +00:00
src/pc/psxsdk/PsyCross/src/gte/PsyX_GTE.cpp
src/pc/psxsdk/PsyCross/src/gte/inline_c.c
src/pc/psxsdk/PsyCross/src/gte/libgte_.c
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
)
Reduce _MSC_VER footprint (#896) Reduce the amount of `#ifdef` by abstracting platform specific code into ad-hoc C files that can be linked and swapped. I trimmed down `libapi.c` and used the `My`/`my_` pattern for those specific PSX API calls. The new `plat_unix.c` contains the usual code, while `plat_win.c` contains placeholder functions waiting for an implementation. I have no rush to do so because I have yet to test if the unix version works. I removed from `sotn.c` and `libcard.c` any reference to SDL, which is now self-contained in `sdl2.c`.
2023-12-27 16:26:24 +00:00
if(WIN32)
list(APPEND SOURCE_FILES_PC src/pc/plat_win.c)
else()
list(APPEND SOURCE_FILES_PC src/pc/plat_unix.c)
endif()
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
set(SOURCE_FILES_PSX_SDK
src/main/psxsdk/libgpu/ext.c
Decompile some PSX SDK functions (#1002)
2024-01-21 17:58:32 +00:00
src/main/psxsdk/libgpu/prim.c
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
)
Conditionally compile libsnd (#1335) This makes changes to allow libsnd/libspu to compile when WANT_LIBSND_LLE is set. If turned on it will immediately crash due to trying to write to the SPU. A build is added to make sure it's compiling.
2024-06-18 17:59:51 +00:00
set(WANT_LIBSND_LLE FALSE CACHE BOOL "Whether to append use LLE for libsnd")
if(WANT_LIBSND_LLE)
set(SOURCE_FILES_LIBSND_LLE
# libsnd
src/main/psxsdk/libsnd/adsr.c
src/main/psxsdk/libsnd/cres.c
src/main/psxsdk/libsnd/decre.c
src/main/psxsdk/libsnd/libsnd_i.h
src/main/psxsdk/libsnd/next.c
src/main/psxsdk/libsnd/pause.c
src/main/psxsdk/libsnd/play.c
src/main/psxsdk/libsnd/replay.c
src/main/psxsdk/libsnd/scsmvol.c
src/main/psxsdk/libsnd/scssattr.c
src/main/psxsdk/libsnd/scssvol.c
src/main/psxsdk/libsnd/seqinit.c
src/main/psxsdk/libsnd/seqread.c
src/main/psxsdk/libsnd/seskoff.c
src/main/psxsdk/libsnd/seskon.c
src/main/psxsdk/libsnd/sscall.c
src/main/psxsdk/libsnd/ssclose.c
src/main/psxsdk/libsnd/ssend.c
src/main/psxsdk/libsnd/ssinit.c
src/main/psxsdk/libsnd/ssinit_h.c
src/main/psxsdk/libsnd/ssplay.c
src/main/psxsdk/libsnd/ssquit.c
src/main/psxsdk/libsnd/ssstart.c
src/main/psxsdk/libsnd/sstable.c
src/main/psxsdk/libsnd/sstick.c
src/main/psxsdk/libsnd/ssvol.c
src/main/psxsdk/libsnd/stop.c
src/main/psxsdk/libsnd/tempo.c
src/main/psxsdk/libsnd/ut_gpa.c
src/main/psxsdk/libsnd/ut_gva.c
src/main/psxsdk/libsnd/ut_rdel.c
src/main/psxsdk/libsnd/ut_rdep.c
src/main/psxsdk/libsnd/ut_rev.c
src/main/psxsdk/libsnd/ut_rfb.c
src/main/psxsdk/libsnd/ut_roff.c
src/main/psxsdk/libsnd/ut_ron.c
src/main/psxsdk/libsnd/ut_sva.c
src/main/psxsdk/libsnd/vm_doff.c
src/main/psxsdk/libsnd/vm_don.c
src/main/psxsdk/libsnd/vm_vsu.c
src/main/psxsdk/libsnd/vmanager.c
src/main/psxsdk/libsnd/vs_mono.c
src/main/psxsdk/libsnd/vs_srv.c
src/main/psxsdk/libsnd/vs_vab.c
src/main/psxsdk/libsnd/vs_vfb.c
src/main/psxsdk/libsnd/vs_vh.c
src/main/psxsdk/libsnd/vs_vtb.c
src/main/psxsdk/libsnd/vs_vtbp.c
src/main/psxsdk/libsnd/vs_vtc.c
Use SFX constants (#1403) Open to suggestions for how to break this change up to make it easier to review. The data extraction necessary for naming values in `D_800ACF60` and `D_800ACF84` could be a separate commit... but I'm not sure it's worth it.
2024-07-11 17:03:39 +00:00
Conditionally compile libsnd (#1335) This makes changes to allow libsnd/libspu to compile when WANT_LIBSND_LLE is set. If turned on it will immediately crash due to trying to write to the SPU. A build is added to make sure it's compiling.
2024-06-18 17:59:51 +00:00
# libspu
src/main/psxsdk/libspu/s_cb.c
src/main/psxsdk/libspu/s_crwa.c
src/main/psxsdk/libspu/s_dcb.c
src/main/psxsdk/libspu/s_gva.c
src/main/psxsdk/libspu/s_i.c
src/main/psxsdk/libspu/s_ini.c
src/main/psxsdk/libspu/s_it.c
src/main/psxsdk/libspu/s_itc.c
src/main/psxsdk/libspu/s_m_f.c
src/main/psxsdk/libspu/s_m_init.c
src/main/psxsdk/libspu/s_m_m.c
src/main/psxsdk/libspu/s_m_util.c
src/main/psxsdk/libspu/s_m_wsa.c
src/main/psxsdk/libspu/s_n2p.c
src/main/psxsdk/libspu/s_q.c
src/main/psxsdk/libspu/s_r.c
src/main/psxsdk/libspu/s_sav.c
src/main/psxsdk/libspu/s_sca.c
src/main/psxsdk/libspu/s_si.c
src/main/psxsdk/libspu/s_sic.c
src/main/psxsdk/libspu/s_sk.c
src/main/psxsdk/libspu/s_snv.c
src/main/psxsdk/libspu/s_sr.c
src/main/psxsdk/libspu/s_srmp.c
src/main/psxsdk/libspu/s_stm.c
src/main/psxsdk/libspu/s_stsa.c
src/main/psxsdk/libspu/s_sva.c
src/main/psxsdk/libspu/s_w.c
src/main/psxsdk/libspu/s_wp.c
src/main/psxsdk/libspu/spu.c
src/main/psxsdk/libspu/sr_gaks.c
Enable spu init (#1344) This reworks enough writes to libsnd/libspu to make it through the call to SsInitHot. Instead of raw pointers we have read/write_16 functions. The writes are saved to an array so we can test against output from mednafen. See `src/pc/psxsdk/expected/_spu_init.txt`. The gold file is generated by running a real psx psy-q program that calls the same function. A modified mednafen prints the writes. There are reads to spustat and other regs that require particular values to be returned, so I've also imported and hooked up the SPU part of mednafen.
2024-06-19 16:37:07 +00:00
src/pc/psxsdk/emu.cpp
src/pc/psxsdk/mednafen/spu.cpp
Conditionally compile libsnd (#1335) This makes changes to allow libsnd/libspu to compile when WANT_LIBSND_LLE is set. If turned on it will immediately crash due to trying to write to the SPU. A build is added to make sure it's compiling.
2024-06-18 17:59:51 +00:00
)
list(APPEND SOURCE_FILES_PSX_SDK ${SOURCE_FILES_LIBSND_LLE})
endif()
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
set(SOURCE_FILES_MOCK_SDK
src/pc/psxsdk/libapi.c
src/pc/psxsdk/libetc.c
src/pc/psxsdk/libgpu.c
src/pc/psxsdk/libgte.c
src/pc/psxsdk/libgs.c
src/pc/psxsdk/libcd.c
src/pc/psxsdk/libcard.c
src/pc/psxsdk/libspu.c
src/pc/psxsdk/libsnd.c
src/pc/psxsdk/cdc.c
)
set(SOURCE_FILES_3RD
src/pc/3rd/cJSON/cJSON.c
)
set(SOURCE_FILES_DRA
src/dra/42398.c
src/dra/play.c
src/dra/loading.c
src/dra/pads.c
src/dra/save_mgr_pre.c
src/dra/save_mgr.c
src/dra/4A538.c
src/dra/collider.c
src/dra/demo.c
Add stage dummy (#939) Last test app specific PR for a few days. This adds a dummy stage that gets loaded by `InitStageDummy`. It does very similarly what the game does by copying the exported stage functions into `g_api.o`. The new entrypoint is now `InitRoomEntities`. The dummy stage loads some assets from WRP. The stage layout and tileset are loaded in-memory. I created a very barebone `RenderTilemap` to draw the foreground without any scrolling implemented. I am not sure why the HUD is only showing when entering in the menu and it's black. There is a hack job in the dummy stage to skip the SEL overlay and ask the game to load WRP. Choosing WRP is purely arbitrary as any stage but SEL would result to the same behaviour. This is a bit of a memory hog. I introduced a memory pool instead of using `malloc` for the assets loaded dynamically. The dummy stage will not stay here for long, so I do not find useful to optimise it. <img width="263" alt="image" src="https://github.com/Xeeynamo/sotn-decomp/assets/6128729/4c0c0ed9-ddca-4f5b-a35d-a3fe0f8ababa">
2024-01-02 09:22:44 +00:00
src/dra/5087C.c
SEL config_us.c (#950) Simple PR that aims to re-use the same `config_us` file from #948 but for SEL. The file is de-duplicated since it is identical. The file `lba_stage` has to be split again since in DRA it comes before `config_us` but in SEL it comes after. That indicates it could have been a stand-alone file. I also imported the exp table responsible for levelling up.
2024-01-07 16:41:18 +00:00
src/dra/lba_stage.c
DRA assets config (#948) Creates the file `config_us.c` with all the configuration needed for the game to know where to locate files in the disc (previously `lba_stage.c`), equipments, accessories, menu strings (previously `lang_us.c`, , spells, relics and enemy structures. There is also an exp table for levelling up but I did not import it yet. This is a major change in the codebase on how we handle assets. Previously they were exported as JSON in `assets/dra`. The main problem is that strings were not properly compiled, still relying on hardcoded offsets expected to be found in the `.rodata` section. I deducted all those information belong to a single C file because the same strings in rodata were referenced from equipment to enemies. If those strings are found in the same C file, the compiler will optimise duplicated strings by de-duplicating them. This is how I reached the conclusion of having all those definitions in a single file. Obviously the major pain point of this is that a JSON was much more declarative and easy to be consumed. Especially if tools were going to use those files. Counting the commas with the struct definition on the side is not the best thing for modding. I had to comment out the HD `lba_stage` as it would require a major work to support the Japanese text.
2024-01-07 02:28:34 +00:00
src/dra/config_us.c
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
src/dra/menu.c
Migrate rodata to functions for dra (#1084)
2024-02-25 17:44:11 +00:00
src/dra/5D5BC.c
DRA finish to import all data from US and HD to C files (#1410) with the exception of those three SEQ files, which needs to be handled with the asset manager
2024-07-14 16:35:13 +00:00
src/dra/d_C910.c
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
src/dra/627C4.c
src/dra/63ED4.c
DRA finish to import all data from US and HD to C files (#1410) with the exception of those three SEQ files, which needs to be handled with the asset manager
2024-07-14 16:35:13 +00:00
src/dra/d_CD80.c
Link player-related functions (#983) This hits new functions that can help us to de-fake more symbols with address-sanitizer
2024-01-14 23:30:58 +00:00
src/dra/692E8.c
src/dra/6D59C.c
src/dra/704D0.c
src/dra/71830.c
Link DRA files 72BB0, 7E4BC, 743B0, 86ECC (#1001) And get rid of `Makefile.pc.mk`
2024-01-20 19:06:37 +00:00
src/dra/72BB0.c
Link all DRA files (#1251)
2024-06-03 20:47:30 +00:00
src/dra/75F54.c
Decompile DRA EntityNumberMovesToHPMeter (#1415) This was decompiled by @joshlory , but due to some annoying rodata, I ended up taking over the PR on their behalf and submitting. The file split here was a bit tricky to get right, but now we're matching. I did not do any reviewing of this code, it is presented here as it was made by josh's scratch.
2024-07-17 04:27:16 +00:00
src/dra/78D0C.c
DRA finish to import all data from US and HD to C files (#1410) with the exception of those three SEQ files, which needs to be handled with the asset manager
2024-07-14 16:35:13 +00:00
src/dra/d_CF74.c
Link all DRA files (#1251)
2024-06-03 20:47:30 +00:00
src/dra/7A4D0.c
Link DRA files 72BB0, 7E4BC, 743B0, 86ECC (#1001) And get rid of `Makefile.pc.mk`
2024-01-20 19:06:37 +00:00
src/dra/7E4BC.c
DRA import more data (#1239) Importing some data from `DBD4` with the goal of making the _Sound_ app more accurate. I do not know in which file to put this data into, so I created a file ad-hoc. EDIT: I kept importing more
2024-06-02 18:29:17 +00:00
src/dra/d_DBD4.c
src/dra/d_E294.c
DRA finish to import all data from US and HD to C files (#1410) with the exception of those three SEQ files, which needs to be handled with the asset manager
2024-07-14 16:35:13 +00:00
src/dra/d_10798.c
Link DRA files 72BB0, 7E4BC, 743B0, 86ECC (#1001) And get rid of `Makefile.pc.mk`
2024-01-20 19:06:37 +00:00
src/dra/843B0.c
Decompile DRA EntityStopWatch (#1383) PSX: https://decomp.me/scratch/eMQyN PSP: https://decomp.me/scratch/1Ktyt
2024-07-12 07:32:13 +00:00
src/dra/8A0A4.c
Link all DRA files (#1251)
2024-06-03 20:47:30 +00:00
src/dra/8D3E8.c
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
src/dra/91EBC.c
src/dra/92F60.c
src/dra/93290.c
src/dra/93BDC.c
src/dra/94F50.c
src/dra/953A0.c
DRA import more data (#1239) Importing some data from `DBD4` with the goal of making the _Sound_ app more accurate. I do not know in which file to put this data into, so I created a file ad-hoc. EDIT: I kept importing more
2024-06-02 18:29:17 +00:00
src/dra/d_24CEC.c
DRA import data at 2F324 (#1240) I think those are a bunch of animation indices? I am not yet sure how to represent them as structured data, so there you go having them imported as C files.
2024-06-02 19:37:19 +00:00
src/dra/d_2F324.c
dra data (#1252) Going to do a few files, just getting this on the CI for checking as I go
2024-06-04 00:47:36 +00:00
src/dra/d_3B0D4.c
DRA reorganise BSS section (#1478) A follow-up to #1473 where I imported the whole BSS section by respecting the symbol offset but ignoring their actual type. The work here consists into checking all the almost 500 symbols in DRA one by one. Each type in `bss.c` will be changed to respect the one actually defined in `dra.h` and document the file that actually holds reference to the symbol. If the symbol is only used in one file it will be removed from `dra.h`. Once the work is done I am planning to get rid of `src/dra/bss.c` and have each file to hold the reference. The reason why I created `dra_bss.h` is because when GCC does not order BSS by how they are declared, but when it finds them first in the code. So doing `extern s32 b; s32 a; s32 b;` will order them as `b` then `a`. `dra_bss.h` needs to not be included in `src/dra/bss.c` but all the structs and enums should. Tons of fake symbols have been addressed as part of this PR.
2024-08-08 22:06:26 +00:00
src/dra/bss.c
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
)
compile ric (#1489) This gets RIC compiling, crashes immediately in `func_8015C920` since `g_CurrentEntity` is not set for some reason
2024-08-08 22:12:22 +00:00
set(SOURCE_FILES_RIC
Document Richter overlay (#1513) This is a proposal on how I would like the naming scheme going forward for the player. The proposal includes the naming and layout once we document Alucard and decompile Maria (PSP). Please let's agree on naming and structure so it can be easy to hack and plug new custom characters at any time. * Animations to have `XXX_anim_yyy` where `XXX` is three letters for `arc`, `ric` or `mar` (`arc` taken from `BIN/ARC_F.BIN`). To mark them `static` whenever it is possible to do so. * `PL_S_xxx` to mark a player step. Steps might be similar between the three different players, but they must be isolated into the respective headers `dra.h` for Alucard, `ric.h` for Richter, `mar.h` for Maria. I am aware that Alcuard steps are used in weapons, which is why they are currently found in `game.h`. This needs to be addressed at some point. * PL_T_xxx` for the various timers from `g_Player.D_80072F00`. Those _might_ be need to be shared between all players, we need more research. * `XxxHandleYyy` for the step handlers. You will see `RicHandleJump` to handle `PL_S_JUMP`. * `XxxSetYyy` for the functions responsible of transitioning into a specific step (see `RicSetJump`) Prefer imperative verbs than paste tense or anything else. So `dead` instead of `killed`, `run` instead of `running` and so on. Functions and animations have `Ric` or `ric_` pre-pended since those symbols are publicly exported and not marked as static. But `#define`s and `enum`s that are isolated into the player's header should be generic. I cracked the animation system, so I created the macros `A_END`, `A_LOOP_AT` and so on. In a next pull request I will change `Entity::unk4C` into `Entity::anim`. I did not want to include it here to not change too many files in one go.
2024-08-15 13:57:54 +00:00
src/ric/pl_header.c
compile ric (#1489) This gets RIC compiling, crashes immediately in `func_8015C920` since `g_CurrentEntity` is not set for some reason
2024-08-08 22:12:22 +00:00
src/ric/1AC60.c
src/ric/1FCD0.c
src/ric/20920.c
src/ric/24788.c
src/ric/2A060.c
src/ric/319C4.c
src/ric/spriteparts.c
src/ric/1CB04.c
src/ric/202A8.c
Refactor some stuff with subweapons (#1702) Primary goal here was to eliminate `ext.generic.unkB0`. It turns out that the only entity that reaches up into this unkB0 region is the Subweapon entity. I went through and changed these all to `ext.subweapon.subweaponId`, but also did some analysis on all the uses to make sure this was an accurate change to make. Other highlights: - Naming CheckSubwpnChainLimit and its RIC counterpart - Moving the RIC version of that function to the next file, split makes more sense this way. - Made both versions of that function `static` - renamed subweapondef's unk6 to be chainLimit - Changed g_unkGraphicsStruct.unk0 to be called `pauseEnemies`. It's true when the stopwatch subweapon is used, and in cutscenes. Found this due to looking at the stopwatch subweapon setting this value. Also made it a bool since it's only ever used as a bool. - Added some playersteps enum uses where they were still using hex values - Studied RicEntityStopwatchCrashLightning in order to give it that name I think that's about it. Overall just some modest cleanup, but continues to make the game code more readable.
2024-09-30 20:19:51 +00:00
src/ric/211D0.c
compile ric (#1489) This gets RIC compiling, crashes immediately in `func_8015C920` since `g_CurrentEntity` is not set for some reason
2024-08-08 22:12:22 +00:00
src/ric/26C84.c
src/ric/2C4C4.c
RIC: add more documentation (#1569) I documented all the `PLAYER.step` for Richter and got the meaning of most of the functions with their parameters. There are some additional renaming and magic numbers documented that are not worth to mention individually. I plan to get rid of `EntityTypes` as it is not sustainable to document 256 combination of entities. Instead I am thinking it would be a better approach to document the `g_Entities` indices as ranges. For example from `32` to `47` we have particles, from `48` to `64` we have player entities that can hit the stage entities and so on. I re-organised and re-imported some of the data close to the function that use them. This will allow me to later split entities into their own units as separate C files.
2024-08-24 08:57:53 +00:00
src/ric/e_giant_spinning_cross.c
compile ric (#1489) This gets RIC compiling, crashes immediately in `func_8015C920` since `g_CurrentEntity` is not set for some reason
2024-08-08 22:12:22 +00:00
src/ric/bss.c
src/ric/d_18568.c
RIC: add more documentation (#1569) I documented all the `PLAYER.step` for Richter and got the meaning of most of the functions with their parameters. There are some additional renaming and magic numbers documented that are not worth to mention individually. I plan to get rid of `EntityTypes` as it is not sustainable to document 256 combination of entities. Instead I am thinking it would be a better approach to document the `g_Entities` indices as ranges. For example from `32` to `47` we have particles, from `48` to `64` we have player entities that can hit the stage entities and so on. I re-organised and re-imported some of the data close to the function that use them. This will allow me to later split entities into their own units as separate C files.
2024-08-24 08:57:53 +00:00
src/ric/pl_anims.c
compile ric (#1489) This gets RIC compiling, crashes immediately in `func_8015C920` since `g_CurrentEntity` is not set for some reason
2024-08-08 22:12:22 +00:00
)
Compile and enable bat (#1512)
2024-08-15 00:28:44 +00:00
set(SOURCE_FILES_TT_000
Reorganizing tt_000 to be more in line with tt_001 (#1768) Reorganizing tt_000 to be in line with organization of tt_001 Files that start servant_ are shared data. Files that start bat_ (or ghost_ in the case of tt_001) are specific to that familiar.
2024-10-08 22:33:14 +00:00
src/servant/tt_000/bat.c
src/servant/tt_000/servant_clutdata.c
src/servant/tt_000/bat_animation_data.c
src/servant/tt_000/bat_data.c
src/servant/tt_000/servant_spriteparts.c
src/servant/tt_000/servant_events.c
Compile and enable bat (#1512)
2024-08-15 00:28:44 +00:00
)
Adding ghost to buildlist (#1764) Adding ghost to build list In order to get the build to work, I needed to mark all of the shared functions between tt_000 and tt_001 as static as it was causing linking issues. Because of this, I needed to combine the two C files for tt_000. Probably want to look at splitting those up into servant specific and shared, but for now, I just wanted to get this working. The issue was msvc didn't like that we were declaring a static function that was not being implemented because part of the shared functions were being implemented in another file. There may be something we can do with function declarations to clean that up if/when we split it again, but I don't know enough about C static functions to figure it out.
2024-10-08 17:56:45 +00:00
set(SOURCE_FILES_TT_001
src/servant/tt_001/ghost.c
src/servant/tt_001/servant_clutdata.c
src/servant/tt_001/ghost_animation_data.c
src/servant/tt_001/ghost_data.c
src/servant/tt_001/servant_spriteparts.c
Reorganizing tt_000 to be more in line with tt_001 (#1768) Reorganizing tt_000 to be in line with organization of tt_001 Files that start servant_ are shared data. Files that start bat_ (or ghost_ in the case of tt_001) are specific to that familiar.
2024-10-08 22:33:14 +00:00
src/servant/tt_001/servant_events.c
Adding ghost to buildlist (#1764) Adding ghost to build list In order to get the build to work, I needed to mark all of the shared functions between tt_000 and tt_001 as static as it was causing linking issues. Because of this, I needed to combine the two C files for tt_000. Probably want to look at splitting those up into servant specific and shared, but for now, I just wanted to get this working. The issue was msvc didn't like that we were declaring a static function that was not being implemented because part of the shared functions were being implemented in another file. There may be something we can do with function declarations to clean that up if/when we split it again, but I don't know enough about C static functions to figure it out.
2024-10-08 17:56:45 +00:00
)
Link stage SEL (#963) This depends from #962 . Without `func_800EA7CC` being decompiled, past the title screen you will be welcomed with a black screen. Using the [non matching scratch](https://decomp.me/scratch/dlQDD) will work. The input works regardless the black screen. Getting past the name selection screen there is a crash at `SetReleaseRate1` due to `D_80138FB4` being `NULL`. Getting past it you will get another crash at `HandleVideoPlayback` but I neither investigated on it or tried what's beyond that. There is a divergence between the Make and CMake. For some reason the build from CMake gives a black screen. I am not able to detect where the issue is. I get no warnings or errors. I noticed `g_MegaMenuStrBuffer` gets full much faster in the CMake build. It might due to a silly size of any of the atomic C types. It needs further investigation.
2024-01-11 20:13:33 +00:00
set(SOURCE_FILES_STAGE_SEL
Add blueprint support (#1271) I had to cherry-pick some existing changes from another branch, but that part is tested and working. For the blueprint stuff, I changed the fields from the strings `"TRUE"` and `"FALSE"` to native JSON boolean values `true` and `false`. That made things much easier to parse. The parsing mechanic is straightforward. I'd like to have @bismurphy review on the blueprint parser and asset changes specifically.
2024-06-06 21:21:03 +00:00
src/pc/stages/stage_sel.c
Link stage SEL (#963) This depends from #962 . Without `func_800EA7CC` being decompiled, past the title screen you will be welcomed with a black screen. Using the [non matching scratch](https://decomp.me/scratch/dlQDD) will work. The input works regardless the black screen. Getting past the name selection screen there is a crash at `SetReleaseRate1` due to `D_80138FB4` being `NULL`. Getting past it you will get another crash at `HandleVideoPlayback` but I neither investigated on it or tried what's beyond that. There is a divergence between the Make and CMake. For some reason the build from CMake gives a black screen. I am not able to detect where the issue is. I get no warnings or errors. I noticed `g_MegaMenuStrBuffer` gets full much faster in the CMake build. It might due to a silly size of any of the atomic C types. It needs further investigation.
2024-01-11 20:13:33 +00:00
src/st/sel/banks.c
src/st/sel/CD54.c
src/st/sel/2C048.c
src/st/sel/33164.c
src/st/sel/3410C.c
src/st/sel/3585C.c
Extract cutscene scripts, portraits and normalize code (#1686) More research on how cutscenes work. I normalized all the various C files as `cutscene.c`, marked all the isolated function as `static` and renamed the main entity as `{STAGE}_CutsceneExec` (e.g. `CEN_CutsceneExec`). I am using the `OVL_EXPORT` to automate the names. TO-DO: - [x] Rename entity as `{STAGE}_EntityCutscene` for consistency - [x] CEN - [x] DRE - [x] NO3 - [x] NZ0 - [x] ST0 - [x] MAR ~~SEL~~ The offset of the portrait data seems to be hardcoded. I have no idea how to resolve these offsets at compilation time. The entire cutscene script thing is very sketchy and horribly designed by the original developers. What a nightmare to integrate into our project. This is how a cutscene script gets decompiled: ``` LOAD_PORTRAIT(0x80188D8C, 0), SET_PORTRAIT(1, 0), SCRIPT_UNKNOWN_11(), PLAY_SOUND(0x37B), WAIT_FOR_SOUND(), SET_SPEED(4), 'T','h','a','t',' ','v','o','i','c','e','!',' ', SET_WAIT(16), SET_SPEED(3), 'A','l','u','c','a','r','d',',', LINE_BREAK(), SET_WAIT(16), SET_FLAG(2), 'i','t','\'','s',' ','y','o','u','!', SET_WAIT(48), NEXT_DIALOG(), ```
2024-09-29 02:56:35 +00:00
src/st/sel/cutscene.c
Link stage SEL (#963) This depends from #962 . Without `func_800EA7CC` being decompiled, past the title screen you will be welcomed with a black screen. Using the [non matching scratch](https://decomp.me/scratch/dlQDD) will work. The input works regardless the black screen. Getting past the name selection screen there is a crash at `SetReleaseRate1` due to `D_80138FB4` being `NULL`. Getting past it you will get another crash at `HandleVideoPlayback` but I neither investigated on it or tried what's beyond that. There is a divergence between the Make and CMake. For some reason the build from CMake gives a black screen. I am not able to detect where the issue is. I get no warnings or errors. I noticed `g_MegaMenuStrBuffer` gets full much faster in the CMake build. It might due to a silly size of any of the atomic C types. It needs further investigation.
2024-01-11 20:13:33 +00:00
)
CEN cutscene parser (#1680) `CutsceneUnk2` uses 8 prims but only 7 are allocated. It looks like at some point the game writes to the address `0x00000000` but I did not confirm it with a PS1 debugger. This is a potential bug. `CutsceneUnk2` signature was also wrong. I had to get rid of `GfxBank` in `src/st/cen/header.c` and I probably need to do the same for the other header files. The code reads chunks of WORDS at the time and a structure would be too large to include `GFX_TERMINATE` in it. CEN is there but not linked because it conflicts with some WRP symbols. I decided to take a much simpler approach compared to what I did with WRP (which needs to be refactored later on). There's a cutscene parser. The asset manager is exporting it to `src/st/cen/cutscene_data.h` if you want to have a look. I know I am still using `config/assets.us.weapon.yaml` and it probably needs to be renamed as `config/assets.us.yaml` later on. I am still deciding.
2024-09-27 22:13:29 +00:00
set(SOURCE_FILES_STAGE_CEN
src/pc/stages/stage_cen.c
src/st/cen/header.c
src/st/cen/e_laydef.c
src/st/cen/e_init.c
src/st/cen/rooms.c
src/st/cen/e_layout.c
src/st/cen/cutscene_data.c
src/st/cen/tile_data.c
src/st/cen/sprites.c
src/st/cen/st_debug.c
src/st/cen/e_breakable.c
src/st/cen/DB18.c
Extract cutscene scripts, portraits and normalize code (#1686) More research on how cutscenes work. I normalized all the various C files as `cutscene.c`, marked all the isolated function as `static` and renamed the main entity as `{STAGE}_CutsceneExec` (e.g. `CEN_CutsceneExec`). I am using the `OVL_EXPORT` to automate the names. TO-DO: - [x] Rename entity as `{STAGE}_EntityCutscene` for consistency - [x] CEN - [x] DRE - [x] NO3 - [x] NZ0 - [x] ST0 - [x] MAR ~~SEL~~ The offset of the portrait data seems to be hardcoded. I have no idea how to resolve these offsets at compilation time. The entire cutscene script thing is very sketchy and horribly designed by the original developers. What a nightmare to integrate into our project. This is how a cutscene script gets decompiled: ``` LOAD_PORTRAIT(0x80188D8C, 0), SET_PORTRAIT(1, 0), SCRIPT_UNKNOWN_11(), PLAY_SOUND(0x37B), WAIT_FOR_SOUND(), SET_SPEED(4), 'T','h','a','t',' ','v','o','i','c','e','!',' ', SET_WAIT(16), SET_SPEED(3), 'A','l','u','c','a','r','d',',', LINE_BREAK(), SET_WAIT(16), SET_FLAG(2), 'i','t','\'','s',' ','y','o','u','!', SET_WAIT(48), NEXT_DIALOG(), ```
2024-09-29 02:56:35 +00:00
src/st/cen/cutscene.c
CEN cutscene parser (#1680) `CutsceneUnk2` uses 8 prims but only 7 are allocated. It looks like at some point the game writes to the address `0x00000000` but I did not confirm it with a PS1 debugger. This is a potential bug. `CutsceneUnk2` signature was also wrong. I had to get rid of `GfxBank` in `src/st/cen/header.c` and I probably need to do the same for the other header files. The code reads chunks of WORDS at the time and a structure would be too large to include `GFX_TERMINATE` in it. CEN is there but not linked because it conflicts with some WRP symbols. I decided to take a much simpler approach compared to what I did with WRP (which needs to be refactored later on). There's a cutscene parser. The asset manager is exporting it to `src/st/cen/cutscene_data.h` if you want to have a look. I know I am still using `config/assets.us.weapon.yaml` and it probably needs to be renamed as `config/assets.us.yaml` later on. I am still deciding.
2024-09-27 22:13:29 +00:00
src/st/cen/F890.c
src/st/cen/st_update.c
src/st/cen/collision.c
src/st/cen/create_entity.c
src/st/cen/e_red_door.c
src/st/cen/st_common.c
src/st/cen/e_collect.c
src/st/cen/blit_char.c
src/st/cen/e_misc.c
src/st/cen/e_stage_name.c
src/st/cen/e_particles.c
src/st/cen/e_room_fg.c
src/st/cen/popup.c
src/st/cen/prim_helpers.c
src/st/cen/header.c
src/st/cen/create_entity.c
Extract cutscene scripts, portraits and normalize code (#1686) More research on how cutscenes work. I normalized all the various C files as `cutscene.c`, marked all the isolated function as `static` and renamed the main entity as `{STAGE}_CutsceneExec` (e.g. `CEN_CutsceneExec`). I am using the `OVL_EXPORT` to automate the names. TO-DO: - [x] Rename entity as `{STAGE}_EntityCutscene` for consistency - [x] CEN - [x] DRE - [x] NO3 - [x] NZ0 - [x] ST0 - [x] MAR ~~SEL~~ The offset of the portrait data seems to be hardcoded. I have no idea how to resolve these offsets at compilation time. The entire cutscene script thing is very sketchy and horribly designed by the original developers. What a nightmare to integrate into our project. This is how a cutscene script gets decompiled: ``` LOAD_PORTRAIT(0x80188D8C, 0), SET_PORTRAIT(1, 0), SCRIPT_UNKNOWN_11(), PLAY_SOUND(0x37B), WAIT_FOR_SOUND(), SET_SPEED(4), 'T','h','a','t',' ','v','o','i','c','e','!',' ', SET_WAIT(16), SET_SPEED(3), 'A','l','u','c','a','r','d',',', LINE_BREAK(), SET_WAIT(16), SET_FLAG(2), 'i','t','\'','s',' ','y','o','u','!', SET_WAIT(48), NEXT_DIALOG(), ```
2024-09-29 02:56:35 +00:00
src/st/cen/cutscene.c
CEN cutscene parser (#1680) `CutsceneUnk2` uses 8 prims but only 7 are allocated. It looks like at some point the game writes to the address `0x00000000` but I did not confirm it with a PS1 debugger. This is a potential bug. `CutsceneUnk2` signature was also wrong. I had to get rid of `GfxBank` in `src/st/cen/header.c` and I probably need to do the same for the other header files. The code reads chunks of WORDS at the time and a structure would be too large to include `GFX_TERMINATE` in it. CEN is there but not linked because it conflicts with some WRP symbols. I decided to take a much simpler approach compared to what I did with WRP (which needs to be refactored later on). There's a cutscene parser. The asset manager is exporting it to `src/st/cen/cutscene_data.h` if you want to have a look. I know I am still using `config/assets.us.weapon.yaml` and it probably needs to be renamed as `config/assets.us.yaml` later on. I am still deciding.
2024-09-27 22:13:29 +00:00
src/st/cen/e_collect.c
)
Link WRP (#1305) I think this is pretty much ready to be merged it. I do not see much of a point of having the branch floating around. I am using a `#ifndef HARD_LINK` to avoid compiling duplicate functions with the same symbol name. For data with the same symbol name but different content I am doing a `#define OVL_EXPORT(x) WRP_##x`. So for example `OVL_EXPORT(g_EntityGfx)` will be expanded as `WRP_g_EntityGfx`. It is an unfortunate hack. On the other hand all the data migration allowed me to mark most of the data and functions as `static`. If we use the same approach on other overlays we could easily statically link them as well. SEL is enabled by default. It will take you straight to the real WRP, not the dummy one. Most of the changes are loading assets from their respective JSON files. Linking the stage was pretty straight forward.
2024-06-12 21:03:56 +00:00
set(SOURCE_FILES_STAGE_WRP
src/pc/stages/stage_wrp.c
Modernize headers (#1743) Extract some commits out of #1701 and avoid the part that will lead to a build failure (fixed in #1738). Now every header uses `OVL_EXPORT`.
2024-10-10 20:37:25 +00:00
src/st/wrp/header.c
New asset manager (#1343) This aims to deprecate all the Splat tools in `tools/splat_ext` in favour of a more centralised asset manager. This brings the following advantages: * Much faster extraction * Faster build * Automatically define `static` symbols or unique names whenever `static` is not possible * Allow to embed assets into the output binary * Drastically simplify `Makefile` by removing all the asset build rules * Avoid situations where it is not possible to extract and build assets that is not 4-byte aligned This is achieved by having the splat YAML targeting a normal C file as data and have an external tool to take care of the following: 1. Extract asset files straight from the overlay binary file into human readable file in `assets/st/STAGE_NAME` 2. Build assets as header files that go into `src/st/STAGE_NAME` to just include them from any C file This requires each stage header to have the following new format: please see `src/st/nz0/header.c` Built assets in `src/st` are ignored by Git. As for now, for simplicity sake, the steps `make extract_assets` and `make build_assets` are just executed within `make extract` exclusively for the US version. I plan to auto-generate files such as `src/st/nz0/tile_data.c`. For a first iteration I am aiming to handle the following: * [X] Extract rooms: `assets/st/*/rooms.json` * [X] Extract room layers: `assets/st/*/entity_layouts.json` * [X] Extract tilemap data: `assets/st/*/tilemap_*.bin` * [X] Extract tilemap definitions: `assets/st/*/tiledef_*.json` * [X] Extract sprites: `assets/st/*/sprites.json` * [x] Extract entity layouts * [X] Build rooms: `src/st/*/rooms.h` * [X] Build room layers: `src/st/*/layers.h` * [X] Build tilemap data: `src/st/*/tilemap_*.h` * [X] Build tilemap definitions: `src/st/*/tiledef_*.h` * [x] Build sprites (aka `g_SpriteBanks`) * [x] Build entity layouts * [x] Allow the tool to suggest how to adjust the Splat config for each overlay I want the tool to cover the following stages: * [x] CEN * [x] DRE * ~MAD~ I do not think this can be done, it is way too different from the other overlays * [x] NO3 * [x] NP3 * [X] NZ0 * [x] ST0 * [X] WRP * [x] RWRP * ~WRP (PSP)~ Maybe in a follow-up PR For a later iteration I plan on extracting and build: * Entity GFX thingie * The CLUT thingie in the header * Uncompressed GFX data * Cutscene data * Blueprints * The `src/config_us.h` thingie --------- Co-authored-by: Josh Lory <josh.lory@outlook.com>
2024-07-02 20:38:36 +00:00
src/st/wrp/e_laydef.c
Merge RWRP with WRP (#1425) This will decompile all the functions but the new `EntityRWarpRoom` from the RWRP overlay. Note that as `e_misc.c` has a function with a different castle flag, I had to use a shared header. Everything else was identical. --------- Co-authored-by: bismurphy <tjmurphy@mit.edu>
2024-07-22 14:57:21 +00:00
src/st/wrp/e_init.c
Link WRP (#1305) I think this is pretty much ready to be merged it. I do not see much of a point of having the branch floating around. I am using a `#ifndef HARD_LINK` to avoid compiling duplicate functions with the same symbol name. For data with the same symbol name but different content I am doing a `#define OVL_EXPORT(x) WRP_##x`. So for example `OVL_EXPORT(g_EntityGfx)` will be expanded as `WRP_g_EntityGfx`. It is an unfortunate hack. On the other hand all the data migration allowed me to mark most of the data and functions as `static`. If we use the same approach on other overlays we could easily statically link them as well. SEL is enabled by default. It will take you straight to the real WRP, not the dummy one. Most of the changes are loading assets from their respective JSON files. Linking the stage was pretty straight forward.
2024-06-12 21:03:56 +00:00
src/st/wrp/st_debug.c
src/st/wrp/e_breakable.c
src/st/wrp/d_608.c
New asset manager (#1343) This aims to deprecate all the Splat tools in `tools/splat_ext` in favour of a more centralised asset manager. This brings the following advantages: * Much faster extraction * Faster build * Automatically define `static` symbols or unique names whenever `static` is not possible * Allow to embed assets into the output binary * Drastically simplify `Makefile` by removing all the asset build rules * Avoid situations where it is not possible to extract and build assets that is not 4-byte aligned This is achieved by having the splat YAML targeting a normal C file as data and have an external tool to take care of the following: 1. Extract asset files straight from the overlay binary file into human readable file in `assets/st/STAGE_NAME` 2. Build assets as header files that go into `src/st/STAGE_NAME` to just include them from any C file This requires each stage header to have the following new format: please see `src/st/nz0/header.c` Built assets in `src/st` are ignored by Git. As for now, for simplicity sake, the steps `make extract_assets` and `make build_assets` are just executed within `make extract` exclusively for the US version. I plan to auto-generate files such as `src/st/nz0/tile_data.c`. For a first iteration I am aiming to handle the following: * [X] Extract rooms: `assets/st/*/rooms.json` * [X] Extract room layers: `assets/st/*/entity_layouts.json` * [X] Extract tilemap data: `assets/st/*/tilemap_*.bin` * [X] Extract tilemap definitions: `assets/st/*/tiledef_*.json` * [X] Extract sprites: `assets/st/*/sprites.json` * [x] Extract entity layouts * [X] Build rooms: `src/st/*/rooms.h` * [X] Build room layers: `src/st/*/layers.h` * [X] Build tilemap data: `src/st/*/tilemap_*.h` * [X] Build tilemap definitions: `src/st/*/tiledef_*.h` * [x] Build sprites (aka `g_SpriteBanks`) * [x] Build entity layouts * [x] Allow the tool to suggest how to adjust the Splat config for each overlay I want the tool to cover the following stages: * [x] CEN * [x] DRE * ~MAD~ I do not think this can be done, it is way too different from the other overlays * [x] NO3 * [x] NP3 * [X] NZ0 * [x] ST0 * [X] WRP * [x] RWRP * ~WRP (PSP)~ Maybe in a follow-up PR For a later iteration I plan on extracting and build: * Entity GFX thingie * The CLUT thingie in the header * Uncompressed GFX data * Cutscene data * Blueprints * The `src/config_us.h` thingie --------- Co-authored-by: Josh Lory <josh.lory@outlook.com>
2024-07-02 20:38:36 +00:00
src/st/wrp/rooms.c
src/st/wrp/e_layout.c
src/st/wrp/tile_data.c
src/st/wrp/sprites.c
Link WRP (#1305) I think this is pretty much ready to be merged it. I do not see much of a point of having the branch floating around. I am using a `#ifndef HARD_LINK` to avoid compiling duplicate functions with the same symbol name. For data with the same symbol name but different content I am doing a `#define OVL_EXPORT(x) WRP_##x`. So for example `OVL_EXPORT(g_EntityGfx)` will be expanded as `WRP_g_EntityGfx`. It is an unfortunate hack. On the other hand all the data migration allowed me to mark most of the data and functions as `static`. If we use the same approach on other overlays we could easily statically link them as well. SEL is enabled by default. It will take you straight to the real WRP, not the dummy one. Most of the changes are loading assets from their respective JSON files. Linking the stage was pretty straight forward.
2024-06-12 21:03:56 +00:00
src/st/wrp/warp.c
src/st/wrp/st_update.c
src/st/wrp/collision.c
src/st/wrp/create_entity.c
src/st/wrp/e_red_door.c
src/st/wrp/st_common.c
src/st/wrp/e_collect.c
src/st/wrp/blit_char.c
src/st/wrp/e_misc.c
src/st/wrp/e_stage_name.c
src/st/wrp/e_particles.c
src/st/wrp/e_room_fg.c
src/st/wrp/popup.c
src/st/wrp/prim_helpers.c
Decompile WRP BSS (#1337) Move BSS definitions to code. This is the last of the ASM configured for WRP. --------- Co-authored-by: Jonathan Hohle <jon@ttkb.co>
2024-06-18 23:01:03 +00:00
src/st/wrp/bss.c
Link WRP (#1305) I think this is pretty much ready to be merged it. I do not see much of a point of having the branch floating around. I am using a `#ifndef HARD_LINK` to avoid compiling duplicate functions with the same symbol name. For data with the same symbol name but different content I am doing a `#define OVL_EXPORT(x) WRP_##x`. So for example `OVL_EXPORT(g_EntityGfx)` will be expanded as `WRP_g_EntityGfx`. It is an unfortunate hack. On the other hand all the data migration allowed me to mark most of the data and functions as `static`. If we use the same approach on other overlays we could easily statically link them as well. SEL is enabled by default. It will take you straight to the real WRP, not the dummy one. Most of the changes are loading assets from their respective JSON files. Linking the stage was pretty straight forward.
2024-06-12 21:03:56 +00:00
)
Progress towards linking/loading weapons (#1384) This links w_000 and allows the texture to be loaded to vram, as well as the functions executed. g_Cluts was renamed since the stages also have g_Cluts. A macro and preprocessor defines are used to allow unique weapon function names. This doesn't load the animsets since it seems like that stuff is getting redone with the asset manager.
2024-07-10 20:53:04 +00:00
set(SOURCE_FILES_WEAPON
src/weapon/w_000.c
Import w_002 data and link overlay (#1493) This PR aims to be a blueprint to what needs to be done for the remaining 56 weapon overlays
2024-08-09 16:53:10 +00:00
src/weapon/w_002.c
Finish w_007 and import data (#1539) https://decomp.me/scratch/Zn2uO
2024-08-18 21:52:32 +00:00
src/weapon/w_007.c
Finish two related files: w_012 and w_034 (#1549) * https://decomp.me/scratch/h62LS * https://decomp.me/scratch/FhCre * https://decomp.me/scratch/N3tj5
2024-08-20 05:00:58 +00:00
src/weapon/w_012.c
src/weapon/w_034.c
Import data for w_041 and link (#1546) Also links `w_052` which I missed in https://github.com/Xeeynamo/sotn-decomp/pull/1524
2024-08-19 17:51:24 +00:00
src/weapon/w_041.c
Finish w_045 and import data (#1521) Unfortunately this build will fail until the fix is merged to decouple `func_ptr_*` signatures. * [func_ptr_80170004_w_045](https://decomp.me/scratch/OmJXk) * [func_ptr_8017000C_w_045](https://decomp.me/scratch/c5Qrm)
2024-08-18 08:22:14 +00:00
src/weapon/w_045.c
Finish w_046 and import data (#1511) https://decomp.me/scratch/dKGxs https://decomp.me/scratch/YGyQp
2024-08-15 21:36:06 +00:00
src/weapon/w_046.c
Link w_051 (#1520)
2024-08-16 02:47:21 +00:00
src/weapon/w_051.c
Import data for w_041 and link (#1546) Also links `w_052` which I missed in https://github.com/Xeeynamo/sotn-decomp/pull/1524
2024-08-19 17:51:24 +00:00
src/weapon/w_052.c
Progress towards linking/loading weapons (#1384) This links w_000 and allows the texture to be loaded to vram, as well as the functions executed. g_Cluts was renamed since the stages also have g_Cluts. A macro and preprocessor defines are used to allow unique weapon function names. This doesn't load the animsets since it seems like that stuff is getting redone with the asset manager.
2024-07-10 20:53:04 +00:00
)
# WEAPON_ID needs to be a string and not just a number
set_source_files_properties(src/weapon/w_000.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_000)
Import w_002 data and link overlay (#1493) This PR aims to be a blueprint to what needs to be done for the remaining 56 weapon overlays
2024-08-09 16:53:10 +00:00
set_source_files_properties(src/weapon/w_002.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_002)
Finish w_007 and import data (#1539) https://decomp.me/scratch/Zn2uO
2024-08-18 21:52:32 +00:00
set_source_files_properties(src/weapon/w_007.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_007)
Finish two related files: w_012 and w_034 (#1549) * https://decomp.me/scratch/h62LS * https://decomp.me/scratch/FhCre * https://decomp.me/scratch/N3tj5
2024-08-20 05:00:58 +00:00
set_source_files_properties(src/weapon/w_012.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_012)
set_source_files_properties(src/weapon/w_034.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_034)
Import data for w_041 and link (#1546) Also links `w_052` which I missed in https://github.com/Xeeynamo/sotn-decomp/pull/1524
2024-08-19 17:51:24 +00:00
set_source_files_properties(src/weapon/w_041.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_041)
Finish w_045 and import data (#1521) Unfortunately this build will fail until the fix is merged to decouple `func_ptr_*` signatures. * [func_ptr_80170004_w_045](https://decomp.me/scratch/OmJXk) * [func_ptr_8017000C_w_045](https://decomp.me/scratch/c5Qrm)
2024-08-18 08:22:14 +00:00
set_source_files_properties(src/weapon/w_045.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_045)
Finish w_046 and import data (#1511) https://decomp.me/scratch/dKGxs https://decomp.me/scratch/YGyQp
2024-08-15 21:36:06 +00:00
set_source_files_properties(src/weapon/w_046.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_046)
Link w_051 (#1520)
2024-08-16 02:47:21 +00:00
set_source_files_properties(src/weapon/w_051.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_051)
Import data for w_041 and link (#1546) Also links `w_052` which I missed in https://github.com/Xeeynamo/sotn-decomp/pull/1524
2024-08-19 17:51:24 +00:00
set_source_files_properties(src/weapon/w_052.c PROPERTIES COMPILE_DEFINITIONS WEAPON_ID=w_052)
Progress towards linking/loading weapons (#1384) This links w_000 and allows the texture to be loaded to vram, as well as the functions executed. g_Cluts was renamed since the stages also have g_Cluts. A macro and preprocessor defines are used to allow unique weapon function names. This doesn't load the animsets since it seems like that stuff is getting redone with the asset manager.
2024-07-10 20:53:04 +00:00
Null backend (#900) This implements a null backend without SDL2 that can be run in CI and also serve to show what the current platform-agnostic API is. There is a core library, which is DRA and the pc supporting code, and two targets, the SDL2 target, and the null one. null.c is the API that has to be implemented to make a new target. Since main is an infinite loop I added a little code to make it exit after 60 frames. I don't know what is wrong with the headers in null.c.
2024-01-19 02:32:22 +00:00
# organization is:
# two executables, sdl2 and null, plus a shared library "core"
# any executable links core (which is pc shared code + sotn psx code)
# the null backend is present to try and help with developing a backend-agnostic interface
# and for a basic "does it segfault" check in CI
# core library
set(SOURCE_FILES_CORE
${SOURCE_FILES_DRA}
compile ric (#1489) This gets RIC compiling, crashes immediately in `func_8015C920` since `g_CurrentEntity` is not set for some reason
2024-08-08 22:12:22 +00:00
${SOURCE_FILES_RIC}
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
${SOURCE_FILES_PC}
${SOURCE_FILES_PSX_SDK}
${SOURCE_FILES_MOCK_SDK}
${SOURCE_FILES_3RD}
Link stage SEL (#963) This depends from #962 . Without `func_800EA7CC` being decompiled, past the title screen you will be welcomed with a black screen. Using the [non matching scratch](https://decomp.me/scratch/dlQDD) will work. The input works regardless the black screen. Getting past the name selection screen there is a crash at `SetReleaseRate1` due to `D_80138FB4` being `NULL`. Getting past it you will get another crash at `HandleVideoPlayback` but I neither investigated on it or tried what's beyond that. There is a divergence between the Make and CMake. For some reason the build from CMake gives a black screen. I am not able to detect where the issue is. I get no warnings or errors. I noticed `g_MegaMenuStrBuffer` gets full much faster in the CMake build. It might due to a silly size of any of the atomic C types. It needs further investigation.
2024-01-11 20:13:33 +00:00
${SOURCE_FILES_STAGE_SEL}
Link WRP (#1305) I think this is pretty much ready to be merged it. I do not see much of a point of having the branch floating around. I am using a `#ifndef HARD_LINK` to avoid compiling duplicate functions with the same symbol name. For data with the same symbol name but different content I am doing a `#define OVL_EXPORT(x) WRP_##x`. So for example `OVL_EXPORT(g_EntityGfx)` will be expanded as `WRP_g_EntityGfx`. It is an unfortunate hack. On the other hand all the data migration allowed me to mark most of the data and functions as `static`. If we use the same approach on other overlays we could easily statically link them as well. SEL is enabled by default. It will take you straight to the real WRP, not the dummy one. Most of the changes are loading assets from their respective JSON files. Linking the stage was pretty straight forward.
2024-06-12 21:03:56 +00:00
${SOURCE_FILES_STAGE_WRP}
Progress towards linking/loading weapons (#1384) This links w_000 and allows the texture to be loaded to vram, as well as the functions executed. g_Cluts was renamed since the stages also have g_Cluts. A macro and preprocessor defines are used to allow unique weapon function names. This doesn't load the animsets since it seems like that stuff is getting redone with the asset manager.
2024-07-10 20:53:04 +00:00
${SOURCE_FILES_WEAPON}
Compile and enable bat (#1512)
2024-08-15 00:28:44 +00:00
${SOURCE_FILES_TT_000}
Adding ghost to buildlist (#1764) Adding ghost to build list In order to get the build to work, I needed to mark all of the shared functions between tt_000 and tt_001 as static as it was causing linking issues. Because of this, I needed to combine the two C files for tt_000. Probably want to look at splitting those up into servant specific and shared, but for now, I just wanted to get this working. The issue was msvc didn't like that we were declaring a static function that was not being implemented because part of the shared functions were being implemented in another file. There may be something we can do with function declarations to clean that up if/when we split it again, but I don't know enough about C static functions to figure it out.
2024-10-08 17:56:45 +00:00
${SOURCE_FILES_TT_001}
Link stage SEL (#963) This depends from #962 . Without `func_800EA7CC` being decompiled, past the title screen you will be welcomed with a black screen. Using the [non matching scratch](https://decomp.me/scratch/dlQDD) will work. The input works regardless the black screen. Getting past the name selection screen there is a crash at `SetReleaseRate1` due to `D_80138FB4` being `NULL`. Getting past it you will get another crash at `HandleVideoPlayback` but I neither investigated on it or tried what's beyond that. There is a divergence between the Make and CMake. For some reason the build from CMake gives a black screen. I am not able to detect where the issue is. I get no warnings or errors. I noticed `g_MegaMenuStrBuffer` gets full much faster in the CMake build. It might due to a silly size of any of the atomic C types. It needs further investigation.
2024-01-11 20:13:33 +00:00
)
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
Null backend (#900) This implements a null backend without SDL2 that can be run in CI and also serve to show what the current platform-agnostic API is. There is a core library, which is DRA and the pc supporting code, and two targets, the SDL2 target, and the null one. null.c is the API that has to be implemented to make a new target. Since main is an infinite loop I added a little code to make it exit after 60 frames. I don't know what is wrong with the headers in null.c.
2024-01-19 02:32:22 +00:00
add_library(core ${SOURCE_FILES_CORE})
target_include_directories(core PRIVATE
include
src/dra
src/pc/3rd
)
Migrate rodata to functions for dra (#1084)
2024-02-25 17:44:11 +00:00
target_compile_definitions(core PRIVATE
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
_USE_MATH_DEFINES # needed for msvc
Null backend (#900) This implements a null backend without SDL2 that can be run in CI and also serve to show what the current platform-agnostic API is. There is a core library, which is DRA and the pc supporting code, and two targets, the SDL2 target, and the null one. null.c is the API that has to be implemented to make a new target. Since main is an infinite loop I added a little code to make it exit after 60 frames. I don't know what is wrong with the headers in null.c.
2024-01-19 02:32:22 +00:00
VERSION_PC
PERMUTER
NON_MATCHING
HARD_LINK
DEMO_KEY_PTR=0
_internal_version_us
)
# sdl2 target
add_executable(${PROJECT_NAME}
src/pc/sdl2.c
Add software rendering (#1407) This takes the GPU from Mednafen and hooks it up by using parts of libgpu and writing to the fifo. I avoid using DMA and just write directly and it seems to work fine. This means that the OTAG part isn't required since that's part of the DMA system and not the GPU apparently. The main bug I'm aware of is the TILE that fades to white in the warp room doesn't show up. The GL renderer is still available. I made the software renderer the default since it's faster and more accurate on average. The two renderers can be toggled with F8. I turned on linear logs by default since it's significantly faster. The biggest gap I'm aware of is PutDispEnv needs to be properly decompiled and hooked up.
2024-07-14 09:00:15 +00:00
src/pc/render_soft.c
src/pc/render_shared.c
src/pc/render_gl.c
src/pc/psxsdk/mednafen/gpu.cpp
src/pc/psxsdk/mednafen/gpu_line.cpp
src/pc/psxsdk/mednafen/gpu_polygon.cpp
src/pc/psxsdk/mednafen/gpu_sprite.cpp
Tetra spirit fixes, macro system (#1413) This adds some fixes to get tetra spirit mostly working. It copies part of the framebuffer with MoveImage to warp it, so that's added. Right now there's some bugs with DrawEnv or DispEnv stuff so that the copy is from the wrong place every other frame and shows as black. There's a couple of out of bound issues that have speculative fixes I'm not sure about. The spells are hard for me to do so I added a macro/hotkey system to be able to test them quickly. I tried calling the spell functions directly but they didn't work right. I think there's probably code scattered around to support them so doing the inputs is the only way to activate it all correctly
2024-07-17 22:13:17 +00:00
src/pc/sdl2_macros.c
Null backend (#900) This implements a null backend without SDL2 that can be run in CI and also serve to show what the current platform-agnostic API is. There is a core library, which is DRA and the pc supporting code, and two targets, the SDL2 target, and the null one. null.c is the API that has to be implemented to make a new target. Since main is an infinite loop I added a little code to make it exit after 60 frames. I don't know what is wrong with the headers in null.c.
2024-01-19 02:32:22 +00:00
)
target_include_directories(${PROJECT_NAME} PRIVATE
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
${SDL2_INCLUDE_DIRS}
include
src/dra
src/pc/3rd
)
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
if (WIN32)
Migrate rodata to functions for dra (#1084)
2024-02-25 17:44:11 +00:00
target_link_libraries(${PROJECT_NAME} PRIVATE
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
${SDL2_LIBRARIES} core)
else()
Migrate rodata to functions for dra (#1084)
2024-02-25 17:44:11 +00:00
target_link_libraries(${PROJECT_NAME} PRIVATE
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
${SDL2_LIBRARIES} core m)
endif()
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
Conditionally compile libsnd (#1335) This makes changes to allow libsnd/libspu to compile when WANT_LIBSND_LLE is set. If turned on it will immediately crash due to trying to write to the SPU. A build is added to make sure it's compiling.
2024-06-18 17:59:51 +00:00
Migrate rodata to functions for dra (#1084)
2024-02-25 17:44:11 +00:00
target_compile_definitions(${PROJECT_NAME} PRIVATE
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
_USE_MATH_DEFINES # needed for msvc
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
VERSION_PC
PERMUTER
NON_MATCHING
Link stage SEL (#963) This depends from #962 . Without `func_800EA7CC` being decompiled, past the title screen you will be welcomed with a black screen. Using the [non matching scratch](https://decomp.me/scratch/dlQDD) will work. The input works regardless the black screen. Getting past the name selection screen there is a crash at `SetReleaseRate1` due to `D_80138FB4` being `NULL`. Getting past it you will get another crash at `HandleVideoPlayback` but I neither investigated on it or tried what's beyond that. There is a divergence between the Make and CMake. For some reason the build from CMake gives a black screen. I am not able to detect where the issue is. I get no warnings or errors. I noticed `g_MegaMenuStrBuffer` gets full much faster in the CMake build. It might due to a silly size of any of the atomic C types. It needs further investigation.
2024-01-11 20:13:33 +00:00
HARD_LINK
Windows build with cmake (#889) This adds cmake and a windows build to the CI. I haven't tested the result, just got it building. I had to make quite a few changes since MSVC has a number of differences compared to GCC. I added two cmake modules to find sdl2 and sdl2_image from here https://github.com/aminosbh/sdl2-cmake-modules The dirent stuff is just `#ifdef`ed out for now since I think it's unused? I'm keeping the Makefile.pc for the moment until this is more proven. I wasn't able to figure out how to add -fsanitize=address for some reason to gcc/clang builds, open to suggestions there. Otherwise I think the cmake build is more or less the same as the Makefile one.
2023-12-27 09:24:00 +00:00
DEMO_KEY_PTR=0
_internal_version_us
)
Null backend (#900) This implements a null backend without SDL2 that can be run in CI and also serve to show what the current platform-agnostic API is. There is a core library, which is DRA and the pc supporting code, and two targets, the SDL2 target, and the null one. null.c is the API that has to be implemented to make a new target. Since main is an infinite loop I added a little code to make it exit after 60 frames. I don't know what is wrong with the headers in null.c.
2024-01-19 02:32:22 +00:00
Conditionally compile libsnd (#1335) This makes changes to allow libsnd/libspu to compile when WANT_LIBSND_LLE is set. If turned on it will immediately crash due to trying to write to the SPU. A build is added to make sure it's compiling.
2024-06-18 17:59:51 +00:00
if(WANT_LIBSND_LLE)
target_compile_definitions(core PRIVATE WANT_LIBSND_LLE=1)
Enable spu init (#1344) This reworks enough writes to libsnd/libspu to make it through the call to SsInitHot. Instead of raw pointers we have read/write_16 functions. The writes are saved to an array so we can test against output from mednafen. See `src/pc/psxsdk/expected/_spu_init.txt`. The gold file is generated by running a real psx psy-q program that calls the same function. A modified mednafen prints the writes. There are reads to spustat and other regs that require particular values to be returned, so I've also imported and hooked up the SPU part of mednafen.
2024-06-19 16:37:07 +00:00
target_compile_definitions(${PROJECT_NAME} PRIVATE WANT_LIBSND_LLE=1)
Conditionally compile libsnd (#1335) This makes changes to allow libsnd/libspu to compile when WANT_LIBSND_LLE is set. If turned on it will immediately crash due to trying to write to the SPU. A build is added to make sure it's compiling.
2024-06-18 17:59:51 +00:00
endif()
Null backend (#900) This implements a null backend without SDL2 that can be run in CI and also serve to show what the current platform-agnostic API is. There is a core library, which is DRA and the pc supporting code, and two targets, the SDL2 target, and the null one. null.c is the API that has to be implemented to make a new target. Since main is an infinite loop I added a little code to make it exit after 60 frames. I don't know what is wrong with the headers in null.c.
2024-01-19 02:32:22 +00:00
# null target
add_executable(${PROJECT_NAME}_null
src/pc/null.c
)
target_include_directories(${PROJECT_NAME}_null PRIVATE
include
src/dra
src/pc/3rd
)
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
if (WIN32)
Migrate rodata to functions for dra (#1084)
2024-02-25 17:44:11 +00:00
target_link_libraries(${PROJECT_NAME}_null PRIVATE
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
core)
else()
Migrate rodata to functions for dra (#1084)
2024-02-25 17:44:11 +00:00
target_link_libraries(${PROJECT_NAME}_null PRIVATE
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
core m)
endif()
Null backend (#900) This implements a null backend without SDL2 that can be run in CI and also serve to show what the current platform-agnostic API is. There is a core library, which is DRA and the pc supporting code, and two targets, the SDL2 target, and the null one. null.c is the API that has to be implemented to make a new target. Since main is an infinite loop I added a little code to make it exit after 60 frames. I don't know what is wrong with the headers in null.c.
2024-01-19 02:32:22 +00:00
Migrate rodata to functions for dra (#1084)
2024-02-25 17:44:11 +00:00
target_compile_definitions(${PROJECT_NAME}_null PRIVATE
PC libgte rsin rcos (#998) A very simple implementation of `rsin` and `rcos`. For now without a pre-calculated sinus table. I am not yet sure about `if (prim->blendMode & 1)`, so I will not create a dedicated define until further investigation. But this was required to render #997
2024-01-20 21:07:25 +00:00
_USE_MATH_DEFINES # needed for msvc
Null backend (#900) This implements a null backend without SDL2 that can be run in CI and also serve to show what the current platform-agnostic API is. There is a core library, which is DRA and the pc supporting code, and two targets, the SDL2 target, and the null one. null.c is the API that has to be implemented to make a new target. Since main is an infinite loop I added a little code to make it exit after 60 frames. I don't know what is wrong with the headers in null.c.
2024-01-19 02:32:22 +00:00
VERSION_PC
PERMUTER
NON_MATCHING
HARD_LINK
DEMO_KEY_PTR=0
_internal_version_us
)
Reference in New Issue Copy Permalink