A multi sector raw disk sector read that reads data from two tracks of
different types will not complete successfully. Reading the sectors one
at a time should fix the issue.
Fix Berserk #1526 Well done guys but we're more clever than you ;)
So instead to mask the color channels as any guy that RTFM, they decided to use the illegal 8H frame format
WMS/WMT 2 is the region clamping mode.
Hw unit can't emulate it right so it can give you bad filtering (Fix#1025)
Note: I only did the fix because I wanted to remove the TEXA hack. Otherwise
it is still recommended to use openGL
It must work fine without it now.
From the google code comments:
It would be nice to test those games
* Ar Tonelico 2 (line in sprite regression?)
* breath of fire dragon quarter (overlayed user interface in the game)
v2: update Dx code to use the good format
* As sw renderer, don't bother to bypass it when it is ATST_ALWAYS
* Don't update the ATE register value
=> It is a really bad idea. Next draw call will be wrong if TEST register isn't written.
The TryAlphaTest context could have been updated
GS really uses an invalid texture located at 0.
Improve the rounding for R&C. The idea is to avoid the corner case were only
the corner of the triangle touch the 7/16 edge.
* Always do +1 before the draw call
* Prefix texture name with i (as input) to keep them before the FB
Goal is to ensure that all renderers share the same draw call value.
Game: harley davidson
* write tex0 ctx0
* write tex0 ctx1
* draw ctx 0
Previous GSdx behavior will load the clut every write of TEX0. In the
above case the draw will take the wrong clut.
To be honest, it could be a wrong emulation on the EE core emulation.
The hardware likely got a single clut (1KB cache is quite expensive)
So clut loading must be skipped if the context is wrong.
Next draw will use the ctx1 clut so I apply TEX0 when the context is switched
Please test harley davidson :)
v2: detect context switch from UpdateContext function
V3: always set m_env.CTXT[i].offset.tex, avoid crash (Thanks to FlatOutPS2 that spot the issue)
V4: move bad psm correction code (rebase put it in the wrong place)
Free bt
3 0xe676d194 in ~Source ../plugins/GSdx/GSTextureCache.cpp:1526
4 0xe676d194 in GSTextureCache::SourceMap::RemoveAt(GSTextureCache::Source*) ../plugins/GSdx/GSTextureCache.cpp:1990
5 0xe676f0fe in GSTextureCache::IncAge() ../plugins/GSdx/GSTextureCache.cpp:1022
Use bt
0 0xe6772a83 in GSTextureCache::LookupSource(GIFRegTEX0 const&, GIFRegTEXA const&, GSVector4i const&) ../plugins/GSdx/GSTextureCache.cpp:204
1 0xe66b0c9f in GSRendererHW::Draw() ../plugins/GSdx/GSRendererHW.cpp:579
2 0xe66fb43e in GSState::FlushPrim() ../plugins/GSdx/GSState.cpp:1509
Hypothesis the m_map array of list contains an invalid pointer
It is populated GSTextureCache::SourceMap::Add based on the coverage. The coverage is based on the offset.
So offset is potentially wrong. As mipmap code hack the offset value. It would be a nice culprit.
This commit avoids a potential bad transition between MIPMAP (which
overwrite the "offset") and the base layer (which wrongly keep an old "offset")
Conclusion, pray for my soul as it is very hard to reproduce
Ratchet & Clank (the third) uses an address of 0 for invalid mipmap.
It would be very awkward to put the middle layer of texture in start of
memory. So let's use this information to correct the lod.
It make the game more robust on the lod rounding
* Use texraw for the unconverted texture (keep index fmt)
=> avoid bad filename order with the multiple texture layers
* add the real mipmap address
* Use a nice string format
The SPTI code is unused, and it's simpler to just use the Windows
ioctls/API if they work (only raw disk sector reading is an issue and
the SPTI workaround is already in place).
It doesn't support dual layer ISO images, and the ini has to be edited
manually so it loads an ISO image ("$" has to be prepended to the ISO
path as well). The PCSX2 internal ISO file reader is probably better in
most/all aspects and I don't think it's worth copying the logic from
PCSX2 into the plugin.
gsdx ogl: only use geometry shader to convert big enough draw call
The purpose of geometry shader is to reduce bandwidth (72 bytes by sprite)
and CPU load.
Unfortunately it increases CPU load due to extra shader validations.
So geometry shader will only be enabled for draw call with more than
16 sprites (arbitrarily, smallest number before shadow hearts plummet)
v2: don't disable geometry shader in replayer.
It is easier to spot sprite rendering and to manually read vertex info.
Warning can be reenabled on GCC
A warning isn't fixed as potentially the code is wrong
../pcsx2/gui/MemoryCardFolder.cpp: In member function ‘void FolderMemoryCard::FlushFileEntries(u32, u32, const wxString&, MemoryCardFileMetadataReference*)’:
../pcsx2/gui/MemoryCardFolder.cpp:1027:10: warning: unused variable ‘filenameCleaned’ [-Wunused-variable]
bool filenameCleaned = FileAccessHelper::CleanMemcardFilename( cleanName );
Strangely the game uses large texture to handle texture buffer.
I think it plays with WMS/WMT. I'm not sure texture shuffling is 100%
correct here. But without it, it's completely broken.
* 0x9C712FF0, Jak1, EU
* 0x472E7699, Jak1, US
* 0x2479F4A9, Jak2, EU
* 0x12804727, Jak3, EU
* 0xDF659E77, JakX, EU
Please report me the CRC of the US version too so I can add them.
Please test the shadows rendering (openGL HW + accurate blending at least basic)
The game sets the framebuffer as an input texture. So I did the same for
openGL. Code is protected with a CRC. It is working because the game want to sample
pixels.
For the record, I tested it GTA too, it doesn't work as expected because
the game will resize the framebuffer to a smaller one. So you don't have
the guarantee that pixel will be read before a data write.
Note: it requires at least accurate blending set on basic
Note: I need CRC of all Jak games that suffers of this issue. Thanks you :)
Default copy-constructor is eight 32 bits move
GSRendererOGL::Lines2Sprites code shrinks from 510B to 398B
(loop of the function 296B => 181B). Hopefully it will reduce the cost
to convert line to sprite on the CPU (i.e. when geometry shader is disabled)
It impacts all renderers. It ought to fix issue in GTA radiosity,
Shadows in Jak series. (note shadows will suck in upscaling)
Implementation is really brutal. Expect a massive slow down, but at least we can test the effect
easily.
Normally perf impact will remain reasonable if the game doesn't use a Read-Write effect
Performances number are welcomes (my guess is really awful in HW mode, slow in SW mode).
You can enable it with "UserHacks_AutoFlush = 1"
GS memory is only 4MB but rendering is allowed to be 2048x2048
with 32 bits format (so 16MB). Technically the frame/depth buffer can start
at the end of the GS memory. Let's not waste too much memory.
Fix crash with BASARAX
(game draws a 2048x1664 32 bits area)
The hack only fix the HW renderer but not the SW renderer. However I'm not sure
the issue is from GSdx.
The hack will disable alpha test that used to generate empty draw call.
Manual gives all setup to upload a palette from the host. But nothing forbid to render
directly in the palette buffer. (GS rule nb 1, there is no rule ^^)
Fix Virtua Fighter 2 dark colors
However I'm not sure we can fix HW renderer. Rendering is done on the GPU but palette
handling is done on the CPU... So we need to read back data (ouch, and slow). A quick
test didn't get the expected results. Potentially there are others bugs (aka not gonna
happen on the HW renderer)
IOCTL_CDROM_RAW_READ apparently does not work for some read modes on
some optical drives, which makes some CD-ROM games unplayable from the
disc.
Work around the issue by using SPTI to retrieve the raw sector data. The
old reading method has been retained in case SPTI cannot be used (if the
device could not be opened with write access).
Fix motocross mania missing texture. Close#1319
As far as I understand, transfer is initialized in DIR. But the real
write only occured later so the blit buffer could have been overwritten
by a new value.
BLIT 0 13700
TREG 40 40
DIR 0 0
BLIT 0 13f00 <=== the bad guy
Write! ... => 0x3f00 W:1 F:C_32 (DIR 00), dPos(0 0) size(64 64)
v2: set a value in m_tr.m_blit for load state
It creates a regression on game that uses a small temporary target to
upload textures of various sizes. Inital code was done to handle direct
frame write (background, FMV) so big target
Purpose is to control the filtering when final image is displayed on the screen
Could improve the sharpness of the output in some games (ofc, it will be pixelated)
When depth primitive is constant and depth test is greater or equal, we can
execute the depth write after color (depth status will only depends on the initial
value)
New case for RGB_ONLY ate:
If the blending equation uses a fixed alpha or a source alpha. We can postpone the alpha write
in a 2nd pass.
If depth can also be postponed, we can guarantee the order of correctness of the value.
1st pass => do RGB
2nd pass => do Alpha & Depth
It fixed Stuntman letter rendering :) Remaining of the game is still broken :(
At higher resolutions it takes too much time to save a screenshot at the
maximum compression level. So let's allow the user to set the
compression level.
This re-uses the png_compression_level setting. The default compression
level is 1 for speed, but if the user wishes to increase the compression
level (without using an external tool) and doesn't mind if the
screenshot takes more time to save then they can increase the
compression level up to a maximum of 9 (which can take quite a while).
Fixes#1527.
PNG_LIBRARIES adds both libpng and zlib to the command line.
PNG_LIBRARY only adds libpng to the linker command line, and the cmake
documentation also suggests not to use it.
Value seems wrongly rounded and you can't distinguish 0xFFFF from 0xFFFE
Instead check that depth is constant for the draw call and the value from the vertex buffer
Fix recent regression on GTA (and likely various games)
In FB_ONLY mode the alpha test impacts (discard) only the depth value.
If there is no depth buffer, we don't care about depth write. So alpha
test is useless and we can do the draw with a single draw call and no program
switch
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.
Gregory Hainaut