Umstieg von Delphi zu JAVA (wichtige Fragen!)

[g-hun]

Hallo!

Ich bin neu im forum und habe ein paar fragen an euch:

also:

ich habe mal vor kurzem mit DELPHI programmiert.
ich fand delphi war eine gute programmiersprache, aber irgentwie dachte ich das java besser wäre.

also meine erste frage ist:

ist java besser als delphi, was meint ihr.

meine zweite frage ist:

kann man mit java genau so gute spiele programmieren wie in delphi und kann man eigentlich sogar theoretisch gesehen gta san andreas mit java programmieren. also wäre java überhaupt dafür fähig.

und: ist java nur eine sprache für webseiten oder kann man auch andere gute dinge mit java programmieren?
wie zumbeispiel programme die mit delphi oder c++ programmiert werden.

ich habe schon fast alle programmiersprachen ausprobiert.
doch da blieb JAVA übrig. und die wollte ich auch mal testen!

das wars auch schon. hoffentlich könnt ihr mir weiter helfen!


danke!

 

[SebiB90]

also meine erste frage ist:

ist java besser als delphi, was meint ihr.

besser und schlechter gibt es nicht, jede programmiersprache hat ihre vor und nachteile

meine zweite frage ist:

kann man mit java genau so gute spiele programmieren wie in delphi und kann man eigentlich sogar theoretisch gesehen gta san andreas mit java programmieren. also wäre java überhaupt dafür fähig.

naja ich glaub da ist die performance bei java bischen zu niedirg obwohl vllt wird sowas mit java 1.6 möglich sein.
aber nicht so aufwendige spiele kann man mit java proggen.

und: ist java nur eine sprache für webseiten oder kann man auch andere gute dinge mit java programmieren?
wie zumbeispiel programme die mit delphi oder c++ programmiert werden.

nein auf keinen fall, java ist nicht javascript. mit java kann man viel machen nicht nur was für hps, java ist zum beispiel im gegensatz du delphi plattformunabhängig, also kannste sogar für alle systeme programmieren, nur hardwarenahe programmierung ist mit java nicht möglich, sonst kannst du so ziemlich alles mit java machen was du auch mit den anderen programmiersprachen machst.

 

[g-hun]

gibt es sogar programme die mit java programmiert wurden und auch verkauft werden??

ps: ich habe dir IDE Eclipse runtergeladen!
nun möchte ich auch programmieren. kenn ihr tutorials?

 

[meez]

ist java besser als delphi, was meint ihr.

Ja, aber das ist absolut Subjectiv!

kann man mit java genau so gute spiele programmieren wie in delphi und kann man eigentlich sogar theoretisch gesehen gta san andreas mit java programmieren. also wäre java überhaupt dafür fähig.

Nein...
1. Nicht dafür Entwickelt, 2. Keine native Anbindung, was für 3D Sachen unerlässlich ist

wie zumbeispiel programme die mit delphi oder c++ programmiert werden.

Ja, wobei wie schon gesagt keine nativen Apps. geschrieben werden können.

gibt es sogar programme die mit java programmiert wurden und auch verkauft werden

Ja, wie Sand am Meer...
Eclipse selber ist z.B. in Java geschrieben...Ist zwar frei, aber es gibt dutzende anderer, kostenpflichtiger IDE's

 

[SamHotte]

google nach "java tutorial" sollte helfen

 

[g-hun]

ihr kennt doch bestimmt die programmiersprache BLITZ BASIC

kann man wenigsten mit java spiele programmieren die man auch in Blitz Basic programmieren kann??

 

[SamHotte]

sorry, die Sprache kenn' ich leider nicht.

 

[g-hun]

wie findet ihr denn JAVA. und:
was findet ihr noch daran gut??

 

[Jockel]

