CreateEvent and CreateThread return NULL on failure, not
INVALID_HANDLE_VALUE. This should have been done in
0477e03965, I didn't check thoroughly
enough.
* Only use dark green color for the default cycle rate. using a different color just for a single value (previously for -1) might be confusing for users.
* Use a constant RGB form of dark sea green color instead of the regular dark green color. these new RGB values have been *tuned* for perf...err perfection!
This syncs the cheats_ws.zip widescreen patches archive with Devina's
archive from 2016-08-07.
The zip file is the zipped content of folder cheats_ws at the archive,
after removing the following 10 known WIP patches: 00000000 1771BFE4
C77AF2CA DA3DD765 07652DD9 FDA1CBF6 CC96CE93 2545CA71 1CE1DA8A CD787D68
Compared to the previous content of cheats_ws.zip:
- 6 files deleted (07652DD9 1CE1DA8A 44D23E5F CC96CE93 CD787D68 FDA1CBF6)
- 49 modified files
- 452 new files (w00t!)
- 1939 files identical to before
The zip now has a total of 2440 patch files, compared to 1994 before.
No functional changes done, the current commit helps us to pass vertical frequency values of individual video modes to GUI code for accurate percentage calculation on titlebar. (which is done on the succeeding commit)
The solution files are unused and for ancient Visual Studio versions -
GSDumpGUI has its own solution file, and bin2cpp is included in the main
solution file.
The property sheets have either fallen out of use or were never used in
the first place.
Fixes a regression introduced by 46ba9aa117,
where the Linux GS replayer would always use the options in inis/GSdx.ini
(or use the default options if that doesn't exist) to replay the dump,
instead of using the GSdx.ini from the specified ini folder.
Update done on f712c5c6d0
Previous code use the size of the draw to compute latest block. I
don't know why I use .x/.y which are the origin offset so the start of the block.
Updated/synced from the online compatibility list.
- Update summary:
Not at dbf (and added): 1
Not at csv (but have compat info at the dbf): 258
Unchanged: 2560
Better compat: 23
Worse compat: 0
- Status before:
Imported entries: 9706
Compatibility 1: 7 games
Compatibility 2: 31 games
Compatibility 3: 48 games
Compatibility 4: 70 games
Compatibility 5: 2665 games
- Status after:
Imported entries: 9707
Compatibility 1: 7 games
Compatibility 2: 29 games
Compatibility 3: 48 games
Compatibility 4: 71 games
Compatibility 5: 2687 games
Check the instruction set first in GPUinit, GPUconfigure and GPUtext
to prevent unsupported vector instructions from being executed.
Move the vector initialisation in GPUinit to a separate function - it
avoids a vzeroupper instruction.
This is a regression from 6db18446 , which, due to correctly applying
the patches when the bios starts, also updated the console title (which
happens at the same function).
So when updating the settings and loading the patches, only update the
console title if we're already outside of the bios.
If the dev/verbose console source is enabled then there's no change.
If it's not enabled (i.e. most users), then:
- Don't show patch info messages twice on boot (regression from 27e7ecce).
- Show patch info messages when loading a saved state (never worked).
- Don't show patch info messages for the bios.
It still doesn't print the info when patches/fixes/etc are enabled or
disabled while a game is running, because such actions while a game is
running can have unexpected effects regardless (for instance, it's
technically impossible to unapply a patch).
If one really wants to follow the exact timing and info about patch
loading, just enable the dev/verbose console source at the console menu.
Also slightly modify the textual description of the other underclock items.
All previous values available at the slider are still there, but since
the new value is now the mildest (slider == -1), it "pushes" the previous
-1 and -2 values one notch down.
This restores the mildest value to be identical to how it behaved before
90b11b2f , which is measured as about 75% speed.
Because the "balanced" preset uses the -1 slider value, it means this
restored mild value is now also used by the balanced preset.
As a note, while the message for the mildest value was always "reduce by
about 33%", before 90b11b2f it was actually about 25% reduction (75% speed,
like with this commit now), and after that commit it was about 40% reduction
(60% speed).
Also, since we add new value to the slider only on one side, the "0"
(default) slider position is now not at the exact middle. That's fine,
but maybe we could also add a milder overclock value on the other side
to have that symetric again.
The ee cyclerate percentage values at the slider text were inaccurate,
and sometimes wildely so.
Add some code to measure the actual speed at runtime (disabled by default)
and update the (static) slider text values according to the measurements.
Also change the description from increase/reduce "by AA %" to "to BB %".
This makes it slightly easier to grasp. E.g. "reduce speed to 10%" is
easier to grasp than "reduce speed by 90%", and similarly, "increase
speed to 300%" is easier to grasp than "increase speed by 200%".
While c782b62 added much more reliable game game startup detection, the
settings system did not yet gain that knowledge, but typically that's OK.
Typically the settings (and patches) are loaded according to the current
CRC, which happens once on bios boot (with general settings) and then again
when the game starts, which includes game-specific fixes, patches, etc.
However, if the setting are changed (and therefore also applied) after
the game CRC is known but before the game starts, such as if the user
presses Tab to change framelimiter while at the bios, then until now it
was accidentally applying the game's settings while still at the bios.
This commit makes the settings routine know whether or not the game actually
started, and apply the generic/game settings accordingly.
Commit 330704a added code which applies the patches before recompiling the
elf entry block, but because at that stage the patches for the current
CRC were not yet loaded, effectively it did nothing.
Now it actually loads the patches before applying them.
As a result, it should now be possible for patches (with place=0) to be
effective before the elf is executed.
This is a hack, because the emulation loads the patches while it's not
paused. It works, but it's not great. A better way would be to pause the
emulation once the entry point is detected, then make the setting get
applied normally (which also loads the patches normally), and then resume
the emulation.
This _should_ properly fix#627 (the test case works as expected now).
Jonathan Li