Archiv verlassen und diese Seite im Standarddesign anzeigen : 3D Engien
pfefferkeks
06-12-2004, 19:38
Hi,
ich moecht mal Versuchen einen eigenen 3D Engien selbst zu schreiben.
Jetzt die Frage da der auch unter linux laufen soll werde ich wohl auf opengl oder 3d java zurueckgreiffen muessen. Oder kennt jemand etwas besseres? Diskusion ist eroeffnet ;).
Desweitern benoetige ich dann noch Dockumentation dazu. Wie ich da vieleicht einen gleinen anfang hinbekomme damit ich ueberhaupt einen anfang finde. Kann mir da jenad helfen?
Desweiteren bin ich ueber jede Info oder nuetzliche ERfarungsberichte dankbar.
gruesse euer Pfefferkeks
peschmae
06-12-2004, 21:18
Du suchst Rat von der riesigen Schnittmenge von (Leuten die ihre eigene 3D engine geschrieben haben) mit (Leute die hier vorbeigucken). Hmm.
Ich weiss nicht wies jetzt mit java3d aussieht unter Linux. Aber als ich mich das letzte mal darüber informiert habe sahs düster aus - irgendwo blei Blackdown gabs eine (afair eingestellte) Implementierung und sonst nichts.
MfG Peschmä
Hi
so zu 3dengine ich habe angefangen eine zuschreiben. erst unter java3d aber das war mir zu schwer weil ich dort kein tutorial in deutsch gefunden hatte. ich kann englisch aber das war für mich doch zu schwer ;)
dann habe (bin ich immer noch dran) ich es in opengl geschrieben und es war durch zig tutorials auch sehr leicht.
Also meiner meinung ach würde ich es in opengl schreiben weil es einen noch viel schwerwiegenden vorteil hat. es ist schnell als java weil: interpreter ist zu langsam für 3dengine zu langsam. ja auch wenn nativ compiliert ist java wegen dem garbagecollector glaube ich zu langsam
mein tip also opengl
mfg gsus
PS: das soll nicht heißen das java3d nicht geeignet ist es ist nur einsteiger unfreundlicher denn man kann, wenn richtig programmiert aus java noch eine menge geschwindigkeit holen
Jetzt die Frage da der auch unter linux laufen soll werde ich wohl auf opengl oder 3d java zurueckgreiffen muessen. Oder kennt jemand etwas besseres?
Ich wuerde auf SDL und OpenGL setzen. Ist wunderbar portabel. Hab neulich meine kleine Engine von Linux auf MacOS X portiert und mein Kumpel hat seine auch unter Windows am laufen.
Desweitern benoetige ich dann noch Dockumentation dazu.
Das Standardwerk fuer OpenGL ist das Red Book: http://www.opengl.org/documentation/red_book_1.0/
Wie ich da vieleicht einen gleinen anfang hinbekomme damit ich ueberhaupt einen anfang finde. Kann mir da jenad helfen?
3D-Programmierung ist ein neues Feld. Wenn du da noch nicht so die Erfahrung hast solltest du dich da erst mal einlesen. Auch Mathematisch sollte man zumindest die Grundlagen etwas verstehen. Wenn man das ganze nicht gerade in der Schule durchgenommen hatte, muss man sich das selber aneignen. Da gibts einen recht guten Link: http://chortle.ccsu.edu/VectorLessons/vectorIndex.html
Desweiteren bin ich ueber jede Info oder nuetzliche ERfarungsberichte dankbar.
Ich habe diesen Sommer auch mit OpenGL angefangen und schon recht nette Dinge hinbekommen. Angefangen mit recht einfachen Dingen (hier (http://chrizel.com/archives/colormat.jpg))... zu einem kleinen Raum mit bewegenden Objekten (hier (http://chrizel.com/archives/das_konstrukt3.jpg))... dann hab ich auch schon recht coole Sachen wie Multiple Renderpasses hinbekommen: hier (http://chrizel.com/archives/das_konstrukt4.jpg).Dann ein kurzer Ausflug in die Vertex Shader Programmierung: hier (http://chrizel.com/archives/das_konstrukt5.jpg). Multitexturing: hier (http://chrizel.com/archives/das_konstrukt7.jpg).
Dann hab ich auch mal nen Nachmittag lang Direct3D ausprobiert, aber das lauft halt nur unter Windows: hier (http://chrizel.com/archives/d3d2.JPG).
Dann kamen die Heightmaps: hier (http://chrizel.com/archives/hmap7.jpg) und hier (http://chrizel.com/archives/hmap8.jpg).
Meine kleine Welt hab ich dann immer weiter ausgebaut. Auf einmal sogar mit Wasseroberflaeche: hier (http://chrizel.com/archives/hmap12.jpg).
Dann noch Mipmapping und Baeume: hier (http://chrizel.com/archives/hmap18.jpg) und hier (http://chrizel.com/archives/hmap19.jpg).
Dann kam eine laengere Pause und ich hab mich wieder mit anderen Themen beschaeftigt... vorletzte Woche habe ich noch meinen Octtree erweitert der jetzt schon einfaches Frustum Culling macht.
Alles in allem kann ich sagen dass ich noch sehr am Anfang stehe. Mir fehlt es vor allem am mathematischen Wissen um auf Dinge wie Occlusion Culling etc. zu kommen...
Hier musst du halt gucken ob du dir das aus mathematischer Sicht zutraust... die sachen die ich da oben gemacht habe sind alle relativ einfach zu bauen mit wenig Mathematik.
RapidMax
08-12-2004, 23:41
Ich würde dir auch zu SDL (OpenGL) raten. Ich habe selber noch nichts damit gemacht, aber neulich ein längeres Gespräch mit einem Studienkollegen gehabt, der nun professionell 3D-Programme entwickelt, mittels SDL unter Solaris/Linux.
Ich habe vor ca. zwei Jahren mit Java3D experimentiert: Es lieft unter Debian Woody ordentlich flott (Das mit dem Performance-Verlust durch Java ist nicht so schlimm, anfangs wirst du das sowieso nicht ausreizen). Dummerweise habe ich mir damit die Abhängigkeiten durcheinander gebracht. Das Java3D Paket war von Blackdown.
Gruss, Andy
pfefferkeks
09-12-2004, 09:31
Hi,
ersteinmal vielen DANKe euche allen.
Ich werde mir dan gleube ich openGL mal anschauen. ;)
Mal sehen wie weit ich komme!
mfg
Pfefferkeks
Zu OpenGL gibt es ein paar Tutorials. Ein nicht ganz so schlechtes gibt es bei
http://nehe.gamedev.net
1.) Java ist nicht wirklich nur interpretiert. Drum ist es beim Linpack auch genauso schnell wie C.
2.) Game-Engines brauchen keine superschnellen Sprachen (gibts sogar in Python - das ist wirklich nur interpretiert).
3.) Garbage-Kollektor macht Speicheranforderungen ca. 5x so schnell wie unter C
1.) Java ist nicht wirklich nur interpretiert. Drum ist es beim Linpack auch genauso schnell wie C.
Was ist Linpack? Meinst du Linux Paket?
2.) Game-Engines brauchen keine superschnellen Sprachen
Wenn sie das allerletzte aus der Hardware rausholen sollen, dann schon... und das ist bei 3D-Engines schon von Vorteil weil man ziemlich schnell an die Grenzen kommt. Desshalb sind die meisten modernen 3D-Spiele fast alle in C oder C++ entwickelt und das wird sich auch nicht aendern. (was nicht heissen soll dass ich grosser Fan von C oder C++ bin! Mir sind Sprachen mit Garbage Collection auch lieber!)
3.) Garbage-Kollektor macht Speicheranforderungen ca. 5x so schnell wie unter C
Gibts dazu Messungen?
(gibts sogar in Python - das ist wirklich nur interpretiert).Nope.
Gruß,
/dev
peschmae
10-12-2004, 09:59
Was ist Linpack? Meinst du Linux Paket?
Linpack isn benchmarking ding. Benutzen sie afaik u.A. um die Top500-Supercomputer-Liste zu machen.
MfG Peschmä
1.) Java ist nicht wirklich nur interpretiert. Drum ist es beim Linpack auch genauso schnell wie C.
Ich glaube du meinst C++. In manchen Dingen ist Java annähernd so schnell wie C++, aber Swing macht das ganze wieder kaputt.
Wobei das alles relativ ist! Denn es ist natürlich vom Compiler abhängig wie schnell/stabil deine Applikation ist und in C/C++ gibt es viele (und sie werden ständig verbessert).
3.) Garbage-Kollektor macht Speicheranforderungen ca. 5x so schnell wie unter C - und wenn eine game-engine viel garbage macht, ist sie eh vom design her, naja...
Der Garbage Collector kann 1. dein Game oder deine Applikation zum Ruckeln bringen, wenn er aktiv ist. 2. Kann er auch nicht mehr gebrauchte Objekte übersehen.
Liebe Grüße
Reality
peschmae
14-12-2004, 08:37
Ich glaube du meinst C++. In manchen Dingen ist Java annähernd so schnell wie C++, aber Swing macht das ganze wieder kaputt.
Ich glaube wenn Ceisserer Java schreibt meint er Java und nicht C++.
MfG Peschmä
Hi,
Ich glaube wenn Ceisserer Java schreibt meint er Java und nicht C++.
das ist das Problem. Viele setzen C und C++ gleich. Er schrieb, dass Java gleich schnell ist wie C. Das würde auf C++ schon eher zutreffen, aber C ist schon etwas schneller wie C++. Das meinte ich.
Liebe Grüße
Reality
.............................
Nein, einfach den Train-Collector benutzen (ist jetzt ein anderer Algorythmus nicht mehr der Train aber genauso kleine Pausen) mit -Xincgc
Dabei treten selbst bei großen heaps nahezu keine GCs auf die länger als 1ms dauern, dafür sinkt der durchsatz, aber müllen in der engine ist sowieso verboten.
Kenn ich ehrlich gesagt nicht. Ist der Befehl Xincgc nur beim gcj (oder wie der auch heisst) verwendbar oder auch beim Compiler von sun?
Und in 10 tagen ist Weihnachten! Nein - nix wird übersehen!
Keine Referenz drauf == tot bei voller GC!
Dir ist sicher bekannt, dass dispose() in Java 1.5 deprecated ist. Die Alternative ist der Garbage Collector. Ich habe ihn mal explizit aufgerufen und konnte keine Speicherplatzminderung feststellen. War aber auch nur ein 0815 Test, liegt vielleicht daran.
Der 10%ige Vorsprung von C ist hier relativ, da die C-benchmarks genau für die Zielhardware kompiliert worden sind.
In der Praxis tut man das nicht, und muss 20-35% Leistungsverlust hinnehmen. Java optimiert immer genau auf die prozerror-features, wenn SSE da ist, wirds verwendet, wenn nicht dann nur FPU.
Kannst du mir die Quelle mal dazu geben? Würde mich interessieren.
Ansonsten: Die VM ist auch nicht optimiert. ;)
Nein, die Compiler sind am Ende!
Optimierende C/C++ Compiler gibts seit über 15 Jahren, es wird heutzutage ziemlich alles gemacht was gerade noch erlaubt und möglich ist, die einzigen neuerungen sind feaure-anpassungen an neue proziis.
Das würde ich nicht sagen. Der gcc 3.4 soll z.B. 30% (wenn ich´s richtig im Kopf habe) schneller sein, als der Vorgänger. Außerdem hat man nicht alle Algorithmen und somit Optimierungen entdeckt.
Liebe Grüße
Reality
Scharn! das einzige was grenzenlt ist die Grafikkarte und dein prozessor beim verarbeiten von den OpenGL-Schamrn. Das bissi Kollision-Detektion und Logik machen heutige Prozessoren mit links.
(Sonst hätte man wohl nie eine Spiele-Engine in Python schreiben können, das 10x langsamer als Java ist (bei reiner codeperformance)).
Und wieso ist die Spieleengine in Python 10x langsamer? Irgendwie sehe ich darin keinen Wiederspruch zu dem was ich gesagt habe. Eher wiedersprichst du dich mit dieser Aussage selber.
Kenn ich ehrlich gesagt nicht. Ist der Befehl Xincgc nur beim gcj (oder wie der auch heisst) verwendbar oder auch beim Compiler von sun?
Das ist ein JVM-switch, also der Runtime übergeben, nicht dem Compiler.
Diesen Switch hat IMHO nur SUN, Bea und IBM bieten ähnliche switches an, die im grunde das selbe tun: Pausen minimieren auch wenn dadurch der Durchsatz leidet (oftmals ca nu 1/2).
Beim GCJ ist's was Garbage-Collector angeht leider etwas schlechter bestellt, der hat nur einen "Conservativ GC", der bei jeder Collection den gesamten Heap nach toten Objecten absucht und da dieser Kollektor eigentlich für C designt wurde, muss es noch raten, welche Variablen nun adress-pointer sind und welche nicht.
Zu gute halten muss man diesem GC ("Boehm GC"), dass er sehr portabel und gut getestet ist.
Dir ist sicher bekannt, dass dispose() in Java 1.5 deprecated ist. Die Alternative ist der Garbage Collector. Ich habe ihn mal explizit aufgerufen und konnte keine Speicherplatzminderung feststellen. War aber auch nur ein 0815 Test, liegt vielleicht daran.
1.) Dispose gibts nur bei Objekten mit Peers, wo ein GC nicht die richtige Methode zum Freigeben ist - gibts aber immer noch und wird auch bleiben.
2.) Java reserviert Speicher in einem eigenen bereich, dem sogenannten heap. Was du im taskmanager siehst ist die Größe des heaps, auch wenn der heap nur 10% voll ist belegt er mehr.
Das würde ich nicht sagen. Der gcc 3.4 soll z.B. 30% (wenn ich´s richtig im Kopf habe) schneller sein, als der Vorgänger. Außerdem hat man nicht alle Algorithmen und somit Optimierungen entdeckt.
Jo, beim Kompilieren, weil er (nun endlich auch!) mit vorkompilierten header-dateien umgehen kann *endlich*. Zur Laufzeit sind wenn du Glück hast im Schnitt 2% drinnen (auf x86).
Und wieso ist die Spieleengine in Python 10x langsamer? Irgendwie sehe ich darin keinen Wiederspruch zu dem was ich gesagt habe. Eher wiedersprichst du dich mit dieser Aussage selber.
Nein, das war natrlich nicht so gemeint.
Obwohl Python mind. 10x langsamer als Java oder C++ ist, ists bei einer Spiele-Engine annähernd egal, vieleicht läuft diese dann um 20% langsamer.
Hätten die das allerdings in C gemacht, wären die nie in den Genuss der excelenten Python-Sprache gekommen und hätten sich mit allerlei Low-Level Zeugs herumschlagen müssen - wären also nie soweit gekommen.
Abschließend bleibt mir nur noch die Nachteile von Java (=die Sun JVM aufzuzählen):
* Langsamer Start für kleine, grafische Anwendungen (-> Swing ist Overdressed)
* Hoher Speicherverbrauch (auch bei C#/.NET, dagegen kommt man bei VMs nur schwer an).
* Nicht OpenSource. Das ist meinem Meinung das allergrößte Problem, wird aber erstaunlicherweise überhaupt nicht ernst genommen.
Das sind so relativ alle Nachteile, welche Rang und Namen haben. Was der JVM über geschwindigkeit etc. nachgesagt wird ist schlicht und einfach falsch.
Relativ schade ist, dass es derzeit keine guten bytecode-VMs gibt, obwohl ich diese Technik sehr vielversprechend finde. Mono ist derzeit gut dabei, allerdings bringts Mono trotz arbeiten an der Runtime/GC erst auf ca. 1/3 bis 1/2 moderner JVMs oder .NET was Speed angeht.
Nein, das war natrlich nicht so gemeint.
Obwohl Python mind. 10x langsamer als Java oder C++ ist, ists bei einer Spiele-Engine annähernd egal, vieleicht läuft diese dann um 20% langsamer.
Dann zeig mal diese Spiele-Engine her oder gib einen Link. Ich denke mal 20% Geschwindigkeitsverlust sind da schon untertrieben. Ein Python Function Call ist allein schon >8x langsamer als bei C oder Java.
Hätten die das allerdings in C gemacht, wären die nie in den Genuss der excelenten Python-Sprache gekommen und hätten sich mit allerlei Low-Level Zeugs herumschlagen müssen - wären also nie soweit gekommen.
Ich kenne PyGame und einen Freund der sich damit sehr intensiv beschaeftigt hat. (http://pygame.org/). Das ganze ist recht nett und mag fuer einfache 2D-Spiele auch voll ausreichend sein, aber bei grafisch aktuellen Spielen kann ich es mir nicht vorstellen dass man das aus Python rausholen koennte. Du sagst selber 20% langsamer. Ich schaetze noch mehr, und bei 3D-Spielen (mit guter Grafik) zaehlt der Speed sehr wohl. Und es ist falsch zu glauben dass alles in der Grafikkarte ablauft. Die OpenGL-Befehle muessen schliesslich auch zur Grafikkarte geschickt werden und das bei jedem Frame.
Ich wuerde dann doch eher Common Lisp vorziehen, denn da habe ich Garbage Collection, dynamic und static Typing, Inkrementelle und optimierte Kompilierung (bis auf Funktionsebene) in Maschinencode, hoehere Abstraktionsmoeglichkeiten usw. Ein sehr bekanntes Spiel das zu grossen teilen auf einer Lisp-Implementierung setzt ist z.B. das PS2-Spiel Jak&Daxter und seine Nachfolger Jak2 und Jak3.
http://c2.com/cgi/wiki?LispInJakAndDaxter
Sorry falls ich euch vollgelabert hab, lg Clemens
Sorry auch von mir, ich will hier nicht grossartig diskutieren, mir gehts nur um Python bei Spielen... den Speed von Java zweifle ich gar nicht an... (dafuer aber andere Aspekte, aber das ist Off Topic :D )
peschmae
20-12-2004, 20:15
* Nicht OpenSource. Das ist meinem Meinung das allergrößte Problem, wird aber erstaunlicherweise überhaupt nicht ernst genommen.
Ist OpenSource :)
Nur nicht im Sinne der OSI. Aber das ist ein Detail ;)
Und ja, mich stört auch dass es das Teil nicht unter einer vernünftigen Lizenz gibt.
Was mich allerdings immer wundert ist dass es eine brauchbare freie Implementierung von .NET gibt (Mono, wies mit .GNU steht weiss ich nicht, aber deren Windows.Forms sieht auch gut aus) - und bei Java diesbezüglich immer noch arg an brauchbarem und aktuellem Fehlt.
MfG Peschmä
Jetzt wirds schön langsam interresant ;-)
Was mich allerdings immer wundert ist dass es eine brauchbare freie Implementierung von .NET gibt (Mono, wies mit .GNU steht weiss ich nicht, aber deren Windows.Forms sieht auch gut aus) - und bei Java diesbezüglich immer noch arg an brauchbarem und aktuellem Fehlt.
Naja, Mono wird meiner Meinung nach überbewertet, deren Runtime steht meiner Meinung nach noch immer erst am Anfang, ist vieleicht Kaffe ein wneig überlegen, aber das wars dann schon.
Windows.Forms werden schön langsam was, weil sie wine über bord geworfen haben und die windows.forms jetzt komplett neu in C# schreiben. Ich bin gespannt wie die das mit der geschwindigkeit hinkriegen.
Der Hauptgrund warum Mono so gut forwärts kommt, ist relativ simpel: Es gibt einfach keine Alternative!
Warum sollte jemand unter Linux (außer aus ideologischen Gründen) eine freie JVM verwenden, wenn es sowieso die SUN/IBM-JVMs gibt, die den selben Code 5x so schnell und 10x so stabil ausführen können?
Zu Mono gibts bis auf Portable.NET (was auch nicht besser ist) keine Alternative, drum arbeiten alle dran, dass Mono besser wird.
Ich hoffe Mono wird was - das wäre endlich das ende dieser unendlichen Inkompatibilitäten, nie wieder irgendwas kompilieren, wenn ich ein stinknormales Programm installieren will
peschmae
21-12-2004, 07:39
Mit .GNU gibts schon eine Alternative zu Mono, die imo unterbewertet wird. (Magst recht haben dass Mono überbewertet wird).
Allerdings gabs Java ja lange Zeit nicht (wirklich) für Linux. Auch zu der Zeit gabs keinen aktuellen freien Port von Java.
Bis Mono wirklich 100%ig kompatibel zu .NET ist dürfte wohl noch sehr viel Zeit vergehen: Microsoft schläft ja auch nicht (.NET 2.0 wartet schon) - und die 100%ige Kompatibilität zeichnet sich ja dadurch aus dass wirklich jedes kitzekleine Detail gleich ist weil sich garantiert irgendwer drauf verlässt dass dem so ist.
MfG Peschmä
Hmm, es kommt auch draufan, wie man Mono einsetzen will und als was man es sieht.
Mono wird auf keinen Fall das "nimm einfach eine beliebige .NET Anwendung von VC.NET und start sie an", wie man das von WINE erwartet.
peschmae
21-12-2004, 17:52
Hmm, es kommt auch draufan, wie man Mono einsetzen will und als was man es sieht.
Mono wird auf keinen Fall das "nimm einfach eine beliebige .NET Anwendung von VC.NET und start sie an", wie man das von WINE erwartet.
Wenn nicht wozu denn Kompatibilität mit .NET? Wozu das Risiko von MS-Klagen eingehen? Wieso dann nicht eine der bestehenden freien JVMs verbessern (in Bezug auf Linux-Funktionalität, weniger Nachbau von Java)? Wieso nicht was mit parrot?
MfG Peschmä
Wenn nicht wozu denn Kompatibilität mit .NET?
Nun, wenn sich der Entwickler an die Mono-APIs hält und die Schnittmenge mit .NET berücksichtigt gibts eh keine Probleme.
Wenn man sich aber heutige .NET-(Windows)-Anwendungen ansieht, kommt einem eher das Graußen.
Da wird haufenweise über PInvoke nativer Code aufgerufen, und das ist natürlic genauso portabel, wie Java mit JNI ;-)
Wieso dann nicht eine der bestehenden freien JVMs verbessern (in Bezug auf Linux-Funktionalität, weniger Nachbau von Java)?
Hmm, ne JVM tut nicht wirklich das, wozu .NET gedacht wurde. .NET soll eher ein virtueller Prozessor sein die die Maschine abstrahiert, eine JVM bietet dazu zu wenig Kontrolle über Speicher etc...
peschmae
21-12-2004, 22:47
Jaja, Parrot. Das Hauptproblem an Parrot ist, dass sie keine Class-Libraries mitliefern wollen.
So gut bin ich über das Projekt ja auch nicht informiert. Aber das kann man ja ändern.
Nicht das informiert sein meine ich, das mitliefern. ;)
Also wiedereinmal das typische (Linux-)Desaster:
Tonnenweise konkurrierende Projekte, obwohl sicher was viel besseres rauskommen würde, wenn alle zusammenarbeiten würden.
Vielleicht, vielleich auch nicht. Bei den Klassikern diesbezüglich (Editoren, DEs, etc) finde ich den Ist-Zustand gar nicht so schlecht.
MfG Peschmä
Also wiedereinmal das typische (Linux-)Desaster:
Tonnenweise konkurrierende Projekte, obwohl sicher was viel besseres rauskommen würde, wenn alle zusammenarbeiten würden.
Das siehst du so. So ist es aber definitiv nicht.
Da enststeht doch keine Konkurrenz, warum sollte man sich anstrengen?
Meine Meinung,
`kk
peschmae
22-12-2004, 06:35
Das siehst du so. So ist es aber definitiv nicht.
Da enststeht doch keine Konkurrenz, warum sollte man sich anstrengen?
Das einzige was dich motiviert ist dass es jemand anderes gibt der droht es besser zu machen als du :confused:
Naja, auf jeden Fall funktioniert das sowohl bei Scribus als auch bei K3b bestens - und bei beiden gibts nicht wirklich Konkurzenz (imo).
MfG Peschmä
Das einzige was dich motiviert ist dass es jemand anderes gibt der droht es besser zu machen als du
Naja, auf jeden Fall funktioniert das sowohl bei Scribus als auch bei K3b bestens - und bei beiden gibts nicht wirklich Konkurzenz (imo).
Vielleicht, vielleich auch nicht. Bei den Klassikern diesbezüglich (Editoren, DEs, etc) finde ich den Ist-Zustand gar nicht so schlecht.
Das siehst du so. So ist es aber definitiv nicht.
Da enststeht doch keine Konkurrenz, warum sollte man sich anstrengen?
Das ganze bezieht sich auch Programme - nicht auf Laufzeitbibliotheken/-umgebungen.
Bei Programmen schadet Konkurenz nie, solange es nicht tonnenweise verschiedenste Dateiformate etabliert werden, welche natürlich dann nicht kompatibel sind.
Bei Laufzeiumgebungen sehe ich das etwas anders:
Die einen Programme wollen Mono, die anderen Portable.NET und wieder andere wollen Parrot, Java und Python nicht zu vergessen.
Ja, dann gibts Konkurrenz, aber das ist nur schlecht, zudem anscheinend sich die Laufzeitumgebungen gegenseitig nicht anstacheln, so ist das jedenfalls bis jetzt.
Dann muss man 6 verschiedene Laufzeitumgebungen installieren und das Ziel des ganzen, eine einheitliche Laufzeitumgebung zu schaffen, welche endlich mit den Abhängigkeiten und den verschiedensten ABIs aufräumt, ist dahin.
Der Status-Quo ist unter Linux ja schon gegeben: GTK+ (besteht aus gtk, gdk, atk, pango, glib), QT (1.x, 2.x, 3.x nicht komatibel), glibc-2.2/2.3 (natürlich auch nicht kompatibel), libstdc++ (in allen möglichen versionen) ...
Tonnenweise shared libs die im Grunde alle das selbe machen und feinerweise natürlich nicht kompatibel sind.
peschmae
22-12-2004, 11:49
Ja, dann gibts Konkurrenz, aber das ist nur schlecht, zudem anscheinend sich die Laufzeitumgebungen gegenseitig nicht anstacheln, so ist das jedenfalls bis jetzt.
Ein bisschen schon. Nur reagiert Sun imo sehr lahm auf die Herausforderung von Microsoft (Naja, generics gibts mittlerweile immerhin).
Dann muss man 6 verschiedene Laufzeitumgebungen installieren und das Ziel des ganzen, eine einheitliche Laufzeitumgebung zu schaffen, welche endlich mit den Abhängigkeiten und den verschiedensten ABIs aufräumt, ist dahin.
Da magst du recht haben.
Aber nur eine einzelne fände ich u.U. auch kritisch - du willst etwas was die nicht kann. Pech gehabt.
MfG Peschmä
Das einzige was dich motiviert ist dass es jemand anderes gibt der droht es besser zu machen als du
Das hat damit nichts zu tun.
Es kommen eindeutig bessere Ergebnisse bei raus, wenn Konkurrenz existiert.
Ein bisschen schon. Nur reagiert Sun imo sehr lahm auf die Herausforderung von Microsoft (Naja, generics gibts mittlerweile immerhin).
Leider muss ich dir da voll recht geben - was haben die denn zu verlieren, wenn sie den Code von J2SE freigeben?
Das einzige was passieren könnte ist das sich beherzte Entwickler hinsetzen und Sachen machen, die schon lange gemacht gehört hätten wie z.B. JIT code caching usw.
peschmae
22-12-2004, 17:45
Leider muss ich dir da voll recht geben - was haben die denn zu verlieren, wenn sie den Code von J2SE freigeben?
Das einzige was passieren könnte ist das sich beherzte Entwickler hinsetzen und Sachen machen, die schon lange gemacht gehört hätten wie z.B. JIT code caching usw.
Sun spricht ja immer von Fork-Befürchtungen und Inkompatibilität. Naja, bei OO ist das ja bisher auch nicht geschehen. (Wobei das ist wohl recht unwartbarer Code).
Sun verwendet OpenSource mehr oder weniger als Abfalleimer (bis auf OpenOffice):
Alles was sowieso keiner mehr braucht wird ge-open-sourced, genau wie das Solaris. Jetzt wo Linux im Grunde genau das selbe wie Solaris kann, wirds opensource weil man sowieso keine kohle mehr damit machen kann.
Ist das denn jetzt wirklich Open Source? Afaik noch nicht, oder? Nur erst gratis für alle. Aber auf jeden Fall hat Solaris 10 scheinbar schon ein paar nette Features (die auch bei Linux noch fehlen - ich hab gerade C't gelesen ;)). Benutzen werd ichs trotzdem nicht solangs nicht frei ist - und bis dahin hab ich mit Linux & xBSD genug zum spielen :D
A propos BSD, wenn wir uns schon beklagen. Wegen der doofen Sun-Lizenz muss sich auf FreeBSD jeder sein Java selber kompilieren. Dazu brauchts u.A. die Linux-Emulation und darauf ein JDK 1.4 - dann lädst du dir die Sun-Java Quellen runter, die passenden Patches dafür - alles von Hand - und hoffst dass du am Ende eine funktionierende FreeBSD-Jvm hast. Sie läuft jetzt aber mühsam wars extrem.
Genau das selbe ists mit Java: Jetzt wird fleißig die Hand drauf gehalten, und wenns dann sowieso keiner mehr braucht -> Adijö.
Ich befürchte irgendwie dass es so weit kommt wenn man guckt wie Microsoft mit .NET 2.0 vorwärts macht und bei Java geschieht zwar einiges aber bei weitem nicht so viel wie bei .NET. (Operatorenüberladung und das von dir erwähnte Caching sind immer noch nicht in Sicht ;))
MfG Peschmä
Wobei das ist wohl recht unwartbarer Code
hab ich mir auch gedacht - stimmt aber nicht! Sun bietet ja den gesamten Java-5 Quellcode zum Download an (inklusive Hotspot source) und da ist eigentlich alles super strukturiert und sauber programmiert...
peschmae
23-12-2004, 06:49
Na klar wirds forken, das kann man auch gar nicht verhindern, die große Frage ist hallt wen das überhaupt stört. Sun muss ja nicht die Java Handelsmarke hergeben, d.h. jeder Fork muss anders (und natürlich total anders) als Java klingen - somit gäbs nicht wirklich eine große Gefahr.
Ich glaube nicht dass es wirklich relevante Forks gäbe solange Sun das Projekt hostet, selber merkliche Code-Beiträge liefert und sich auch sonst vernünftig verhält. Gäbe nicht wirklich einen Grund.
hab ich mir auch gedacht - stimmt aber nicht! Sun bietet ja den gesamten Java-5 Quellcode zum Download an (inklusive Hotspot source) und da ist eigentlich alles super strukturiert und sauber programmiert...
Ich bezog mich auf OO ;)
Wusste ich gar nicht, die scheinen noch doofer als angenommen! Das ist doch lächerlich - damit schaden die sich im grunde nur selber...
Ja, extrem. Ich hatte etwa ne Woche bis die Sache funktionierte.
MfG Peschmä
localhost
27-12-2004, 13:44
Hallo
ICh habe das jetzt alles lesen war teilweisse sehr lustig.
Aber kann jetzt jeder mal hier hinschreiben was er für das beste held wodrin man ein 3D schutter wie CStrike code.
Und nicht das ganze blabla dazu.
Alles was ich jetzt weis wer das dan C / OpenGL .
Mit Objective-C(++) inkl. GNUStep.
Vorteile:
- Frei & OpenSource (nicht so ein Java-keiner-weiß-was Ding)
- Verwendet GCC
- C(++)-Kompatibel (gut für OpenGL)
- mehr Objektorientiert als Java und C++, wenn man will
- SmallTalk-Ähnlich
- Macht richtig Spaß damit zu proggen
- Nette Speicherverwaltung
Nachteile:
- wenig verbreitet
- kennt kaum einer
- Windows-Entwicklung ist etwas kompliziert einzurichten
- teilweise langsamer als Java und C++, da stärker Objektorientiert (z.B.: eine float-Zahl wäre ein Objekt von NSNumber oder NSDecimal, aber rein float ist auch möglich, aber weniger objektorientiert)
Meine Meinung...
localhost
30-12-2004, 14:05
selbst wenn man eine woche brauch um das spiel zu installiren haubsache es leuft werned des spielen gut schnell und es siet schön aus.
Naja. Je wie man es auffasst.
Du kannst auch mit Java schöne und schnelle Spiele programmieren. Aber dafür hast du dann höhere Anforderungen.
Aber wie gesagt. Wer C oder C++ nicht will, aber trotzdem Problemlos OpenGL nutzen möchte, ist Objective-C(++) einfach genial.
So kannst du "modern" Programmieren, aber trotzdem bei Zeitkritischen Routinen auf C oder C++ zurückgreifen. Unter OS X kannst du es sogar mit Java mixen. Zudem kannst du auf fast alle "Spiele"-Bibliotheken zugreifen, da C kompatibel.
Rein C würde ich nicht mehr nutzen. Bei so komplexen Sachen wie Spiele, ist eine objectorientiere Sprache einfach leichter.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.