4. 2D-Programmierung - Welcher Weg ist der Beste?

2D-Programmierung - Welcher Weg ist der Beste?

  • B

    Hallo Leute.

    Ich fang gerade etwas mit C/C++ an. Und mein Ziel, das ich mir mittelfristig mal gesetzt hab, ist, ein kleines 2D-Adventure zu schreiben.
    Jetzt fehlt mir eine Grundlage, auf der ich aufbauen kann.
    Was wäre der einfachste Unterbau für ein 2D-Fullscreen-Spiel? Soll ich mit DirectX arbeiten oder sollte es SDL sein? Oder gibts was einfacheres?
    Ich hab keine hohen Anforderungen, ich brauch einfach was schnelles für 2D-Grafiken (Bitmaps etc).

    Danke schonmal.

    0
  • ?

    Hallo

    Schau dir mal das an:
    http://www.sfml-dev.org/

    Entscheide dich vor allem, welche Programmiersprache du lernen willst. C++ oder C. Der Link oben nutz du dir nur bei C++, wenn du C lernen willst, kannst du es mit sdl probieren. Bei c# würde ich dir zu xna raten.

    chrische

    0
  • ?

    chrische5 schrieb:

    Hallo

    Schau dir mal das an:
    http://www.sfml-dev.org/

    ja, sfml! ist echt allererste sahne, befindet sich im moment in der stetigen entwicklung. ist einfach zu benutzen, sehr gut strukturiert und sehr perfomant. der entwickler schreibt auch kräftig im eigenen forum, vorschläge werden also IDR instant umgesetzt, sofern sie sinnvoll sind und guter support ist damit auch da.

    0
  • M

    Meinst du mit "was schnelles für 2D-Grafiken" schnell in Bezug auf deine Entwicklungsarbeit oder schnell in Bezug auf Performanz? Naja, eigentlich ist die Frage egal, nimm SFML, das ist platformunabhängig und nutzt intern OpenGL, d.h. es hat genau wie DirectX Hardwarebeschleunigung. Da brauchst du dir über die ganzen Initialisierungssachen keine Gedanken zu machen, sondern kannst direkt loslegen. Es gibt eine Reihe Tutorials, die wirklich Schritt für Schritt vorgehen und auch für absolute Anfänger geeignet scheinen. Grundlagen in C++ solltest du aber schon mitbringen.

    Desweiteren bietet es dir Dinge wie vorgefertigte Laderoutinen für Grafiken (BMP, PNG, JPEG, GIF, TGA, ...), Inputmanagement (für Maus und Tastatur, Joystick AFAIK auch) und ist nebenbei schön klar aufgebaut.

    gruß
    Martin

    Edith sagt, dass ich zu langsam war. Aber irgendwo sind wir doch alle einer Meinung, was SFML angeht 😃

    0
  • M

    Aber irgendwo sind wir doch alle einer Meinung, was SFML angeht 😃

    Stimmt... ich auch

    Also mir war DirectX zu kompliziert, und da OpenGL nicht versprach weniger kompliziert zu werden, habe ich verschiedene Grafik-Engines durchprobiert.
    DarkGDK: Besonders einfach, hatte aber einen entscheidenen Fehler: Bitmaps + Sprites verträgt sich nicht
    XNA: Hab ich wieder aufgegeben wegen C#(War zu faul es zu lernen)
    SFML: Funktionierte alles, sobald ich mir die Bibliothek selbst kompiliert hatte. Auch das ist inzwischen nicht mehr nötig. Sehr einfach zu nutzen. Bietet viele Funktionen(Mehr als z.B. DarkGDK für 2d), man verliert aber dank der m.E. schöneren Programmierung nicht so leicht den Überblick. Schneller als SDL ist SFML in jedem Fall, je nach Rechner auch schon mal 3000%(Hab ich nicht nachgeprüft, aber SFML ist performanter als DarkGDK)
    Einziger Nachteil ist m.E., dass der Inputmanager schonmal zu Fehlern(Programm stürzt ab, wenn sich der Cursor über eine ganz bestimmte Stelle befindet) führen kann, da hier gleich 2 Wege nach Rom führen.

    0
  • B

    Danke euch erst mal.

    Ich hab nun mal das SFML Package installiert. Jetzt findet der aber das "-lsfml-system", das in den Linker Options steht (benutze Code::Blocks) nicht.

    In der Anleitung steht ja, dass man die *.a files in den /lib-Ordner kopieren muss. Jetzt sind da aber 2 Verzeichnisse namens "static" und "dynamic" drin. Soll ich die jetzt alle durcheinander in den lib-Ordner würfeln?

    edit: Habe genau das getan und es geht jetzt. Sorry^^

    edit: Anderes Problem: Ich hab mir gerade das Beispiel hier
    http://www.sfml-dev.org/tutorials/1.3/graphics-window.php
    gezogen und probiert.
    Fehler:
    \programming\graphics-window.cpp||In function `int main()':|
    \programming\graphics-window.cpp|9|error: 'class sf::RenderWindow' has no member named 'IsOpened'|
    \programming\graphics-window.cpp|17|error: 'class sf::RenderWindow' has no member named 'Close'|
    ||=== Build finished: 2 errors, 0 warnings ===|

    0
  • B

    Mr X schrieb:

    Schneller als SDL ist SFML in jedem Fall, je nach Rechner auch schon mal 3000%(Hab ich nicht nachgeprüft, aber SFML ist performanter als DarkGDK)

    *rofl* Quelle?

    Aber ja ne, ist klar, deswegen verwendet z. B. UT2004 unter Linux auch SDL, weil das ja so langsam ist 🙄

    SDL ist eine C-API und bietet nicht so viel wie SFML, aber richtig benutzt ist SDL gleich performant wie SFML (ja, auch unter Windows). Aber die Diskussion hatten wir IIRC im Forum schon mal. Trotzdem: bitte denk nach bevor du Schwachfug schreibst.

    EDIT: einem Anfaenger empfehle ich natuerlich trotzdem auch SFML

    0
  • B

    Und genau deshalb scheint mir SFML jetzt eine gute Lösung...

    Ich kämpfe noch etwas, aber es wird schon klarer. Ich melde mich nochmal, wenn ich Probleme haben sollte...

    0
  • M

    Blue-Tiger schrieb:

    *rofl* Quelle?

    http://www.sfml-dev.org/forum/viewtopic.php?t=43

    Blue-Tiger schrieb:

    Aber ja ne, ist klar, deswegen verwendet z. B. UT2004 unter Linux auch SDL, weil das ja so langsam ist 🙄

    Nur, um das OpenGL Fenster aufzumachen und die Userinputs zu verarbeiten (AFAIK). Da dort OpenGL benutzt wird, ist es wurscht, ob man SFML oder SDL nimmt.

    Blue-Tiger schrieb:

    SDL ist eine C-API und bietet nicht so viel wie SFML, aber richtig benutzt ist SDL gleich performant wie SFML (ja, auch unter Windows). Aber die Diskussion hatten wir IIRC im Forum schon mal. Trotzdem: bitte denk nach bevor du Schwachfug schreibst.

    Im 3D-Bereich sollten sie sich, s.o., nichts tun, da beide ja OpenGL dafür nutzen. Bei 2D nutzt SFML ebenfalls OpenGL, aber SDL nimmt irgendwas, was da ist (das kann durchaus etwas ohne Hardwarebeschleunigung sein, daher langsamer). Es kommt natürlich auf den Programmierer an, wie er mit den Dingern arbeitet, aber provokativ kann man schon sagen, dass SFML schneller läuft.

    Also, bevor man was von "Schwachfug" postet, erstmal einen Gang zurück und selber nachdenken 😉

    0
  • M

    Blue-Tiger schrieb:

    Mr X schrieb:

    Schneller als SDL ist SFML in jedem Fall, je nach Rechner auch schon mal 3000%(Hab ich nicht nachgeprüft, aber SFML ist performanter als DarkGDK)

    *rofl* Quelle?

    Aber ja ne, ist klar, deswegen verwendet z. B. UT2004 unter Linux auch SDL, weil das ja so langsam ist 🙄

    SDL ist eine C-API und bietet nicht so viel wie SFML, aber richtig benutzt ist SDL gleich performant wie SFML (ja, auch unter Windows). Aber die Diskussion hatten wir IIRC im Forum schon mal. Trotzdem: bitte denk nach bevor du Schwachfug schreibst.

    EDIT: einem Anfaenger empfehle ich natuerlich trotzdem auch SFML

    Es geht hier in diesem Thread(siehe Überschrift) um 2d, und da ist SFML angeblich(wie ich bereits schrieb) deutlich schneller. Quelle:
    http://www.sfml-dev.org/forum/viewtopic.php?t=43&start=0

    Das sind zwar angaben der Fangemeinde und das Benchmark-Programm ist vom SFML-Entwickler geschrieben, aber angesichts dieser gewaltigen Performance Unterschiede(bezogen auf 2d) wird da schon irgendetwas wares dran sein, und das SFML schneller ist als DarkGDK habe ich selber erlebt(wieder nur 2d)

    Ansonsten: Vielleicht bevor Du anderen Schwachfug in die Schuhe schiebst erstmal vielleicht nachfragen, wie ich darauf komme... 😉
    mfg
    Philipp

    0
  • B

    Sorry nochmal...

    Ich versuche jetzt was mit Fenstern zu machen, was aber nicht geht.

    Ich habe, wie hier http://www.sfml-dev.org/tutorials/1.3/window-window.php beschrieben, die SFML/Window.hpp includiert und in die Main geschrieben:

    sf::Window App(sf::VideoMode(800, 600, 32), "SFML Window");

    Als Fehler kommt:

    obj\Debug\main.o||In function main':| C:\\Projects\\sfml\\sfml_test\\main.cpp|36|undefined reference tosf::VideoMode::VideoMode(unsigned int, unsigned int, unsigned int)'|
    C:\Projects\sfml\sfml_test\main.cpp|36|undefined reference to sf::Window::Window(sf::VideoMode, std::string const&, unsigned long, int)'| C:\\Projects\\sfml\\sfml_test\\main.cpp|68|undefined reference tosf::Window::~Window()'|
    C:\Projects\sfml\sfml_test\main.cpp|68|undefined reference to `sf::Window::~Window()'|
    ||=== Build finished: 4 errors, 0 warnings ===|

    Der findet das anscheinend nicht... Aber die Datei ist da.

    0
  • L

    hast du auch die libs eingebunden und dies auch in der richtigen Reihenfolge?

    mfg ligginator

    0
  • N

    In den Tutorials auf der SFML-Homepage sollte eigentlich alles erklärt sein. Im Forum findest du auch viele Problemlösungen.

    0
  • B

    Ich hatte ein paar Linker Options vergessen.

    Der Witz ist jetzt:
    Im Tut hier http://www.sfml-dev.org/tutorials/1.3/window-events.php
    wird App.Close aufgerufen.
    Aber anscheinend gibt es die Methode Close gar nicht.
    Window.App gibts,
    Window.Display gibts,
    und ne Menge mehr, aber KEIN Close. Es wird mir nicht mal vorgeschlagen. Da kann doch was nicht stimmen...

    0
  • B

    mad_martin schrieb:

    Nur, um das OpenGL Fenster aufzumachen und die Userinputs zu verarbeiten (AFAIK). Da dort OpenGL benutzt wird, ist es wurscht, ob man SFML oder SDL nimmt.

    Im 3D-Bereich sollten sie sich, s.o., nichts tun, da beide ja OpenGL dafür nutzen. Bei 2D nutzt SFML ebenfalls OpenGL, aber SDL nimmt irgendwas, was da ist (das kann durchaus etwas ohne Hardwarebeschleunigung sein, daher langsamer). Es kommt natürlich auf den Programmierer an, wie er mit den Dingern arbeitet, aber provokativ kann man schon sagen, dass SFML schneller läuft.

    SFML benutzt intern (auch fuer 2D) OpenGL. Und wenn du 'schnelles' SDL haben willst, musst du auch dort OpenGL verwenden. Daher meine Aussage "richtig benutzt ist SDL gleich schnell wie SFML". Und natuerlich weiss ein Anfaenger sowas nicht, daher ists auch gut, einem Anfaenger SFML zu empfehlen - ein fortgeschrittener Benutzer wird selbst abschaetzen koennen, ob er lieber direkt auf OpenGL programmiert oder die Power gar nicht benoetigt und deshalb die komfortablere API benutzt.

    Wie gesagt hatten wir genau diese Diskussion schon mal hier, da ging es um genau den gleichen (schwachfugigen ;p) Thread auf dem SFML-Board. Natuerlich gewinnt Software-SDL nicht gegen Hardware-SFML.

    Uebrigens wird genau das auch am Ende des von euch verlinkten Threads erwaehnt: 🙄

    Your benchmarks are severly flawed. You are comparing the software, 2D library that ships with SDL to OpenGL. Of course you are going to get a huge difference in performance - you don't even need to perform a benchmark to understand that.

    I perfectly know that, this benchmark is basically just for beginners who might not be aware of the technical details, and wonder how SFML compares to a well known multimedia library.

    0
  • ?

    Blue-Tiger schrieb:

    mad_martin schrieb:

    Nur, um das OpenGL Fenster aufzumachen und die Userinputs zu verarbeiten (AFAIK). Da dort OpenGL benutzt wird, ist es wurscht, ob man SFML oder SDL nimmt.

    Im 3D-Bereich sollten sie sich, s.o., nichts tun, da beide ja OpenGL dafür nutzen. Bei 2D nutzt SFML ebenfalls OpenGL, aber SDL nimmt irgendwas, was da ist (das kann durchaus etwas ohne Hardwarebeschleunigung sein, daher langsamer). Es kommt natürlich auf den Programmierer an, wie er mit den Dingern arbeitet, aber provokativ kann man schon sagen, dass SFML schneller läuft.

    SFML benutzt intern (auch fuer 2D) OpenGL. Und wenn du 'schnelles' SDL haben willst, musst du auch dort OpenGL verwenden. Daher meine Aussage "richtig benutzt ist SDL gleich schnell wie SFML". Und natuerlich weiss ein Anfaenger sowas nicht, daher ists auch gut, einem Anfaenger SFML zu empfehlen - ein fortgeschrittener Benutzer wird selbst abschaetzen koennen, ob er lieber direkt auf OpenGL programmiert oder die Power gar nicht benoetigt und deshalb die komfortablere API benutzt.

    Wie gesagt hatten wir genau diese Diskussion schon mal hier, da ging es um genau den gleichen (schwachfugigen ;p) Thread auf dem SFML-Board. Natuerlich gewinnt Software-SDL nicht gegen Hardware-SFML.

    Uebrigens wird genau das auch am Ende des von euch verlinkten Threads erwaehnt: 🙄

    Your benchmarks are severly flawed. You are comparing the software, 2D library that ships with SDL to OpenGL. Of course you are going to get a huge difference in performance - you don't even need to perform a benchmark to understand that.

    I perfectly know that, this benchmark is basically just for beginners who might not be aware of the technical details, and wonder how SFML compares to a well known multimedia library.

    Naja, richtig benutzt ist C++ dann auch so schnell wie Assembler!

    SDL hat nicht umsonst einen puren 2D Part. Es arbeitet so einfach mit OpenGL zusammen, damit man 3D Anwendungen möglich macht. Bei Diskussionen um Geschwindigkeit etc, sollte man schon über den "reinen" 2D Part von SDL sprechen, ansonsten unterscheided sich SDL von purem OpenGL nämlich auch durch gar nix, ausser, dass die Initialisierung etwas einfacher gemacht wird (es sei denn man verwendet OpenGL blits mit SDL, was dann jedoch wiederum gääähnend langsam ist)

    0
  • J

    der vorschlag mag etwas unkonventionell sein, aber: wer 2d grafikprogrammierung von der pike auf lernen möchte, sprich double buffering und page flipping und dergleichen... dem würde ich empfehlen, das mit java zu tun (im ernst).
    warum? man erzielt sehr schnell recht vernünftige ergebnisse. die performance ist auf modernen rechnern absolut ausreichend (ich hab selbst eine 2d engine in java geschrieben - wollte mal sehen ob das geht - fps konstant vom v-sync gecapped...).
    der haupt punkt ist, dass man sich nicht mit apis wie directx oder opengl rumschlagen muss; das erledigt die bibliothek... und so kann man sich voll drauf konzentrieren, fullscreen exclusive handlen zu lernen, zu rendern usw...
    beherrscht man dann diese technologie ist der sprung von 2d in java auf 2d in einer xbeliebigen anderen sprache klein, denn wenn man erstmal weis, wie in 2d umgebungen gerendert wird, ist es leicht (finde ich) das auf andere umgebungen zu abstrahieren. ein guter programmierer sollte sich nie auf nur eine sprache beschränken und c/c++ sind ganz gemächlich aussterbende technologien (gut, ob java viel länger leben wird, kann ich auch nicht sagen)
    aber wenn man rendern lernen will und 50% des codes nur zur fehlerbehandlung da sind, dann kommt man nur geringfügig dazu, sich aufs wesentliche zu konzentrieren.
    btw c# soll auch sehr gute grafikbibliotheken haben.
    also wenn jemand nicht gleich ein konkretes spiel bauen will sondern erstmal lernen möchte, wie man 2d animationen darstellt, scrolling und ebenen etc implementiert: in java spart ihr locker 30-50% codezeilen, die ihr schreiben müsst und es geht auch alles damit, was in c++ geht.

    0
  • B

    Öhm... vielleicht können wir uns wieder auf mein Problem konzentrieren. Ich hab bereits was, aber es geht nicht, da die Klasse Windown keine Methoden namens Close() oder IsOpened() hat, obwohl es so im Tutorial steht...

    0
  • M

    Hast du dir Version 1.3 gezogen? Und nimmst das passende Tutorial? Dann muss etwas bei dir schief gelaufen sein. Zeig mal deinen Code her!

    0
  • R
    Mod

    BenNation schrieb:

    Öhm... vielleicht können wir uns wieder auf mein Problem konzentrieren. Ich hab bereits was, aber es geht nicht, da die Klasse Windown keine Methoden namens Close() oder IsOpened() hat, obwohl es so im Tutorial steht...

    👍
    anderes wird ab hier entfernt werden ⚠

    0
Anmelden zum Antworten