Wenn Maker-Spiele laggen...

[TwoFace]

... was kann man allgemein gesehn tun, außer die berühmt-berüchtigten 0.0er Waits?

Ich weiß, dass man sauber scripten muss. Parallele Prozesse nicht überladen. Events, die man nicht unbedingt braucht und die nicht unbedingt die ganze Zeit laufen müssen via Switch wegschalten bzw. nur dann aktivieren, wenn man sie braucht.

Aber wenn dies alles schon geschehen ist: welche weiteren Methoden kann man allgemein anwenden, um die Performance seines Spiels (rm2k3) zu verbessern?

[MagicMaker]

→ Die Anzahl aufgespaltener Events, die immer NUR gleichzeitig laufen, verringern und zusammenfassen
→ Codestruktur überdenken und gegebenenfalls nach einem Geistesblitz neu zusammenbauen, es gibt
　 genug Möglichkeiten für ein und dasselbe Ergebnis


außer die berühmt-berüchtigten 0.0er Waits?
Die wirklich eine Menge bringen, weil sie der Software befehligen, bis zum nächsten Frame abzuwarten,
um nicht nochmal etwas wiederholen zu lassen, obwohl auf dem Bildschirm und deinen Augen kein einziger
Moment der Darstellung vergangen ist.

[Supermike]

Hast du denn ein Problem mit Laggs oder reine Verbeugung?
Es muss nicht unbedingt immer der Code des Spiels selbst sein. Audiocodecs können auch des Teufels Werk sein.

[TwoFace]

→ Die Anzahl aufgespaltener Events, die immer NUR gleichzeitig laufen, verringern und zusammenfassen
→ Codestruktur überdenken und gegebenenfalls nach einem Geistesblitz neu zusammenbauen, es gibt
　 genug Möglichkeiten für ein und dasselbe Ergebnis

Bei dem Verringern und Zusammenfassen bin ich noch dabei. Wobei ich mich schwer tu, rauszufinden, was genau Performance-Probleme verursacht.


Hast du denn ein Problem mit Laggs oder reine Verbeugung?
Es muss nicht unbedingt immer der Code des Spiels selbst sein. Audiocodecs können auch des Teufels Werk sein.

Ja, mein Projekt laggt derzeit ziemlich hart. Vor allem, wenn ich mit dem Helden in ein Event (Bombe) lauf und ne Battle-ani (Explosion) angezeigt wird, laggt es manchmal kurz und auch beim normalen Laufen ab und an, wenn viele sich bewegende Events auf der Map sind. Ich hab halt ends viele Parallele Prozesse. An der Zahl sind es momentan 7, die gleichzeitig laufen (unsichtbare) und das meiste steuern (Trefferabfragen & Co. halt), 5-8 Events auf der Map und ja, viele Battle-anis halt...

Und jo.. wie meinst du das mit den Audiocodecs? Bei den Sounds?


1. ) würde es die Performance echt verbessern, wenn ich Sachen, die ich zusammenfassen kann, zusammen in einen größeren PP steck ?

2. ) Laggt es denn, wenn es laggt, generell auf allen PC's oder braucht man dann, um eine gute Spielbarkeit zu gewährleisten, einfach nur einen besseren PC ?

[caesa_andy]

Kannst du nicht statt so vieler Paraleler Prozesse einfach mit Common-Events arbeiten? Ich kenne jetzt zwar dein KS nicht, aber würde es nicht auch funktionieren, dass du einfach in dem Augenblick, in dem der Spieler einen Schuss abgibt, das entsprechende Event EINMAL aufrufst, es durchlaufen lässt, und dann wieder beendest? 7 PP klingt schon ziemlich viel ...

[TwoFace]

Kannst du nicht statt so vieler Paraleler Prozesse einfach mit Common-Events arbeiten?

Könnt ich schon so hinbekommen, dass alles über die Database gesteuert wird... zumindest zu sagen wir 80%... aber macht das denn 'nen Unterschied ob ich ein Event einmal oder mehrmals über nen PP aufruf oder ihn einmal oder mehrmals über Common Event calle?

[caesa_andy]

Könnt ich schon so hinbekommen, dass alles über die Database gesteuert wird... zumindest zu sagen wir 80%... aber macht das denn 'nen Unterschied ob ich ein Event einmal oder mehrmals über nen PP aufruf oder ihn einmal oder mehrmals über Common Event calle?

Du sollst das Event nicht über ein Common-Event aufrufen ;)

Meine Frage war, ob Dinge, die im Augenblick über einen parallelprozess gesteuert werden, WIRKLICH permanennt ablaufen müssen, oder ob du es nicht so machen kannst, dass die ganzen Parrallen Events als inaktive Comon-Events da sind, bis sie gebraucht werden ;)

Ich meine, du schriebst was davon, dass du die Trefferabfrage über einen PP regelst ... aber nach meinem Dafürhalten wird die Trefferabfrage doch nur dann gebracht, wenn wirklich geschossen wird. Also schmeiß das Parallel-Event raus, mach ein Common-Event, dass die Positionen der Charaktere speichert und dann den eventuellen Treffer ermittelt, und ruf dieses Common Event EINMAL auf, sobald der Spieler den Schuss-Knopf drückt. Und ansonsten bleibt das Event inaktiv und tut gar nichts.

Ich kenne mich zugegebenermaßen mit Schuss-KS' nicht wirklich aus ... aber so würde ich das machen, statt alles in PPs zu packen.

[Davy Jones]

→ Die Anzahl aufgespaltener Events, die immer NUR gleichzeitig laufen, verringern und zusammenfassen
→ Codestruktur überdenken und gegebenenfalls nach einem Geistesblitz neu zusammenbauen, es gibt
　 genug Möglichkeiten für ein und dasselbe Ergebnis
Einmal das und dann noch der Verzicht auf Molebox und größere rotierende Pictures. Nicht alle PCs sind davon betroffen, aber es hilft sich dagegen im voraus abzusichern.

[TwoFace]

Ich meine, du schriebst was davon, dass du die Trefferabfrage über einen PP regelst ... aber nach meinem Dafürhalten wird die Trefferabfrage doch nur dann gebracht, wenn wirklich geschossen wird. Also schmeiß das Parallel-Event raus, mach ein Common-Event, dass die Positionen der Charaktere speichert und dann den eventuellen Treffer ermittelt, und ruf dieses Common Event EINMAL auf, sobald der Spieler den Schuss-Knopf drückt. Und ansonsten bleibt das Event inaktiv und tut gar nichts.

Du bringst mich auf eine Idee. Es würde ja auf's gleiche rauskommen, wenn ich den Trefferabfrage-PP mit einem Switch versehe, sodass der Event nur dann in Kraft tritt, wenn geschossen wird/ein Gegner getroffen wird und am Ende der Abfrage wird er wieder auf OFF gestellt. Ich versuch das nachher gleich mal und schau, ob sich rein performancetechnisch was verbessert.


Einmal das und dann noch der Verzicht auf Molebox und größere rotierende Pictures. Nicht alle PCs sind davon betroffen, aber es hilft sich dagegen im voraus abzusichern.

Danke, aber ich verwende derzeit weder das eine noch das andere :)