fokiiq.blogg.se - Shining force 2 rom fig format

#Shining force 2 rom fig format update
#Shining force 2 rom fig format Patch
#Shining force 2 rom fig format code

#Shining force 2 rom fig format Patch

Several patches can be stored in the same branch, either when necessary for patch combination management, or when they simply form a functionally coherent set.El Viento may desperately want to be a Castlevaniabeater, but it’s more akin to a ’90s straight-to-video movie, which oddly enough, is actually a recommendation. The patch can then be merged into a target build branch to be combined with other patches for future projects. Creating a new patch :įork the repository, and create a new branch from master branch content.ĭeclare optional patch in disasm/sf2patches.asm.

Creating a new game project :įork the repository, and then start project by creating a new branch from build/standard branch content.

#Shining force 2 rom fig format update

Update master branch with SF2RE output and txt documentations.

#Shining force 2 rom fig format code

This is the recommended starting point to have fun playing with the game's code and content. Main build branch, containing all features and fixes considered as the maintained standard set. 'build/xxx' branches :īranches which combine content from feature/fix branches in order to produce a consistent set of compatible changes which can be used as a stable starting point for further projects.Īutomatically updated with master branch progress, through GitHub Actions configured in directory. Manually updated with master branch progress when needed : before working on it, and before merging it into a build branch. Single feature/fix developments which should stay optional patches by using declarations in file sf2patches.asm.Ĭontent of these branches can then be combined into build branches. Reassembling the code from this branch should produce a bit-perfect copy of the original rom. The documented disassembly in its initial form, and a starting point for feature/fix developments in other branches. Git workflow guidelines : 'master' branch : "entry-oriented" way, to make each entry contain all that is specific toĮditors can then edit assets individually, and point to them whileĮditing battle or map entries.

In an opposite top-down approach, battles and maps are organized in an.

Most data is considered as assets and gathered by type for aīottom-up approach : graphics, sound, scripting, etc., need to beĬreated first in order to use them in maps, battles, cutscenes.

Process by reflecting them in the folder structure. The main goal is to clarify the game's data organization and creation Values while RAM locations are pointed to, moved, etc. Once again, disambiguation is natural, as enums are used as immediate Beware : ASM 68k writing skills required !ĭisambiguation is made by the way they are accessed : functions areīranched or jumped into while data is pointed to, moved, etc.

The game's code can be edited in the disassembly.

The game data obtained with split.bat can be edited individually before being included in the game with build.bat.

It should be possible to start from this disassembly to modify the game's data and mechanics. If using the master branch, the assembled game will be perfectly identical to the original one (see below).

with build/build.bat, assemble the game from its disassembly and the extracted data chunks.

with split/split.bat, split the original rom file into a lot of small binary data files, to extract data chunks which are not included in the disassembly.

)īy providing the original US rom file of the game, one will be able to use the provided tools in order to : ) and assembler code (algorithms, workflows, hardcoded stuff.

Text files dispatched along documented data assets (structure, format, compression.

Commenting the disassembly's ASM code, proper formatting and splitting of binary data.

Providing documentation of the game will be done mainly in two ways :

Giving fan-projects the ability to start from this disassembly by editing the game's code and assets.

Being able to re-assemble the game and obtain the same rom file as the original game.Documenting as much content of the game as possible, to get a perfect understanding of how it works.

The purpose of this project will be to provide a disassembly of Shining Force II with the following goals in mind : A disassembly of the game "Shining Force II" for documentation and fan-project purposes, which can be assembled back into a bit-perfect replica of the original rom file.