Fixes rendering at thousands of FPS when pausing if FSUI is active.
Avoids flickering when recreating swap chain in vulkan on menu open,
because we're no longer doing it.
Guest memory is now mapped into a shared memory/file mapping, for use
with fastmem.
64-bit and 128-bit arguments are passed by register/value instead of by
reference/address.
LDL/LDR/SDL/SDR now use 64-bit GPRs instead of SSE.
These have no meaning in x64 (apart from throwing compiler warnings),
and we don't do 32-bit anymore. Also saves needing to include
`Pcsx2Defs.h` in files which don't otherwise need it.
The scalar limit value was updated only during any turbo/slowmotion
toggle, let's also update it properly after any change in the emulation
settings.
This prevents the need of toggling from turbo/slowmotion to update to
your requested frame rate percentage.
Improved the video mode detection code by also detecting the DVD variant video modes of NTSC & PAL, PSX mode actually make use of these specific variants, as well as the BIOS. Previously, I just had them as a single bios video mode due to laziness. (I know, my bad)
After further research, it seems that these DVD variant modes have their own individual VSync timing values similar to the standard NTSC & PAL video modes, dealing with those timer codes might be essential in getting timing accuracy of the PSX mode games. (I kept it to default NTSC/PAL values for now, interested people can mess with it later)
I had planned to do this before but there some were concerns that two different video modes make use of 0x73 gate in SetGsCrt, which was rather weird (how the heck could two video modes be used in a single param value?)
0x73- DVDPAL ( 720 x 480 @ ??.???Hz)
0x73- DVD480P ( 720 x 480 @ ??.???Hz)
Hence, we had decided to use the CMOD bit from SMODE1 (AKA color subcarrier frequency) to detect whether it's an analog or digital video mode and update the necessary timing values but seems like it's no longer necessary, after further discussions from some PS2 developers, we've come to the conclusion that only DVDPAL is possible via 0x73 in SetGsCrt. (So I assume the DVD480p init possibility was fake info from Blue and those other GSM guys who were reverse engineering the PS2)
Previously, the code used a lot of "bitwise AND" to get specific bitfields of the interrupt mask control register, which makes the code look a bit hacky, also it's even more hard for normal people to calculate the value when hexadecimal values are used for the bitwise operations where the register is totally binary. Instead of dealing with all those mess, let's just get the bitfield values from the already implemented nice union of the IMR register. FWIW it also makes the code more readable.
Previously the video mode was initialized using the info fetched from SetGsCrt Syscall though unfortunately, it doesn't seem to work with PSX games as they don't use the SetGsCrt syscall. At such cases, we get the video mode info from the SMODE2 colorburst to properly maintain the timing as per the video mode. Might help some cases on PSX games where PAL/NTSC video mode was improperly set to a wrong limit instead of it's actual vertical frequency limit.
* More accurate to PS2 behavior and avoids an useless SMODE write function, it makes sense to also move this as video mode specific colorburst detection was already moved to SetGsCrt.
Technically there's no term called "RegionMode" and the values obtained through the SMODE1 register is actually used for identifying the video mode of the game not any region modes.
* Convert "GS_VideoMode" into an enum class
* The detected values using the SMODE registers were for the video modes and not the region of the game, changed the variable naming to video modes to prevent any confusions.
* Fix a bug where 1080I was reported as progressive
* Convert GS_VideMode into an enum class
* Move VideoMode init code from _gsSMODEwrite to SYSCALL
* PCSX2 will now correctly report whether the video mode is NTSC/PAL/VESA/480p/576p/720p/1080i/1080p
I'm expecting something to break, it's my code, it's bound to. But i have tested some 40 games without problems, so my hopes are high!
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5551 96395faa-99c1-11dd-bbfe-3dabce05a288
The detection is based on a quickly reversed smode1 flag and needs to be done properly.
The timing itself also needs reversing and has only been tested on the VP2 intro video.
(That video now runs without audio / video desync when progressive scan is enabled :) )
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5179 96395faa-99c1-11dd-bbfe-3dabce05a288
Threading VU1 took a lot of rewrites and new code to make possible (MTGS, microVU, gifUnit...), but we finally got to the point where it was feasible, and now we've done it! (so now everyone can stop complaining that pcsx2 only takes advantages of 2 cores :p).
The speedups in the games that benefit from it are great if you have a cpu with 3+ cores (generally a 10~45% speedup), however games that are GS limited can be a slowdown (especially on dual core cpu's).
The option can be found in the speedhacks section as "MTVU (Multi-Threaded microVU1)". And when enabled it should should show the VU thread-time percentage on the title bar window (Like we currently do for EE/GS/UI threads).
It is listed as a speedhack because in order for threading VU1 to have been a speedup, we need to assume that games will not send gif packets containing Signal/Finish/Label commands from path 1 (vu1's xgkick). The good news is very-few games ever do this, so the compatibility of MTVU is very high (a game that does do this will likely hang).
Note: vs2010 builds and Linux builds need to be updated to include "MTVU.h" and "MTVU.cpp".
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4865 96395faa-99c1-11dd-bbfe-3dabce05a288
The problem as I understood is is incomplete COLCLAMP support.
Thanks to sudo for the hack :)
(Unfortunately we couldn't find out more about why these FMV also *all* flicker.)
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4837 96395faa-99c1-11dd-bbfe-3dabce05a288
- Fixed a bug with mVU's ESIN implementation. This finally fixes the flower-petal bug in Radiata Stories (and hopefully the clouds-bug in VP2 but havn't tested). Rama and I have wanted to fix this for a long time, but never knew the problem :p
- Improved implementation of some undefined behavior that happens on branches to take into account pipeline stalls.
gif / vif:
- Added some logging code that parses gif packets. It can be enabled by the PRINT_GIF_PACKET macro in Gif.h
- Deleted some old gif code.
- On ReadFIFO_VIF1() clear the out-reg to prevent uninitialized results in case GSreadFIFO() doesn't modify it...
- Create a fallback for GSreadFIFO2() so that its always defined (as long as the plugin implements GSreadFIFO())
pcsx2:
- Organized the virtual folders in vs2008 a bit...
Note: vs2010 and Linux builds need to be modified to add Gif_Logger.cpp and delete GIFpath.cpp
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4835 96395faa-99c1-11dd-bbfe-3dabce05a288
this should be the only time that an explicit flushing is needed.
doing it this way should be faster than flushing every incomplete gs packet like r4829 was doing...
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4831 96395faa-99c1-11dd-bbfe-3dabce05a288
refractionpcsx2