Gsdx 1.0 #628
Gsdx 1.0 #628
Conversation
Gow uses 24 bits buffer, so only color is updated but blending is configured as Cd so it is a NOP In this case, we don't lookup the target in the texture cache. It reduces the complexity to handle depth which can be located at same address as RT Note: please test DX renderer
…/depth It is requires when game will uses sometimes an address as a RT sometimes as a depth
Yes it is possible on PS2 world
texture_cache_depth = 1 (default for openGL)
Extend the texture cache to search Color target in Depth target
GS doesn't supports texture shuffle/swizzle so it is emulated in a complex way. The idea is to read/write the 32 bits color format as a 16 bit format. This way, RG (16 lsb bits) or BA (16 msb bits) can be read or written with square texture that targets pixels 1-8 or pixels 8-16. However shuffle is limited. For example you can copy the green channel to either the alpha channel or another green channel. Note: Partial masking of channel is not yet implemented V2: improve logging V3: better support of green channel in shader V4: improve detection of destination (issue due to rounding)
Please test SMT games (issue #572)
…urate blending from the GUI
- Forced off for DX currently to save fallover.
This ways it will be disabled for dx
Otherwise it is unreadable
Might not work if depth is recasted as a rt (we lost the alpha channel)
To clear a (W, H) RT/Depth, GS can only send a (W , H/2) primitive with a Z (or RT) pointer in the middle of the buffer Top-half will be cleared by the color (or the depth). Bottom-half will be cleared by the depth (or the color). Code isn't enabled yet but it was tested with success on GoW2.
It fixes games that uses 16 bits RT (like snow engine games)
The idea will be to use the remaining int to store the FB mask
It seems to impacts lots of games that still have issue (VP2, MTG3, PoP) The PSMT32 format is read a PSMT8. I think we need to convert it as PSMT8H (i.e. unpack it to have only an alpha channel)
It might help to fix a bit the color on a couple of games accurate_fbmask = 1 Code uses GL4.5 extensions. So far it seems the effect is ony used a couple of time and often in non-overlapping primitive. Speed impact will likely remain small
… cache It avoid various upscaling glitches on GS post-processing effect // 1/ Palette is used to interpret the alpha channel of the RT as an index. // Star Ocean 3 uses it to emulate a stencil buffer. // 2/ Z formats are a bad idea to interpolate (discontinuties). // 3/ 16 bits buffer is used to move data from a channel to another. // // I keep linear filtering for standard color even if I'm not sure that it is // working correctly. // Indeed, texture is reduced so you need to read all covered pixels (9 in 3x) // to correctly interpolate the value. Linear interpolation is likely acceptable // only in 2x scaling // // Src texture will still be bilinear interpolated so I'm really not sure // that we need to do it here too. // // Future note: instead to do // RT 2048x2048 -> T 1024x1024 -> RT 2048x2048 // We can maybe sample directly a bigger texture // RT 2048x2048 -> T 2048x2048 -> RT 2048x2048 // Pro: better quality. Copy instead of StretchRect (must be faster) // Cons: consume more memory // // In distant future: investigate to reuse the RT directly without any // copy. Likely a speed boost and memory usage reduction.
Code is obviously slow but at least it works. It fixes the blur effect of VP2
"Regression" introduced in 8 bits RT support The case appears when 1/ address of RT is the same as input texture 2/ input format is 8 bits 3/ previous lookup of RT was miss
Improve the rendering in MGS3 (even if the game is still broken due to others TC issues) // Typical bug (MGS3 blue cloud): // 1/ RT used as 32 bits => alpha channel written // 2/ RT used as 24 bits => no update of alpha channel // 3/ Lookup of texture that used alpha channel as index, HasSharedBits will return false // because of the previous draw call format // // Solution: consider the RT as 32 bits if the alpha was used in the past
Code is not ready. It allow to test the new code without a massive regression
|
I will test this tonight, might actually have some free time :P |
|
I propose we add the new logos too ;) |
|
OK DX doesn't seem to fall over or generally look any worse, in fact the blur on VP2 nearly works, which is weird :P MGS3 on minimal crc or lower = 80fps, with partial or higher 180fps |
|
Well blur will (mostly) work if CRC is below full. Great. Let's merge it. So people can test it more easily. |
|
I did get a weird error but i wasn't able to reproduce it, i think i modified some settings then loaded a different game, but i got Totally mismatched window handles on OverrideWndProc! that many times ;p |
|
I think it is a gui issue, likely the tooltip. It might be a good idea to review it a little But I don't know :( |
|
I tried making tooltips come up, swapping renderers, switching settings, bringing the settings up while the emulator was running, escaping then opening them and changing options and resuming, nothing seemed to trigger it :( |
|
Sorry for the noob question, but what does this improve? Are games more accuratelly emulated now in hardware mode both in OGL and DX? |
|
That's the idea, it brings hardware mode closer to software |
I thought the plan was for the next stable release ? |
|
It was for the new version of GSdx, and this is marked as GSdx 1.0 |
|
It got updated to 1.0 as gsdx was like 0.18. even the thread on the forum got changed to 1.0 |
|
Hum, I hope you didn't put 2.0 in the new logo ;) |
|
Nope the logos don't have any number on them ;) |
|
Why hasn't mipmapping been implemented on GSDX hardware mode yet? Is it harder to implement it in hardware than it is in software or it was just lack of time? |
|
For sure it is harder to implement on HW. The complexity of mipmap in HW is the texture management. If game uses mipmap in a traditional way, it must be doable. However it could be easily a nightmare. GS textures doesn't really have a size, neither a format. GS textures are a pointer to a raw data + an header of how to interpret them. It takes times. It took me 3 months to add proper support for pseudo 8 bits/16 bits texture conversion and real depth support. Mipmapping is just a small part of GSdx limitation. |
|
Wow, I didn't know it was so complicated, it's usually simple in other systems. Do you think DX12 and Vulcan will allow such things to be implement in hardware easier? |
Ok time to merge the big change.
@refractionpcsx2
Could you check latest addition still compile on windows and DX is still working as bad as before.