PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Warum programmiert man moderne Spiele heute nicht in Java?


Gast
2008-03-31, 12:52:49
Heute habe ich mal die Java Version von Nasa World Wind ausprobiert
und dabei festgestellt, daß diese Java3d mit Hardwarebeschleunigung verwenden.

Was mir dabei aber besonders aufgefallen ist und was mich besonders überrascht hat war die Tatsache, daß das Programm eine richtig gute Reaktionszeit hatte und die 3d Kugel richtig flüssig ohne Haken gedreht und animiert werden konnte, so etwas war ich von bisherigen Java Beispiel Anwendungen die auf Java3d setzen nicht gewohnt.

Daher komme ich zu der Annahme, daß 3d Spiele in Java heute ja gar kein Problem mehr sein dürften, denn wie man an diesem Nasa World Wind Beispiel sieht, sind die Probleme die man mit Java und 3d immer hatte wohl von Gestern.

Über das flüssige Nasa World Wind könnt ihr euch hier selber überzeugen.
Einfach auf folgender Seite auf Java Webstart klicken:
http://worldwind.arc.nasa.gov/java/


Das negativ Beispiel mit Java und 3d Grafik war bis jetzt bei mir immer dieses Spiel:
http://www.happypenguin.org/show?Arkanae
http://www.happypenguin.org/images/screen18.jpg

Das lief zwar vom 3d her flüssig, nur war es vom reagieren her immer ruckelig, der Charakter und das drumherum stockte und hackelte ständig.

The_Invisible
2008-03-31, 12:59:31
weil zig wichtige libs/frameworks/middlewares auf c/c++ setzen ;)

das ruckeln dürfte wohl an der implementierung gelegen haben.

mfg

Demirug
2008-03-31, 13:15:24
Weil man auf Konsolen nicht Jitten kann/darf.

Gast
2008-03-31, 13:16:03
Hat von euch schon jemand JME ausprobiert?
http://jmonkeyengine.com/index.php?option=com_frontpage&Itemid=1
http://www.devmaster.net/engines/engine_details.php?id=78

Das ist eine Scene Graph Engine für 3d Spiele in Java.
Und die Beispiel Screenshots sind IMO mehr als erstaunlich, dafür das das alles im normalerweise langsammen Java gemacht worden ist:

http://www.jmonkeyengine.com/images/jme/userscreens/Spirits3.png

http://www.jmonkeyengine.com/images/jme/userscreens/HC3.png

http://www.jmonkeyengine.com/images/jme/userscreens/projectedwater-3.jpg



Wenn man mit Java ein 3d Spiel entwickeln würde, dann gewinnt man ja sicher bei der Entwicklungszeit, aber kann man damit auch wirklich alles für 3d Spiele wichtige realisieren, was man mit C und C++ realisieren kann?

Um also gleich zum Punkt zu kommen, wäre ein Shooter wie Crysis mit Java machbar? Und wieviel Performance (in Prozent) würde man dabei wohl geschätzt einbüßen?

Macht also eine Entwicklung eines Spieles in C/C++ heute überhaupt noch Sinn, wenn man das alles in Java machen kann und Java viel bequemer zum Progen ist.

Gast
2008-03-31, 13:29:44
Weil man auf Konsolen nicht Jitten kann/darf.

Jitten?

Was bedeutet das Wort?

Gast
2008-03-31, 13:35:59
Jitten?

Was bedeutet das Wort?

Ok, ich habe jetzt etwas recherchiert.

Demirug, sag doch gleich das das Wort Jitten etwas mit just-in-time (JIT) Compilern zu tun hat. Ich höre das Wort jedenfalls zum ersten mal.

Gast
2008-03-31, 13:38:19
Und die Beispiel Screenshots sind IMO mehr als erstaunlich, dafür das das alles im normalerweise langsammen Java gemacht worden ist

Java ist nicht langsam.

Zum Thema: Ich denke es wird sich wenn dann eher .net durchsetzen bei Spielen.

Gast
2008-03-31, 13:45:29
Was ist besser:

JOGL (Java OpenGL) oder LWJGL (Lightweight Java Game Library)

Trap
2008-03-31, 13:49:23
Java ist nicht langsam.
Langsam oder schnell als Attribute von Sprachen ist sowieso ziemlich an den Haaren herbeigezogen, das ist eigentlich eine Eigenschaft der Implementierung der Sprache.

Die aktuelle JVM ist da schon ziemlich gut, ab und zu sogar besser als der aktuelle GCC, es hängt aber doch sehr von der konkreten Aufgabe ab, es gibt auch Fälle in denen die JVM 3 mal so lang braucht.

Gast
2008-03-31, 14:14:58
Java ist einfach zu langsam und unflexibel. Warum etwas Schlechteres nehmen, wenn es doch das gute C++ (bald C++0x!) gibt.

Gast
2008-03-31, 14:16:59
Gerade bei Spielen kommt es auf High-Performance an und da ist Java meilenweit rückständig, auch hinsichtlich des ROI und TTM.

Shink
2008-03-31, 14:19:20
Mal etwas zum Thema: Wurde sicher schon oft gepostet aber ein paar Leute haben vor einiger Zeit Quake II auf Java portiert und es ist im Vergleich gar nicht so lahm (bzw. teilweise schneller), selbst auf langsameren PCs:
http://bytonic.de/html/benchmarks.html

Den Hauptgrund sehe ich auch bei den Konsolen: Da kann man anscheinend mehr Geld machen und M$ wird nicht so blöd sein und Java bei seiner xBox unterstützen.

Manche Spiele programmierte man früher tatsächlich zumindest teilweise in Java (z.B. vampire masquerade: Redemption), nahm aber genau deshalb wieder davon Abstand.

Ich fänds praktisch, aber im Prinzip ist es natürlich egal womit man programmiert und weshalb sollte man sich freiwillig der xBox-Zielgruppe verweigern?

Der_Donnervogel
2008-03-31, 14:20:44
Langsam oder schnell als Attribute von Sprachen ist sowieso ziemlich an den Haaren herbeigezogen, das ist eigentlich eine Eigenschaft der Implementierung der Sprache.
Da ist auf jeden Fall etwas dran, allerdings kann man das auch nicht so Allgemeingültig sagen. Die meisten Sprachen haben einen Fokus in irgend einem Bereich, wo sie besonders gut da stehen, sei es weil die Sprache direkt etwas besonders effizient unterstützt, oder weil sie ein gutes Framework hat. Umgekehrt gibt es auch Dinge, die bei gewissen Sprachen einfach kritisch sind. zB ist es bei normalem Java ein Problem Dinge zu machen die von einem exakten Timing abhängig sind (zB. eine Hardwaresteuerung). Vor allem dass der Garbagecollector auch zu einem ungünstigen Zeitpunkt, der nicht kontrollierbar ist, anspringen kann ist hier ein Problem der Sprache selbst. Bei solchen Sachen ist zB ein C++ besser, da man hier wirklich die Kontrolle hat, wann Speicher freigegeben werden kann und wann das Programm wichtigeres zu tun hat.
Die aktuelle JVM ist da schon ziemlich gut, ab und zu sogar besser als der aktuelle GCC, es hängt aber doch sehr von der konkreten Aufgabe ab, es gibt auch Fälle in denen die JVM 3 mal so lang braucht.
In den meisten Fällen ist der Unterschied aber wirklich zu vernachlässigen.

Berni
2008-03-31, 14:22:50
Das Wichtigste sind ja die ganzen vorhandenen Libraries und Enwicklungsumgebungen. Und die bauen halt hier nicht auf Java auf. Java würde auch kaum Vorteile bringen, da es nicht schneller ist und man außerdem in C++ auch ähnlich schnell programmieren kann (der Vorteil von Java resultiert ja größtenteils aus den integrierten Klassen/Libraries, die für Desktopanwendungen sehr gut geeignet sind).

The_Invisible
2008-03-31, 14:23:27
Mal etwas zum Thema: Wurde sicher schon oft gepostet aber ein paar Leute haben vor einiger Zeit Quake II auf Java portiert und es ist im Vergleich gar nicht so lahm (bzw. teilweise schneller), selbst auf langsameren PCs:
http://bytonic.de/html/benchmarks.html

Den Hauptgrund sehe ich auch bei den Konsolen: Da kann man anscheinend mehr Geld machen und M$ wird nicht so blöd sein und Java bei seiner xBox unterstützen.

Manche Spiele programmierte man früher tatsächlich zumindest teilweise in Java (z.B. vampire masquerade: Redemption), nahm aber genau deshalb wieder davon Abstand.

Ich fänds praktisch, aber im Prinzip ist es natürlich egal womit man programmiert und weshalb sollte man sich freiwillig der xBox-Zielgruppe verweigern?

microsoft wird da wohl eher C#/.net nehmen bevor sie auch überhaupt nur an java denken ;)

mfg

Gast
2008-03-31, 14:27:26
Manche Spiele programmierte man früher tatsächlich zumindest teilweise in Java (z.B. vampire masquerade: Redemption), nahm aber genau deshalb wieder davon Abstand.
Hui, hast du ne Quelle dazu? Das klingt interessant.

Shink
2008-03-31, 14:32:14
Java würde auch kaum Vorteile bringen, da es nicht schneller ist und man außerdem in C++ auch ähnlich schnell programmieren kann (der Vorteil von Java resultiert ja größtenteils aus den integrierten Klassen/Libraries, die für Desktopanwendungen sehr gut geeignet sind).
Vielleicht diskutieren wir da besser nicht drüber, da gibts wohl verschiedene Meinungen (Restriktivität in Programmiersprachen; AOP; Spring)

robobimbo
2008-03-31, 14:34:06
Gibt es nicht auch einen Java-Compiler der richtigen Binärcode für die jeweilige Zielplattform erzeugt? Mein Alzheimer verseuchtes Gehirn meint soetwas einmal wahrgenommen zu haben.

Damit würde man dann ja auch für Konsolen etwas mit Java produzieren können (theoretisch).

Shink
2008-03-31, 14:41:12
Es gibt ja GCC-GCJ sowie Excelsior JET. Ob es erlaubt ist damit ein kommerzielles Konsolen-Spiel rauszubringen kann ich aber nicht sagen. So oder so müsste jemand AWT, JOGL und was weiß ich noch auf das Windows der xBox portieren.

Zu Vampire: Hmm...
http://www.gamasutra.com/view/feature/3347/dirty_java_using_the_java_native_.php?page=13
Der ganze Artikel sollte interessant sein (dafür dass er fast 10 Jahre alt ist).

Java Fanboy
2008-03-31, 14:53:55
Java ist einfach zu langsam und unflexibel. Warum etwas Schlechteres nehmen, wenn es doch das gute C++ (bald C++0x!) gibt.


Im C++0x Standard gibt's ja nichtmal brauchbare Funktionen zu Stringbearbeitung.
Alles muß man selber machen.

Gast
2008-03-31, 14:56:15
Im C++0x Standard gibt's ja nichtmal brauchbare Funktionen zu Stringbearbeitung.
Alles muß man selber machen.
[ ] Du hast Ahnung

std::string
<algorithm>
Closures
Functors

Monger
2008-03-31, 14:58:48
Weil man auf Konsolen nicht Jitten kann/darf.
Blöde Frage, aber was macht XNA eigentlich dann auf der XBox360? Spuckt der XNA Compiler dann den fertigen Binärcode aus? Wie sieht es dann da eigentlich mit Dingen aus was normalerweise von der Runtime abgefangen werden, wie z.B. Stack/Bufferoverflows?

Gast
2008-03-31, 15:02:50
Ich fänds praktisch, aber im Prinzip ist es natürlich egal womit man programmiert und weshalb sollte man sich freiwillig der xBox-Zielgruppe verweigern?


Also wenn man nur in einer kleinen Spieleschmiede arbeitet, dann kann man ruhig auf Java setzen, denn ein Entwicklerkit für die XBox kriegt man als kleine Spieleschmiede eh nicht.

Da braucht man schon einen großen Publisher damit man überhaupt für Konsolen entwickeln darf.


Ehrlich gesagt finde ich sogar, daß man hier mit Java sogar gewinnen kann, denn Java ist Plattformunabhängig und wenn man schon nicht die Konsolen abgrasen darf, weil man zu klein ist, dann kann man wenigstens den Mac, Linux und vielleicht auch Handy Markt mit seinem Java 3d Spiel bedienen.

Gast
2008-03-31, 15:06:12
Vor allem dass der Garbagecollector auch zu einem ungünstigen Zeitpunkt, der nicht kontrollierbar ist, anspringen kann ist hier ein Problem der Sprache selbst. Bei solchen Sachen ist zB ein C++ besser, da man hier wirklich die Kontrolle hat, wann Speicher freigegeben werden kann und wann das Programm wichtigeres zu tun hat.

Wann braucht man denn die Kontrolle darüber den Speicher zu reinigen?
Doch nur dann, wenn man gerade ein neues Level läd und der alte Speicher sauber gemacht werden muß, ansonsten ist es aber egal, da mitten im Level der Speicher bei den meisten Spielen eh nicht aufgräumt wird.
Das betrifft eigentlich IMO nur Spiele mit einer ganz großen Welt die Häppchenweise mitten im Spiel geladen wird (z.b. Morrowind oder FS-X), aber bei so begrenzten Welten wie z.B. Crysis ist es besser wenn man alles in den Speicher haut und dann beim Laden des nächsten Levels die Aufräumarbeiten beginnt.

Habe ich Recht?

Gast
2008-03-31, 15:11:29
Es gibt ja GCC-GCJ sowie Excelsior JET. Ob es erlaubt ist damit ein kommerzielles Konsolen-Spiel rauszubringen kann ich aber nicht sagen. So oder so müsste jemand AWT, JOGL und was weiß ich noch auf das Windows der xBox portieren.

Zu Vampire: Hmm...
http://www.gamasutra.com/view/feature/3347/dirty_java_using_the_java_native_.php?page=13
Der ganze Artikel sollte interessant sein (dafür dass er fast 10 Jahre alt ist).


Also dem Artikel entnehme ich, daß Java für Vampire nur als Scriptsprache verwendet wurde.

Demirug
2008-03-31, 15:12:20
Blöde Frage, aber was macht XNA eigentlich dann auf der XBox360? Spuckt der XNA Compiler dann den fertigen Binärcode aus? Wie sieht es dann da eigentlich mit Dingen aus was normalerweise von der Runtime abgefangen werden, wie z.B. Stack/Bufferoverflows?

Seit wann muss sich Microsoft an seine eigenen Regeln halten?

Gast
2008-03-31, 15:25:12
Seit wann muss sich Microsoft an seine eigenen Regeln halten?Und warum geht es hier nur um Microsoft. Es gibt wesentlich größere Hersteller von Konsolen. Warum verwendet Sony kein Java sondern einen eigenen Entwicklungskit? Warum Nintendo?

Ich glaube nicht, dass die Konsolen daran "schuld" sind, dass man Spiele nicht in Java entwickelt. Welches der PC-only Spiele wurde in Java geschrieben (außer den bekannten Browsergames)? Richtig! Kein einziges. Also an den Konsolen kann es nicht liegen. Warum sind Gothic 3, Crysis, X3 oder WoW nicht in Java? Alles keine Microsoft-Spiele, sondern von Herstellern, die ihre Konsolenunabhängigkeit besonders hervorheben.

Monger
2008-03-31, 15:32:10
Seit wann muss sich Microsoft an seine eigenen Regeln halten?
Das war jetzt völlig arglos gefragt, ich hab keine Ahnung. Also ist das was aus XNA für XBox360 rauspurzelt kein "managed code" mehr, richtig ?!

Gast
2008-03-31, 15:44:26
Hat schon mal jemand die beiden Versionen von Jake2 Webstart getestet?
http://bytonic.de/html/jake2_webstart.html

Also einmal die JOGL Version und ein andermal die LWJGL Version?
Welche ist performanter?

SgtTynis
2008-03-31, 15:47:55
Mir fällt spontan Call of Juarez ein, dessen Skriptingengine auf Java basiert. Keine Ahnung wie die das auf die XBox portiert haben.

Shink
2008-03-31, 16:05:39
Und warum geht es hier nur um Microsoft. Es gibt wesentlich größere Hersteller von Konsolen. Warum verwendet Sony kein Java sondern einen eigenen Entwicklungskit? Warum Nintendo?
Keine Ahnung. Bei Sony wär ich mir auch gar nicht so sicher dass die nirgends Java verwenden.

Jedenfalls gabs Java für den Dreamcube AFAIR und wurde auch für Segas Spiele teilweise eingesetzt.

