Ein Zeit-mess-Event zweckentfremden

**IndependentArt** · 10.07.2013, 15:41

Ich hatte schon länger den Gedanken, das Zeit-mess-Event, dass bei mir ja eh mitläuft, noch für andere Zwecke zu benutzen, wenn ich eben für irgendwas einen PP brauche, der was anzeigen soll. Natürlich darf ich das Wait dabei nicht verändern.

Aber mal rein theoretisch: Wenn ich verschiedene Befehle da reinhaue die keine Zeit brauchen, zB das ein Balken im Kampf blinkt o.ä., geht das irgendwann zu Lasten der Genauigkeit der Messung? Oder ist dem Maker egal, wieviel da noch durchläuft?

**MagicMaker** · 10.07.2013, 16:13

Es vergeht kein wahrnehmbarer Augenblick, solange du keine waitlosen Schleifen mit Sackgasse bzw zuvielen
Varianten hintereinander abarbeiten lässt, du Befehle benutzt, die das Event eh unterbrechen und auf den Spieler
erstmal warten, Zeit von sich aus vergehen lassen (wie ein Wait) oder die Hardware mit zuvielen Anweisungen
einfach nur überlastet ist, sollte eigentlich nie wirklich vorkommen.

Zu einer nicht-verschmerzbaren Abweichung sollte es nicht kommen, solange zwischen den Messungen auch
immer der richtige Zeitabstand eingestellt wird.

**Bex** · 10.07.2013, 18:49

Warum solltest du einen blinkenden Balken mit dem Zeitmesssystem verbinden?

Du solltest zwar wie du schon erkannt hasst nicht den Code deines Zeitevents mit Waits zum stottern bringen, du kannst aber folgendes versuchen:
1.Eine Variable jedesmal wenn der Code durchläuft +1 rechnen und dahinter ein Conditional Branch ob die Variable z.B 600 ist.
So kannst du dir einen Wait bauen ohne den Code anzuhalten.

2.Beim Ace kann ich in dem Common Event einen Set Move Route machen und irgend ein Event auf der Map Waiten lassen, dannach in der Moveroute einen Schalter umlegen.
An irgend einer Stelle des Codes machst du einen Branch ob der Schalter an ist, wenn ja passiert das was du wolltest. (Vieleicht geht das bei dem Maker den du benutzt auch)

Ich hab beide Ansätze nur grob angerissen, hoffe es hilft ansonsten weiter nachfragen.

**IndependentArt** · 10.07.2013, 19:15

Zitat

Warum solltest du einen blinkenden Balken mit dem Zeitmesssystem verbinden?

Wie gesagt, um PPs zu sparen. Es gibt halt verschiedene Dinge, die ich gern machen würde, die alle einen PP benötigen und zwar einen einzelnen, weil sie ja nicht dauernd laufen sollen. Wenn man aber nun alles in einen packen könnte, der eh schon läuft, wäre das Performance-technisch super. Auch bei der Zustandsanzeige im Kampf hab ich einen PP verbraten, der aber aus ist, wenn niemand von einem Zustand betroffen ist.
Das hätte ich dann genauso gemacht, mit der Variable, wie dus beschrieben hast.

Beim Bsp. 2 bin ich nicht sicher, ob das für mich eine Rolle spielt oder ob ichs richtig verstanden hab. Ich benutze den 2k3, auch hier kann man switches(leider keine variablen) in move event einbauen.

Zitat

waitlosen Schleifen mit Sackgasse

Was genau versteht man als solche?

**MagicMaker** · 10.07.2013, 21:59

Zitat

Was genau versteht man als solche?

Laggende Endlosschleife, die nix bringt:

Code:

<> Irgendwas
<> Schleife
 <> Kram der ohne Entkommen wiederholt wird
 <>
: ENDE
<> Wird nie passieren
<>

Endlosschleife, die zumindest flüssig im Hintergrund funktioniert:

Code:

<> Irgendwas
<> Schleife
 <> Kram der dauerhaft wiederholt wird
 <> Warten: 0.0s
 <>
: ENDE
<> Wird nie passieren
<>

Schleife mit schlecht durchdachtem Ausbruch, der nie passiert:

Code:

<> Irgendwas
<> Schleife
 <> Kram der ohne Entkommen wiederholt wird
 <> Bedingung: Irgendwas, das gar nicht möglich ist
  <> Schleife brechen
  <>
 : ENDE
 <> Warten: 0.0s
 <>
: ENDE
<> Wird nie passieren
<>

Schleife mit ausgetüfteltem Ende:

Code:

<> Irgendwas
<> Schleife
 <> Kram der wiederholt wird
 <> Bedingung: Irgendwas, das irgendwann erfüllt sein wird
  <> Schleife brechen
  <>
 : ENDE
 <> Warten: 0.0s
 <>
