Entwickler-Ecke :: Thema anzeigen

Aya - Di 27.08.02 04:19
Titel: 2D Spiel

Hi,

hab mal ne frage... kann mir jemand sagen wie man am besten ein 2D Spiel programmiert (so á la Diablo1), denn 3D is das ja nich wirklich.. auch nich 3D mit ner Orthographischen Ansicht... :)

Aber auch sowas wie Canvas isses net wirklich, denn dafür isses viel zu schnell ^^

Also mich würd mal interressieren wie man das macht. (bitte nich auf irgendwelche Komponenten verweisen, denn damit kann ich reichlich wenig anfangen.. will es selber machen :) )

Wie ich 3D Programmiere (mit OpenGL), das kann ich bereits recht gut.. nur halt 2D versteh ich net so ganz wie's gemacht wird :)
(3D OpenGL code ich z.Z. mit VC++, is da nen unterschied ob ich's mit VC++ oder mit Delphi mache?? Hat VC++OpenGL vor/nachteile gegenüber DelphiOpenGL??)

Au'revoir,
Aya

Günter - Do 29.08.02 09:46
Titel: Re: 2D Spiel

Hallo Aya,

selbst mit DirectX verwendet man mittlerweile DirectDraw (2D Schnittstelle) nicht mehr, es wird seit DirectX 7 auch nicht mehr weiterentwickelt.

Da du schon Erfahrung in 3D-Programmierung mit OpenGL hast, würde ich dir empfehlen das Spiel in "Pseudo-3D" zu Entwickeln, das heißt du setzt für alle Punkte den Z-Wert (Tiefen-Wert) einfach auf 0, und schon ist es 2-Dimensional.
Außerdem kannst du so über deine Objekte sehr einfach Texturen legen, die Kollisions-Erkennung ist einfacher und du hast weitaus mehr graphische Möglichkeiten als mit "reiner" 2D Grafik.

Diablo 2 ist auf diese Weise realisiert

Gruß Günter

OregonGhost - Fr 30.08.02 07:18

Vor allem hast du bei 3D-Programmierung die volle Unterstützung deiner Grafikkarte. Bei 2D hast du nur die vergleichsweise lachhafte 2D-Beschleunigung. Aufpassen musst du nur bei großen und kleinen Texturen: Viele Karten brauchen mindestens 64x64 und manche können maximal 256x256, und viele Karten machen beim Kacheln hässliche Artefakte...

Du solltest statt z-Wert 0 lieber 1 bzw. -1 (je nach System) nehmen (weil auf 0 gerne die Kamera liegt), und einfach den rhw-Wert auf 1 setzen. Bei Direct3D kannst du auch einfach transformierte, unbeleuchtete Vertices nehmen, dann kannst du in Bildschirmkoordinaten rechnen, es ist schneller als wenn die noch transformiert werden müssten, und Beleuchtung hast du auch. Dann aber ohne rhw ;c)

mth - Mo 02.09.02 21:26

Mr_T hat folgendes geschrieben:

Also wenn du die Absolute 2d - Keule auspacken willst, dann schreibe deine Grafukunits kommplett in ASM! Per Int 10 in die Supervga - Modi switchen und dann direkt über die Banks in den Grafikspeicher schreiben.... scheller bekommste es nirgends ... da ist es auch net relevand, wie groß deine Texturen sind und nichts ... aber ist ne Menge Aufwand.......

Das ist Unsinn. Die heutigen Grafikkartentreiber sind oft hoch optimiert wärend das VESA Interface, auf das du Anspielst, nur noch Stiefmütterlich behandelt wird. Mit ASM ist das heutzutage auch so eine Sache. Gegen einen guten optimierenden Compiler (z. B. die von Intel) kann man als Assembler Programmierer kaum noch bestehen.

tommie-lie - Mo 11.11.02 17:48

also ich weiß ja nicht, was die openGL-API drauf hat, aber zumindest in GLScene wüsste ich auch, wie ich ein 3D-Spiel in openGL proggen würde:
Mit Sprites, was sonst?
Depth-Sorting ist schon inklusive, Landschaft gibt's als Hintergrundbild, Steinchen und Männchen als animierte Sprites drauf, gutes Gameplay, fertig ist das Siedler-Spiel für Arme.

