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

2D kannst du mit Canvas auch mit Canvas machen, nur ist es etwa doof, das es etwas langsam ist. Aber da steht ja was in der FAQ

Sonst könnte ich z.b. auch nur auf DirectX verweisen, denn damit kann man natürlich auch 2DS realisieren.

Aya hat folgendes geschrieben:

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...

Da kommt eigenlich nur DirectX in Frage. Vieleicht noch die SDL (Simple DirectMedia Layer) da ists etwas einfacher gehalten.

nur DirectX???
Also muß (!) es ja mit OpenGL auch gehen, nur.. wie??? Ne Orthographische ansicht is das net bei Diablo1, das is echtes 2D... nur wie macht man das..??

Au'revoir,
Aya

Aya hat folgendes geschrieben:

Also muß (!) es ja mit OpenGL auch gehen, nur.. wie??? Ne Orthographische ansicht is das net bei Diablo1, das is echtes 2D... nur wie macht man das..??

Ich kenne Diablo nicht. Einem Screenshoot aus dem Internet nach zu beurteilen ist aber eindeutig eine Isometrische (d. h. eine durchaus dreidimensionale) Darstellung. Auf jeden Fall ist es kein plattes 2D.

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

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)

Hi!

Hab mal ne Frage:
Bin noch relativ frisch in Sachen Delphi-Programmierung...

Kan mir jemand ne URL geben, wo man sich über "D / §D-Spiele-Programmierung informieren kann?!


Danke im Voraus!

Andi

bei 2d würde ich sagen, kommt drauf mit was du proggen willst. (delphiX)?

3d delphi:

[url]www.neobrothers.de[/url]

cu

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.......

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.

Zitat:

Gegen einen guten optimierenden Compiler (z. B. die von Intel) kann man als Assembler Programmierer kaum noch bestehen.

Yo, allerdings ist der Microsoft C++ Compiler noch etwas schneller als der von Intel. Außerdem kann er (mit dem Visual C++ Processor Pack) optimierten Code sowohl für 3DNow! als auch für ISSE ausspucken, was also nochmal einen Temposchub gibt (Ich glaube kaum, dass Intels 3DNow! unterstützt (c; )

also ms compiler sind immer langsam,dagen ist borland 1000 mal schneller

und was das spieler programmieren angeht:
wenn du 2D Spiele machen willst nehme DelpihX und wenn du es wirklich nur mit delphi bordmitel machen willst nehme ne Image komponente ist aber ne mege aufwand

MFG
mimi

mimi hat folgendes geschrieben:

also ms compiler sind immer langsam,dagen ist borland 1000 mal schneller

Es geht nicht um die Kompiliergeschwindigkeit, sondern um die Geschwindigkeit des Kompilats, und da ist der VC++-Compiler einsame Spitze, besonders mit dem bereits erwähnten Processor Pack.

Klar, man kann ja mit dem Borland C++ Compiler entwickeln und das Endprodukt mit dem VC++-Compiler kompilieren, dann ist man schneller fertig ;c)

Hi!

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?

Cu,
Udontknow

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 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.

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.

[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...

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:

mitglied.lycos.de/po...sdemo/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.

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:

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