: ENDE
<> Wird zu gegebenem Zeitpunkt passieren
<>

**Corti** · 11.07.2013, 08:27

Es spricht nichts dagegen diverse parallele Funktionen in ein PP zu klatschen.

Zeitmessung...Zeitmessschleifen werden gerne so gemacht

label1
Wait1.0
SekundenTotal+1~
wenn(!Abbrechen) { jumpToLabel1 }

Das ist so genau wie es geht und doch ungenau, ein Schätzeisen, aber ist das ein Problem? Ich denke nicht. Je mehr Code man da rein packt

label1
Wait1.0
SekundenTotal+1~
CallCE (HpAnzeige)
CallCE (Blinkezeugs)
wenn(!Abbrechen) { jumpToLabel1 }

Desto ungenauer wird die Zeitmessung.

Oh~ und LabelJumps > Loops

**IndependentArt** · 11.07.2013, 09:42

Liegt es an mir oder sind deine Aussagen widersprüchlich?

Zitat

Es spricht nichts dagegen diverse parallele Funktionen in ein PP zu klatschen.

und

Zitat

Je mehr Code man da rein packt desto ungenauer wird die Zeitmessung.

Das ganze klingt jetz so wie "Die Zeitmessung ist ja so oder so nicht genau, also macht es auch nix, wenn sie noch bisschen ungenauer wird."
Ist es das, was du sagen wolltest?

**Bex** · 11.07.2013, 10:13

Also beim Ace ist die Länge des Codes erstmal zweitrangig solange man die Befehle so einstellt das nicht gewaited wird und auch so keine Waits vorkommen, bis auf
das 1Frame Wait bzw 0.0Frame Wait beim alten Maker am Ende der Schleife.

Wenn ich also z.B 20 Paralelle Events habe die alle nur kleinkram abfragen, so kann das schon zu Problemen führen wenn man wenig Performance über hat.
Es war bisher aber kein Problem ein Paralelles Event laufen zu haben, das bis zu paarhundert Conditonal Branches pro Frame abfragt.

Probleme können auch auftreten wenn man zuviele Sachen jeden Frame erneuert.
z.B mein Kampfsystem.
Damals hab ich die Koordinaten für die Events jeden Frame neubestimmt, zusätzlich wurde dann noch eine Trefferabfrage durchgeführt und weil mein Geschoss ein Event war,
so wurde die Trefferabfrage jeden Frame durchgeführt auf der 10 Felder langen Strecke bis zum Ziel. Da verzehnfacht bis sogar noch wesentlich mehr vermehrt sich der Code.

Heutzutage läuft nur noch die eine Actionstastenabfrage in der Schleife und alles andere wird einmalig ausgeführt wenn man es brauch.
Das geht besonders gut duch Call Common Events, deine common Events dürfen also normalerweise nie laufen und keine Bedingung haben.
So das sie immer ein aufrufendes Event brauchen , das ist sparsamm.
Manchmal ist es aber ok sachen in ein weitteres Paralelles Event einzubauen.
z.B eine Miene, das Paralelle Mienen Common Event wird erst aktiv wenn die Miene gelegt wurde und schaltet sich beim Mapwechsel aus sollte auf der nächsten Map keine Miene liegen.
So hab ich zwar Zeitweise ein zweites Paralelles Event am laufen, aber es ist ok.
Manchmal geht benutzerfreundlichkeit halt über das Ziel alles in einen Codestrang zu packen.

Edit: Beim Ace ist häufige Lag ursache: Viele haben einen Set Moveroute Befehl in einer Schleife der den Set Moveroute Befehl des Players jeden Frame neu aufruft obwohls nur einmalig müsste. Dadurch entsteht spürbares Lag. Hatte neulich jemand mit seiner Lauffunktion.

**Corti** · 11.07.2013, 10:25

Zitat von IndependentArt

[1]Liegt es an mir oder sind deine Aussagen widersprüchlich?[...]
[2]"Die Zeitmessung ist ja so oder so nicht genau, also macht es auch nix, wenn sie noch bisschen ungenauer wird."

zu [1]: Nein. Generell ist dein Ansatz durchaus clever, zumindest cleverer wie der anderer Helden, die lieber alles in einzelne CEs packen weil es einfacher ist und nachher meckern "Buh, mein Spiel hat nur 55 PPs zeitgleich und ruckelt >.<"
zu [2]: Ich bezwecke nicht dir zu sagen welche Kompromisse du in welcher Form eingehen solltest. Ich möchte dir die Tatsachen aufzeigen um dir zu erlauben einen Antwort zu finden, die deinen Prioritäten entspricht.

Kurzfassung:

PPs zusammen fassen ist generell eine gute, für die Performance förderliche Sache
Zeitmessung per PP ist technisch bedingt immer ungenau
Einen Zeitmessungs-PP mit anderen PPs zu kombinieren macht die Messung noch ungenauer.