Such doch einfach mal auf Sourceforge/Google/was auch immer nach Produkten/Spielen, die in Java geschrieben wurden.
Z.B.: Quake 2 in Java: http://www.bytonic.de/html/screenshots.html
(weshalb ich meez' Punkt auch nicht ganz verstanden habe, dass mit Java keine 3D-Sachen möglich sind (oder habe ich meez da falsch verstanden?))

Wenn sich mit Java kein Geld verdienen lassen würde, würde die Sprache wohl kaum so eine Verbreitung haben, was ja irgendwie impliziert, dass es auch Produkte in dieser Sprache geben muss.

 

[Illuvatar]

Meez meinte, man kann nicht direkt auf das Grafikzeugs, wie DX oder OGL zugreifen. Allerdings gibt es Wrapper dafür, die die Sache eben naturgemäß leicht verlangsamen. Bsp. Java3D für DX5 (oder 6?), JOGL für OGL etc.
Tutorial: www.java-forum.org/de/javabuch, sonst im Sticky Thread in der Tutorials Sektion schauen

 

[0xdeadbeef]

Man kann mit Java natürlich schon flotte 3D-Spiele machen, wenn man eine native Anbindung an DirectX oder besser (im Sinne plattformübergreifender Entwicklung) OpenGL hat. Dadurch verliert man theoretisch die Plattformunabhänbgigkeit, in der Praxis ist OpenGL mit Java zumindest unter Win und Linux kein Thema - wa den Mac angeht, bin ich mir nicht so sicher. Gibt ja auch genügend Projekte, die beweisen, daß flottes 3D in Java kein Problem ist.

Allerdings muß klar sein, daß man bei einer teilweise interpretierten Sprache im Schnitt etwas Performance verliert. Dazu kommen die vergleichweise sehr langsamen Arrayzugriffe im Vergleich zu C++ und dergleichen, weil jeder Arrayzugriff auf Konsistenz überprüft wird. Last but not least kann unter Java jederzeit die Garbage Collection zuschlagen, was kurzzeitig die Performance des Spiels gegen 0 drückt (Ruckeln).

Hat natürlich alles seine zwei Seiten: durch das Speicherkonzept kann man (beinahe) keine Speicherlecks mehr programmieren und dank der Überwachung der Arrayzugriffe werden schwer zu findende Bugs vermieden.

 

[Soulfly]

Also wenn man sich das neue JSR-231 ansieht. Das ist die nächste Generation von JOGL. Die ist absolut leistungsfähig und räumt bald in Verbindung mit Mustang (Java 1.6) so richtig auf.

Man kann sagen, dass Java mit Jogl etwa 80-95% der Leistung nativ compilierter OpenGL-Programe hat.

Fazit: Alles ist möglich!

 

[byte]

Man kann sagen, dass Java mit Jogl etwa 80-95% der Leistung nativ compilierter OpenGL-Programe hat.

In Anbetracht der Tatsache, dass selbst viele native 3D Engines auf aktuellen Rechnern ruckeln, ist das ernüchternd. Aber sicherlich ein Weg in die richtige Richtung.

 

[meez]

Also wenn man sich das neue JSR-231 ansieht. Das ist die nächste Generation von JOGL. Die ist absolut leistungsfähig und räumt bald in Verbindung mit Mustang (Java 1.6) so richtig auf.

Man kann sagen, dass Java mit Jogl etwa 80-95% der Leistung nativ compilierter OpenGL-Programe hat.

Glaub ich nicht :!:

Zudem find ich's irgendwie Schwachsinnig eine Software wie Jogl zu benutzen...Da schreib ich grad lieber meine ganze App. in einer nativen Sprache, mit der sie dann auch anständig läuft...Zudem gibts halt für andere Sprachen bedeutend mehr gescheite und optimierte Libs...
JAVA ist nicht für 3D Andwendungen entwickelt/designed worden...Und schon gar nicht, um es mit irgendwelchen Krücken a la Jogl zu werden...
Es braucht halt einfach Zeit, um über vierundreissig Umwege auf DX oder GL zuzugreifen!

Was den JSR-231 angeht, das ist einfach ne Spezifikation, und sagt noch gar nichts über die Performance aus...

Die einzige Möglichkeit wäre, die native Anbindung direkt ins JRE zu integrieren , aber das ist zu unflexibel für mich als Anwender/Entwickler (bei so hoch optimierter Software)...Wenn ich ne andere Version (auch Patch Version) der Lib brauche, muss ich zuerst warten bis ein neues JRE rauskommt, und dann auch noch das ganze neue JRE mit meiner App. mitdeployen, um sicher zu sein, dass das Zeugs auch da ist...

 

[Soulfly]

Klar ist JSR-231 eine Spezifikation! Und?
Trotzdem kannst du hier nicht sagen: " nö da programmier ich lieber nativ!"
Warum programmierst du denn Java, wenn du sowieso so engstirnig denkst?

Kennst du Jogl überhaupt? Wie es funktioniert und so weiter, ich denke nicht!
Es läuft über NIO auf den nativen Treibern und das ist eben der Flaschenhals, der eben einen Overhead produziert und
die Programme leicht verlangsamt, das wird SUN früher oder später auf jeden Fall noch tweaken.

Mach dich erstmal schlau und ich denke du wirst erstaunt sein was man damit alles machen kann.
OpenGL in Applets ist sogar auch möglich, das mit netter Performance seit den JSR-231 builds.
Am Beispiel von Jake2 sieht man es deutlich und da wird noch mit dem alten Jogl gebencht.
Der knüller ist aber, es läuft überall. Und das ist der Grund warum man Java programmiert.
Es soll überall laufen. Und wenn Jogl nicht gut sein soll, dann frage ich mich warum Sun sich dafür engagiert
und auch noch Personal darauf ansetzt.

Auf Jeden Fall ein herzlich willkommen an den Author dieses Threads in der Java-Welt in der die portabiltät
die größere Rolle spiele als die Performance. (Wobei Java immer schneller wird natürlich!)


MfG
Soulfly

PS: Jogl ist keine Software, sondern eine Schnittstellen-API *RÄUSPER*

 

[MPW]

Also um Java mal von einer anderen Seite vorzustellen:

Java ist die meistgenutzte Programmiersprache der Welt!

Eine Seite die du an Java vllt. auch noch nicht kennst, sind Handyspiele, die MicroEdition von Java laeuft heute praktisch auf jedem neuen Handy.(Man kann natuerlich auch sinnvolle Anwendungen, nicht nur Spiele damit programmieren.)

Zu Java und Spiele:

Also ich hab schon einige recht gut Java3D Spiele gesehen. Ich meine um sowas wie GTA San Andreas zu proggen...da sitzten selbst Profis ewig dran, so 100 Leute 2 Jahre oder so, das kann man alleine eh nie schaffen.

Aber es gibt ganz nette, sehr fluessig laufende Java 3D Games, Paradroiz ist z.B. eines.
Der Vorteil von Javaspielen ist auch, dass es gleich auf mehreren Plattformen verfuegbar ist.

Was genau willst du machen, willst du ein konkretes Spiel realisieren, oder nur mal so ein paar kleine Spiele machen?

 

[meez]

Klar ist JSR-231 eine Spezifikation! Und?

Ich sag nur, dass das nichts über die Performance aussagt, da du ja meintest, dass damit (und 1.6) 80-95% nativer Apps. erreicht werden kann...

Trotzdem kannst du hier nicht sagen: " nö da programmier ich lieber nativ!"
Warum programmierst du denn Java, wenn du sowieso so engstirnig denkst?

Mach ich auch, sollte ich mich irgendwann der 3D Welt hingeben, weil da Java als Managed Language einfach nicht wirklich tauglich ist...
Das heisst aber nicht, dass Java nicht für die meisten Spiele tauglich ist...Es geht hier um Anwendungen die am Limit laufen...

Kennst du Jogl überhaupt?
Jogl ist keine Software, sondern eine Schnittstellen-API *RÄUSPER*

1. Ne noch nie gehört,
2. Klar ist es nur ein Schnittstellen-API, die auf GL Treiber aufsetzt, trotzdem wird die Implementation halt nativ gemacht...Das ganze definiere ich als Software :!:

Mach dich erstmal schlau und ich denke du wirst erstaunt sein was man damit alles machen kann.

Es ist nicht das Problem was man damit machen kann, sondern ob es sinnvoll ist...

Der knüller ist aber, es läuft überall. Und das ist der Grund warum man Java programmiert.

Sofern ein OpenGL Treiber in genau der erforderlichen Version verfügbar ist. (Es gibt bessere Gründe für Java als Plattformunabhängigkeit)

Es soll überall laufen. Und wenn Jogl nicht gut sein soll, dann frage ich mich warum Sun sich dafür engagiert
und auch noch Personal darauf ansetzt.

Nur weil Sun was macht oder toll findet, muss das nicht automatisch auch gut sein...

Auf Jeden Fall ein herzlich willkommen an den Author dieses Threads in der Java-Welt in der die portabiltät
die größere Rolle spiele als die Performance. (Wobei Java immer schneller wird natürlich!)

Nicht in jedem Fall, wie oben schon beschrieben, sondern eher die Eigenschaften einer Managed Sprache, die Java heutzutage ausmachen, da die Zeit der Killerapplets definitiv vorbei ist...

 

[MPW]

Kennst du Jogl überhaupt?
Jogl ist keine Software, sondern eine Schnittstellen-API *RÄUSPER*

1. Ne noch nie gehört,
2. Klar ist es nur ein Schnittstellen-API, die auf GL Treiber aufsetzt, trotzdem wird die Implementation halt nativ gemacht...Das ganze definiere ich als Software :!:

Zeit irgendwie, dass du keine Ahnung hast.....also wuerde ich mich ein bisschen zurueckhalten;-)

