DXTC requires the opengl s3tc extension. On open source drivers you need to install a custom library for mesa to get it as the compression isn't shipped by default since it is patented. For that reason we can't also add it to Wine.

(In reply to comment #1)
> DXTC requires the opengl s3tc extension. On open source drivers you need to
> install a custom library for mesa to get it as the compression isn't shipped by
> default since it is patented. For that reason we can't also add it to Wine.
> 

I see. And presumably, native dlls wouldn't help here either.

I think I misunderstood you before. The problem is legal/availability issues of S3TC, correct? I don't understand the underlying technology very much, but am I right in saying that S3TC is required for DXTC hardware support? If so, would it be possible (as in, legally) to implement a DXTC converter in software?

After some research, I now understand more about the problem here. Wine can't implement a DXTC/S3TC encoder without violating the S3TC patent, and probably the same goes for a decoder.

A while ago in #winehackers someone suggested that this particular decoding function could be offloaded to the GPU (when the appropriate functionality is available). The process would be essentially:
1. Load S3TC texture into a PBO
2. GPU converts to ARGB
3. Wine reads back the converted texture from PBO

Of course, this won't work when the GPU doesn't support S3TC/DXTC textures. I've been meaning to write a PoC for this, but haven't had the time. Comments?

Likely you could implement the algorithm that way but the drivers which offers PBOs are also the ones which offer S3TC. (Only Nvidia and ATI offer this at this point and I doubt PBOs will be supported on much older GPUs though if they support VBOs it is possible as PBOs are an extension to those)

*** Bug 15340 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
> Likely you could implement the algorithm that way but the drivers which offers
> PBOs are also the ones which offer S3TC. (Only Nvidia and ATI offer this at
> this point and I doubt PBOs will be supported on much older GPUs though if they
> support VBOs it is possible as PBOs are an extension to those)
> 

What I'm wondering is, is it worth it to implement this algorithm that only works on particular GPU and driver pairs? I would vote "yes" on this, but it would have to be done in such a way that it wouldn't be more broken if S3TC support is not found in the driver.

Also, adjusted description to be more accurate.

Is this still an issue in current (1.1.18 or newer) wine?

Created attachment 20214 [details]
Tail of wine crash output on 1.1.18, including the backtrace

There's been a regression in Wine that causes B&W to crash shortly after starting. I've attached the backtrace (above). It's in Wine's texturing code, interesting :)

