theonlyzac / sly1 Goto Github PK

One of the next major milestones will be rendering things on the screen. Any help or progress toward this would be greatly appreciated.

• Rendering polygons
• Rendering text
• Playing MPEG videos

Since these functions aren't in the proto debug symbols I made up a name for their files, but I think cheat code stuff is mostly handled by joy.c, and it's probably possible to piece together the proper home for the savedata-related functions.

https://doxygen.nl

Tasks

• Standardize documentation throughout project
• Configure doxygen to generate doc pages

The working branch for this is splat.

By the time function matching is set up we should have a file CONTRIBUTING.md to help people get involved with the project. It should include sections for:

• Forking the repo
• Finding functions to decompile
• Using the function matching script
• The style guide
• Making a pull request

The game will need to be able to process input/output from the controller to implement anything that requires player interaction.

• Handle controller input
• Implement controller rumble

The data for the game levels are stored in BRX archives on the game disc. Loading the levels involves reading the archives into memory with the CBinaryInputStream class.

Unit tests should be written using CTest to replace the informal testing in main.cpp

Originally posted by @detolly in #3 (comment)

Regarding code structure, the additional directories seem pointless.

I would probably put everything under src/, no reason to do Cheats/cheats.cpp and Cheats/cheats.h etc if all dirs are just gonna have a same named source & header file.

Never thought I'd say this but flat is just better in this case.

Originally posted by @VelocityRa in #3 (review)

When multiple unit tests are added in the same file, typically only one of them is built with make check.

The plan is to use CodeMatcher to match the decomp functions against the game binary, so we'll need to include it either as a submodule or just the exe, and come up with a way to match the decomp against the game bin which does not have debug symbols.

&g_difficulty is a ptr. change function signature to void ... (Difficulty& difficulty)

An L-value reference is a ptr that the compiler has guaranteed is a valid object before it's passed into the function. therefore it's a ptr in binary but in the code it's a reference. Also, as mentioned in the discord, it's a possibility that all these functions are member functions of the difficulty structure if a reversed calling convention is assumed (i have no idea what calling convention this binary uses).

Originally posted by @detolly in #3 (comment)

The first mention of contributing to the project in the README.md file links to "/CONTRIBUTING.MD", which doesn't exist.
Line 38 should be modified from [CONTRIBUTING.md](/CONTRIBUTING.MD) to [CONTRIBUTING.md](/CONTRIBUTING.md) (the extension ".md" should be lowercase), like at line 139.

To eventually produce a matching decomp we need to switch the compiler to the ee-gcc (archived here). That means reformatting the code to follow to the older C++ standard.

Tasks

• Refactor code as C++98
• Add/update Makefiles
• Write instructions for using the new compiler