Java ist einfach noch nicht so alt wie C++, Java kann heute dass, was mit C++ vor 3 - 5 Jahren moeglich war. Und es gibt Einschaetzungen, dass Java C++ ueberholen wird, wenn der Fortschritt weiter so rasant laeuft.

 

[AlArenal]

Abgesehen davon muss ein Game nicht immer die allerdollsten allerneusten 3D-Features irgendwelcher Karten und Dualo Cores und solche Scherze völligst ausreizen, um toll zu sein.

Hab mir Anfang des Jahres Darwinia gekauft und das Game ist sowas von cool und kultig, auch ohne SLI & Co, ähnliches gilt z.B. auch für Star Wolves. Eine gute Spielidee angemessen umgesetzt ist deutlich mehr Wert als Games, für die man alle 6 Monate die Karre aufrüsten muss...

Von daher ist es nicht zu weit hergeholt, dass Java zukünfitg auch vermehrt im Bereich 3D und Games eingesetzt werden könnte. Ich habe schon zu Zeiten gezockt, als es für unmöglich gehalten wurde, ordentliche Games in C++ zu coden, weil das ja viel mehr Speicher und Speed frisst, als wenn man schön von Hand seinen Assembler- und C-Code strickt...

Gerade im Entertainment-Bereich ist Zeit nunmal Geld und wenn sich herausstellt, dass in Java die Enticklungszeit verkürzt werden kann..

