Extend GSVector to support float move
Initial code likely used integer move for performance reason. However due to
the nan correction, register is now in float domain.
I hope it wasn't done on purpose.
CID 168624 (#1 of 1): Missing break in switch (MISSING_BREAK)
unterminated_case: The case for value CMD_CONFIG_MODE is not terminated by a 'break' statement.
CID 168626 (#1 of 1): Uninitialized scalar field
uninit_member: Non-static class member m_end_block is not initialized in this constructor nor in any functions that it calls.
Fix rendering issue on letters on Kengo/burnout 3/...
Default algo will execute the alpha test in 2 passes. However due to blending
you can't handle accurately the color.
Fortunately for us, the rendering uses an always pass depth test so you
can execute first all the color rendering (which doesn't depends on the alpha test)
And then the depth part which depends on the alpha test.
* Code was factorized a bit with the help of max_z
* Add an extra optimization if test is ZTST_GEQUAL and min z value is
the biggest value. Z test will always be pass.
Note: due to float rounding (23 bits mantissa vs 24 bits depth) the test
is done against 0xFF_FFFE and not 0xFF_FFFF. It is wrong but GPU will
also use float so impact will be null.
CreateEvent and CreateThread return NULL on failure, not
INVALID_HANDLE_VALUE. This should have been done in
0477e03965, I didn't check thoroughly
enough.
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.
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.
vector push_back causes a SIGILL signal on a Nehalem (SSE4.2) QEMU VM
when compiled with GCC 6.1.1.
However, an empty constructor causes illegal instruction exceptions to be
generated on a Windows VM.
So here's an inbetween that looks stupid but works on what I've tested.
Not tested
* rumble
Save/load state will be implemented in the next commit
v2:
* Print current deteced pad mode
* fix dpad button tranmission
close#366
Fix#1457 (GTA)
The game uses a depth format for a pure color buffer (cokes do ravage
in gaming industry)
However I'm really afraid that it migth break another effect in other games.
Combine all the different configurations together so the project files
are more generic and maintainable.
Also standardise the layout so all the project files will be similar and
all have the same standard elements (even if empty).
Add 64-bit configurations.
Additional specifics:
spu2-x: FLOAT_SAMPLES preprocessor definition removed since it's unused.
Use a relaxed atomic to read the exit variable in the hot path
Wait that exit is deasserted in the destructor, so we are sure the
thread will "soon" return
Value could range from 1 to 9. Default is 4 and it is potentially the
best option. Feel free to test some values on your system, behavior
might depends on the core number and thread number
Value is exponential so 4 is 2 times more pixels than 3.
Small value increased thread overhead, big value increase wait/sync latency
memory overhead by thead is only 256KB
However it will reduce the probability to block the push thread to nearly 0
I tested a couple of dumps and only manage 4000 element with 1 extrathread.
Add a factor 2 on the VRAM to get the quantity of available memory for the textures.
The driver is allowed to put some textures in RAM. Of course it is bad for performance
but it won't crash.
Due to the 4GB by process limit, I keep a (reasonable) maximum of 3.8GB.
In order to avoid a crash when memory is too low an exception will be risen
with no guarantee on rendering and big performance impact. In this situation
you ought to reduce upscaling/disable large framebuffer.
* Does the first vsync (start counter) after the sleep
* Dump data after the rendering, avoid to count extra destructor,sleep time
* Dump data into a basic csv file (if people want nice graph)
There is only a single event queue, so you need to detect the pad based
on the configuration
Mouse/Wiimote is limited to first pad
Related to issue #1441
Gregory Hainaut