PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : StateMachine(s)


crazy_kong
2003-09-13, 09:30:23
Peisfrage:

vieviele Klassen und statemachines sollte ine spiel haben:

zb.

states:

Into:

wieviele states ?????




hauptauswahl:

wieviele states ?????





spiel:


-----

liquid
2003-09-13, 14:02:00
LOL Junge, was geht denn hier ab????

crozz-posting? (http://www.c-plusplus.de/forum/viewtopic.php?t=48851)

cya
liquid

zeckensack
2003-09-13, 16:43:36
Ich sage auch 32 :naughty:

Kann man aber binär-bäumen. 32 primär-states und für komplexe Sachen dann noch sub-states, deren unlatch von einem Eintrag in den primärstates getriggert wird :naughty:

Abe Ghiran
2003-09-13, 17:01:53
Zeckensack, das verstehe ich nicht?!?!? Du hast doch hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=90472) vor kurzem noch erklärt, das 32 mittlerweile doch ein bißchen wenig wird...
Also ich bin für 42, besser 64 (das ergibt dann auch wieder einen schön ausbalancierten binary tree).

Grüße, Jan

Sorry for spam ;)

zeckensack
2003-09-13, 17:14:16
Original geschrieben von Abe Ghiran
Zeckensack, das verstehe ich nicht?!?!? Du hast doch hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=90472) vor kurzem noch erklärt, das 32 mittlerweile doch ein bißchen wenig wird...
Also ich bin für 42, besser 64 (das ergibt dann auch wieder einen schön ausbalancierten binary tree).

Grüße, Jan

Sorry for spam ;) Eehhm, ja, 64 bit-Prozessoren könnten natürlich problemlos 64 states mit einem einzigen branch killen.
32 bit-Maschinen dominieren aber noch den Markt, deswegen ...
Mit dem Addressraum hat das doch nichts zu tun :|

Abe Ghiran
2003-09-13, 18:19:22
Original geschrieben von zeckensack
Mit dem Addressraum hat das doch nichts zu tun :|
Weiß ich doch ;). Nur kann ich die Frage vom Threadersteller und den Thread selbst irgendwie nicht ernst nehmen...;D

Deswegen noch mal, sorry for spam, kommt bestimmt nicht wieder vor.

Aber um mal doch noch was sinnvolles beizutragen: theoretisch gingen doch wirklich sehr einfach 64bit (z.B. mit long long beim gcc, als bitfeld mißbraucht, ich denke an was anderes dachtest du doch auch nicht?) - aber wie sieht das denn dann mit der performance auf einer 32bit Maschine aus, bzw. auf welche Register zerlegt der Compiler das dann, wenn man zwei 64bit int's mit einer boolschen op. verknüpfen will?

Grüße, Jan

zeckensack
2003-09-13, 19:42:45
Hrhr :D

Long long auf 32 bit-Maschinen ist natürlich 'emuliert'.
Das ganze Ding muß in die 'ticks' der SM, bei Renderern heißt das in die Draw Calls, also ist das direkt im kritischen Pfad und sollte am besten garnichts kosten.

Du hast im Optimalfall sowas im Highlevel-Code:
draw-calls:
if (state_changes!=0) unlatch_states();

unlatch_states:
flush();
...Wenn geflusht werden muß, ist sowieso alles zu spät. Es geht darum, daß es schnell sein muß, nicht zu flushen :)

Im ASM sieht das dann (von mir bevorzugt) so aus:
MOV EAX,[...]
TEST EAX,EAX
JNZ .unlatch

Bei 64 bit kriegst du dann wahrscheinlich diese Variante:
MOV EAX,[...]
TEST EAX,EAX
JNZ .unlatch
MOV EAX,[...+4]
TEST EAX,EAX
JNZ .unlatch
Also zwei branches. Schlecht.
Wenn ich den ASM dazu von Hand schreiben würde, sähe das so aus:
XOR EAX,EAX
OR EAX,[...]
OR EAX,[...+4]
JNZ .unlatch
Ich traue aber derzeit keinem Compiler zu, das so hinzukriegen ?-)

Demirug
2003-09-13, 20:01:35
Zecki, Ich habe zwei verschiedene gefunden die dich um eine Anweisung schlagen. In beiden fällen kommt das folgende heraus.


mov eax,dword ptr [...]
or eax,dword ptr [...+4]
je ...

