Ergebnis 1 bis 7 von 7

Thema: Z.Priorität eines Pictures

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1

    Doktor von Stein Gast
    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.

    Geändert von Doktor von Stein (31.10.2012 um 12:53 Uhr)

  2. #2
    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

  3. #3
    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.

    Zitat Zitat
    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.

  4. #4

    Doktor von Stein Gast
    Zitat Zitat von -KD- Beitrag anzeigen
    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.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •