Analytisches Anspielen

[Brei]

Nochmal danke für den Stream und die technischen Ratschläge, genau wie für diesen Tipp.

...

Immer gern

Das OpenGL-Plugin erfordert, so weit ich gesehen hab, DynRPG-Version 3, während meine exe auf Version 2 läuft. Jetzt hab ich versucht, die auf Version 3 zu updaten, aber dann startet sie einfach gar nicht mehr, ohne Fehlermeldung oder sonst was. Hab dann etwas rumprobiert und kann sagen, dass das am Better AEP liegt, sobald ich eine ansonsten "frische" Better AEP-RPG_RT.exe auf Version 3 update, startet sie einfach gar nicht mehr. Sprich, Better AEP und das OpenGL-Plugin schließen sich aus, was sehr ärgerlich/schade ist. Weißt du vielleicht eine gute Alternative zu Better AEP (Title skippen, Auto Saves und Loads ermöglichen), mit der ich das ersetzen kann?

...

Ich hab es zwar auf die schnelle auch nicht hinbekommen Better AEP und Dynrpg 0.3 in deinem Projekt zum Laufen zu bekommen, seltsamerweise ging es allerdings problemlos in meinem. (Ich habe einfach den Patch als .ips in den "DynPatches" Ordner gezogen und es hat erfolgreich den Title Screen übersprungen. Mehr hab ich nicht getestet. Aber grundsätzlich scheint Better AEP + DynRpg 0.3 + OpenGl zu funktionieren. Ist mir ein Rätsel, warum es in deinem Projekt nicht so klappt. (Ich bekomme dann irgendeine Assertion Failure)

Edit: Ich bekomme dein Spiel sogar so weit, dass ich den Title Screen überspringe. Aber, egal ob ich das tue oder nicht: Mit Dynrpg 0.32 fliegt mir das Spiel hinter dem Title Screen um die Ohren.

Abgesehen davon: Auto Saves und Auto Loads habe ich selber im Spiel, das ist gar kein Problem. Zum Titel skippen hab ich spontan nichts gefunden.

Die Gegner-Typen sind tatsächlich konsequent alles Skelette oder Knochenhaufen, und das hat auch seinen Sinn und soll eigentlich nicht verändert werden. Allerdings versteh ich natürlich den Punkt, dass die Gegner sich teilweise zu ähnlich sehen (vor allem in den ersten Ebenen, wo die meisten humanoid sind). Über einige der Designs werd ich noch mal drübergehen müssen, um sie besser zu differenzieren, vor allem durch ihre Körperform; jeder Gegner-Typ sollte anhand seiner Silhouette allein identifizierbar sein.

...

Klingt gut, mach ruhig auch viel mit Farbe.

Darum wäre das zweitwichtigste nach der Performance für mich, die Gegner vom Grid zu kriegen, damit sie immer akkurat mit dem Spieler, dessen Projektilen, Nahkampfwaffen usw. interagieren.
Ich sprach gestern ja schon an, dass ich dafür ein Plugin bräuchte, das es mir ermöglicht, die Zeichenreihenfolge von Pictures on the fly zu ändern. Konkret möchte ich, dass jeder Gegner als ein Picture/Spritesheet repräsentiert wird, bei dem ich nur die aktuelle Position ändern muss, ohne es neu anzuzeigen. Aber da die Gegner natürlich wild durcheinander laufen können, müssen die Pictures abhängig von ihrer Y-Koordinate sortiert werden, statt von der Pic-ID.
Das sollte natürlich nicht für alle Pictures gelten, sondern entweder für ~50 Stück, die dann "Same Layer-Objekte" spielen können, oder über nen Comment-Befehl togglebar sein. Das wär wahnsinnig hilfreich.

...

Also, in dem Zusammenhang habe ich da gerade Folgendes rumliegen:
@picture_change_layer [pictureId], [layerId]
mit den relevanten layerIds (0: unter allen events; 1: unter allen same-layer-as-hero events, 2: über allen same-layer-as-hero events)

Innerhalb der Layer ist die Reihenfolge immer noch den Ids folgend.
Unklar, ob dir das weiterhelfen würde.

Was ich außerdem rumliegen habe:
Einen Befehl um die Grafik eines Events um genau x Pixel zu bewegen, ohne dabei das Tile zu wechseln.

Auf die Premiumlösung, allen Event selbst Pixelmovement zu geben, bin ich auch scharf, und vielleicht bauen wir sowas auch mal - aber das kann noch dauern.

Falls ich da an meine Grenzen (bzw. die des Makers) stoße und z.B. die Interaktion von Gegner-Projektilen mit Spieler, Gegnern, Objekten, Büschen, Wänden usw. standardmäßig im Maker einfach nicht flüssig hinbekomme, würd ich mich noch mal an dich wenden.

...

Mach das so

Und noch zwei andere Fragen. Im Maker ist es ja so, dass beim Wechseln einer Eventseite der Maker sich merkt, wo genau im Code er vor dem Wechseln gerade war, und wenn man auf die vorige Eventseite zurückspringt, beginnt er nicht von vorn, sondern von diesem Punkt aus. Bei Mapübergängen macht er das glaub ich auch manchmal; springt an die Stelle im Script eines Events auf der Map, an der das Script war, als die Map das letzte Mal verlassen wurde. Das ist sicherlich ein Feature, das man auf viele clevere Arten nutzen kann, mich stört es aber einfach ungemein und zwingt mich, an diversen Stellen mit Flag zu arbeiten, um auch ja immer zum Script-Anfang zurückzuspringen, wenn die Map gewechselt oder irgendein anderer Code ausgeführt wurde.
Gibt es ein Plugin, das dieses Verhalten des Makers abschaltet, sodass er immer zum Anfang eines Scripts springt, wenn eine Eventseite oder die Map gewechselt wird?

...

Nicht, dass ich wüsste.

Und steht die Performance eines Scripts in irgendeinem Zusammenhang mit dessen Länge? Sprich, wenn ein Script zum Beispiel ewig lang ist und in einem Go 20 Funktionen ausführt, ist das schlechter für die Performance, als jede einzelne Funktion auszulagern und die nacheinander zu callen?

...

Gute Frage. Ich bin der Sache nie gezielt nachgegangen. Ich hatte mal ein sehr langes Event das sich laggy angefühlt hat - und das sich weniger laggy angefühlt hat, nachdem ich einen Teil gecallt habe. Aber das ist viele Jahre her, und ich hab da nie Diagnose betrieben. Ich wollte mir immer mal ein Plugin für solche Zeitmessungen bauen, aber das habe ich noch nicht. Ich habe auch keine Ahnung wie schnell der Maker Eventcode einließt, oder wann, oder ob/wie er das cacht.

[Kingzi]

Ich hab es zwar auf die schnelle auch nicht hinbekommen Better AEP und Dynrpg 0.3 in deinem Projekt zum Laufen zu bekommen, seltsamerweise ging es allerdings problemlos in meinem. (Ich habe einfach den Patch als .ips in den "DynPatches" Ordner gezogen und es hat erfolgreich den Title Screen übersprungen. Mehr hab ich nicht getestet. Aber grundsätzlich scheint Better AEP + DynRpg 0.3 + OpenGl zu funktionieren. Ist mir ein Rätsel, warum es in deinem Projekt nicht so klappt. (Ich bekomme dann irgendeine Assertion Failure)

Edit: Ich bekomme dein Spiel sogar so weit, dass ich den Title Screen überspringe. Aber, egal ob ich das tue oder nicht: Mit Dynrpg 0.32 fliegt mir das Spiel hinter dem Title Screen um die Ohren.

...

Habs jetzt hinbekommen
Keine Ahnung, warum beim Ausprobieren gestern die exe einfach gar nicht gestartet ist, aber ich hab mir jetzt einfach eine komplett neue exe nach und nach mit allen Patches vollgepackt, die ich brauch, Voodoo-Magie betrieben und den Vollmond angeheult, und jetzt geht's.

Was ich außerdem rumliegen habe:
Einen Befehl um die Grafik eines Events um genau x Pixel zu bewegen, ohne dabei das Tile zu wechseln.

...

Verhalten Event-Grafiken sich denn dabei entsprechend ihrer Pixel-Position oder ihrer Tile-Position? Sprich, könnte ich theoretisch 10 Gegner-Events in irgendeine Ecke packen und die zugehörigen Grafiken effektiv als Pictures pixelweise irgendwo über den Screen schieben und die würden brav in der richtigen Reihenfolge entsprechend ihrer Y-Koordinate dargestellt? Bzw. wie weit kann ich den Sprite überhaupt unabhängig vom Event bewegen? Beliebig, oder moved das Event nach 16 Pixeln nach?
In jedem Fall wäre mir das glaub ich eine große Hilfe, falls du's mit mir teilen könntest.

Gute Frage. Ich bin der Sache nie gezielt nachgegangen. Ich hatte mal ein sehr langes Event das sich laggy angefühlt hat - und das sich weniger laggy angefühlt hat, nachdem ich einen Teil gecallt habe. Aber das ist viele Jahre her, und ich hab da nie Diagnose betrieben. Ich wollte mir immer mal ein Plugin für solche Zeitmessungen bauen, aber das habe ich noch nicht. Ich habe auch keine Ahnung wie schnell der Maker Eventcode einließt, oder wann, oder ob/wie er das cacht.

...

Dieses wage Gefühl hatte ich nämlich auch, konnte aber nirgendwo was definitives dazu finden. Wär 'n interessanter Fakt für performantes Scripting.

[Brei]

@Sölf:
Ja doch, ich überleg mir das mal.

@Kingzi:
Ist ja schonmal ziemlich nice, dass das OpenGL plugin sich doch noch gebeugt hat!

Verhalten Event-Grafiken sich denn dabei entsprechend ihrer Pixel-Position oder ihrer Tile-Position? Sprich, könnte ich theoretisch 10 Gegner-Events in irgendeine Ecke packen und die zugehörigen Grafiken effektiv als Pictures pixelweise irgendwo über den Screen schieben und die würden brav in der richtigen Reihenfolge entsprechend ihrer Y-Koordinate dargestellt? Bzw. wie weit kann ich den Sprite überhaupt unabhängig vom Event bewegen? Beliebig, oder moved das Event nach 16 Pixeln nach?
In jedem Fall wäre mir das glaub ich eine große Hilfe, falls du's mit mir teilen könntest.

...

Die Events verhalten sich entsprechend ihrer Grid Position und moven nicht nach. Sie werden aber nach pixelgenauer y-Position gezeichnet. Ich kann dir gerne zeitnah ein paar Getter/Setter etc. für den Offset schreiben und dann lass ich dir das zukommen. Hast du Interesse am Sourcecode?

Edit: Der Event Offset ist leider nur 8 Bit groß, das ist ein Problem für den Ansatz ...
Allerdings könnte ich die grid Position eben doch nachziehen und das Event bleibt dann halt im Phasing mode...

Dieses wage Gefühl hatte ich nämlich auch, konnte aber nirgendwo was definitives dazu finden. Wär 'n interessanter Fakt für performantes Scripting.

...

Wenn ich irgendwann mal bisschen Langeweile habe schreib ich das Zeitmess-Plugin und finde das mal raus...

[Kingzi]

Die Events verhalten sich entsprechend ihrer Grid Position und moven nicht nach. Sie werden aber nach pixelgenauer y-Position gezeichnet. Ich kann dir gerne zeitnah ein paar Getter/Setter etc. für den Offset schreiben und dann lass ich dir das zukommen. Hast du Interesse am Sourcecode?

Edit: Der Event Offset ist leider nur 8 Bit groß, das ist ein Problem für den Ansatz ...
Allerdings könnte ich die grid Position eben doch nachziehen und das Event bleibt dann halt im Phasing mode...

...

Ja, dann wäre es so am besten. Dann mach ich die Abfragen für Steine und Büsche auch noch pixelabhängig, dann brauch ich gar keine Event-IDs mehr zu storen und rumgeisternde Events stören nicht weiter.
Den Sourcecode würd ich mir liebend gern ansehen, vielleicht kann ich mir damit und mit meinen beschränkten C#-Kenntnissen beibringen, wie man so einen Patch schreibt.

[Brei]

Hier das Git Repository:
https://gitlab.com/Dorosaurus/utilsForKingzifrombrei/
Da ist jetzt dabei:
- Ein hartes Set Offset ohne Bounds Checking.
- Add Offset das ggf die Gridposition nachzieht.
- Get Offset.
- Set Offset auf eine Map-Pixel-Position.

Bei Fragen zum Plugin oder DynRPG im Allgemeinen, immer her.

[Kingzi]

Niiiice, vielen Dank

[Brei]

Kein Thema
Ich finde es immer ganz dankbar performancekritischen (aber ggf. stumpfen) Code dann im C++ zu machen. Ich hab z.B. nach und nach die Kollisionsabfragen dahin ausgelagert.

[Brei]

Morgen 19Uhr dann "Rollende, Radikale Revolte"
https://www.slimesalad.com/forum/viewgame.php?t=7794
von "Bird"

[Brei]

Stream startet pünktlich in wenigen Minuten

[Brei]

Nächsten Samstag ca. 19:00 gibt es dann die aufpolierte Version von "Fröhliche Schatzjagd" zu sehen!

[Brei]

Wieder Samstag (4.1.2020) 19:00 schau ich mir nochmal 'Fröhliche Schatzjagd' an, diesmal voraussichtlich mit weniger Blick auf die Technik, und mehr Blick auf das Gamedesign.
Es scheint sich viel am Spiel getan zu haben.