Grafikausgabe für ein Iso-Game

[Weazle25]

Wie es der Titel schon verrät arbeite ich an einem Iso-Game.
Die Vorbereitungen dafür sind fast abgeschlossen.
Ich weiss nur noch nicht wie ich die Bilder auf den Bildschirm bekommen soll.
Das Problem dabei sind folgende Anforderungen die erfüllt werden müssen:
Betriebssystem: Windows und Linux sowohl 32 als auch 64 Bit.
Bildschirmauflösung: Alle 15 Bit Auflösungen die von der Hardware unterstützt werden im Window- und Fullscreen-Modus.
Sowie ermitteln der verfügbaren Auflösungen.
Das Grafikset stammt von einem anderen Spiel und ist daher fest vorgegeben.
Dadurch das das Grafikset mit 630 Mb (unkomprimiert) sehr gross ist kommt direktes rendern per OpenGL nicht in Frage.
Bleiben also nur 2 Möglichkeiten offen:

1. Jeder Frame wird auf eine Textur gepixelt und dann per OpenGL gerendert.
2. Die Frames werden (per GDI oder ähnlichem) direkt auf den Bildschirm gepixelt.

Variante 2 gefällt mir deutlich besser da mein Laptop schon zu alt ist und ich daher unter Linux kein OpenGL nutzen kann.
SDL kommt auch nicht in Frage da ich schon an vielen Stellen gelesen habe das SDL auf 64 Bit Systemen recht instabil sein soll.
Also wie bringe ich meine Bilder am besten auf den Bildschirm?
Kennt jemand geeignete Tutorials (möglichst deutsch), Units, Komponenten oder Frameworks?


Gruss
Weazle

[corpsman]

Brauchst du wirklich immer alle 650 MB auf einen schlag ?

ich würde auf jeden Fall OpenGL nehmen, mit dem OpenGLControl aus der Komponenten Sammlung bist du zumindest schon mal Plattform unabhängig.
Tutorials auf Deutsch gibt es nicht viele die einzigen die ich kenne sind Hier Wenn du das "Basic" mal hast kann man von da aus sehr gut weiter entwickeln. Ich erstelle so gut wie alle OpenGL Projekte aus diesem Basis Sample

[Weazle25]

Brauchst du wirklich immer alle 650 MB auf einen schlag ?

Ich könnte die Bilder zwar Stück für Stück nachladen aber es würde auch wieder darauf hinaus laufen das schon nach kurzer Zeit wieder die kompletten 630 Mb im Speicher liegen.
Allerdings sind die Bilder hier noch unkomprimiert.
Ausgehend von den original Bildern werde ich aber eine modifizierte RLE-Kompression benutzen die nur zwischen sichtbaren und nicht sichtbaren Pixeln unterscheidet.
So müssen nur die sichtbaren Pixel gespeichert werden und die nicht sichtbaren Pixel werden dann beim zeichnen einfach übersprungen.
Auf diese Weise kann ich die Bilder auf ca. 200-300 Mb drücken und spare sogar noch etwas Rechenleistung ein.

ich würde auf jeden Fall OpenGL nehmen, mit dem OpenGLControl aus der Komponenten Sammlung bist du zumindest schon mal Plattform unabhängig.
Tutorials auf Deutsch gibt es nicht viele die einzigen die ich kenne sind Hier Wenn du das "Basic" mal hast kann man von da aus sehr gut weiter entwickeln. Ich erstelle so gut wie alle OpenGL Projekte aus diesem Basis Sample

DelphiGL kannte ich schon und deine clear_engine hat mir auch ein grosses Stück weiter geholfen.
Allerdings ist die Hardware-Unterstützung unter Linux nicht unbedingt die Beste so das ich auf ubuntu 8.10 fest hänge da ich sonst keine Hardware-Beschleunigung habe.
Auf ubuntu 9.10 habe ich nur Mesa-Treiber und mein Laptop läuft in weniger als 15 Minuten heiss und rebootet.
Bei ubuntu 10.X habe ich weder Hardware-Treiber noch Mesa so das ich es erst gar nicht zum laufen bekomme.
Reines Rendern per OpenGL und das damit verbundene laden aller Grafiken in den VRAM kommt auch nicht in Frage.
Denn die 630 Mb beziehen sich auf nicht-optimierte Grafiken.
Würde ich die Grafiken nun für OpenGL optimieren kämen nochmal ca. 50-100 Mb dazu.
Damit wären wir dann bei 700-800 Mb und dabei hätten die Grafiken immer noch 15 Bit Farbtiefe.
Neuere Grafikkarten nutzen aber nur 32 Bit Farbtiefe und niedrigere Farbtiefen werden dann emuliert.
Die Grafiken würden dann auf satte 1400-1600 Mb anschwellen und wer hat die schon.
Ich kann es also drehen und wenden wie ich will. Ich komme an einem VGA/SVGA ähnlichen Softwaremodus nicht vorbei.
Das Pixeln der Frames auf eine OpenGL-Textur (eine Textur als Front-/Backbuffer) werde ich aber zusätzlich einbauen.