Jetzt liegt es an dir. Niemand hier kennt dein Spiel und dann wissen welche PPs du wo hast und welche Variante die optimalste ist. Je nach PPs kann es locker flockig problemlos sein die Zeitmessung UND das andere PP zeitgleich zu haben. Die Chance dazu ist recht hoch. Vor Jahren hatte man noch viel schwächere PCs und es wurde noch schlampiger gescriptet, einfach weil man sich noch weniger Gedanken machte und meist gings auch gut.
Wenn du jetzt X verschiedene grafische Anzeigen, Koordinatenabfragen etc hast, dann könntest du überlegen die in den selben PP zu packen.

**Kelven** · 11.07.2013, 10:40

@Corti
Warum eigentlich eine Schleife in einer Schleife, also ein Sprung zum Label in einem ich sage mal "Thread", der sowieso immer wieder von vorne anfängt? Vielleicht hab ich auch nur missverstanden worum es eigentlich geht.

**Corti** · 11.07.2013, 10:56

Hrm~ gute Frage

Ist in diesem Fall wohl eher nicht nötig. Ich hab in dem Beispiel alles intuitiv und aus Gewohnheit mit Labels gemacht.Was speziell die Zeitmessung angeht, das kann man sicherlich auch in der Hauptschleife des CEs machen.

**Morden** · 11.07.2013, 11:06

Wobei die Zeitmessung per PP immer ungenau sein wird, da PP's meines Wissens nach z.B. während eines Map-Übergangs nicht weiterlaufen. Auch überhaupt ein Wait mit in das PP zu setzen macht die ganze Sache schon ungenauer, da bei einem Wait von 1.0s schon ein 1.0s wait + ein 0.0 wait "ausgeführt" werden.

PeAcE
MorDen

**IndependentArt** · 11.07.2013, 11:20

Okay, ich werd es einfach mal ausprobieren. Auch vielleicht die Zeit mit und ohne zusätzliche Prozesse messen.

Zur Zeitmessung speziell gab es übrigens schonmal nen anderen Thread von mir, also die Diskussion nicht unbedingt darauf jetzt ausweiten. ^^

**DNKpp** · 11.07.2013, 11:21

Warum nutzt ihr eigentlich nicht einfach den timer, wenn ihr genaue Zeitangaben haben wollt? Der müsste doch genauer sein.

**Corti** · 11.07.2013, 11:30

Und läuft im Kampf weiter wenn man will~ ;-)

**IndependentArt** · 11.07.2013, 11:31

Darüber hab ich noch nicht nachgedacht.

Außerdem würde das ja den ganzen Thread zunichte machen, weil ich dann keinen PP mehr brauche ^^ Wobei, doch, um Minuten und Stunden abzurechnen möglicherweise.

**WeTa** · 11.07.2013, 11:54

Zitat von Corti

Oh~ und LabelJumps > Loops

Falls Loops im Maker nicht aus irgendwelchen Gründen unperformant sind ist das ganz großer Schwachsinn.
Sprunganweisungen sollte man so selten wie möglich verwenden, besonders, wenn es korrekte Alternativen gibt. Sie werden nicht ohne Grund als schädlich angesehen.
Was wollen wir in diesem Fall machen? Eine Schleife. Also verwenden wir auch eine Schleife, alles andere wäre pants-on-head-retarded. Der Labeljump gibt uns nichtmal einen Performancevorteil, weil die Schleife nicht geschachtelt ist, es gibt keinen Grund ihn statt der Schleife zu verwenden.

**DNKpp** · 11.07.2013, 12:03

Gab es nicht einen Bug mit loops und break loop?

**MagicMaker** · 11.07.2013, 12:13

Zitat

Gab es nicht einen Bug mit loops und break loop?

Schon, aber wenn man die Bedingung und Ausbruchanweisung immer an das Ende einer Schleife setzt,
kann dieser nicht auftreten und es ist sowieso die praktischste Methode.

**Bex** · 11.07.2013, 12:19

Ich dachte der Bug heist USER der vergisst in einem Endlos Loop ein Wait einzubauen damit das Spiel nicht abstürzt

.

Du könntest doch anfangen eine Funktion nach der anderen hier per Pictures vorzustellen, dann könnte man erstmal schauen ob der Kram allgemein schonmal vernünftig aufgebaut ist. Anschliessend oder währenddessen schaut man wie man es verschachteln kann.
Wäre auf jedenfall interessant zu sehen wie du deine Funktionen bisher umgesetzt hast.

Thema: Ein Zeit-mess-Event zweckentfremden

Themen-Optionen

Anzeige

Ein Zeit-mess-Event zweckentfremden

Berechtigungen