DOOM III mit Framebremse ?
-
Hab ich das jetz richtig verstanden das einfach genaue Fließkommazahlen nach IEEE-Standart eine Genauigkeit von 6 bis 7 Dezimalzahlen haben. Damzufolge ein Reichweite von 8.43X10 hoch-37 bis 3.37X10 hoch38. Bin nicht so gut in Mathe.
-
junix schrieb:
TomasRiker schrieb:
also gibt es 2^32 verschiedene float-Werte
Das wiederum ist nun kreuzfalsch.
Wieviele sind es denn?
-
Nach IEEE bestehen Einfachgenaue Werte aus 23Bit großen, normaliesierten Mantiessen, einem 8 Bit Exponenten mit einem Offset von 7FH und einem Vorzeichen Bit.
Wenn ein Fehler drin ist bitte richtig stellen. Ich habe erst gestern mit der Programmierung begonnen
*ausrede*
-
Jester schrieb:
angenommen wir haben nen großen Exponenten, in der Mantisse stecken immer gleich viele Bits, also gleich viele Stellen. Durch die Verschiebung im Exponenten haben wir dann manchmal keine Nachkommstallen und manchmal eben sehr viele. Aber dadurch ändert sich die Genauigkeit sehr stark. Bei großen Zahlen liegen die darstellbaren Zahlen manchmal sehr weit auseinander. Bei kleinen Zahlen nahe bei 0 hast Du also recht genaue Schritte. Dennoch gibts es Zahlen (und zwar mehrere, nicht nur 0...nennen wir sie x), die zwar selbst noch darstellbar sind, für die aber zum Beispiel gilt: 1+x=1
Also nichts mit immer gleicher Genauigkeit.Aber die Genauigkeit hängt nicht mit der Differenz zum Nachfolger/Vorgänger zusammen, sondern mit der Anzahl der signifikanten Stellen. Und diese ist bei Fliesskommanzahlen immer gleich (24 bei float). Daher ist dein Schluss falsch.
@TomasRiker:
Nein die Genauigkeit nimmt eben nicht ab/zu da, die Zahlen nicht gleichverteilt sind, wie es Jester ja beschreibt.
-
Letzten Endes ist es auch wurscht - dann hat das mit der Framerate eben einen anderen Grund!
-
[Numerus] schrieb:
Hi,
TomasRiker schrieb:
Vielleicht werden bei hohen Framer1aten einfach die Fließkommazahlen zu ungenau, weil man es mit sehr kleinen Werten zu tun kriegt. Oder John Carmack hat sein Physiksystem schlampig designt!
köder schrieb:
TomasRiker schrieb:
Oder John Carmack hat sein Physiksystem schlampig designt!
Ist egal. Er wird wieder Geschichte schreiben. Jeder von uns hat doch den Quellcode von Quake gesehen. Sehr professionel sah das nicht aus
Das zweifel ich jetzt mal ganz stark an !!
Bye
goto fail;Dieser Codeabschnitt ist von de Quake2 Engine. Das sagt doch schon alles.
-
TomasRiker schrieb:
Letzten Endes ist es auch wurscht - dann hat das mit der Framerate eben einen anderen Grund!
naja,
du befindest dich an 10000.f (1.e4)
bei 350fps (die quake mitlerweile erreicht) hast du bei 1.f geschwindigkeit noch 0.002857f (0.285614e-2) weg zu bestreiten, somit bist du beim nächsten frame bei 1.000000285614 (1.e4)das ist ein extrembeispiel, aber die begründung weshalb float zu ungenau wäre.
es mag sein, dass eine q3a level kleiner ist, aber bei doom3 gibt es eben physic berechnungen, diese nutzen öfters beschleunigung zur berechnung, da kann also (1.f/350.f)^2 auftauchen 8.16e-6 bei (1.f/60.f)^2 wären wir noch bei 2.78e-4
bei 350fps dürfte die level nicht größer 1.f sein falls man mit max 1.f läuft, damit man noch die anfangsbeschleunigung zum fortbewegen nutzen kann ansonsten wäre float zu ungenau, bei 60fps würde man bei noch 100.f levelgröße eine fortbewegung haben.
da jeder room für sich alleine aggeiren soll in doom3 (soweit man munkelt) und die räume auch nicht sonderlich gross sind, wäre eine maximale levelgröße (raumgröße durch portale getrennt ist gemeint) von 100.f ausreichend...klar sind das vermutungen bezüglich D3, aber das ändert nichts an der genauigkeit von float die durchaus zuwenig sein kann.
rapso->greets();
-
KLAUSUS schrieb:
[Numerus] schrieb:
Hi,
TomasRiker schrieb:
Vielleicht werden bei hohen Framer1aten einfach die Fließkommazahlen zu ungenau, weil man es mit sehr kleinen Werten zu tun kriegt. Oder John Carmack hat sein Physiksystem schlampig designt!
köder schrieb:
TomasRiker schrieb:
Oder John Carmack hat sein Physiksystem schlampig designt!
Ist egal. Er wird wieder Geschichte schreiben. Jeder von uns hat doch den Quellcode von Quake gesehen. Sehr professionel sah das nicht aus
Das zweifel ich jetzt mal ganz stark an !!
Bye
goto fail;Dieser Codeabschnitt ist von de Quake2 Engine. Das sagt doch schon alles.
Find' ich auch!!
Absolut genial, in Zeiten überhöhten Overheads durch übertriebene OOP mal wieder irgendwo was Leistung rauszuhauen...!!
Was gibt's performanteres?!
-
Also bei Q3 war dir normale Laufgeschwindigkeit IMHO 320 ups (units per seconds) und die grössten Level vielleicht 60s lang, macht ~20000 Units (klar, wer will da ewig rumlaufen). Ausserdem muss man bei dieser Ungenauigkeitsfragen auch immer bedenken, das Rechnungen, bei denen in irgendeiner Form gerundet wird, weil etwas als konstant angenommen wird, was sich während des Frames ändert, immer durch _kürzere_ Frames genauer wird. Also ich kanns mir eigentlich nicht vorstellen, das man sowas machen würde um Ungenauigkeiten auszuschliessen. Das könnte man auch anders lösen, und "marketingtechnisch" wäre diese andere Lösung sicher anzustreben.
Bye, TGGC
-
TGGC schrieb:
C-O-M-M-A-N-D-E-R schrieb:
framelock nicht optinoal!!
wird definitiv nur 60 FPS geben!!!
gestern in irgendeinem artikel gelesenArtikel != Realität
q.e.d.
Bye, TGGC (Der Held bei Dir!)
-
Helium schrieb:
Das zweifel ich jetzt mal ganz stark an !!
Was? Das jeder hier den Quake-Code gesehen hat? Meinetwegen. Trotzdem sieht er nicht grade toll aus.
Liegt AFAIK daran, dass die Leute von ID die alten Compilern und deren Optimierungen fuer zu schwach hielten, und selbst alle moeglichen Optimierungen reingehackt haben. Geruechten zufolge wurde sogar der ASM-Code, den die Compiler ausgespuckt haben, noch von Hand optimiert...
Ich kann leider keine Quellen angeben, aber ich hab's irgendwo mal gelesen *ueberleg*
-
deren assembler code ist zwar recht optimiert, aber die verwenden fast immer den selben shader, was nicht optimal ist. nvidia ersetzt den shader durch immer den passendesten, sodass um einiges weniger bearbeitet wird.
siehe: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=169471
rapso->greets();
-
Tobiking schrieb:
Es soll dann glaube ich so rauskommen das dann bei 120 fps alle Frames 2 mal gezeigt werden. Also ohne bewegungsunterschiede.
aber nur, weil carmack entweder nicht auf die idee kam bewegungen zwischen zwei updates zu interpolieren oder es für die engine einfach zuviel geworden wäre. soweit ich das verstehe, ist die physik jetzt schlicht auf 60 updates geprügelt, aus dem einfachen grund, daß die in früheren spielen reichlich bescheiden war (und man z.b. mit mehr fps höher oder weiter springen konnte). ich erinnere mich dunkel gelesen zu haben, daß die selbst bei q3 noch mit ints gerechnet haben (was hoffentlich ein mißverständnis war und in wirklichkeit auf fixed point rauslief).
ohne interpolieren wäre es aber tatsächlich schwachsinn mehr als 60 bilder darzustellen und vollkommen verschenkte leistung.
Obwohl man ja auch bei Monitoren sagt das man bei 60 Hz noich ein Flackern sehen kann.
nur hat die bildschirmfrequenz null damit zu tun wie oft sich der inhalt des bildes ändert ,-) höchstens wenn vsync aktiviert ist und die karte die 60fps nicht gut schafft gibts probleme, die bestehen aber eher darin, daß durch unglückliches timing die fps halbiert werden (in allen anderen fällen würde ich es trotzdem dem bild zuliebe nicht deaktivieren).
TheTester schrieb:
der angeschaltete vsync dürfte ja auch sone funktion haben, wartet das system da eigentlich direkt also praktisch ein kompletter halt oder kann der rechner nebenbei was ausführen?
vsync blockiert den bufferswap bis das letzte bild vollständig dargestellt wurde. falls du also zum rendern nicht grade einen getrennten thread benutzt steht solange das ganze programm (oder zumindest alles, was im gleichen thread läuft). deswegen plaziert man den swap auch sinnigerweise möglichst spät, sprich: direkt bevor man den neuen frame pinseln will.
kurz:
-render bla und render blub (und NUR rendern)
-physik, ai
-culling, "vorbereitende maßnahmen" für den nächsten frame
-swapweil das ganze sowieso als schleife läuft ist swap-render-rest einfacher zu überschauen ,-)
TomasRiker schrieb:
Vielleicht werden bei hohen Frameraten einfach die Fließkommazahlen zu ungenau, weil man es mit sehr kleinen Werten zu tun kriegt.
eher umgekehrt, floats werden genauer je kleiner die werte sind:
1,2345
1234,5
was ist genauer?sorgen gibts erst, wenn wirklich mal 0,0000000001 rauskommen würde und ein float daraus 0 macht (aber die gefahr seh ich bei doom3 nicht so bald *fg*). bei einem profiler wären allerdings doubles keine blöde idee ,-)
-
Hi
@ Trienco beides ist gleich genau, da die genauigkeit von der anzahl der Ziffern der Mantisse abhängig ist und nicht von der grösse ( was dem exponenten gleichkommen würde).
eine Flotzahl besteht aus einer Mantisse und einem Exponenten. die Mantisse kann man sich als ganz normale Intzahl vorstellen. der Exponent gibt dan an um viele stellen das Komma verschoben werden soll.
Mantise * 10^Exponent
und übrigens wer rechnet mit zahlen mit über 300 oder 4900 Stellen (egal ob vor oder nach dem Komma)? nicht mal Physiker. Somit sind double und long double total neben der realität.
das grosse problem bie Flieskomma zahlen ist das addieren und subtrahieren von grossen und kleinen zahlen. da kann es schon mal passiren, das eine kleine zahl auf grund von rundung einfach auf 0 gerundet wird, da sie die Mantisse der grossen zahl nicht mehr beinflusst, und das macht man dann 3 Millinen mal und wundert sich das die zahl nicht kleiner wird.
gruss Termite
-
Nehmen wir mal das Beispiel mit 5 Ziffern: 1234,5
hier kann ich in 0,1er-Schritten gehen.1,2345
hier kann ich in 0,0001er-Schritten gehen.
Aber Du kannst gerne behaupten das sei gleich genau. 0,1 ist schließlich fast das selbe wie 0,0001.
MfG Jester
-
Hi
aber beide haben 5 ziffern uns sind somit auf 5 dezimalstellen geanu. egal wo bei flot das komma steht das ist nu mal bei flot egal.
Bei flieskomma zahlen ist der interne aufbau für die genauigkeit entscheident.
1234.5 wird in 1.2345 * 10^3 dargestellt und
1.2345 wird in 1.2345 * 10^0 dargestellt.und wo ist nun bitte genauer 1.2345 (*10^4) oder 1.2345 (*10^0) ?
auserdem jester. du vergleicht gerade zwei verschiedene sachen. einmal die beiden 5 stelligen zahlen. und einmal den kleinsten Wert den sie darstellen können. (wird glaub ich auch als maximaler Fehler bezeichnet)
beide zahlen können bei 5 Dezimalstellen maximal 10000 verschieden Werte annehmen. Egal wo das Komma steht. Damit haben beide Zahlen eine Genauigkeit von 1/100.000 auf ihren Wertebereich. der eine geht von 9.9999 bis 0.0000 der ander von 9999.9 bis 0.0
ok man kann nun die genauigkeit auf einen absoluten Wert umrechnen der wie du richtigt sagst 0.1 oder 0.00001 ist. und 0.00001 ist besser als 0.1 nur kann man bei einer kleinen absoluten Wert keine grossen zahlen darstellen.
versuch nun mal mit 5 dezimalziffern und 4 nachkommastellen auf 1.2345 sagen wir mal 8.7656 drauf zu addieren. sollte 10.0001 ergeben. was leider laut definition nicht mehr darstellbar ist. Entweder oben oder unten eine 1 wechlassen. was ist besser ?
gruss Termite
-
ihr streitet euch um 2 verschiedene dinge.
1. genauigkeit von float, die ist immer gleich da standard
2. rechengenauigkeit wenn man mit float arbeitet. das hängt von der fpu und dem verwendetem code ab, wenn man da pech hat, dann gibt es abweichungen die weit größer sind als man von float erwarten würde einfach weil die verwendete fpu anders arbeitet.
rapso->greets();
-
Termite schrieb:
@ Trienco beides ist gleich genau, da die genauigkeit von der anzahl der Ziffern der Mantisse abhängig ist und nicht von der grösse ( was dem exponenten gleichkommen würde).
aber auch nur, wenn man die genauigkeit einer zahl als die gesamtanzahl der stellen sieht. rechnen in 1/10 schritten wird wohl kaum jemand ernsthaft als besonders genau bezeichnen, denn in dem moment ist es mir schnurz, ob vor dem komma 1 oder 8 stellen stehen.
und übrigens wer rechnet mit zahlen mit über 300 oder 4900 Stellen (egal ob vor oder nach dem Komma)? nicht mal Physiker. Somit sind double und long double total neben der realität.
bitte was? mit 23bit mantisse komme ich maximal auf was, 8.388.607? das sind lächerliche sieben stellen und wenn die mal nicht zufällig aufeinanderfolgen haben floats ausgeschissen. 20000,001? hoppla, da bekommt mein weltraum spiel aber recht ruckelige positionswechsel, wenn ich nicht zusätzlich trickse und naiv die position als float speichere, denn allein so ein sonnensystem hat ja gerne mal 10.000mio km durchmesser und die position wird ja dann doch eher mindestens in m gerechnet. 10.000.000.000.000m ? ich glaube der float bröckelt grade ein wenig bei einem exp von 14 und einer schrittweite von entsprechend 10km. ein double kommt auf 15 stellen und siehe da, wir brauchen sogar nur 14 und kommen locker aus oder können in dezimeter rechnen ohne uns nen kopf zu machen. natürlich könnte man auch gleich nen 64bit integer nehmen und in mm rechnen ,-)
daß uns das rendern am ende um die ohren fliegt, weil die karten mit floats rechnen ist eine andere sache.
ein fehler war trotzdem drin, die genauigkeit von float ist zur 0 hin besser, nicht für kleine zahlen.
-
Trienco schrieb:
eher umgekehrt, floats werden genauer je kleiner die werte sind:
1,2345
1234,5
was ist genauer?sorgen gibts erst, wenn wirklich mal 0,0000000001 rauskommen würde und ein float daraus 0 macht
Ist schon klar...
Bye, TGGC (Der Held bei Dir!)
-
Termite schrieb:
aber beide haben 5 ziffern uns sind somit auf 5 dezimalstellen geanu.
das scheitert schon daran, daß meine definition von dezimalstelle (die ich so auch im netz finde) wohl eine andere ist, nämlich stellen _hinter_ dem komma.
