Druckbare Version
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?
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.
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.
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.Zitat:
Warum solltest du einen blinkenden Balken mit dem Zeitmesssystem verbinden?
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.
Was genau versteht man als solche?Zitat:
waitlosen Schleifen mit Sackgasse
Laggende Endlosschleife, die nix bringt:Zitat:
Was genau versteht man als solche?
Endlosschleife, die zumindest flüssig im Hintergrund funktioniert:Code:<> Irgendwas
<> Schleife
<> Kram der ohne Entkommen wiederholt wird
<>
: ENDE
<> Wird nie passieren
<>
Schleife mit schlecht durchdachtem Ausbruch, der nie passiert:Code:<> Irgendwas
<> Schleife
<> Kram der dauerhaft wiederholt wird
<> Warten: 0.0s
<>
: ENDE
<> Wird nie passieren
<>
Schleife mit ausgetüfteltem Ende: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
<>
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
<>
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
Liegt es an mir oder sind deine Aussagen widersprüchlich?
undZitat:
Es spricht nichts dagegen diverse parallele Funktionen in ein PP zu klatschen.
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."Zitat:
Je mehr Code man da rein packt desto ungenauer wird die Zeitmessung.
Ist es das, was du sagen wolltest?
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.
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 >.<"Zitat:
Zitat von IndependentArt
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.
@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.
Hrm~ gute Frage :D 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.
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
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. ^^
Warum nutzt ihr eigentlich nicht einfach den timer, wenn ihr genaue Zeitangaben haben wollt? Der müsste doch genauer sein.
Und läuft im Kampf weiter wenn man will~ ;-)
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.
Falls Loops im Maker nicht aus irgendwelchen Gründen unperformant sind ist das ganz großer Schwachsinn.Zitat:
Zitat von Corti
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.
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,Zitat:
Gab es nicht einen Bug mit loops und break loop?
kann dieser nicht auftreten und es ist sowieso die praktischste Methode.
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.
Es ist mir jetzt zu mühselig in den Untiefen des Quartiers nach einem Performancetest zu suchen, den ich mal vor Jahren gesehen habe, aber soweit ich mich erinnere wurde das mal gestestet und in Sachen Performance Jump>loop.Zitat:
Zitat von Tako
Dazu kommt die Sache mit dem Bug.
In Sprachen, die vollwertige, sicherere und fehlerfreie Alternativen zur Auswahl haben: 100% Zustimmung.Zitat:
Zitat von Tako
Makerschleifen sind scheisse. while(true) { if(X) break; } mit möglichen Fehlern wenn man das Abbruchkriterium nicht ans Fußende packt. Wenn ich mir überlege wie ich etwas umsetze dann denke ich in for,while,doWhile~ nicht in while(true)break, was sich mit Labels imo eleganter umsetzen lässt.Zitat:
Zitat von Tako
Der Break springt immer automatisch zum nächsten Schleifenende, das im Code ist,
ohne darauf zu achten, dass dieses eine Verschachtelungstiefe weiter oben sein muss,
wie aber schon gesagt lässt sich das problemlos verhindern:
Wer ganz komisch drauf ist, kann den Bug auch zu einem sehr skurrilen Vorteil nutzen:Code:<> Schleife
<> Salatgebimse
<> ...
<> Schleife
<> Quatsch mit Sauce
<> ...
<> Schleife
<> Schnupfen
<> ...
<> Bedingung: Zeckenbiss
<> Break
<>
: ENDE
<> Hier darf keine Schleife mehr kommen
<>
: Schleife-ENDE
<>
<> Bedingung: Eistee
<> Break
<>
: ENDE
<> Hier darf keine Schleife mehr kommen
<>
: Schleife-ENDE
<>
<> Bedingung: Käse
<> Break
<>
: ENDE
<> Hier darf keine Schleife mehr kommen
<>
: Schleife-ENDE
<>
Code:<> Break
<> Schleife
<> Wird nicht ausgeführt
<>
: Schleife-Ende
<>
Ich bin tatsächlich nicht besonders gut darin, ein Script logisch aufzubauen. Es läuft oft eher nach der Art Try and Error. Loops hab ich bisher nie großartig benutzt, verstand auch den Sinn nicht, wiederholt sich zB ein PP Event automatisch. Und Labels sind halt schön flexibel anzusteuern.
Ich hab jetz mal den Timer reingehaun in meinen Zeitmesser, scheint zu funktionieren. Hab aber trotzdem noch ein 0.0 wait drin, damit immer die Minuten und Stunden richtig abgerechnet werden.
Jetzt versuche ich mich gerade darin, die Zustandsanzeige damit zu verbinden. Das waren bisher 3 PPs, für jeden Chara einer(der Verschleiß an PPs schockiert mich grad selbst). Das ist bisher so geregelt, dass wenn irgendjemand von einem Zustand betroffen ist, alle 3 PPs laufen(entweder war ich da faul oder es hatte wirklich einen triftigen Grund).
Der Code der Events sieht so aus:
Auf diese Weise werden hübsch die Zustände der Charas nacheinander durchgeschalten. Da nicht jeder Chara notwendiger Weise von den gleichen Zuständen betroffen ist, sah ich da auch die 3 Events gerechtfertigt.Code:if: zustand 1 on:
variable zustandsanzeige chara 1: set 1
wait 1.0
if: zustand 2 on:
variable zustandsanzeige chara 1: set 2
wait 1.0
usw.
Sehe ich grad auch immernoch, da mir nicht so recht einfallen will, wie ich das in das Zeitevent hineinquetschen kann, ohne das sich die Waits verändern.
Das Zeitevent sieht grad so aus:
Ja, und das ist nun der Punkt, wo ich in dem Skript des Zeitevents etwas mit der gleichen Funktionalität der anderen PPs schreiben müsste.Code:Start timer
Label 1
(ich springe von ganz unten dann hierher zurück,
weil ich nicht sicher bin, ob der timer neu gestartet werden darf)
Abrechnugn von Minuten und Stunden
wait 0.0
variable für zustandsanzeige chara 1 +1
variable für zustandsanzeige chara 2 +1
variable für zustandsanzeige chara 3 +1
(ich dachte mir, dass ich in jedem fall schonmal 3 varis brauche)
-->zustandsanzeige
jump to label 1
Whoa.Zitat:
Zitat von Corti
Der 2k ist so scheiße? :hehe:
Entwickelt ihr nicht den ganzen Tag Patches und DynRPG Plugins mit mehr Codezeilen, als der eigentliche Maker hat? Könnt ihr das nicht fixen?
Ich meine WHOA :hehe::hehe::hehe:
Aber klar, dann hast du natürlich recht.
Der 2k kann nichtmal Schleifen oh Gott help
Zitat:
Code:
if: zustand 1 on:
variable zustandsanzeige chara 1: set 1
wait 1.0
if: zustand 2 on:
variable zustandsanzeige chara 1: set 2
wait 1.0
usw.
Warum brauchst du dort ein Wait?Das bringt den Code doch unnötig zum stottern? Ausserdem würde ich diesen Paralellen Code anders aufbauen, da beim zutreffen der Bedingung, der Code bei jedem durchlauf also mehrere
Dutzend mal in der Sekunde neu zugewiesen wird.Das spielt nur keine Rolle wenn ein Schalter für ein anderes Common Event aktiviert wird. Wobei man dann überlegen sollte ob man es nicht anders Eventen kann, weil bei diesem Aufbau und eine Set Moveroute Befehl würde das Spiel anfangen zu laggen, weil der Moveroute Befehl es absolut nicht mag jeden Frame
neu zugewiesen zu werden fürs selbe Ziel.
Beispiel anhand eines simplen Schnell laufen Systems:
Conditional Branch: A.Taste Gedrückt
Wenn Ja: Conditional Branch: Schalter[Rennen] Aus Wenn Ja: Set Move Route Player Speed 5 Turn Schalter[Rennen]An
Wenn Nein: Nichts
Else Case von der ATaste= Conditional Branch Schalter [Rennen]An Wenn Ja Set Move Route Player Speed 3 Turn Schalter[Rennen]Aus
Else:Nichts oder erst gar keinen Else einstellen.
Die zusätzliche Schalterabfrage verhindert, das Code der teilweise Rechenintensiver ist als eine Bedingung neuausgeführt wird obwohl es nicht nötig ist.
Im Beispiel rennt der Spiele sollange Schnell bis er die A Taste los lässt.Der code der ihn aber schnell laufen lässt , bzw langsam, wird nur einmalig zugewiesen
Ich bin kein Experte,also korigiert mich falls ich mal falsch liege, sind aber meine Erfahrungswerte bisher.
Edit: Ups bin etwas vom eigentlichen Code abgewichen^^
Damit der Zustand 1 Sekunde lang angezeigt wird. Ich vergaß zu erwähnen, dass sich das ganze auf Events auf der KS Map bezieht, die dann je nach Stand der Variable eben umschalten.Zitat:
Warum brauchst du dort ein Wait?
Ich verstehe ungefähr, was du meinst. Ich wüsste nur nicht so recht, wie ich das auf mein Problem anwenden könnte.
Wie kommst du darauf? Seite 3, rechte Spalte, 8ter Befehl von unten.Zitat:
Zitat von Tako
@Schleifen
In einer vernünftigen Hochsprache ist so eine Pragmatik wünschenswert. Aber doch bitte nicht in so einer Umgebung wie der 200x Serie des Makers. :)
Bitte was für ne Serie?
Versionen 2000 und 2003.
Na dann. Vielen Dank für deinen Beitrag ... Makenshi o_O
Oh entschuldige. Ich hätte dir auch etwas sinnvolles zu deinem Ursprungsproblem hinterlassen sollen. ^_^
Ich hole es mal nach:
Erstmal braucht jeder Befehl Zeit um abgearbeitet zu werden. Das heißt jeder Befehl den du zusätzlich in dein PP reinsetzt, wird die Zeitmessung beeinflussen.Zitat:
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?
Wenn du das verhindert möchtest, solltest du ein zweites PP erstellen wo du nicht zeitkritische Operationen ablaufen lässt.
Eine andere Alternative um das Problem ganz zu umgehen, ist es gar nicht erst mit PPs zu arbeiten wo es nicht sein muss. Die Aktualisierung einer Werte Anzeige (HP, MP, etc.) muss nicht zwangsläufig im Hintergrund ständig aktualisiert werden.
Oft weißt du genau wann sich zum Beispiel der HP Stand des Spielers verändert. Es macht hier Sinn nach jedem Schaden dem man dem Spieler zufügt ein CE aufzurufen. Dieses kann dann den Schaden von den HP abziehen und die HP Leiste aktualisieren.
Im Endeffekt solltest du dir aber nicht übermäßig Gedanken über zu viele PPs machen. Der Großteil der Rechner dürfte heutzutage mehr als Leistungsstark genug dafür sein. Da kommt es auf eine kleine Anzahl mehr auch nicht an.