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.

---

Zitat:

---

Original von bubblebobble:
Das ist natürlich sehr oldschool!
Alpha ist aber nicht notwendigerweise für Transparenz Effekte da, sondern vor allem kann man Objekte mit Antialiasing auf den Hintergrund blitten, was ein sehr schönes Bweiches Bild ergibt, man hat also keine Treppchen mehr bei vordergrundobjekten, ähnlich wie Pixelfonts vs. Antialiased Fonts.
Aber auch schatten lassen sich damit gut machen, oder, wenn man die entsprechenden Blit routinen schreibt, auch Beleuchtung etc.
Allerdings brauchst du auf jedenfall 16 oder 24 bit screens.

---

Zitat:

---

Du bist der sache schon näher, aber ignorierst ziemlich hartnäckig was ich versuche sei mehreren Posts zu vermitteln. Vielleicht drücke ich mich nicht klar genug aus, ist aber auch schwierig ohne Grafiken.

---

Zitat:

---

Ich habe mir jetzt aber die Ultimative Lösung ausgedacht, mit der Landschaften auch Hügel und beliebig hohe Objekte haben können, und man beim Refreshen trotzdem effizient bleibt.
Dazu muss ich aber ein paar Grafiken machen.
Grundsätzlich ist es aber so, wie ich weiter oben beschrieben habe, aber das auffinden der neu zu zeichnenden Objekte wird effizienter.

---

Zitat:

---

Original von whose:

Genau, Du hasts im Grunde erfaßt. Und dabei spielt es keine Rolle, welche Größe z.B. das Gebäude aktuell hat, da Du diese Größe in die Berechnung der Überdeckung aktuell mit hinein nehmen kannst. Die Größen ändern sich ja nicht mitten im Zeichenvorgang sondern schon davor. Also kannst Du auch auf die Größen zurückgreifen bei der Berechnung, selbst für die Ermittlung des betroffenen Tiles. Statt fester Werte nimmst Du einfach die tatsächlichen Werte des Objekts.

Grüße

---

Zitat:

---

Original von whose:

Zitat:

---

Original von Reth:
Hm, jetzt hab ich mein Hauptproblem (?) wieder entdeckt.
Ich habe meine Animationsklassen so entworfen, dass sie mit flexiblen Framegrößen umgehen können und ihre aktuelle Höhe und Breite kennen.
Es gibt dazu noch eine maximale Höhe und Breite.
Eine Animation kann aus beliebig vielen Frames mit unterschiedlichen Größen bestehen.

Das macht das Ganze nicht unbedingt leichter (im Hinblick auf Umsetzung von Pixelkoordinaten auf Arraykoordinaten).

Hm, muss ich mir nochmal reinziehen.

---

Nein, im Grunde ists auch dann genau das Gleiche. Du nimmst als Berechnungsgrundlage halt die dann aktuellen Größen (Position X/Y, Höhe und Breite des Animationsframes) und weißt, was so alles überdeckt wird davon.

---

Zitat:

---

Unter anderem erfährst Du dann auch, ob dieses Objekt bereits in einem Damage-Bereich (ClipRect später!) liegt und ob es da noch ganz reinpaßt. Paßts nicht mehr ganz rein, ists an der Zeit, den Damage-Bereich zu vergößern

Nimm Dir dazu auch mal Michas, Thilos und meinen Rat zu Herzen, informier Dich über Sinn und Zweck von ClipRects. Wenn Du diese ClipRects in ihrer Größe so berechnest, daß alle Objekte auf ihren jeweiligen Positionen und in ihren aktuellen Größen da reinpassen, kannst Du für die Ermittlung der betroffenen Tiles (also die unterste Ebene!) sogar ganz simpel die ClipRect-Koordinaten nehmen.

---

Zitat:

---

Die Tiles müssen im Refresh dann ja als erstes gezeichnet werden und eben auch durch Clipping beim Zeichnen begrenzt werden, damit nicht am Refresh beteiligte Objekte unbehelligt bleiben.

---

Zitat:

---

Original von whose:

8 ist Binär 00000111.

---

Zitat:

---

Und was passiert bei, sagen wir, 12/8? Das ist 1.5. Wie wird das gerundet?

Das ist implementierungsabhängig Je nach Compiler/Typ der Operanden geht das in die Hose und Du bekommst 2 statt 1. Richtig kritisch wirds ab 13...

---

Zitat:

---

Das bedeutet, es wird immer automatisch zum richtigen Index umgeschalten, wenn Deine Tiles 8 Pixel breit sind.

Mit dem Verfahren oben bekommst Du immer die (fast) korrekt für unsere Zwecke gerundete Ganzzahl. Bei x=9 käme dabei 2 raus, was dem richtigen Index+1 (!) entspricht. Bei x=17 gäbe das 3, was ja auch richtig ist, da die Koordinate 17 das dritte Tile berührt (immer davon ausgegangen, daß ein Tile 8 Pixel groß ist). Einziger Fallstrick hierbei ist die in C/C++ verwendete Indexierung, die nun einmal bei 0 beginnt und nicht bei 1. Daher mußt Du das Ergebnis um 1 verringern, um den korrekten Index im Array zu erhalten.