Coda
2008-03-31, 16:08:05
Ein Problem dürfte auch einfach der GC sein. Wenn man fast den ganzen Hauptspeicher braucht funktioniert das nicht mehr gut.

Shink
2008-03-31, 16:56:21
Ein Problem dürfte auch einfach der GC sein. Wenn man fast den ganzen Hauptspeicher braucht funktioniert das nicht mehr gut.
Bezüglich des "Java braucht zuviel Hauptspeicher und GC ist sinnlos bei diesen Anwendungen"-Arguments (meinentwegen bei Konsolen): Wie sieht das eigentlich bei der Mobile Edition aus? Handys kommen ja anscheinend ganz gut zurecht mit Java; vielleicht sollte man einfach die J2ME auf Konsole portieren?

Coda
2008-03-31, 17:19:02
Bezüglich des "Java braucht zuviel Hauptspeicher und GC ist sinnlos bei diesen Anwendungen"-Arguments (meinentwegen bei Konsolen): Wie sieht das eigentlich bei der Mobile Edition aus? Handys kommen ja anscheinend ganz gut zurecht mit Java; vielleicht sollte man einfach die J2ME auf Konsole portieren?
Ich sage nicht dass ein GC schlecht ist oder nicht, aber er braucht def. mehr Speicher als eine manuelle Speicherverwaltung.

Handy-Spiele sind jetzt wirklich nicht am Limit programmiert.

Shink
2008-03-31, 17:42:09
Handy-Spiele sind jetzt wirklich nicht am Limit programmiert.
Keine Ahnung ehrlich gesagt. Jedenfalls gibts dort auch 3D-Beschleunigung und aufwändigere sowie weniger aufwändige Spiele. Ich wäre irgendwie davon ausgegangen, dass man dort manchmal nicht besonders viel Speicher zur Verfügung hat aber wie gesagt: Keine Ahnung; ist nur eine Vermutung.

The_Invisible
2008-03-31, 17:44:26
Mir fällt spontan Call of Juarez ein, dessen Skriptingengine auf Java basiert. Keine Ahnung wie die das auf die XBox portiert haben.

der interpreter wird ganz einfach als .dll oder so mitgeliefert.

ist aber aber wirklich 100% Java? wär schon ein bisschen komisch.

mfg

EgonOlsen
2008-03-31, 17:45:23
Die Sachen von Techland (Also Chrome, Call of Juarez, irgendein Autorennen, dessen Namen ich vergessen habe...) nutzen alle Java als Quasi-Skriptsprache für die Spiellogik. Das komplette JRE ist dabei. Was sie mit den Konsolen gemacht haben (gibt es das wirklich für Konsole...?), weiß ich nicht.

Ansonsten würde ich sagen, die Nutzung von Java auch nur für von Hobbyisten entwickelte Spiele stagniert bestenfalls, eher ist sie rückläufig. Warum das so ist, ist mir auch nicht ganz klar, denn die verfügbaren Werkzeuge werden eher besser und mehr als schlechter und weniger. Ein Problem ist sicher der schlechte Ruf von Java, den es sich in seiner Anfangszeit mühsam erarbeitet hat und bis heute pflegt. Selbst 99% der Entwickler, die Java jeden Tag zur Anwendungsentwicklung nutzen, haben keine Ahnung von den anderen Möglichkeiten und können immer nicht glauben, dass man in Java z.B. solche lustigen Dinge auch im 3D-Bereich anstellen kann: http://www.jpct.net/demos/jbullet/jbullet.jnlp

Auch schön sind die Trolle, die scheinbar aus dem Heiseforum hierher gefunden haben. Geht sterben!

Demirug
2008-03-31, 17:53:42
Und warum geht es hier nur um Microsoft. Es gibt wesentlich größere Hersteller von Konsolen. Warum verwendet Sony kein Java sondern einen eigenen Entwicklungskit? Warum Nintendo?

Warum ich Microsoft hier aufgeführt habe ist ganz einfach. Mit dem XNA Framework haben sie ja ein Bytecode System auf der Xbox 360 laufen. Entsprechend unterstützt das System also so etwas. Sony scheint dagegen noch nicht einmal das nötige System calls vorgesehen zu haben. Bei Nintendo kenne ich mich noch nicht so aus. Im Allgemeinen mögen die Konsolenhersteller aber sowas nicht weil es ein Sicherheitsrisiko darstellt.

Ich glaube nicht, dass die Konsolen daran "schuld" sind, dass man Spiele nicht in Java entwickelt. Welches der PC-only Spiele wurde in Java geschrieben (außer den bekannten Browsergames)? Richtig! Kein einziges. Also an den Konsolen kann es nicht liegen. Warum sind Gothic 3, Crysis, X3 oder WoW nicht in Java? Alles keine Microsoft-Spiele, sondern von Herstellern, die ihre Konsolenunabhängigkeit besonders hervorheben.

Weil jeder der heute ein PC Spiel schreibt sich die Hintertür der Konsolenportierung offen halten will.

Das war jetzt völlig arglos gefragt, ich hab keine Ahnung. Also ist das was aus XNA für XBox360 rauspurzelt kein "managed code" mehr, richtig ?!

Doch das ist managed code.

Ein Problem dürfte auch einfach der GC sein. Wenn man fast den ganzen Hauptspeicher braucht funktioniert das nicht mehr gut.

Ein GC verhindert aber sehr effektiv die Speicherfragmentierung. Ein großes Problem auf Konsolen.

ScottManDeath
2008-03-31, 18:01:08
Im C++0x Standard gibt's ja nichtmal brauchbare Funktionen zu Stringbearbeitung.
Alles muß man selber machen.


http://www.boost.org/doc/libs/1_35_0/doc/html/string_algo.html