Ich bin jedes Mal aufs Neue entzückt, wenn ich Civilization 4 starte und im Splash-Screen sowas wie "Initializing Python" steht. Und in der kann man Civ 4 in Python modifizieren und erweitern. In Java 7 wird wohl Groovy mit an Bord sein.. Vielleich tsteht dann bei Civ 6 "Initializing Groovy"?

Aber nur sooo...

 

[meez]

Zeit irgendwie, dass du keine Ahnung hast.....also wuerde ich mich ein bisschen zurueckhalten;-)

:?:

Ist die GL Implementation nicht nativ? Hallo?..Hab ich was nicht mitbekommen?
GL Implementationen werden meist als Teile der GK Treiber auf die Kisten gebracht...
Spezifikation + Implementation = SW


Nochmal :?: :bahnhof:

 

[Soulfly]

Wenn du das so definierst, dann verrate mir doch mal, wie es bei C/C++ oder Delphi funktioniert.
Ungefähr auf die gleiche Weise.
Es gibt also eine dll, auf die mit einer in C geschriebenen "API" Bibliothek auf die
die verfügbaren OpenGl-Funktionen zugegriffen wird. Also auch wieder ein Schnittstelle, die aber im Laufe Zeit
ziemlich eingerostet ist.

Und ja OpenGL wird mit den Treibern geliefert. (Also die Dll)
Diese DLL beinhaltet native Assembleranweisungen, die mit der Hardware kommunizieren und
die Mikroprogramme auf dem Grafikchip ansprechen.

Auf diese greift Jogl auch zu um OpenGl zu nutzen!
Und wenn man sich das alles von weitem anschaut. In C: veraltete Schnittstelle die statisch bleibt.
In Java hingegen haben wir eine Schnittstelle, die gerade neu in Entwicklung ist und jetzt schon fast an
die C-Version rankommt. Sie hat gute Chancen gleichwertig zu werden oder besser. Wie gesagt, der Overhead entsteht noch wenn man auf DLL Bibliotheken zuzugreifen will. Daran wird aber gearbeitet

Spezifikation + Implementation = SW

Aha? Du vergisst, dass SW auch lauffähig sein muss! Ein Spezifikation + Implementation ist eigentlich alles, je nach Spezi halt. Du kannst ja auch eine Klasse spezifizieren und dann implementieren! Diese kann man benutzen.
Viele Klassen davon nennen sich Bibliothek, die von Software benutzt werden kann.
Software ist es, wenn es die Spezifikation auch sagt und das Implementierte "allein" startfähig ist.

MfG
Soulfly

 

[meez]

Naja, man kann übers Wording von SW streiten...Gibt wohl bessere Ausdrucksweisen...Wenn die Bibliothek lieber ist...Oder um korrekt zu sein eine Software-Bibliothek...Aber es geht hier auch nicht ums Wording...
Es geht mehr darum, aus einem abstrahierten Interpreter auf native Bibliotheken zuzgreifen, die NICHT mit dem Interpreter zusammen ausgeliefert werden...Dies zerstört einer der Vorteile von Java, nämlich sicher zu sein, dass das Zeug, dass ich entwickelt habe auch funktioniert, da ich sicher bin, dass sie im Interpreter vorhanden sind...

 

[Soulfly]

