Wärend meiner Arbeit an meiner MMOG Engine Karmarama ist mir ein Problem aufgefallen, welches man immer wieder und in allen Sprachen wieder an trifft. Das bei der Entwicklung einer Engine/Spiels immer wieder sehr viel Zeit in basis implementierung von Events/Signals, Zeit, Fenster, Grafik Context, Timer, Threads, Netzwerk Protokolle, Lineare Algebra, Multilanguage, Unicode und noch ein bischen mehr.

Bei C++ kommt noch dazu, dass man sogar noch Reflection(auch unter Runtime Service oder RTTI bekannt) und Serialisierung, sowie ab und zu auch Smartpointer(C++ ist durch die c basierten klassen total pointer verseucht und kann so schnell pointerfehler bringen) implementiert.
Java,C#,Delphi,Freepascal haben diese letzten angesprochenden Features schon fest in der Sprache Implementiert.

Da ein Framework heute mehr sinn macht, wenn es Cross ist steigt die Anforderung enorm, da man Typesafe mit an Bord bekommt und eventuell von Platform zu Platform noch zusätzliche Möglichkeiten bekommt bzw. Funktionalität selber Implementieren muss.

Ein solches Framework gibt es bisher nicht aber es gibt einige die schon gute Vorarbeit gezeigt haben und ein Teil der Anforderungen erfüllen.
SDL, DirectX und .Net bzw. mono sowie boost sind hier recht verbreitet und bekannt.

Ich habe vor wenigen Tage beschlossen die Notwendige Arbeit, die für solch ein Framework nötig ist, in Angriff zu nehmen, da ich es für meine Engine benötige. Diesen Teil habe ich los gelöst von Karmarama neu Aufgesetzt und nenne es, bis sich ein Name gefunden hat, DirectZ.
Das ganze soll unter BSD Lizenz und in C++ geschrieben sein, das ganze wird also als statische bibliothek in reiner Klassenform für C++ verfügbar sein aber auch die ganze Sache in C runter wrappen und als Dynamische Bibliothek anbieten. Dieser 2. Schritt ist dazu gedacht, dass auch andere Sprachen diese Bibliothek verwenden können. Da die Klassen auf C runter gewrappt werden kann man auf der anderen Sprache das umgekehrte wieder tun und von prozeduralen standardisierten c funktionen auf Klassen hoch wrappen und so z.B. in Freepascal dann gleiches verwenden.

Ich möchte die wichtigen Teile von .Net und Java API für Spiele in diesem Framework für C++ entwickeln und somit die Entwicklung vereinfachen.
So kann ein Java oder C# Programm dann einfacher auf C++ umgeschrieben werden und wer sich fragt, wieso denn überhaupt die Arbeit und nicht gleich Java oder C# mit Mono oder .Net, den kann ich nur sagen Java,C# und Co auf Geräten wie Nintendo Wii, PlayStation3, X-Box360, Mobile PC, Serversystemen(z.B. Bladecenter) sind in der Regel nicht verfügbar und wenn um ein vielfaches langsamer und resourcenintensiver. Bei Spielen kommt es auf Leistung an und je komplexer das Spiel wird des so schlechter schneiden die anderne Compiler im vergleich zu GCC und anderen C++ Compilern ab. Also ist es für Entwickler auf PC in diesem Bereich weniger Gewinnbringend, da auf PC die anderen Sprachen nahezu gleiche Performance erreichen können, wenn der Programmierer Ahnung von seiner Sprache hat.

Für Entwickler anderer Sprachen als C++ hat dies den Vorteil, das die Portierung auf C++ stark vereinfacht wird, da das ganze Backend das gleiche bleibt, was sich ändert ist ledeglich die syntax(von Programmen, die auf OpenGL basieren ja bekannt, überall ist der OpenGL Code der gleiche).

Interessanter ist für alle Programmierer nun aber eher die Implementierung von Spielespezifischen Klassen wie z.B. Inputdevices ala PS3, X-Box360, WiiMote oder bestimmten Joysticks und so weiter. DirectInput, von DirectX hatte es glanzvoll mal vor langer Zeit vor gemacht und mitlerweile wurde es eingestampft(DX8), weil man es nicht genug gepflegt hatte und keiner mehr groß nutzte.
Netzwerk ist oft ein größeres Problem, wo man dann sich irgendeine der vielen Bibliotheken lädt und dann anfängt beispiele um zu basteln um z.B. auf HTTP, FTP, SSL, NTP, ... zu zu greifen. Sowas kostet viel Zeit und man muss auch immer gucken wegen der Lizenz und ob es nicht vieleicht eine Bibliothek gibt die noch besser geeignet ist.
Scriptanbindung ist oft ein großes Problem, da man die Objektdaten, die man rausgeben will auch für eine spezielle Scriptsprache nutzen will und das verbinden kostet immer wieder viel Zeit und wird von vielen Entwicklern immer wieder neu gemacht.
Multilanguage ist auch ein großes Problem, was ist wenn man sein kleines Programm mit Unicode nutzen will, damit auch Menschen anderer Sprache und Symbolic es nutzen können. Dazu braucht man zum einen Unicode, Übersetzungsmechanik und Informationen über die Sprachliche Formatierung von Wärung, Zeit und so weiter. Sowas ist sehr aufwändig und oft unterstützen die genutzen Bibliotheken dann dies auch nicht.

