Originally the path to a single read/write database was set with the "database" setting. If a game, cheat, or code line was created, modified, or deleted, the entire database was rewritten.

Now there can be a read-only database in addition to a read/write one, specified by the "databaseReadOnly" and "databaseReadWrite" settings, respectively. If a game, cheat, or code line is created, modified, or deleted, it is written to the read/write database rather than rewriting the whole database. The read-only database won't be written to by CheatDevice.

Loading works, still need to implement saving only modified games/cheats to the read/write database.

Add preliminary menu awareness for read/write vs. read-only games. Idealy if a read-only game is currently highlighted in the mnu, the context menu will only have the "Add Game" and "Cancel" options. The context menus for cheats and code lines of read-only games would behave similarly.

If a cheat is read-only, its title and code lines cannot be modified. If a game is read-only, its title and read-only cheats cannot be modified. You can, however, add additional cheats.

If a game only has read-only cheats, its game title won't be written.

Draw progress bar less often.

Fix "(null)" from being written by fprintf() when a database path is NULL.

Use lookup-table to decode hex string. It seems to be a little faster than before.

…aded, add the new cheats to the existing game. Otherwise, create a new game.

This format has been made obsolete by zipped txt files.