These slots are only ever attached to event handling mechanisms within
the class itself, they're never used externally. Because of this, we can
make the functions private.
This also removes redundant usages of the private access specifier.
The previous code could potentially be a compilation issue waiting to
occur, given we forward declare the type for a std::unique_ptr. If the
complete definition of the forward declared type isn't visible in a
translation unit that the class is used in, then it would fail to
compile.
Defaulting the destructor in a cpp file ensures the std::unique_ptr's
destructor is only invoked where its complete type is known.
Allows capturing screenshot at the current internal resolution (native for software renderer), but a setting is available to capture it in other resolutions. The screenshot is saved to a single PNG in the current layout.
* Add CheatEngine; Add support for Gateway cheats; Add Cheat UI
* fix a potential crash on some systems
* fix substr with negative length
* Add Joker to the NonOp comp handling
* Fixup JokerOp
* minor fixup in patchop; add todo for nested loops
* Add comment for PadState member variable in HID
* fix: stol to stoul in parsing cheat file
* fix misplaced parsing of values; fix patchop code
* add missing break
* Make read_func and write_func a template parameter
tr() will not function properly on static/global data like this, as the
object is only ever constructed once, so the strings won't translate if
the language is changed without restarting the program, which is
undesirable. Instead we can just turn the map into a plain old function
that maps the values to their equivalent strings. This is also lessens
the memory allocated, since it's only allocating memory for the strings
themselves, and not an encompassing map as well.
This is more localized to what we want to enforce directory-wise with
the project. CMAKE_SOURCE_DIR indicates the root of the source tree, but
this would cause the wrong behavior if someone included yuzu as part of
a larger buildsystem (for whatever reason). Instead, we want to use the
directory where the "project(yuzu)" command was declared as the root
path reference.
These should be initialized to deterministic values so it's easier to
catch improper behavior, as it'll always be reproducable, instead of
performing uninitialized reads.
These are only used within this class, so we can make them private to
keep their use contained. This also gets rid of the pre-Qt5 'slot'
identifier, since Qt 5's connection syntax doesn't require a function to
be declared a slot anymore.
This gets rid of an unnecessary type conversion. We can just use the
regular QStringLiteral to already format the string as the type
setWindowTitle accepts instead of converting from a std::string
instance.
* Initial implementation
* Various fixes and new features
* Address some review comments
* Fixes
* Address more comments
* Use g_hle_lock
* Add more state checking, remove unneeded include
* Minor changes
Keeps the definition constrained to the citra_qt target and prevents
polluting anything else in the same directory (should that ever happen).
It also keeps it consistent with how the USE_DISCORD_PRESENCE definition
is introduced below it.
Lets us keep the generic portions of the compatibility list code
together, and allows us to introduce a type alias that makes it so we
don't need to type out a very long type declaration anymore, making the
immediate readability of some code better.
This has gotten sufficiently large enough to warrant moving it to its
own source files. Especially given it dumps the file_sys headers around
code that doesn't use it for the most part.
This'll also make it easier to introduce a type alias for the
compatibility list, so a large unordered_map type declaration doesn't
need to be specified all the time (we don't want to propagate the
game_list_p.h include via the main game_list.h header).
Depending on whether or not USE_DISCORD_PRESENCE is defined, the "state"
parameter can be used or unused. If USE_DISCORD_PRESENCE is not defined,
the parameter will be considered unused, which can lead to compiler
warnings. So, we can explicitly mark it with [[maybe_unused]] to inform
the compiler that this is intentional.
We can utilize QStringList's join() function to perform all of the
appending in a single function call.
While we're at it, make the extension list a single translatable string
and add a disambiguation comment to explain to translators what %1
actually is.
change TouchToPixelPos to return std::pair<int, int>
static_cast (SDL)
various minor style and code improvements
style - PascalCase for function names
made touch events private
const pointer arg in touch events
make TouchToPixelPos a const member function
did I do this right?
braces on barely-multiline if
remove question comment (confirmed in Discord)
fixed consts
remove unused parameter from TouchEndEvent
DRY - High-DPI scaled touch put in separate function
also fixes a bug where if you start touching (with either mouse or touchscreen) and drag the mouse to the LEFT of the emulator window, the touch point jumps to the RIGHT side of the touchscreen; draggin to above the window would make it jump to the bottom.
implicit conversion from QPoint to QPointF, apparently
I have no idea what const even means but I'll put it here anyway
remove unused or used-once variables
make touch scaling functions const, and put their implementations together
removed unused FingerID parameters
QTouchEvent forward declaration; add comment to TouchBegin that was lost in an edit
better DRY in SDL
To do -> TODO(NeatNit)
remove unused include
This adds a Game List configuration group box which is similar to yuzu's, with features including icon size setting, row 1/2 text, and ability to hide invalid titles (those without a valid SMDH). I also added a UI tab and moved the language and theme settings there.
Placing the array wholesale into the header places a copy of the whole
array into every translation unit that uses the data, which is wasteful.
Particularly given that this array is referenced from three different
translation units.
This also changes the array to contain pairs of const char*, rather than
QString instances. This way, the string data is able to be fixed into
the read-only segment of the program, as well as eliminate static
constructors/heap allocation immediately on program start.
Keeps the individual behaviors in their own functions, and cleanly
separate. We can also do a little better by converting the relevant IDs
within the core to a QString only once, instead of converting every
string into a std::string.
Disambiguates what the string represents to help translators more easily
understand what it is that they're translating. While we're at it, we
can move the code to its own function, so that we don't need to specify
the same string twice.
Frame advancing is a commonly used TAS feature which basically means running the game frame by frame. TASers use this feature to press exact buttons at the exact frames. This commit added frame advancing to the framelimiter and two actions to the Movie menu. The default hotkey is `\` for advancing frames, and `Ctrl+A` for toggling frame advancing. The `Advance Frame` hotkey would automatically enable frame advancing if not already enabled.
This adds a clock init time field to the CTM header. The clock settings would be overridden when playing a movie. And when recording a movie, if the clock is set to System Time, it would be set to fixed init time at the current moment as well. In this way this keeps consistency with the RNG even if the user does just no setting.
Changes the interface as well to remove any unique methods that
frontends needed to call such as StartJoystickEventHandler by
conditionally starting the polling thread only if the frontend hasn't
started it already. Additionally, moves all global state into a single
SDLState class in order to guarantee that the destructors are called in
the proper order
Instead of using an unsigned int as a parameter and expecting a user to
always pass in the correct values, we can just convert the enum into an
enum class and use that type as the parameter type instead, which makes
the interface more type safe.
We also get rid of the bookkeeping "NUM_" element in the enum by just
using an unordered map. This function is generally low-frequency in
terms of calls (and I'd hope so, considering otherwise would mean we're
slamming the disk with IO all the time) so I'd consider this acceptable
in this case.
Qt provides an overload of tr() that operates on quantities in relation
to pluralization. This also allows the translation to adapt based on the
target language rules better.
For example, the previous code would result in an incorrect translation
for the French language (which doesn't use the pluralized version of
"result" in the case of a total of zero. While in English it's
correct to use the pluralized version of "result", that is, "results"
---
For example:
English: "0 results"
French: "0 résultat" (uses the singular form)
In French, the noun being counted is singular if the quantity is 0 or 1.
In English, on the other hand, if the noun being counted has a quantity
of 0 or N > 1, then the noun is pluralized.
---
For another example in a language that has different counting methods
than the above, consider English and Irish. Irish has a special form of
of a grammatical number called a dual. Which alters how a word is
written when N of something is 2. This won't appear in this case with a
direct number "2", but it would change if we ever used "Two" to refer to
two of something. For example:
English: "Zero results"
Irish: "Toradh ar bith"
English: "One result"
Irish: "Toradh amháin"
English: "Two results"
Irish: "Dhá thorthaí" <- Dual case
Which is an important distinction to make between singular and plural,
because in other situations, "two" on its own would be written as "dó"
in Irish. There's also a few other cases where the order the words are
placed *and* whether or not the plural or singular variant of the word
is used *and* whether or not the word is placed after or between a set
of numbers can vary. Counting in Irish also differs depending on whether or not
you're counting things (like above) or counting people, in which case an
entirely different set of numbers are used.
It's not important for this case, but it's provided as an example as to why one
should never assume the placement of values in text will be like that of
English or other languages. Some languages have very different ways to
represent counting, and breaking up the translated string like this
isn't advisable because it makes it extremely difficult to get right
depending on what language a translator is translating text into due to
the ambiguity of the strings being presented for translation.
In this case a translator would see three fragmented strings on
Transifex (and not necessarily grouped beside one another, but even
then, it would still be annoying to decipher):
- "of"
- "result"
- "results"
There is no way a translator is going to know what those sets of words
are actually used for unless they look at the code to see what is being
done with them (which they shouldn't have to do).
