DOOM III mit Framebremse ?



  • die hardware gibts eh noch net um mehr als 60 fps anzuzeigen!



  • framelock nicht optinoal!!

    wird definitiv nur 60 FPS geben!!!
    gestern in irgendeinem artikel gelesen



  • 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



  • Quelle : giga.de

    Eines gleich vorweg: Es stimmt. Das Spiel, das im ersten Quartal des nächsten Jahres in die Läden kommen soll, wird eine eingebaute Sperre haben, welche die Framerate auf maximal 60 begrenzt.

    Der Grund dafür wurde von John Carmack persönlich in einem Statement auf "IGN" erläutert. Demnach ist die eingebaute Uhr, die für die zeitliche Stimmigkeit aller Aktionen und Handlungen im Spiel sorgt, auf 60 Frames pro Sekunde eingestellt.

    Grund dafür wiederum sind Probleme, wie sie schon beim indizierten "Quake III" auftauchten. Hier waren nämlich manche Moves nur Spielern möglich, die über Rechenmonster verfügten, die Framraten von über 125 auf den Bildschirm bringen konnten.

    Durch den festen "Tic" werden dieselben Eingaben verschiedener Spieler auf unterschiedlichen Systemen immer das gleiche Ergebnis produzieren.

    Somit ist das also eine gute Sache



  • nur das John das Physik System nicht geschrieben hat und auch sonst so gut wie nix mit der erstellung des ->GAMES<- DOOM III zu tun hat...
    siehe dazu: http://doom3maps.ngz-network.de/news.php?extend.514

    er hat "nur" die Engine geschrieben. das Game zu implementieren übernimmt ein anderes Team.



  • Ok, schmeissen wir eben mit nichtsagenden Quotes umher:

    http://doom3.ca/

    Todd hollow-head the CEO of id software and Tim willits were interviewed by pc.ign games. Not sure if I listed this interview anywhere so I thought i'd post a link. Anyway they did mention that the game will see a 60 frames per second rate cap. But remember when quake 2 was invented Carmack was posting 28 frames per second. When quake 3 was produced the default setting was 83 frames per second, if people used fps (frames per second) higher than 100 servers would crash. Today if your frame rate drops below 100 in quake 3 things can get a little ugly. Lesson: framerate levels can change over time.

    Wie hatten auch irgendwo mal einen Link, wo nachzulesen war, das teilweise bis zu 90 Einzelbilder durch den Menschen wahrgenommen werden können...



  • TGGC schrieb:

    Todd hollow-head

    Muahahahahaha!! Der Arme...

    Naja, ich dachte schon nur ich wäre Doom 3 besessen... 🤡



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



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



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



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



  • 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



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



  • 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



  • 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



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


Anmelden zum Antworten