Coda
2008-03-31, 18:10:58
Ein GC verhindert aber sehr effektiv die Speicherfragmentierung. Ein großes Problem auf Konsolen.
Da kann man auch anders drumrumschiffen. An die Grenze der Hardware kommt man mit nem GC auf jeden Fall nicht.

Würdest du denn einen einsetzen wollen auf ner Konsole mit 512MiB RAM?

Demirug
2008-03-31, 18:20:35
Da kann man auch anders drumrumschiffen. An die Grenze der Hardware kommt man mit nem GC auf jeden Fall nicht.

Würdest du denn einen einsetzen wollen auf ner Konsole mit 512MiB RAM?

Ja. Sofort.

Gast
2008-03-31, 18:47:24
Ja. Sofort.
Auch wenn die 512 mit dem grafikchip geteilt werden müssen, man als letztendlich effektiv ca. 256 MB hat?

del_4901
2008-03-31, 18:49:51
Auch wenn die 512 mit dem grafikchip geteilt werden müssen, man als letztendlich effektiv ca. 256 MB hat?
Ich denke ab dieser Größenordnung macht das keinen Unterschied. Und solange man sich nicht mit einem CopyGC rumschlagen muss, ist doch alles in bester Ordnung.

Gast
2008-03-31, 19:00:07
Ich denke ab dieser Größenordnung macht das keinen Unterschied. Und solange man sich nicht mit einem CopyGC rumschlagen muss, ist doch alles in bester Ordnung.
Also ich bezweifel das man Spiele wie Mass Effect, die Speichertechnisch eh schon absolut am Speicherlimit laufen, mit Java implementieren könnte.

Bei manch anderen Spielen ist das aber natürlich kein Problem, jo.

Coda
2008-03-31, 19:11:28
Ja. Sofort.
Interessant. Und du meinst dass du damit wirklich auch allen Speicher ausnutzen könntest?

del_4901
2008-03-31, 19:12:14
Also ich bezweifel das man Spiele wie Mass Effect, die Speichertechnisch eh schon absolut am Speicherlimit laufen, mit Java implementieren könnte.

Bei manch anderen Spielen ist das aber natürlich kein Problem, jo.

von Java war keine Rede, es ging mir nur um den GC. Und da gibt es solche und solche. Die hybriden werden sich dabei wohl durchgesetzt haben. Da wird der CopyGC eben nur angeschmisssen, wenn grade genug Platz ist. Und es ist ja nicht so, dass man in "Härtefällen" die Platte nicht zu Hilfe nehmen darf. Solange läuft Mark&Sweep oder was anderes. Dafür habe ich dann keine externe Fragmentierung mehr. Das kann man aber auch sehr effizent zu Kosten von interner Fragmentierung (Verschnitt) auch in C++ lösen.

Die Fragen sind:

Kann man sich den Verschnitt leisten?
Wie häufig bin ich überhaupt am Speicherlimit?
Wie häufig bin ich am Adresslimit?


Also ich persöhnlich kann auch ohne GC ziehmlich gut leben, weil die Infrastruktur dafür steht.

Demirug
2008-03-31, 19:33:59
Interessant. Und du meinst dass du damit wirklich auch allen Speicher ausnutzen könntest?

Wenn du so am Limit bist das du dir den minimale Overhead nicht leisten kannst bist du sowieso schon so gut wie Tod.

Primär geht es mir aber sowieso mehr darum die lästigen Speicherfehler los zu werden.

del_4901
2008-03-31, 19:42:02
Wenn du so am Limit bist das du dir den minimale Overhead nicht leisten kannst bist du sowieso schon so gut wie Tod.

Primär geht es mir aber sowieso mehr darum die lästigen Speicherfehler los zu werden.

Der Overhead ist im Worst-Case genau so groß, wie die belegte Speichermenge. (CopyGC, und niks zu entwerten) Das versucht man natürlich soweit wie möglich nach hinten zu schieben, bzw. einen günstigen Zeitpunkt zu finden. Ist aber nicht immer vermeidbar.

Bei einem System wo ich nur vorgegebene Blockgrößen verwenden darf, habe ich solche Probleme nicht, da kann ich mich mutig bis zur Threshinggrenze vorarbeiten. (Die natürlich bei so einem System niedriger ausfällt)

Demirug
2008-03-31, 19:52:46
Der Overhead ist im Worst-Case genau so groß, wie die belegte Speichermenge. (CopyGC, und niks zu entwerten) Das versucht man natürlich soweit wie möglich nach hinten zu schieben, bzw. einen günstigen Zeitpunkt zu finden. Ist aber nicht immer vermeidbar.

Bei einem System wo ich nur vorgegebene Blockgrößen verwenden darf, habe ich solche Probleme nicht, da kann ich mich mutig bis zur Threshinggrenze vorarbeiten. (Die natürlich bei so einem System niedriger ausfällt)


Man muss ja nicht unbedingt einen CopyGC verwenden.

Ich weis jetzt ehrlich gesagt nicht warum du hier die Systemblockgröße einwirfst. Darüber läuft ja sowieso noch ein Heapmanager und diese neigen zum fragmentieren.

Mit Speicherfehler meine ich aber solche Scherze wie die Verwendung von eigentlich bereits gelöschten Objekten und ähnliches. Und versuche mir jetzt bitte nicht zu erzählen das erfahrenen Entwicklern sowas nicht passiert.

del_4901
2008-03-31, 20:00:14
Man muss ja nicht unbedingt einen CopyGC verwenden. .
Wenn man externe Fragmentierung wegbekommen möchte kommt man darum nicht rum. Für alle anderen Fälle ist das ok.