Wenn ich beim Programmieren meiner Engine eines gelernt habe, dann das man nicht alles in eine Lösung pressen kann.
Darum mein Gedanke zur Bibliothek_
-Die Bibliothek definiert eine Schnitstelle auf die Funktionalität und kann durch verschiedene Backends auf unterschiedliche implementierungen zugreifen(z.B. PThread,WinThread backend).
-Die Bibliothek selber ist unter BSD und kann so ohne Einschränkungen für jeglichen gebrauch verwendet werden.
-C++ Klassen Umsetzung und Wrapper auf C um über dll/so anderen Sprachen verfügbar gemacht zu werden.
-Für Spiele-Engines notwendige Basisfunktionalität ist das primäre Ziel.

Um dieses Projekt Sinnvoll an zu gehen suche ich noch Leute, die Helfen wollen, indem sie z.B. beim Programmieren Helfen, entstehenden Programmcode bewerten, Interface Vorschläge und Kritik üben, Lösungen für Probleme anbieten, Dokumentation, Lektor, Beispiele schreiben, Unittests und so weiter. Es ist natürlich auch wichtig zu wissen was alles rein soll und was wichtiger als anderes ist.

Ich bin von der Java und .Net API für einige Klassen recht überzeugt, da sie von vielen Programmierern entwickelt wurde und schon lange reift.
Meiner Meinung nach kann man auch ganze Bibliotheken einfach wrappen, wie z.B. LibXML.
Hier denke ich auch an Adapter Pattern, diese nutzte ich bisher in meiner Engine, um über Plugins weitere Formate(xml,dds) hinzu zu fügen.
Über Plugins habe ich auch weitere Protokolle(filesystem) oder GraphicContext(OpenGL3,OpenGL2) hinzu gefügt.
QT hat das mit den Plugins recht gut vor gemacht.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hi,

im grunde genommen ist das was du da beschreibst das was ich mit meinem "Core" mache, bzw gemacht habe


Ich habe es bei mir in sachen Netzwerk, Threads, Fenster etc so gemacht, das der Programmierer einfach nur z.B. ein "CIThread" erstellt, und der core schaut automatisch nach ob es PosixThreads, oder WinThreads etc gibt und macht alles dementsprechend automatisch - je nach system das effektivste thread-system

Netzwerk etc genauso.. es gibt CISocket der je nach system nen wrapper für BSDSockets oder WinSock1/2 etc ist.

Renderer sind bei mir ebenfalls als Plugins eingebunden.. ich kann bei einer Scene einfach hin und herschalten zwischen OpenGL, OpenGLES 1, OpenGLES 2, Software Rasterizer und Software Raytracer..


Insofern alles recht ähnlich wie du es beschreibst = ich kann dich nur unterstützen in dem Vorhaben

Das einzige was mich extrem stören würde an deinem Vorschlag "libXML komplett wrappen".. wenn du schon dir die mühe machst eine standard library zu schreiben, würde ich so stark wie möglich versuchen auf fremde libs zu verzichten. Denn du sagst selber du willst so system unabhängig bleiben wie irgendwie möglich.. und es gibt nichts schlimmeres als wenn ich - nur um deine lib nutzen zu können - erstmal 20 andere libs compilieren muß.

Aber das ist nur meine Meinung - und ich weiß das ich damit recht allein dastehe

Aya~

Das klingt ja alles sehr löblich, aber für mich ist das nichts - ich bin ein Pascal-Fundamentalist und DLL's binde ich nur ein, wenns wirklich gar nicht anders geht, denn ich kann sie von Pascal aus nicht debuggen. Ich benutze hauptsächlich Lazarus, und da muss man Pionierarbeit leisten, um überhaupt mal an einen RC zu kommen, namentlich in Linux. Ich treibe ziemlich viel Aufwand, um DLL's so weit wie möglich vermeiden zu können.

Abgesehen davon kann ich meinen Senf dazugeben, wenn irgendein Problem auftaucht und hab auch nichts dagegegen, mal das eine oder andere Dokument zu streamlinen, wenns nötig ist. Übersetzungen ins Englische sind mir auch kein Problem.

