Ergebnis 1 bis 20 von 30

Thema: [RM2K3] Spiegelbild zum Spieler bewegt sich zu langsam

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Ohne jetzt genauer durchgeguckt zu haben:
    Gibt das nicht alleine wegen des 0.1 waits Probleme? 0.1 bekommt das menschliche Auge ja durchaus problemlos mit, was wiederum dazu führen dürfte, dass das Spiegelbild sich leicht zeitversetzt bewegt? Wenn überhaupt würde ich bei sowas mit 0.0 arbeiten.

    Spontaner Ansatz:
    Code:
    <>Set Var [0001: Held X] = Pos X
    <>Wait (0.0)
    <>Set Var [0001: Held X] - Pos X
    <>If V[0001] > 0
      <>Move Event: left
    :ELSE
      <>If V[0001] < 0
        <>Move Event: right
      :END
    :END
    Sollte so eigentlich gehen (wenn ich nicht die Bewegungsrichtungen verwechselt habe...) und auf jeden Fall schneller sein als die 0.1-Varianten oder wenn mehrere PPs involviert sind. Ließe sich genau so mit einer zweiten Variable auch für die Y-Achse erweitern.

    Geändert von BDraw (21.03.2016 um 19:32 Uhr)

  2. #2

    Users Awaiting Email Confirmation

    Danke schon einmal für die Antworten

    @ BDraw: Ich hatte es schon einmal geschafft, dass sich beide Events gleich schnell bewegen. Dann kam jedoch das Kollisionsproblem dazu. Und das funktionierte theoretisch mit 0.1 Wait ganz gut. Der 0.0 Wait hinter den Move Event des Spielers ist auch nur dazu da, damit die Variable schnell genug mit der neuen X - Koord. versehen werden kann. Seid ich jedoch die Kollisionssache mit drinne habe, buggt das so rum.

    @ Cornix: Inwiefern hat meine Lösung denn Probleme? Ich dachte es wäre klüger, die einzelnen Berechnungen und Abläufe in einzelnen Common Events zu separieren. Zwecks Übersicht und das so natürlich manche Sachen gleichzeitig nebeneinander ablaufen können.

    @ Beide und Allg.: Habe beide Sachen versucht versucht. Leider keine Verbesserung. Zu dem bewegen sich die Figuren teilweise auch bei nur einem minimalen Tastendruck mehr als ein Feld in die entsprechende Richtung, obwohl im Move Event nur eine Bewegung enthalten ist. Habs mit Waits als auch Proceed with Movement versucht, die Figuren laufen dennoch mehr als sie sollten. Vorzugsweise die Spielfigur.

    Edit: Wenn ich alle Bewegungsabläufe, die Bestimmung der X - Koord. und auch die Eingabe separiere, funktionierts leider auch nicht

    MfG Draegor

    Geändert von Draegor (21.03.2016 um 21:21 Uhr)

  3. #3
    Ich hab's gerade mal getestet - bei mir hat es sich mit meinem Ansatz durchaus gleichschnell bewegt (und auch die korrekte Anzahl an Felder - sicher, dass du da mit Pos X und nicht Screen X gerechnet hast), allerdings hat es ab und an plötzlich ausgesetzt. Da ich allerdings ins Testmenü mit den Variablen komme, konnte ich nicht überprüfen, wann bzw. wo genau der Fehler auftrat, sprich, ob es irgendwo am Wait liegt, das dann die Berechnung verfälscht, oder mein Windows noch nicht ganz auf der Höhe war. Letzteres ist allerdings bei sowas simplen eher unwahrscheinlich, auch wenn Bootcamp + Windows + Steam immer etwas braucht, um in die Gänge zu kommen. :/

    Was ich aber gerade nicht ganz verstehe: Weswegen steuerst du denn auch den Spielercharakter manuell? Für mehr Kontrolle über die genaue Position oder wozu?

  4. #4

    Users Awaiting Email Confirmation

    @BDraw: Ich bewege den Helden manuell, damit er sich beim Drücken von Pfeiltaste Oben nach Oben-Rechts und beim Drücken von Pfeiltaste Unten nach Unten-Links bewegt. Diese Aussetzer habe ich auch manchmal. Aber irgendwie kommen und gehen die, wie es ihnen gerade passt. Manchmal habe ich sie auch gar nicht.

    Hast du vielleicht noch einen Tipp, wie ich die Kollision einbauen kann? Weil irgendwie hardert das ganze System da dran und mir will nicht so ganz einleuchten, wieso es das tut.

    MfG Draegor

  5. #5
    Wenn du nicht bereits anderweitig Verwendung für die Terrain-IDs hast wäre das eine Möglichkeit. Du markierst in der Database alle nicht-passierbaren Tiles mit einer Terrain-ID und kannst so auf Maps ganz einfach abfragen, ob ein Tile passierbar ist oder nicht. Die leider ziemlich unpraktischen Nachteile sind, dass das nicht bei Upper Layer-Tiles hilft und auch mit Events nicht klappt - das lässt sich aber umgehen, da man afair mit Store Event ID auch Felder abfragen kann, auf denen kein Event ist (ergäbe dann ID = 0). So kann man das nutzen um abzufragen, ob überhaupt ein Event vorhanden ist.

    Etwas elegantere Methoden würde auf Pixelbewegungen aufbauen, aber das ist dann wiederum recht kompliziert, da du das genau mit der Bewegungsgeschwindigkeit timen müsstest. Da ist vor allem dieser Post sehr hilfreich.

    Meine Theorie was die Aussetzer angeht wäre, dass die mit den Waits zusammenhängen. Dadurch, dass der 2k/3 recht grobe Einheiten benutzt, kann es passieren, dass der Spieler genau dann eine Taste drückt, wenn ein Wait den Code am Weiterarbeiten "hindert". Beispiel: Du fragst eine Taste ab und hast am Ende ein Wait von 0.1 damit alles flüssig läuft. Der Spieler drückt die Taste (alles super soweit), lässt los, und drückt sofort die nächste Taste. Das ist aber viel schneller als 0.1s, wodurch das Event noch beschäftigt ist und so den Tastendruck noch gar nicht wieder abfragt. Gerade wenn du Abfragen hast die stattfinden, während der Spieler weiter lustig Tasten drücken kann, kann das zu ganz merkwürdigen Hängern führen, da du ja nach außen hin nicht weißt, ob der Spieler gerade genau so eine "Lücke" erwischt. Deswegen auch meine Skepsis bei so langen Waits wenn es um Bewegungsabfragen geht.

    Geändert von BDraw (21.03.2016 um 23:19 Uhr)

  6. #6
    Vielleicht mal ein anderer Ansatz, der im Prinzip das selbe Ergebnis hat, aber technisch einfacher zu bewerkstelligen sein sollte:

    Das Spiegelbild soll ja fix in Beziehung zum Spieler sein (z.B. 5 Felder rechts von ihr).
    Dann erstelle einen Charakter, der in der Mitte deine Figur hat, 5 Felder nach Links geht (da aber transparent ist) und 5 Felder nach rechts geht und da deine Spiegelfigur hat.
    Dann wären deine Figur und das Spiegelbild quasi die selbe Figur, die Bewegungen würden hundertprozentig synchron laufen und du könntest nicht mehr feststecken oder sonstwie sich die Positionen der Figuren zueinander ändern.
    Das einzige was du noch machen müsstest, wäre transparente Blöcke dahin zu stellen, wo deine Spielfigur nicht hin kann, weil das Spiegelbild sonst in die Wand laufen würde.
    Sollte sich die Position der beiden Figuren zueinander später ändern oder das Spiegelbild verschwinden, kannst du ja einfach eine neue Grafik für deinen Helden einfügen (das sollte der 2k3 über Events machen können).

  7. #7
    Eins verstehe ich nicht: Wenn Spielfigur und Spiegelbild sich gleichzeitig bewegen sollen, warum packst du dann das Ausführen der Bewegung nicht in einen einzigen CE? Wenn du nach dem Move-Befehl ein "Proceed with Movement" platzierst, dann sorgt nämlich der Maker dafür, dass beide Events sich gleichzeitig bewegen.

  8. #8
    Zitat Zitat von Leana Beitrag anzeigen
    Eins verstehe ich nicht: Wenn Spielfigur und Spiegelbild sich gleichzeitig bewegen sollen, warum packst du dann das Ausführen der Bewegung nicht in einen einzigen CE? Wenn du nach dem Move-Befehl ein "Proceed with Movement" platzierst, dann sorgt nämlich der Maker dafür, dass beide Events sich gleichzeitig bewegen.
    Ich denke das Problem ist doch, dass das Spiegelbild an Wänden hängen bleiben kann (Die Figur geht nach oben, bei der Spiegelfigur ist da aber eine Wand und dann bleibt sie quasi auf der Stelle stehen).
    Und das sollte - soweit ich es verstanden habe - nicht passieren.
    Der Abstand der Figuren soll immer gleich bleiben: Kann A sich nicht hoch bewegen, dann kann B es auch nicht, selbst wenn da bei B frei wäre und umgekehrt.
    Wenn das nicht so wäre, wäre es ja recht simpel umzusetzen.
    Oder übersehe ich da gerade was?
    Bin mit den englischen Maker-Begriffen nicht so ganz vertraut ^^

  9. #9
    Jetzt bin ich erst recht verwirrt. Wenn es sein kann, dass beim Spiegelbild ein Hindernis ist und bei der Spielfigur nicht, dann passt sein ganzer Code nicht, weil dieser Umstand nicht berücksichtigt wird.

  10. #10

    Users Awaiting Email Confirmation

    Danke für die ganzen Antworten und Ideen .

    Also worauf das ganze hinauslaufen soll ist, dass ich versuche, mit Events ein kleines Interface auf der Map darzustellen. Ich würde das ja mit Pictures machen aber die sind begrenzt und mit dem Resource Hacker bin ich leider zu ungeschickt und auch nicht wirklich fähig, die Anzahl der Bilder in die Höhe zu schrauben.
    Das Interface soll sich halt genau mit dem Helden mitbewegen, damit das quasi so eine Art "Rahmen" am unteren Bildschirmrand zieht.

    @ Alle: Das Problem ist teilweise genau umgekehrt. Der Spieler läuft gegen eine Wand. Das bedeutet für das System, dass ich afaik ein Move Event in die Richtung ausgelöst habe. Das wiederum führt dazu, dass sich das Spiegelbild bewegt (es bekommt ja das Signal durch das Move Event), obwohl der Spieler aber durch ein Hindernis die Bewegung tatsächlich gar nicht ausführen kann. Deswegen ist der Fall auch egal, ob das Spiegelbild irgendwo hängenbleibt, das wird später sowieso auf Phasing Mode ON und Above Hero Layer gesetzt. Es geht wirklich nur darum, dass sich das Spiegelbild oder besser dann das Interface später nicht bewegen darf, wenn ich als Spieler an einem Hindernis stehe und versuche, quasi in das HIndernis zu laufen. Ob beim Spiegelbild ein Hindernis ist oder nicht, ist erst einmal völlig irrelevant ^^.

    @Leana: Die Ausführung der Bewegung ist ja von 2 Sachen abhängig. Einmal, welche Taste ich gedrückt habe, damit auch die richtige Bewegung ausgeführt wird und dann wiederum, ob sich beim Spieler ein Hindernis befindet und er die Bewegung quasi gar nicht richtig ausführen kann. Deshalb habe ich das auch so geschachtelt gemacht, weil ich genau genommen gar nicht vorher weiß, ob sich an besagter Stelle gerade ein Hindernis befindet oder nicht.
    Und mit "Proceed with Movement" ergibt sich leider das Problem (so wie es noch derzeit ist), dass das nur funktioniert, wenn die beiden Move Events zeitgleich starten. Und wegen dem Herumgerechne oder den Waits, gelingt das leider irgendwie nicht :S

    @ Eddy131: Das mit dem Charakter verstehe ich leider gar nicht ^^ Dann ist die Figur aber dennoch ein Event oder? Würden sich daraus aber nicht die gleichen Probleme wie jetzt ergeben?

    @ BDraw: Ich habe auch die Vermutung das es an den 0.1 Waits liegt aber 0.0 Waits bringen ja leider auch keine Besserung. Im Gegenteil, da kommt der Code einfach nicht hinterher, weswegen 0.1s quasi schon das Minimum darstellt.
    Der Gedanke mit der Terrain - ID kam mir auch, aber da weiß ich auch nicht genau, ob ich am Ende dann nicht wieder dabei lande, das sich das System dann quasi aufhängt oder einfach nicht hinterher kommt.

    Nochmal Danke für die Hilfen und Ideen ^^

    Edit: Also unter Nutzung von Terrain - IDs klappt das mit der Geschwindigkeit einwandfrei. Danke dafür nochmal an BDraw.
    Jedoch bewegt sich mein Held und das Spiegelbild immer 2 Felder in die jeweilige Richtung und ich leider keine schlüssige Idee habe. Also vielleicht, weil sich der Spieler mit der Tasteneingabe ja von Hause aus in die Richtung bewegt. Dann müsste das aber theoretisch nur bei links und rechts passieren. Die Figuren laufen aber auch immer 2 Felder wenn man nach oben-rechts bzw. unten-links läuft. Die Kollision will mir aber auch mit den Terrain - IDs nicht gelingen.

    MfG Draegor

    Geändert von Draegor (22.03.2016 um 22:38 Uhr)

  11. #11
    Da du ja erst nach dem Move-Event der Spielfigur weißt, ob diese sich bewegt hat oder nicht, geht es nicht ohne kleine Verzögerung. Ich würde alles in einen CE packen, weil man sich dadurch schon mal unnötige Abfragen spart (z.B. die Abfrage im anderen CE, welche Taste gedrückt wurde) und die kosten ja auch Zeit. Und die Prüfung, ob die Spielfigur sich bewegt hat, würde ich nach dem Speichern der aktuellen Position durchführen. Falls aktuelle Position != alter Position, dann Spiegelbild nachführen, ansonsten passiert nichts. Ich denke, die Verzögerung ist auf diese Weise so gering, dass man sie (fast) nicht bemerkt.

  12. #12
    Also, wie ich das jetzt verstanden habe: Du willst am unteren Bildschirmrand quasi eine Grafik einblenden die Permanent (vom Bildschirm, nicht der Map, aus gesehen) auf der gleichen Stelle steht.
    Dafür möchtest du aber nicht die Makereigene Grafikanzeige nutzen, weil die irgendwie beschränkt ist und du die Anzahl der Möglichen Objekte schon ausgereizt hast.
    Soweit stimmig?

    Was ich meinte ist, dass du die Grafik deines Helden mit dem erweiterst, was du anzeigen lassen möchtest.
    Der Held kann ja unendlich groß oder klein werden.
    Nimm dann einfach eine Grafik, die Bildschirmfüllend ist, setze den Helden wie gewohnt in die Mitte und dein Interface dahin, wo es sein soll und den Rest lass transparent.
    Wenn sich das Interface ändert (ich weiß ja nicht, was genau du da anzeigen lassen möchtest), dann änderst du einfach die Grafik des Helden zu einer, wo das angepasste Interface angezeigt ist.
    Du müsstest nur darauf achten, dass der Held sich immer exakt in der Mitte des Bildschirms befindet, sonst läuft dein Interface mit.
    Also Karten immer so groß machen, das man mit der Figur - und damit mit dem Bildschirm - nicht an den Rand der Maps kommt.

    Ob das die Performanteste, einfachste oder sonstwie beste Methode ist, weiß ich nicht.
    Sie müsste aber funktionieren, wenn du dich an die Einschränkungen hältst.
    Mit Grafiken arbeiten wäre hier meine erste Wahl, aber das geht bei dir ja scheinbar nicht.

    So, ich hoffe das war jetzt verständlicher und hat dir geholfen

Berechtigungen

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