News-Archiv März 2000
News-Index
- 5.13er Detonatoren
- 64-MB- vs. 32-MB-GeForce
- AMD Spitfire vor dem Start
- SoF - Importverbot
- erste Benches mit SoF
- Warten auf den Celeron II
- neue SpeedUp-DLLs für Q3A
- com_blindlyLoadDLLs
- S3TC in Q3A
- 5.08er Detonator
- GeForce und S3TC
5.13er Detonatoren
28. März 2000 / von Leonidas
Auf Voodooextreme gibt es neue GeForce-Treiber in der S3TC- und FSAA-unterstützenden Version 5.13 - wie üblich bei nVidia inoffizielle Betaversionen. Diesmal sind auch die Versionen für Windows 2000 und Windows NT4.0 mit dabei - die Version für Windows 95/98 liegt lokal zum Download bereit (2,3 MB). Sie läuft bei mir etwas schneller als die 5.08er.
Unabhängig davon das diese Treiber theoretisch auch ab TNT1-Karten aufwärts funktionierten sind sie wohl eher rein für die GeForce gedacht. Positiverweise sollen eine Menge Inkompatiblitäten und Absturzursachen der 5.08er Treiber behoben sein. Das FSAA (Full-Scene-Antialiasing) kann man nun in den OpenGL-Eigenschaften des Treibers direkt ein- bzw. ausschalten. Falls diese Option - wie z.B. bei mir - nicht angezeigt wird - es ist die letzte der "Leistungs- und Kompatiblitätsoptionen", diejenige die unbenannt ist. Ein Neustart ist im übrigen nicht notwendig um diese Einstellung wirken zu lassen.
Nachtrag vom selben Tag ...
Hoppla, Unreal Tournament (noch Version 4.05b) läuft ja auf einmal einwandfrei mit dem 5.13er! Die
leichten Bildfehler unter OpenGL sind weg und Direct3D stürzt nicht mehr bedingungslos nach ca. zwei Minuten
ab. Für Leute mit ähnlichen Problemen ist dieser Treiber ein echter Tip.
Nachtrag vom 29. März ...
Guru3D berichtet das sich das FSAA mit den 5.13ern auch unter Direct3D einschalten läßt -
und das diese Direct3D-FSAA-Kombination noch sehr im Alpha-Stadium sei da sich massenweise
Bildfehler einstellen. Wer es ausprobieren mag ...
Nachtrag vom 17. April ...
*LOL* - ist leider durchgerutscht: Der neue
5.14er Detonator (2,3 MB) ist logischerweise auch wieder lokal zu bekommen ...
Nachtrag vom 7. Mai ...
Oben genannte Files sind runter von unserem Server. Der jeweils aktuelle GeForce-Treiber liegt
ab sofort immer hier.
64-MB- vs. 32-MB-GeForce
28. März 2000 / von Leonidas
Sharky Extreme hatte vor einigen Tagen die Gelegenheit eine 64-MB-GeForce von DELL gegen eine "normale" GeForce mit 32 MB zu testen. Beide Karten waren dabei im positiven Gegensatz zu den DELL-eigenen Tests mit DDR-RAM ausgestattet, so daß einem fairen Vergleich nichts im Wege stand. Erwartungsgemäß gewinnt die 64-MB-GeForce sobald das richtige Timedemo in der richtigen Grafikeinstellung herangezogen wird, aber das könnt Ihr bei Sharky selber nachlesen.
Denn mein Fokus richtet sich auf die Frage warum Sharky beide GeForce´s nicht mal mit den 5.08er Treibern, d.h. also mit S3TC gebencht hat. Ich kann mangels eines 800 MHz bzw. 1 GHz Coppermines und auch mangels der 64-MB-GeForce keinen direkten Gegentest durchführen aber an einem relativen Vergleich zeigen, daß dieser S3TC-Test durchaus Sinn macht.
Den Aussagen von Sharky´s Benchmarks zufolge läuft die 64-MB-GeForce im Quaver-Demo mit den höchsten Texturendetails unter 1024*768 @ 32 Bit ganze 163 % schneller, unter 1280*1024 @ 32 Bit satte 212 % schneller - gemessen auf einem 1 GHz Coppermine. Ich kann nur einen Celeron 550 MHz und eine SDR-RAM GeForce dagegensetzen - diese aber performt durch allein durch S3TC im Quaver-Demo mit den höchsten Texturendetails unter 1024*768 @ 32 Bit passable 135 % besser und unter 1280*1024 @ 32 Bit phänomenale 233 % besser (die Vergleichsbenchmarks ohne S3TC wurden meinerseits selbstverständlich auch mit dem 5.08er aufgenommen).
So gesehen erreicht das S3TC einen ähnlichen Leistungsgewinn wie die 64-MB-GeForce! Natürlich ist die Qualität der durch S3TC komprimierten Texturen nicht mehr ganz gleichwertig dem Original - ein Haken ist immer mit dabei. Und natürlich besitzt die 64-MB-GeForce eine gewisse längere Lebenserwartung als die 32-MB-Kollegen - bei zukünftigen Spielen mit ebensolchem Texturenhunger wie Quake 3 (momentan ist dieses Spiel in Bezug auf den RAM-Bedarf der Texturen einzigartig) werden sich die 64 MB sicher auszahlen - denn S3TC oder DXTC wird nicht jedes Spiel anbieten.
Das erste Gegenargumente gegen die 64-MB-GeForce sind der monströse Preis seitens DELL (Mehrpreis zur 32-MB-Ausführung: $ 240 - gibt es nur in Komplett-PCs von DELL), welche als Designer des 64-MB-GeForce-Referenzboards auch bei der Preisgestaltung der frei erhältlichen 64-MB-GeForce-Karten mit im Boot sein werden. Dieser wäre gerechtfertigt - wenn denn die Mehrleistung der Karte nicht auch durch S3TC zu erreichen wäre. Aber nur wegen der besseren Texturenqualität gegenüber S3TC soviel Holz?
Das andere Gegenargument: Die Nachfolger NV11 und NV15 stehen vor der Tür - sich jetzt noch eine sehr teure Grafikkarte mit einem Chipsatz der in Kürze nicht mehr State of the Art sein wird zu kaufen ist eventuell leicht übertrieben. Insofern kann ich die Begeisterung für die 64-MB-GeForce seitens Sharky - und auch seitens anderer Sites - nicht ganz teilen. Sinn und Zweck gerade von Hardware-Sites ist es auch, ab und zu mal die Leser auf mögliche Fehlkäufe hinzuweisen und nicht alles was schneller ist als vorher bedingungslos über den grünen Klee zu loben.
Anmerkungen zum besseren Verständnis:
1. Deswegen weil meine 32-MB-GeForce durch S3TC solche Zugewinne erreicht
wird das bei der 64-MB-GeForce von DELL mit S3TC nicht auch so performen (Sharky
hätte es ja testen können ...). Die Texturen des Quaver-Demos passen problemlos
in den Speicher der 64-MB-GeForce - eine S3TC-Komprimierung bringt dann nichts
an Mehrleistung.
2. Die Mehrleistung der 64-MB-GeForce ist nur unter 32 Bit Texturenqualität mit
gleichzeitig den höchsten Texturendetails zu beobachten - bei jeder anderen
Einstellung ist eine 32-MB-GeForce genauso schnell. Wer also z.B. komplett unter
16 Bit spielt wird gar nichts an Mehrleistung verbuchen können.
3. Als momentan einziges Spiel bietet Quake 3 überhaupt solche große Standardtexturen
(nicht vorkomprimierte hochauflösende wie auf der Extras-CD von UT) an um eine 32-MB-Grafikkarte
ins Schwitzen bringen zu können. Die Texturenaufkommen aller anderen Spiele sind
momentan sogar mit 16-MB-Grafikkarten zu bewältigen. Ergo wird die Mehrleistung
der 64-MB-GeForce momentan ausschließlich auf Quake 3 beschränkt bleiben.
weitere News/Artikel in gleicher Richtung:
Nachtrag vom 10. April ...
AnandTech kommt im übrigen rein praktisch genau auf das selbe Ergebnis,
welches ich hier theoretisch voraussagte ...
AMD Spitfire vor dem Start
26. März 2000 / von Leonidas
Auf rb computing findet man die neuen OEM-Preise für AMD-Prozessoren, welche in den USA zum 24. April hin gelten werden (bei uns wie üblich ein paar Tage später). Beim Athlon ist vor allem zu beobachten das AMD mit Macht versucht die 700-, 750- und 800-MHz-Typen unters Volk zu bringen - was natürlich den Hintergrund hat das AMD bei den höhergetakteten CPUs momentan wesentlich liefern kann als Intel. In je höheren Sphären der Konkurrenzkampf Intel vs. AMD abläuft desto besser für AMD.
Viel interessanter ist die erstmalige Notierung der LowCost-Athlon-Variante Spitfire, obwohl "LowCost" in diesem Zusammenhang wirklich nur den Preis und nicht die Leistungsfähigkeit andeutet. Der Spitfire wird - ähnlich wie der Celeron / Celeron II - als Sockelvariante (Socket A) in übertaktfreudiger 0.18-micron-Technologie kommen, mit 128 kB FirstLevel-Cache (wie beim originalen Athlon) und 256 kB FullSpeed-SecoundLevel-Cache on die.
Der SecoundLevel-Cache ist somit völlig gleich dem des Coppermine - der originale Athlon indes hat 512 kB SecoundLevel-Cache welcher bis 750 MHz auf der Hälfte des CPU-Taktes läuft und ab 800 MHz auf 2/5 des CPU-Taktes. Der FullSpeed-SecoundLevel-Cache des Spitfire sollte trotz kleinerer Größe in Spielen sogar Vorteile gegenüber dem Original-Athlon bieten - wie schon beim Coppermine zum Katmai (alte Pentium3-Typen) zu beobachten. Probleme könnte es bezüglich der Mainboards geben - ich konnte jedenfalls noch keines mit Socket A für den Spitfire entdecken. Möglicherweise wird dies auch über Adapterkarten gelöst (wie beim gesockelten Celeron in Slot1-Boards).
Damit scheint AMD´s Antwort auf den Celeron und den Celeron II nun Ende April / Anfang Mai an den Start zu gehen. Bei Preisen von ca. 230 DM für die 600-MHz-Variante wird endlich wieder ein bißchen Bewegung in den LowCost-Markt kommen - auch zum Vorteile der Intel-User, da die angekündigten und Anfang April erwarteten Celeron II´s sich an diesen Preisen orientieren werden.
Oops - fast vergessen: Auf PC Watch Japan gibt es eine nette AMD-Prozessoren-Roadmap welche einen Ausblick bis ins Jahr 2002 bietet. Von Intel gibt es in dieser Richtung offiziell noch nichts neues.
Nachtrag vom 10. April ...
Zu den Größen der Spitfire-Caches gibt es inzwischen widersprüchliche Aussagen. Allgemeine Tendenz ist aber,
daß es weniger werden wird als die vor genannten Werte - eher wahrscheinlich sind inzwischen 64 kb
1th-Level-Cache und 128 kB 2nd-Level-Cache.
SoF - Importverbot
26. März 2000 / von Leonidas
Der deutsche Vertreiber von Soldier of Fortune, Activision Deutschland, macht sich dieser Tage geradezu ungeheuer beliebt ;-)) durch bekanntgewordene Details bezüglich der Veröffentlichung von SoF in Deutschland. Das wir die eingedeutschte - massive gekürzte und umgeschriebene - Version gleich wieder vergessen ist klar. Diese deutsche Version wird hoffentlich von Euch nicht der US-Version vorgezogen - sonst gibt es in Zukunft noch mehr solcher Fälle wie nachfolgend beschrieben!
Der Punkt ist das die in den USA erscheinende "Mature"-Version (die einzig wahre - es gibt selbst in den Staaten noch eine gekürzte "Tactical"-Version) nie nach Deutschland (und damit auch die Schweiz und Österreich) kommen soll! Games Zone berichtet darüber, Zitat: " ... US-Importe über die einschlägigen Versandhändler will Activision Deutschland rigoros unterbinden ... ". Grund: Activison Deutschland distanziert sich laut eigener Aussage von der übertriebenen Gewaltdarstellung der US-Version von SoF - ich sage eher die reiten ganz oben mit auf der momentanen Welle der selbsternannten Saubermänner in den elektronischen Medien.
Das ganze funktioniert dadurch das Activision beim deutschen Zoll eine "Grenzbeschlagnahmung" aller Original-Versionen des Spiels beantragt (ist für meine Begriffe sicher schon geschehen). Damit durchsucht der deutsche Zoll auf jeden Fall jede gewerbliche Sendung welche nach Spielen für PCs/Konsolen aussieht - hat aber auch die Möglichkeit jegliche private Sendung mit ähnlichem Verdachtsmoment zu durchsuchen und dann auch zu beschlagnahmen (auch wenn private Sendungen meist durchrutschen weil der Zoll sonst nie fertig werden würde). De facto kann Activision Deutschland damit verhindern das die deutschen Händler die Original-Version von SoF ins Programm nehmen - das wirtschaftliche Risiko durch eine oder mehrere konfiszierten Sendung ist für die Händler zu hoch.
Was kann man tun? Es gibt durchaus eine Möglichkeit: Der deutsche Zoll kann nur Sendungen von außerhalb der Europäischen Union durchsuchen. Ergo kann man sich aus jedem EU-Staat, in welchem keine solche Importbeschränkung existiert, von einem dort ansässigen Händler eine Originalversion schicken lassen - die kommt am deutschen Zoll vorbei. Sollte Großbritanien als Vorzugs-Reimportland auch eine solche Importbeschränkung wie Deutschland auferlegt bekommen kann man es immer noch in einem der kleineren EU-Staaten versuchen - dort gibt es keine lokalisierten Versionen sondern ausschließlich US-Originale.
Im Zweifelsfall hilft nur noch sich das Spiel von einem US-Versender (möglichst keinen reinen Spieleversender, deren Sendungen werden todsicher kontrolliert) privat schicken zu lassen und darauf zu hoffen das es am Zoll vorbeikommt. Zumindestens wird es bei SoF wohl für viele ein größeres Problem werden an das Spiel heranzukommen. Für uns gilt: Mal sehen wie sich die Sache weiterentwickelt wird - im Zweifelsfall werden wir eine extra Rubrik einrichten müssen "wie kommt man an SoF ran" :->
Dank an diejenigen die indirekt - teilweise ohne es zu wissen :-) - zu diesem Artikel beigetragen haben: Prolium, Frank G, Oliver Kirchner.
erste Benches mit SoF
25. März 2000 / von Leonidas
... kommen natürlich von Ravensoft (Hersteller von "Soldier of Fortune"), das Spiel selber steht kurz vor der Veröffentlichung ist aber noch nicht draußen. John Scott von Ravensoft testet jedenfalls mit der Vollversion des Spiels alles an Grafikchips durch was es momentan so zu kaufen gibt - und auch alles was es nicht mehr zu kaufen gibt, was aber noch im Einsatz ist. Benchmarks Soldier of Fortune.
Auch wenn die benutzten Timedemos wohl nicht besonders aussagekräftig scheinen (es wurde ein Level mit geringem Texturenaufkommen benutzt - eine Konzessionsentscheidung an die im Test vertretenen alten Grafikchips mit nur 4 oder 8 MB Grafikkartenspeicher) geben die Benchmarks ein passables Gefühl dafür welche Grafikkarten für SoF besonders geeignet sein werden. Das die GeForce gewinnt ist aufgrund ihres T&Ls nicht verwunderlich, ganz besonders weil SoF auch als erstes Spiel überhaupt einige Lightning-Effekte in Hardware (das "L" in T&L) berechnet.
Entscheident scheint für SoF eine große CPU zu sein. Obwohl der mittlerweile in die Jahre gekommenen Quake2-Engine entsprungen setzt SoF in den Hardwareanforderungen ähnliche an wie Kingpin - möglichst große CPU, möglichst viel RAM. Mit einem Pentium 2 mit 400 MHz kam unter 1024*768 @ 16 Bit keine Grafikkarte auf 30 Bilder pro Sekunde (auch keine GeForce) - das ist bei weitem langsamer als Quake III Arena oder Kingpin. Bei dem besagten Pentium II mit 400 MHz war es fast egal welche Grafikkarte am werkeln war - die Ergebnisse zumindestens der aktuellen Chips lagen alle sehr eng zusammen. Erst beim Test mit dem Pentium III E auf 700 MHz offenbarten sich die deutlichen Vorteile von Matrox G400, nVidia Riva TNT2, S3 Savage2000 und ganz deutlich vorne - nVidia´s GeForce.
Was ist daraus zu folgern? Solange man keine 700-MHz-CPU sein eigen nennt ist man mit jeder halbwegs aktuellen Grafikkarte (d.h. auch nVidia Riva TNT und 3Dfx Voodoo3) passabel mit dabei - obwohl es im MultiPlayer-Gefecht sicher an die Grenzen der Spielbarkeit gehen könnte. Für SoF macht aber allein eine toll übertaktete GeForce mit übertaktetem DDR-RAM noch gar nichts - ohne die entsprechende CPU wird sie ihr Potential nicht ausspielen können.
SoF stellt hier von vornherein ganz andere Anforderungen an das Gesamtsystem (und natürlich mit besonderem Augenmerk auf CPU und RAM-Größe). Damit ist SoF nach einem Jahr mit relativ wenig hardwarefressenden Spielen das erste einer neuen Generation von Spielen die von einer 500-/600-MHz-CPU als unteres Level ausgehen. Ich schätze das wird in der nahen Zukunft vollkommende Normalität werden ...
Nachtrag vom 25. Juni ...
besagte Timedemos sind mittlerweile auch in unserem Download-Bereich zu finden.
Warten auf den Celeron II
23. März 2000 / von Leonidas
Er sollte schon längst da sein - aber irgendwie ist er immer noch nicht aufgetaucht: Der Celeron II von Intel. Dabei handelt es sich um einen Celeron mit Coppermine-Kern (die bisherigen Celerons haben immer noch den Kern des Pentium II). Der Name "Celeron II" ist dabei rein spekulativ, Intel hat noch nichts genaueres verlauten lassen. Verschiedentlich redete man schon von "Celeron III" in Anlehnung an den Pentium III.
Der Celeron II kommt aller Voraussicht nach ausschließlich mit 66 MHz Bustakt (um einen gewissen Abstand zum Pentium III E mit 100 oder 133 MHz Bustakt zu lassen). Der Coppermine-Kern wird wohl unmodifiziert übernommen - d.h. man kommt mit entsprechender Software auch in den Genuß der Intel´schen ISSE-Unterstützung. Die ist zwar nicht weit verbreitet und das Internet wird garantiert nicht schneller durch ISSE >:-> aber zumindestens die Quake3-Spieler können durchaus mit 5 bis 10 Prozent mehr Leistung rechnen (Vergleich bei gleicher Taktrate des Chips), da ISSE zumindestens in Quake 3 passabel implementiert wurde.
Die Bauform wird die gleiche sein wie beim gesockelten Coppermine. Diese nennt sich FCPGA - im Gegensatz zu den bisherigen Celeron in PPGA-Bauform. Besitzer eines Boards mit Sockel370 sollten klären ob ihr Board auch einen gesockelten Coppermine unterstützt - dann würde auch der Celeron II laufen. Besitzer eines Boards mit Slot1 benötigen einen speziellen FCPGA-Slot1-Adapter, der alte PPGA-Slot1-Adapter macht es auf keinen Fall mehr. Es gibt zwar auf Tom´s Hardware Guide eine Bastelanleitung wie das dennoch funktioniert - aber um einen 50-DM-Adapter zu sparen an einer CPU herumzulöten halte ich für übertrieben.
Noch ein bißchen im unklaren ist die Größe des 2th-Level-Caches. The Register wärmte kürzlich wieder mal alte Spekulationen auf, daß der Celeron II zwar mit nominellen 256 kB Full-Speed-Cache on die kommt (ergo wie beim Coppermine), daß aber die Hälfte dieses Caches per Hardware disabled sei. Selbiges tat Intel im übrigen beim Mobile Celeron - der Chip ist ein vollwertiger Mobile Pentium II, nur das die Hälfte des Caches disabled war. So oder so wird der Cache beim Celeron II wie schon bei den bisherigen Celerons 128 kB betragen. Im Fall der 256 kB und Hälfte davon disabled hoffe ich immer noch auf findige Programmierer/Bastler, die es schaffen diese Beschränkung aufzuheben.
Der Vorteil der Celerons mit Coppermine-Kern wäre natürlich die wiedergewonne Übertaktfähigkeit. Die letzten "alten" Celerons mit 500 und 533 MHz sind bekanntlich kaum noch übertaktfähig (meistens 500 @ 563 und 533 @ 600 ... wenn alles optimal läuft) - der alte 0.25-micron-Produktionsprozeß läßt nicht mehr als maximal 600 MHz zu. Genauso gut kann man anstatt eines 500 @ 563 einen 366 @ 550 nehmen - zum wesentlich geringeren Preis. Durch den Coppermine-Kern ist der Celeron II wieder genauso gut übertaktbar wie der Coppermine selber - die 0.18-micron-Produktionstechnologie ermöglicht wesentlich höhere Taktraten. Natürlich sind hier wieder die kleineren Modelle vorzuziehen - diese werden sich am sichersten übertakten lassen und kosten außerdem sowieso weniger.
Besonders interessant wird der Celeron II für zwei Anwendergruppen: Zum einen diejenigen deren Mainboard keine 133 MHz Bustakt unterstützt. Für diese entfällt das Übertakten des Coppermines - dieser Chip kommt gleich mit 100 MHz Bustakt und unter 133 MHz (ein Drittel mehr CPU-Takt) lohnt sich eine Übertaktung nicht besonders. Den Celeron II mit 66 MHz Bustakt zu übertakten - z.B. auf 100 MHz - ist in einem solchen Falle die Alternative, auch weil dies jedes gängige Mainboard unterstützt.
Die andere Anwendergruppe ist diejenige deren Grafikkarte keine 89 MHz Bustakt mitmacht oder aber die dieses Risiko gar nicht erst eingehen wollen. Bei Übertaktung eines Mainboards mit i440BX-Chipsatz geht der AGP-Takt unweigerlich auf 89 MHz hoch - nur Boards mit VIA´s Apollo Pro 133 oder Intels i820/i840-Chipsätzen (die RAMBUS-geschädigten) beherrschen nun mal echten 133 MHz Bustakt in all seinen Konsequenzen. Dazu gibt es auf Tom´s Hardware Guide einen Artikel in wie weit verschiedenen Grafikkarten die 89 MHz AGP-Takt aushalten. Ich würde die dort getroffenen Aussagen allerdings nicht komplett für bare Münze nehmen - bei Übertaktung funktioniert jede einzelne Karte nun mal anders. Das sicherste ist es mit eigene Karte zu versuchen irgendwo anders mal die 89 MHz AGP auszutesten - oder aber den Celeron II zu nehmen und dort 66 MHz Bustakt auf 100 MHz setzen.
Womit wir gleich beim Problem des Celeron II wären: Richtig Sinn macht Übertaktung es erst wenn es von 66 MHz Bustakt auf 100 MHz geht (was der Hälfte mehr CPU-Takt entspricht), auch weil dann alle Systemtakte wieder nominal laufen. Nur - einen 600er Celeron II (9 * 66,67 = 600) auf 100 MHz Bustakt zu setzen wird schon riskant - da kommen schließlich 900 MHz heraus! Ob das der Chip ohne spezielle Kühlung mitmacht steht zu bezweifeln. Damit werden nur die ganz kleinen Celeron II sich richtig zum Übertakten eignen. Ich halte selbst den 566er (8,5 * 66,67) auf 850 MHz für gewagt, daß größte Erfolgspotential hat der 533er (8 * 66,67). Der wird mit ein wenig Glück und besserer Kühlung durchaus die 800 MHz schaffen.
Frage nur: Bringt Intel den 533er Celeron II überhaupt heraus? Es gibt momentan schon einen 533er Celeron - allerdings noch in 0.25 micron und noch mit altem Pentium2-Kern. Begeistert über die Overclocker sind die Prozessor-Hersteller ja noch nie gewesen. Insofern ist es nicht unmöglich das Intel gleich - um den Overclockern einen Riegel vorzuschieben - einen 566er Celeron II herausbringt. Und bei diesem würde ich wirklich abwarten wollen was die Overclocking-Götter so sagen, ehe man selbst das Risko eingeht.
Denn falls der 566er nicht die 100 MHz Bustakt schafft stehen den meisten Anwendern nur noch 75 MHz zu Verfügung was 638 MHz bedeuten würde - kein großer Gewinn. Bei 83 MHz Bustakt (706 MHz) funktionieren schon mal einigen die EIDE-Festplatten oder die PCI-Karten nicht mehr richtig - dies ist keine Option welcher jeder so einfach nutzen kann. Insofern lege ich alle Hoffnung in den 533er Celeron II - wenn er denn kommt.
Nachtrag vom 6. Mai ...
Das "Warten" hat sich gelohnt: Zuerst beschätigte ich mich mit dem
Overclocking des Celeron II und dann noch mal
mit den Leistungen gegen einen Pentium III.
Nachtrag vom 28. Mai ...
Unser erstes Review - Intel Celeron II 566 MHz @ 850 MHz
neue SpeedUp-DLLs für Q3A
19. März 2000 / von Leonidas
Passend zum 1.16er Patch gibt es wieder neue Speed-Optimierungen für Quake III Arena - angepasst auf eben diesen 1.16er Patch.
In meiner Konfiguration war die Optimierung von Quake3World die schnellste, der Abstand zu der von Stomped ist allerdings gering. Auch die beiden "alten" Optimierungen sind mit meiner Hardware nicht langsamer, der Abstand schnellste zu langsamste liegt bei nur einem unbedeutenden Prozent.
So gesehen kann das bei anderen Hardware-Konfigurationen wieder ganz anders aussehen - wer die Zeit und Muße hat sollte alle vier Stück ausprobieren und die entsprechend schnellste auswählen (zu den Downloads).
Entgegen mancher alten Anleitung kommen alle Dateien grundsätzlich in das
baseq3-Verzeichnis von Q3A. Zum Ausschalten der lästigen Warnfenster setzt man in
seiner autoexec.cfg folgenden Befehl ein:
set com_blindlyLoadDLLs 1
Nachtrag vom 15. April ...
Story der ersten beiden Optimierungen in drei Teilen:
Teil 1,
Teil 2 und
Teil 3
com_blindlyLoadDLLs
13. März 2000 / von Leonidas
Kann sein das es einigen schon mal aufgefallen ist, mit der 1.16 hängt sich Q3A beim Map-Wechsel ab und zu auf, weil eine Warnmeldung in einem - unsichtbaren - Fenster bestätigt/abgelehnt werden muß?
Die Warnmeldung betrifft die Nutzung der Speed-Up-DLLs für Q3A. In der ReadMe zum 1.16 stand zwar ein Befehl drin, wie dieses Warnfenster grundsätzlich auszuschalten wäre, und zwar:
Clients can turn OFF the confirmation dialog by with the console command: "/com_blindlyLoadDLLs 1".
... funktioniert bloss nie. Ich habe dann doch noch mal bei Robert Duffy von idSoftware nachgefragt, hier die Antwort:
it is not a command it is a cvar
set com_blindlyLoadDLLs 1
or on the command line "+set com_blindlyLoadDLLs 1"
robert...
Funktioniert nun einwandfrei. Wer sie noch nicht hat - die Speed-Up-DLLs für Q3A liegen genau hier.
Nachtrag vom 14. März ...
Nicht zu vergessen - mit dem 1.16er Patch kommen die Speed-Up-DLLs nicht mehr
ins Quake3-Hauptverzeichnis sondern ins baseq3-Verzeichnis - ansonsten werden
sie gar nicht erst geladen.
S3TC in Q3A
13. März 2000 / von Leonidas
Ich will noch ein wenig aus eigener Erfahrung zu den 5.08er Detonator-Treibern für die GeForce schreiben, da ich am Wochenende endlich mal Zeit hatte mit diesen ein wenig zu experimentieren ...
Weil ein paar Screenshot enthalten sind welche die Ladezeit dieser Newsseite zu stark vergrößern würden ist dieser Artikel hierhin ausgelagert wurden.
5.08er Detonator
8. März 2000 / von Leonidas
Dieser GeForce-Treiber zieht ja nun wirklich Kreise ... nicht nur die Möglichkeit S3TC unter OpenGL sondern auch über einen Registry-Hack FullScene-Antialiasing zu nutzen! Überall im Netz findet man jedenfalls Screenshots mit eben diesem FSAA, Benchmarks alte gegen neue Treiber und mit und ohne FSAA und so weiter. Eine Auswahl:
- Guru3D - Screenshots Quake III, Anleitung FSAA
- 3DGPU - Benchmarks Quake III
- Thresh´s FiringSquad - komplette Benchmarks mit/ohne FSAA und gegen "alte" Treiber
- Riva3D - Screenshots Half-Life
- nVNews - Screenshots Unreal Tournament
- nVNews - Screenshots Quake III
- Planet GeForce - Screenshots Quake III
- Rivastation - Anleitung FSAA und S3-Level, Screenshots und Benchmarks Quake III
- Reverend The Pulpid - Screenhots und Benchmarks Quake III, Screenshots Descent 3
- Reactor Critical - Screenshots und Benchmarks Quake III, Anleitung FSAA
Anderseits gibt es schon eine Reihe von Gegenanzeigen, daß der 5.08er Treiber einige Spiele zum Absturz bringt - wobei dies hardwareabhängig bei jedem unterschiedlich sein wird. Auch unter Quake 3 wurde teilweise von diversen Fehldarstellungen berichtet.
Wer es dennoch versuchen will: Den 5.08er Treiber laden (2,3 MB), S3TC funktioniert dann unter Quake III automatisch (ausschalten mit: "r_ext_compress_textures 0"). Die S3-Levels befinden sich bei S3/Diamond, die extra Startdatei "DMMQ3.exe" nicht vergessen, mit der muß auch das Spiel gestartet werden will man in den Genuß der S3-Levels kommen. Das FSAA kann mit diesen Registry-Dateien aktiviert/deaktiviert werden (funktionieren nur wenn die GeForce diejenige Grafikkarte im System ist, welche zuerst installiert wurde - ansonsten Anleitung wie z.B. auf Rivastation durchlesen).
Nachtrag vom 13. März ...
Ich habe mich gleich nochmal mit dem Thema GeForce-Texturenkomprimierung in Q3A beschäftigt -
diesmal etwas ausführlicher.
Nachtrag vom 28. März ...
5.13er Detonatoren
Nachtrag vom 7. Mai ...
Oben genannte Files sind runter von unserem Server. Der jeweils aktuelle GeForce-Treiber liegt
ab sofort immer hier.
GeForce und S3TC
6. März 2000 / von Leonidas
Darüber das nVidia die S3TC-Texturenkomprimierung für OpenGL von S3 lizensieren will wurde ja schon ab und an spekuliert. Hintergrund: nVidia´s GeForce kann das S3-Texturenkompressionverfahren in Hardware, nur fehlte bisher für OpenGL die notwendige Lizenz seitens S3. In DirectX ist dieses Verfahren unter dem Namen DXTC seit Version 6.0 enthalten und steht somit allen Chips offen welches dieses unterstützen.
Nun scheint aber aus der Spekulation Realität zu werden, denn Björn3D liegt eine Mail von nVidia vor, welche die Arbeit an entsprechenden Treibern (Detonator 5.08) bestätigt. Außerdem hat Björn3D zwei nette Screenshots mit und ohne Texturenkomprimierung in Quake 3 abbekommen. Der Unterschied in der Grafik ist minimal - der Geschwindkeitsgewinn ist momentan noch nicht abschätzbar. Die von nVidia getätigten Benchmarks weisen zwar einen Speed-Vorteil durch S3TC aus - allerdings ist dies unter 1600*1200 auch nicht wesentlich verwunderlich. In dieser hohen Auflösung wird der Grafikspeicher knapp und da wirkt dann die Texturenkomprimierung Wunder. Ob S3TC unter 1024*768 mehr fps bringen steht zu beweifeln.
Zwei interessante Sachen sehe ich hier:
Wer bisher Quake 3 unter 32 Bit Texturen spielte und auch daran festhalten will sollte S3TC
gleich wieder vergessen - die herauskommende Texturenqualität liegt leicht unter 16-Bit-Texturen-Niveau.
Der Punkt wird bei aller S3TC-Euphorie ganz gern vergessen ... 12. März: Irrtum meinerseits - Richtigstellung
siehe hier.
Wer unter 16 Bit Texturenqualität spielt wird aller Voraussicht nach keinerlei
Geschwindigkeitsvorteil feststellen, es sei denn bei den sehr hohen Auflösungen ab 1280*960. Darunter
sollte es egal sein ob die Texturen in voller Schönheit oder in komprimierter Form im Grafikkarten-Speicher
schlummern - eine 32-MB-GeForce schafft das problemlos.
S3TC unter OpenGL ist nett, aber leider nicht mal die Hälfte der Wahrheit - denn die komprimierten OpenGL-Texturen der originalen Maps von Quake 3 sehen visuell nicht besser aus. Sicher gibt es die S3-Level, aber für die gibt es einfach zu wenig Server. Richtig interessant wäre die Texturenkomprimierung für Unreal Tournament, da die auf der Extras-CD enthaltenen Texturen wirklich besser aussehen. Hier wird nVidia mit den S3TC-enthaltenden Treibern aber nicht weiterkommen - es liegt alles bei den UT-Programmierern Epic. Diese müssen sich dazu aufschwingen, endlich die in der UT-Engine enthaltene Texturenkomprimierung auch für Direct3D und OpenGL umzuschreiben. Momentan funktioniert diese Texturenkomprimierung in UT nur bei S3´s MeTaL-APi. Und da hilft dann auch kein neuer Detonator-Treiber mit S3TC ...
Worauf ich hinaus will: nVidia sollte S3TC unter OpenGL durchziehen, sich aber nicht daran aufhalten (auch wenn es PR-technisch sicher gut vermarktbar ist) - um dann endlich Epic auf die Füße zu treten und dafür zu sorgen, daß Unreal Tournament die großen Texturen der Extras-CD auch unter Direct3D respektive OpenGL beigebracht werden. Dies würde uns wesentlich mehr bringen als S3TC unter Quake 3.
Sinn und Zweck von Texturenkomprimierung ist es nicht, Texturen die sowieso in den Grafikkarten-Speicher passen würden aus Spaß an der Freunde zu komprimieren, sondern Levels mit komprimierte Texturen zu nutzen welche ohne die Komprimierung nicht spielbar wären weil die Texturen - unkomprimiert - nicht in den Grafikkarten-Speicher passen würden. Ersteres bringt im Prinzip gar nichts, letzeres bringt deutlich schönere Levels.
Nachtrag vom 7. März ...
So schnell kann es gehen - auf Reactor Critical gibt es schon die 5.08er Treiber.
Temporäre lokale Kopie (2,3 MB). Sie sollen angeblich wesentlich schneller als
die bisherigen 3.72er in Quake 3 sein (um die 5 bis 10 % Plus, Messung seitens Rivastation.
Richtigstellung vom 12. März ...
Die Aussage, daß die komprimierten Texturen in Quake 3 auf 16-Bit-Niveau liegen ist schlicht falsch (mein Fehler).
Richtig ist das die vorkomprimierten Texturen in Unreal Tournament auf 16-Bit-Niveau liegen - Quake 3 komprimiert
die Texturen aber beim Einladen des Levels und es komprimiert sowohl 16- als auch 32-Bit-Texturen. Die 32-Bit-Qualität
der komprimierten 32-Bit-Textur in Quake 3 bleibt dabei weitestgehend erhalten.
Nachtrag vom 13. März ...
Ich habe mich gleich nochmal mit dem Thema GeForce-Texturenkomprimierung in Q3A beschäftigt -
diesmal etwas ausführlicher.