Richtig aktiv mitarbeiten will ich nicht, denn ich kann C++ nur holperig lesen und schreiben schon gar nicht. Testen ist auch nichts für mich, denn von Pascal aus kann ich eine DLL nicht debuggen und ohne Debugger ist das Testen wenig sinnvoll.

Ich hätte gleich einen Vorschlag, denn ich beschäftige mich grade mit ODE bzw. dem Quickstep-Verfahren, das da drinnen steckt: man könnte für so ein Framework eine eigene Wiki-Abteilung schaffen und bei komplexen Utilities im Wiki einen Artikel bereitstellen, der sowohl das Verfahren erklärt als auch woher es stammt bzw. wer es als erster verwendet hat. Das schafft nicht nur Dokumentation sondern auch Rechtssicherheit.

So eine Arbeit würde ich gerne übernehmen, denn dabei kann man eine Menge lernen.

Das Stimmt nur dann, wenn es keine Pascal-DLLs sind...

Ansonsten finde ich einen Ansatz für ein solches Framework nicht schlecht, auch wenn Bibliotheken wie SDL schon einen Großteil der aufgeführten Features beinhalten. Warum nicht einfach eine Erweiterung dafür schreiben?

_________________
http://audorra.sourceforge.net//http://andorra.sourceforge.net

Man sollte nicht den Fehler begehen auf Fremdbibliotheken zu verzichten, viele sind bsd und können problemlos mit in den eigenen Code rein gepackt werden.
So sind z.B. gettext,lzma,libzip,pthread,libxml2 und einige weiter mehr als hilfreich und teilweise sogar problemlos nutzbar.
Wer versucht von jeglicher Dependencies weg zu kommen hat verloren, da dies einfach nicht möglich ist.

Bis auf libDirectZ.so ist alles standard gebundenes zeug vom compiler, also ich mag das nicht ersetzen und bestimmt nicht neu implementieren.
Ich glaube du meinst viel mehr unnötige Dependencies zu vermeiden und z.B. sowas wie lzma,libzip,libxml2 in plugins aus zu lagern und sowas wie gettext,pthread, welche auf jeden system verfügbar sind zu verwenden.

Abhängigkeiten auf andere Bibliotheken ist nichts schlimmes, man muss nur sicher stellen, das die Verfügbarkeit gewährleistet wird.
Auf Linux und Windows basierten Systemen ist das kinderleicht, da dies die 2 meist genutzen Platformen sind und entsprechend die Codequalität auf diesen recht stark geprüft wird. Windowsuser sind es heute gewohnt, dass sie ihre Platten mit der gleichen Bibliothek noch 40x zu müllen, da guckt doch keiner hin, ob das in system32 oder im Programmordner gelandet ist. Bei linux gibt es paketdienste und pakete erstellen ist ebenso kinderleicht und automatisierte Scripte können diese problemlos zusammen stellen und die dependencies mit angeben. Der wirklich einzige Grund für das nicht verwenden einer Speziellen bibliothek liegt nur in der nicht verfügbarkeit auf einer der Zielplatformen, alles andere halte ich für selbstbetrug.

libXML2 ist der Quasi Standard auf Linuxsystemen für arbeit mit XML und entsprechend ist die API ausgereift und das Featureangebot riesig. Ehrlich gesagt es ist die einzige ihrer Art. XML Parser für jegliche verwendungszwecke, XML generatoren, Validierung, XPath, XSL und so weiter sind alle implementiert und selbst unter einigen Windows Programmen zu finden. Es gibt 2 große Schnittstellen für XML einmal SAX und einmal DOM diese sind zum erbrechen groß und sprengen mit Abstand dem Umfang eines Programmierers. Das die Schnittstelle keine reine libXML Implementierung wird ist hoffentlich klar aber die default Implementierung will ich über libXML2 machen. Denn XML ist nicht nur ein textformat wo man mit ein kleinen selbstgebastelten Parser mal drüber huscht, das mag für die eine oder andere Private Lösung ausreichen aber daraus kann schnell mehr werden. Validierung über dtd ist ebenfalls ein Bestandteil von XML und nicht gerade unbeliebt.
XSL ist auch ein Bestandteil von XML und verdammt nützlich wenn man z.B. aus xml files Scripte, HTML files und ähnliches machen möchte. Ich glaube das möchte man nicht nochmal implementieren, nur weil man nicht eine Bibliothek mit liefern möchte. Wenn das libxml2 backend plugin fehlt, dann muss er hoffen das ein weiteres da ist, denn eine feste Implementierung wird es nicht geben, da Meinungen und Anforderungen zu weit auseinander liegen.