Mal im Ernst: Mit allem kann man 3D-Spiele machen. Sprites gibt es meines Wissens sowohl per Direct3D (wo ja mittlerweile DirectDraw drin ist, MS wollte nur alle bisherigen Sachen über den Haufen rennen und hat kurzweg DirectDraw in Direct3D gepackt) als auch per openGL und Canvas. Die oben beschriebene Variante über Assembler direkt in den Grafik-Puffer zu schreiben, halt ich für extrem übertrieben und sollte eigentlich nur absoluten Freaks vorbehalten bleiben, weil man jede Funktion selber basteln muss und auf quasi nichts Vorhandenes (durch den GraKa-Treiber, den ja wohl mittlerweile jeder installiert haben sollte) zurückgreifen kann. Aber schnell ist es schon, das ist richtig (da können auch GraKa-Treiber nicht viel machen, wenn man's richtig programmiert, bleibt ein Stück direkt gerechnetes in der GPU immer schneller, als wenn da noch ein Treiber und das lahme Windoof dazwischenhängt).

Zur Umsetzung: Wenn du openGL nehmen willst (nur um MS eins auszuwischen ;-) ), kannst du auf jeden Fall mit sprites arbeiten. Du bräuchtest du animierte Sprites mit Transparenz. Da wäre GIF wie geschaffen für. Für Delphi (ob's auch mit VC++ geht, weiß ich nicht) gibt's da die GraphicsEx von Mike Lischke (www.lischke-online.com [http://www.lischke-online.com] aus dem Gedächtnis, ob der Link funzt, weiß ich nicht, ich such aber mal nach...), die neben GIF auch andere bekannte Formate (psp, und andere) lesen kann. Damit könnte man seine Sprites basteln. Als Hintergrund nimmt man halt einfach seine Landschaft, ohne Objekte. Steine (wie in Siedler) werden dann ebenfalls als Sprites gemacht, müssen aber immer in mehreren Versionen verfügbar ein, weil man ja den Stein mit der Zeit abbauen kann. Männchen und andere Sachen, die da seu fleuchen und kreuchen, macht man dann als Sprites mit animierter Textur, die fröhlich durch die Gegend hüpfen. Häuser (ebenfalls in mehreren Baustadien vorhanden) sind auch Sprites. Das auswählen usw geht halt mit der Maus und per überprüfen, wo sie das liebe Nagetier befindet und welches Sprite denn darunter liegt. Der Rest ist wie bei jedem anderen Spiel auch. Anständiges HUD für Informationsnachschub, gute Ideen und schöne Grafiken, und schon kann kaum noch was schiefegehen.

OregonGhost - Mo 11.11.02 20:16

Ein HUD gibt's eigentlich nur in 3D-Spielen, weil das ist das, was dem Spieler(-charakter) direkt vor dem Kopf liegt ;c)

GIF ist ein völlig ungeeignetes Format für 3D-Spiele, weil es nur 256 Farben unterstützt und nur volle Transparenz. DirectX Graphics unterstützt beispielsweise die gängigen Formate BMP, TGA und PNG, die allesamt 24 Bit plus Alphakanal (8 Bit) unterstützten. Jede gängige Bildbearbeitung kann diese Formate erstellen.

tommie-lie hat folgendes geschrieben:

wie ich ein 3D-Spiel in openGL proggen würde:
Mit Sprites, was sonst?

Mit Sprites kann man aber nur 2D-Spiele programmieren...

Als "Landschaft" eine Bitmap zu nehmen ist auch etwas unpraktisch, was machst du dann mit deiner 20mal20-Bildschirme-Karte?

Udontknow hat folgendes geschrieben:

Wie ist denn dann das Handling von übergrossen Bildern? Ich muss also immer mir Vertices erstellen und mein Bitmap dann als Textur laden? Bei einer Begrenzung der Texturgrösse von 256 x 256 müsste ich ja dann das Bild sozusagen zerstückeln und auf mehrere Vertices verteilen? Das ist aber umständlich... Gibt es da keine Alternative?

Die maximale Texturgröße von 256x256 gilt v.a. für Voodoo 3. Heutzutage kannst du 2048x2048 annehmen, aber es ist sehr einfach, die Bitmap zu zerstückeln. Dazu sind nur wenige Zeilen Code nötig.
Wenn es dir um ein Hintergrundbild geht, kannst du das stattdessen auch direkt in den Frontbuffer kopieren.

tommie-lie - Mo 11.11.02 20:50

[quote="OregonGhost"]Ein HUD gibt's eigentlich nur in 3D-Spielen, weil das ist das, was dem Spieler(-charakter) direkt vor dem Kopf liegt ;c)
[/code}
Als HUD kann man aber auch das Bezeichnen, was zum Beispiel bei Strategiespielen die Menüs und Infos und so weiter anzeigt. Also diese Felder rundum, wo die Landkarte drin ist und Bauoptionen usw.
Das wird mittlerweile ebenfalls als HUD bezeichnet (man kann es zumindest so bezeichnen)...

Zitat:

GIF ist ein völlig ungeeignetes Format für 3D-Spiele, weil es nur 256 Farben unterstützt und nur volle Transparenz. DirectX Graphics unterstützt beispielsweise die gängigen Formate BMP, TGA und PNG, die allesamt 24 Bit plus Alphakanal (8 Bit) unterstützten. Jede gängige Bildbearbeitung kann diese Formate erstellen.
Gibt's aber nur, wenn man auch mit DirectX arbeitet. Außerdem will ich jetzt einfach mal sagen, daß 256 Farben reichen dürften, wenn man anständig mit AntiAliasing, Dithering und sonstigen Grafik-Tricks arbeitet...
Für ein Spiel à la Siedler reicht GIF auf jeden Fall.

Zitat:

[quote="tommie-lie"]
wie ich ein 3D-Spiel in openGL proggen würde:
Mit Sprites, was sonst?

Mit Sprites kann man aber nur 2D-Spiele programmieren...

Heißt dieser Thread nicht 2D-Spiele? Oder bin ich hier im falschen Topic?

Zitat:

Als "Landschaft" eine Bitmap zu nehmen ist auch etwas unpraktisch, was machst du dann mit deiner 20mal20-Bildschirme-Karte?

Das versteh' ich nicht. 20*20? Kein Bitmap? Wenn die Landschaft feststeht, gibt's keine Probleme...
Man kann aber auch für Wiese, Wasser, Wüste und all den Kram auch eigene kleine Bilder machen, die man nachher tile-artig (mit Überlappung!) zusammenkleistert. Ist aber meiner Meinung nach schwieriger zu koordinieren...

Anonymous - Di 12.11.02 02:18

Also ich experimentiere momentan etwas mit Canvas und muß sagen, daß wenn man den Code etwas optimiert es auch nicht so langsam ist.

Hier eine kleine Canvas Demo von mir:

http://mitglied.lycos.de/popov3/pub2/canvasdemo/CanvasDemo.zip

Eigentlich ist das ganze keine selbstablaufende Demo, sondern wurde für das Bewegen der Objekte mit der Maus geschrieben. Ich hab das ganze in einen Timer gepackt und etwas Bewegung reingebracht. Wenn Ihr also da irgendwo einen Schatten sieht wenn zwei Objekte (Objekte = Sprites) übereinander flegen, dann liegt es nur daran, daß ich meine Übung in 10 Minuten auf Demo umgeschrieben habe.

Was man sieht wenn man daß Programm startet sind 100 Bitmaps. Auch wenn die nur wie bunte Rechtecke aussehen, so sind das Bitmaps die beim Strat des Programms erstellt werden. Auf der Oberfläche liegen 100 Objekte. Vier davon (Nummer 25, 50, 75, 90) bewegen sich auf dem Bildschirm. Die mit mit der kleineren Nummer bewegen sich unter den Objekten mit der größeren Nummer, d.h. es gibt eine Z-Ordnung. Natürlich ist das ganze etwas optimiert und ich arbeite mit drei Bitmaps als Puffer.

Wenn man bedenkt, daß ich nur etwas rumexperimentiert habe, so finde ich das Ergebnis garnicht so schlecht ist. Man kann kann das ganze noch mehr optimieren, aber ich schätze, daß man durchaus ein kleines Spiel mit den Möglichkeiten machen kann. Wie gesagt, alles nur reines Canvas.

Ich hab einen 1600XP. Es kann also sein, daß auf einem langsameren Rechner das ganze etwas langsamer abläuft.

Mr_T - Di 12.11.02 15:36
Titel: Re: 2D Spiel

Aya hat folgendes geschrieben:

Wie ich 3D Programmiere (mit OpenGL), das kann ich bereits recht gut.. nur halt 2D versteh ich net so ganz wie's gemacht wird :)

Also wenn du bereits mit Delphi und Open Gl 3d progst, dann ist 2d auch kein Thema... so kannst du mit:

Quelltext

1:
2:
3:
4:

glMatrixMode(GL_PROJECTION);
glLoadIdentity;
gluOrtho2D(0,width,0,height);
glMatrixMode(GL_MODELVIEW);

relativ einfach in den Orthographischen Open - Gl - 2d - Modus schalten. Der Unterschied zum 3d sind recht einfach:
1) Du brauchst bei den Vertexen nur noch glvertex2f aufzurufen, da die z-koord immer null bleibt
2) bei gltranslate bleibt der z - wert immer null (besser: du solltest ihn immer null lassen)
3) Jeder Pixel entspricht einer Welt - einheit (begonnen unten links) ... d.h. du kannst ale Objekte Pixelgenau dahin setzen, wo sie hinsollen und auch das markieren von Objekten stellt sich nciht mehr so schwierig dar....

