Ja wiedermal ein Thread von mir. Ich habe die letzte Zeit genutzt, um mir mal genauere Gedanken über mein Projekt zu machen und bin jetzt an der Stelle, an der ich mein Projekt grob designen möchte.

Feststeht: OGL und SDL

In Frage steht: Delphi oder Java


Und dann überlege ich derzeit, wie ich mein Projekt aufbaue. Ich bin mal so frei dazu eine sehr interessante Idee von Traude zu zitieren:


Nun kommt ihr ins Spiel: Ich kenne die meisten Vor- und Nachteile von Java und Delphi, mir geht es eher um eure persönliche Meinung, welche besser zum Arbeiten ist und ob an diesem ganzen "Java bringt ne scheiss performance (thanks to vm)"-gedöhns wirklich was dran ist. Einfach mal ne knackige Einschätzung der Sprachen

Ja und dann gehe ich mal davon aus, dass es sicher auch schon andere gab, die ähnliche Projekte einer Engine aufgesetzt haben; vllt können die ja mal ganz grob schematisch so wie Traude ihren Projektentwurf aufzeigen

Danke schonmal an euch

Auch auf die Gefahr hin mich unbeliebt zu machen. Wie sieht denn dein Projekt aus? Oder ist dein Projekt eine Engine zu schreiben?

Meiner Meinung nach brauchst du einen konkreten Anwendungsfall für eine Engine/API/Bibliothek. Du solltest also zu mindest grob wissen für was du eine Engine schreibst und was sie letzten Endes alles können soll. Auch bräuchtest du eine Anwendung in der du die Engine benutzt. So gesehen wäre eine Engine auch nur ein "Abfallprodukt" einer konkreten Anwendung/eines Spiels. Schau dir nur mal die kommerziellen Engines an. Es gibt zu ausnamslos allen Engines ein passendes Spiel.

Und da komm ich wieder zum Anfang. Als Erstes überhaupt musst du dir überlegen was du alles mit dem fertigen Produkt machen willst. Und wenn es nur eine Ideensammlung ist. Denn der Aufbau einiger Dinge ergibt sich mitunter schon aus den Anforderungen bzw. schließt einige Designs aus. Wenn du einen Plan für dein Projekt hast solltet du ihn evtl. auch hier kurz vorstellen. Einfach um auch auszuschließen, dass du unpassende Antworten bekommst.


Sprache: Kann man mit Java überhaupt SDL benutzen? Muss man das überhaupt? Denn das Fenster und der OpenGL Kontext werden doch eh anders erstellt. Und mir persönlich ist die VM zu Speicherhungrig und bei normalen Java Anwendungen die ich benutze habe ich häufig mit Verzögerungen (10-20 Sekunden) zu kämpfen. Ich bin aber auch absoluter Delphi/Pascal Anhänger.

Wenn du Java verwenden willst, fällt SDL außen vor, denn JOGL und LWJGL bringen ihre eigenen Routinen zur Erzeugung des Fensters bereits mit.
Was die Performance angeht, das ist meiner Meinung nach eher auf den zu Grunde liegenden Code abhängig und dann kann auch eine Delphi OGL Anwendung ruckeln
Was vielleicht auch wichtig wäre, wie fit bist du wirklich in den jeweiligen Sprachen? Bei JAVA wirst du sehr viel mit den Buffern aus dem NIO Package arbeiten und lose Bindung kann einem auch begegnen. Was nun die Fallstricke bei Delphi sind kann ich nicht beurteilen ^^"

Mehr Infos und wie Lossy schon sagte ein konkretes Anwendungsziel sind auf jeden Fall von Vorteil zur Beurteilung der Situation.

_________________
(\__/)
(='.'=)
(")_(")

Also ich arbeite ja mit Java kenne Delphi dafür nicht so richtig, also werde ich auch nur was in Bezug auf java sagen.
Bisher macht mir weder der GC noch das Speichermanagment größere Probleme und ich zeichne schon mehrere tausende Triangles ( keine Ahnung wieviele genau, ca. 5000 Objekte a 12-20 Triangles und einige größere Objekte). Das ganze schafft an die 100 Frames und läuft noch ohne Quadtree und irgendwelchem Culling. Speicher wird auch kaum verbraucht zur Zeit ca 1-2% von 2GB für das ganze Programm mit Netzwerk etc. mit dabei.
Klar für ein wirklich kommerzieles größeres Spiel ist Java sowieso nicht wirklich was, aber gerade was OpenSource und Plattformunabhängigkeit betrifft hat java denke ich keine Probleme (jedenfalls hatte ich nie welche unter Unix Linux Windows etc.).
Außerdem hat sich der 3DBereich bei Java auch enorm entwickelt und wird auch weiterentwickelt d.h keine tote Leiche im Keller. Zur Not gibt es sogar fertige Engines, verschiedene anbindungen an Opengl (Jogl, LWJGL). Allerdings sieht es mit Support nicht ganz so rosig aus wie hier
Eine kleine, auch subjektive, Einschätzung von mir, aber vll hilft sie dir ja
mfg revolte

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x