Die Idee finde ich gut bei der Umsetzung müsste man noch ein bischen was klären.
Ich denke, dass man das nicht in das DelphiGL wiki packen sollte, da es ja nichts mit zu tun hat also müsste ein eigenes Wiki her.
Als I0n0s, Frase und ich damals ein Wiki für X-Dream hatten, da hatten wir uns recht schnell verzettelt, da man Englisch und Deutsch wollte, dann immer die Artikel auf den gleichen Stand zu halten und überhaupt Aktualisierungen zu bringen bzw. was überhaupt Sinn macht hinein zu stecken ist dann mehr das Problem gewesen. Ich denke mal du würdest in so einem Wiki gerne eine Technische Doku sehen aber in welchen Maß ?
Ich bin z.B. kein Fan noch ein Wiki auf zu machen und dann etwas, was schon irgendwo steht noch mal zu schreiben, nur weil es zum Thema passt.


SDL ist eine andere Zielgruppe und seit einer weile frage ich mich ob die Entwickler überhaupt noch eine haben.
Diese Bibliothek hat sehr viele Probleme, welche damit anfangen, dass sie völlig veraltet ist(die entwickler kümmern sich nicht um regelmässige Updates siehe OpenGL3 was seit ewigkeiten im trunk liegt und nicht released wird), dann ist der Featureumfang sehr spärrlich, da es zwar ein Timecounter implementiert aber was ist mit Uhrzeit, Zeitrechnung, UTC/GMT, Zeitzonen, Lokalisierung, Timer, Zeitspannen erfassung ?
Wenn man es mit böser Zunge beschreiben möchte dann würde ich sagen, es ist praktisch um mal "ein" Fenster zu erstellen und mit OpenGL ein paar basis dinge zu testen aber jeglicher weiterer Schritt ist dann eigenarbeit.
Aya hat vorhin auch schon erwähnt, dass das direkte Implementieren von Bibliotheken ganz und garnicht dem Wort Standard entspricht und das ist völlig richtig. Man Entwickelt eine Schnittstelle und implementiert auf dieser dann Bibliotheken und SDL macht dies nicht.
Man kann nicht mal eben ein anderen Grafikbibliothekt als OpenGL verwenden, die implementierung ist im Sourcecode fest drin und fällt einen schon auf die Füße, wenn man Direct3D verwenden möchte.
Auch Lizenztechnisch ist das nicht möglich, denn SDL steht unter lgpl und schränkt Kommerzielle Projekte zu stark ein.
BSD ist eine völlig Anspruchslose Lizenz, du kannst mit dem Code machen was du willst egal unter welchen Bedindungen, du kannst dir sicher sein du bist rechtlich abgesichert. Du darfst nur nicht die Copyright vermerke vom Urheber entfernen und müssen mit geliefert werden, wenn sie als Textdatei beiliegen.
Der Code muss nicht bei gelegt werden, Änderungen müssen nicht weiter gegeben werden, keine distribution des Codes notwendig, du kannst sogar die binäre Form verkaufen. Firmen meiden Bibliothken, desen Lizenz offenlegung von Änderungen mit sich zieht aus verschiedenen Gründen. Ein wichtiger ist hierbei, dass man schlicht weg nicht die Zeit hat jede Änderung ein zu schicken und auch nicht möchte, dass ständig Personen Mails schreiben, dass sie den Sourcecode haben möchten. Das ist ein enormer Verwaltungsaufwand, den man da sich einhandelt und Zeit ist Mangelware in Firmen. Laut diverser Artikel und Vorträge, die ich konsumieren konnte, haben die meisten Firmen kein Problem damit die Änderungen raus zu geben aber nachdem das Projekt fertig ist und man möchte den Verwaltungsaufwand nicht. Bei einem Vortrag auf der Linuxtag von einem Manager von Sourceforge hat er gesagt, dass die meisten Updates von Firmenmitarbeiter comittet werden und diese bei MIT,BSD,Apache2 und ähnlichen Lizenzen wesentlich höher ist als bei gpl und lgpl.
Wieso denn überhaupt über Firmen reden ? Eine solche Bibliothek braucht entsprechende pflege und diese wird durch Hilfe von Programmierern und anderen Personen geleistet. Wenn Firmen solch eine Bibliothek nutzen, dann sind die Chancen auf eine bessere Verbreitung wesentlich höher und das bringt mehr Personen und das wiederum besseren Code und das wiederum weiter Personen. Für Sinnvolle nutzung muss man ein Quasi Standard erschaffen.
Das Wort ist schon mal am Anfang im Post aufgetreten und heisst nichts anderes, als dass es kein Standard ist aber jeder nutzt es und dadurch ist es dann doch ein Standard. Microsoft, IBM, Intel und AMD machen das regelmässig so, jeder wirft Schnittstellen für Grafik API oder ähnliches auf dem Markt und hofft das die Leute zu dieser wandern.
Um dann nochmal auf ein anderen Punkt ein zu gehen, nein SDL unterstützt nicht ein Großteil der aufgeführten Features, sehr sehr grob über den Daumen gepeilt ca 0.1%.

