I need help on this pull request. While it matches as it is, I cannot
decode the Japanese strings from bytes to UTF-8 convertible into
Shift-JIS into a C file that is able to give me an `OK`. I think the
problem lies on how Python decodes Shift-JIS byte arrays.
I [wrote a
tool](https://gist.github.com/Xeeynamo/d75c73431eaf54b42f955ca8740bb754)
to automate the process:
```bash
python3 sotn_config.py > src/dra/config_jp.c && make
```
To extract some of the strings as Shift-JIS, uncomment the first line at
the function `get_sjis_str`. I am tempted to make a custom decoder. But
first I want to gather your insight in case I am missing something
obvious.
Imports the `D_800C1ECC` table straight into `953A0.c`, so
`ApplyQuadChannelSetting` can populate the fields correctly.
Also removes a fake symbol from `menu.c`, which allows to access the new
merged `g_ChButton` array correctly. This fixes the _"Button Settings"_
sub-menu in _"System"_
The function is not referenced anywhere other than by being exported in
`GameAPI`. I suspect only the LIB overlay uses it. I added a comment
speculating what the function might be about.
Came across this function today and found several improvements for it.
- Unkstruct_800FD5BC is a duplicate of DamageParam. Therefore, I have
changed all instances of Unkstruct_800FD5BC to DamageParam. The fields
make sense in context and everything.
- Because func_800FD5BC is in GameApi, which is defined in `game.h`, its
argument (now a DamageParam) needs to be accessible in `game.h`.
Therefore, DamageParam moves from dra.h to game.h.
- We had a fake division being done with using a `temp` and checking a
comparison to zero; this has been changed to be a normal division. This
is a common pattern I see in initial m2c output and I'm sure it exists
in other places in the repo, would be nice if we could find an automated
way to search for this type of structure to simplify the code.
- Changed a 0x14 to 20 since it makes way more sense that way
- Changed an `if(){dostuff; return} else{morestuff}` to just
`if(){dostuff; return} morestuff`, eliminating the `else`
I think this function should not be in `menu.c` since it has no close
connection to any kind of menu. It would also be nice if we could figure
out what damageKind actually is, and maybe make an enum for it.
Overall, no new decompiling here, but lots of improvement to the
readability of the code. This might actually be a good PR to keep in
mind as an example for people who are interested in the project but
aren't comfortable with assembly, since this is a lot of improvement and
change, without touching assembly at all.
The file is 192KB long. Yet on PSX it seems the game still wants to load
256KB of it. Obviously that only works there where the memory is
unprotected.
There are two other crashes happening at `func_801B1FD8` and
`func_801B2108`. The first one is triggered by `func_801ACF7C` and it
seems to be related to the termination character. The second I have no
idea.
To skip `SEL` and boot straight to WRP, go to `sim_pc.c` and comment the
following lines:
```c
case STAGE_SEL:
InitStageSel(&g_api.o);
break;
```
Some deduping and renaming that might help later
- Dedupe DestroyEntity
- Dedupe ST EntityIsNearPlayer
- Dedupe DestroyEntitiesFromIndex
- Dedupe ST CollectHeart
- Dedupe ST UnkEntityFunc0
- Decompile + rename rwrp EntityExplosionSpawn
Happy to rename this one but this is the best I came up with.
This is the entity function for the faint rings that appear around
Richter in two cases. 1: When he gets saved by Maria after dying in the
prologue, and 2: When he powers up for the flame-whip ability when you
press triangle without a subweapon.
Here is a screenshot of the former case:
This is actually 4 instances of the ring, nested within each other. I'll
be honest, I never even noticed this existed. This is a huge amount of
code for something so minor.
`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.
Went through all the current calls to `CreateEntFactoryFromEntity` in
RIC and changed them to use the proper `FACTORY()` syntax. This is
extremely helpful for finding where entities are created since they're
much more searchable.
The new `INCLUDE_ASM_NEW` was a test when I decided to slowly import DRA
HD. It essentially removes the need of specifying `asm/us` or `asm/hd`.
which is dictated by `VERSION` found in `include/common.h`.
This PR make the use of `INCLUDE_ASM_NEW` the default. To fall to the
old behaviour, `INCLUDE_ASM_OLD` is required. This is only used by the
overlay MAD, which sets `VERSION` as `beta`.
Comment describes what this function is for. I identified it by setting
a breakpoint in an emulator and waiting for it to trigger, then verified
by NOP-ing it out.
Here is a screenshot of the sparkle appearing:
This is the last function using rodata in 32324.c. However, once I
decompiled it and did the normal rodata steps, I had a mismatch of `00
00 00 00` bytes, which signalled that this should not be the end of the
file. Therefore, I pulled 345EC.c into this file, which now matches.
Function scratch is here: https://decomp.me/scratch/PSKCu
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.
My main goal was to extract the .data for the table in RIC, but while I
was doing that, I also decided to clean things up a bit, so now:
- Both tables have proper names
- Both tables have all the entities forward-declared in the proper .h
file
- Attempted to remove all repeated forward-declarations in the .h file,
not sure if I got them all
Overall this should improve readability and should be pretty close to
how I would expect the original game to have done it.
It still complains on 🍎 due to the missing SDL header. Doing `brew
install SDL2` does not fix the issue. I think it would eventually be
beneficial to add a macOS agent to the CI.
I noticed that there was a mismatch in the rodata where a set of 4 `00`
bytes was being skipped, and those indicate that these should be the
same file.
Rewrites SEL's `banks.c` to use an array of `u_long` and make use of
declarations to populate it.
This PR comes after giving up at believing the original developers would
had the decency of using structs instead of crude array of data. They
are really developers from another era.
This is one of the few remaining sound functions.
It calls `ApplyQuadChannelSetting` and `func_80135624` in extremely
similar ways, so I've adjusted the arguments to those functions so they
match. `func_80135624` should probably get its own name which is similar
to `ApplyQuadChannelSetting`, but I don't know enough about these
functions to actually tell what it's doing.
One of the few remaining DRA functions.
Some of the code here seems fake, but it matches so I'm going with it. I
tried to change all the pointers to use the loop indexing but it didn't
work. Might have been written by a coder who was more comfortable
working with pointers than with loops.
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.
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.
I had to merge `2C048.c`, `2D260.c` and `2EED8.c`. The hint was in a
string that had to be in `2C048.c` but it was also used in the other two
files. I couldn't still merge this with `33164.c` due to the same
problem I described in #946 .
EDIT: I kept importing more data. SEL also contains its own `lba_stage`,
but some offsets and OVL size are out of sync compared to DRA. I have
the suspect the table was manually maintained, unlike our _"top class
engineering"_
I spent some time trying to merge `2EED8` and `33164` as the rodata
seems to suggest it. But there is a weird 4-bytes padding that is added
when the file split does NOT happen. If you want to have a look before
merging this, please do.
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`
