"S3TC für Direct3D in UT" Petition

19. August 2000 / von Leonidas ... Nachtrag (2. September)

Seit den ersten 5.xxer Treibern für die GeForce-Serie fristet S3TC (Texturenkomprimierung) nicht mehr ein Schattendasein auf S3-Karten, sondern ist zum Key-Feature geworden - und mittlerweile wird es auch von jeder der neueren Karten beherrscht. Seinerzeit sorgte es bei den GeForce-Karten für einen gewissen Performance-Boost in Q3A - wenngleich die Bildqualität etwas darunter leiden musste.

Sinn und Zweck von S3TC war es allerdings nie, die Spielgeschwindigkeit durch Komprimierung der normalen Texturen zu erhöhen. Vielmehr geht es bei der Idee von S3TC um wirklich große, sagen wir 50 MB, Texturen - welche eine normale Grafikkarte auch mit 32 MB RAM nicht bewältigen könnte. Eine Sequenz mit 50 MB Texturen wäre nur mit einer Texturenkompression lösbar - welche S3 mit dem damals aber etwas untergegangen Chip "Savage 3D" vorstellte. Die Texturenkomprimierung auf dieser Karte war sicher leistungsfähig - zu sehen auch an extra erstellten Unreal-Leveln - allerdings war die Karte selber viel zu langsam, um sich durchsetzen zu können. Das änderte sich auch mit der Savage4 Pro(+) und der Savage2000 nicht wesentlich - beide Karten waren zwar teilweise wesentlich schneller, konnten sich aber aus verschiedenen Gründen nicht durchsetzen.

Letztendlich blieb S3TC bis zu DirectX6 eine Sache rein für S3-Karten - und damit kümmerten sich auch die Spiele-Entwickler nicht wesentlich um dieses eigentlich so vielversprechende Feature. In DirectX6 integrierte Microsoft jedoch S3TC - unter dem Namen "DXTC" - und machte zumindestens für Direct3D die Texturenkomprimierung für jeden Chip, der dies in Hardware beherrscht, möglich. Es gibt jetzt schon einige Spiele, die DXTC nutzen (z.B. Ultima 9), in Zukunft werden es noch wesentlich mehr werden - da so ohne große Anforderungen an die Leistungsfähigkeit des Chips gigantische Texturen möglich sind.

Soviel zur Vorgeschichte, welche teilweise notwendig ist, um den speziellen Fall "Unreal Tournament" richtig einordnen zu können.

Denn Unreal Tournament unterstützt nicht "von Haus aus" eine Texturenkomprimierung so wie Quake III Arena (welches erst einmal alle Texturen komprimiert, egal ob das notwendig wäre). Die Texturenkomprimierung von UT ist nur für die auf der zweiten CD liegenden Extras-Texturen gedacht - und funktioniert auch nur bei diesen. Hier hat man die normalen UT-Level nochmal mit sehr großen 50-MB-Texturen versehen. Leider kommt hier ein Überbleibsel der alten Unreal-Engine ins Spiel - diese Texturenkomprimierung funktioniert nur mit der in Unreal und UT integrierten MeTaL-API für S3-Chips.

Zum UT-Verkaufsstart machte man sich darüber keine wesentlichen Gedanken - weil damals kaum eine Grafikkarte außer den S3-Karten Texturenkomprimierung in Hardware unterstützte. Heuer ist das eine ganz andere Geschichte - wie oben ausgeführt unterstützen eine Vielzahl von Grafikkarten eine Texturenkomprimierung (eine Unterstützung der MeTaL-API wird allen non-S3-Karten logischerweise verwehrt bleiben). Schon zu Zeiten der "Entdeckung" von S3TC in Q3A war klar, daß S3TC oder DXTC nur dann interessant werden, wenn dem non-S3-User auch die Texturen auf der Extras-CD zugänglich gemacht werden.

Oder einfacher: S3TC gibt es in UT nur für MeTaL-API, wir wollen es auch für die Direct3D- oder OpenGL-API!. Logisch - auch die zweite CD haben wir ja nun mitbezahlt. Und technisch können Karten ab GeForce-Generation auch locker die Texturenkomprimierung. Wo liegt also das Problem?

Das Problem hat einen Namen und dieser heisst Epic. Die Jungs und Mädels um Chefprogrammierer Tim Sweeney müssten entweder DXTC unter der UT-Direct3D-API oder S3TC unter der UT-OpenGL-API ansprechen. Wobei die Direct3D-Variante zu bevorzugen wäre, schließlich ist Direct3D in UT schneller und stabiler als OpenGL. Außerdem wird S3TC unter OpenGL von weniger Karten unterstützt als DXTC unter Direct3D.

Um nun genau diese Sache endlich einmal voranzutreiber, habe sich einige User entschlossen, eine Petition im Umlauf zu bringen, welche hier zu finden ist. Ich gebe mal den originalen Text wieder:

To: D3D users of Unreal Tournament

The D3D users of Unreal Tournament have seen the light. For too long have we had to suffer with slow frame rates and poor image quality. This petition is here to stop it. This petition is to implement the S3 texture compression technology into the DirectX API for Unreal Tournament. We would like to see the second CD of Unreal Tournament put to use. Nvidia has even offered to help with this issue. Therefore, we would like to see the benefits of having S3TC (improved visual quality, higher frame rates) implemented into Direct3D.