Ich will nicht eine .Net/mono Alternative in bibliotheksform programmieren, dazu fehlen mir die Mittel und ist für das eigentliche Ziel, den Spiele/Demo/Engine Entwickler das leben leichter zu machen weit vorbei. Ich kenne keinen derartigen Programmierer, der sagt dass er schon immer mal in seinem Spiel ActiveDirectory Regeln Verarbeiten oder als Systemdienste entwickeln wollte.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich dachte dein Zeitplan wäre knapp wegen deiner Mondlandung, Karmarama, dem OpenGL3 Kompendium und deinem Reallife, wieso versuchst du jetzt das nächste Godlike-Projekt zu starten? Davon mal ab halte ich es zwar für ne schöne Idee, aber mal wieder völlig übertrieben. Ich will garnicht wissen wie dick das Handbuch dazu werden soll ( und wer es mal eben in seiner Freizeit in alle Sprachen übersetzt ). Außerdem kenne ich dich aus dem Forum als eher konservativ, was Kritiken angeht ( für neuen PC-Schnickschnack gilt ja das Gegenteil wie man ständig liest ), also gehe ich nicht davon aus, dass man sich kreativ mit in das Projekt einbringen könnte, als dass man ein Schreiberling deiner Ideen wird. Als Argument betrachte man nur das Abschmettern der Worte meiner Vorposter.

Also kurz nochmal:

- Idee ist cool
- Umsetzung ist unreal
- Teamfähigkeit sehe ich bei dem Projekt eher weniger
- Ich würde das Produkt nicht einmal nutzen wollen, falls es irgendwer eines Tages umgesetzt bekommen sollte (Ein zweiter Urknall ist wohl etwa grob über den Daumen gepeilt 0.314% wahrscheinlicher), weil es zu groß werden würde
- Die Teamleitung hätte höchstwahrscheinlich einen stark beschnittenen Zeitplan

PS: eigentlich wollte ich nicht schreiben, aber da kribbelt es immer so, wegen diesem Traumgetänzel von NEUNEUNEU und überschwerster super Pro-Technik. Schlau und Informiert zu sein ist ne tolle Sache, aber aufm Teppich bleiben macht auch Spaß.

_________________
Klar Soweit?

Moah... Ich hätte es zwar nicht so krass wie Sellmann ausgedrückt, aber:

/fullack @ Sellmann

Grüße,
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Part-Time-Scientists ist eine Gruppe von vielen Menschen und unser Augenmerk liegt aktuell auf der Hardware, Softwaremässig ist es aktuell recht mau, um genau zu sein ist ohne den ersten Prototyp nicht viel machbar. Da ne menge zu Papierkorbarbeit verkommt aber es gibt halt themen die schon jetzt machbar sind und diese werde ich Teilweise auch mit diesem Projekt überkreuzen können. Zum anderen ist es eine Teilmenge von Karmarama, was am Framework gearbeitet wird ist automatisch für Karmarama gut. OpenGL3 ist etwas, was Kreativität benötigt und diese kann man bekanntlich nicht erzwingen, ich schreibe wenn ich solche Phasen habe und sonnst bleibt es auch mal einige Tage unangetastet. Da es Softwaretechnisch sehr schlecht auf dem Gebiet aussieht(Treiber kommen recht langsam, Updates von Frameworks noch viel langsamer) bzw. auch mit Lektüre(weder Tutorials noch Bücher sind bis dato Online), kann ich nur sagen ich sehe das nicht eng und es ist noch dazu etwas Freiwilliges wo sich noch niemand gemeldet hat ob er nicht vieleicht was zum Thema machen kann. Man kann nicht nur Konsumieren
Ich verstehe auch nicht, wieso wer glaubt, dass ich das alles alleine machen will ? Ich würde mich sogar freuen, wenn sich einige Leute finden und das gerne machen würden. Von mir aus auch ohne mein zutun, dann würde ich auch einfach nur die Verwaltung machen und könnte meine Zeit noch in neue dinge stecken.


Dieses Projekt ist meiner Ansicht geradezu Ideal für Kreatives, da es durch Backends beliebig Erweiter bar ist und die einzelnen basis Interfaces stehen doch genau jetzt zur Diskussion. Vieleicht ist das bisher nicht klar geworden aber deshalb hab ich doch geschrieben, dass um Hilfe jeglicher Art und auch Vorschläge zu Schnittstellen gerne gesehen ist. Ich habe auch schon geschrieben, dass ich von .Net/Mono und Java API recht angetan bin und diese entspricht z.B. garnicht der Schnittstelle von z.B. ähnlicher Karmarama Klassen. Also kann ich sagen, diese Befürchtung hat kein Nährboden.

