Technik-Sammelthread für Probleme und Antworten

[Morden]

Bin an RM2k gebunden, DynRPG ist also keine Option.

...

Wenn du an den Rm2k gebunden bist, kann ich dir für komplexere Sachen den DestinyPatch empfehlen! Der stellt eine Skriptsprache bereit, welche du in den Kommentaren notierst, und die dir auf fast alles Zugriff gewährt. Damit kannst du dann auch komplexere Skripte "leichter" umsetzen. Zählschleifen und erweiterte logische Ausdrücke sind schon was feines^^

Wenn's ruckelt, hast du Mist gebaut, aber für diese Abfrage brauchst du bestimmt keinen hochkomplexen Code aus der Factory.

…

Am Ende einen Wait 0 benutzen, reicht aus.

...

Ich könnte mir vorstellen, dass evtl. der Else-Handler - wenn er denn verwendet wurde - daran Schuld sein könnte. Also an dem Ruckeln. Ich habe auch schon desöfteren festgestellt, dass man die Engine ziemlich leicht zum ruckeln bringen kann, wenn man viele Else-Handler verwendet und die Reihenfolge der Abfragen nicht der "erwarteten" Häufigkeit entspricht. Dort ist es dann oftmals schneller keine Else-Handler zu benutzen, und das ohne sie zu lösen.

Und eigentlich bräuchte man bei einem PP kein Wait 0 am Ende, weil ein PP automatisch ein Wait 0 am Ende des Event-Skriptes setzt Setzt man gar kein Wait in einem PP, so wird es - im günstigsten Fall - 60 mal in der Sekunde ausgeführt (60 fps). Es wartet also von vornherein schon einen Frame - also Wait 0 - bis es das nächste Mal durchläuft. Mit einem Wait 0 würde es also 30 mal durchlaufen pro Sekunde.

PeAcE
MorDen

[Nemica]

Also 30 mal in der Sekunde ist eh mehr als genug. Und gegen sich stapelnde Else-Handler kann man die Abfragen in Gruppen aufteilen und den nicht benutzten Code überspringen.

[Morden]

Also 30 mal in der Sekunde ist eh mehr als genug. Und gegen sich stapelnde Else-Handler kann man die Abfragen in Gruppen aufteilen und den nicht benutzten Code überspringen.

...

Ob 30 mal die Sekunde genug ist, kommt wieder darauf an, was gemacht werden soll - wobei ich dir natürlich grundsätzlich Recht gebe. Normalerweise sollte das reichen. Nur ist es einfach gut zu wissen, wie der Maker seine Events abarbeitet - ist zumindest meine Meinung. Denn ein AutoStart-Event z.B. wartet nicht bis zum nächsten Frame, weswegen man damit auch ziemlich einfach die gesamte Engine lahmlegen kann.

Man kann manchmal auch komplett auf den Else-Handler verzichten. Aber es ist stimmt schon was du sagst, ist alles ne Frage der Code-Strukturierung. Ich arbeite ja auch nicht erst drei Tage mit den Makern^^ Und der Else-Handler ist imo schlecht implementiert xD

PeAcE
MorDen

[Nemica]

Das mit dem Elsestapeln ging auch eher an Elvis Stein den Jüngeren.

[elvissteinjr]

Also bei mir läuft ja jetzt alles. Destiny wollt ich jetzt nicht auch noch reinhauen und schon gar nicht kurzfristig lernen damit umzugehen(ist Contestprojekt, Abgabe: heute*hust*). Achja, ich hoffe übrigends dass du nicht extra für Zählschleifen den Destiny brauchst, würde mir sorgen machen.^^'
Und selbst wenn ein PP den Frame abwartet, ohne Wait wird das auf Singlecores oft unverhältnismäßig lahm.

Die Frage ist ja, wie man die klassische direkte Positionsabfrage denn für die Menge sinnvoll aufteilen könnte. Wenn ich das ganze jetzt mit Flächen gebraucht hätte, wär's erst recht was geworden.

Aber naja, bei läuft ja jetzt alles soweit. Hoffe nur dass wirklich schwache Rechner da nicht irgendwie trotzdem überfordert werden(die Schalter sind ja nicht die einzigen Sachen die als PP laufen), hab sowas aber leider nicht mehr im Haus.

[Cherry]

Ob Singlecore oder Hexadecacore macht beim Maker keinen Unterschied, alles wird da auf einem Prozessorkern ausgeführt.

[elvissteinjr]

Bloß kann das Ding dann ja nicht das ganze System mit runter reißen, das war eigentlich mein Punkt, sorry.

[Morden]

Also bei mir läuft ja jetzt alles. Destiny wollt ich jetzt nicht auch noch reinhauen und schon gar nicht kurzfristig lernen damit umzugehen(ist Contestprojekt, Abgabe: heute*hust*). Achja, ich hoffe übrigends dass du nicht extra für Zählschleifen den Destiny brauchst, würde mir sorgen machen.^^'
Und selbst wenn ein PP den Frame abwartet, ohne Wait wird das auf Singlecores oft unverhältnismäßig lahm.

Die Frage ist ja, wie man die klassische direkte Positionsabfrage denn für die Menge sinnvoll aufteilen könnte. Wenn ich das ganze jetzt mit Flächen gebraucht hätte, wär's erst recht was geworden.

Aber naja, bei läuft ja jetzt alles soweit. Hoffe nur dass wirklich schwache Rechner da nicht irgendwie trotzdem überfordert werden(die Schalter sind ja nicht die einzigen Sachen die als PP laufen), hab sowas aber leider nicht mehr im Haus.

...

