[RM2K3] Spiegelbild zum Spieler bewegt sich zu langsam

Hallo miteinander ^^.

Ich habe folgendes Problem: Ich möchte das sich ein Event ("Spiegelbild") genauso bewegt wie der Spieler es tut. Das habe ich bereits so umgesetzt bekommen. Jedoch bewegte sich das Event auch, wenn der Spieler gegen ein Hindernis läuft und sich somit gar nicht fortbewegt hat. Auch das habe ich geschafft, zu klären.

Jedoch habe ich nun das Problem, dass das Spiegelbild einen Bruchteil langsamer ist als meine Spielfigur. Und auch so viel langsamer, dass man es als Spieler mitbekommt.

Im folgenden zu meinem Code: Er besteht hauptsächlich aus 3 Common Events die auf Parallel Process laufen und sowohl die Bewegung, als auch Kollisionsabfrage steuern.

1.) Bewegung für den Spieler
2.) Bewegung für das Spiegelbild
3.) Rechner für die X - Position

Anhang 23219 Anhang 23218 Anhang 23220

Ich habe schon etliche Varianten mit Switches und Variablen als Kontrolleure ausprobiert und auch die Forks schon verschieden geschachtelt, aber das Spiegelbild hinkt immer noch etwas hinterher. Liegt vielleicht auch den Waits aber ich finde keine Lösung mehr, den Code noch weiter zu beschleunigen.
Vielleicht kann mir ja einer von euch helfen ;)

MfG Draegor

Ich habe zwar gerade keinen RPG-Maker 2003 zur Hand um es zu testen, aber ich kann schon so sehen, dass deine Lösung Probleme hat.
Versuch es einmal wie folgt:

Benutze 2 Events mit Parallel Processing

Event 1:

Code:

---

key Input Proc: [001 BewegungsRichtung]
Wait: 0.1 Sec

---

^ Dieses Event speichert, in welche Richtung sich der Spieler gerade bewegt.

Event 2:

Code:

---

Variable Oper: [002 Neue X Position] Set, Hero X Coord
Branch if Var [002 Neue X Position] != [003 Alte X Position]
    Branch if Var [001 BewegungsRichtung] is 1
        Move Event: ...
    End
    Branch if Var [001 BewegungsRichtung] is 2
        Move Event: ...
    End
    ... "Und soweiter für alle anderen Richtungen"
End
Variable Oper: [002 Neue X Position] Set, [002 Alte X Position]
Wait: 0.1 Sec

---

^ Dieses Event überprüft über den Vergleich der derzeitigen X-Koordinate mit der vorherigen X-Koordinate, ob sich der Spieler überhaupt bewegt hat. Falls der Spieler sich bewegt hat wird die Bewegung anhand der Variable BewegungsRichtung nachgespielt.
Alternativ kannst du dir die Variable BewegungsRichtung auch sparen und die Richtung einfach anhand der Differenz zwischen der neuen und alten Position berechnen.

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.

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

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?

@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

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.

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

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.

Zitat:

---

Zitat von Leana

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 ^^

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.

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

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.

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 ;)

Zitat:

---

Zitat von Eddy131

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.

---

Kurze Randinfo: Nein, kann er nicht, das geht erst ab dem XP aufwärts. Der 2k/3 hat für jedes Charset eine fixe Größe von 24x32px. Alles darüber benötigt mehrere Charsets, die aber Synchron zu bewegen führt zu exakt dem Problem, was Draegor ja eh schon hat.