Ich weis jetzt ehrlich gesagt nicht warum du hier die Systemblockgröße einwirfst. Darüber läuft ja sowieso noch ein Heapmanager und diese neigen zum fragmentieren. .
Ich dachte eigendl. an einen Heapmanager der Blöcken bestimmter Größe arbeitet. (Po2 etc.) Die fragmentieren nur intern (sprich haben Verschnitt)

Mit Speicherfehler meine ich aber solche Scherze wie die Verwendung von eigentlich bereits gelöschten Objekten und ähnliches. Und versuche mir jetzt bitte nicht zu erzählen das erfahrenen Entwicklern sowas nicht passiert.
Je nach Komplexität des Heapmanagers kann man bestimmte Fehler erkennen.
Und printet man sich ins Log. Und bei den Anderen-Fehlern (die mir grad als Beispiele einfallen) hilft dir auch kein GC weiter.

Demirug
2008-03-31, 20:09:37
Wenn man externe Fragmentierung wegbekommen möchte kommt man darum nicht rum. Für alle anderen Fälle ist das ok.

Da gibt es durchaus Zwischenformen die Fragmentierung verhindern und keinen so hohen Overhead haben.

Ich dachte eigendl. an einen Heapmanager der Blöcken bestimmter Größe arbeitet. (Po2 etc.) Die fragmentieren nur intern (sprich haben Verschnitt)

Sowas haben meine Kollegen auch schon kaputt bekommen. :D

Je nach Komplexität des Heapmanagers kann man bestimmte Fehler erkennen.
Und printet man sich ins Log. Und bei den Anderen-Fehlern (die mir grad als Beispiele einfallen) hilft dir auch kein GC weiter.

Wir haben einen sehr guten Debug heap manager. Trotzdem geht für die Analyse solcher Bugs immer eine Menge Zeit drauf. Da ich Codeowner der Systemkomponenten bin landen alle Heapfehler erst mal bei mir. Deswegen habe ich da einen recht guten Überblick.

Gast
2008-03-31, 20:10:02
Die Sachen von Techland (Also Chrome, Call of Juarez, irgendein Autorennen, dessen Namen ich vergessen habe...) nutzen alle Java als Quasi-Skriptsprache für die Spiellogik. Das komplette JRE ist dabei. Was sie mit den Konsolen gemacht haben (gibt es das wirklich für Konsole...?), weiß ich nicht.


Chrome war ein geiler Shooter und bei der GS als Vollversion dabei.
Habe ihn sogar durchgespielt, aber das der Java als Scriptsprache benutzt hat, wußte ich echt nicht.


Warum benutzt man eigentlich Java als Scriptsprache?
Ist es dafür nicht eher ungeeignet?

Der große Vorteil bei Scriptsprachen (wie z.B. Lua, Phyton etc.) ist doch, daß der Code zur Laufzeit interpretiert wird und man so ein Spiel leicht modden kann, weil der Code ja leicht bearbeitbar ist.
Aber wenn man den Code jetzt in Java schreibt, dann wird der ja in Bytecode compiliert und ist somit nicht mehr zum leichten Modden bearbeitbar.

Wo sind da also die Vorteile von Java als Scriptsprache?
Da kann man zum Scripten IMO ja auch gleich C++ nehmen.
Oder etwas nicht?

EgonOlsen
2008-03-31, 20:13:19
Der große Vorteil bei Scriptsprachen (wie z.B. Lua, Phyton etc.) ist doch, daß der Code zur Laufzeit interpretiert wird und man so ein Spiel leicht modden kann, weil der Code ja leicht bearbeitbar ist.
Aber wenn man den Code jetzt in Java schreibt, dann wird der ja in Bytecode compiliert und ist somit nicht mehr zum leichten Modden bearbeitbar.
Zumindest bei Chrome lagen die Javaquellen dabei. Sie wurden wohl bei Verwendung oder einfach beim Starten neu kompiliert. Von sofern unterschied sich das Resultat nicht von einer echten Skriptsprache. Ich denke, bei Call of Juarez stecken sie auch irgendwo in den PAKs, ich habe aber nicht nachgesehen.

Edit: Bei Call of Juarez stecken 2066 vorkompilierte Class-Dateien drin. Von den Quellen sehe ich aber nichts...

Java Fanboy
2008-03-31, 20:17:21
http://www.boost.org/doc/libs/1_35_0/doc/html/string_algo.html

Genau das meinte ich.

The String Algorithm Library provides a generic implementation of string-related algorithms which are missing in STL. It is an extension to the algorithms library of STL


Im Standard ist das alles nicht drin.
Und der Gast der mir vorwirft keine Ahnung zu haben, der scheint wohl selber sein eigenes C++ nicht richtig zu kennen.


Boost ist jedenfalls kein Teil der STL.

Gast
2008-03-31, 20:20:29
Genau das meinte ich.



Im Standard ist das alles nicht drin.
Und der Gast der mir vorwirft keine Ahnung zu haben, der scheint wohl selber sein eigenes C++ nicht richtig zu kennen.


Boost ist jedenfalls kein Teil der STL.
[ ] Du kennst C++0x.
[x] Ich kenne C++.

del_4901
2008-03-31, 20:21:16
Genau das meinte ich.



Im Standard ist das alles nicht drin.
Und der Gast der mir vorwirft keine Ahnung zu haben, der scheint wohl selber sein eigenes C++ nicht richtig zu kennen.


Boost ist jedenfalls kein Teil der STL.
*klugscheiss* mit C++09 aber schon! also halt mal schön die Füße still!

del_4901
2008-03-31, 20:26:41
Da gibt es durchaus Zwischenformen die Fragmentierung verhindern und keinen so hohen Overhead haben.

