--prevList, undoPrevList, and redoPrevList removed. All of the definitions for previous are now stored in separate data items.
---Should yield small speed increases.
---Makes it easier to port these definitions to Ram Watch eventually.
---Auto-aligns data, making it impossible for issues, such as the original values not aligning with the correct values because the prevList wasn't recreated, impossible.
---Makes it possible for the field to automatically update when the definition is changed (Implemented).
--Value/PrevToString() now use the same code.
--Reduces redundancy.
---This was a problem as PrevToString wasn't taking into account the data type, whereas Value was. This is now fixed.
-Watch now stores the data for the "last change" previous definition. Now I just have to set up the option in the GUI.
2. Fixed issues with the light blue current frame pointer in tastudio
3. Removed a totally useless index that was being kept seperately in the movie log.
4. Moved the tastudio update after the check to see if the rest of the saved state list is valid.
5. Changed some function/variable names related to the movie log for clarity.
1. Added a list of save states to the movie log.
2. Added corresponding support functions for the save states.
3. Added double click to the list view to load a previous frame.
4. Added a context menu to the list view with insert and delete.
5. Fixed some issues with the green zone of valid state history.
6. Fixed an input bug that I had unwittingly created, as well as issues with the nes log format.
1. Hooked up Fast Forward, Fast Forward to End
2. Made a placeholder for Turbo Fast Forward.
3. Fixed rewind to not stomp on the previous frame with new input.
4. Fixed rewind to stop at the beginning of the movie instead of freaking out.
5. TAStudio now shows data from the most recent frame.
6. CommitFrame is called even if not recording so played back frames also show up in TAStudio.
7. Play mode only stops at the end of the movie if you tell it to. Your emulator normally continues to play with no input after the end of the movie.
8. TAStudio is now updated after a rewind (even though the rewind doesn't play a new frame).
9. Split the tools update into before and after updates.
10. Going into read-only mode adjusts the movie mode.
11. Implemented New, Open, Save, and Save As for TAStudio.
12. Fixed an issue where frames past the end of the log would default to the input from the last frame of the log.
13. Fixed a problem where you couldn't rewind to frame 0.
14. Fixed a scrolling issue in the TAStudio list view.
15. Fixed an issue with the TAStudio virtual NES controller not matching up with the log.
16. Fixed an issue where the NES reset button would get held in when rewinding.
17. Added/Modified a couple of button graphics.
--It's going to be based heavily based on Imran Nazar's "GameBoy Emulation in Javascript" series. I figure it's better that I learn by emulation (Har har) instead of spending more time reading references than programming.
--Finished the memory management (Part 2).
--adelikat:
---Do I implement the required functions for IEmulator and IVideoProvider now, do it later, or is this something you or zeromus would do (Like for the API)?
---At what point should we have the emulator actually use this core instead of zeromus'? As terrible as he says his is, this one doesn't do anything yet. Still, I need some mechanism of testing it.
-Made it so that the log only opens when logging is true and that the file closes upon destruction.
--Still, BizHawk says that it can't open the file again when I load a game again. This is because the emulator class gets recreated without deleting the original one every time you load a game.
---adelikat convinced me not to care about this.
-Fixed the initial state of the GB CPU:
--It was setting AF to 0x01, not A. This is effectively setting F to 0x01, which gets overwritten later anyway.
--Two BIOS flags were used in different places; merging them gets the PC to start in the right place.
-By fixing the initial state, most of the log now matches up.
--The only differences are the VBA has some repeated records (Where all of the registers, including PC, are the same as the previous record) whereas BizHawk doesn't.
--This very well might be an issue with how I'm logging it
--Alternatively, it could be some kind of lagging mechanism.
--I'm not sure which version is even correct...VBA is far from accruate.
--All in all, considering that the vast majority of the diff comes out as the same, I think I fixed the biggest CPU related bug. Will investigate more later.
brandman211