Ok back in the suggestions thread there was discussion of a Cheat database like those found in other emulators such as Project64, Jnes, and even 1964. This thread is for creating that Database, it is by no means the final product since the actual implementation has yet to be coded in VBA-M
Great that you opened this thread. We really need to get this started, because IMHO the cheat system in VBA wasn't really that great or good, but now we have the possibility to create an impressive database for the Best Multi GB-Emulator available.
sounds good. which file format will be used for it (xml-based, perhaps?) ?
We don't know yet, but atm we're discussing a PJ64 styled INI system, but don't know exactly. Time will show.
Code: Select all
[superman-Countdown To Apokolips (U)]
;Load the master cheat first
;End Gameshark Codes
;Start Proaction Replay
;End Proaction Replay
Now mind you this isn't final and is due to change especially since the implementations has not yet been written yet.
i dislike large text files... the PEC codelist is 24mbs, and thats due to an excessive amount of Valkyrie Profile codes (yes,.. ONLY Valkyrie Profile Codes)
without them it'd be 6mbs, tops.
I would gather a central XML file to dictate the cheats to be loaded from other files would be better. so. for instance
- Minish Cap XML
the Database.xml would be used to match against the rom's hex, or crc, or w/e, and then load the cheats from the file specified.
.....but if we can keep a single file small, by not using mbs worth of cheats for one game, it'd be ok.
or small, multipart xml files with a fixed number of cheat info (cut at 500 kbs for example),dated, and with user-input cheats separately added outside of the db (minish cap.xml). this way, the cheat format could be thought of with only storage requirments in mind, and not really reeditability (it'd be desirable for edits to be saved in separate files, easier submitting process, in case theyre not in central db yet).
Also, cheats could work in more than one game (euro, italian and US versions for example), so expanding matching to the gameid would sound nicer (for all kinds of reasons, one could have bad cartridge dumps which would fail a crc32 check)