Nein, natürlich kann man kopf- und fußgesteuerte Schleifen im Maker nachbauen - keine Frage. Damit dann halt auch Zählschleifen. Aber dennoch ist es wesentlich komfortabler, wenn man sie direkt benutzen kann - darauf wollte ich eigentlich hinaus. Rein »theoretisch« kann man wirklich vieles mit dem Maker nachbilden - mehr oder weniger aufwändig, und mehr oder weniger performant. Und gerade Koordinaten getten scheint für die Maker-Engine echt schwerstarbeit zu sein. Hatte das mal getestet indem ich die Zeit gemessen habe, wie lange es dauert 500.000 mal die Koordinaten eines Events zu getten. Dabei hatte ich einmal komplett die Maker-Engine verpflichtet, einmal DynRPG für das getten der Koordinaten (dabei die Schleife per Maker Engine) und einmal die komplette Schleife in DynRPG/C++. Zeit war Maker > Maker/DynRPG > DynRPG/C++ (Wobei DynRPG/C++ extrem schnell war ( <1s ) )
Wobei ich glaube, dass das jetzt nicht sonderlich neu und interessant war xDD

Und normalerweise sollte es - wie Cherry schon sagte - egal sein, ob Dual- oder Singlecore, solange die Pro-Kern-Leistung hoch genug ist. Wobei ich dir Recht gebe, dass beim DualCore der Vorteil ist, dass Windows-Hintergrunddienste auf den zweiten Kern verteilt werden können.

Was vor allem beim Maker noch zu beachten ist, ist dass JEDE Variablen-Operation die gleiche Zeit zu kosten scheint. Egal ob "+", "-" usw. Das interessante: Die Variablen-Range-Funktion braucht anscheinend auch genauso lange, wie eine normale Variablen-Operation an einer einzigen Variable o.O

Und bzgl. sinnvoller Aufteilung kommt das wohl auch ganz auf die Aufgabe des Skriptes an.

Ob Singlecore oder Hexadecacore macht beim Maker keinen Unterschied, alles wird da auf einem Prozessorkern ausgeführt.

...

Hexadecacore = 16 Kerne? ^^

PeAcE
MorDen

[elvissteinjr]

Was vor allem beim Maker noch zu beachten ist, ist dass JEDE Variablen-Operation die gleiche Zeit kostet. Egal ob "+", "-" usw. Das interessante: Die Variablen-Range-Funktion braucht auch genauso lange, wie eine normale Variablen-Operation an einer einzigen Variable o.O

...

Das ist gar nicht so verwunderlich. Die meiste Zeit wird der Maker wohl für die interpretierung der Skriptzeile beanspruchen, danach für den Zugriff auf das VariablenArray. Die eigentlichen Rechenoperatiionen benötigen da nur minimalste CPU Zeit.

[Mike]

Gibt's die Möglichkeit den Maker in der "Mindestens 1 Lebenspunkt bleibt übrig"-Sache dahingehend auszutricksen, dass ich - wie bei einem Kampf - anstatt auf den GameOver-Screen zu kommen, eine Art "Custom Handler" einbaue?

LG Mike

[TwoFace]

Klar. Wähl Conditional Branch auf und geh auf Seite 2 zu "Hero HP is at least" und definiere die HP als 1.

[Mike]

Ich meinte damit, dass ich bei der Funktion "Change HP's" den Haken bei "hp reduction can kill target" setzen kann, ohne dann zum GameOver-Screen zu kommen. Es soll dann ein selbsterstellter GameOver-Screen aufgerufen werden, der zB animiert oder dgl. ist

LG Mike

[Corti]

K.a. wozu du das brauchst, Action-KS oder irgendwelche Dungeonfallen oder so, da du es wahrscheinlich selbst codest, mach ne Abfrage ob es killen wird, dann haste deine Information.

if(Schadenspunkte > verbleibende HP)
{
// Held würde sterben...
}

[Mike]

So hab ich's momentan gelöst Kam mir aber unlogisch vor, dass es da keine Funktion gibt, weil's beim Kampf auch eine gibt. Danke trotzdem!

Und ja: Für Dungeonfallen. Genau ins Schwarze getroffen ^^

LG Mike

[Cynder]

Hey hier ist mal n merkwürdiges problem : ohne grund spinnen auf einmal
die bewegungen rum - der chara läuft automatisch nach oben und man kann nicht nach unten
meine tatatur ist aber in ordnung habs schon mit ner andern ausrpobiert - und andere programme und tools sind auch in ordnung

ich habe den maker auch schon re-instaliert
das problem taucht bei ALLEN makern auf sowohl asl beim 2003 als auch beim XP
was da los ?

[Cherry]

Starte dieses Programm, das korrigiert den Fehler: http://share.cherrytree.at/showfile-2704/kbdreset.exe

[Cynder]

leider nicht

[Cherry]

Dann gibts normalerweise eigentlich nur noch die Möglichkeit dass du ein Gamepad angeschlossen hast und das nicht ordentlich kalibriert ist...

Bzw. hast du schon einen simplen Computerneustart versucht?

[Riven]

Ich hab mal ne Frage zu dem UnlockPic Patch der bei mir irgendwie nicht zu funktionieren scheint ... ich habe die RPG_RT.exe gepatcht doch wenn ich das Spiel starte frieren trotzdem alle beweglichen Hintergrundbilder ein sobald die Textboxmessage startet -.- muss man noch irgendwie etwas einstellen oder so? Im Prinzip ist es ja ne simple Sache und ich wüsste nicht was ich falsch gemacht hätte bzw nicht gemacht habe... ich benutze den 2k

[Nemica]

Eigentlich ist da nix mehr einzustellen. oô

Schnapp dir ne neue exe und versuchs nochmal.