Das Studum bringt einem wieder niks bei, bei uns hats bei Cheney aufgehört. Was gibs denn da noch so aktuelles feines, nur so Interesse halber.


Sowas haben meine Kollegen auch schon kaputt bekommen. :D
<Eigentlich> ist das nicht möglich.


Wir haben einen sehr guten Debug heap manager. Trotzdem geht für die Analyse solcher Bugs immer eine Menge Zeit drauf. Da ich Codeowner der Systemkomponenten bin landen alle Heapfehler erst mal bei mir. Deswegen habe ich da einen recht guten Überblick.
Soll ich jetzt Mitleid haben? :D So ein Debuglog ist schonmal geil, ich würde das auch mit GC haben wollen.

Java Fanboy
2008-03-31, 20:30:38
*klugscheiss* mit C++09 aber schon! also halt mal schön die Füße still!

Ach, bauen die jetzt doch mal ein paar Funktionen von Boost in den nächsten C++ Standard rein, Funktionen die man früher nie haben wollte.


Die C++ Leute scheinen also wohl gemerkt zu haben, daß ihnen wegen Java und C# die Fälle davonschwimmen und jetzt geben sie nach.
Überfällig war das jedenfalls schon lange.


Was dann noch als Makel bei C++ übrig bleibt ist die schön geordnete Klassenhierarchy mit Punktoperator.

z.b.
io.lang.object

del_4901
2008-03-31, 20:33:53
Was dann noch als Makel bei C++ übrig bleibt ist die schön geordnete Klassenhierarchy mit Punktoperator.

z.b.
io.lang.object

Ach ich vergaß, <Shift> ist ja so schwer zu erreichen. Und Namespaces muss man sich ggf auch noch ausdenken. Ach, ist das schlimm wenn Mutti mir nicht die Butterbrote schmiert.

Demirug
2008-03-31, 20:43:14
Das Studum bringt einem wieder niks bei, bei uns hats bei Cheney aufgehört. Was gibs denn da noch so aktuelles feines, nur so Interesse halber.

.Net nutzt da einen interessanten Ansatz mit Generationen. Ist irgendwo im MSDN beschreiben. Ich habe da sowieso den Eindruck dass die aktuell in der Praxis verwendeten GC teilweise doch heftig von den theoretischen Modellen abweichen.

Soll ich jetzt Mitleid haben? :D So ein Debuglog ist schonmal geil, ich würde das auch mit GC haben wollen.

Nein. Ich werde ja dafür bezahlt. Und es gibt ja auch Sachen die interessanter als Bughunting sind. Das größte Problem ist bei diesen Heapfehler ja häufig die Reproduzierbarkeit. Vor allem wenn du ein paar Threads am Laufen hast.

Für.Net gibt es ein spezielles Tool mit dem man sich das aktuelle Speicherlayout genau anzeigen kann. Ist zum Beispiel ganz interessant wenn man sieht welche Objekttypen wie viel Speicher brauchen.

del_4901
2008-03-31, 20:48:01
Demi. Links!!!! Du hast die doch bestimmt gebookmarkerd.

Gast
2008-03-31, 20:48:35
Ach ich vergaß, <Shift> ist ja so schwer zu erreichen. Und Namespaces muss man sich ggf auch noch ausdenken. Ach, ist das schlimm wenn Mutti mir nicht die Butterbrote schmiert.


Also io.lang.irgendwas ist ja wohl besser als irgendwelche für sich gesetzten Namespaces die man dann jedesmal umschalten muß.

Und was du mit shift meinst könntest du ja mal erläutern, ich benutzte zum Proggen Notepad.

del_4901
2008-03-31, 20:54:05
Also io.lang.irgendwas ist ja wohl besser als irgendwelche für sich gesetzten Namespaces die man dann jedesmal umschalten muß.
So nen Quark, dafür gibs den doppel-Doppelpunkt, und der liegt auf <Shift> + <.>


Und was du mit shift meinst könntest du ja mal erläutern, ich benutzte zum Proggen Notepad.
Disquallifiziert!

ScottManDeath
2008-03-31, 21:16:58
Heute in boost, morgen in der STL und uebermorgen auf der ganzen Welt. :)

TR1 ubernimmt Teile (wie z.b. filesystem (in TR2), regex, smart pointer usw) aus boost in den Standard. Entweder nutzt man TR1 ueber boost, http://www.boost.org/doc/libs/1_35_0/doc/html/boost_tr1.html oder ueber die vom Compiler mitgelieferte STL Implementation http://blogs.msdn.com/vcblog/archive/2008/02/25/channel-9-stephan-t-lavavej-digging-into-c-technical-report-1-tr1.aspx

ScottManDeath
2008-03-31, 21:18:51
Für.Net gibt es ein spezielles Tool mit dem man sich das aktuelle Speicherlayout genau anzeigen kann. Ist zum Beispiel ganz interessant wenn man sieht welche Objekttypen wie viel Speicher brauchen.

CLR Profiler?

Trap
2008-04-01, 12:18:43
Bei GCs beschreibt http://www.springerlink.com/content/m36636405668rnp8/ den Stand der Technik von vor 15 Jahre ziemlich gut und ausführlich. Danach wurde am meisten an multithread GCs gearbeitet.

Man kann natürlich auch ohne Kopieren den Adressraum defragmentieren (zumindest bei eindeutig erkennbaren Referenzen): alle Referenzen zu einem Objekt sammeln, es verschieben und dann alle Referenzen aktualisieren. Ab dem Verschieben-Schritt muss man Zugriffe auf den vorigen Speicherbereich (Page) des Objekt abfangen und die Zugriffe auf das Objekt umleiten (das geht mit OS-Mitarbeit ziemlich flott).

