Open-Source-Bibliotheken in der Indie-Szene
-
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
Soundplattformunabhä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
TimerEinspruch 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.
-
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
Soundplattformunabhä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
-
zensiert von rapso
-
tut mir leid jungs, aber rechtliche sachen darf ich hier echt nicht behandeln, hab der fairheit halber auch meinen text zensiert. sorry. ihr koennt mich gerne deswegen anmotzen ;), aber forumsvorgaben aufgrund von gesetzen
-
rapso schrieb:
tut mir leid jungs, aber rechtliche sachen darf ich hier echt nicht behandeln, hab der fairheit halber auch meinen text zensiert. sorry. ihr koennt mich gerne deswegen anmotzen ;), aber forumsvorgaben aufgrund von gesetzen
Du weißt aber schon, dass man anonymisierte Fallbetrachtungen immer durchdiskutieren darf, das erlauben auch Gesetzte.
Wenn du also schreibst:
Der Chef von Herr A sagt Herr A, dass er in seiner Freizeit nicht programmieren darf und wenn er es doch macht, dann gehört der Code der Firma von Chef.Dann darf ich sagen:
*
Ich bin der Meinung das dies rechtlich nicht zulässig ist, weil....
*Juristisch ist das keine Rechtsberatung, deswegen ist es gesetzlich erlaubt.
Eine Rechtsberatung wäre wenn ich z.B. schreiben würde:
Hey Leute, ich habe hier ein Problem mit meinem Nachbar, weil....
was soll ich tun?und du dann schreibst
*
Stell ihm ne Unterlassungsklage und mache dies und jenes.
*Das dürftest du dann nicht, weil der Fall konkret ist, in diesem Fall könntest du lediglich auf einen Anwalt verweisen.
Also, es ist immer nicht alles so heiß gekocht, wie der juristische Laie immer glaubt.
Rechtsfälle dürfen, wenn sie anonymsiert sind, durchaus durchgesprochen werden.
Siehe auch, wie das andere Foren lösen (unter dem Link "was ist erlaubt" dürfte das wesentliche stehen):
http://www.recht.de/phpbb/viewtopic.php?f=13&t=111060Viel schlimmer, ein echtes Problem in eurem C++ Forum sind da eher eure nennung von Produktnamen und Personen. Sowie die Anwesenheit von Links auf diverse Seiten, inkl. Youtube.
In dem Rechtsforum ist folgendes nie erlaubt:
- Links auf Youtube und sonstige dubiose Quellen.
- Nennung von Produktnamen und Hersteller, diese müssen alle anonymisiert werden. Anstatt Microsoft kann man also schreiben, Softwarefirma aus Redmond.
- Angabne von realemn Namen. Das mit eurem Jürge Wolf, der hier öfters vorkommt, inkl. dem Aufruf seine Bücher nicht zu kaufen ist schon hart an der Grenze des erlaubten.Also, wenn ihr echte Rechtsproblemen aus dem Weg gehen wollt, dann solltet ihr erstmal an den obigen Fällen ansetzen.
Das was hier geschrieben wurde war okay und es gab keinen Bedarf das zu zensieren.