@Draegor:
Wie Leana schon richtig angemerkt hat: Eine minimale Verzögerung gibt es so oder so, wenn du abfragst, ob der Held sich bewegt hat. Das präziseste wäre da die Pixelkoordinaten abzufragen, was aber Feintuning braucht, damit die Abfrage nicht zu schnell wird (und eben genau darin mündet, dass das Event sich zu weit bewegt). Die einzige komplett, 100% synchrone Variante wäre das direkt in die Heldensteuerung zu integrieren, was aber eben eine Kollisionsabfrage voraussetzt. Bzgl. der Performance: Reine Rechenoperationen bekommt der Maker eigentlich sehr schnell hin, von der Seite aus gäbe es kein Problem. Schwierig wird es immer dann, wenn du auf einmal viele parallele Prozesse gleichzeitig laufen hast (die evtl. auch noch ineinandergreifen) oder wenn da waits drin sind, da damit merkliche Pausen entstehen. Ein wait mit 0.0 merkt man eigentlich nicht, 2x0.0 kann schon dazu führen, dass man als Spieler was mitbekommt, wenn davon Bewegungen abhängen. (0.0 "Maker-Sekunden" = 1/6*0.1s = 1/60s, 2x0.0 = 1/30s. Afaik kann das Auge etwa 1/60s wahrnehmen?)
Von proceed with movement würde ich auf alle Fälle die Finger lassen - zum Einen sorgt der Befehl nicht dafür, dass dinge sich gleich schnell oder gleichzeitig bewegen, er hält bloß alles an, bis alle aktuellen move events fertig ausgeführt wurden. Zum Anderen kann eben das dazu führen, dass, im Falle eines Hinterherhinkens des Spiegelbilds, der Code blockiert wird, der den Helden bewegt, was sich aus Spielersicht darin äußert, dass man scheinbar relativ zufällig die Figur manchmal (oft) nicht bewegen kann.

Aber ganz ehrlich, bei dem Aufwand würde ich an deiner Stelle echt überlegen, Pictures zu nehmen. Der Aufwand steht sonst echt in keinem Verhältnis, gerade für sowas wie ein Interface. Schau mal wenn der Maker wieder bei Steam im Angebot ist, die Version hat inzwischen deutlich mehr als die 20 Pictures die es früher nur gab. Und wenn du nicht gerade ein komplett Picture-basiertes Menü mit drölfzig Ziffern hast kommst du mit 50 Pics normalerweise auch gut aus, wenn du etwas haushaltest.
Dazu kommt vor allem dass, wenn ich dich richtig verstehe von wegen "Rahmen" und so, es gar nicht um die Bewegung des Helden geht, sondern um die der Kamera - und die kann man nicht ohne weiteres abfragen. Am Maprand würdest du also in noch mehr Probleme laufen, sofern du nicht dann ein eigenes Scrollingsystem einbaust oder konstant auch noch Map- mit Screenkoordinaten vergleichst. Wenn du aber einfach ein Picture nehmen könntest und gut ist würde ich mir den Aufwand schenken.

Zitat:

---

Zitat von BDraw

Kurze Randinfo: Nein, kann er nicht, das geht erst ab dem XP aufwärts. Der 2k/3 hat für jedes Charset eine fixe Größe von 24x32px. Alles darüber benötigt mehrere Charsets, die aber Synchron zu bewegen führt zu exakt dem Problem, was Draegor ja eh schon hat.

---

Oh, danke für die Info.
Das wusste ich tatsächlich nicht, dachte dass mit den Variablen größen gab es schon vorher, immerhin gibt es ja auch bei den Spielen mit den 2k/3 Makern größere Gegner-Grafiken auf der Map (?), daher ging ich davon aus, dass das auch für den Helden gelten müsste.

Zitat:

---

Zitat von BDraw

Wenn du aber einfach ein Picture nehmen könntest und gut ist würde ich mir den Aufwand schenken.

---

Ganz meine Rede :A

Zitat:

---

Zitat von Eddy131

Oh, danke für die Info.
Das wusste ich tatsächlich nicht, dachte dass mit den Variablen größen gab es schon vorher, immerhin gibt es ja auch bei den Spielen mit den 2k/3 Makern größere Gegner-Grafiken auf der Map (?), daher ging ich davon aus, dass das auch für den Helden gelten müsste.

---

Ne, das ist bei allen Charsets der Fall. Man kann theoretisch natürlich größere Sachen aus mehreren Charsets zusammenstückeln - ob das jetzt ein Gegner, ein Baum oder ein Haus ist, ist ja egal - somit wie sich beide Events synchron frei (d.h. bspw. außerhalb einer Cutscene, wo die Bewegungen ja 100% vorgegeben sind) bewegen sollen wird es bloß immer etwas knifflig.