Tja soweit is Jogl auch schon Mac, Linux mit MesaGL oder TreiberGL von Nvidia oder Ati, Windows mit Treibern und alles softwaremäßige Beschleunigung oder Hardwaremäßige Beschleunigung, wie es gerade möglich ist.
Für alle fälle ist gesorgt!
Und sag du mir nicht, dass du noch nie eine dir fremde Schnittstelle benutzt hast, die noch nicht "im" Interpreter integriert worden ist.
Gibt viele davon!


MfG
Soulfly

 

[byte]

Auf diese greift Jogl auch zu um OpenGl zu nutzen!
Und wenn man sich das alles von weitem anschaut. In C: veraltete Schnittstelle die statisch bleibt.
In Java hingegen haben wir eine Schnittstelle, die gerade neu in Entwicklung ist und jetzt schon fast an
die C-Version rankommt. Sie hat gute Chancen gleichwertig zu werden oder besser.

Hä? Native Windows Spiele nutzen DirectX als Grafikschnittstelle und die würde ich nicht als veraltet bezeichnen. Im Gegenteil: Direct3D hat OpenGL vor langer Zeit überholt. Ich sage das nicht, weil ich Microsoft Fan bin, sondern weil es einfach Fakt ist. Bin sicherlich der letzte der sich ärgern würde, wenn wieder mehr Spiele OpenGL nutzen würden (wie früher). Aber zur Zeit haben native Windows Spiele halt die Nase vorn. Und selbst wenn Jogl und Co. an die gleiche Leistung kommen würden: Es müsste schon deutliche Vorteile bieten, bevor die Industrie die Plattform wechselt. Denn mal im Ernst: Was bringt mit bitte schön Plattformunabhängigkeit bei einem Computerspiel, wo das Zielpublikum eh Windows besitzt?

Und das Civ4 Beispiel mag löblich sein. Jedoch kann mans auch als Schuss ins eigene Bein verstehen, denn erstens läuft das Spiel auf nicht aktuellen Rechnern miserabel langsam und hat zweitens tausend Bugs (zumindest in den ersten Versionen nach Release). Ich will das nicht auf Python abwälzen, aber wenn schon ein Beispiel alternativer Programmierkunst bei Computerspielen, dann auch bitte ein funktionierendes.

PS: Civ ist natürlich trotzdem ein geniales Game, das steht ausser Frage! Nur ein Wunder an Programmierfertigkeit war keiner der Teile von Sid Meier. :roll:

 

[Illuvatar]

Wo wir doch schon offtopic sind: Ich hab mal gehört, dass OpenGL auf Vista nicht mehr funktionieren wird. Ist das immernoch der aktuelle Stand?

 

[byte]

Inkompatibilität von Aero-Glass und OpenGL
Der ursprüngliche OpenGL-1.1-Software-Emulator-Treiber von Windows XP wird in Vista durch einen OpenGL-1.4-D3D-Translater mit Hardware-Beschleunigung ersetzt. Die volle OpenGL-Leistung lässt sich weiterhin nur mit dem zur Grafikkarte gehörenden OpenGL-Treiber erreichen. Sofern allerdings dieser Treiber aktiv ist wird der Aero-Glass-Modus deaktiviert. Dies gilt allerdings nur für die gleichzeitige Darstellung von DirectX und OpenGL, also bei der Darstellung der OpenGL-Anwendung im Fenster, wie das etwa bei CAD-Arbeiten üblich ist, Vollbildanwendungen, die den OpenGL-Treiber des Grafikkartenherstellers verwenden, sollen auch von einem Aero-Glass-Desktop gestartet und in vollem Umfang genutzt werden können. Für professionelle Arbeiten mit CAD-Systemen ist dies dennoch hinderlich.

Kritiker sehen darin eine Strategie Microsofts, OpenGL zugunsten von DirectX zurückzudrängen, um konkurrierende Betriebssysteme zu benachteiligen.

 

[bygones]

denke das passt besser von Thema her in die Allgemeine Programmieren...

*verschoben*

 

[MPW]

Gerade im Entertainment-Bereich ist Zeit nunmal Geld und wenn sich herausstellt, dass in Java die Enticklungszeit verkürzt werden kann..

Was meiner Meinung nach viel interessanter sein duerfte, ist dass die games alle auch unter Linux und Mac liefen.(Und natuerlich noch so sachen wie Solaris, die aber eh keiner benutzt...)

 

[AlArenal]

PS: Civ ist natürlich trotzdem ein geniales Game, das steht ausser Frage! Nur ein Wunder an Programmierfertigkeit war keiner der Teile von Sid Meier. :roll:

Das waren Programme aus dem Hause Microsoft auch nie.. allerdings muss ich zugeben von beiden die Sourcen nie gesehen zu haben. Du?

Und was das ewige Gelaber angeht OpenGL wäre ja sooo weit hinter DirectX zurück: Wieso gibts die Engine von ID eigentlich immer auch in einem Linux-Port? Oder kann die Quake-Engine nichts? Natürlich kann man nun wieder kommen, ein Spiel nehmen dass letzte Woche ershcien und ankommen mit "Das kann nun hyper-texture-antialiased-supersampled Quadrupel-Buffering und OpenGL kann das nicht!" - Super! Und?

 

[Soulfly]

hyper-texture-antialiased-supersampled Quadrupel-Buffering und OpenGL kann das nicht!" - Super! Und?

Um das aufzugreifen! Vor allem welche GRafikkarte kann das wirklich gut darstellen (wenn es das irgendwann geben sollte )? Workstationgrafikkarten von Disney vielleicht?

ID-Engines sind die genialsten dinger die ich kenne und ich weiß nicht was daran schlechter sein soll. Naja!

Ich für meinen Teil freue mich, wenn ich wirklich ein Spiel vor mir habe, das eine gute story hat und vielleicht auch noch gut aussieht. Wenn mehr wert auf Story gelegt werden würde, würde es diese Diskussion z.B. auch nicht geben.

MfG
Soulfly

 

[AlArenal]

Für mich ist es ne Krankheit und ich nenne sie "Featureitis". Sie äußert sich darin, dass man versucht ein Produkt als "besser" darzustellen, indem man Unmengen neuer Features einbaut, die teils noch eigens erfunden und als solche deklariert werden, ohne einen wirklichen zusätzlichen Nutzen zu bringen.

 

[SamHotte]

.. und oft wird darüber vergessen, erstmal die Bugs aus dem bestehenden Programm zu entfernen (siehe M$ Office) *zustimm*

 

[RicoSoft]

there are no bugs, only features

die kunst besteht darin, die bugs als features zu verkaufen, m$ versteht sich sehr gut darin

 

[stev.glasow]

Sagte der Windows Nutzer
Ist aber doch oft so. Deswegen gibts ja Werbung und so kram. Wir Blender schauen doch auf sowas.
Mal nen anders Beispiel: Denk mir so, kaufst dir mal nen schickes Sturmfeuerzeug hier an der Küste ist's ja doch ziehmlich windig. Guck mir die Feuerzeuge so an, seh eins mit ner geilen Frau drauf und so 'nem "Gastrahler". Denke mir das Ding is cool das nehm ich. 3 Tage später ist das Gas fast leer und auffüllen geht auch nur immer nen bisschen. Dann 2 Tage später löst sich der Deckel und nochmals paar Tage später geht gar nix mehr und bei mehrmaligem Hinsehen ist die Olle doch gar nicht so toll.
Und die Moral von der Geschicht - wir doofen Blender kaufen öfter Piss :roll:

Offtopic sind wir irgendwie gar nicht

 

[AlArenal]

Offtopic sind wir irgendwie gar nicht

Da bin ich aber froh, dass du das sagst

 

[byte]

Die meisten Spieleentwickler nutzen halt DirectX anstatt OGL, weil Plattformunabhängigkeit bei Spielen für sie kein driftiges Argument ist. DirectX ist halt ein hübsches Delevopment Kit für für die Spieleentwicklung, weil man nicht nur 2D/3D Grafikelemente erzeugen kann sondern auch noch drum und dran wie Sound, Musik etc. OGL hingegen bietet nur 2D/3D zur Entwicklung der Grafikengine.

ID Software ist natürlich ein schönes Beispiel, dass OGL auch was kann. Aber im Gegensatz zu den meisten anderen Spieleentwicklern will ID nicht einfach nur ein Spiel (Doom, Quake) verkaufen, sondern es geht ihnen darum, eine Engine zu vermarkten. Dass sie dann natürlich andere Ansprüche an die API stellen (wie Plattformunabhängigkeit), ist nur natürlich. Trotzdem sind sie (leider) nicht repräsentativ für die gesamte Spieleindustrie.

Und nochmal wegen Civ: In manchen Versionen, gerade in Civ4, waren nach Release so essentielle Bugs drin, das kannst Du nicht mit irgendwelchen Microsoft Produkten vergleichen. Sorry, aber wenn ich mir ein Spiel kaufe, und das Game abkackt, nachdem ich ein vorher gespeichertes Spiel laden möchte oder wo ich mir erst einen Microsoft XML Parser aus dem Netz saugen muss, damit ich das Spiel überhaupt erst spielen kann... da brauche ich mir nicht den Code der Software angucken, um beurteilen zu können, dass im Entwicklungsprozess wohl etwas schiefgelaufen ist.

