Texture updates have been moved into TextureCache, while
TMEM updates where moved into bpmem. Code for handling
efb2ram updates was added to TextureCache.
There was a bug for preloaded RGBA8 textures, it only copied
half the texture. The TODO was wrong too.
Instead of blindly using the expected width, clamp it to the stride of the
buffer which dx11 returns. This prevents use from reading invalid memory
at the end of textures.
This doesn't solve the base issue of what to do when a game tries to copy
from outside the efb. On real hardware it returns random noise (biased
to all ones)
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.
Scott Mansell