[Bug 39057] Support for Indexed Vertex Blending

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=39057

swswine at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52830|0                           |1
        is obsolete|                            |

--- Comment #55 from swswine at gmail.com ---
Created attachment 52947
  --> https://bugs.winehq.org/attachment.cgi?id=52947
Patch to implement indexed vertex blending (updated), wine 1.8-rc2

(In reply to Matteo Bruni from comment #54)

> I would probably drop indexed vertex blending with plain uniforms
> altogether, it looks too messy and e.g. allocating extra ~1KB for
> modelview_matrix_location[] for each GLSL shader doesn't seem justifiable.
I am not comfortable dropping it because the only person who actively tests my
patch here is keen of running it under GL 2.1 :)). IVB might be used by old
games working fine on old hardware, should not we attempt to support it?
Actually I set only 150 matrices if no UBO, so it just 600 bytes. It can be
further reduced by making it dynamic, so the space will be allocated only for
the shaders which actually use IVB (if it is not too messy for these 600
bytes). It seemed to me that the most messy part is selective matrix update
logic which is currently more tricky for the UBO part. But if you are sure that
it is better to drop non-UBO support than I will of course drop it.

> You should probably add a separate field in d3d_info.limits for the indexed
> limit (and avoid touching ffp_vertex_blend_matrices) and use it where
> necessary. You should also report 0 (or 8, but since there is real hardware
> on Windows returning 0 that is okay) indexed vertex blending matrices for
> devices not created with the D3DCREATE_SOFTWARE_VERTEXPROCESSING flag (I
> think you can look that up from device->create_parms.flags).

done. Considering D3DCREATE_SOFTWARE_VERTEXPROCESSING flag looks a bit messy as
done outside the function where all the caps are filled in, but this function
(wined3d_get_device_caps in directx.c) does not have access to device structure
and thus can't get that flag. Changing its parameters is tricky as it is
exported function and changing it will require fixing it's call across the
tree. I've verified that the wined3d_device_get_device_caps in wined3d/device.c
actually used in d3d9 GetDeviceCaps implementation, and tested that reported
capabilities are those we expect.

> I don't think you need a static variable (or a variable at all) to store the
> next update_id value, unless I'm missing something.
I've changed this part now: I figured out now how to get a link to a shader
priv structure from the context update handler and replaced transform context
update versioning  with just a plain flag in shader_priv structure.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.