Gruss
Weazle

[corpsman]

Also all deine Beschreibungen machen mich natürlich schon neugierig was du da Programmierst ..

In der Hoffnung das du keine Hohen Frameraten brauchst würde ich dir zustimmen und komplett auf OpenGl verzichten. Dann kannst du wenn es sagen wir mal ein Spiel ist, welches immer nur kleine Bildbereiche ändert, tatsächlich auch mit der VGA Graphik relativ hohe Bildraten erreichen. Deine RLC braucht natürlich auch wieder Rechenkraft für die Decodierung, das solltest du nicht unterschätzen. Und lohnen tut sie sich nur bei sehr vielen "Gleichen" Pixeln. Deswegen wurde sie ja bei Schwarzweiß Bildern eingesetzt. Wenn du schon solch "kreative" Pack Algorithmen verwenden willst, schau dir mal die Quadtree Kodierung an.

Allgemein, solltest du vorhaben dein Spiel was auch immer das ist was du da schreiben willst (evtl. Verrätst du es ja), zu veröffentlichen, dann sieht es allerdings wieder anders aus.
Was Mesa an geht stimme ich dir übrigens zu. Mesa ist Cool, ich hab es in meiner DA auch verwendet, aber heut zu tage ist es nur noch interessant wenn du z.B. wie ich in meiner DA 32-Bit pro Farbkanal hast, oder einen extrem große Rendering Context.

[Weazle25]

Also all deine Beschreibungen machen mich natürlich schon neugierig was du da Programmierst ..

Ich möchte folgende Spiele der Firma "Impressions Games" nachbauen:
- Caesar 3 (1998)

- Pharaoh (1999) + Addon Königin des Nils: Kleopatra (2000)

- Herrscher des Olymp - Zeus (2000) + Addon Herrscher von Atlantis: Poseidon (2001)

- Der erste Kaiser: Aufstieg des Reichs der Mitte (2002)

Das klingt im ersten Moment komplizierter als es ist denn alle 4 Spiele basieren auf der gleichen Engine und unterscheiden sich technisch nur durch einige Details.
Die Ähnlichkeit dieser Spiele ist dabei so hoch das wenn ich eines dieser Spiele nachbaue automatisch auch die anderen Spiele zu 80-90% mit drin sind.
Daher habe ich mich entschieden meine Engine so aufzubauen das ich die Grafiken aller 4 Spiele nutzen kann.
Allerdings werden die Grafiksets nicht alle gleichzeitig geladen.
Das Grafikset von Kaiser ist dabei mit 630 Mb (unkomprimiert) das grösste und mit fast 72.000 Grafiken auch das aufwändigste.

In der Hoffnung das du keine Hohen Frameraten brauchst würde ich dir zustimmen und komplett auf OpenGl verzichten. Dann kannst du wenn es sagen wir mal ein Spiel ist, welches immer nur kleine Bildbereiche ändert, tatsächlich auch mit der VGA Graphik relativ hohe Bildraten erreichen.

Es müssen auch keine hohen Frameraten erreicht werden.
Ich habe mal ein Bild angehängt das zeigen soll wie die Bilder aufgebaut sind.
Auf ein Zwischenbild werden die Groundtiles (der rautenförmige Teil im Bild links) gezeichnet.
Das Zwischenbild wird dann nurnoch aktualisiert. Es wird also nur noch dort gezeichnet wo es nötig ist.
Anschliessend wird bei jedem Frame das Zwischenbild in den Backbuffer kopiert (entspricht einem cls) und die Bilder mit den Lebewesen und die Überhangbilder (das Bild in der Mitte) drüber gezeichnet.
Das habe ich so schon mit Blitz3D gemacht und es hat auch sehr gut funktioniert.
Nur hat sich Blitz3D als recht langsam erwiesen (FPC ist da deutlich schneller).

