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.
A previous PR changed a whole lot of min/maxes to std::min/std::max
but made a mistake here and used a templated min which cast it's
arguments to unsigned instead of casting return value.
This resulted in glitchy artifacts in bright areas (See issue 7439)
I rewrote the code to use a proper clamping function so it's cleaner
to read.
Another issue from #334 with the casting moved from the output of
min to it's inputs.
This is a non-issue on 64 bit machines, but if dolphin is compiled
on an OS with size_t == u32 (say ARM) then remainingSize could be
truncated.
Restored the casting to the original order before #334.
s_encodingPrograms is defined as an array with a length of 64
NUM_ENCODING_PROGRAMS is also defined as 64.
However 64 is out of bounds, so we want to be comparing for "equal to or
greater than here"
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
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!
ffmpeg 2.0 changed requirements for the FFV1 encoder and made them more strict,
requiring more fields of the input frame to be initialized. Explicitly setting
pixfmt, width and height solve the EINVAL issues with FFV1 encoding.
Original fix from http://ffmpeg.org/pipermail/libav-user/2013-October/005759.html
Jules Blok