4. SDL Dateien komprimieren

SDL Dateien komprimieren


  • Lieber Scorcher24,

    wenn jemand schreibt "SDL ist voll der Dreck, nimm SFML!!!einself", was ca. jeden zweiten Tag passiert, meldest du dich nicht zu Wort.

    Wenn ich dann schreibe "SDL ist veraltet, SFML wäre z.B. ne bessere Wahl. Aber darum gehts ja nicht." fühlst du dich genötigt blöd rumzumoppeln.
    Du könntest ja irgendwas dazuschreiben warum es deiner Meinung nach ein Blödsinn ist. Aber nein, lieber dumme Polemik, das zieht natürlich besser. Zumindest bei allen die aus dem seichten Ende des Genpools geschöpft wurden.

    Top, weiter so! 👍

    0
  • ?

    Mass effect 3 verwendet SDL, nicht SFML - nur mal so als info. Aber für mich sieht die Einstellung zu SDL übertrieben negativ aus - auch wenn SFML seine Vorteile hat (und ich im allgemeinen sogar Leuten dazu raten würde, damit anzufangen wenn sie sich unsicher sind).
    Und die Behauptung SDL sei verhaltet halte ich tatsächlich auch für Blödsinn. Wie kommst du eigentlich auf sowas?

    In SDL kannst du mit SDL_rwops Daten direkt ausm Speicher laden.
    Eine kleines Beispiel:
    http://sdl.beuc.net/sdl.wiki/SDL_RWops

    0
  • ?

    Nachtrag:
    Um festzustellen ob sich hustbaer mit "dummer Polemik" auskennt muss man wohl nur seinen letzten Beitrag lesen (Glashaus und so).

    Um nochmal ein genaueres Beispiel zum lesen aus/schreiben in den Speicher anzugeben:
    http://sdl.beuc.net/sdl.wiki/SDL_RWFromMem

    0
  • ?

    Schau dir mal physFS an, das bietet dir u.a. genau diese Funktionen mittels einem virtuellen Dateisystem.

    Gruß

    0
  • ?

    SFML ist besser als SDL, weil
    - es schneller ist (SDL kann nur mit OpenGL mithalten)
    - es in modernem C++ geschrieben ist
    - es die wichtigen Features schon fertig enthält, während man bei SDL für alles Extrapakete braucht

    SDL ist nur verbreiteter weil es schon viel länger existiert und darum bekannter ist.

    0
  • ?

    zu Punkt 1:
    SDL mit openGL ist schneller als SFML, ohne (deutlich) langsamer, weil SDL einen software renderer als backend hat - soll sich allerdings mit der neuen Version ändern. Das eigentliche Problem ist, das man um SDL sinnvoll zu verwenden (momentan) auch openGL verwenden muss. Dazu gleich mehr.

    zu Punkt 2:
    Stimmt mehr oder weniger. Deswegen ist SFML (insgesamt) leichter zu verwenden. Auch weil man sich eben auch mit openGL beschäftigen "muss", ist die leichtere Verwendung der Grund der für SFML spricht.

    zu Punkt 3:
    Diese "extra" Pakete sind jetzt wirklich kein Aufwand. Einmal runterladen, dependency einstellen und fertig.

    Ingesamt steht also leichtere Verwendung der Geschwindigkeit und mehr Unterstützung für verschiedene Plattformen gegenüber (und beide verwenden ein jeweils anderes Lizenzmodell). Da ist also keines von beiden einfach "besser" sondern je nach Verwendungszweck entweder das eine oder das andere. Wie mit Programmiersprachen muss man eben das richtige Werkzeug für die richtige Aufgabe verwenden.

    0

  • Wieso sollte SDL in Kombination mit OpenGL schneller sein als SFML? SFML verwendet auch bloss OpenGL...

    KMT schrieb:

    ohne (deutlich) langsamer, weil SDL einen software renderer als backend hat - soll sich allerdings mit der neuen Version ändern.

    Und das meinte ich mit "veraltet" 🙂

    0
  • ?

    KMT schrieb:

    Das eigentliche Problem ist, das man um SDL sinnvoll zu verwenden (momentan) auch openGL verwenden muss.

    Ja.

    KMT schrieb:

    Stimmt mehr oder weniger.

    Ne, stimmt voll und ganz. SFML hat wohl eine der schönsten APIs, die man in C++ finden kann. Und welche Vorteile C++ gegenüber C hat, müssen wir hier wohl nicht diskutieren.

    KMT schrieb:

    Diese "extra" Pakete sind jetzt wirklich kein Aufwand.

    Doch, es ist Aufwand. Wenn auch nicht viel, es ist unnötig. Man muss sich zuerst alles zusammensuchen, verschiedene Dokumentationen verwenden. Da es sich um verschiedene Autoren handelt, sind auch Codestile nicht immer einheitlich und Support wird schwieriger.

    KMT schrieb:

    mehr Unterstützung für verschiedene Plattformen gegenüber (und beide verwenden ein jeweils anderes Lizenzmodell). Da ist also keines von beiden einfach "besser" sondern je nach Verwendungszweck entweder das eine oder das andere.

    Ja, Plattformen ist ein Vorteil für SDL. Bei Lizenzen ist SFML mit zlib/libpng gegenüber SDL mit LGPL klar freier. Aber sagen wir, für 95% der User ist SFML besser geeignet, selbst in C. Die Vorteile von SDL betreffen hauptsächlich Spezialfälle, und schon gar keine Anfänger.

    Was ich noch vergessen habe: Support ist bei SFML ebenfalls unschlagbar. Fragen werden innerhalb von Stunden vom Entwickler selbst beantwortet, auch die Bibliothek wird sehr aktiv entwickelt. SDL habe ich nicht mehr verfolgt, aber ich habe den Eindruck, 1.2 gibts schon ewig. Auch wenn ich mir die letzten paar Changelogs anschaue, sind alles nur Bugfixes. Mal schauen, was 1.3/2.0 bringt...

    0
  • ?

    Tut mir leid für die späte Antwort.

    @hustbaer
    Kurz gesagt, Abstraktionsoverhead. Klar kannst du sfml auch direkt mit opengl verwenden, dann hat sich die Frage was man als "eigenen" backend verwendet meiner Meinung nach eh erledigt.

    Und "veraltet" heißt üblicherweise das etwas entweder nicht weiter entwickelt wird, oder höchstens vielleicht noch veraltete Konzepte als Interface verwendet.
    Beides trifft meiner Meinung nach bei SDL nicht.

    @nt

    Ne, stimmt voll und ganz. SFML hat wohl eine der schönsten APIs, die man in C++ finden kann. Und welche Vorteile C++ gegenüber C hat, müssen wir hier wohl nicht diskutieren.

    Ne, stimmt mehr oder weniger. "Modern" ist ein fließendes Konzept, und ist vorallem nicht völlig natürlich etwas gutes. Hättest du das "modern" weggelassen, hätte ich auch das "mehr oder weniger" weggelassen.

    Doch, es ist Aufwand. Wenn auch nicht viel, es ist unnötig. Man muss sich zuerst alles zusammensuchen, verschiedene Dokumentationen verwenden. Da es sich um verschiedene Autoren handelt, sind auch Codestile nicht immer einheitlich und Support wird schwieriger.

    Modularisierung hat auch Vorteile. Don't need, don't use. Vom interface kann ich keine unterschiedlichen Codestile erkennen und das ist für ein Bibliothek im Normalfall der relevante Teil. Und unter libsdl.org gibt es Informationen zu allen Modulen.

    Bei Lizenzen ist SFML mit zlib/libpng gegenüber SDL mit LGPL klar freier. Aber sagen wir, für 95% der User ist SFML besser geeignet, selbst in C. Die Vorteile von SDL betreffen hauptsächlich Spezialfälle, und schon gar keine Anfänger.

    Ob man die LGPL jetzt schlechter oder (aus ideologischen Gründen) besser findet sei mal dahingestellt. Aber freier ist zlib, da will ich nicht wiedersprechen.
    Und nicht das wir uns mißverstehen: Anfängern würde ich nie zu SDL raten. Aber die sollen eben auch nicht den Eindruck bekommen, das SDL Teufelswerk ist. Das ist nämlich eben nicht gerechtfertigt.

    SDL habe ich nicht mehr verfolgt, aber ich habe den Eindruck, 1.2 gibts schon ewig. Auch wenn ich mir die letzten paar Changelogs anschaue, sind alles nur Bugfixes. Mal schauen, was 1.3/2.0 bringt...

    1.2 bekommt nur noch bugfixes, da sich die Entwickler auf 1.3/2.0 konzentrieren wollen. Am Interface tut sich aber bei 1.3/2.0 fast nix.

    0

  • KMT schrieb:

    @hustbaer
    Kurz gesagt, Abstraktionsoverhead. Klar kannst du sfml auch direkt mit opengl verwenden, dann hat sich die Frage was man als "eigenen" backend verwendet meiner Meinung nach eh erledigt.

    Naja, damit der Vergleich fair ist muss man mMn. "SDL + OpenGL direkt" auch mit "SFML + OpenGL direkt" vergleichen.
    Oder eben "SDL + OpenGL indirekt" vs. "SFML + OpenGL indirekt". Was halt nicht möglich ist, weil die SDL das nicht kann, nur dafür kann ja die SFML nix.

    Und "veraltet" heißt üblicherweise das etwas entweder nicht weiter entwickelt wird, oder höchstens vielleicht noch veraltete Konzepte als Interface verwendet.
    Beides trifft meiner Meinung nach bei SDL nicht.

    Veraltet ist für mich auch wenn die aktuellste Version Dinge nicht verwenden kann die schon lange State-Of-The-Art sind.
    Und das trifft auf SDL zu, wenn man die SDL-eigenen Blitting-Funktionen verwenden möchte, die eben keinerlei Hardwarebeschleunigung verwenden. (Abgesehen vielleicht von MMX/SSE etc. - aber es werden halt keine Funktionen der Grafikkarte verwendet.)

    Und ... ist jetzt schon ne Zeitlang her dass ich mir die SDL angesehen hätte, aber ich meine mich zu erinnern dass das Interface für die SDL-eigenen Blitting-Funktionen derart ist, dass man es überhaupt nicht vernünftig mit Hardware-Beschleunigung implementieren kann. Weil halt direkter Zugriff auf Surface-Inhalte erlaubt wird.

    Wenn man sowieso mit OpenGL direkt arbeiten will, und nur etwas sucht was einem den ganzen Rest abnimmt, dann ist SDL vermutlich weiterhin eine gute Wahl. Wenn man aber etwas sucht was man als "Grafik Engine" verwenden kann, dann ist SDL mMn. eben veraltet.

    Und dass an einer neuen Version gearbeitet wird interessiert erstmal nicht, und zwar so lange bis diese fertiggestellt ist (bzw. zumindest eine Beta verfügbar + der Release-Termin absehbar ist).

    0
Anmelden zum Antworten