Xmas
2003-09-13, 21:29:39
LOL

also irgendwie ist mir die Frage zu hoch ;D

GloomY
2003-09-13, 22:47:53
Klärt mich mal auf: Was sind Statemaschines? ???

Xmas
2003-09-13, 23:02:35
Original geschrieben von GloomY
Klärt mich mal auf: Was sind Statemaschines? ???
http://whatis.techtarget.com/definition/0,,sid9_gci214244,00.html

Zu Deutsch auch "Automat"
http://de.wikipedia.org/wiki/Endlicher_Automat

GloomY
2003-09-14, 11:34:53
Original geschrieben von Xmas
http://whatis.techtarget.com/definition/0,,sid9_gci214244,00.html

Zu Deutsch auch "Automat"
http://de.wikipedia.org/wiki/Endlicher_Automat Achsooooo... Ja, Automaten sind mir natürlich bestens bekannt :)

Gast
2003-09-14, 11:36:22
Aber wann und wofür brauch ein Spiel Automaten?

Demirug
2003-09-14, 11:56:19
Original geschrieben von Gast
Aber wann und wofür brauch ein Spiel Automaten?

Immer für alles was Interaktivitäten erlaubt.

Der einfachste Automat ist eine Lampe welche sich über einen Taster ein und ausschalten lässt.

zeckensack
2003-09-16, 20:34:22
Original geschrieben von Demirug
Zecki, Ich habe zwei verschiedene gefunden die dich um eine Anweisung schlagen. In beiden fällen kommt das folgende heraus.


mov eax,dword ptr [...]
or eax,dword ptr [...+4]
je ...
Oh Gott, ja natürlich :zweifel:

Chris Lux
2003-09-18, 15:32:29
Original geschrieben von zeckensack
Eehhm, ja, 64 bit-Prozessoren könnten natürlich problemlos 64 states mit einem einzigen branch killen.
32 bit-Maschinen dominieren aber noch den Markt, deswegen ...


sorry ich hab grosses technisches verständnis, aber das musst du mir erklären, was 64bit mit 64 states in einem branch zu tun haben? (sorry wenn ich dumm frage ;))

p.s. was meinst du mit unlatch states?

zeckensack
2003-09-19, 03:09:15
Original geschrieben von Hans Ohlo
sorry ich hab grosses technisches verständnis, aber das musst du mir erklären, was 64bit mit 64 states in einem branch zu tun haben? (sorry wenn ich dumm frage ;))

p.s. was meinst du mit unlatch states? Es geht mir um den Aufbau einer state machine.
Eine SM ist nach außen hin über eine API gekapselt, und da hast du zwei hauptsächliche Klassen von Funktionen:
1)Funktionen die "Arbeit" erledigen
2)Funktionen die die Konfiguration der Maschine ändern

2) ist hier das große Problem. "states" interagieren oft in komplexer Weise und es ist recht teuer, das für jeden Furz komplett auszurechnen. Bspw kann ich die Maschine sofort komplett umkonfigurieren, wenn ein state geändert wird. Dann kann's mir aber passieren, das die client-Applikation danach noch zehn weitere Änderungen vornimmt. Dann mache ich viel Arbeit umsonst, und client-Verhalten lässt sich auch nicht vorhersehen.


Des Rätsels Lösung ist nun ein Integer irgendwo, das festhält welche States verändert wurden. Die Funktionen die states ändern, machen dann erstmal nichts, außer die neuen Parameter aufzuzeichnen, und zu vermerken, welche Klasse von Parametern sich geändert hat. Das wäre dann eines von unseren 32 bits.
In den "Arbeits"-Funktionen prüfe ich nun, ob sich der state geändert hat, und wenn ja, konfiguriere ich die Maschine um, bevor die neue Arbeit ausgeführt wird. Wenn nicht ("make the common case fast"), wird diese Abfrage von der hoffentlich vorhandenen Branch prediction ziemlich gut wegoptimiert.



Diese Art von state management vereinfacht auch noch ein paar andere Dinge, und erlaubt ausserdem ziemlich leicht "batching". Das würde hier aber wirklich zu weit gehen.

Vielleicht schreibe ich mal ein Buch darüber :grübel:

liquid
2003-09-19, 17:37:30
Und ich würds auf jeden Fall kaufen (wenns gut ist :D)!!!

cya
liquid