Desweiteren laufen eigentlich alle Microsoft Produkte bei mir zufriedenstellend. WinXP läuft seit 2.5 Jahren ohne Neuinstallation wie geschmiert und die Office Produkte machen (bei mir) das, wozu sie programmiert wurden. Trotzdem gibt es andere Programme, die das besser umsetzen. Aber offensichtliche Bugs muss ich schon mit der Lupe suchen.

 

[AlArenal]

Die meisten Spieleentwickler nutzen halt DirectX anstatt OGL, weil Plattformunabhängigkeit bei Spielen für sie kein driftiges Argument ist. DirectX ist halt ein hübsches Delevopment Kit für für die Spieleentwicklung, weil man nicht nur 2D/3D Grafikelemente erzeugen kann sondern auch noch drum und dran wie Sound, Musik etc. OGL hingegen bietet nur 2D/3D zur Entwicklung der Grafikengine.

ID Software ist natürlich ein schönes Beispiel, dass OGL auch was kann. Aber im Gegensatz zu den meisten anderen Spieleentwicklern will ID nicht einfach nur ein Spiel (Doom, Quake) verkaufen, sondern es geht ihnen darum, eine Engine zu vermarkten. Dass sie dann natürlich andere Ansprüche an die API stellen (wie Plattformunabhängigkeit), ist nur natürlich. Trotzdem sind sie (leider) nicht repräsentativ für die gesamte Spieleindustrie.

Ist doch Schmarrn. Du kannst doch nicht erst sagen, dass Plattformabhängigkeit bei Spielen relativ irrelevant ist und dann sagen, dass es das für ne 3D-Engine doch relavant ist. Wo wird die Quake-Engine denn eingesetzt, wenn nicht in 3D-Spielen? Was soll ich denn ne plattformunabhängige Engine entwickeln für plattformabhängige Games? *amkopfkratz*
Die UT-Enginge gibts übrigens auch als Linux-Port....

ID, um bei dem Beispiel zu bleiben, portiert schon seit Ewigkeiten die Engine, gibt Sourcecode raus, usw. Das ist mehr ne ideologische Geschichte von John Carmack und nichts, womit sie noch dolle Kohle machen. Wenn DirectX doch soo viel doller ist, wäre das durch für die Jungs eher ein Argument auch DirectX zu nutzen, um ihre Engine noch viel doller zu machen und damit noch mehr Game-Coder als Kunden zu gewinnen.

Den Aufwand für Sound kannste übrigens vernachlässigen. Keine Game-Schmiede fällt die strategische Pro-DirectX-Entscheidung auf der Basis dessen, dass man damit auch Töne machen kann... Das kannste einfach abstrahieren, so dass in der Win-Version die AUsgabe über DX läuft, auf Linux über ALSA, auf Mac wieder anders. Da gibts nicht die großen Unterschiede. Lenken, Gas geben und bremsen ist auch bei allen Autos gleich...

 

[byte]

Es war eine Vermutung meinerseits, aber ich lasse mich gerne von Dir aufklären, wenn das alles so ein Schmarrn ist. Erklär Du mir doch einfach, warum DirectX wesentlich mehr eingesetzt wird als OpenGL. Dazu hast Du Dich nämlich bisher nicht geäußert.

ID, um bei dem Beispiel zu bleiben, portiert schon seit Ewigkeiten die Engine, gibt Sourcecode raus, usw. Das ist mehr ne ideologische Geschichte von John Carmack und nichts, womit sie noch dolle Kohle machen.

Das ist so nicht ganz richtig. Der Sourcecode war lange Zeit nicht frei verfügbar, sondern wurde erst kürzlich unter GNU Lizenz gesetzt, und das betrifft auch nur die mittlerweile alte Q3 Engine. Bevor Du wieder sagst, dass das Schmarrn ist, habe ich extra für Dich den Link rausgesucht: http://www.idsoftware.com/business/technology/

Wenn DirectX doch soo viel doller ist, wäre das durch für die Jungs eher ein Argument auch DirectX zu nutzen, um ihre Engine noch viel doller zu machen und damit noch mehr Game-Coder als Kunden zu gewinnen.

Habe ich nirgends so behauptet, dass DX > OGL ist. Hättest Du etwas nachgedacht, hätte Dir auffallen müssen, dass ich es selbst bedauere, dass DX so weit verbreitet ist.

