4. DOOM III mit Framebremse ?

DOOM III mit Framebremse ?

  • T

    TGGC schrieb:

    @Tomas: Das mit den "einfach die Fließkommazahlen zu ungenau, weil man es mit sehr kleinen Werten zu tun kriegt", ist ja wohl schon unsinnig in sich. Weil "_Fließkomma_zahlen" 😉

    Ich verstehe nicht, was Du mir damit jetzt sagen willst...

    0
  • H

    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.

    0

  • TomasRiker schrieb:

    TGGC schrieb:

    @Tomas: Das mit den "einfach die Fließkommazahlen zu ungenau, weil man es mit sehr kleinen Werten zu tun kriegt", ist ja wohl schon unsinnig in sich. Weil "_Fließkomma_zahlen" 😉

    Ich verstehe nicht, was Du mir damit jetzt sagen willst...

    Ich meine wenn sich die Framezahl verzehnfacht, dann "fliesst" das Komma eine Stelle weiter und die Genauigkeit bleibt gleich.

    0
  • T

    Aha, ein Wortwitz 😃
    Du weißt natürlich, dass ich float und double meine, deren Genauigkeit nicht unendlich ist.

    0

  • Nein, das ist kein Wotrwitz. Fließkommazahlen heissen wirklich so, weil das kommen daher umher fliessen kann wie es möchte. Daher ist deren Genauigkeit unabhängig von der Größe der Zahlen. Natürlich müsste man sich das binär vorstellen, d.h. bei Verdopplung/Halbierung einer Zahl wird das Komma verschoben.

    Bye, TGGC

    0
  • T

    Angenommen ich benutze floats.
    Ein float hat 32 Bits, also gibt es 2^32 verschiedene float-Werte (einige davon sind vielleicht ungültig, also könnten es auch ein paar weniger sein).
    Da müsste doch die Genauigkeit abnehmen, wenn ich mit sehr kleinen Zahlen rechne, da das Ergebnis vielleicht mit diesen 32 Bits garnicht mehr darstellbar ist.

    0
  • J

    TGGC schrieb:

    Daher ist deren Genauigkeit unabhängig von der Größe der Zahlen.

    Woohoo it's magic ehhhh?

    Dann stells Dir halt mal binär vor:

    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.

    MfG Jester

    0
  • J

    TomasRiker schrieb:

    Angenommen ich benutze floats.
    Ein float hat 32 Bits,

    Soweit noch richtig.

    TomasRiker schrieb:

    also gibt es 2^32 verschiedene float-Werte

    Das wiederum ist nun kreuzfalsch.

    http://www-irm.mathematik.hu-berlin.de/~hgrass/0wr/node4.html
    oder
    http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/overview/reals.html
    zur Klärung.

    -junix

    0
  • ?

    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. 😞

    0
  • T

    junix schrieb:

    TomasRiker schrieb:

    also gibt es 2^32 verschiedene float-Werte

    Das wiederum ist nun kreuzfalsch.

    Wieviele sind es denn?

    0
  • ?

    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*

    0

  • 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.

    0
  • T

    Letzten Endes ist es auch wurscht - dann hat das mit der Framerate eben einen anderen Grund!

    0
  • ?

    [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.

    0
  • R
    Mod

    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();

    0
  • S

    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?! 🕶 😉

    0

  • 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

    0

  • 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 gelesen

    Artikel != Realität

    q.e.d.

    Bye, TGGC (Der Held bei Dir!)

    0
  • B

    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*

    0
  • R
    Mod

    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();

    0
Anmelden zum Antworten