C++ code:

---

IntuiMSGReceiver::receive(struct MsgPort *Port)
{
    struct IntuiMessage *msg = (struct IntuiMessage *) GetMsg(Port);
    // reply und verarbeiten
}

---

Zitat:

---

Original von Holger:
Nein, erzeuge einfach exakt so viele Objekte, wie Du es jetzt auch schon tust. Ist jedes tile ein einzelnes Objekt -> ok, dann ist jedes tile auch ein eigenständiger painter. Gibt es kein tile Objekt, sondern ein Background-Objekt, das alle tiles als array o.ä. verwaltet -> ok dann wird dieses Background-Objekt zum painter.

---

Zitat:

---

So soll auch auf dem Window auch nur in Ausnahmefällen ein anderer Painter gesetzt werden. Normalerweise stellst Du ja immer das Gleiche dar, ein Level, eine Statusanzeige, ein paar Konfigurationsmögichkeiten, etc. Nur der Zustand dieser Objekte ändert sich. Und wenn das passiert, wird lediglich dem Fenster mitgeteilt, daß ein Refresh gewünscht ist. Der Painter bleibt derselbe.

---

Zitat:

---

Original von Holger:
Ne, ne, is schon so, wie Du denkst. setPainter() macht das, was Du von einer set... Methode erwarten würdest. Ala

code:

---

windowPainter=p;
requestRefresh();

---

---

Zitat:

---

Was willst Du sammeln? Du hast Objekte, die einen Status haben, und wenn der sich ändert mußt Du einen Refresh triggern, z.B. mit einer Methode ala requestRefresh(); auf dem Fenster (die Du natürlich schreiben mußt...), funktional vergleichbar mit repaint() in Java. Optional sollte man auch einen Bereich übergeben können, der dann zur damagedRegion des Layers hinzugefügt werden kann.

---

code:

---

painter.blit(...);
window.requestRefresh();
...
// im Painter
rastPort.blit(...);

---

Zitat:

---

Original von Holger:

Hmm, ich versuche ja auch immer offen gegenüber allem zu sein, und GoldEd scheint wirklich sehr viele Features zu haben.
Aber allein das Positionieren des Cursors nach einer Einfügeoperation ist für mich ein Ausschlußkriterium. So könnte ich nie arbeiten, und wenn keiner eine Konfigurationsmöglichkeit kennt...
Und daß ist ja nicht die einzige Eigenheit, bei der GoldEd polarisierend auf die User wirkt.

---

Zitat:

---

Original von schluckebier:

Z.B. kommt oben direkt unterhalb der Symbole immer ein weißes Feld, in dem der Dateiname steht. Finde ich vollkommen unnütz, da der Dateiname ohnehin im Fensterrahmen steht (und Platzverschwendung ist es obendrein, weil in dieser Zeile sonst nichts steht), bekomme ich aber ums Verrecken nicht weg. Sollte also jemand einen Tipp haben... Falls ich's nicht hinbekomme, muss das Backup von GoldEd 6 halt wieder her. :o)

---

Zitat:

---

Original von Holger:
Zeichenoperationen sind an sich nicht kritisch. Aber RastPort wie Graphics besitzen einen Zustand wie aktuelle Zeichenfarbe, Zeichenmodus, Line Pattern, etc.
Man sollte sicherstellen, daß zu Beginn eines Refreshs ein definierter Ausgangszustand herrscht. Das kann man erreichen, in dem man immer eine Kopie resp. neuen RastPort herausgibt oder alle Attribute zurücksetzt.

...

Deshalb ist eine getRastPort-Methode auf einem Fenster nicht sinnvoll. Dem Fenster sollte die fürs Zeichnen zuständige Instanz bekannt sein, an die es den Refresh delegieren kann.

Vereinfacht so:

C++ code:

---

class Painter
{
  virtual void paint(RastPortObj& rp);
}

class Window
{
  //... bißchen was weggelassen ;)
  public:
    setPainter(Painter& p);
  protected:
    void refresh();
}

Window::refresh()
{
  windowPainter.paint(new RastPortObj(intuiWindow->RastPort));
}

---

---

Zitat:

---