And regarding whether the bug has been fixed, it can *only* be fixed by one of the following solutions:
1) Resolving the patented s3tc/DXTC issues and implementing a software DXTC to ARGB converter
2) Deferring decoding s3tc/DXTC textures to the graphics card where s3tc is supported, then read back the texture and tell the app "here is your converted texture" (like what I suggest in Comment #2, which in turn was suggested by people in #winehackers)

I don't think either of these things have been done.

In the duplicate Bug 15340, Roderick mentions the s3tc patches for mesa. They don't help here (thought they would for solution #2 if it was implemented) because the app isn't trying to load an s3tc texture into the graphics card, it's got an s3tc/DXTC texture that it wants converted to ARGB by DirectX and/or the video driver, then load the ARGB texture into the graphics card.

I'll be trying to determine where the regression that causes the current crashiness occurs :)

I can now confirm that there is still no DXTC to ARGB converter as of 1.1.18.

*** Bug 15308 has been marked as a duplicate of this bug. ***

Why not copy the Mesa route described at http://dri.freedesktop.org/wiki/S3TC and try using an external library which it is up to the user or packager to supply, assuming they have complied with the relevant licensing requirements? If we can't dlopen the library, then fallback to whatever we do now. Feeding it off the GPU could be done either before or after the library, basically depending on performance I'd think, but neither path depends on the other that I can see.

*** Bug 20183 has been marked as a duplicate of this bug. ***

Still present.

Also affects Orbiter 2010. The source library provided in #14 is 404, so the workaround is slowly turning extinct.

http://orbit.medphys.ucl.ac.uk/

Created attachment 32355 [details]
Implements DXT1 to ARGB4444 texture conversion. Tested against commit b898130a114f1baf24f717ab0c5f9a65030c5283.

I have written a patch implementing DXT1 to ARGB4444 texture conversion. I pushed for inclusion in mainline, but was told this algorithm is patented. I decided to give VIA and S3 the privilege of sitting on my finger and write this patch anyway. Then I pushed the patent to the ground and had my way with it thoroughly. It wasn't as pleasant for the patent as it was for me.

More patches are coming, most notably to implement XRGB1555 to DXT1, DXT1 to XRGB1555 and DXT3 to ARGB4444 texture conversion. The patches handling XRGB1555 textures will fix the crash upon finishing the temple in land 1.

I advise anyone who wishes to try this to check out commit b898130a114f1baf24f717ab0c5f9a65030c5283, since the commit after it (	7e3985e1fea60da73bae2b9465b94e5d110909fc) causes left / right mouse button clicks to be ignored in Black & White.

To use this patch and not be affected by bug 25417 (http://bugs.winehq.org/show_bug.cgi?id=25417), copy the following commands in a terminal:

mkdir ~/src
cd src
git clone git://source.winehq.org/git/wine.git ~/wine
cd wine
git checkout b898130a114f1baf24f717ab0c5f9a65030c5283
wget -O wine-dxt1-to-argb4444-conversion.patch http://bugs2.winehq.org/attachment.cgi?id=32355
patch -p1 < wine-dxt1-to-argb4444-conversion.patch
./configure --prefix=/usr
make depend
make
sudo make install


By the way: DXT1 textures are used as low resolution textures in Black & White, whereas DXT3 textures are used as high resolution textures. Until I post a DXT3 -> ARGB4444 patch, go to the Black & White installation directory and type 'wine Setup.exe'. Then go to the 'Graphics Detail Level' slider and select 'Custom Detail'. Then click the 'Custom...' button, uncheck "Use hi-res textures" and check "Use detail textures".

Created attachment 32358 [details]
Implements DXT1 to XRGB1555 texture conversion.

This incremental patch adds support for DXT1 -> XRGB1555 texture conversion, required for the temple surface. Once I post an XRGB1555 -> DXT1 patch, the crash will be solved.

(In reply to comment #18)
> Created an attachment (id=32355) [details]
> Implements DXT1 to ARGB4444 texture conversion. Tested against commit
> b898130a114f1baf24f717ab0c5f9a65030c5283.
> 
> I have written a patch implementing DXT1 to ARGB4444 texture conversion. I
> pushed for inclusion in mainline, but was told this algorithm is patented.

Rude language aside, thanks for looking in to this. Let's just hope that there are no nasty legal consequences!

(In reply to comment #21)
> Rude language aside, thanks for looking in to this. Let's just hope that there
> are no nasty legal consequences!

Rude language? What? :p I just managed to tell S3 to go (...) themselves without resorting to the F-word, that's just classy.

Have you tried out the patch(es) yet? Tell me if you find any problems.

Created attachment 32374 [details]
Implements DXT1, DXT3 to ARGB4444 and XRGB1555 texture conversion. This is a full (non-incremental) patch. Preferrably apply against commit b898130a114f1baf24f717ab0c5f9a65030c5283.

I have now implemented DXT3 -> ARGB4444 texture conversion, enabling high resolution textures.

There is only one bug left to tackle (15984), that one requires an XRGB1555 -> DXT1 conversion function. When that has been completed, likely tomorrow, Black & White will no longer crash when saving or entering a skirmish game and will be eligible for platinum status in the AppDB.

Platinum's only for games that run well on unpatched wine.

(In reply to comment #24)
> Platinum's only for games that run well on unpatched wine.

Whoops. Well, I suppose a gold rating accompanied with a thorough howto and .deb and .rpm packages built from the patched source will be almost as snazzy.

Working on that XRGB1555 -> DXT1 patch now, almost there :)

(In reply to comment #25)
> (In reply to comment #24)
> > Platinum's only for games that run well on unpatched wine.
> 
> Whoops. Well, I suppose a gold rating accompanied with a thorough howto and
> .deb and .rpm packages built from the patched source will be almost as snazzy.
> 
> Working on that XRGB1555 -> DXT1 patch now, almost there :)

Just had the chance to try out your patch attached here. Amazing work!

Two things:
1) What happened to your XRGB1555 encoder?
2) Is there any way you can implement this so it defers the actual decompression algorithm to OpenGL/Mesa? At the moment, there's no way this patch will be included in upstream wine.

Hello Ben, I hope you're enjoying Black & White - it's been a long time coming.

1) The XRGB1555 -> DXT135 compression algorithm is no longer essential to running Black & White, as it's only used to compress the screenshots into thumbnails when one saves a game. The crashes were caused by a shoddy implementation of DirectDraw blitting (used when making these savegame screenshots), Zdenek Behan has provided a hack that bypasses blitting. In the HowTo I have included all 3 patches needed for playing Black & White on Wine.

2) Personally I think this patent fear is nonsense, since only a backwards, oppressive and capitalist legal climate as in the U.S. would allow patents to kill innovation. If you like, I could write a patch to hook into libtxc_dxtn, though there are two concerns: A) the overhead produced by converting the 16 bit textures to 32 bit (libtdx_dxtn works with 32 bit textures) and then performing a function call to libtdx_dxtn.so would be just silly and B) the Mesa guys are finally turning on the light in their attics and are discussing providing DXT support natively in Mesa ( http://lists.freedesktop.org/archives/mesa-dev/2011-March/005826.html ). 
I'll push a patch to provide fast, direct compression / decompression of 16 bit (A)RGB textures to Mesa when they've completed the merger.

For now, just follow the HowTo on the AppDB page and you're good to go. If you want an online match sometime, give me a yell! My rhino is feeling lonesome. =(

(In reply to comment #27)
> Hello Ben, I hope you're enjoying Black & White - it's been a long time coming.
> 
> 1) The XRGB1555 -> DXT135 compression algorithm is no longer essential to
> running Black & White, as it's only used to compress the screenshots into
> thumbnails when one saves a game. The crashes were caused by a shoddy
> implementation of DirectDraw blitting (used when making these savegame
> screenshots), Zdenek Behan has provided a hack that bypasses blitting. In the
> HowTo I have included all 3 patches needed for playing Black & White on Wine.

Thanks :)

