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">
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`
Previously attempted by @sonicdcer https://decomp.me/scratch/CMSl2.
I'm not sure the signature for func_801CDD80 is correct, which led me
down this rabbit hole. It matches, but there's a lot of ugliness going
on, I'm not sure if `arg1` has the correct type, or that `GH_Props` is
the right struct to access..
This one is pretty weird, there are a whole bunch of temp variables that
I couldn't figure out how to solve.
There are 8 blocks which set a variable, capped between 0 and an upper
limit (0xF0 or 0xFF). For the upper limit, I have created a `MIN()`
macro. I tried to make a `CLIP()` which would handle both limits in one
macro, but couldn't create one that would match.
Scratch here if anyone can improve things:
https://decomp.me/scratch/fY8js
This is a historical W.I.P. that held me back due to some dirty bytes in
the US version. It is now done.
I renamed the file to `lba_stage.c` as I plan to add another file called
`lba_bin.c` right after this PR.
To quickly build the HD LBA, which is very different, I wrote a quick
script to duplicate and patch the US one:
```python
def s16(f):
return int.from_bytes(f.read(2), byteorder='little', signed=False)
def s32(f):
return int.from_bytes(f.read(4), byteorder='little', signed=False)
with open("disks/pspeu/PSP_GAME/USRDIR/res/ps/hdbin/dra.bin", "rb") as f:
f.seek(0x3C50)
for i in range(0, 0x50):
print(f"0x{s32(f):04X}, 0x{s32(f):04X}, 0x{s32(f):05X}, 0x{s32(f):04X}, 0x{s32(f):04X}, 0x{s32(f):05X}, 0x{s32(f):04X},")
s32(f)
s32(f)
s32(f)
s32(f)
```
---------
Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>
Sorry for the unimaginative function name, not really sure what it's for
yet. Pulled into the existing header as these two functions always
appear together. Slightly refactored the function.
Some entity, don't know what. There seem to be a lot of entities that
just use 7C and 7E from the `ext`, might be something we think about
unifying in the future.
I am not sure if we want to use this pattern. Here I am proposing to
wrap functions to open files and read the entirety of a file.
The objective is to avoid performing sanity checks for `fopen`, `fread`
and `malloc`, other than ensuring allocated resources are correctly
de-allocated on both happy and unhappy paths.
How it works is the first parameter is always the callback, while
starting from the second are all the parameters necessary to instantiate
and allocate the resources to be passed to the callback.
Found this function in RIC, it's very similar to the one in DRA, which
is nice.
Patterns of zeros in the rodata indicated that this should be the start
of a new file, which also makes sense since CreateEntFactoryFromEntity
comes with it.
RIC has its own array of blueprints, I'll probably add that to the splat
later on but that seems like material for a separate PR. For now we
focus on the entity function.
This appears to control Richter using an item crash.
We add an enum for the subweapon IDs. This should be useful in other
places but for now makes the switch much more readable.
Loops in EntityAlucard and UpdateEntityRichter indicate that these 16
elements of g_Player are an array of 16 values. The known ones appear to
be player status effect timers.
While those functions have a long-standing issue preventing them from
matching, they provide enough evidence to suggest that we should make
this change. I have changed all existing uses, and changed the symbols
so that any remaining non-decompiled functions will use the proper form.
It would probably be beneficial to make an enum for the 16 elements of
this new array, but I'll hold off on that for now until we can identify
the purpose of more of them.
---------
Co-authored-by: Luciano Ciccariello <Xeeynamo@users.noreply.github.com>
Function looks like function `u32 UpdateAnim(s8* frameProps, s32*
frames)` without any value returned.
Next step will be `func_8010DA70` as it is used with it.
scratch : https://decomp.me/scratch/Ib0tn
This one has a corresponding DRA function. I believe these relate to the
fading shadows that appear behind the player, but I'm not confident
enough about that to go ahead and rename things. For now, it's
decompiled at least.
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`.
I had the suspect menu strings were part of a string of arrays since a
while. So I come up with a `g_MenuStr[]`, which removed the need of many
fake symbols. I did not yet come with a bunch of `#define`s to resolve
some magic numbers. Luckily you can guess which string is which from the
context of the function. Resolving the HD strings might give me more
clues on how to come up with good defines.
I decided to go for the route of having a `lang_us.c` and a `lang_jp.c`
for the sake of maintaining things simpler. This is also due to the fact
the HD build orders the japanese strings in a different way, making
things a bit harder. Any modder can just come up with their own
`lang_XX.c`, translate the menu in the language they want and just link
it, without touching the original files.
For the test app things were tricky. I've been debating how to implement
it as SOTN-encoded strings are not pre-encoded on compilation time like
the PSX toolchain does. Instead they are burnt into the executable as
UTF-8 characters. Instead of encoding them on-the-fly in `MenuDrawChar`,
I decided to re-use `AnsiToSotnMenuString` to pre-encode all the strings
and re-route each `g_MenuStr` pointer to the converted strings. This is
both efficient at runtime and prevents to modify the existing matching
code. Now the menu looks amazing.
I thought this was going to be much harder to do. I ended up doing
incremental steps in each commit to ensure having healthy checkpoints in
case things were going south. The tool ` ./tools/sotn-str.py parse
disks/us/DRA.BIN 0xOFFSET` saved me sooo much time. But we need to tweak
it to deal with Japanese characters.
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.