Das kann vieleicht sein für mich ist sie eher ein völlig verspäteter und überfälliger Schritt für die Spieleentwicklung.
Ich würde mich sehr freuen, wenn du dazu mehr schreibst, da es so ohne jeglicher Basis schlecht zu bewerten ist.
Das kann sein, vieleicht bist du auch nicht die Zielgruppe, ist ja nicht jeder für zu begeistern aber dann sollte man auch kein VCL,LCL,DirectX nutzen, sonnst würde man sich wiedersprechen, denn diese sind noch viel Umfangreicher. Ist das der Fall dann gehörst du halt nicht zur Zielgruppe, das ist doch nicht auch nicht weiter schlimm.
Das soll eigentlich ein selbstläufer werden, meine größte Hoffnung liegt darin, dass die Leitung des Projektes auch von Zeit zu Zeit wechselt, wenn es für Personen schlicht mehr Möglich ist, aus welchen Grund auch immer. Ich stelle das ganze auch nicht ohne Grund BSD, die Rechte können so Problemlos weiter wandern und bedarf meiner wenigkeit nicht aber irgendwer muss solch ein Projekt überhaupt mal Anfang, sonnst passiert einfach garnichts.

Ich finde es gut, wenn man seine Meinung sagt, auch wenn sie für jemanden Unbequem ist und ich denke das merkt in meinen Antworten im Forum auch immer wieder. Vieleicht teilweise nicht ganz Diplomatisch, ich gebs zu aber von einen guten Kritik hat man nun mal mehr als wenn man garnichts sagt. Es ist mir auch viel lieber als Frase sein 2 Zeiler.
Wovon ich rein garnichts hab, wo ich nicht mal weiß wieso er Probleme und Vorteile sieht.

Ich denke es wäre Sinnvoll nochmal klar zu sagen was absolute Anforderungen an das Projekt sind und was eher was schönes ist.
Absolut wichtig ist:
-Das der Bibliothekcode in C++ und für GCC sowie Microsoft Visualstudio C++ Compiler Problemlos compilierbar ist.
-Ständig auftretende Probleme in der Spieleentwicklung lösen kann.
-Die Implementierung Platformunabhängig bleibt. edit: fehlerteufel Die Schnittstelle Platformunabhängig bleibt. Die Implementierung ist oft Platformabhängig.
Alles was sonnst noch erwähnt wurde ist Nice to have.

Ich hatte ein bischen Forschung vorher betrieben auch im Rahmen von Karmarama und die meisten Bibliotheken die ähnliches im Ziel hatten sind schlicht eingeschlafen, weil der Hauptentwickler nicht dafür gesorgt hatte, dass andere Programmierer weiter machen könnnen. So wurden z.B. schlechte dokus, fehlende out the box lösungen und noch schlimmer falsche lizenzen verwendet. Einige haben auch garnicht daran gedacht, was passiert, wenn sie keine Zeit mehr haben und wo die ganzen Daten und so weiter weiter zur verfügung stehen. Aktuell bin ich am überlegen, ob man nicht vieleicht sogar sich mal mit den Leitungen von führenden OpenSource Engines zusammen setzt und einfach mal über die Idee redet. Es soll ja die Arbeit von künftigen Programmierern erleichtern und sicher stellen das man nicht wochen und monate damit verbracht wird Fehler im Basiscode zu fixen. Hände hoch, wer schon alles Lineare Algebra in irgend einer Sprache implementiert hat, weil das suchen nach bisherigen Lösungen garnicht in den Sinn kam, man keine gute gefunden hat oder diese schlicht zu langsam waren oder z.B. nicht Objektorientiert oder unpassende Lizenzen haben(okey auf Lizenzen achten wohl die wenigsten xD). Was die leute an SDL und DirectX oft loben ist, dass sie vieles aus einem Werkzeugkasten bekommen und dies viel Zeit ersparrt. Wer will denn schon Code schreiben um ein Fenster oder ein OpenGL Render Context auf verschiedenen Platformen zu nutzen und wer mag sich in die API einer Datenbank(mySQL, PostgreSQL, lightSQL,..) einlesen, weil man kein Interface für Datenbanken in seinem Portfolio hat ? Bibliotheken existieren bereits, Interfaces wurden für verschiedene dinge schon von größten Projekten/Firmen implementiert und haben sich teilweise bewährt. Problemlösungen zu den meisten Themen, die hier auftreten sind bereits gelöst. Man muss halt nur wissen wer hat Ahnung oder wer könnte wissen wer sie hat und muss dann Fragen. Ich habe z.B. kein Problem auch mal Frase zu fragen ob er mir mal erklären kann wie java die Threads aufgebaut hat und wie das Handling ist und obs Beispiele und Doku vieleicht mal für mich raus suchen kann. Ich weiß das er mit Java täglich arbeitet und entsprechend das Wissen hat und dies viel Hilfreicher ist als meine 2 Semester Javaunterricht. Ich habe auch das Thema als erstes hier angeschnitten, weil hier nun mal viele Anfänger und fortgeschrittende Entwickler rum hängen, die wärend ihrer Zeit auf Probleme gestossen sind und genau hiermit versuche ich die Chance zu geben genau diese Probleme in entsprechenden Context los zu werden, damit künftige Entwickler dieses Problem nicht haben.

