The gta issue is a side effect of render scaling, the half pixel offset helps if I recall.
(05-03-2015, 09:11 PM)Ōkami Amaterasu Wrote: [ -> ]i think this'll work.
but really, an attachment limit lower than 6K seems absurd
It's not supposed to be that low, it's a server misconfig from when we migrated. Hopefully it will get fixed soon.
(05-04-2015, 12:13 AM)refraction Wrote: [ -> ]The gta issue is a side effect of render scaling, the half pixel offset helps if I recall.
Hum I'm need to check but I have the error message so I think it is blending related. It also appears in native mode.
Quote:Impossible blend for D3D: (Cd - Cs) * 128 >> 7 + Cd
Ok. It is a good gs example. The impossible blend is only used for a single draw call without primitive overlapping. It won't be too costly to emulate it in the fragment shader. However I need to change a bit the architecture of the opengl renderer.
Would be cool if you can fix that
Yes, I just don't know what will be the best solution.
1/ Either use half-float for the render target (would help color clipping)
Pro => it can be unclamped (be outside of [0:1]). So you can still use the blending unit.
Pro => support primitive that overlap
cons => need a 2nd pass to clamp/wrap the result
cons => bandwidth requirement for big upscale
cons => interaction with texture cache
2/ Either use a FS blending (require GL4.5 extension)
Pro => easier to implement (still use standard render target)
Cons => need to split draw call in non-overlap draw calls
Cons => more FS power requirement for big upscale
It boiled down to the number of time those blending effect are used and how game designer make them (single big sprite (like GTA) or lots of small triangles).
Well, if it is only a single draw call, the overheads for such an operation shouldn't be too high, considering the first is more compatible it might be better to go with that (aside from the texture cache bit, i feel for you buddy
), it would be also nice as it could benefit the DX side as well in more than just GTA potentially.
So I would say option 1 would be the best solution
the second one would be significantly easier to implement. Are there any examples were the impossible blends are primitively overlapped ? if there aren't any then, why not go for the second one ?
Hum for 1/
Either we always use an half float RT (colors is 16 bits instead of 8), big cost in all draws calls
Or maybe we could
1/ convert RT from char to half-float
2/ do the draw
3a/ wrap or clamp color
3b/ convert back the RT from half-float to char
I need to check how 1&3b can be done. Maybe 3a/3b can be merged together. This method is interesting because it is transparent for the texture cache.
Quote: the second one would be significantly easier to implement. Are there any examples were the impossible blends are primitively overlapped ? if there aren't any, then why not go for the second one ?
Nobody know. The error message appears only once at the blend state "compilation". Game can reuse it later for a lot of effects.