view+surfaces=nix gut?

  • view+surfaces=nix gut?

    In meinem spiel gibt es ein object namens obj_light, dass viele surfaces gleichzeitig bzw. aufeinander drawt, da es sehr komplex schatten simuliert. Es hat eine depth von -30
    drawe ich jetzt etwas mit dem obj_inventar welches eine depth von 0 hat, ist das gedrawte unter dem schatten welches das obj_light macht.
    Das soll aber nicht so sein, ich möchte über den schatten zeichnen.
    Also setzte ich die depth auf -31, was jedoch gravierende Folgen hat: Zum einen wird der view nicht mehr berücksichtigt, d.h. wenn ich ein sprite auf x=30 und y= 45 drawe folgt es dem view obwohl ich es doch auf die fixen variablen x und y zeichne.
    Zum anderen werden die sprites horizontal gezerrt. Ich weiß jetzt nicht um welchen faktor genau, aber sie sind schon fast doppelt so breit wie normal.
    Wie bereits gesagt, wenn die depth höher als -30 ist geht alles normal.

    Was kann da die Ursache sein?

  • Ich kenne einen ähnlichen Fehler, der Views, Surfaces und automatic drawing betraf bei dem alles aufs Doppelte skaliert wurde.
    Ich kann verstehen, wenn du deinen Code nicht komplett öffentlich machen willst, aber so per Ferndiagnose kann zumindest ich da nicht viel zu sagen... schicks mir daher vielleicht mal zu, dann kann ich mal etwas dran rumfummeln und dieses Rätsel auch mal vielleicht endlich für mich lösen (und für alle anderen natürlich auch).

    Edit:
    Views sind von der Mechnanik her etwas merkwürdig umgesetzt. Ich hoffe ja darauf, dass es kein Bug ist, sondern ein logisches Resultat, das sich manipulieren bzw. umgehen lässt.

  • Problem Nummer 1: Du zeichnest auf(!) den Surfaces im Draw-Event. Das darf man wegen der Videospeicherverwaltung des GMs niemals machen. Ich habe den entsprechenden Code, der vor dem Zeichnen der Surface selbst ausgeführt wird, aus draw_light ins End Step ausgelagert und damit schonmal die Depth-Probleme behoben.

    Genau diesen Code hab ich dann aber auch wieder gelöscht als ich festgestellt habe, dass der als Workaround für das Inventar gedacht war. Wenn du aber mal doch solchen Code hast, muss der ins End Step Event.

    Problem Nummer 2: Warum wandert alles mit doppelter Geschwindigkeit mit? Auch dieses Problem hat den gleichen Grund: Du zeichnest nach dem Zeichnen der Surface selbst wieder auf selbiger. Dabei werden die Positionen der internen Variablen geändert und man müsste in folgenden Draw-Events (deshalb das Problem erst ab -31) auf 0,0 zeichnen, damit es korrekt mitwandert.
    Lösung: Du packst diesen Code wiederum ins Begin-Step-Event, dann verhält sich auch alles normal.


    Erklärt mein altes Problem noch nicht, aber es zeigt, warum man nicht in Draw-Events auf Surfaces rumzeichnen soll: Die View-Variablen werden geändert.

  • Problem Nummer 1: Du zeichnest auf(!) den Surfaces im Draw-Event. Das darf man wegen der Videospeicherverwaltung des GMs niemals machen. Ich habe den entsprechenden Code, der vor dem Zeichnen der Surface selbst ausgeführt wird, aus draw_light ins End Step ausgelagert und damit schonmal die Depth-Probleme behoben.
    Also darf man im draw event nur direkt auf den Bildschirm zeichnen und nciht auf surfaces?
    Problem Nummer 2: Warum wandert alles mit doppelter Geschwindigkeit mit? Auch dieses Problem hat den gleichen Grund: Du zeichnest nach dem Zeichnen der Surface selbst wieder auf selbiger. Dabei werden die Positionen der internen Variablen geändert und man müsste in folgenden Draw-Events (deshalb das Problem erst ab -31) auf 0,0 zeichnen, damit es korrekt mitwandert.
    Lösung: Du packst diesen Code wiederum ins Begin-Step-Event, dann verhält sich auch alles normal.
    aber ich schreibe dann doch auch noch extra im draw event des inventars am anfang: surface_reset_target(). Somit müsste doch wieder auf den Bildschirm gezeichnet werden, oder?

    Also das mit dem view hast du hinbekommen sagst du. Und was ist mit der verzerrung?
    Könntest du mir bitte die veränderte gm6 schicken?

  • Hab ich nicht mehr. Folge einfach der Anleitung in meinem Post. Bei mir hat danach alles funktioniert - ich denke mal, dass die Art der Fehler zum Teil rechnerabhängig ist - gefixed sein sollten sie dann trotzdem alle.

    Also ja: Man darf nicht auf Surfaces im Draw Event zeichnen. Das liegt daran, dass Resettarget sich nicht darum kümmert, dass die ganzen Werte wieder stimmen.

  • Ja du hattest recht!
    Ich hab einfach diesen code:

    GML-Quellcode

    1. if gehtlos=1
    2. {
    3. surface_set_target(surface)
    4. draw_clear(c_white)
    5. surface_reset_target()
    7. surface_copy(surface,0,0,surface2)
    8. }

    ins step end event getan, anstatt ins draw event und schwupps, ging plötzlich alles!
    Danke für die Hilfe!

  • Benutzer online 1

    1 Besucher