Original von _PAB_:
@rbn:
Und das, was Genesi mit den MorphOS-Entwicklern macht - ist das etwa richtig und unterstützenswert ?
http://morphos.net/

---

Zitat:

---

Original von bubblebobble:

Aber du siehtst jetzt, warum man dazu eigentlich ein paar Grafiken braucht, das wird schnell zu kompliziert in Worte zu fassen, obwohl es eigentlich einfach ist.

---

Zitat:

---

Original von bubblebobble:
Ja, davon gibts noch mehr, aber nichts released und noch nichts programmiert. Nur Studien bis jetzt.

---

Zitat:

---

Ja, Objekte die sich bewegen muss man "umhängen" im Array, aber egal ob das direkt auf dem Tile array ist oder dem "imaginären", rechteckigen Array. Allerdings kann dann ein Objekt auch in mehreren Arrays sein. Aber ich denke der Overhead lohnt sich. Wieviele sich bewegende Objekte planst du denn? Ich meine nicht feststehende Anims, wie z.B. eine wehende Fahne, weil da kann man einfach die Maximum Größe aller AnimFrames angeben und fix lassen.

---

Zitat:

---

Speichern würde ich das ganze in einem dynamischen, eindimensionalen Array pro Rechteck Feld. Das ist also ein Array, was dynamisch erweitert wird, falls es zu klein ist.

---

Zitat:

---

Es wird also nicht zwischen Boden-Tile, stehenden Objekten und beweglichen Objekten unterschieden. Alle sind in der gleichen Struktue gespeichert. Wenn sich ein Objekt bewegt, wird diese eben manipuliert.

---

Zitat:

---

Die Überdeckung ist eigentlich ganze einfach.Grob wird nach ISO Tiles sortiert, also Objekte auf einem ISO Tile weiter vorne sind auch immer im Bild weiter vorne. Objekten innerhalb eines Tiles gehen dann nach Hotspot. Dadruch kann man z'.B. immer och Zäune entlange der Tilegrenzen machen, wo man einmal davor und einmal dahinter stehen kann. Nur mit Hotspot geht das nicht, das funktioniert nur bei punktuellen Objekten wie Bäumen, Figuren etc.

---

Zitat:

---

Bei meiner Methode gibt es aber noch den vorteil, das Tiles höher sein können als andere, ohne mehraufwand. Dadruch lassen sich z.B. sehr hohe Berge machen, sodass die Boden Tiles eigentlich mehrere Tile Ebenen höher liegen (optisch). Gespeichert sind sie aber schon brav auf ihrem Platz im Tile Netz.

---

Zitat:

---

Original von bubblebobble:
@Reth
Ja, der Screenshot ist von meinem Spiel. Die Figur ist allerdings aus einer (sehr viel) älteren Version, als die Landschaft noch gepixelt war. Jetzt ist sie richtig gezeichnet, was mir besser gefällt, obwohl gepixelt auch seinen Charme hat, aber eben old-school aussieht.

---

Zitat:

---

Kurz gesagt: Man baut die Landschaft in Tiles auf, so wie gehabt. Allerdings nimmt man nicht das Tile Array, um herauszufinden welches Object neu gezeichnet werden muss, sondern ein nochmals imaginär darüberliegendes Array, was dann auch Rechteckig sein kann. Das Array enthält dann für alle Raster-Rechtecke die Information, welches Objekt darinliegt. Das kann man in aller Ruhe berechnen, bevor das Spiel los geht. Objekte die sich bewegen müssen natürlich geupdated werden, aber das kostet kaum Zeit, das sind ein paar Bytes verschieden.
Muss ich einen Bereich neu zeichnen (es wird grundsätzlich immer alles neu gezeichnet), lege ich ein ClipRect um diesen Bereich, schaue in welche Rechtecke des Raster-Arrays die Refresh-Region hineinragen, und erhalte sofort alle Objekte, die ich dann stumpfsinnig blitte. Das ist alles.

Vorteil: Schnelles auffinden aller Bilder, die neu geblittet werden müssen, und Objekte können beliebig gross/hoch sein. Auch kann man Hügel machen, sodass Tiles "angehoben" werden. Der Refresh engine ist das völlig egal woher die Bildchen kommen, weil sie nur in das Raster-Array schaut.

---