Individuelles Frametiming (Speicherfrage)
Übersicht

![]() |
Kernle 32DLLBetreff: Individuelles Frametiming (Speicherfrage) |
![]() Antworten mit Zitat ![]() |
---|---|---|
Hiho, für mein Spiel habe ich einen sog. AnimationController gebastelt, der einen FPS unabhängigen Zählalgo liefert. Das Problem dabei ist, das angeommen wird das jeder "Frame" die gleiche länge hat. In anbetracht dessen was ich noch umsetzen will, möchte ich jetzt versuchen mein System auf Individuelles Frametiming umzustellen (so wie es z.b. in Gif Animationen der Fall ist).
Das Problem ist dabei aber nicht wie ich das anstelle, sondern wie ich meine Daten dazu speicher. Mir sind zwei Möglichkeiten eingefallen, und ich würde mal gerne eure Meinung dazu hören. Dazu habe ich einen kleinen Test geschrieben, der imo gut zeigt wie sich die Systeme unterschieden, genauere Erklärung dazu unten... BlitzMax: [AUSKLAPPEN] SuperStrict Mein Test liefert mir dabei folgende Ergebnisse: Code: [AUSKLAPPEN] --------------------
Frames: 7 Animationtime: 267ms TestsToBeDone: 1000000 -------------------- calculating... -------------------- Results: FrameTest1: Memory ussage: 1068.00000 Byte 1.04296875 KByte 0.00101852417 MByte Timing: 232 FrameTest2: Memory ussage: 28.0000000 Byte 0.0273437500 KByte 2.67028809e-005 MByte Timing: 251 -------------------- Also meine beiden Systeme funktionieren wiefolgt: Das erste System erstellt einfach ein Array mit so viele Einträgen wie die Animation komplett in ms lang ist (siehe dazu AbsoulteFrameTime im Code, ganz oben). Das hat den Vorteil das man zur bestimmung des aktuellen Frame nur auf den Index der übergebenen ms time gehen muss, der Zugriff also quasi sofort ist. Leider wird der Speicherverbrauch sehr schnell übergroß. System 2 speichert dagegen relative Daten, d.h. für jeden Frame wird ein Indexeintrag erstellt, in dem gespeichert wird von wo bis wo in ms er "aktiv" ist. Z.b. von 0 bis 9 (d.h. der Frame ist 10 ms lang). Vorteil von System 2 ist definitiv der minimale Speicherverbrauch. Wie man am obrigen Test sieht ist der Geschwindigkeitsvorteil von System 1 zu minimal, der Speicherverbrauch aber schon bei geringen 267ms ca 1kb beträgt (ihr könnt euch vorstellen wie das bei besonders langen Animationen aussieht die 1 Minute gehen). Wie gesagt, ich würde einfach mal gerne hören was ihr so davon haltet. Oder ob euch selber noch was einfällt. So wie es aussieht würde ich System 2 wählen. So long, Kernle |
||
Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009 |
![]() |
HolzchopfMeisterpacker |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ich hab kurz eine alte BB-Version, wie ich sie mal gebraucht habe, nach BMax umgeschrieben. Kurze Erklärung:
Der aktuelle Frame wird erst erhöht, wenn die Spieldauer diejenige eines Frames überschreitet. Die While-Schleife sorgt dafür, dass, wenn die Spieldauer grösser ist als eine Framedauer, das Frame ganz übersprungen wird, dadurch bleiben Animationen immer schön Synchron. Ob diese Variante optimal ist, wäre noch zu prüfen, da bei jedem Hauptschleifenaufruf geprüft wird, ob das Frame gewechselt werden muss - aber ich stell's mir sowieso schwierig vor, so ein System zu realisieren, bei dem die Zeit direkt einen Index angibt... Weil ich keine animierten Bildchen zur Verfügung hab', gibt's halt einen fliessenden Graphen: BlitzMax: [AUSKLAPPEN] SuperStrict So wie ich das sehe, geht dein System 2 jeweils solange durch die Liste der Frames, bis es das richtige gefunden hat. Evtl zieht das bei vielen langen Animationen dann doch zu sehr an der Geschwindigkeit... mfG |
||
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm |
![]() |
Kernle 32DLL |
![]() Antworten mit Zitat ![]() |
---|---|---|
Also deine Methode ist schon ganz gut Holzchopf, werde sie mir aber nochmal im detail anschauen müssen.
Ich hatte indess nochmal eine Idee wie man das 2. System verbessern könnte. Statt die Zeit "Bereiche" zu speichern, speichere ich nur wie in den Ursprungsdaten (im Code ganz oben) nur die Dauer des Frames, und gehe davon aus dass das nächste Glied in der Kette (ob nun Array, List oder was auch immer) der nächste Frame ist. Wie ich jetzt vom einen auf den andere Frame komme stelle ich mir recht simpel vor. Ich habe zwei Variablen, eine die auf den aktuellen Frame zeigt, und eine, die quasi die "überschuss Zeit" angibt. Dazu gleich mehr. Gehen wir davon aus ich habe 2 Frames mit 100 ms die hintereinander kommen, und gehen wir davon aus das wir zur Zeit 0 starten, und seit dem letzten Update 104 ms vergangen sind. Dann passiert folgendes: ![]() ![]() ![]() ![]() d.h. die ÜberschussZeit beträge in dem Beispiel dann 4ms, und wir wären beim 2. Frame. Ich denke das System ist recht praktikabel - auch bei vielen Frames. Die einzige schwäche sehe ich wenn es sehr viele kurze Frames gibt, im worstcase sogar 1ms Frames. Dann muss sehr viel gesprungen werden, aber ich glaube das ist leider kaum zu vermeiden. Was haltet ihr davon? (Ich hoffe meine Erklärung war verständlich irgendwie) |
||
Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009 |
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group