also ich hatte vor einer weile mal vor, das z-remake, was hier im forum mal angefangen wurde, in angriff zu nehmen. das wäre ein "usecase" für die engine ^^
vllt wirds jetzt etwas klarer

Das große Problem bei Java sind die fehlenden records. Objekte wie z.B. Vektoren werden außer in einigen Sonderfällen immer auf dem Heap anlegt und dadurch steigt der Speicherverbrauch laufend an. Irgendwann muss dann der Speicher während des Spiels bereinigt werden und dann kommt es vermutlich zu einer Verzögerung.
Delphi hat auch Operatorüberladung für records, so dass 3D-Berechnungen wesentlich einfacher und übersichtlicher werden.

Gut von der Sprache her gefaellt mir Delphi auch besser als Java, nur Java im Rational Software Development Kid ist eine wirkliche Offenbarung.
Ich könnte mich wahrscheinlich an ein paar fehlende Annehmlichkeiten von Turbodelphi Eclipse gegenüber gewöhnen, aber mein Turbodelphi will partout kein UML darstellen und das ist etwas, was mir ganz arg aufstösst. (ka ob das an mir liegt, aber ich bekomms nicht behoben)

Werd dann wohl mein UML aufm blatt machen oder in nem separaten programm und dann baue ich alles in delphi

Die Rational Software schlägt so ziemlich alles. Und selbst standard Eclipse als IDE ist für mich mittlerweile meine uneingeschränkte Nummer 1.

Einen Vector kann man durchaus auch in einem Array unterbringen. Aber ich hab bei mir in Java nicht wirklich auf solche Feinheiten geachtet und es lief trotzdem.
Mir geht es mittlerweile mehr darum wie gut mich die Sprache (+IDE) bei der Arbeit unterstützt. Ich kann dann auch eine 5 Sekunden längere Startzeit verkraften, wenn ich 100h schneller durchs Projekt komme. Im moment schreibe ich aber hauptsächlich an einem Web-Projekt welches mit JSP und Struts und , man höre und staune, SVG zu tun hat.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Sprachtechnisch kann ich erstmal sagen, Java ist durchschnittlich nur 5% langsamer(war mal ne zahl die ich in einen compiler benchmark gefunden hab) als c/c++ geschriebene alternativen aber realtime anwendungen wie Spiele ist es ein bischen anders.
Die Darstellung in 3D ist nahezu gleich zu Delphi und c/c++, die unterschiede kommen mit der Physik,KI,Szenenverwaltung und restlichen Code drum rum.
Physik,Sound,Ki werden in der Regel wie 3D über externe libs gemacht und damit nimmt es sich dann nicht viel aber wenn man wirklich teile selber schreibt kommt man selbst mit optimierten Code ned an c/c++ ran.
Java ist als Sprache klar vorzuziehen, es ist wesentlich unanfälliger als Delphi und kann auch später beim portieren die ganze sache erleichtern.
Spielt portabilität keine Rolle und du willst wirklich soviel wie möglich rausholen, dann eher Delphi.
Die beste Lösung ist natürlich c++ aber die steht ja nicht zur verfügung, da du sie ja schon ausgeschlossen hast.

Aufbau:
Eigentlich bekommt man nur geprädigt, GUI, Logik und Daten zu trennen und dann abstrakte Klassen zu definieren und Implementierungen auf diese zu bauen. Damit kann der Entwickler mit den abstrakten klassen arbeiten und sieht nicht die OpenAL oder FMod implementierung dahinter.
Ob die abstrakten Klassen nun wirklich abstrakte Klassen oder Interfaces sind ist ja dem Programmierer überlassen.

Ich mache das wie folgt.
1. Abstrakte Klassen für jedes Module(z.B. SoundBuffer,SoundManager,MusicManager,SoundFormatReaderAdapter)
2. ableiten von 1. mit entsprechenden Code(eigener Code oder wrapper für OpenAL/Ogg/Vorbis)
Also von SoundBuffer gibt es dann SoundBufferOpenAL und von SoundFormatReaderAdapter gibt es dann VorbisReaderAdapter.
Die SoundBuffer werden vom Manager erzeugt und verwaltet, damit kann man Buffer für OpenAL oder andere Libs gut implementieren.
Dieses Konzept findet überall bei mir verwendung auch beim zeichnen(TKar_ContextClass-> TKar_ContextOGL).
Der Zeichencontext erstellt die instanzen für die TKar_Mesh, TKar_Texture, TKar_Material, TKar_Shader Klasse.
Also sieht man immer nur TKar_Mesh aber die instanz ist eigentlich TKar_MeshOGL und durch virtual wird der call von TKar_MeshOGL verwendet.

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

Projekte: https://github.com/tak2004

