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
This was a community effort relying on the work of myself, @ser-pounce ,
@Xeeynamo , and others. Thanks all for helping to put this together and
it will be very exciting to have such a large and important function in
the repo!
Lots of room for improving this one in terms of code style, but having a
baseline functional version in is huge.
These functions both have very difficult functions before them in their
files, so need to split to new files to make the rodata work.
Originally decompiled RIC func_80166060, then once that was done I dug
through the blueprints and realized it matches EntityTeleport, which
made decompiling EntityTeleport an easy task, at which point I renamed
the RIC function to match.
I've also gone through a lot of the functions they call and labeled the
ones that match between overlays; I expect this to be helpful in the
task of identifying names for a bunch more functions.
Decompile and de-duplicate EntityStageNamePopup for all the overlays the
function is in.
I also detected a helper function I renamed as `PrimDecreaseBrightness`
that was originally accepting a completely wrong parameter type. This
helped me to get rid of `Unkstruct_80128BBC` too.
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.
Progress on RIC has been hugely beneficial for solving some old DRA
functions. I'm going to start going through all the entities and try to
identify all of the ones that are in common between the two. I tried
this one in DRA a long time ago, but once I identified the
correspondence between these two functions, having the RIC version
available made things a HUGE amount easier.
One very important thing in the analysis of these functions: Take a look
at the RIC version, func_80160FC4:
https://github.com/Xeeynamo/sotn-decomp/blob/master/src/ric/24788.c#L260
The first thing the function does is it loads paramsLo and paramsHi.
Then there is an if-statement which takes paramsHi into account.
But in this new function, those variables aren't given values until the
switch statement. This means that in the if-statement, paramsHi is not
initialized and will be undefined. I believe this is a bug, but would
like to hear someone else's thoughts before giving it an official bug
label.
As noted in the comment, I don't know what this actually is and how it
corresponds to DRA, but hopefully the comment will help track it down in
the future.
In the entity extension, this function just has a timer at offset 7C.
The gravity boot beam entity had the same. I decided to create an
extension called TimerOnly to handle these multiple entities that just
have a timer there. I think finding patterns like these in the entities
will be nice to try to slim down entity.h.
Working in parallel on these two overlays has been hugely beneficial, I
think I will continue to try to do things this way.
I don't think I have any major comments besides that. This code required
more fake stuff than usual in order to make registers agree.
Originally decompiled this for RIC, then in the process of figuring out
what this entity was, I realized it was a duplicate of one in DRA which
was already named EntityHitByIce. Therefore, I have gone ahead and
decompiled it for DRA as well.
I think there are a whole lot more functions that are duplicated between
RIC and DRA, but there are enough subtle differences that the
duplicate-finder script misses them.
Because of the close relation between this and AlucardHandleDamage and a
previously-unnamed RIC function, I have named that function
RichterHandleDamage to match.
This is a proof-of-concept for Japanese sotn_strs. The macro `_SJ` is
used to designate them. I only converted one string in config_jp to
serve as a test for the pipeline. I moved sotn_str to a folder and added
some tests. I renamed it since python doesn't like modules with - in the
name. The code could be cleaner and the conversion table could use some
more work but I think this is a reasonable start.
This is a pretty big one!
There are a lot of unknown SFX entries, I'll leave that as a future
thing to work out what all the hex codes for the sounds are.
Pulling in the rodata gave the usual mismatch with 00 bytes, so I moved
the following C file into this one.
Several other changes here and there, this is a fairly large commit so
please be sure to examine it carefully.
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:
![image](https://github.com/Xeeynamo/sotn-decomp/assets/15314202/3719d784-c30c-4c4f-8d51-6662fbb93d5f)
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:
![image](https://github.com/Xeeynamo/sotn-decomp/assets/15314202/d071e946-b012-4878-a050-41ada78fe2bc)
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.