This moves the Gekko disassembler to Common where it should be. Having it in the Bochs disassembly Externals is incorrect.
Unlike the PowerPC disassembler prior however, this one is updated to have an API that is more fitting for C++. e.g. Not needing to specify a string buffer and size. It does all of this under the hood.
This modifies all the DebuggingInterfaces as necessary to handle this.
Fixes a bug where "Use Fullscreen" would initialize into exclusive fullscreen regardless of the borderless fullscreen setting.
Also relieves the need for the video renderer to check the borderless fullscreen setting each time.
This can happen during shutdown.
As long as we don't call event.Skip() the CFrame won't be closed yet, so even if we can't veto the shutdown will still happen in the correct order.
It was only used for Windows XP and lower.
This also bumps the _WIN32_WINNT define in the stdafx precompiled headers to set the minimum version as Windows Vista.
The hack was needed because the Nvidia 3D Vision heuristics are documented to only support surfaces that are the same size as the backbuffer. This would be the case if you enabled the hack and selected the "Auto (Window Size)" internal resolution.
However, on recent drivers the same effect is achieved by selecting the "Auto (Multiple)" internal resolution. Therefore the hack is no longer required.
Also have the renderer remember its own fullscreen state. This is done to prevent a case where we exit exclusive fullscreen through the configuration and a focus shift at the same time. In this case the renderer would fail to detect that the fullscreen state was changed.
This ensures the transition from/to exclusive mode happens while the RenderFrame is fullscreen.
This prevents fullscreen loops and relieves us of having to restore the window size after we exit fullscreen.
It's not used outside of the class, and it also shouldn't be modified
outside of it either (considering it holds all the blr instructions inserted by the user).
We can't use RendererHasFocus for this purpose because of some issues
with exclusive fullscreen, and the new RendererHasFocus implementation
didn't work for non-Render to Main Window cases, since the renderer
window wasn't managed by wx.
This reverts commit ff918df889.
This changed it from "RendererHasFocus" to "UIHasFocus", which is
wrong. Specifically, it broke for non-Render to Main Window cases where
the renderer window isn't managed by wx. It also broke the pending
exclusive fullscreen support, which checks this function to determine if
the renderer is on top so it can full-screen it.
We'll add a new hook, "UIHasFocus", in the next commit.
- Gets rid of the underscore in some function names
- Appends the 'm_' prefix to class member variables.
Now it isn't a pain to see what is being modified in terms of state. Especially in the OnPaint call.
The logic of RendererHasFocus was extremely convoluted beforehand and
was too brittle and broke in certain circumstances, like when the
GCPad window was active. Simplify it and leave a comment explaining the
new logic. This fixes the GCPad window not working when Background Input
is unchecked.
Lessens the restrictions on the searching in the code view.
Now typing out the full 8 digit hex number isn't needed. For example, you don't need to type 000000FF to go to FF, you just literally type FF.
Also makes JumpToAddress a boolean function to remain consistent with the DSP code view.
This will also change the address search box to have a red background if
either an invalid hex number is given, or if it's longer than 8 characters
Do the scaling in the code that interprets the results.
This also removes the templatization of things and changes the interface
to always take a double.
This does add a bit more code to the users of GetState, especially when
having to deal with focus management, but this will be cleaned up very
soon, as focus and focus-related options will be centralized inside the
input platforms themselves, rather than spread out across all the input
plugins.
Change our DrawCoordinate helper method to take raw coordinate
positions, and draw the rectangle using that. This is a lot better
and more friendly than applying various crazy constants in the GetState
for the base/range.
It substantially complicates the code and doesn't really provide any
functionality. According to the forums, the Android app is out of date
and has been broken for quite a while.
If we want to add this back, I'd write an app that speaks a more native
Wiimote protocol, and we can hook that up to the backend quite easily.
It could even be over our NetPlay protocol!
Rachel Bryk