please test for regressions and fixes.
some little changes to make pixel shader more dx9 sm2.0 friendly. the condition is not to use pixel lighting ( sorry no hardware support for the quantity of parameters needed).
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6777 8ced0084-cf51-0410-be5f-012b33b47a6e
The code now uses direct pointer access from C code to write the colors to the destination texture instead of trying to force them back up into an __m128i and a single write call. This is what produces the major speed-up.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6761 8ced0084-cf51-0410-be5f-012b33b47a6e
* Fixed a bug on Texture Converter when Copy EFB to RAM's cache is disabled, so...
* ...accordingly, I revert my latest commit because now it becomes useless.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6760 8ced0084-cf51-0410-be5f-012b33b47a6e
- Assign width and height to the actual powers of two rather than to the exponents...
- Clean up FramebufferManager()
- Make use of more depth buffer formats to prevent some devices from failing to create a depth buffer
Should fix issue 3256.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6730 8ced0084-cf51-0410-be5f-012b33b47a6e
the private SVN_REV_STR which relies on finicky build mechanics.
With SCons, kill the old svnrev.h in Source if still present.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6715 8ced0084-cf51-0410-be5f-012b33b47a6e
GX_TF_RGBA8 texture decoder optimized with SSE2 producing a ~68% speed increase over reference C implementation.
TABified the entire document per NeoBrainX. :)
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6706 8ced0084-cf51-0410-be5f-012b33b47a6e
~25% speed improvement in decoding GX_TF_RGB5A3 textures which aren't used very much. I thought it would help for movie playback but I misled myself. Video playback has nothing to do with this texture format.
Next I'll see if I can knock out some of these other texture decoders. Byte swizzling I'm sure can somehow be accomplished using _mm_unpacklo_epi8 trickery, so that'd be another big win I hope.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6698 8ced0084-cf51-0410-be5f-012b33b47a6e
TextureDecoder.cpp: merged two functionally identical decode5A3RGBA and decode5A3rgba methods.
OpcodeDecoding.cpp and DLCache.cpp: optimization for GX_LOAD_XF_REG. The PSUHFB solution sounds better for SSSE3, but this is a small win for the default case.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6692 8ced0084-cf51-0410-be5f-012b33b47a6e
Whatever that means, it fixes that stupid Super Mario Sunshine glitch and possibly lots of other stuff, so test as many glitchy games as possible with this ;)
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6669 8ced0084-cf51-0410-be5f-012b33b47a6e
Should fix almost all regressions of the recent ClearScreen changes and keep the fixed stuff.
The Super Mario Sunshine glitch is caused by another issue and will be addressed in my next commit.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6668 8ced0084-cf51-0410-be5f-012b33b47a6e
corrected peek color and peek z to correctly emulate real hardware formats.
implements native gamma correction.(i don't own any game that uses this functionality so i will appreciate feedback)
i need a lot of feedback in this changes please
enjoy
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6664 8ced0084-cf51-0410-be5f-012b33b47a6e
make some changes to the Clear code. please test a lot , the point of this commit is to determine the correct behavior of the efb clearing so feedback is welcome
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6663 8ced0084-cf51-0410-be5f-012b33b47a6e
1) What is the FIFO? The fifo is a ring queue for write (CPU) and read (GPU) the graphics commands.
2) What is the Brakpoints? The breakpoint is the FIFO mark to allow parallel work (CPU-GPU) When the GPU reached the breakpoint must stop read immediately until this Breakpoint will be removed for the CPU.
3) What is an overflow? The CPU write all room FIFO possible, and like a ring overwrite commands not processed yet.
4) ¿Why you have an overflow? In theory should not have an overflow never because the fifo has another mark (High Watermark) When the CPU Write reach this mark raise a CP interruption and the FIFO CPU WRITES should stop write until distance between READ POINTER AND WRITE POINTER will be equal to another mark (LO Watemark to prevent and overflow.
5) ¡So if impossible why you have overflows? Simple, the CP interruption is processed later and the Overflow happens. (there is a lot of theories about this)
6) ¿Why is no so simple like when CPU WRITE POINTER is near to the end of the FIFO only process pending graphics command?
Because when this happens sometimes we are in BREAKPOINT and is IMPOSIBLE process the graphics commands.
- This HACK process the pending data when CPU WRITE POINTER is 32 bytes before the end of the fifo, and if there is a Breakpoint force the situation to process the commands and prevent an overflown.
In theory you have not see "FIFO is overflown by GatherPipe nCPU thread is too fast!" anymore. But if you have a hang in game where you had this please read the NOTICE LOG in user\logs, I've added this message "FIFO is almost in overflown, BreakPoint" when the hack is activated. (I will delete this message very soon)
Good Luck!! PD: Shuffle sorry for the large commit description :P
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6662 8ced0084-cf51-0410-be5f-012b33b47a6e
logging: turn off write to file
core: don't insert anything in memcard b slot
video: efb scale to integral, AF to 1x
audio: 100% volume, 48KHz sample rate
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6650 8ced0084-cf51-0410-be5f-012b33b47a6e
Rodolfo Osvaldo Bogado