> 2) Personally I think this patent fear is nonsense, since only a backwards,
> oppressive and capitalist legal climate as in the U.S. would allow patents to
> kill innovation.

I agree with you. I'd even argue that implementing the S3TC algorithms from scratch is not a patent violation as long as you don't reverse-engineer. But I'm not a patent expert, an nor are the wine devs, so as it stands this sort of software decoder won't get into wine upstream.

> If you like, I could write a patch to hook into libtxc_dxtn,
> though there are two concerns: A) the overhead produced by converting the 16
> bit textures to 32 bit (libtdx_dxtn works with 32 bit textures) and then
> performing a function call to libtdx_dxtn.so would be just silly and

I suggested it mainly because it'd be more likely to be accepted by AJ.

> B) the
> Mesa guys are finally turning on the light in their attics and are discussing
> providing DXT support natively in Mesa (
> http://lists.freedesktop.org/archives/mesa-dev/2011-March/005826.html ). 
> I'll push a patch to provide fast, direct compression / decompression of 16 bit
> (A)RGB textures to Mesa when they've completed the merger.

This is good news then :) Something to keep an eye on.

> For now, just follow the HowTo on the AppDB page and you're good to go. If you
> want an online match sometime, give me a yell! My rhino is feeling lonesome. =(

Poor rhino!

I just want to say thank you to Itzamna for his hard work. It works perfectly now and my wife has been playing for hours!

Created attachment 33871 [details]
Rebase DXT patch on latest git commit (da4ed4707683687254d4abcb63f8abdd0ba7b313).

More recent git commits broke the patch, here's an update.

Also, you may have noticed DXT3 textures sometimes get decompressed with jagged edges... I'll look into it in the weekend, it may have something to do with alpha pixels or with blending.

(In reply to comment #27)
> B) the
> Mesa guys are finally turning on the light in their attics and are discussing
> providing DXT support natively in Mesa (
> http://lists.freedesktop.org/archives/mesa-dev/2011-March/005826.html ). 

It looks like this will never happen. They merged the floating textures (enabled with the --enable-float configure flag, but Linux distribution are unlikely to enable it) because it was infeasible to provide them in an external library, but the DXT texture support will stay in libtxc-dxtn, at least up until the S3 patent is valid.

Created attachment 34559 [details]
Rebase DXT patch May-09-2011

This is the new patch to address the name change from surface_base.c to surface.c in the dlls/wined3d folder

Hey Itzamna, the file name changed for the patch so I remade it.  Thanks for all your help.

Which one source version should i download to get it to work?

I downloaded few wersions of wine's source. 
1.1.2, 1.1.27, 1.1.5, 1.5.4
But cannot patch or compile it.
Tried to use both patches (33871 and 34559).

Is still an issue in wine 1.5.6 or newer?

Can't start it even on wine 1.5.20 on ubuntu 12.10 ... tried it with black and white version 1.0 and patched 1.3 ... even with no-cd crack. 

Sometimes it begins to start, shows the two splash screens, but freezes and does only show a black screen :-(

I have no clue about the exact details of this, but by now texture
compression is AFAIK provided by the package libtxc-dxtn-s2tc0 (this is
its name in Ubuntu), which happens to fix many black-screen issues.

Please give it a try, install it and tell us if it changes something.

This is still an issue in wine 1.7.5. Haven't been able to try in 1.7.13, see Bug 35721.

Building with the patch fixes most of the issues but leaves a few.

1. All the sprites for trees haven't any alpha, making them rectangular with a greenish background.

2. Some textures still seem to be missing, for example the Celtic temple and some parts of Yin and Yan.

The game still tries to use WINED3DFMT_B5G5R5X1_UNORM to WINED3DFMT_DXT1 conversion, I don't know for what but maybe implementing it could help with the missing textures. I also get lots and lots of these output lines:

fixme:d3d_surface:surface_load_location Unimplemented copy from SFLAG_INTEXTURE to SFLAG_INSYSMEM for depth/stencil buffers.

and

err:ddraw:d3d_device_prepare_vertex_buffer (0x1b6b70) wined3d_buffer_create_vb failed with hr = 8876017c

Patch was added to Wine-Staging:

https://github.com/wine-compholio/wine-staging/tree/master/patches/wined3d-DXTn
(needs 'autoreconf -f' and 32-bit libtxc-s2tc to be present at ./configure time)

It might be a bit slower than directly implementing DXTn support in Wine, but is a bit more safe from a legal perspective.

(In reply to Sebastian Lackner from comment #39)
> Patch was added to Wine-Staging:
> 
> https://github.com/wine-compholio/wine-staging/tree/master/patches/wined3d-
> DXTn
> (needs 'autoreconf -f' and 32-bit libtxc-s2tc to be present at ./configure
> time)
> 
> It might be a bit slower than directly implementing DXTn support in Wine,
> but is a bit more safe from a legal perspective.

Please do not give up on this! I'd love to play this game!

Created attachment 52372 [details]
Rebase patch for 1.7.51

Created attachment 52384 [details]
DXTC-ARGB converter with fixed DXT3 Alpha for 1.7.51

from your wine directory, run

patch -p1 < wine-dxt13-to-argb4444-xrgb1555-conversion-dxt3-fixed-alpha-1.7.51.patch

This fixes the alpha problem for trees in Black and White 1 with high quality textures

I would LOVE for this to be included in mainline wine. Is there something I can do to help that process?

(In reply to Linus Unnebäck from comment #43)
> I would LOVE for this to be included in mainline wine. Is there something I
> can do to help that process?

This bug is staged, should only be a matter of time now, right?

(In reply to Tiago Medeiros from comment #44)
> (In reply to Linus Unnebäck from comment #43)
> > I would LOVE for this to be included in mainline wine. Is there something I
> > can do to help that process?
> 
> This bug is staged, should only be a matter of time now, right?

Not necessarily. The staging tree intentionally has less strict rules regarding patch acceptance. The fact that a staged patch is available, only means that there is at least one proposed solution, not necessarily that this is the solution which will be used in the development tree later. For users who need such STAGED features immediately, I would recommend to use either a prebuilt package of Wine Staging, or compile it manually with all patches you want.

Hi, Mike McQuaid, lead Homebrew maintainer here. Is there any chance of this patch getting merged for a future Wine stable release? Homebrew doesn't want to carry patches like this indefinitely as we consider upstream a better judge than us on the suitability of patches. If there's no chance in this getting merged we'll consider removing it and direct people to this bug report instead. Thanks for all your work on Wine!

(In reply to Mike McQuaid from comment #46)
> Hi, Mike McQuaid, lead Homebrew maintainer here. Is there any chance of this
> patch getting merged for a future Wine stable release? Homebrew doesn't want
> to carry patches like this indefinitely as we consider upstream a better
> judge than us on the suitability of patches. If there's no chance in this
> getting merged we'll consider removing it and direct people to this bug
> report instead. Thanks for all your work on Wine!

Which patch in particular are you referring to? The staging patch has pretty much no chance of getting merged. I think using libtxc_dxtn when available is fine, but the way this is implemented in staging isn't.

That said, it's not clear to me whether that patch is even needed with current Wine. The last release anyone reported this occurring in was Wine 1.7.5 from 2013, in comment 38.

Thanks, I was referring to the staging patch. We'll remove it unless/until one of our users reconfirms it on 2.0.0 and even then I'd probably want to see it submitted in a way that could be accepted before we reinclude it.

(In reply to Mike McQuaid from comment #48)
> Thanks, I was referring to the staging patch. We'll remove it unless/until
> one of our users reconfirms it on 2.0.0 and even then I'd probably want to
> see it submitted in a way that could be accepted before we reinclude it.

Hi Mike, Henry,

I submitted the updated version of the patch as I was experiencing this bug at the time (at the end of 2015). I can give it another test for you this weekend if you like, but I can't imagine how this could be resolved without this patch.

The tl;dr is that there are fears around a software patent for this technology, which appears to be shipped on every graphics card released in the last decade, but requires a license to implement in software. The patent in question appears to expire in October 2017 (at which point there shouldn't be an issue with Wine merging this into stable?)

In the meantime, the patch does serve a purpose, although it's debatable as to whether homebrew is the right place to host it. The current recipe does make things *very* easy to end users though.

What are your thoughts?

Homebrew is happy to carry this patch if the merge concerns are patents but not if the patch isn't technically suitable for merging for other reasons.

I'm not close enough to the project to know either way, but my guess would be that the methods that this patch adds line up with the other methods in the file (convert_yuy2_r5g6b5 etc). I'd want someone on the project to confirm though.

(In reply to Sam Russell from comment #49)
> I submitted the updated version of the patch as I was experiencing this bug
> at the time (at the end of 2015).

There seems to be some disagreement between Sam and Mike? Sam is probably referring to attachment 52384 [details], from comment 42, which is not the staging patch series linked from this bug.
Either way, the attached patch is not acceptable for upstreaming at the moment, if nothing else for the patent reasons mentioned.

> I can give it another test for you this
> weekend if you like, but I can't imagine how this could be resolved without
> this patch.

425e84dac5c87f6b1e7d89b363017a045e4c0626 might have made the patch (whatever that is) unnecessary for Black & White.

Confirming this patch is still necessary and effective as-is in Wine 2.0

Before patching: http://i.imgur.com/bu308Yc.png
After patching: http://i.imgur.com/CY0Wg2A.jpg

(In reply to Sam Russell from comment #53)
> Confirming this patch is still necessary and effective as-is in Wine 2.0
> 
> Before patching: http://i.imgur.com/bu308Yc.png
> After patching: http://i.imgur.com/CY0Wg2A.jpg

What does the terminal output say?

I'm not sure I follow your question. The textures never worked, they continue to not work. I don't know Wine well enough to debug further, but I am happy to confirm that I'm seeing identical symptoms on Wine 2.0 as I saw on Wine 1.7.

(In reply to Sam Russell from comment #55)
> I'm not sure I follow your question.

What does Wine 2.0 write to stderr when running the application?

> Either way, the attached patch is not acceptable for upstreaming at the moment, if nothing else for the patent reasons mentioned.

Could you suggest how the patent reasons could be resolved and what would need to be done for this patch to be upstreamed? Thanks.

(In reply to Mike McQuaid from comment #57)
> > Either way, the attached patch is not acceptable for upstreaming at the moment, if nothing else for the patent reasons mentioned.
> 
> Could you suggest how the patent reasons could be resolved and what would
> need to be done for this patch to be upstreamed? Thanks.

I quess it would be better to send a question to wine-devel mailing list.

(In reply to Mike McQuaid from comment #57)
> > Either way, the attached patch is not acceptable for upstreaming at the moment, if nothing else for the patent reasons mentioned.
> 
> Could you suggest how the patent reasons could be resolved and what would
> need to be done for this patch to be upstreamed? Thanks.

https://en.wikipedia.org/wiki/S3_Texture_Compression#Patent

Though it looks like it's close to running out (Oct 2, 2017).

I think I was pretty clear in saying that I think using an external library like libtxc-dxtn-s2tc would be fine. Of course if that can be avoided that would be preferred, which is why I asked for debug output.

I didn't save the log output sorry. Can reproduce by running black and white (any version) under wine and getting into the game, the textures start getting hit fairly early on.

Created attachment 57121 [details]
screenshot of textureless stuff

Not sure what log can be useful, attached log is from wine-git. I can reproduce the textureless people/buildings, in the log I'm facing the problem in the screen (don't know if that is relevant).

+d3d,+tid (3.2mb unpacks to 300mb):
http://alexa.pro.br/~bruno/wine/bw.txt.bz2

standard log:
http://alexa.pro.br/~bruno/wine/bwstd.txt

Created attachment 57125 [details]
comparison Staging vs Vanilla 2.0

Since there were no screenshots I attached the previous comment screenshot and now a comparison taken from the same angle of a house. Staging is almost perfect, but looks like the windows are not stretched as they should.

Created attachment 57187 [details]
patch

(In reply to Bruno Jesus from comment #62)
> Created attachment 57121 [details]
> screenshot of textureless stuff
> 
> Not sure what log can be useful, attached log is from wine-git. I can
> reproduce the textureless people/buildings, in the log I'm facing the
> problem in the screen (don't know if that is relevant).
> 
> +d3d,+tid (3.2mb unpacks to 300mb):
> http://alexa.pro.br/~bruno/wine/bw.txt.bz2
> 
> standard log:
> http://alexa.pro.br/~bruno/wine/bwstd.txt

That's helpful, thanks. Could you give the attached patch a try, and create a new log with +ddraw included?

Created attachment 57188 [details]
comparison vanilla and patched

The patch works for me on Debian, thanks Henri.

The screenshot shows clearly every building roof in black, while patched is OK. People also have correct textures.

Created attachment 57189 [details]
+d3d,+ddraw with patch

287mb uncompressed. Game loaded to the point the screen is drawn correctly. The trace lines added are present in the log.

(In reply to Bruno Jesus from comment #65)
> The patch works for me on Debian, thanks Henri.

The patch was committed. This should be now fixed with commit 5a6efe632918fd18758897c39910d52791d46053.

(In reply to Józef Kucia from comment #67)
> The patch was committed. This should be now fixed with commit
> 5a6efe632918fd18758897c39910d52791d46053.
The patch that's supposed to fix it is f576e5c02857a506e63c33e3303e2a0a4bc24e1a. 5a6efe632918fd18758897c39910d52791d46053 is about handling failure to convert in surface_convert_format() in a more reasonable way, but the application isn't supposed to reach that anymore.

Closing bugs fixed in 2.2.

Removing the 2.0.x milestone from bugs included in 2.0.1.

*** Bug 13610 has been marked as a duplicate of this bug. ***