Xmas
2008-04-01, 15:37:32
Keine Ahnung ehrlich gesagt. Jedenfalls gibts dort auch 3D-Beschleunigung und aufwändigere sowie weniger aufwändige Spiele. Ich wäre irgendwie davon ausgegangen, dass man dort manchmal nicht besonders viel Speicher zur Verfügung hat aber wie gesagt: Keine Ahnung; ist nur eine Vermutung.
Das stimmt auch, und Entwickler von etwas komplexeren Anwendungen müssen schon sehr darauf achten möglichst wenig Objekte zu erzeugen. Da die Entwickler aber meist darauf achten dass die Anwendung auch auf Handys mit kleinem Java-Heap läuft gibt es für den Anwender normalerweise nur wenig Probleme. Nur sind eben die Möglichkeiten eingeschränkt.

Demirug
2008-04-01, 16:19:42
CLR Profiler?

Das ganze nennt sich SOS und ist eine WinDbg Erweiterung.

SentinelBorg
2008-04-04, 22:10:02
Nicht Java, aber .Net 1.1: http://www.arenawars.net/

Monger
2008-04-04, 22:20:46
Nicht Java, aber .Net 1.1: http://www.arenawars.net/
Ich hab leider keine Beweise dafür, aber ich glaubte auch mal gehört zu haben, dass "Universe at War" auch in .NET geschrieben ist. Und natürlich gibt es schon unzählige kleinere Spieleprojekte, die mit XNA umgesetzt wurden.

Coda
2008-04-04, 22:23:08
Nicht Java, aber .Net 1.1: http://www.arenawars.net/
Der Demo-Installer will .NET 2.0 installieren. 1.1 hätt mich auch gewundert.

Demirug
2008-04-04, 22:29:28
Der Demo-Installer will .NET 2.0 installieren. 1.1 hätt mich auch gewundert.

Das Original Arena Wars war wirklich mit .Net 1.1 programmiert. Das ist ja der Nachfolger Arena Wars Reloaded.

Gast
2008-04-04, 22:38:51
der interpreter wird ganz einfach als .dll oder so mitgeliefert.
DLLs und Konsolen sind ein unschönes Thema... bei Opensource Kram gibts ohne DLLs oft Lizenzprobleme in kommerzieller Software.

Demirug
2008-04-04, 22:47:53
DLLs und Konsolen sind ein unschönes Thema... bei Opensource Kram gibts ohne DLLs oft Lizenzprobleme in kommerzieller Software.

Das ist kein Open Source sondern ein GPL/LGPL (sowie ähnlicher Lizenzen) Problem. In der Regel bekommt man auf einer Konsolen nichts ohne kleine Anpassungen zum laufen. Diese Anpassungen müsste man nun aber veröffentlichen. Das geht aber wiederum in der Regel nicht weil man dann gegen die Lizenz des Entwicklerkits verstoßen würde.

Capt'N Coax
2008-04-13, 21:40:57
Was macht die Diskussion für einen Sinn ohne den Anwendungsbereich abzustecken?

Tatsache (IMO) ist:
In C++ ist einfach ein Großteil der Arbeit Speichermanagment und das Beheben der Fehler die damit in Verbindung stehen. Hier tauscht man die Mächtigkeit der Sprache eben mit schnellerer Entwicklungszeit UND Komplexität. Und gerade die teilweise grottigen IDE's leisten ihren Teil dazu bei, dass ich z.B. mittlerweile ungern C++ programmiere. Es ist mir zu umständlich.

Alle die behaupten, Java wäre zu 'langsam', gehen einfach auch von falschen Vorrausetzungen aus. Das Java Speicher frisst ohne Ende ist bekannt, aber wenn man hier von Casual Games ausgeht, ist der Speicher wohl kaum das Problem auf Mittelklassen-PCs. Einen Highend-Shooter in Java zu entwickeln, halte ich allerdings für nahezu unmöglich (Laufzeitbedingt).

Wer also nicht auf Konsolen setzt und kleine Spielchen, die sich mit einem kleinen Team realisieren lassen, entwickeln will ist IMO mit Engines wie JME gut bedient. Im Gegensatz zu vielen akademischen C++ Engines wie z.B. Crystal Space ist Sie sehr einfach zu entwickeln. Und diese ganzen wahnsinnig vollgestopften Open Source-Großprojekte stehen sich aufgrund ihrer Komplexität selbst im Weg.

Was will ich als Hobby- oder Casual-Entwickler denn erreichen? IMO extrem kurze Entwicklungszeiten und ggf. massive Unterstützung von externen Quellen wie XML etc., schnelles Prototyping und solche Dinge. Da ist C++ meiner Meinung nach die falsche Wahl. Es fängt ja schon mit Grundlagen an, sich für seine Minimal Applikation den ganzen Copy Ctor/Overloading Speicheralloziierungskram anzutun, bevor man mal den ersten Algorithmus fürs Spiel überhaupt in Angriff genommen hat. Aber gut, die Pro's denken da garnicht drüber nach ;-) Bis zum nächsten "end up in the middle of invalid memory".

Es gibt ja einen Grund, warum die "Großen" massiv auf Scripting setzen. Mal abgesehen von den anderen Vorteilen ist es nämlich wesentlich einfacher und wirtschaftlich ökonomischer, seine Logik über Scriptsprachen abzufackeln.

Und Java kommt den Scriptsprachen da schon ein DEUTLICHES Stück näher als C++ es jemals tun wird (was es auch nicht will).

Shit, ich bin mal wieder deutlich hintendran mit dem Beitrag.