Dann habe ich noch eine Frage, da meine Post in der Regel recht lang und sehr ausführlich sind, würde es als besser empfunden werden, wenn ich diese Aufsplitte und z.B. zu einzelnen Personen oder Thematik in einen jeweils eigenen Post eingehe. Weil ich schon fast sagen würde "Ich weiß" dass dies abschreckt und schlicht garnicht bzw. überlesen wird und noch dazu man schlicht weg auch nur ein geringe Auffassungs Kapazität hat. Mir ist es im Rahmen dieses Thread z.B. aufgefallen das Dinge gesagt wurden, die ich vorher schon angesprochen habe und nun davon ausgehe, dass durch die Langen Texte es nicht gelesen wurde und somit auch Missverständnisse aufgetreten sind. Dies würde aber zu mehreren Post führen und könnte wiederrum als Flame ausgelegt werden.[/code]

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich muss zugeben das ich die Probleme kenne mit den veralteten Frameworks.

Aktuell bin ich ebenfalls soweit mir nen Framework zu basteln, welches als basis für meine Projekte dient,
welches genau die gleichen anforderungen wie die beschreibung von dem neuem Projekt enthält.

Was mich am meisten davon interessiert, wie du das mit den "Schaltern" löst, also wann entschieden wird,
welche Library verwendet wird und wie das Klassenmodell dazu aussieht.

Könnte mir gut vorstellen an dem Projekt mitzuarbeiten und mein beitrag dazuzuleisten.

