[Bug 41930] Civilization III Complete shows black terrain (Wine compiled with OSMesa support)

[WineHQ Bugzilla]

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

--- Comment #43 from Bryan Varner <bryan at varnernet.com> ---
In gdi32/bitblt.c, nulldrv_StretchBlt(...) is responsible for determining what
putImage implementation to use when StretchBlt is called upon a source and
destination.

By default, it uses the nulldrv_StretchBlt(), which delegates to the
_destination_ StretchBlt() implementation. This seems to make sense except in
the case of:

* A WGL off-screen pbuffer source using 
* With alpha blending enabled in the GL Context
* Using precomputed alpha in a 5_6_5 pixelformat (or any that doesn't include a
dedicated Alpha channel)


In this case, an ROP of SRCCOPY should be carried out as a SRCPAINT, to OR the
pixel values into the destination.

This seems like an awful lot of source state to be discovered by the
destination in dibdrv_PutImage(), especially without the DC for the src being
passed in as a way to validate against a current (if any) GLContext.


If there was an easy way to hook this so that the source driver was used for
the PutImage function rather than the Destination driver, but the contexts for
both were passed to PutImage, we could centralize this into a new driver
function for osmesa_PutImage(...) have it massage the ROP in the proper
context, and then defer to invoke the destination pPutImage with the proper
ROP.

Or that might be a terrible idea and I'm missing the obvious fix.

-- 
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.