Ich persönlich würde es zumindest so machen: da braucht man nicht so viel umlernen ;-)

OregonGhost - Di 12.11.02 19:20

@tommie-lie: (nur zur Klärung, ich will dich nicht angreifen... Manchmal werden meine Antworten nämlich so verstanden)

Hinter dem mit dem HUD stand ein ";c)", soviel dazu...
(will nicht so viel quoten)
Nein, du bist nicht im falschen Topic, du sagtest aber, du wüsstest, wie du ein 3D-Spiel programmierst, nämlich mit Sprites ;C)
Das mit den Grafikformaten trifft trotzdem zu, weil es mit einer 3D-API gelöst werden soll, DirectX war ein Beispiel. Ich würde dennoch kein komprimiertes Format nehmen, am besten also TIFF oder TGA. Gerade für Pseudo-2D-Spiele sind diese Formate besser, wegen des von dir angesprochenen Anti-Aliasings, weil man das mit dem Alphakanal wunderbar glatt machen kann, dann wirkt das nämlich nicht wie eine aufgesetzt Bitmap und zieht aber keine Leistung, wie echte Kantenglättung das würde.

Mit 20*20 Bildschirmen meinte ich, stell dir vor, deine Map ist so groß, dass sie auf 20*20 Bildschirme passen würde. Mit einer Hintergrundbitmap ist es dann nicht mehr getan, es sei denn, derjenige hat eine Killergrafikkarte mit einem Gigabyte RAM ;c)

