Open-Source-Bibliotheken in der Indie-Szene



  • Nexus schrieb:

    Nathan und Lichtweite, wie schon angetönt sind bei kommerziellen Projekten eben andere Kriterien wichtig als bei Hobbyprojekten. Normalerweise lohnt es sich nicht, alles aus Wissensdurst oder Experimentierfreude von Grund auf zu entwickeln 😉

    Ach so, ich dachte mit Indieszene meinst du soetwas.
    Bei Minecraft z.B. bezweifele ich, dass Notch das Spiel von Anfang an verkaufen wollte. Ich denke, er hat eher aus Spaß angefangen.
    Du redest von professioneller Indieszene, ok, dann war das ein Missverständnis. 🙂


  • Mod

    Nexus schrieb:

    rapso schrieb:

    SDL/SFML sind ja eher high-level wrapper von APIs mit ein paar utilities, die meisten werden dennoch ihren wrapper haben, man hat am ende also
    CustomWrapper(OpenSourceWrapper(Api()));
    was nicht soviel sinn macht.

    Warum machen mehrere Abstraktionsebenen keinen Sinn? Man muss natürlich den CustomWrapper nicht genau wie die Open-Source-API aufbauen, sondern auf einer höheren Abstraktionsebene. Wenn man z.B. mit den Features und der Portabilität von SFML zufrieden ist, warum sollte man das Gleiche nochmals in OpenGL, OpenAL, diversen spezifischen Bibliotheken und 3 verschiedenen Betriebssystem-APIs nachprogrammieren?

    1. die wenigsten erstellen fuer 3 verschiedene betriebssysteme, und das ist vielleicht maximal 1% vom code der api spezifisch ist. das argument hat noch keinen grossen developer bei opengl vs directx ueberredet, erst recht nicht bei 'irgendwelchen online sources'.
    2. viele dieser wrapper sind minimal, ob du jetzt ein fenster ueber SDL oder direkt android erstellst, ist recht banal.
    3. du limitierst dich zu dem was so ein wrapper kann, wenn er es nicht kann, feature request an den feature tracker und hoffen dass es mal jemand macht oder du musst es selbst irgendwie einhacken.
    4. wieso gibt es nicht nur einen einzigen, sondern alle zeitlang erfindet jemand yet another lib with a different name that already exists?
    5. kannst du deine hand ins feuer legen, dass in einem open source projekt alles mit rechten dingen abgeht, dass da niemand mitarbeitet der sourcen kopiert hat mit z.b. GPL sodass dein fast fertiges PS3 spiel ploetzlich nicht released werden kann. oder dass da jemand arbeitet dessen arbeitgeber dein konkurent ist und z.b. per arbeitsvertrag sich alle rechte an jeglichem source gesichert hat den jemand zur zeit der anstellung entwickelt hat und damit von dir nach dem release license gebuehren pro kopie verlangen kann (selbst wenn du ein kostenloses spiel rausgeworfen hast) ?

    rapso schrieb:

    woher hast du diese info? ich kenne keinen indie der es jedesmal neu schreibt

    Ich meinte weniger bei jedem neuen Spiel desselben Studios, sondern bei jedem Studio (natürlich kann man nicht den Code anderer Studios verwenden, aber eben existierende freie oder kommerzielle Engines).

    da kommt punkt 4. auf, wenn nichtmal die open source leute sich auf eine open source engine einigen koennen, sondern immer wieder das rad neu erfinden, wieso sollte da ein indie studio nicht eigene tools entwickeln statt open source? etwas eigenes zu haben worueber du alles weisst und dir bei der implementierung ein eigenes design gedacht hast, kann viele vorteile haben. z.B. fragt mal sony ploetzlich bei dir an, ob du dein indie spiel nicht auf PSN bringen moechtest, wie lange wird das dauern... jetzt musst du ueberlegen "bekomme ich das open source tool portiert? oder schmeisse ich es raus und bastel alles nach? hm, was wird wohl wie lange dauern, noch nie gedanken darueber gemacht"...gibt es SDL fuer ouya? (ich weiss es nicht, vermute aber mal nicht), falls nicht, wer macht sich jetzt die arbeit damit...
    und nichts ist schlimmer am markt, als einer zu sein der es genau so macht wie alle anderen, du brauchst was, was du sehr gut kannst. Unity,UDK,CryEngineFree sind grundverschieden in allem was du dir rauspickst, das ist bewust so. wenn du dir indie spiele anschaust die erfolgreich sind, siehst du meistens dass der schwerpunkt auf etwas liegt, was so noch nie da war. "Flower" hat unmengen an grass rendering, little big planet hat eine sehr flexible stabile engine (kannst also 'noobs' mit der engine machen lassen was du willst und es funktioniert einfach). world of goo, super meat boy, rez... das worauf es dort ankommt ist mit viel zeit entwickelt worden, das was open source dazuliefern wuerde, waeren die 'basics' und viele features die du nie nutzen wirst, was dich aber einarbeitungszeit kostet und damit es nutzbar gemacht wird, musst du es am ende dennoch 'anpassen'.

    Wenn ich richtig informiert bin, wurde für Super Meat Boy eine Engine geschrieben (->). Bei Vessel ist von einer "custom built engine" die Rede, es ist allerdings nicht klar, ob diese nur Physik, KI und Audio betrifft, oder auch Grafik (->). Fez wurde mit XNA entwickelt (->). Bei Dustforce wird auch von einer Engine gesprochen (->). World Of Goo verwendete SDL und weitere Open-Source-Bibliotheken (->). Sind zumindest ein paar Indie-Games, die ich gerade kenne...

    und ich bin mir sicher die verwenden ihre engines oder teile davon immer weiter. sowas wie Box2D ist echt nuetzlich und gut, kleines module (nicht ein bloated uber-monster), solide, einfache api. das wird in sehr sehr vielen spielen verwendet (z.b. angry birds).

    rapso schrieb:

    bis auf preis, sehe ich nichts was open source engine so gut machen wuerden dass man auf unity verzichten wuerde

    Ja, war wie gesagt mehr im Vergleich zu "selbst schreiben" als "Komplett-Engine verwenden" gedacht. Das Problem mit Open-Source-Libraries ist neben fehlender Finanzierung/Manpower wohl auch gerade die kleine Verbreitung im professionellen Umfeld, was sich wiederum negativ auf die Entwicklung auswirkt.

    und gerade da sehe ich keinen vorteil in open source. willst du eine engine, licensier eine, da bekommst du auch den source. auf der anderen seite, einige open source dinge, die gut sind, z.b. Qt, kosten dich dann dennoch geld. Open source sollte nicht mit 'kostenlos' verwechselt werden, there is no free lunch, irgendwie zahlst du am ende dennoch (meistens, gibt ja ausnahmen wie box2d).

    Wie sieht das üblicherweise aus, wird bei fertigen Engines wie Unity überhaupt noch C++ verwendet? Die Skripts sind ja vor allem auf C# ausgelegt.

    wenn du die engine licensierst, kannst du mit c++ arbeiten soweit ich weiss. die meisten grossen spiele werden meines wissens nach so gemacht, auch auf konsolen wo es bald unity gibt willst du vermutlich nicht c# nutzen.
    ich programmiere gerade mit c# fuer die vita, das ist echt grausam langsam, der gc kann dich umbrigen, weshalb du noch deinen eigenen garbage collector mittels free-lists brauchst und einfach eine simple OOP klassensamlung fuer path finding (was kein problem auf iOS/Android mit c++ ist) auf primitive arrays umzuschreiben, hat 3x performance gebracht bei mir. dieselbe erfahrung hatte ich damals mit java auf android gehabt.
    wenn du dir die psm foren dazu anschaust, meckern alle ueber die performance, sogar die c# fans koennen das nicht leugnen. das ist wieder: there is no free lunch.



  • tl;dr: Die genannten OpenSource-Projekte sparen vielleicht ein Wochenende, maximal eine Woche. Das ist kaum relevant wenn man 3-6 Monate an einem Spiel sitzt. Dafür handelt man sich aber nicht die ganzen Nachteile ein. (Man muss sich erst einlernen, Code anderer Leute debuggen, ist weniger flexibel, ...)



  • Ich bin mit vielem einverstanden, und sehe auch, dass Neu-Schreiben einige Vorteile hat. Es hängt wohl damit zusammen, wie lange man an seinem Indie entwickelt, und wie gut man die benötigten Features im Voraus abschätzen kann. Was ich aber auch glaube, ist dass gewisse Open-Source-Bibliotheken schlicht zu unbekannt sind oder schon nur deswegen nicht verwendet werden, "weil man das als professioneller Spieleentwickler nicht macht". Genauso wie jeder professionelle Musiker einen Mac haben muss :p

    Ich werde mich im Folgenden daher vor allem auf kontroverse Punkte beziehen. Ausserdem werde ich SFML als Beispiel bringen, da ich diese Bibliothek am besten kenne.

    rapso schrieb:

    4. wieso gibt es nicht nur einen einzigen, sondern alle zeitlang erfindet jemand yet another lib with a different name that already exists?

    Hast du schon mal SDL mit SFML verglichen? Da liegen Welten dazwischen. Alleine schon weil SFML eine äusserst saubere C++-API hat, sehr leicht zu benutzen und massiv schneller ist. Sowas wie SFML gabs zuvor nicht.

    rapso schrieb:

    5. kannst du deine hand ins feuer legen, dass in einem open source projekt alles mit rechten dingen abgeht

    Nein, aber das kannst du bei einem Closed-Source-Projekt noch viel weniger. Wer garantiert dir, dass nirgends Code kopiert wurde? Wenn niemand den Code sieht, kann sowas viel eher unbemerkt bleiben.

    rapso schrieb:

    sowas wie Box2D ist echt nuetzlich und gut, kleines module (nicht ein bloated uber-monster), solide, einfache api.

    Schau dir mal SFML an. Eine der am saubersten designten C++-Bibliotheken überhaupt. Schön leichtgewichtig und modular, du kannst auch nur einzelne Teile davon linken. Und du kannst es problemlos mit eigenem OpenGL-Code kombinieren. Oder gleich das ganze Rendering über OpenGL/DirectX lösen und nur andere Features verwenden.

    SFML ist eben noch nicht so verbreitet, weil es vergleichsweise jung ist. Aber die Community ist stark am Wachsen, sehr viele Leute wechseln auch von SDL oder Allegro.

    cooky451 schrieb:

    tl;dr: Die genannten OpenSource-Projekte sparen vielleicht ein Wochenende, maximal eine Woche.

    Ja, bestimmt. Die Bibliotheken werden ja primär aus Langeweile über Jahre hinweg entwickelt.

    Was du meinst, trifft vielleicht auf Fenster-Erstellung und direktes Zeichnen mit OpenGL/DirectX zu. Das kriegt man noch schnell mal hin. Bedenke, dass die Bibliotheken aber viel mehr enthalten, z.B. SFML: Speichern/Laden diverser Bild-, Schriftart- und Audioformate, Darstellung von Text, GLSL-Integration, Abspielen von Soundeffekten und Musik, simple Netzwerkanbindung (portable TCP/UDP-Pakete), Unicode, portable Zeitmessung. Natürlich benötigst du davon üblicherweise nicht alles.

    Aber wenn du viele solche Funktionalität brauchst, musst du dir dennoch alles aus diversen Low-Level-Bibliotheken zusammensuchen. Und dann hast du x verschiedene Codestile und Lizenzen, musst alles richtig einbinden und konfigurieren, etc. Das ist viel mühsamer als eine schöne Schnittstelle mit konsistentem Design. Und du wirst beim Selbst-Schreiben auch mehr Bugs haben als eine über Jahre verwendete (und oft auch ausführlich getestete und optimierte) Bibliothek.



  • SFML gibt dir wenig Kontrolle darüber, wie genau der GL Context erzeugt wird, Dinge wie Enumeration verfügbarer Hardware etc. sind überhaupt nicht abgedeckt, für professionelle Anwendungen aber durchaus nicht unwesentlich, wenn du das willst, heißt es erstmal, die SFML in ihren Grundfesten ganz ordentlich umschreiben und wenn du da dann anfängst, kannst du dir das auch gleich selber bauen...



  • Wenn ich die Antworten hier richtig verstanden habe, dann nutzen die Leute deswegen so wenig bis gar keine OpenSource-Libs weil sie dadurch Zeit und damit Geld verlieren. Viel Geld für einen kommerzielle Engine auszugeben ist anscheinend billiger als sich in andere Libs einzuarbeiten und diese anzupassen. Nix ist so teuer wie Arbeitszeit.

    Als Beispiel nehme ich mal Photoshop, dafür 1000,-EUR auf den Tisch zu blättern ist viel billiger als mit einem kostenlosen oder günstigen Programm täglich einen schlechteren Workflow zu haben, da dass dann bis jedem Auftrag Geld kostet, da man nicht so gut vorankommt und dadurch weniger schafft.

    Geld auszugeben kann viel Geld sparen.



  • Nexus schrieb:

    Bedenke, dass die Bibliotheken aber viel mehr enthalten, z.B. SFML: Speichern/Laden diverser Bild-,

    10 Minuten auf Wikipedia für .bmp und .tga - und wenn man seinen Kram eh packt, bekommt man .png quasi gratis dazu.

    Nexus schrieb:

    Schriftart-

    Das ist nett, aber bekomme ich den Kram dann auch in meine Shader rein oder muss ich SFML das zeichnen lassen?

    Nexus schrieb:

    und Audioformate,

    Kann ich das Abspielen von Sound dann in meine eigene Job-Queue integrieren, oder erstellt SFML da eigenständig irgendwelche Threads? Kann ich steuern ob SFML z.B. WASAPI nutzt?

    Nexus schrieb:

    simple Netzwerkanbindung (portable TCP/UDP-Pakete)

    Kann das mit boost::asio mithalten, oder ist das eher ein mini-C++-Wrapper um ganz normale Berkeley Sockets?

    Nexus schrieb:

    Unicode

    Ich wusste gar nicht dass man mit SFML auch Textbearbeitung machen kann. Oder ist damit gemeint dass man Unicode Text zeichnen kann? Nun ja, noch mal 30 Minuten gespart. Das summiert sich ja wirklich.

    Nexus schrieb:

    portable Zeitmessung.

    Du meinst std::steady_clock/std::high_resolution_clock?

    Nexus schrieb:

    Aber wenn du viele solche Funktionalität brauchst, musst du dir dennoch alles aus diversen Low-Level-Bibliotheken zusammensuchen. Und dann hast du x verschiedene Codestile und Lizenzen, musst alles richtig einbinden und konfigurieren, etc. Das ist viel mühsamer als eine schöne Schnittstelle mit konsistentem Design.

    Es sei denn ich schreibe es einfach selbst.

    Nexus schrieb:

    Und du wirst beim Selbst-Schreiben auch mehr Bugs haben als eine über Jahre verwendete (und oft auch ausführlich getestete und optimierte) Bibliothek.

    Da habe ich leider gegenteilige Erfahrungen gemacht.

    SFML ist in vielen Bereichen einfach zu unflexibel. Es ist schön, dass sie ein high-level Interface anbieten wollen, aber das scheint mir leider nicht durchdacht genug ab einer gewissen Komplexität. Wenn sie die Sachen gesplittet hätten (z.B. man könnte mp3s laden und dann selbst abspielen, oder den Text selbst rendern, oder hätte mehr Auswahl was den Kontext angeht), würde das vielleicht schon ganz anders aussehen.



  • Okay, ich sehe, was ihr meint. SFML ist tatsächlich nicht so stark erweiterbar, da es die Philosophie hat, simpel zu sein und die wichtigsten Fälle abzudecken.

    Aber es scheint mir doch reichlich naiv zu glauben, dass man über Jahre entwickelte Funktionalität jeweils in kurzer Zeit selbst nachbauen könnte, noch dazu optimiert und mit weniger Bugs. Das klingt einfach nicht realistisch, zumal die Bibliotheks-Entwickler oft selbst jahrelang als professionelle Entwickler gearbeitet haben und dadurch recht viel Erfahrung mitbringen. Ich sehe auch nicht, wieso die gleichen Leute, die im C++-Forum jeweils "erfinde das Rad nicht neu" predigen, hier gegen ihre eigenen Prinzipien verstossen, obwohl die Argumente dieselben sind.

    Zudem gibts nicht nur schwarz und weiss: Man kann für gewisse Features Bibliotheken benutzen und mit eigener Funktionalität ergänzen. Man muss sich eben überlegen, wie lange man zur Anwendung der Bibliothek benötigt. Bei sauber designten High-Level-APIs kann die Einarbeitung durchaus nur wenige Stunden erfordern, was normalerweise in starkem Gegensatz zum Selbst-Schreiben steht. Ausserdem sind High-Level-Bibliotheken super geeignet für Prototyping. Man kann mit verschiedenen Features experimentieren. Falls man sich dann doch für eine eigene Implementierung entscheidet, verliert man immer noch weniger Zeit, als wenn man alle experimentellen Ansätze selbst implementiert hätte.

    cooky451 schrieb:

    Es sei denn ich schreibe es einfach selbst.

    Du verschätzt dich gerade gewaltig, du kannst niemals alles selbst schreiben. BMP liegt ja noch drin, aber bei JPEG lohnt sich der Aufwand längst nicht mehr. Schriftarten sind ebenfalls recht komplex (nicht unbedingt das Dateiformat, aber die richtige Darstellung). Gleiches gilt für Audio, Video, Unicode, und so ziemlich alles, was ein bisschen komplexer ist. Du musst nicht SFML benutzen, es gibt genügend andere Bibliotheken. Für Sockets scheinst du ja auch Boost.Asio (eine Open-Source-Bibliothek) zu verwenden.

    cooky451 schrieb:

    Du meinst std::steady_clock/std::high_resolution_clock?

    Ah, du meinst die mit der Millisekundenauflösung in Visual C++? :p

    So ein Bug reicht, um hochauflösende Uhren in C++11 unbrauchbar zu machen, sodass man für Portabilität doch wieder auf externe Bibliotheken ausweichen muss.



  • Wenn hier einer im Forum sagt, dass sich das Rad nicht neu erfinden nicht lohnt, dann hörst du darauf? 😃



  • Nexus schrieb:

    Aber es scheint mir doch reichlich naiv zu glauben, dass man über Jahre entwickelte Funktionalität jeweils in kurzer Zeit selbst nachbauen könnte, noch dazu optimiert und mit weniger Bugs.

    Was heißt hier optimiert? Wüsste nicht was man beim Fenster erstellen sonderlich optimieren sollte. Und wenn ich eh eine eigene Job-Queue schreiben muss, dann ist es natürlich effizienter wenn ich die Sounds dort integrieren kann. Gleiches Argument gilt auch für Schriften etc.

    Nexus schrieb:

    Ich sehe auch nicht, wieso die gleichen Leute, die im C++-Forum jeweils "erfinde das Rad nicht neu" predigen, hier gegen ihre eigenen Prinzipien verstossen, obwohl die Argumente dieselben sind.

    Ich predige das sicher nicht. Ich empfehle vielleicht offensichtlichen Anfängern sich mal SFML anzugucken, einfach weil die Wahrscheinlichkeit ziemlich hoch ist, dass die keine Sonderwünsche haben was die Schrift oder Threads angeht etc.
    Aber ansonsten vertrete ich eher die Ansicht, dass man sehr sparsam mit externen Abhängigkeiten umgehen sollte. (Jeder der mal versucht hat einige GPL-Projekte zu kompilieren, wird das zu schätzen wissen. 🤡 )

    Nexus schrieb:

    Ausserdem sind High-Level-Bibliotheken super geeignet für Prototyping. Man kann mit verschiedenen Features experimentieren. Falls man sich dann doch für eine eigene Implementierung entscheidet, verliert man immer noch weniger Zeit, als wenn man alle experimentellen Ansätze selbst implementiert hätte.

    So viele Features hat SFML dann auch nicht, als dass ich da groß experimentieren könnte.

    cooky451 schrieb:

    JPEG

    Noch nie benutzt, keine Ahnung wie komplex das ist.

    cooky451 schrieb:

    Für Sockets scheinst du ja auch Boost.Asio (eine Open-Source-Bibliothek) zu verwenden.

    Aber auch nur weil ich das Interface quasi genau so aufbauen würde. Das trifft aber leider auf ausgesprochen wenig Bibliotheken zu. Und selbst asio nervt mich, weil es an boost::system hängt.



  • Nexus schrieb:

    Warum werden Open-Source-Bibliotheken wie SDL, SFML, Irrlicht oder Ogre3D kaum für kommerzielle Spiele eingesetzt?

    Spontan fallen mir 3 mögliche Gründe ein:

    1. Prestige - Eine fertige Engine die für Lau angeboten wird (was auf Open Source zutrifft, trotz gewerblicher LGPL) klingt halt so, als würde man es ohne die Arbeit der anderen nicht schaffen.

    2. Kenntnisse - Das was man selber programmiert, kennt und versteht man besser als das Zeugs von irgendwelchen anderen Entwicklern.

    3. Urheberrecht - Auch wenn die vielen Open Source Lizenzen viel erlauben bleibt halt doch immer der juristische nachgeschmack. Die LGPL erlaubt z.B. die Verwendung als Lib, aber wenn man die Lib selbst ändert, dann muss man das wieder zur Verfügung stellen. Aber vielleicht will man das ja gar nicht, weil der Code murks ist oder man der Konkurrenz keine starke Waffe in die Hand geben will, also macht man besser alles selbst und dann kann kein Open Source Verfechter sich beschweren dass er zu kurz kommen würde.
    Bei kommerziellen Lizenzen werden die Eigentümer ja entschädigt in dem sie ihren Obulus erhalten und dann ist gut, dann hat man Ruhe. Bei Open Source wird's noch in 10 Jahren Community Mitglieder geben, die hier und da etwas zu kritisieren haben und sei es nur, weil man sich weigert, eine aktuelle DLL der verwendeten Open SOurce Lib mit einem Patch nachzuliefern.



  • rapso schrieb:

    1. die wenigsten erstellen fuer 3 verschiedene betriebssysteme, und das ist vielleicht maximal 1% vom code der api spezifisch ist. das argument hat noch keinen grossen developer bei opengl vs directx ueberredet, erst recht nicht bei 'irgendwelchen online sources'.
    2. viele dieser wrapper sind minimal, ob du jetzt ein fenster ueber SDL oder direkt android erstellst, ist recht banal.

    Das wird ständig behauptet, aber es stimmt nicht!

    Klar, für das Fenster mag das gelten, aber wer hat schon Bock sich auch noch um die 100 verschiedenen Eingabegeräte zu kümmern?

    Versuch mal dem Gamer ohne SDL einen Spezial > 10 Tasten Joystick als Eingabegerät unter Linux anzubieten.

    Klar kannst du den Treiber auf Kernelebene direkt ansteuern, aber plattformneutral ist das nicht mehr und den Aufwand mußt du erstmal betreiben.
    Diesen nimmt die SDL für dich ab.

    Gleiches gilt für Threading und für Timingsachen, auch hier hilft die SDL ungemein.

    Wenn du das alles selber machst, dann mußt du unter Linux die Posix Threads und unter Windows eben die Windoes Threads direkt verwenden.
    Das bläht alles den Code auf und ist Arbeit, die man sich eigentlich sparen kann.

    Die SDL hilft hier also ungemein.

    Es geht also nicht nur um die < 100 Zeilen um ein Fenster aufzumachen,
    sondern auch um den ganzen Rest.

    Um das alles:
    Threading
    Input Devices
    Timer
    Grafik
    Sound

    plattformunabhägngi unter einen Hut zu bringen, müßtest du die Arbeit der SDL doppelt machen, wenn du das alles selber implementieren möchtest.

    Diese Arbeit kann man sich sparen und sich um den eigentlichen Gamingcode kümmern.

    Wenn für dich die Welt der Spiele natürlich bei DirectX endet, dann ist deine Meinung klar.
    Hier bietet DirectX ja schon alles was du brauchst, aber das ist eben nicht plattformunabhängig.

    oder dass da jemand arbeitet dessen arbeitgeber dein konkurent ist und z.b. per arbeitsvertrag sich alle rechte an jeglichem source gesichert hat den jemand zur zeit der anstellung entwickelt hat und damit von dir nach dem release license gebuehren pro kopie verlangen kann (selbst wenn du ein kostenloses spiel rausgeworfen hast) ?

    In welchem Land gelten solche Gesetze, das der Code, den man in der Freizeit daheim mit eigenem Strom und Computer entwickelt, dem Arbeitgeber gehört?

    wenn du dir indie spiele anschaust die erfolgreich sind, siehst du meistens dass der schwerpunkt auf etwas liegt, was so noch nie da war.

    Plants vs. Zombies 😃

    Auf so ne Idee muss man erstmal kommen.
    Das ist wie:

    Kühlschrank gegen Wassereimer



  • Nexus schrieb:

    Ja, bestimmt. Die Bibliotheken werden ja primär aus Langeweile über Jahre hinweg entwickelt.

    Was du meinst, trifft vielleicht auf Fenster-Erstellung und direktes Zeichnen mit OpenGL/DirectX zu. Das kriegt man noch schnell mal hin. Bedenke, dass die Bibliotheken aber viel mehr enthalten, z.B. SFML: Speichern/Laden diverser Bild-, Schriftart- und Audioformate, Darstellung von Text, GLSL-Integration, Abspielen von Soundeffekten und Musik, simple Netzwerkanbindung (portable TCP/UDP-Pakete), Unicode, portable Zeitmessung. Natürlich benötigst du davon üblicherweise nicht alles.

    Aber wenn du viele solche Funktionalität brauchst, musst du dir dennoch alles aus diversen Low-Level-Bibliotheken zusammensuchen. Und dann hast du x verschiedene Codestile und Lizenzen, musst alles richtig einbinden und konfigurieren, etc. Das ist viel mühsamer als eine schöne Schnittstelle mit konsistentem Design. Und du wirst beim Selbst-Schreiben auch mehr Bugs haben als eine über Jahre verwendete (und oft auch ausführlich getestete und optimierte) Bibliothek.

    Genau so sehe ich das auch.



  • cooky451 schrieb:

    SFML ist in vielen Bereichen einfach zu unflexibel. Es ist schön, dass sie ein high-level Interface anbieten wollen, aber das scheint mir leider nicht durchdacht genug ab einer gewissen Komplexität. Wenn sie die Sachen gesplittet hätten (z.B. man könnte mp3s laden und dann selbst abspielen, oder den Text selbst rendern, oder hätte mehr Auswahl was den Kontext angeht), würde das vielleicht schon ganz anders aussehen.

    In der SDL sind so Sachen wie TFT Support und Bildformate laden aus der SDL in eigene Bibliotheken ausgelagert (libsdl_ttf und so zeugs)



  • Einspruch schrieb:

    Versuch mal dem Gamer ohne SDL einen Spezial > 10 Tasten Joystick als Eingabegerät unter Linux anzubieten.

    Wie viele aktuelle Spiele laufen unter Linux und unterstützen dort "> 10 Tasten Joysticks"?

    Einspruch schrieb:

    Wenn du das alles selber machst, dann mußt du unter Linux die Posix Threads und unter Windows eben die Windoes Threads direkt verwenden.

    Und? Das ist doch trivial und ich seh grad nicht, welchen Mehrwert mir SDL_Thread im Vergleich zu den rohen APIs liefern könnte. Man bedenke auch, dass Threading mittlerweile sowieso direkt in Standard C++ supported wird...

    Einspruch schrieb:

    Das bläht alles den Code auf und ist Arbeit, die man sich eigentlich sparen kann.

    Also lieber das ganze Projekt mit unverhältnissmäßigen Abhängigkeiten würzen...

    Einspruch schrieb:

    Es geht also nicht nur um die < 100 Zeilen um ein Fenster aufzumachen,
    sondern auch um den ganzen Rest.

    Du meinst die < 100 Zeilen für

    Einspruch schrieb:

    Threading
    Timer

    Einspruch schrieb:

    Input Devices

    Dafür gibt es sicherlich auch unter Linux irgendwelche APIs und man muss nicht gleich auf eine riesige Library springen, von der man dann 1% benutzt...

    Einspruch schrieb:

    Grafik

    Wenn du mit den sehr begrenzten Möglichkeiten der SDL zufrieden bist...

    Einspruch schrieb:

    Sound

    OpenAL, fmod, ...

    Einspruch schrieb:

    In der SDL sind so Sachen wie TFT Support und Bildformate laden aus der SDL in eigene Bibliotheken ausgelagert (libsdl_ttf und so zeugs)

    Und du kannst die Fonts und Bildformate damit auch verwenden ohne die SDL zu verwenden?

    So Libraries wie SFML und SDL sind nett für Anfänger und Hobbyisten. Der Vorteil liegt aber weniger darin, dass sie einem so unglaublich viel Arbeit abnehmen, sondern eher darin, dass sie es einem ermöglichen, auch ohne tiefgehendes Wissen etwas ansehliches auf die Beine zu stellen. Und erreicht wird das, indem alles hinter einem entsprechend abstrakten Interface versteckt wird. Aber sobald die gebotene Abstraktion nicht exakt deinen Anforderungen entspricht, ist so eine Library mit einem Schlag unbrauchbar. Oder anders ausgedrückt: SDL und SFML sind super für das, wofür sie gedacht sind. Und das ist nunmal wohl, Spieleprogrammierung für Anfänger und Laien zugänglich zu machen. Jemand, der kein Anfänger oder Laie ist, wird sich dagegen dort nicht wohl fühlen...



  • cooky451 schrieb:

    Was heißt hier optimiert? Wüsste nicht was man beim Fenster erstellen sonderlich optimieren sollte.

    Dann ist ja gut, dass ich noch genügend andere Beispiele genannt habe 😉

    cooky451 schrieb:

    Aber ansonsten vertrete ich eher die Ansicht, dass man sehr sparsam mit externen Abhängigkeiten umgehen sollte.

    Diese Aussage basiert wieder auf einer falschen Annahme -- "wenn ich keine High-Level-Bibliothek nehme, habe ich keine Abhängigkeiten". Das stimmt eben nicht! Du kommst um Abhängigkeiten nicht herum, wenn du etwas mehr als die trivialen Dinge benötigst. Im Gegenteil hast du dann viel mehr Abhängigkeiten, weil du all die Low-Level-Bibliotheken wie libjpeg, libpng, libsndfile, Freetype, OpenAL, WinSock, etc. einzeln einbinden musst.

    cooky451 schrieb:

    So viele Features hat SFML dann auch nicht, als dass ich da groß experimentieren könnte.

    Ich habe ja schon gesagt, dass es nicht nur um SFML geht. Du kannst dir also echt nicht vorstellen, dass man durch eine High-Level-Bibliothek (Open-Source oder nicht) schneller ans Ziel kommt? Selbst wenn einzelne Dinge nicht ideal sind, bekommt man so sehr schnell eine Vorstellung der Machbarkeit und möglicher Implementierungsprobleme. Wenn man dann sieht, dass man einen komplett anderen Weg einschlagen muss, verliert man viel weniger Zeit als bei selbstgeschriebenem Code.

    cooky451 schrieb:

    [JPEG] Noch nie benutzt, keine Ahnung wie komplex das ist.

    Schau mal hier. Viele der genannten Funktionalitäten sind ähnlich komplex, nicht ohne Grund gibt es jeweils spezialisierte Bibliotheken.



  • Nexus schrieb:

    cooky451 schrieb:

    Aber ansonsten vertrete ich eher die Ansicht, dass man sehr sparsam mit externen Abhängigkeiten umgehen sollte.

    Diese Aussage basiert wieder auf einer falschen Annahme -- "wenn ich keine High-Level-Bibliothek nehme, habe ich keine Abhängigkeiten". Das stimmt eben nicht! Du kommst um Abhängigkeiten nicht herum, wenn du etwas mehr als die trivialen Dinge benötigst. Im Gegenteil hast du dann viel mehr Abhängigkeiten, weil du all die Low-Level-Bibliotheken wie libjpeg, libpng, libsndfile, Freetype, OpenAL, WinSock, etc. einzeln einbinden musst.

    Viele kleine Abhängigkeiten haben imo mehrere Vorteile. Insbesondere bekomm ich genau das, was ich brauch und nicht mehr, ich kann einzelne Komponenten nach Lust und Laune separat austauschen und updaten, niemand zwingt mir eine bestimmte High-Level-Abstraktion auf, ...

    Abgesehen davon, hast du diese Abhängigkeiten so oder so, oder was glaubst du, macht deine High-Level-Bibliothek unter der Haube? 😉

    cooky451 schrieb:

    So viele Features hat SFML dann auch nicht, als dass ich da groß experimentieren könnte.

    Ich habe ja schon gesagt, dass es nicht nur um SFML geht. Du kannst dir also echt nicht vorstellen, dass man durch eine High-Level-Bibliothek (Open-Source oder nicht) schneller ans Ziel kommt? Selbst wenn einzelne Dinge nicht ideal sind, bekommt man so sehr schnell eine Vorstellung der Machbarkeit und möglicher Implementierungsprobleme. Wenn man dann sieht, dass man einen komplett anderen Weg einschlagen muss, verliert man viel weniger Zeit als bei selbstgeschriebenem Code.[/quote]
    Schnell ans Ziel ist aber nicht das einzige, was zählt. Insbesondere in einem professionellen Umfeld, ist z.B. Qualität wohl auch nicht ganz unwichtig...



  • dot schrieb:

    Viele kleine Abhängigkeiten haben imo mehrere Vorteile.

    Da bin ich völlig mit dir einverstanden. Ich wollte nur sagen, dass man um gewisse Abhängigkeiten nicht herumkommt, auch wenn man vieles selbst schreibt 🙂

    dot schrieb:

    Abgesehen davon, hast du diese Abhängigkeiten so oder so, oder was glaubst du, macht deine High-Level-Bibliothek unter der Haube? 😉

    Ja, man hat sie noch und muss evtl. deren DLL mitliefern. Je nachdem sind sie aber auch gut wegabstrahiert, sodass man sie nicht alle einzeln linken muss und weniger Konfigurationsaufwand (gerade im Bezug auf Portabilität) hat.

    dot schrieb:

    Schnell ans Ziel ist aber nicht das einzige, was zählt. Insbesondere in einem professionellen Umfeld, ist z.B. Qualität wohl auch nicht ganz unwichtig...

    Das ist klar, ich bezog mich aufs Prototyping. Wenn man bereits viel Erfahrung hat und der einzuschlagende Weg schon im Voraus weitgehend bekannt ist, hat das natürlich weniger Relevanz.


  • Mod

    Einspruch schrieb:

    rapso schrieb:

    1. die wenigsten erstellen fuer 3 verschiedene betriebssysteme, und das ist vielleicht maximal 1% vom code der api spezifisch ist. das argument hat noch keinen grossen developer bei opengl vs directx ueberredet, erst recht nicht bei 'irgendwelchen online sources'.
    2. viele dieser wrapper sind minimal, ob du jetzt ein fenster ueber SDL oder direkt android erstellst, ist recht banal.

    Das wird ständig behauptet, aber es stimmt nicht!

    Klar, für das Fenster mag das gelten, aber wer hat schon Bock sich auch noch um die 100 verschiedenen Eingabegeräte zu kümmern?

    ich unterstuetze neben touchscreen, das sony xperia play pad, archos pad,hama creedroid und Ouya pad. ist das alles bei SDL dabei?

    ich arbeite auch an meinem kleinen Oculus support, fuer wann ist das bei SDL geplant?

    Versuch mal dem Gamer ohne SDL einen Spezial > 10 Tasten Joystick als Eingabegerät unter Linux anzubieten.Klar kannst du den Treiber auf Kernelebene direkt ansteuern, aber plattformneutral ist das nicht mehr und den Aufwand mußt du erstmal betreiben. Diesen nimmt die SDL für dich ab.

    klingt ja gravierend, welches spiel hast du nochmal gemacht das joystick support hatte und auf mehreren platformen vertrieben wurde?
    theoretisch hast du recht, praktisch: einspruch abgelehnt.

    Gleiches gilt für Threading und für Timingsachen, auch hier hilft die SDL ungemein. Wenn du das alles selber machst, dann mußt du unter Linux die Posix Threads und unter Windows eben die Windoes Threads direkt verwenden.
    Das bläht alles den Code auf und ist Arbeit, die man sich eigentlich sparen kann.

    1. kannst du eine der posix libs unter windows nutzen
    2. ist das threading bei mir in 3 kleinen klassen was platformspezifisch ist. task/job system etc. was cross platform ist hat sicherlich schon 10mal soviel code als thread erstellen, priority setzen, mutex, semaphore erstellen, locken.
    3. wuerde ich da lieber boost nehmen als SDL, sieht irgendwie sauberer aus.

    Es geht also nicht nur um die < 100 Zeilen um ein Fenster aufzumachen,
    sondern auch um den ganzen Rest.

    der ganze rest ist sicherlich <1% vom spiel und den schreibt man eh sauber gewrapped, da wohl niemand direkt auf einer externen api arbeiten wuerde.

    Um das alles:
    Threading
    Input Devices
    Timer
    Grafik
    Sound

    plattformunabhägngi unter einen Hut zu bringen, müßtest du die Arbeit der SDL doppelt machen, wenn du das alles selber implementieren möchtest.

    ich kenne ehrlichgesagt niemanden der raw drauf arbeitet, man schreibt sich also eh einen wrapper. den vorteil den man dann hat ist, dass auf neuen platformen fuer die es SDL nicht gibt, man eben nur seinen kleinen wrapper fuer diese platform portiert z.b. hatte ich so ein spiel in einer woche von iOS auf psp portiert. was machst du in dem fall? selbst die SDL auf neue platformen portieren? warten bis es die SDL dafuer gibt?

    Diese Arbeit kann man sich sparen und sich um den eigentlichen Gamingcode kümmern.

    diese arbeit hat man eh immer weil man seinen wrapper schreibt, ob man die platform api wrappt oder einen wrapper, die arbeit ist da, falls man es sauber und portabel haben will.

    Wenn für dich die Welt der Spiele natürlich bei DirectX endet, dann ist deine Meinung klar.
    Hier bietet DirectX ja schon alles was du brauchst, aber das ist eben nicht plattformunabhängig.

    meine platformen sind:
    -pc (linux,osx,windows)
    -tablet/phones (iOS,Android,Bada,Blackberry,WP8)
    -konsolen (DS,PSP,PSVita,PS3,X360)
    (-ehemalige platformen waren noch gba,gamecube,ps2)

    davon hat die SDL folgende unterstuetzt als ich die platformen verwenden wollte
    -pc
    kein android&NDS (ist erst seit nem jahr drinnen glaube ich), kein iOS, PSP, WP8, GBA, GC, PS2, PSV, X360, PS3
    einfach nur OpenGL (ES und EGL) und dazu OpengSL ES und du hast schon mehr abgedeckt fuer video/audio als SDL bei den relevanten platformen kann (nichts persoenliches gegen die dreamcast, GP32, Solaris, BeOS, usw. zielgruppe )

    wenn du dir indie spiele anschaust die erfolgreich sind, siehst du meistens dass der schwerpunkt auf etwas liegt, was so noch nie da war.

    Plants vs. Zombies 😃

    Auf so ne Idee muss man erstmal kommen.
    Das ist wie:

    Kühlschrank gegen Wassereimer

    es kommt oft nicht auf die idee an, sondern auf die realisierung. aber stimmt schon, das setting ist schon gut/spassig 🙂



  • von rapso zensiert


Anmelden zum Antworten