Den Aufwand für Sound kannste übrigens vernachlässigen. Keine Game-Schmiede fällt die strategische Pro-DirectX-Entscheidung auf der Basis dessen, dass man damit auch Töne machen kann...

Da hast Du wohl recht. Die Entscheidung eines Unternehmens ist eine einfache Kosten/ Nutzen Rechnung. Mit welchen Mitteln lassen sich die Ziele bestmöglich und kostengünstig erreichen. Und da DX9 quasi ein einfacher All-Around Baukasten für Computerspiele ist, zieht OGL wohl den kürzeren. Aber wie gesagt: Das ist eine Vermutung meinerseits! Ich sags lieber, bevor Du mir wieder unterstellst, ein DX Fanboi zu sein... :bae:

 

[AlArenal]

ID, um bei dem Beispiel zu bleiben, portiert schon seit Ewigkeiten die Engine, gibt Sourcecode raus, usw. Das ist mehr ne ideologische Geschichte von John Carmack und nichts, womit sie noch dolle Kohle machen.

Das ist so nicht ganz richtig. Der Sourcecode war lange Zeit nicht frei verfügbar, sondern wurde erst kürzlich unter GNU Lizenz gesetzt, und das betrifft auch nur die mittlerweile alte Q3 Engine. Bevor Du wieder sagst, dass das Schmarrn ist, habe ich extra für Dich den Link rausgesucht: http://www.idsoftware.com/business/technology/

Ich sprach von "der Quake-Engine", nicht speziell von der aktuellsten Version. Schau mal hier:

id Software veröffentlicht einige Jahre nach dem Release üblicherweise den Quellcode der Quake-Spiele unter der GNU GPL. So wurde der Quellcode von Quake I am 21. Dezember 1999, von Quake II am 22. Dezember 2001 und von Quake III Arena am 19. August 2005 freigegeben.

Siehe: http://de.wikipedia.org/wiki/Quake-Engine
Und: http://www.idsoftware.com/business/techdownloads/

 

[byte]

Bevor wir uns im Kreis drehen: ist ne super Sache von ID Software. Aber trotzdem werden die Engines erstmal vermarktet. Q3 ist Ende 1999 erschienen, Ende 2005 kam die GNU Lizenz. Sechs Jahre lang wurde die Engine vermarktet und zu Geld gemacht. Ähnlich lief es bei den älteren Engines. Es kamen eine Vielzahl Spiele mit aufgebohrten ID-Engines auf den Markt. ID verdient demnach ihr Geld nicht primär mit den eigenen Spielen, sondern mit ihren Engines. Es liegt daher auf der Hand, dass sie wesentlich mehr Interesse daran haben, dass ihre Engines flexibel und portabel sind, vergleichbar mit der Framework-Entwicklung.

Aber das ist imo nicht repräsentativ auf dem Spiele Markt. Wie machen es denn die meisten Entwickler? Sie entwickeln eine Engine für Spiel X und das wars. Oder sie kaufen die Engine fremd ein. Wenn sie gut drauf sind, verwenden sie ihre Engine für weitere Spiele im eigenen Haus weiter (siehe Electronic Arts).

Sowas beeinflusst die Wahl der im Entwicklungsprozess eingesetzten Technologien und Werkzeuge natürlich.

 

[AlArenal]

Ich habe nie gesagt, dass das zeitnah geschieht, oder man John Carmack darum heilig sprechen soll. Ich habe lediglich erwähnt, dass ID bereits seit langem ihre Engines im Source verfügbar macht und das ist nunmal korrekt.

Und das Fass EA sollten wir gar nicht erst aufmachen. Auf den Sauhaufen bin ich sowas von stinkig......

 

[AlArenal]

Und da es nichts gibt, das es nicht gibt:

With the mainstream adoption of graphics acceleration hardware, the use of one API or another no longer implies the use of a specific optimized software renderer. Instead, the low-level rendering logic is implemented in the graphics hardware and its drivers, and thus is largely the same whether OpenGL or Direct3D is used. This trend has revealed that neither API possesses an inherent speed advantage over the other. The performance of an application depends instead on the programmer's skill, the quality of the drivers, and the performance of the graphics hardware.

Und was MS Vista angeht:

Note that this functionality only truly matters for applications running in windowed mode. Full-screen applications, the way most people run games, will not be affected. Desktop compositing wouldn't affect them regardless, and the user won't notice that windows that the user can't see have had desktop compositing deactivated. However, the problem remains for running windowed OpenGL ICDs.

http://en.wikipedia.org/wiki/Direct3D_vs._OpenGL