[Bug 52684] Command and Conquer Generals (and C&C Zero Hour) have no ground textures

[WineHQ Bugzilla]

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

Zebediah Figura <z.figura12 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #7 from Zebediah Figura <z.figura12 at gmail.com> ---
(In reply to bender647 from comment #5)
> I'm guessing you did NOT run the game when prompted by the installer, and
> instead ran it afterward manually (and it failed to run).  I was able to
> recreate this scenario a few times.

I'm pretty sure I did run the game when prompted, and it crashed the same way.
Regardless, creating the Options.ini file as instructed did fix the crash, and
allowed me to reproduce the bug.


This one actually turned out into a whole mess of related problems. The basic
problem is that the game creates a SYSMEM and a DEFAULT texture, maps the
SYSMEM with D3DLOCK_NO_DIRTY_UPDATE, then does IDirect3DDevice8::CopyRects() to
copy it into the DEFAULT texture. There is one bug and two missed optimizations
here, any one of which would be sufficient to avoid this:

(1) Normally the sysmem texture would be left in WINED3D_LOCATION_SYSMEM after
the map, but because of the flag, we don't invalidate ~map_binding, hence
CLEARED is valid. Based on some testing I believe this code path is incorrect,
although I'm not sure it was possible to trigger an actual bug before the
offending commit. Unfortunately we rely on that lack of invalidation in some
other places, so those will also need to be fixed. In particular I believe we
should be respecting the dirty regions for managed textures in
wined3d_texture_load_location(), not when mapping. Even for managed textures
SYSMEM should still be valid; it's just not uploaded to the GPU.

(2) In order to blit from a CPU texture in SYSMEM to a GPU-only texture in
CLEARED, we end up loading the former into TEXTURE_RGB and doing a GPU-side
blit. That should be avoided. We don't want to load the GPU texture into a CPU
location, but we should be able to upload directly from the sysmem. Normally we
do, but in this case texture2d_blt() thinks that since CLEARED is CPU
accessible that this is a job for the CPU blitter.

(3) When loading a texture into TEXTURE_RGB whose valid locations are SYSMEM
and CLEARED, we end up clearing the texture again, which can be avoided (if
both of those locations really were valid, then SYSMEM is already cleared).
This may not be worth optimizing, though, since it'd take some really weird
usage to get here after fixing (1). [You'd have to do something like create a
staging texture, map it read-only without initializing it, and then copy from
it.]

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