There were some logic snafus from my part, however while it is better it is not usable quite yet.
The problem I'm running into is that I didn't anticipate the nature of 1.6's cheat implementation.
I truly hope this has been changed in the later versions of PJ64.
1.6 uses the registry to act as a hold/store/general go to for just about anything cheats.
Project64 has two threads, the main thread (The window), and the emulation thread (Where the game runs).
Both access the same area pretty much simultaneously, thankfully accessing the registry is thread safe.
What I created isn't thread safe whatsoever so there's problems opening the file while a write is happening.
So there's two ways I can fix this.
1) Make the thread(s) yield if the file is already in use
2) Redo the logic so reads and writes are only performed by the main thread (Start Emulation and End Emulation for example).
Number 2 will come with the possible benefit of increasing the maximum number of cheats that can be applied.
Why's that? Because accessing the registry as many times as 1.6 was is costly.
This is where I believe Gent came up with the limit of 500 cheats and 100 GS cheats (I'll be honest I don't know the difference, thankfully I don't have to, we have Gent).
So I will be doing my best to come up with a solution that is not bogged down by constant file reads and writes (registry included, because even if it's cached by the operating system this is still costly)
This isn't the only place where I need to make changes either.
Changing the size of the window, moving it around, etc... is all written to file/registry as it occurs.
I won't go into how much this makes my head hurt -- Honestly, you don't need to know!
So this is my current project, STILL working on the settings overhaul!
Gent - Kill me now