---

Zitat:

---

Original von whose:
Zu dem Thema ist auf gamedev.net der Artikel, von dem ich sprach. Ich weiß jetzt nicht mehr genau, welcher das war, aber da gings auch um Hextiles und deren Anordnung in einem 2D-Array. Wenn ich mich recht erinnere, war das so gelöst, daß die Tiles einer Reihe auch in die entsprechende Reihe des 2D-Arrays eingetragen wurden und bei Berechnungen/Zeichenoperationen der Zeichen-Offset berücksichtigt wurde.

---

Zitat:

---

Original von whose:

Zitat:

---

Original von Reth:
Die Damagelist wird dann Layer für Layer komplett neu gezeichnet (in dem einen Artikel auf gamedev.net steht glaub, dass erst alle Layer eines Bereiches gezeichnet werden, bevor die des anderen Bereiches drankommen, um Abschneiden von Objekten zu verhindern. Also entweder hab ich in dem Artikel was missverstanden oder passiert dadurch doch genau das: Objekte können abgeschnitten werden.

---

Es kann Dir passieren, daß Objekte "aus Versehen" von Objekten einer unteren Ebene übermalt werden, wenn Du die Reihenfolge nicht korrekt einhältst. Das kann so weit gehen, daß ein neu zu zeichnendes Tile ein gerade neu gezeichnetes Objekt eines Nachbartiles übermalt. Das wäre dann abgeschnitten.

---

Zitat:

---

(char angenommen) Es wird mit 11111000 UND-verknüpft.

---

Zitat:

---

Der Gag dabei ist die vorherige Addition von 7. Mit der Mimik erreichst Du, daß Du nur ganze Zahlen erhältst, die durch 8 teilbar sind. Wenn Du z.B. ein Objekt auf der Koordinate x = 9 liegen hast, muß diese Koordinate für die Umrechnung in einen Array-Index irgendwie auf "ganze" Indizes erweitert werden. Mit dem Krempel von oben käme dann (9 + 7) = 16 heraus, das &~8 hätte darauf keinen Einfluß. 16 läßt sich gut durch 8 teilen...

---

Zitat:

---

Original von Micha1701:
Hi!

Ich hab in Realms of Power ebenfalls Tiles verwendet. Und diese überlagern meist das darüber liegende Tile (z.B. Berge oder auch Einheiten). Damit ich jetzt nicht alles neu zeichnen mußte, hab ich einfach den zu bemalenden Bereich beschränkt. Dazu einfach mit Region() und InstallClipRegion() den Bereich beschränkt. Dann mußte ich nur den Teil um das zu ändernde Tile neu zeichnen. Alles andere wird dann ja nicht "zerstört".

Vielleicht hilft Dir das weiter.
--
Micha

http://www.Silicon-Wizards.com

---

Zitat:

---

Original von whose:
@Reth:

Bekannt sein muß dafür die Anzahl der X-Koordinaten pro Zeile.

Dann ist Eintrag(x, y): Array[y * x]

Simpel, oder?

---

Zitat:

---

2D-Arrays sind kein wirkliches Geschwindigkeitsproblem. Der Compiler arbeitet mit 2D-Arrays genau so. Du kannst also beruhigt 2D-Arrays verwenden.

---

Zitat:

---

Worauf Du unbedingt achten mußt ist, so wenig Zeichenvorgänge wie möglich pro Frame zu erreichen und nicht zu lange durch die Koordinatenberechnungen zu laufen.

---

Zitat:

---

Ich kann Dir auch gern mal Sourcecode zu meiner Sprite-Engine schicken. Die ist zwar derzeit nicht besonders komplex, aber läuft butterweich auf allen Maschinen und zeichnet nur so viel, wie unbedingt nötig ist (also bewegte Objekte vor fixem Tile-Hintergrund, der fixe Hintergrund muß unter jedem Sprite dann ja restauriert werden). Da habe ich sogar noch wesentlich komplizierter gearbeitet, als nötig wäre. Interessanterweise läuft die sogar mittels OS-Doublebuffering, also mit der ChangeScreenBuffer()-Mimik. Das scheint ürigens die einzige Methode zu sein, die sowohl unter CGFX als auch P96 rasterstrahlsynchron läuft.

---

Zitat:

---

Einziger Nachteil bei dieser Engine ist bisher nur, daß die noch nicht mit überlappenden Sprites klarkommt, da wird der Hintergrund noch doppelt gezeichnet unnötigerweise.

---

Zitat:

---

(Edit) Vielleicht fällts Dir leichter, wenn Du Dir die Grafik vorstellst wie übereinandergelegte Overhead-Folien. Für jedes Objekt eine eigene Folie, die Hintergrund-Tiles bilden eine einzige Folie. Je nachdem, wie Du die "Folien" der Objekte verschiebst, sind ein oder mehrere Tiles auf der Hintergrund-"Folie" überdeckt.

---

Zitat:

---

Die Ermittlung der überdeckten Bereiche ist verhältnismäßig einfach:

+---------------------------- X
| +--+
| | |
| +--+
|
|
|
|
|
Y

Hier bildet jeder "Strich" auf den Achsen die Position eines Hintergrund-Tiles ab.

Das eingezeichnete Objekt ist 4*3 "Tiles" groß. Wenn jedes Tile größer als 1 Pixel ist, kann es zu Überschneidungen zwischen Tile-Array- und Objektkoordinaten kommen (also unvollständige Überdeckung, weil eine Abbildung der Objekt-Koordinaten in Pixeln auf den Tile-Array-Index keine ganzzahlige Angelegenheit mehr ist, sobald ein Tile 2 Pixel pro Richtung groß ist. Eine Objekt-Koordinate in Pixeln kann dann einem "halben" Tile entsprechen).

Man muß also in "ganzen Tiles" den Bereich ermitteln, den das Objekt überdeckt.

Dieser Bereich ermittelt sich wie folgt, wenn die Tiles 8*8 Pixel groß sind:

Startposition des Bereiches in X: (ObjectPosX + 7) &~ 8
Startposition des Bereiches in Y: (ObjectPosY + 7) &~ 8

Anzahl "ganze" Tiles in X, die das Objekt überdeckt: (((ObjectPosX + ObjectSizeX) + 7) &~ 8 ) - Startposition in X

Anzahl "ganze" Tiles in Y, die das Objekt überdeckt: (((ObjectPosY + ObjectSizeY) + 7) &~ 8 ) - Startposition in Y

Die ermittelten Werte sind Indizes innerhalb des Tile-Arrays, also "ganze" Tiles (!). Damit weißt Du, welche Tiles innerhalb des Arrays neu gezeichnet werden müssen. Das funktioniert genauso bei hexagonalen Tiles, vorausgesetzt, Du bekommst die Koordinaten in ein 2D-Array transformiert.

---

Zitat:

---

In Deinem Fall ist das Ganze sogar noch ein wenig simpler, fällt mir gerade auf. Bei Deiner Grafik kann ein Objekt maximal 3 Tiles überdecken, da läßt sich das bestimmt noch stark vereinfachen (also nur mit den Objektkoordinaten arbeiten, die Größe des Objekts spielt dann wohl nur eine sehr untergeordnete Rolle).

---

Zitat:

---

Original von whose:

Zitat:

---

Original von Reth:
2. Was mache ich mit Objekten, die mehr als ein Tile überdecken? Denke mir dass so, dass deren linke untere Ecke (wenn man immer von oben links nach unten rechts blittet) ausschlaggebend ist. Über welchem Tile diese liegt, in dessen Layerliste wird das Objekt eingetragen.

---

Prinzipiell eine gute Idee... so kannst Du auch mehrere überlagernde Objekte relativ simpel verwalten, in diesem Fall über die Liste des Tiles. Achte nur drauf, daß Du dadurch nicht zu viele Blits fabrizierst (also nicht platt alles neu zeichnen, auch wenns nicht nötig ist), sonst wirds mächtig langsam bei vielen Überdeckungen.

Grüße

---

Zitat:

---

Original von Holger:
Entweder Du verschiebst die Funktionalität des Umwandelns in Standard-Gadgetstrukturen in die Buttons, etc. Oder Du verlagerst diese Funktionalität in eine dritte Klasse. Letzteres ist die sauberste Methode.
Solche Operationen können auch vom Compiler transparent eingefügt werden, d.h. die Benutzung bleibt unkompliziert.

class Fenster
{
...
public:
void add(StandardGadget g);
}

class MyButton
{
//optional: friend MyButton
}

class MyButtonStandardGadgetFactory
{
public:
MyButtonStandardGadgetFactory(MyButton b);
operator StandardGadget();
}

// ...

MyButton example;
Fenster fenster;
fenster.add(example);

So in etwa.

mfg

PS: Hoffe natürlich auch, daß Du (und alle anderen) ein schönes Fest hatten!

---

Zitat:

---

Aber was macht man denn typischerweise mit solchen Events? Du versuchst herauszufinden, welcher Button/Menüpunkt betroffen ist, und ordnest ihm die zugehörige Aktion zu. Das kann über IDs und ellenlangen Switch-Statements oder halt über Pointer auf die zugehörige Aktion machen.
Mehrere Beobachter an ein Fenster zu hängen, die dann jeder für sich herausfinden müssen, ob das jeweilige Event für sie relevant ist, sind nicht nur umständlich zu programmieren, sondern auch Resourcenverschwendung. Intuition teilt Dir bereits mit, welches Gadget betroffen ist, das Gadget bietet mit dem UserData-Eintrag bereit eine Möglichkeit der Zuordnung zum zughörigen Anwendungobjekt, warum willst Du diese Möglichkeiten nicht nutzen?
Mehrere Beobachter für ein- und dieselbe Funktion sind eher die Ausnahme.

---