Charsets sind immer exakt gleich aufgebaut: ein Char hat 24x32px, ein Charset für einen Char hat damit immer 72x128px (3 Frames * 4 Richtungen) und ein ganzes Charset wie man es importiert (für insg. 8 Charaktere; 4 oben, 4 unten) 288x256px. Alles darunter nimmt der Maker gar nicht erst an. Die wiederum werden für Helden, Map-Events und Vehicles gleichermaßen verwendet.

Zitat:

---

Zitat von BDraw

Aber ganz ehrlich, bei dem Aufwand würde ich an deiner Stelle echt überlegen, Pictures zu nehmen. Der Aufwand steht sonst echt in keinem Verhältnis, gerade für sowas wie ein Interface. Schau mal wenn der Maker wieder bei Steam im Angebot ist, die Version hat inzwischen deutlich mehr als die 20 Pictures die es früher nur gab. Und wenn du nicht gerade ein komplett Picture-basiertes Menü mit drölfzig Ziffern hast kommst du mit 50 Pics normalerweise auch gut aus, wenn du etwas haushaltest.
Dazu kommt vor allem dass, wenn ich dich richtig verstehe von wegen "Rahmen" und so, es gar nicht um die Bewegung des Helden geht, sondern um die der Kamera - und die kann man nicht ohne weiteres abfragen. Am Maprand würdest du also in noch mehr Probleme laufen, sofern du nicht dann ein eigenes Scrollingsystem einbaust oder konstant auch noch Map- mit Screenkoordinaten vergleichst. Wenn du aber einfach ein Picture nehmen könntest und gut ist würde ich mir den Aufwand schenken.

---

Inwiefern ist der Aufwand geringer, wenn er anstatt eines Events ein Picture benutzt? Ob man ein Event nachführt oder ein Picture, ist doch vom Ablauf das Gleiche? Und das Problem mit dem Maprand hat er doch immer. Schließlich soll diese Anzeige bestimmt auch weiterhin sichtbar sein, wenn die Spielfigur dort entlang läuft.

Zitat:

---

Zitat von Leana

Inwiefern ist der Aufwand geringer, wenn er anstatt eines Events ein Picture benutzt? Ob man ein Event nachführt oder ein Picture, ist doch vom Ablauf das Gleiche? Und das Problem mit dem Maprand hat er doch immer. Schließlich soll diese Anzeige bestimmt auch weiterhin sichtbar sein, wenn die Spielfigur dort entlang läuft.

---

Zitat:

---

Zitat von Draegor

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.

---

So wie ich es verstanden habe, versucht Draegor, einfach ein Interface (/Rahmen/Menüteil/...) irgendwo anzuzeigen, welches sich natürlich mit dem Bildausschnitt mitbewegen soll. Das ist aber genau das, was ein Picture von Haus aus tut, ganz ohne Abfragen, etc., sofern man nicht "Scroll with Map" anklickt. Das Picture hat seinen Platz dann fest auf der Kamera sozusagen und ist von der Map bzw. was der Char auf dieser treibt völlig losgelöst. Um den selben Effekt, der in jedem Show Picture-Befehl von vorn herein drin ist, aber mit Charsets hinzubekommen, muss man es manuell passend zur Kamera bewegen, was ein relativ großer Aufwand ist.

EDIT: gerade nochmal geschaut, der legale 2k3 unterstützt bis zu 1000 Pictures und kostet momentan 19,99€.

Aber Draegor spricht doch die ganze Zeit davon, dass das Interface dem Helden folgen soll und nicht, dass es "fest" an einer Stelle bleiben soll. Ich denke, das mit dem "Rahmen" ist eher so gemeint, dass sich das Interface halt immer am unteren Bildschirm hin- und herbewegen soll. Denn der Held macht ja auch stets eine Bewegung in der X-Richtung, auch wenn die Auf.- bzw. Ab-Taste gedrückt wurde.