The person who wrote this seemed to misunderstand how XPending and
XNextEvent actually work. XNextEvent will wait in poll if there's
no event yet, meaning that we don't need to sleep after we process
all the events; the kernel will sleep for us.
This changes indentation, so view with -w or a similar feature to
understand what's actually changed here.
The concept of a "title bar" / "status bar" shouldn't be a core concept,
so remove the Host_UpdateStatusBar function, and move the code handles
whether to update the status bar or titlebar into DolphinWX.
This is effectively unused, as the window handles that we pass to the
GLInterface are window handles for the frame which isn't ever a real
toplevel window. Host_UpdateTitle is what actually sets the proper title
on the render window.
Now that MainNoGUI is properly architected and GLX doesn't need to
sometimes craft its own windows sometimes which we have to thread back
into MainNoGUI, we don't need to thread the window handle that GLX
creates at all.
This removes the reference to pass back here, and the g_pWindowHandle
always be the same as the window returned by Host_GetRenderHandle().
A future cleanup could remove g_pWindowHandle entirely.
We now have two cases: the GLX window is parented into a frame, or it's
parented into the MainNoGUI host. In both cases, the GLX window should
be locked to the size of the parent, so just sync it up based on that.
Our existing code was relying on the GLX backend to create the GLX
window properly, and for the rest of the code to patch that up, sort
of. If we rely on Host_GetRenderHandle() returning a valid window, we
can do a lot better about this.
Create a simple window inside MainNoGUI to make this happen.
Move to one display. There's no reason to have two displays here -- the
comment stated that one should touch GLX and one should touch window
events, and that they should be touched from different threads, but the
current code wasn't this careful.
Just use one Display connection.
Now, the only supported EGL platform is Android. We might eventually add
back support for EGL/X11 or EGL/Wayland, but it will have to be
architected differently.
Yes, this is a fancy new feature, but our Wayland support was
particularly bitrotten, and ideally this would be handled by a platform
layer like SDL. If not, we can always add this back in when GLInterface
has caught up. We might be able to even support wxWidgets and GL
together with subsurfaces!
Restructure our build system so we have multiple targets. Right now we
only build MainNoGUI if we are using X11, since that's the only truly
supported backend: the OS X code actually doesn't compile, according to
comments made on IRC.
We want to have two build targets: Main and MainNoGUI, and this code
will be linked against in both cases, so the ifdef isn't enough for
this case.
Just append to a vector of strings, and then convert it after the fact.
This was used to send fake button or key events to every backend to
implement freelook. When I ported these to be based on wx events in
commit 5248211, I didn't realize that these were now unused, so I didn't
remove them. Do that now.
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.
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.
This will allow us to simplify the checks for background input and push
them further down into the architecture, into the ControllerEmu layer.
The new setting isn't actually used yet, though.
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.
Most users will have something in the radius or deadzone fields, so
don't bother filtering out 'extra' work. This also lets us clean up
the modifier implementation.
It was only used for really old joypads which we really don't want to
support. If users have these joypads, they should look into using
something at the OS level, as games shouldn't need to have this
transformation; it should be done by the OS and driver.
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!
Pad mapping and the UI behind it is significantly confusing,
and has been confusing users since NetPlay was introduced.
As part of a large code cleanup to help NetPlay more stable,
introduce a better pad mapping system where local pad mapping
is handled by the client. Now, all the server and other
clients know is which player have which controllers, and the
clients only know this so they can show the pad mapping in the
UI; they don't do anything else with it.
A future cleanup will use this pad mapping data to completely
ignore the pads configured in the settings pane on the host.
This can happen if the user does not have an up to date version of
the DirectX SDK, as Microsoft intentionally broke it and requires
users to install the W8 SDK.
If we don't do this, then when the game starts we'll send out the
buffer size to clients being a super large value of junk, and they'll
hang forever trying to accumulate an input buffer a size that they'll
never ever reach in a million years.
This never manifested in release builds for some reason.
Add a simple Python script that does a basic normalization on
the game INI files and run it across all the files we have. This
normalizes the sections, their order and comments, and the whitespace
within them.
It also removes the sections Video_Hardware, Gecko, and Wii, which
should not be in the game INI files we ship by default.
The MS INI parser and most other INI parsing libraries APIs only support
comments at the beginning of lines. Right now, some Game INI files use sections
like:
[OnFrame]#Add memory patches here
But these section headers are parsed separately, so this should not break
them.
Jasper St. Pierre