FarCry 64 Bit - höhere Sichtweite, wieso?
-
Mich würde das gerade mal interessieren.
Das Problem bei hohen Sichtweiten ist doch normal das z-Buffer-Flimmern, oder? Die Auflösung des z-Buffers hängt aber meines Wissens nach von der Grafikkarte ab. Oder kann die Grafikengine die Objekte mit 32Bit-doubles tatsächlich nicht mehr genau genug sortieren?? Der z-Buffer ist im Vergleich dazu doch meistens gar nicht erst mit 32Bit Genauigkeit bestückt, der wird aber wohl sicher mal zumindest für die Darstellung von Nebel und Schatteneffekten benutzt. Also müsste eigentlich nicht eher der z-Buffer die Sichtweite schon limitieren anstatt der CPU?Danke für Informationen.
-
mehr sichtweite bedeutet auch mehr rechenlast.
64bit cpus sind, zumeist viel leistungstärker als die, die noch keine 64bit hatten, so kann man dort also die sichtweite ein wenig höcher stellen ohne angst haben zu müssen, dass ein n00b mit einer 1GHz cpu anfängt zu weinen dass es bei ihm ruckelt.aber der hauptgrund ist eigentlich, 64bit bringt erstmal garnichts. also muss sich das marketing irgendwas aus den fingern saugen. so enstehen dann die 32bit screenshots auf kleinsten details und 64bit in höchsten.
aber du mußt den leuten nunmal immer was erzählen. "ja wir haben nun 64bit.. was es bringt.. emm, ja es ist cool und register presure ist kleiner.. emm.. ja und wenn wir viele gigabyte an daten hätten, würde es nur auf 64bit laufen und emm... ne, sie sehen keinen unterschied".
rapso->greets();
-
Ok, größtenteils Marketing-Gag also. Danke.
Ich find ja 64 Bit Wortbreite prinzipiell nicht verkehrt, weil ich selber auch oft mit 64 Bit - Werten hantiere und es ist nicht schwer vorstellbar, dass eine Division auf so einem Prozessor deutlich schneller abläuft. Aber für das Problem der Sichtweite war mir das eher weniger einsichtig.
-
jeder x86 ab 386 kann 64bit divisionen durchführen (64bit/32bit=32bit + 32bit_rest)
je größer die werte, registerbreite, desto langsammer ist es natürlich.
64bit sind kein marketinggag, bringt ja eventuell was. aber dafür muss dann alles eigentlich ausgelegt worden sein. ist wie mit pentium vs pentium pro. der pro war eigentlich fixer, aber die für den pentium geschriebenen/compilierten programme waren darauf langsammer.
dass die graphikqualität sich ändern, indem man plötzlich weiter sieht und bumpmapping bekommst, ja das ist gag.
rapso->greets();
-
Optimizer schrieb:
...Das Problem bei hohen Sichtweiten ist doch normal das z-Buffer-Flimmern, oder?...
Das lustige daran ist, das sich das Problem bereits allein durch das Runterskalieren des Koordinatensystems beheben lässt. Noch dazu gibt das einen satten Geschwindigkeits-Vorteil. Habe das letztens beim Rendern von 3DS Models mit astronomisch grossen Koordinaten beobachtet, die nach dem runterskalieren plötzlich doppelt so schnell und ohne flimmern dargestellt wurden
-
Cpp_Junky, was du da schreibst hat wohl andere gründe, durch runterskalieren alleine kann man die von dir beschriebenen effekte kaum erhalten.
rapso->greets();
-
Dann nimm dir doch mal irgendeinen OpenGL Code. Am besten den 3DS Loader von NeHe und multiplizier beim Laden jede Koordinate mit 100. Dann guckst du dir die Framerate an und machst das gleiche nochmal indem du jede Koordinate mit 0.5 multiplizierst. Ich kann mir das auch nicht erklären, kann das hier aber auf zwei verschiedenen Rechnern mit unterschiedlichen Grafikkarten (nVidia GeForce 5900 und ATI Radeon 7000) reproduzieren.
-
Also prinzipiell sollte nach meinem Verständnis eine Verkleinerung nichts bringen. Floating Points haben kein Problem mit großen Werten, wenn alle anderen Werte auch groß sind. Umgekehrt nimmt die Genauigkeit nicht zu, wenn du alles in einem Bereich von -0.00001 bis +0.00001 abspielen lässt. Große Unterschiede im Betrag zweier Zahlen sind immer problematisch und bleiben es bei jeder Skalierung.
Was natürlich wirklich sein kann, dass du einfach Probleme kriegst, wenn du der größten darstellbaren Zahl nahe kommst. Aber dann muss man es schon sehr übertreiben.