Um evtl. Shaddow mal etwas vorzugreifen. Ich denke, dass man verschiede Klassen braucht, die abstract oder interfaces sind, ist sicherlich jedem irgendwo klar. Seine frühere Struktur war ja auch schon mit reichlich Klassen überseht. Aber ich denke das Hauptproblem besteht darin wie die einzelnen Klassen miteinander kommunizieren bzw wer was von wem wissen darf etc. Und vor allem wie die Hauptklassen miteinander verdrahtet sind. Also wie Eingaben (Tastatur/Maus) and die Objekte gereicht werden etc. Shaddow korrigiere mich, wenn ich falsch liege.


Shaddow: Ja ein Stategiespiel ala Z kommt der Sache schon näher. Ich meinte aber, dass du dir eher bewusst machen solltest was dort passiert. Bzw was es dort alles gibt. Die verschiedensten Gebäude, Fahr- und Fuseinheiten. Vor allem die machen/interagieren/effekte etc etc. Für eine Anwendung die ich gerne schreiben möchte (demnächst irgendwann mal) habe ich mir überlegt was die üblichen Anwendungsfälle sind und welche Menüpunkte/Befehle ich dort benötige. Also was ich für Funktionalität benötige. Keine Frage das kann man natürlich immer später noch nachlegen und verändern. Nur wenn du ein System auf die Beine gestellt hast und dann feststellst, dass etwas grundsätzliches nicht geht und du alles ändern müsstest oder fiese Einschränkungen in kauf nehmen musst, dann ist so etwas ärgerlich. Das Risiko kann man aber nie ausschließen egal wie lange man das macht. Das steckt eigentlich hinter dem "Plan und Gedanken" machen.

kürzlich bin ich über folgenden Artikel gestolpert.
Darin wird eine übersichtliche OO Struktur erläutert, die darüber hinaus sehr flexibel sein soll.
Leider habe ich bis jetzt noch nicht die Zeit gehabt, den Text genauer durchzuarbeiten. Aber da ich heute frei habe, werde ich das jetzt nachholen...

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Also ich finde JOGL nicht so berauschend. Performance technisch kommt es natürlich drauf an, wie umfangreich dein "Z" werden soll.
Aber bei umfangreicheren Sachen ist das Java merklich langsamer. Soweit ich weis, hast du bei JOGL auch Probleme, wenn du dynamisch neue Grafikelemente hinzufügen willst(irgendwelche neuen VBO's zB). Mit dynamisch meine ich heir Grafikdaten, welche nicht zur Initialisierunszeit vorliegen.
Von daher würde ich dann zu Delphi raten, da ja C++ wie schon angemerkt nicht zur Auswahl steht^^

Engine-Design technisch kannst du ja auch bei anderen Engines schauen, wie die es machen (Irrlicht z.B.)

MfG Pellaeon.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Also, meine Erfahrungen mit Java waren eigentlich auch nicht so berauschend, wobei ich zugeben muss, dass ich nicht allzu viel damit gemacht habe, speziell kein OpenGL.

Wenn du SDL verwenden willst, dann ist dir Delphi eigentlich eher eine Kugel am Bein. Denn wenn man SDL verwendet, möchte man es portabel haben (oder gibt es einen anderen guten grund?) und genau das ist es, was Delphi dir nicht bietet. Da solltest du dir mal FreePascal anschauen, in kombination mit der Lazarus-IDE. Du kannst natürlich auch weiterhin in Delphi programmieren und dir mühe geben, FreePascal-kompatibel zu bleiben, aber das ist nicht immer leicht. Zum Beispiel habe ich eine böse Überraschung erlebt, als ich ein Projekt von Delphi nach FPC portieren wollte und ohne es zu wissen nicht fpc-kompatible Units verwendete... Naja, die Fehler waren dann halt im wahrsten Sinne des Wortes vorprogrammiert.

Wenn dir die Plattformunabhängigkeit egal ist, ist es jacke wie hose ob du Delphi oder FPC+Lazarus verwendest.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

mh naja c++ ist mal prinzipiell nicht ausgeschlossen nur mag ich die sprache von der syntax eigentlich ncoh weniger als java
weiss nich so genau.. aber bei c++ könnte ich rational nehmen

und die syntax is java ja ziemlich aehnlich

Ich hab zwar mit Java bisher nur 2 Semester an der Uni zu tun gehabt (und erst recht nix mit OpenGL), aber meine persönlichen Erfahrungen von der Sprache an sich sind da auch nicht gerade sehr berauschend. Da ich nun schon seit Jahren mit Delphi auch an größeren Projekten arbeite und dadurch auch dementsprechend Erfahrung hab bin ich eigentlich nur dabei mich die ganze Zeit drüber aufzuregen wie umständlich manche Sachen in Jave sind . Liegt aber größtenteils daran das ich mich echt schon arg auf Delphi eingeschossen hab. Ich würde die wahl davon abhängig machen ob Plattformunabhängig sein muß oder nicht.