Die Siedler 3 übrigens hat für die Landschaft gerade keine Bitmaps verwendet, sondern die Landschaft aus zigtausenden winzigen Dreiecken zusammengesetzt.

tommie-lie - Di 12.11.02 19:52

OregonGhost hat folgendes geschrieben:

@tommie-lie: (nur zur Klärung, ich will dich nicht angreifen... Manchmal werden meine Antworten nämlich so verstanden)

Von mir nicht.
Jeder der Bedenken hat, kann sich merken: Bei mir wird nichts als "Angriff" genommen. Wenn doch, sage ich's auch so!

Zitat:

Nein, du bist nicht im falschen Topic, du sagtest aber, du wüsstest, wie du ein 3D-Spiel programmierst, nämlich mit Sprites ;C)

Uups. Vertippt. Sorry, meinte natürlich 2D-Spiel. Ist mir eben erst aufgefallen, sonst hätte ich den anderen Post auch anders geschrieben.

Zitat:

komprimiertes Format nehmen, am besten also TIFF oder TGA. Gerade für Pseudo-2D-Spiele sind diese Formate besser, wegen des von dir angesprochenen Anti-Aliasings, weil man das mit dem Alphakanal wunderbar glatt machen kann, dann wirkt das nämlich nicht wie eine aufgesetzt Bitmap und zieht aber keine Leistung, wie echte Kantenglättung das würde.

Stimmt. Targa wäre gar nicht schlecht für diesen Zweck und wird auch oft genommen. Aber Alpha ist meines Wissens Transparenz (genauer gesagt Deckkraft), also bin ich mit dem AA nur halb einverstanden. Alpha und AA bringt nämlich nur am Rand der Textur etwas, wo man das, was dahinter ist, noch durchsehen soll. Da wäre es auch sinnvoll, mit abgestuften Alpha zu arbeiten. Aber direkt IN einer Textur, also bei Farbübergängen usw braucht man Dithering, (womit man per GIF auch nichts erreichen würde, was Größe angeht, nur als Anmerkung)

Zitat:

Die Siedler 3 übrigens hat für die Landschaft gerade keine Bitmaps verwendet, sondern die Landschaft aus zigtausenden winzigen Dreiecken zusammengesetzt.

Stimmt. Ich glaube sogar, es sind Sechsecke...
Aber jetzt versteh' ich,was du mit den 20 Screens meinst.
Es kommt halt drauf an, wie groß die Map sein soll. Bei kleinen Sachen, und wenn man keinen KArteneditor oder Scripts oder sonstiges anbieten will, ist es vermutlich ebsser mit einem einzigen Bild als Hintergrund. Aber wenn man Editoren machen will, oder sehr viele, sehr große KArten hat, wären kleine Kacheln, die sich überlappen sinnvoller.
Habe ich aber auch schon geschrieben *g*

OregonGhost - Mi 13.11.02 17:44

Zum einen soll Aya sich melden, wenn sie das ganze in eine andere Richtung lenken soll, zum anderen glaube ich, dass unsere Diskussion durchaus wertvolle Beiträge zum Thema liefert ;c)
Darum eins noch:

Zitat:

Alpha und AA bringt nämlich nur am Rand der Textur etwas, wo man das, was dahinter ist, noch durchsehen soll. Da wäre es auch sinnvoll, mit abgestuften Alpha zu arbeiten

Und genau das ist bei Sprites das entscheidende. Wenn der Alphakanal entsprechend aufgestuft ist, sieht es so aus, als wäre das Sprite Teil des Bildes, und wirkt nicht so aufgesetzt. Und das wichtigste: Es erfordert keinerlei Programmieraufwand ;c)

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!