Deine RLC braucht natürlich auch wieder Rechenkraft für die Decodierung, das solltest du nicht unterschätzen. Und lohnen tut sie sich nur bei sehr vielen "Gleichen" Pixeln. Deswegen wurde sie ja bei Schwarzweiß Bildern eingesetzt. Wenn du schon solch "kreative" Pack Algorithmen verwenden willst, schau dir mal die Quadtree Kodierung an.

Bei den IG-Spielen wurde das ja auch so gemacht und was schon vor 10 Jahren funktionierte wird heute sicher auch noch funktionieren.
Zumal DirectX dort nur dazu genutzt wird die fertigen Frames per DirectDraw auf den Bildschirm zu bringen.
Die Frames werden jedoch ausschliesslich im RAM gepixelt.
Ausserdem funktioniert die Kompression ja nicht ganz so wie RLE.
Sie ist nur an RLE angelehnt.
Der Algorythmus unterscheidet nur zwischen sichtbaren und nicht sichtbaren Pixeln.
Welche Farbe der Pixel hat ist dabei völlig unwichtig (es sei denn Pixel=Transparenzfarbe).
Wie bei der RLE-Kompression gibt es auch hier einen "Laufwert".
Dieser kann positiv oder negativ sein.
Ist der Laufwert positiv dann gibt er die Anzahl der Pixel an die gezeichnet werden sollen (unabhängig von der Pixelfarbe).
Ist der Laufwert negativ dann gibt er die Anzahl der Pixel an die beim zeichnen übersprungen werden sollen (die der "Pixelcursor" vorrücken muss) bzw. die Anzahl der unsichtbaren Pixel die beim kodieren des Bildes weggelassen wurden.

Hier ein Beispiel: (O=durchsichtig, U=sichtbar)
Das Bild ist 30x4 Pixel gross und soll nun kodiert werden.
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
OOOOOOOOOOUUUUUUUUUUOOOOOOOOOO
OOOOOUUUUUOOUUUUOOOOOUUUOOUUUU

Das ergibt dann folgende Kodierung:
Zeile 1: [-30] -> es werden keine Pixel gezeichnet
Zeile 2: [30][UUUUUUUUUUUUUUUUUUUUUUUUUUUUUU] -> alle 30 Pixel werden gezeichnet
Zeile 3: [-10][10][UUUUUUUUUU][-10] -> 10 Pixel überspringen dann 10 Pixel zeichnen und dann nochmal 10 Pixel überspringen
Zeile 4: [-5][5][UUUUU][-2][4][UUUU][-5][3][UUU][-2][4][UUUU] -> ich glaube das findest du selbst raus

Es gibt aber auch einige wenige Bilder die Alphamaps nutzen.
Diese werden dann in 2 Layer zerlegt die nach der gleichen Methode kodiert werden.
Layer 1 enthält alle Pixel die zu 100% sichtbar sind und Layer 2 nur die Pixel die durchsichtig sind.
Die nicht sichtbaren Pixel werden auch hier nicht gespeichert.
Das hat den Vorteil das nicht jeder Pixel auf Transparenz getestet oder berechnet werden muss.

Allgemein, solltest du vorhaben dein Spiel was auch immer das ist was du da schreiben willst (evtl. Verrätst du es ja), zu veröffentlichen, dann sieht es allerdings wieder anders aus.

