Z.Priorität eines Pictures

[Suirat]

Danke für deine Antwort, aber ich denke du hast das Problem falsch verstanden.
Das Menü ist schon komplett fertig, was die Navigation betrifft, ich habe zudem noch einige Huds die Pictures verbrauchen, das erste Picture was ich, ohne in die Hud Picture eingreifen zu müssen benutzen kann ist das Pic Nr. 35.
Ich denke wenn man das Projekt downloadet ist schnell erkennbar was das eigentliche Problem ist.

Ich lasse es Picturebasiert, da so im Hintergrund ein Teil der Map zu sehen ist und ich diesen Effekt einfach angenehmer finde. Die Cursor-Bewegung findet über Loops und Lables statt, da ich keine Variablen oder Switches unnötiger Weise verschwenden wollte, und das ist meiner Meinung nach auch die einfachste, übersichtlichste und nachvollziehbarste Methode.

Wie gesagt einfach mal das Projekt anschauen um einen besseren Überblick zu erhalten.

Ich hoffe es findet sich jemand, der sich mit dem seltsamen und meiner Meinung nach auch komplizierten Problem ausseiandersetzten kann.

Gruss Suirat

[Doktor von Stein]

Hallo Suirat,
Suche im Sprite_Picture nach der Zeile 62.
Diese ersetzt du durch diesen Code:

Code:

self.z = @picture.number + 201
if @picture.name == "cursor"
self.z = 5000
end

Wenn du jetzt noch den Bildnamen deines Cursors auf "cursor" änderst, sollte das ganze funktionieren, wie du es willst, auch wenn ich dir ernstlich empfehlen würde, dir einen anderen Workflow zuzulegen.

[Suirat]

Entschuldigung bereits im Vorhinein dafür, dass ich einen derart alten Thread wieder pushe. (Um das Problem geht s mir gar nicht mehr). Was ich jedcoh sehr interessant fand und gerade eben zum ersten mal gelesen habe, war der Hinweis mit dem Workflow - mittlerweile hat das Projekt einen großen Schritt nach vorn gemacht, was die technischen Komponenten anbelangt und ich merke wie viel Preformance das ganze Game zieht. Bei meiner vollen und mit allen Features vollgepadkten (80x80 großen) Testmap ist es unmöglich ohne Ruckler zu spielen. Ich muss nun das Ace-Engine Xp Update von Terv implementieren um zumindest noch einigermaßen Preformance zu sichern.

Was genau meinst du mit Workflow (Die Event basierten Funktionen - hab ich falsch 'evented') oder allgemein dass ich das alles ohne Scripts mache?

Gruß Suirat

[-KD-]

Ich glaub es ging eher darum, dass es nicht sonderlich elegant ist Eventcode und Rubycode so zu vermischen. Es lässt sich schwerer lesen, verstehen und warten. Und ein Menü kann man auch genauso gut komplett in Ruby oder komplett über Events lösen.

Bei meiner vollen und mit allen Features vollgepadkten (80x80 großen) Testmap ist es unmöglich ohne Ruckler zu spielen.

...

Viele RGSS Scripte sind schlecht gecodet und verbraten unnötig viel Performance. Oder aber sie sind einfach nicht optimiert, weil es für ein einzelnes Script auch oftmals nicht erforderlich ist. Es hat aber vermutlich auch keiner Lust alle deine Scripte durchzusehen und zu optimieren. Wenn du ungefähr sagen kannst, welches Script so sehr an der Performance zieht, kann man dir schon eher weiterhelfen.
Prinzipiell lässt sich auch ein featurereiches Spiel ohne Performanceprobleme umsetzen.
Der Umstieg auf die VX Ace Engine könnte tatsächlich helfen, weil dort auch Rubyscripte deutlich schneller ausgeführt werden. Allerdings hat der VX Ace eine andere Map-Engine. D.h. du musst eine eigene Map-Engine schreiben, die wiederum eine Menge Rechenzeit frisst. Wie viel du also am Ende an Performance rausbekommst ist ungewiss.

[Doktor von Stein]

Ich glaub es ging eher darum, dass es nicht sonderlich elegant ist Eventcode und Rubycode so zu vermischen.

...

Genau das meinte ich.
Wenn man ein Menü auf einer Map haben will, sollte man entweder mit Picturebefehlen arbeiten oder aber komplett scripten und ein Bild der Map im Hintergrund halten.
Hier gibt es genug talentierte Leute, die dir dabei helfen können.

Grüße,
Dr. Stein.