Zelda AKS mit Pixelmovement

[Lachsen]

Respekt, Respekt.

Ich habs jetzt nur kurz angestestet, dabei kamen keinen schwerwiegenden Fehler. Lediglich bei dem Großen Bereich mit den Büschen ist link, wenn man das schwert geschwungen hat und daraufhin weiterhin festhielt, nicht auf das Feld vor ohm gegangen, wo zueben ein Busch zerstört wurde... Desweiteren gehen die Büsche mit gezogener Klinger nicht weg, wenn man gegen sie latscht (das war nen Feature von A Link to the Past, afair)

Ansonsten wirklich gut, von der Performence her. Link bewegt sich nur etwas langsam, genau wie der Gegner. Aber das kann unter umständen an meinem Laptop liegen...

Hab nen Intel Pentium M 1,6 Ghz (also mit Centrino Tech.), ner 64 MB Grafikkarte... ehm... irgendwas... ATI Readon Mobile...
und 512 MB Arbeitsspeicher...

Beim Drehschwung fiehl es auf, dass es etwas langsam lief.
Ich hab allerdings mal ein Jump'n Run Skript erstellt, mit Pixel Bewegungen und recht aufwändig animiert und das lief ohne weitere Probleme...
Und ich denke das Skript war vom Rechnen-Aufwand nicht viel weniger schwerlastig als dieses Zelda-Skript...
Also ich schätze es dürfte eigentlich nicht langsam laufen... oder ist die Drehattacke absichtlich etwas langsamer?

(ich meine... normalerweise ist da ja kein Slowdown-Effekt, sondern ein stocken... von daher... )

Ich hatte auch mal im Kopf gehabt, so ein Skript zu probieren (da ich RM2k-treu bin und auch mit den Patches nicht so vertraut bin natürlich ohne Diagonale Bewegung...), was mich dann immer zögern ließ, ist die Anzeige der Sprites, die sich durch die Map bewegen. Genauer gesagt ist es problematisch, wenn diese Sprites so nah zusammen stehen, dass sie sich überlappen. Sie können ja einmal so übereinandern stehen und einmal umgekehrt... Um da immer eine richtige Anzeige zu haben muss man zwangsläufig die Picture ID der Sprites ändern (oder alternativ das Sprite in zwei Grafiken aufteilen, wobei die obere hälfte ne Höhere Picture ID hat... aber 2 Pictures pro Figur? Mir wäre das zu aufwändig...)

Sigh... alles wäre soviel einfacher, wenn man Variablen für die Picture ID angeben könnte...

Könnte das mal irgendwer zurechthacken? XD Das wäre mit die größte Errungenschaft für alle Extrem-Skripter (schätz ich mal)

Wie auch immer... beim Zelda-Skript fällt das Problem ja zum Glück nicht zur last, da man nie wirklich die Möglichkeit hat die Sprites nach genug ran zu bekommen, damit sie sich (langzeitig) überlappen... zumindest von unten, denn da kommt der Fehler (ich habs genau gesehen, als ich GameOver ging... ganz kurz überlappen sie sich etwas und Links Mütze verschwand unter dem Schatten des Gegners XD)
Allerdings hat Zelda auch große Gegner und spätestens hier brauch man ne Lösung für das Problem Oo

Dennoch: Respekt. Wenn ich mich recht erinnere, gehörst du sicherlich zu den besten Skriptern, die ich hier so im Maker-Bereich zu sehen bekam, Ryo Saeba.

Saubere Arbeit ^^

C ya

Lachsen

Edit: Zur Performance: Die Drehattacke scheint tatsächlich einfach so so langsam zu sein, also nicht aus performenced Gründen. Also ist die Performence, so wie ich das sehe, einwandfrei

[Ryo Saeba 1000]

Ehrlichgesagt habe ich Zelda III schon lange nicht mehr gespielt und hab bei den Animationsgeschwindigkeiten meist einfach nur grob geschätzt. Die Wirbelattacke schneller ablaufen zu lassen wäre kein Ding, einfach die entsprechenden Waits (hab da afair immer ein 0.1 drinnen) verkürzen.
Freut mich dass es auf einem 1,6GHz Rechner gut läuft^^

Bei dem großen Feld kann es daran liegen dass Link wie gesagt nicht wie im Original reinflutscht, sondern man sich da diagonal bewegen muss um reinzuflutschen, dann sollte es aber ohne Probleme gehen.

Das mit dem Gedrückthalten und Büsche/ Gegner plätten hab ich nicht mehr eingebaut, wollte ich noch zusammen mit Rennen und von Vorsprüngen runterspringen aber am Ende hat die Motivation leider dazu gefehlt, da ich da kein Spiel draus mache und am Ende nur zeigen wollte was mit dem 2k/2k3 möglich ist.