Wie du siehst habe ich mir schon einige Gedanken gemacht wie man das Zeichnen beschleunigen kann.
Der einzige K(n)ackpunkt der mir noch einfällt ist die Bildschirmauflösung.
Es soll ja jede Bildschirmauflösung verwendbar sein die von der Hardware unterstützt wird.
Und wenn ich da so an FullHD mit 1920x1080 Pixeln (oder im Extremfall sogar WQXGA mit 2560x1600 Pixeln) denke dann könnte es da schon etwas eng werden.
Andererseit sind seid Kaiser auch Multicore-Prozessoren (mit bis zu 6 CPU's) dazu gekommen so dass man den Rechenbedarf eigentlich ganz gut verteilen kann.

Fehlt nur noch ein VGA/SVGA ähnlicher Screen auf den ich pixeln kann damit es mit der Engine weiter gehen kann.


Gruss
Weazle

[corpsman]

Wow,

Ich bin echt gespannt ob du das hin bekommst. Was mich allerdings schon etwas verwirrt. Auf der einen Seite gehst du Richtung Low Level, um Alte bzw. Rechner mit Wenig Graphikpower zu unterstützen, auf der Anderen Seite willst du theoretisch 6 Kerne nutzen können...

Da Frage ich mich, welcher Rechner der solche Prozessoren hat, läuft ohne eine entsprechende 3d-Fähige Graphikkarte ?

Was die Unterstützung der Ettlich vielen Graphikmodi angeht. Bei meinem Balanced (der Port nach Linux ist schon bei ca. 90% )war das auch immer die Diskussion, letztendlich war mein Glück hier OpenGL genutzt zu haben. Denn das Spiel verliert deutlich an Schwierigkeitsgrad wenn man "mehr" sieht, und dank OpenGL kann man die Auflösung hoch schrauben, das Sichtfeld an sich aber gleich "Klein" halten. Ich darf da nur an die gute alte Zeit von C&C Tiberiumkonflikt erinnern. Als die SVGA Version raus kam, konnte man die komplette Map auf einen Schlag sehen, und somit waren einige Missionen auf einmal kein Problem mehr. Ich denke dieses Problem trifft dich auch.

Sagen wir du legst dein Spiel auf 1024x768 aus und skalierst die Graphiken nicht, dann sieht der Spieler mit WQXGA gut 5,2 mal mehr. Das wäre dann schon ein deutlicher Vorteil. Zudem wird auf dem Monitor alles doch "sehr klein". Eine 1280x800 Auflösung auf meinem Laptop mit 15,1 Zoll wirkt doch ganz anders als 1920x1080 auf sagen wir einem 19 Zoll Monitor.

[Weazle25]

Wow,

Ich bin echt gespannt ob du das hin bekommst. Was mich allerdings schon etwas verwirrt. Auf der einen Seite gehst du Richtung Low Level, um Alte bzw. Rechner mit Wenig Graphikpower zu unterstützen, auf der Anderen Seite willst du theoretisch 6 Kerne nutzen können...

Da Frage ich mich, welcher Rechner der solche Prozessoren hat, läuft ohne eine entsprechende 3d-Fähige Graphikkarte ?

Wie wär's mit meinem altersschwachen Laptop?
Samsung R40plus
Intel Dual Core mit 2x 1,7 GHz
2 GB RAM
ATI Radeon XPress 1250 mit 256 Mb VRAM (shared)
Mit solch einem Rechner komme ich mit reinem OpenGL-Rendering nicht sehr weit.
Dafür könnte ich im Software-Modus 1 CPU quasi als GPU missbrauchen und dieser dann die grafischen Berechnungen überlassen.
Wärend die andere CPU dann andere Aufgaben übernehmen könnte (günstig für Multiplayer und andere zeitkritische Sachen).
Andererseits benötigen die o.g. Spiele laut Hersteller nur 2 bzw. 4 Mb VRAM.
Da würde es recht seltsam wirken wenn eine neuere Version des gleichen Spiels plötzlich 2 GB VRAM benötigen würde.
Denn weniger als 2 GB VRAM wären ja nicht möglich (s.o.)
Vielleicht könnte man das ganze mit Textur-Kompression gerade eben noch auf unter 1 GB bringen.
Nur wäre dann kaum noch Platz für die Quads die ich dann ja in grosser Menge benötigen würde und testen könnte ich das nur mit einem stark abgespeckten Grafikset mit dem ich dann auch nicht alles testen könnte.
Es wäre auch nicht sehr schön wenn der Entwickler sein eigenes Spiel nicht spielen kann.
Das geht dann auch ein wenig am Sinn vorbei denn ich schreibe dieses Spiel ja eben weil ich es spielen möchte.
Allerdings waren die o.g. Spiele ja noch für Singlecore CPU's mit 400 MHz audgelegt.
So das ich selbst bei meinem vergleichsweise bescheidenen Laptop noch etwas Luft nach oben habe und so noch Features einbauen kann die damals durch die knappe Rechenleistung nicht möglich waren (z.B. grössere Karten und eben höhere Auflösungen).

Was die Unterstützung der Ettlich vielen Graphikmodi angeht. Bei meinem Balanced (der Port nach Linux ist schon bei ca. 90% )war das auch immer die Diskussion, letztendlich war mein Glück hier OpenGL genutzt zu haben. Denn das Spiel verliert deutlich an Schwierigkeitsgrad wenn man "mehr" sieht, und dank OpenGL kann man die Auflösung hoch schrauben, das Sichtfeld an sich aber gleich "Klein" halten.

Um dieses Problen zu lösen wurde bei vielen Spielen "Fog of War" eingeführt.
Nehmen wir mal Age of Empire als Beispiel.
Dort würde man bei einer höheren Auflösung zwar mehr sehen aber immer nur den Teil den man "frei" gespielt hat.
Da würde das Spiel mit einer hohen Auflösung nicht sehr viel einfacher dafür aber kompfortabler werden.

Sagen wir du legst dein Spiel auf 1024x768 aus und skalierst die Graphiken nicht, dann sieht der Spieler mit WQXGA gut 5,2 mal mehr. Das wäre dann schon ein deutlicher Vorteil. Zudem wird auf dem Monitor alles doch "sehr klein". Eine 1280x800 Auflösung auf meinem Laptop mit 15,1 Zoll wirkt doch ganz anders als 1920x1080 auf sagen wir einem 19 Zoll Monitor.

Meinst du 1024x768 Pixel auf einem 32 Zoll Monitor sind besser?
Einige meiner Freunde haben bereits so grosse Monitore und sind derart begeistert das sie sich auch keine kleineren mehr holen wollen.
Leider haben immer noch sehr viele Spiele eine Auflösungsbegrenzung und sehen auf solchen Monitoren einfach grausig aus.
Daher kann auch so ein grosser Monitor bei der Spielewahl zu einem Problem werden.
Die o.g. Spiele sind auch nur für 640x480, 800x600 und 1024x768 Pixel ausgelegt und sehen auf diesen Monitoren sehr pixelig aus so das das spielen nicht wirklich Spass macht.

Ich darf da nur an die gute alte Zeit von C&C Tiberiumkonflikt erinnern. Als die SVGA Version raus kam, konnte man die komplette Map auf einen Schlag sehen, und somit waren einige Missionen auf einmal kein Problem mehr. Ich denke dieses Problem trifft dich auch.

Das Problem bei den IG-Spielen ist ja nicht das man zu viel sieht sondern das man eher zu wenig sieht.
Denn im Gegensatz zu C&C liegt der Schwerpunkt hier nicht beim kämpfen sondern bei Wirtschaft und Städtebau.
Feinde dienen hier nur als Behinderung. So kann z.B. in der Nähe von Feinden nicht gebaut werden.
Andererseits lassen sich Invasionen auch durch Bestechung vermeiden.
Wärend der Spieler bei C&C selbst darauf achten muss Feinde rechtzeitig zu entdecken wird hier bei einer Invasion eine Meldung generiert mit der man direkt zum Eindringling springen kann.
Feinde spielen hier also nur eine untergeordnete Rolle.
Eine höhere Auflösung wäre für diese Art von Spielen sogar sehr förderlich da man nicht wie bei 1024x768 Pixeln ständig hin und her scrollen muss nur weil man ein Stadtvirtel bauen oder ein grösseres Monument begutachten möchte.



Eine Lösung für mein Screen-Problem habe ich aber immer noch nicht gefunden.
SDL ist zwar ganz nett und die 2D-Display-Surfaces sind einfach zu benutzen.
Nur ist SDL auf 64-Bit Systemen recht instabil.
Daher meine Frage: Muss es denn unbedingt SDL oder TCanvas sein?
Gibt es denn nichts anderes?

Gruss
Weazle

PS:Schon wieder so ein Monster-Posting.

[corpsman]

Daher meine Frage: Muss es denn unbedingt SDL oder TCanvas sein?
Gibt es denn nichts anderes?

Also ich kenne außer SDL, Mesa, OpenGL, und TCanvas nichts.

SDL scheidet aus wie du sagst
Mesa ginge sicherlich und macht so gut wie alles in Software ( Die Befehle sind Kompatibel zu OpenGL ), in wie weit du Einfluss hast auf welchem Core das alles Läuft weis ich natürlich nicht

OpenGL scheinst du nicht zu wollen, bzw. Argumentativ aus zu schließen.

=> Ich würde sagen Probiere aus, wie du mit Mesa zurecht kommst, andernfalls nimm das Doublebufferd TCanvas ( nachdem ich dir schon einiges zutraue, denke ich wirst du das auch entsprechend Schnell = hohe Framerate hin bekommen).

Alle anderen Varianten die ich Kenne basieren letztendlich immer auf OpenGL ( z.B. Andorra ), oder dem TCanvas Ansatz.


Wäre ich in deiner Situation, ich denke ich würde tatsächlich den TCanvas Ansatz wählen, er bedeutet mehr Arbeit, aber auch mehr Einfluß.

[carli]

Wieso scheidet SDL aus?
Ich hab ein 64bit System und da läuft alles Prima (linux )

SDL ist genau das, was du brauchst: Du hast ein Fenster, du hast ein Screen-Surface und du kannst die Tilemap in ein Surface laden und die relevanten Teile auf den Bildschirm blitten.