Auch wenn es nichts bringen mag, unterzeichnen kostet nichts. Das wir weiterhin brav alles hinnehmen sollen, was man uns vorsetzt, will uns Epic (Chef Tim Sweeney himself) relativ sofort klarmachen - nachfolgend ein Auszug aus einem Thread auf PlanetCrap (PS: DXT1 bis DXT5 sind verschiedene Arten von DXTC):

If by 'staying silent' you mean we haven't answered every question on every message board on the Internet, guilty as charged! Though, I've answered about 20 'why don't you support DXT1 under Direct3D in Unreal Tournament' queries in email.

Supporting DXT1 in Direct3D would very significantly slow down our texture management code, which isn't overly fast as it is. Though the DXT1 format is only 4 bits per pixel compared to 16-32 bits per pixel for our other textures on Direct3D, the DXT1 textures we shipped with are really high-res (many 1024x1024) so they consume a lot more video memory and texture bandwidth, as well as causing contention issues with other texture sizes and formats.

Some people then ask, "so why don't you support it as an option, and let us decide whether we want the really high res textures but a significant performance drain?" My view here has been closely influenced by the experience we had with Unreal 1's "Curved Surfaces" feature, an optional feature users could turn on which caused creature and player meshes (not world geometry) to be dynamically tesselated to up to 9X higher polygon counts, making them look more smooth and curvy -- also at a slowdown. Well, tons of users turned that option on thinking it would be cool, then later experienced the slowdowns and didn't realize the slowdown was caused by that one little "curved surfaces" menu option they had selected hours or days earlier. Moral of the story: don't add optional little features that cause major slowdowns.

So, we are definitely NOT going to add DXT1 support to the Direct3D code. We are influenced a lot by users' opinions; remember the recent Unreal 1 petition which shamed us into releasing the final Unreal 1 patch? :) But that was something that made Unreal 1 better; adding DXT1 to UT would make the game worse and we're not going to do it no matter how many people sign the petition.

Was sagt uns das?

1. Unterzeichnen kostet immer noch nichts.

2. Das es zu kompliziert wäre, halte ich für Schwachsinn. MeTaL ist wie Glide eine sehr OpenGL-nahe Schnittstelle. Demzufolge liesse es sich bei Problemen mit der Direct3D-Implementierung von DXTC eben auf OpenGL umschwenken - das sollte wesentlich einfacher sein. Auch sonst halte ich die angeblichen "Schwierigkeiten" unter Direct3D für vorgeschoben - in Unreal2 und folgenden Epic-Spielen wird es keine MeTaL- und Glide-Schnittstellen mehr geben und ich kann mir nicht vorstellen, daß man auf die Texturenkomprimierung dann verzichten wird. In Unreal2 wird es die Texturenkomprimierung wohl auch für Direct3D geben und da an Unreal2 schon länger gearbeitet wird, sollte es auch in UT möglich sein. Schließlich sind alle Epic-Engines modular aufgebaut, Teile sollen laut Epic-Aussagen easy auswechselbar sein (siehe Unreal 2.26 mit UT-Code).

3. Die Ausrede, das man nicht "kleine Features mit großer (Schadens-)Wirkung" einbauen wolle, ist schlicht und ergreifend BLÖDSINN. Klar - wenn man das wie in Unreal tief in den Optionen versteckt und es auch nirgendwo erklärt ist, was da rauskommt - ist es logisch, daß sich die User beschweren. Eine solche leistungsfressende Option muß sowohl gut erreichbar, als auch klar dokumentiert und auch standardmäßig disabled sein. Die Epic-Aussage im speziellen Unreal-Fall ordne ich im übrigen unter "Frechheit gegenüber dem User" ein. Da hält man wohl die User (und Käufer) für zu blöd, mit den tieferen Optionen umzugehen - letztendlich hat Epic den Fehler begangen, diese Option überhaupt nicht zu dokumentieren!

4. Epic versucht sich ganz bewusst herauszureden. Ich habe da zwei persönliche Theorien: Erste wäre, daß S3 dafür zahlt (zahlte), daß es in UT die Texturenkomprimierung nur für die MeTaL-API gibt. Und die zweite wäre: Epic will "S3TC für alle" in der kommenden Unreal2-Engine groß vermarkten und will jetzt keinen Konkurrenten mehr im eigenen Lager. Eventuell sind auch beide Theorien gleichzeitig zutreffend ...

Nachtrag (2. September):

Dös ist ja wohl der Hammer! Mit dem 4.28er Linux-Patch für Unreal Tournament können GeForce-Besitzer auch die Super-Texturen der Extras-CDs nutzen. Der Patch kommt dabei nicht von Epic selber, sondern von Lokigames, auf dem Linux & Games seit einiger Zeit schwer aktiv sind. Kurz und schmerzlos: Wenn es eine dritte Partei schafft, unter Linux S3TC in OpenGL zu aktivieren, kann es Epic für Win32 auch! Alles andere sind doch nur Ausreden (und viel Geld von S3?).

Home News-Archiv August 2000