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.

---

Zitat:

---

Original von Holger:
Du denkst zu sehr in den alten AmigaOS-Strukturen, mit denen man sich eigentlich lieber nicht beschäftigen sollte. Was zeichnet denn in der Praxis z.B. einen Button aus? Einen Label-String und/oder ein Icon und im Falle des Label-Strings evtl. ein markierter Buchstabe für den Short-Cut. Dimension und Position sind Sache des Layouts, interessiert mich als Anwendungsprogrammierer überhaupt nicht und Flags bei einem Button? Kenne ich keine. Sicher, in den Gadget-Strukturen gibt es allgemeine Flags für Intuition, aber der Wert ist für jeden Button identisch.
Rahmen und Füllfarbe sollten nur im absoluten Ausnahmefall von denen einer normalen Buttons abweichen...
Ähnliches bei einer Checkbox, gleiche Attribute, plus einem boolschen Selected-Attribut.

Versuch Dich an der Praxis desjenigen, der die Komponenten hinterher benutzt zu orientieren. Was braucht er wirklich:
Button erzeugen, Text/Icon setzen
eindeutige ID zuordnen für die auszuführende Aktion, übersetzte String im locale-catalog, Hilfethemen.

Ein Gadget besteht von der Logik her wirklich aus fast nichts. Seiner Identität, Position in der Gadget-Hierarchie, den View-Optionen und dem Datenmodell.
Man beachte, daß mehrere Gagdets sich ein View-Setup und/oder ein Datenmodell teilen können. Im Gadget direkt sind nur die nicht gemeinsam nutzbaren Eigenschaften enthalten.

---