Im Prinzip fallen mir 2 Varianten ein, die ich auch bisher selber verwendet habe.
Das erste Prinzip ist das definieren von Flags(#define SUPPORTSSE 1 oder #define THREADUSE PTHREAD), welche beim Compilieren festlegen ,welche Variante benutzt werden bzw. welche weiteren Funktionalitäten zu der existierenden frei gelegt werden solle.
Diese Variante sollte man versuchen zu Meiden, da sie halt einmalig ist und eine Erweiterung ohne neu compilieren verhindert.

Ich weiß nicht ob dir das Adapter Pattern geläufig ist darum hier nochmal ein Wiki Artikel den ich mal vor einiger Zeit erstellt hatte. http://wiki.delphigl.com/index.php/Adapter_Muster.
Die zweite Möglichkeit ist das nutzen von Factories kombiniert mit dem Adapter Pattern und Plugins.
Man definiert eine Schnittstelle z.B. IThread sowie IThreadFactory und die dazu gehörigen weiteren Schnittstellen wie z.B. ICondition, IMutex, je nachdem wie man das Design aufbaut.
Nun schreibt man eine Implementierung für z.B. PThread und die ThreadFactory, welche es erlaubt Instanzen von der pthread Implementierung zu erzeugen und diese über das IThread nach aussen verfügbar macht.

Beim Start des Programmes braucht man ledeglich eine der verfügbaren ThreadFactories sich herraus suchen und diese als Standard Factory definieren. Das erleichtert das Programmieren, wenn man über eine bestimmte Globale Variable oder Singleton Klasse Threads erstellt statt jedes mal den entsprechend gewählte Factory mit zu übergeben.
Dies geht natürlich nicht überall und ab und zu muss man wirklich die gewählte Factory übergeben, diesen Schritt musste ich in Karmarama bei den Rendercontext gehen, damit jedes Fenster nicht den gleichen Context besitzen musste sondern der eine OpenGL und der andere z.B. einen Software Renderer oder ähnliches sein durfte.

Der Adaptermanager ist hierbei das Sammelbecken für alle Implementierungen ala ThreadAdapterManager und die Adapter sind einzelne Factories für Implementierungen ala ThreadAdapter_PThread.
Damit der Adaptermanager die Adapter automatisch beim linken der fest eincompilierten implementierungen erhält, packt man üblicherweise eine statische variable mit in den cpp code der implementierung.
Sobald das Programm startet, wird die statische Variable angelegt und der construktor aufgerufen, damit registriert sich der Adapter selbständig. Um zur Laufzeit weitere Implementierungen hinzu zu bekommen, braucht man ein Plugin System, welches genau das gleiche ist wie die feste implementierung, nur das noch ein extra Plugincode hinzu kommt, der dem Pluginmanager sagt, was es für ein Plugin ist, ob es valide ist und je nach lust und laune des programmierers noch andere dinge tut. Ist es geladen dann bietet der AdapterManager eine neue Implementierung an, mit Factory und so weiter. Dann kann man eine Implementierung aussuchen und künftig nutzt jeglicher Code diese Implementierung.

Mal Auszüge aus meinen alten Code der ähnliches macht.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Na ja. Vielleicht ist ein 2 Zeiler auch einfach nur eine Zustimmung. Ich wollte aber eigentlich zu dem Thema gar nichts sagen. Was mitunter auch daran liegt, dass meine Ansichten in gewissen Asekten doch grundverschieden sind. Allerdings denke ich, dass dir das vielleicht helfen oder einen denkanstoß geben könnte. Das Projekt ist für mich alleine schon nichts, weil meine Projekte eine komplett andere Ausrichtung haben. Allerdings wäre das Projekt auch aus anderen Gründen nichts für mich. Denn was ich mitbekommen habe ist, dass du immer versucht alles mögliche gleichzeitig abzudecken. Und du dadurch dann deutlich zu komplizierte Konstruktionen erstellst. Und zwar so kompliziert, dass eigentlich niemand außer dir mehr damit klar kommt. Obendrauf kommt noch mal, dass du im Bezug auf so etwas schon ab und an mal deine Meinung änderst. Mir persönlich wäre das Risiko zu groß.

Das ist nicht böse gemeint. Aber ich denke, dass diese Punkte zu einem Problem werden könnten.

Mir fällt eigentlich kein Kompliziertes Konstrukt ein, was aus meiner eigenen Feder stammt aber das ist auch garnicht das Thema. Denn dieses Projekt dreht sich nicht um mich, sondern um alle die mit machen und wie etwas aussieht bestimmen die die daran mit arbeiten. Klar ändere ich auch mal meine Meinung, wäre dies nicht der Fall wäre ich wohl Allwissend und das ist niemand.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Das Adapter und Plugin Prinzip ist mir schon klar.

Ich Programmiere seit geraumer Zeit nach ähnlichem Prinzip in meiner Festanstellung als Entwickler.
Benutzte da keine Factories sondern eher eine art interface modell wie z.b. ein DirectShow Filter arbeitet.

Nur privat hab ich irgendwie kein kopf dafür, ist aber wohl auch deshalb so das viele Anwendungen die ich gemacht habe,
schlecht oder gar nicht erweiterbar sind.

Selbst Xenorate Media Player sollte damals auch nen Plugin Konzept bekommen "Version 3",
habe nur nichts brauchbares hinbekommen oder war einfach unzufrieden mit meiner code basis.



Hast du eigentlich sowas wie nen Konzept für das ganze Projekt schon ?
Also ne Detailiertere beschreibung was alles in dem Projekt getan werden muss und
vor allem was muss es später alles können (Detailiert).

Nein, weil dann wäre es ja auch wieder mein Projekt und meine Gedanken und das ist für diese Art von Projekt nicht sinnvoll.
Ich würde sowas gemeinschaftlich mit allen Interessierten erarbeiten.
Das einzige was ich vorgegeben habe sind die folgenden 3 Stichpunkte, die schon vorher gefallen sind.
-Das der Bibliothekcode in C++ und für GCC sowie Microsoft Visualstudio C++ Compiler Problemlos compilierbar ist.
-Ständig auftretende Probleme in der Spieleentwicklung lösen kann.
-Die Schnittstelle Platformunabhängig bleibt.

Mein Perönliches Ziel wäre bis Ende dieses Jahres den Umfang des Projektes definiert zu haben.

edit:1337 Beitrag ^^

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Es hat niemand behauptet, dass irgendjemand allwissend sein soll. Ich ändere meine Meinung auch von Zeit zu Zeit. Das gehört nun mal dazu, wenn man aus dem lernt was man tut. Aber lass mich das anders sagen. Ein Projekt bei dem jeder gleichberechtigt ist ist von vornherein zum Scheitern verurteilt. Die wahrscheinlichkeit, dass es totdiskuttiert wird ist sehr groß. Entsprechend muss es jemanden geben der die Oberhand behält. Und dann kann es schnell passieren, dass Ideen durchgedrückt werden die bei den Anderen nicht auf Gegenliebe stoßen. Das wiederrum kann schnell dazu führen, dass man alleine da steht und das Projekt machen muss. Und was ist wenn man urplötzlich irgendetwas anders machen will. Andere Sprache. Grundsätzliches Konstrukt anders. Als Benutzer von so einem Framework hat man dann die Wahl entweder nicht mehr updaten oder die Pille schlucken und seinen Code überarbeiten zu müssen.

Das ist keine Kritik. Sondern das ist etwas was du dir vorher überlegen solltest. Denn ich denke es dürfte nicht in deinem interesse liegen ein zweites SDL zu entwicklen. Zu mal es von den Strukturen her deutlich komplexer werden soll.