Uh willst du dabei ins Detail gehen, um was für Projekte es sich handelt?
Nein, habe ich aus privaten Gründen nicht verlinkt 
(Ich sollte vielleicht klarstellen, dass der Content nichts problematisches ist, nur definitiv ein bisschen zu spicy für hier.)
I.Z. Ich tu' mich mit den Kreativaspekten etwas schwer, aber ich bin in mancher Hinsicht sowieso eher ein "Leser". (Mir fehlt glaube ich auch einfach die Übung.)
Ab und an helfe ich allerdings (indirekt) bei ein/zwei Spieleprojekten aus, die ich mag, und bastle (seeeehr langsam) an einem Mini-Fangame wenn ich die Muße dazu habe.
Mit Steam Link geht's sogar auf dem Handy 
Aber nicht unterwegs, wobei die Steuerung und Latenz bei mir auch echt zu wünschen übrig lässt (aber mein Handy ist nicht schnell).
Es gibt recht gute Windows- bzw. x86-Tablets, aber ich glaube die sind meistens auch viel schwerer und mit Windows nicht so schnell.
Auf meinem habe ich Linux drauf, was Energieprobleme und Leistung korrigiert, aber da geht ja MZ nicht.
Jedenfalls komme ich mal kurz aus meiner zu-viele-Projekte-bedingten Versenkung, weil ich ein kleines Plugin als Auftragsarbeit gemacht habe: R-Stick Mouse MZ
Wie der Titel besagt, ist das ein Mausemulator für Gamepads. Einfach einschalten und euer Spiel geht per Gamepad als Point-and-Click. (Drag&drop geht auch.)
So, jetzt auch für MV. Das war dann doch etwas mehr Arbeit.
Ich habe eine Hover-Funktion für MV eingebaut, damit man allgemein nicht dauernd überall in den Menüs doppelklicken muss. Funktioniert wie in MZ.
Per Touchscreen sollten aber nach-wie-vor zwei Taps nötig sein.
[…]
Zum Tagesausklang ein bisschen Fernweh.
Ich liebe diese Art von Szene. Ist das eine Ebene an Parallax oder mehrere?
(Das wäre auch mal wieder eine gute Pluginidee, aber das gibt es schon.)
Jedenfalls komme ich mal kurz aus meiner zu-viele-Projekte-bedingten Versenkung, weil ich ein kleines Plugin als Auftragsarbeit gemacht habe: R-Stick Mouse MZ
Wie der Titel besagt, ist das ein Mausemulator für Gamepads. Einfach einschalten und euer Spiel geht per Gamepad als Point-and-Click. (Drag&drop geht auch.)
Ich bin dafür schon bezahlt worden, deshalb ist das komplett kostenlos und MIT-lizensiert, obwohl's technich meinen kommerziellen Plugins entspricht.
Ich habe unvernünftigerweise ein ziemlich komplexes Rust-Projekt gestartet (so 
-artig) und mache deshalb eventuell für eine Weile (ein paar Wochen) etwas langsamer bei RPG Maker. Nicht, dass ich aktuell besonders schnell dabei wäre, aber naja. Falls was daraus wird und ich es veröffentliche, erwähne ich es wahrscheinlich mal hier im Forum.
(Das sollte sich nicht auf den Support bei meinen Plugins auswirken, außer dass ich vielleicht mal zu tief in der Materie bin und dann eine Nachricht nicht so schnell sehe.)
Ah, jetzt habe ich es verstanden, danke für die Erhellung! Für eine sehr große und sehr lange Explosion im "Auserwählten" hätten wir das zum
Beispiel gut gebrauchen können, aber da es so etwas nicht gab, haben wir uns mit den Möglichkeiten des Makers durchgemogelt. Aktuell benötige so etwas also momentan nicht, kann mir aber vorstellen, dass das für Leute interessant sein könnte, die gern aufwändige Kampfsequenzen oder Effektanimationen verwenden möchten.
Man kann sonst glaube ich auch recht einfach ein "Play Movie"-Video transparent über den Bildschirm legen.
Ich habe das nicht getestet, aber wenn man Graphics._updateVisibility bzw. im MZ Video._updateVisibility so anpasst, dass der Haupt-<canvas> nicht versteckt wird, dann müsste man den hinter transparenten Videos noch sehen. Wenn man das nicht als veröffentlichtes Plugin ausarbeitet, dann sind das geschätzt 5-6 Zeilen JavaScript, um es an einen Schalter zu binden.
Das müsste auch in einem parallelen Ereignis funktionieren, wenn dadurch der Spielablauf nicht blockiert werden soll. Das Spiel wird durch Videos soweit ich beurteilen kann nicht angehalten oder sonstwie pausiert, das blockiert nur den Interpreter der das Video angezeigt hat. Müsste auch als Dauerschleife klappen.
Ich denke nicht, dass ich eine Demo schneller hinbekommen würde als das Plugin selbst.
Aber ja, es macht wahrscheinlich keinen Sinn. Bewegliche Objekte sind mit animierten Doodads schon gut abgedeckt, für Kämpfer und Charaktere habe ich schon meine eigenen Plugins, und quasi alles andere ist endweder eh animiert oder lässt sich wegen Caching auf diese Weise nicht animieren. Im Endeffekt wäre die einzige Verbesserung, dass man eine Animationsfunktion wie von Tilesetseite A1 auf allen anderen Tilesetseiten unabhängig nutzen könnte und dabei keine Vorgabe der Frameanzahl hätte.
Wenn ich es mit Einzel-PNGs implementieren würde, dann wäre das in Sachen Performance quasi nicht messbar, denke ich, aber selbst ein optimiertes Plugin ist nutzlos wenn man es eh nicht braucht
Da ich technisch nur über sporadisch es Halbwissen verfüge, finde ich es immer wieder spannend wenn Du einem hier neue/weitere Erkenntnisse über die Funktionsweise des Malers erläutern kannst.
Besten Dank dafür!
Dazu muss ich noch etwas nachtragen: Das Tileset wird in den meisten Frames tatsächlich der Effizienz halber nicht neu gezeichnet, mit animierten Bitmaps wäre das also (standardmäßig) im Takt der Wasseranimation, 2 mal pro Sekunde. Man kann aber einfach .refresh() aufrufen und dann wird es doch neu gezeichnet.
ZitatEs gibt ja auch (zumindest für MV und MZ wohl auch) Plugins für frei platzierbare Objekte (habe den Namen gerade vergessen), welche ähnlich wie Decals das Mapping erweitern.
Wenn man die dahinter stehende Technik noch eleganter lösen könnte, hätte man wohl durchaus einen Mehrwert geschaffen.
Diese Grid-Free Doodads von Yanfly bzw. VisuStella?
Ich müsste da mehr dazu wissen, was da das Problem ist.
Die Yanfly-Plugins sind technisch okay, soweit ich beurteilen kann. Das einzige Manko ist, dass die so programmiert sind, dass es leichter zu Konflikten mit anderen Plugins kommt. Zur Entwicklungs-UX kann ich allerdings nichts sagen, da ich das Plugin selbst nicht habe bzw. nutze. Ist nur in einem der Spiele dabei, die ich hier auf der Festplatte habe. Von der Laufzeiteffizient her ist YEP_GridFreeDoodads quasi genau so wie Ereignissprites, habe da nichts dran auszusetzen.
Die VisuStella-Plugins haben alle diese nervige Quellcodeverschlüsselung, die wohl auch zur Laufzeit ordentlich Leistung kostet.
"Nervig" daher, dass ich dadurch auch keine Kompatibilität mit diesen Plugins garantieren kann. In der Praxis gibt's meistens trotzdem keine Probleme, aber falls doch kann ich's halt nicht (so einfach) reparieren.
Alles anzeigenDass Gifs weniger effizient laufen sollen als Videos - gerade wenn man nur von wenigen Frames ausgeht, überrascht nicht ziemlich.
Könnte man alternativ eine Bildfolge abrufen, wie sie in einigen Programmen für Animationen verwendet wird? Also beispielsweise durch reine Benennung und Ablage in einem eigens dafür vorgesehenen Ordner?
Beispiel:
Baum_animiert00
Baum_animiert01
Baum_animiert03
usw.
Ich kann mir aber gut vorstellen, dass sowas im Hinblick auf den Video-Speicher nur stark dosiert ratsam wäre, da sonst der Zwischenspeicher schnell überflutet wird, wenn man etliche "Slots" in den Tilemaps durch solche Grafiken ersetzt.
Das ginge an sich. Eine Bitmap ist ja ein Maker-eigenes Bündel aus Eigenschaften, das kann ich (vermutlich) recht einfach auch anders implementieren und dann wechseln. Sehr effizient ist das auch, macht sich zur Laufzeit quasi nicht bemerkbar, sodass da die einzige Grenze wirklich der Videospeicher ist.
Die meisten Maker-Texturen, bei denen das Sinn machen würde, sind nicht wirklich hochauflösend.
Tilesetseiten im MV kosten wahrscheinlich zwischen 1,2 und 1,6 MB VRAM, sodass da ca. 500 zusätzliche Texturen von der Größe wohl realistisch sind, bevor man was an der Bildrate merkt (zumindest für installierte Spiele, im Browser ist das eventuell stärker begrenzt). Das größte Problem wären die Ladezeiten, im MZ (viel) mehr als im MV, da der MZ Ressourcen weniger effizient verwaltet. Videodateien werden soweit ich weiß oft auf der Grafikkarte dekodiert oder sonstwie beschleunigt, bei Bilddateien ist das leider sehr selten möglich.
Bei Bildern, die auf Fenster gezeichnet werden (inkl. denen in img/faces/ und vielen Icons) funktioniert das alles aber leider erstmal nicht. Da müsste man erst das Bild durch einen Sprite ersetzen.
Alles anzeigenHmm - ich tu mir gerade schwer zu verstehen was damit genau gemeint ist
Also, ok, Video einbinden - aber was ist mit "in Texturen laden" gemeint?
Könnte mir vorstellen z.B. bei einem Fluss reale Grafiken einzubauen - sowas in etwa?
Wäre interessant zu wissen wie das aussehen könnte. Nicht gut für die Performance ist gerade beim MV Maker natürlich leider generell eher suboptimal
Ja, zum Beispiel. Man könnte dann auch Videodateien mit Show Picture nutzen. Wobei ich nicht weiß, wie das mit dem Abspielen aussehen würde, wäre wahrscheinlich eine unkontrollierte Dauerschleife. (Ich verwende den Maker immer auf Englisch, daher habe ich die deutschen Namen nicht immer parat.)
Wenn die Bildrate und Auflösung Makertypisch gering sind, dann sollte es flüssig(er) laufen. Ich glaube nicht, dass die Daten durch den Hauptspeicher geladen werden müssen.
Wenn ich das richtig verstanden habe, dann würde ich wohl eher auf GIFs zum Erweitern der Makergrenzen bei den Tilesets setzen, anstelle auf Videodaten. 3-6 Frames könnten hier bereits vieles möglich machen, ohne hoffentlich zu stark auf die Performance drücken.
Vielleicht wäre das ja eher eine Überlegung wert, um beispielsweise sonst nicht animierte Boden-Texturen oder Detailobjekte wie Bäume leicht zu animieren.
Das funktioniert leider nicht (annähernd so einfach). Es gibt zwar ein PixiJS-Plugin für GIFs, aber das wirft keine Texturen aus, weshalb sich das hierfür nicht gut nutzen lässt.
GIFs sind leider auch ineffizient verglichen mit quasi allen anderen Formaten und würden die Performance wahrscheinlich stärker drücken als Videos.
Es ist ja mit PixiJS ziemlich einfach, Videos in Texturen zu laden. Ich überlege gerade, ob ich mich mal dransetzen soll, diese Funktion auch im RPG Maker leicht nutzbar zu machen. Mir fehlt allerdings etwas die Problemstellung dazu, bzw. weiß ich nicht, ob das überhaupt jemand haben wollen würde. Ist auch nicht gut für die Performance, je nach Video und Anzahl.
Macht das Sinn? Würdet ihr sowas nutzen? Wenn ja, wofür?
Ich konnte während der letzten Woche kaum was tun, habe dafür aber gestern und heute ein neues Plugin und ein Update veröffentlicht.
Dynamic Actors erlaubt die gleichzeitige Kontrolle von Dynamic Characters und/oder Dynamic Pictures, eignet sich also vor allem, um Grafiken für die Spielcharaktere einzurichten. Ich habe auch ein paar Extrafunktionen für NPCs mit eingebaut und da dieses Plugin quasi nur die anderen beiden automatisiert ist es gratis.
Bei Live Menu and Pause hatte ich mir wohl anfangs etwas zu viel vorgenommen und dann ein halbes Dutzend subtile Fehler nicht bemerkt. Die sind jetzt behoben, sodass z.B. Spieler nicht mehr aus Versehen mit offenem Menü Ereignisse aktivieren können. (In-Spieler-Hineinrammen und automatische/parallele Events funktionieren trotzdem.)
Die eigentliche Motivation für das Update war aber, die Option hinzuzufügen, das Hauptmenü bei laufenden Ereignissen automatisch zu schließen, damit es in Spielszenen nicht im Weg ist. Parallel laufende Ereignisse und solche, die "sofort" abgeschlossen sind, schließen das Menü allerdings nicht, damit es nicht zu unnötigen Unterbrechungen kommt.
Tamschi meeegaaa niceee!!!
Hoffe, der Papierkramstapel ist gleich mitabgearbeitet worden?
Leider ist der etwas größer, aber ich mache Fortschritte. Habe mir noch ein paar Aufbewahrungsboxen für lose Zettel ausgedruckt, damit ich Quittungen sortieren kann.
(Ich kann einige davon noch einreichen, was mir hoffentlich ein bisschen mehr finanziellen Freiraum beschert.)
Tamschi
Sorry, jetzt warst Du mir bei den Wortmelungen untergegangen. Ich finde solche "Visual Equipment"-Plugins immer super nützlich - gerade wenn man eine Vielzahl an Ausrüstungskombinationen in seinem Spiel hat! Aber auch wenn man sich anfangs im Spiel einen Charakter selbst zusammen basteln kann, hat solch ein Plugin einen großen Mehrwert!
Wie schaut es denn mit der Performance aus? Kann man sagen, dass diese bei einem ~5-10 Jahre alten PC weniger ins Gewicht fällt?
Ist (auf diesem schnellen PC) nicht wirklich messbar, weil der Performance-Impact selbst im Debug-Modus zu gering ist.
Alles was ich sagen kann ist, dass es für alle Sprite_Character zusammen in meinem Test weit weniger als 1ms kostet. (Über 5 Sekunden/~300 Frames taucht das 3 mal auf bei 1ms Abtastrate, ich tippe also auf ca. 0.01ms pro frame für 26 sprites oder ~0,4µs pro Sprite (mit großer Ungenauigkeit).)
In einem echten Spiel mit höherer Anzahl von Ausrüstungsitems ist das sicher etwas mehr, aber solange die Bilder gleich sind kann man auch Regeln mit mehreren Ausrüstungsgegenständen definieren.
Ich habe das jetzt nicht extra dafür verzweigt, wenn es gar keine Regeln für einen Sprite gibt, weil es eh schon sehr schnell ist. Ich kann jetzt nicht aus dem Stehgreif sagen, ob es dadurch schneller oder langsamer würde. Vielleicht ein paar Prozent schneller, aber man würde es höchstwahrscheinlich selbst auf alten PCs nicht merken.
Das Zusammensetzen der Bilder passiert rein auf der GPU ohne Rücklesen, wird aber auch im RPG-Maker-eigenen Cache abgelegt und daher in der Regel nicht wiederholt. Der Ladevorgang ist weiterhin größtenteils asynchron (nur gepuffert, um Flackern zu vermeiden), in sofern wird's nicht ruckeln solange es nicht eh schon Ruckler gibt.
Die Messungen habe ich mit der ~5 Jahre alten NW.js-Version die bei MV dabei ist gemacht. Falls ihr die aktualisiert wird das Spiel insgesamt noch mal schneller, einfach weil dann JavaScript allgemein schneller läuft.
Dazu am Rande: Ich arbeite gerade an einem Plugin, mit dem man Charaktersprites (also die Kartengrafiken für Akteure, Ereignisse und Fahrzeuge) dynamisch zusammensetzen kann. Bisschen so wie der Generator, nur eben regelbasiert zur Laufzeit. Dauert allerdings noch ein wenig bis es öffentlich ist, weil ich diese Woche wahrscheinlich keine Zeit habe, mich um das Testen und die Veröffentlichung zu kümmern.
Mein eigentliches Ziel dabei ist, die aktuelle Ausrüstung der Akteure anzuzeigen (bzw. kleine Staubwolken oder Wassertropfen, wenn jemand durch Sand oder Pfützen läuft), aber sowas geht damit denke ich auch.
Das ist jetzt fertig: Dynamic Characters
War dann am Ende doch noch etwas mehr Arbeit, aber ich fühle mich heute wahnsinning produktiv und habe das vorhin nach einer anderen größeren Sache auch noch fertiggemacht. Und jetzt muss ich mal schauen, was ich mit dem Rest des Tages so mache, außer mich langsam durch den Stapel Papierkram hier neben mir zu wühlen 
[…]Außerdem habe ich Lunee und Co massiv verkleinert, damit ihr Weltkartensprite nicht genauso groß ist wie die Ereignisse selbst. Aber da wir es besonders kompliziert mögen, musste ich das nicht nur 1x machen sondern 6x, da dreimal unterschiedlicher Van und dreimal unterschiedlicher Van + mysteriöser Compagnon Nr. 1.
Dazu am Rande: Ich arbeite gerade an einem Plugin, mit dem man Charaktersprites (also die Kartengrafiken für Akteure, Ereignisse und Fahrzeuge) dynamisch zusammensetzen kann. Bisschen so wie der Generator, nur eben regelbasiert zur Laufzeit. Dauert allerdings noch ein wenig bis es öffentlich ist, weil ich diese Woche wahrscheinlich keine Zeit habe, mich um das Testen und die Veröffentlichung zu kümmern.
Mein eigentliches Ziel dabei ist, die aktuelle Ausrüstung der Akteure anzuzeigen (bzw. kleine Staubwolken oder Wassertropfen, wenn jemand durch Sand oder Pfützen läuft), aber sowas geht damit denke ich auch.
Da ist (abgesehen von Problemen mit der Benutzeroberfläche) kein hartes Limit, ja.
Ich hab' vor einiger Zeit ein Scherz-Spiel mit 100 Kämpfern gleichzeitig gesehen und das lief (im Browser) noch relativ gut. War natürlich quasi unspielbar.
Nur interessehalber was ist dabei das Maximum?
Ups, ich hatte vergessen, eine 4 durch 6 zu ersetzen 
Überall wo jetzt 6 steht, bzw. 7 als maximum + 1.
Ja, das wird durch die Funktion Game_Party.prototype.maxBattleMembers geregelt.
Wenn du also (in MV oder MZ)
Game_Party.prototype.maxBattleMembers = function() {
return 6;
};
Sprite_Actor.prototype.setActorHome = function(index) {
this.setHome(600 + index * 32 * 4/6, 280 + index * 48 * 4/6);
};schreibst, dann hast du bis zu 6 Kämpfer wo sonst 4 stehen.
Wobei du rechts index auch durch ((index * 2) % 7) ersetzen kannst. Dann stehen die in bis zu zwei Reihen, was sie vielleicht etwas besser sichtbar macht.