Ich hatte auch mal im Kopf gehabt, so ein Skript zu probieren (da ich RM2k-treu bin und auch mit den Patches nicht so vertraut bin natürlich ohne Diagonale Bewegung...), was mich dann immer zögern ließ, ist die Anzeige der Sprites, die sich durch die Map bewegen. Genauer gesagt ist es problematisch, wenn diese Sprites so nah zusammen stehen, dass sie sich überlappen. Sie können ja einmal so übereinandern stehen und einmal umgekehrt... Um da immer eine richtige Anzeige zu haben muss man zwangsläufig die Picture ID der Sprites ändern (oder alternativ das Sprite in zwei Grafiken aufteilen, wobei die obere hälfte ne Höhere Picture ID hat... aber 2 Pictures pro Figur? Mir wäre das zu aufwändig...)

Sigh... alles wäre soviel einfacher, wenn man Variablen für die Picture ID angeben könnte...

...

Du sprichst mir wirklich aus der Seele^^ Ich habe mir auch schon über dieses Problem Gedanken gemacht und sah nur die Möglichkeit die ganzen nötigen CE's zu duplizieren mit dem einzigen Unterschied, dass beim Duplikat eine andere Pic-ID zur Anzeige verwendet wird. Bei den zig Show und Move Pic Befehlen eine unglaubliche Arbeit, die ich mir wohl nur gemacht hätte, wenn ich mehr als einen Gegner eingebaut hätte.
So eine durch Variablen einfach änderbare Pic-ID Sache würde den Maker zusammen mit einem aufgehobenen Piclimit relativ mächtig machen.. ich war am verzweifeln als ich vor einiger Zeit für mein RTS-Interface eine Rahmenauswahl (also dass man mehrere Einheiten per pixelgenau per Maus veränderbaren Rahmen umschließen und somit auswählen kann) scriptete, da hab ich mir das sooo sehr gewünscht xD

achja, thx für das Lob^^

[PsY]

Nochmal Respectomondo!

Aber bei mir klappt das nur wenn ich meinen Screen mit F4 und dann F5 verkleinere sonst ruckelt es immer!

[NH]

o.O Das Teil steckt voller Bugs. Was für welche?
Hier mal so eine kleine Auswahl:

- Man kann das Schwert nicht benutzen.
- Man kann aus den violetten Dingens Büsche reusziehen.
- Link läuft plötzlich einfach geradeaus und bleibt nicht mehr stehen.

So, die anderen 347'384'723 hab ich vergessen.
Sonst wäre es super, aber die vielen Bugs ;_;

[Ryo Saeba 1000]

- Man kann das Schwert nicht benutzen.

...

Das stimmt nicht.

- Man kann aus den violetten Dingens Büsche reusziehen.
- Link läuft plötzlich einfach geradeaus und bleibt nicht mehr stehen.

...

Du erzählst mir nichts neues^^ Schon die Bugliste gelesen?

[Venoran]

Ich habs auch mal angetestet. Natürlich musste ich es vorher ein wenig "optimieren", damit es auf meinem 800 Mhz-Rechner überhaupt funktioniert. Die Idee, statt Events auf Bilder und deren Screen-Berechnung zu setzen ist zwar nicht neu, aber bisher hat es kaum jemand für den RPG-Maker wirklich durchgesetzt.
Die Qualität von Spielen lässt sich dadurch erhöhen, aber leider steigt auch der Arbeitsaufwand enorm.
Ich kenne mich zwar mit Technik in Bezug mit dem RPG-Maker gut aus, aber trotzdem brauchte ich fast eine ganze halbe Stunde, um das System ganz zu durchblicken!! Ich glaube kaum, dass ein Durchschnittsmaker dieses System wirklich verwenden kann, trotzdem ist es eine äußerst gute Innovationsquelle!
Ich will deine Arbeit nicht schlecht machen (versteh mich net falsch... ); ich finds richtig gut, dass es mal jemand durchgezogen hat!
Ich wäre dafür vermutlich zu faul...

Mit Respekt,
G.V.H.

[FabiF.de_renamed]

WOW, echt GOIL.... DOCh so hohe system anforderungen hab ich nicht, und bei mir ruckelts mächtig... trotzdem sehr gut gemacht... ich trau mich nichtmal mir dass im maker anzuschauen, weil dass zuviel technik ist.

Aber respekt

wenn man so ein ganzes spiel machen würde, und es nicht so ruckeln würde.... dann wird es bestimmt ein HAMMER game, leider wie gesagt ruckelts bei schlecheteren Rechnern....

Mann das ist geil, mach weiterso TOP

eins hat mir nur nicht gefallen..... und zwar, manchmal kann man zwischen büschen nicht durchlaufen, weil die Kollisionsabfrage zu ungenau ist.... obwohl man theoretisch vorbei laugen könnte geht dass net...

MFG FabiF.de

MFG FabiF.de

[Ryo Saeba 1000]

Ich habs auch mal angetestet. Natürlich musste ich es vorher ein wenig "optimieren", damit es auf meinem 800 Mhz-Rechner überhaupt funktioniert.

...

Du hast durchgeblickt o.O toll, zeigt mir dass da vielleicht doch ein erkennbares System ist xD respekt.
Darf man fragen wie du es optimiert hast?

eins hat mir nur nicht gefallen..... und zwar, manchmal kann man zwischen büschen nicht durchlaufen, weil die Kollisionsabfrage zu ungenau ist.... obwohl man theoretisch vorbei laugen könnte geht dass net...

