An KHR_debug callback could end up waiting for a mutex
on a thread which calls windows system functions.
While this is not expressly forbidden by the standards,
it does forbid directy calling windows system functions
from a KHR_debug callback. Close enough.
Instead of having special case code for efb2tex that ignores hashes,
the only diffence between efb2tex and efb2ram now is that efb2tex
writes zeros to the memory instead of actual texture data.
Though keep in mind, all efb2tex copies will have hashes of zero as
their hash.
Addded a few duplicated depth copy texture formats to the enum
in TextureDecoder.h. These texture formats were already implemented
in TextureCacheBase and the ogl/dx11 texture cache implementations.
The last heuristic wasn't quite smart enough and had a few
false positives in Mario Kart: Double Dash and Metroid prime 2.
Now we only activate if the game is rendering a 16:9
projection to a 4:3 viewport.
Someone suggested on IRC that we should make a database of memory
locations in GameCube games which contain the 'Widescreen' setting
so we can automatically detect if the game is in 4:3 or 16:9 mode.
But that's hardly optimal, when the game actually tells the gpu
what aspect ratio to render in. 10 min and 6 lines of code later,
this is the result. Not only does it detect the correct aspect ratio
it does so on the fly.
I'm a little suprised nobody thought about doing this before.
fcmpo and fcmpu can be matched by the REORDER_CMP pass, as they set CR0
and they can cause interrupts if the fpu is disabled.
So we add an extra check to make sure op a is an integer op too.
The constructor sets up way_from_valid and way_from_plur as fast lookup
tables for implementing the PLRU algrothm. Then the Init function
memsets them to zero, meaning the instruction cache will now always
choose the first way in each set.
This degrades the cache from 128 sets, 8 way to 128 sets, 1 way.
Not only does fixing this bug increase accuracy, but it increases
preformance too, giving a 1% speedup to interpreter.
Instead of opening... and... closing... files... after... every...
file... operation... (which can be slow, especially if a virus scanner
is running), we catch attempts to open the same file twice and
only open one copy of the file.
Dolphin uses threads, but never actually pulled them it. Normally
some library we depend on would pull threads in, but there are
potential builds that forget to pull in threads.
Not deleted, because it's the only option for some other operating
systems such as FreeBSD or any other slightly exotic operating
system someone might try and run dolphin on.
On the first boot of Pokemon Snap it copies a 144KB file to the Wii's
NAND, but it only copies 32 bytes per IPC write call.
This was causing dolphin to open and close the same file over 4000
times. This wouldn't usually be a huge issue, except some operating
systems (namely Windows) allow 3rd party programs (namely antivirus
software) to hook all accesses to the filesystem.
This causes the antivirus software to scan the same file for viruses
4000+ times, which is kind of slow.
This fix reduces the initial boot time of pokemon snap from 3+ min
to just a few seconds. Could also improve other games which write
things to NAND.
Will break a few things, see the next commit for an improved fix.
Yet another story of games loading weird shit into registers.
For some reason, Burnout 2 would (in rare situations) load invalid
addresses into cp_state.array_bases. What would the real hardware
do in this situation? Who knows, Burnout 2 doesn't actually enable
the vertex array with the invalid address so nothing kinky happens.
But dolphin tries to optimise things and starts using the address
as soon as it is loaded into memory. This causes GetPointer (which is
now much more vocal) to throw an error.
The Fix: We don't call GetPointer until we are sure the vertex array
has been enabled.
For floating loads with a known address, this eliminates the pattern of:
mov r12d, 80001014
mov rdx, r12d
mov rdx, dword ptr [rbp+rdx]
and generates a nice simple:
mov rdx, dword ptr [rbp+00001014]
Instead of swaping each word of the elf code section(s) looking
for a match to our pattern, we swap the pattern just once (at
compile time) and test against our swapped pattern.
* Don't claim to support any features we don't, like relocation
* Actually zero-out BSS sections, as memory might not be already
zeroed.
* Deleted commented out code.
* Removed GetPointer, updated to more modern interface methods.
* Updated pointer types style from "u32 *x" to "u32* x"
* The file already exsists, otherwise we wouldn't have gotten
this far in the boot.
* We have already checked if it's a Wii or GameCube elf,
besides, it's too late to change our minds now anyway.
* On Wii - Don't call EmulatedBS2, it can never succeed as
it knows nothing about booting elfs. Just call the
SetupWiiMemory directly if needed.
* On GameCube - We still call EmulatedBS2_GC, but we stop
it from running Apploader, which might boot something
unexpected from the default iso or DVD root folder.
Results are still not correct, but things are getting closer.
* Don't cull CULLALL primitives so early so they can be used as reference
planes.
* Convert CalculateZSlope to screenspace coordinates.
* Convert Pixelshader to screenspace coordinates (instead of worldspace
xy coordinates, which is totally wrong)
* Divide depth by 2^24 instead of clamping to 0.0-1.0 as was done
before.
Progress:
* Rouge Squadron 2/3 appear correct in game (videos in rs2 save file
selection are missing)
* Shadows draw 100% correctly in NHL 2003.
* Mario golf menu renders correctly.
* NFS: HP2, shadows sometimes render on top of car or below the road.
* Mario Tennis, courts and shadows render correctly, but at wrong depth
* Blood Omen 2, doesn't work.
Previously it was packed into spare slots in clippos.xy and normal.w,
but it's ugly and more importantly it's causing bugs.
This was discovered during the debugging of a zfreeze branch, which
expected clippos.xy to be xy position coordinates in clipspace (as
the name suggested).
Turns out the stereoscopy shader had also run into this trap, modifying
clippos.x (introducing errors with per-pixel lighting).
This commit has been moved outside of the zfreeze PR for fast merging.
Fixes#7917
The first memset was clearing the delicate bits of the std::string
in the struct, causing segfaults.
I also removed the rest of the memsets because they were paranoid,
unneeded and waseful. We shouldn't be managing the ssl libraries
structs for it.
I checked and the ssl library's functions were already memsetting
those structs as needed.
We will now rely on Memory::CopyFromEmu to do bounds checking.
Some games actually load palettes from 0x00000000, despite the
fact no valid palette data should ever be there.
Fixes Issue 7792.
Scott Mansell