...

hmmm die Kollisionsabfrage mit der Umgebung ist eigentlich das einzige auf das ich so richtig stolz sein kann, da sie bugfrei und ohne Probleme funktioniert und dazu noch pixelgenau ist. Du must diech wie schon OFT gesagt diagonal bewegen, wenn du nicht genau in die Lücke reinpasst. Probier's mal aus, es geht und ist keinesfalls ungenau..

[one-cool]

Hosasa, ein echt geniales System, ich habe es mir bisher nur im maker angesehen, da ich es interessanter fnide, wie es gelöst ist.
Ich schau es mir aber später auch mal als Spiel an.

einige Sachen sind imo echt klasse gelöst, wie ich es sehe.

Du hast nur etwas wirr für Aussenstehende geproggt.
Hat ne Weile gedauert, bis ich durchgestiegen bin. Maybe werde ich damit auch ein wenig rumspielen und basteln, ^mal schauen.

Von mir ein respekt an das, was du geschaffen hast.

[Venoran]

Du hast durchgeblickt o.O toll, zeigt mir dass da vielleicht doch ein erkennbares System ist xD respekt.
Darf man fragen wie du es optimiert hast?

...

Ist ganz einfach! In wirklichkeit braucht das Skript gar nicht so viel Performance...
Dein Fehler war, dass du vieles einfach 30 bis 40 Mal pro Sekunde berechnest, obwohl ein Mensch weder so schnell reagiert noch sieht. Natürlich ist flüssiges Spielen wichtig, aber man muss es nicht übertreiben.
Was aber am meisten Performance kostet, ist dein Angriffs-Common-Event.
Es ist zwar eine technisch sehr gute Leistung, trotzdem hast du einige umständliche Stellen in deinen Event "Angriff". Ich meine, ein Schlag muss treffen, aber nicht unbedingt als Parallel-Process dauernd berechnet werden.
Berechne lieber, ob der Gegner überhaupt in Reichweite des Schwertes liegt und berechne dann die Trefferzone des Schwertes.
Dir jetzt genau zu erklären, was ich umgeändert habe, würde ziemlich lange dauern...
Deswegen sag ich dir einfach folgendes: Berechne nur das, was du wirklich in diesen Moment brauchst. Um herauszufinden, was man braucht, kann man auch eine 1.0-Berechnung benutzen, die alle anderen Berechnungen aktiviert oder deaktiviert, wenn benötigt.

Mit Respekt, G.V.H.

[CRZYSheep]

Hi,
ja gefällt mir sehr gut! Ne nette Umsetzung des gewohnten Zelda Ks!
Ähhm nur eins, ich hab das komplette Teil auf nem 1,2 Gig AMD, 256 SDRam gefahren und habe keinen unterschied zu meinem anderem Rechner finden können, läuft auf beiden einwandfrei und Ruckellos!
Mfg CRZYSheep!

[Ryo Saeba 1000]

Ist ganz einfach! In wirklichkeit braucht das Skript gar nicht so viel Performance...
Dein Fehler war, dass du vieles einfach 30 bis 40 Mal pro Sekunde berechnest, obwohl ein Mensch weder so schnell reagiert noch sieht. Natürlich ist flüssiges Spielen wichtig, aber man muss es nicht übertreiben.
Was aber am meisten Performance kostet, ist dein Angriffs-Common-Event.
Es ist zwar eine technisch sehr gute Leistung, trotzdem hast du einige umständliche Stellen in deinen Event "Angriff". Ich meine, ein Schlag muss treffen, aber nicht unbedingt als Parallel-Process dauernd berechnet werden.
Berechne lieber, ob der Gegner überhaupt in Reichweite des Schwertes liegt und berechne dann die Trefferzone des Schwertes.
Dir jetzt genau zu erklären, was ich umgeändert habe, würde ziemlich lange dauern...
Deswegen sag ich dir einfach folgendes: Berechne nur das, was du wirklich in diesen Moment brauchst. Um herauszufinden, was man braucht, kann man auch eine 1.0-Berechnung benutzen, die alle anderen Berechnungen aktiviert oder deaktiviert, wenn benötigt.

Mit Respekt, G.V.H.

...

Ähm ja, mein Angriffs CE ist ziemlich derb^^ wenn man sich dagegegen die Wirbelattacke ansieht... dass es als PP Event läuft ist an sich ziemlich nützlich, aber mit den Waits hast du sicher recht, beim Angriffsevent dürfte es ein 0.1 auch tun. Allerdings sehe ich noch nicht, wo du jetzt noch generell was geändert haben sollst, da das Haupt-CE (afair Tastatur) mit einem 0.0 Wait laufen muss, sonst verlangsamt sich die Bewegung von Link zu stark. Ähnliches gilt auch für den Gegner. Wäre aber natürlich toll, wenn du da auch eine Lösung parat hättest.
btw wenn die Steuerung 30 statt 5 mal pro Sekunde abgefragt wid ist sie auch 6mal genauer.. aber man müsste halt sehen, welchen Kompromiss man da eingeht.