VisualZusi

[Arne M]

########### NACHTRÄGLICH EINGEFÜGTER HEADER#########################
-PRIMÄRES ZIEL IST ERSTEINMAL NUR DAS AUSLAGERN DER GRAFIK. Kein LAN-Zusi (Obwohl interessante Idee)
-DIE GENAUE SCHNITTSTELLE UND WAS SIE ÜBERTRÄGT IST MOMENTAN NOCH NICHT WICHTIG. fakt ist nur: Selbst üm dümmsten Fall ihrer Implementierung ist die Datenrate machbar.
-Der Screenshot ist ein Extrembespiel. Er soll zeigen was HEUTE schon mit einer premium Karte machbar ist. Er dient auch dazu jegliche Diskussion über Hardwareressourcen zu unterbinden. Kein Zusi Landschaftsbauer würde es jemals ohne entsprechende Beflanzungsalgorithmen hinbekommen. Aber: Es ist wichtig ihm die Möglichkeiten dazu zu eröffnen.
#############################################################





Hallo Carsten, liebe Zusianer....

Im Aachener Mitgliedertreffen kamen ein paar Ideen auf bezüglich der Grafik von Zusi3.

Ich weiss, dass das Benutzen einer Grafik-Engine allgemein mit großer Skepsis betrachtet wird. Denoch hab ich mir eine Idee einmal genauer angeschaut und ich halte sie für sehr Machbar und lohnenswert.

Soweit ich Zusi3 kenne werden die landschaftsobjekte auch nur als *.x abgespeichert, gleiches gilt für wagons etc.
Nun, man nehme einmal an, man schaffe es ein Programm mithilfe einer Engine (oder auch nicht usw) zu schreiben (C++) dass eine Zusi3 Landschaft laden kann. Desweiteren schaffe man es diesem Programm die Information über die Lage der Gleise zu geben. 3. Man Schaffe es, dass Zusi3 diesem Programm pro frame mitteilt welche beweglichen Objekte ihre Position/Lage wohin verändert haben. Man denke hier an Wagons fahrender Züge oder an Bahnübergänge oder (weichenzungen? ). Datenübermittlung per TCP-Server o. ähnliches. Natürlich sind noch ein paar weitere Informationen nützlich: Wo is die Kamera, bin ich im Tunnel...

Da sich in Zusi in der Regel bis auf die Züge nicht viel bewegt halte ich den Datenvekehr für durchaus überschaubar.
Ein Rechenbeispiel: Es haben sich im frame in Zusi 1000 Objekte bewegt. ein 3d vector ist 96bit gross. davon hat das Objekt 2 (position und rotation) also 192... mal 1000 macht ungf 192 kbit plus die informationen drum rum wie datentyp etc( vernachlässigbar) . mal 50 frames pro sekunde macht roundabaout 2,5 bis 3 Mb die sekunde. Das ginge zur Not sogar noch übers Internet.

Ein Computerspiel übers Netzwerk funktioniert so ähnlich. Das eigentliche Gehirn des Spiels läuft auf einem Server, der Output wird dann Codiert und verschickt. am anderen Ende nimmt das Partnerspiel( was im prinzip nur noch ein Objektbetrachter ist ) diese Informationen, lädt das mesh usw von SEINER festplattte und rendert das ganze.

5. Man schaffe es in zusi3 das rendern abzuschalten.

Wie auch immer, würde man dies schaffen wären der Grafik keine Grenzen mehr gesetzt.

Ich würde es auch ganz alleine machen, das ergebnis wäre es mir wert.

Grüße Arne

[Max Senft]

Hi,

mir hat sich jetzt auf Anhieb das Ziel nicht erschlossen? Soll das ein Viewer sein? Multiplayer-Funktionalität? Wofür soll es gut sein? Du hast bei deiner Berechnung den Overhead vergessen. Es muss ja irgendwie definiert werden welches Objekt welche Koordinate erhält. Desweiteren wird sich nicht in jedem Frame jedes Objekt ändern. Ganz davon abgesehen dass nicht immer jedes Objekt sichtbar sein wird. Und: Soweit ich weiß funktionieren Netzwerk-Spiele/Simulationen nicht auf der Basis, dass Grafikinformationen durchs Netz geschaufelt werden, sondern die Daten über die Objekte. Also die Aktionen, z.B. Schranke 123 öffnet. Der Client wandelt das dann entsprechend in einen Animationsbefehl um. Was auch noch dazu kommt: Wieso eine neue 3D-Engine basteln wenn Carsten schon speziell für Zusi eine entwickelt hat?!

Also: Was ist das Ziel?

Gruß
Max

[ThSchulz]

Ich weiss, dass das Benutzen einer Grafik-Engine allgemein mit großer Skepsis betrachtet wird.

Äh, das musst du nun genauer erläutern. Zusi sieht doch schick aus!?

[Arne M]

Also......
ersteinmal Entschuldigung, dass nicht alles auf Anhieb verständlich ausgedrückt war, die Nachricht ist eigentlich eher an Carsten gerichtet, aber dem kann ich keine persönliche Nachricht schicken.

wie auch immer, ich werde mal versuchen es genauer zu erläutern:

Äh, das musst du nun genauer erläutern. Zusi sieht doch schick aus!?

JA ! Zusi3 sieht sehr gut aus! aber da geht noch was. Vorallem wird da in der Zukunft noch mehr gehen. Stellt sich nun die Frage: wie bringt man Zusi3 dazu die Möglichkeiten moderner Grafikkarten voll auszuschöpfen?

...wo wir nun beim oben nachgefragten Zweck des Ganzen angekommen sind. Also: VisualZusi (oder wie auch immer man es nennen mag) soll, so die idee, eine mögliche Lösung auf diese Frage sein.

Zuerst mal: Braucht man das denn für eine Eisenbahnsimulation überhaupt?
-NEIN! natürlich nicht aber hübsch ist es trotzdem.

Nun zurück zur Idee:
Eine Möglichkeit wäre natürlich, dass Carsten sich noch einmal ein paar Jahre hinsetzt und das Ganze direkt in Zusi regelt. Nur das dauert leider sehr lang, denn eine Grafikkarte mit all ihren heutigen und geplanten Shadertypen voll auszunutzen ist nicht mehr so einfach wie früher.

Um sich diese Arbeit zu ersparen kann man eine Grafik-Engine benutzen. (Keine "basteln", eine benutzen)
Natürlich hat eine fertige Engine ein paar Nachteile: sie kann nicht immer genau das, was man braucht und ein Eisenbahnsim ist nunmal etwas sehr spezielles. Aber ich halte alle denkbaren Zusi "specials" dennoch für machbar, wenn auch nicht immer ohne Umwege.

Nun gibt es noch ein weiteres Problem: Zusi ist in Delphi geschrieben und um auf eine hinreichend große Vielfalt an Engines zurückgreifen zu können sollte man in C++ programmieren.

Da also obige Lösungsansätze nicht ideal erscheinen, kam die Idee dies extern auszulagern.

@Max Senft:
Entschuldige, so genau wollte ich es in den Überlegungen erst einmal nicht nehmen. Natürlich ist ein Datenpaket nicht so groß, wie die Größe seines Inhalts und man sollte die Masse nur auf das notwendige beschränken, aber dass ist für die Grundidee jetz auch nicht so wichtig.

Gedacht ist also ein eigenständiges Programm, welches für Zusi die Grafik darstellt. Es soll eine fertige Engine benutzen um sich Arbeit zu ersparen, den Funktionsumfang der Zusi eigenen Engine halte ich für implementierbar. Damit man es in C++ schreiben kann, soll es ausgelagert werden. Ausserdem erspart es Carsten es selber machen zu müssen. (Ich mache es auch gerne ganz alleine)

Es soll keine Kritik an der Grafik von Zusi3 sein, sondern ein Versuch, Heute schon an Morgen zu denken.

Ich hoffe, dass ich die Ziele nun besser darlegen konnte.

Mfg Arne

PS: wer mal Blut lecken möchte:

[Carsten Hölscher]

Ich denke, dafür gibt es sinnvollere Schnittstellen als tcp.
Recherchier doch vielleicht mal, wie es mit engines für Delphi ausschaut.

Carsten

[Arne M]

Ich denke, dafür gibt es sinnvollere Schnittstellen als tcp.

Welche schnittstelle man auch nehmen mag...... Hauptsache Schnittstelle!

Recherchier doch vielleicht mal, wie es mit engines für Delphi ausschaut.

Auf dem OpenSource Markt gibt es zurzeit eigentlich nur 2 echtzeit fähige populäre Engines.
Diese sind OGRE und Irrlicht. Die meisten anderen freien Engines sind oft Ableger davon und meist zu speziel und unpopulär.

OGRE ist, soweit mir bekannt NICHT für Pascal oder Delphi verfügbar. Für Irrlicht meine ich mal gesehen zu haben, dass jmd einen Wrapper geschrieben hat. Was der taugt/erwaeiterbarkeit/ zukunftschancen kann ich dir leider nichts zu sagen.

Hinzukommt, dass dies noch mit einem weiteren Vorteil freier Engines kollidiert. Neben dem, dass sie natürlich kostenlos sind, sind sie vorallem gut dokumentiert und deswegen leicht erweiterbar. Und es kann sein, dass dieser Vorteil unter Delphi verloren geht (weis es aber nicht)
Die Architekturen von OGRE und Irrlicht wurden halt unter einer "Objektorientierten, C-Syntax nahen" (C++, JAVA, C#, (Python), Objective C ..... ) Denkweise entworfen.


Wie es im kommerziellen Bereich aussieht, weiss ich nicht so ganz genau. Aber tendenziell gilt wohl: What you buy, is what you get, PUNKT!
Ob es da trotzdem Delphi-brauchbares gibt, müsstest du selber recherchieren.

Aber bist du dir sicher, ob es klug ist, GENAU dass in Delphi zu schreiben. Klar, dein eigener Code wird wohl noch eine Weile auf modernen Plattformen kompilierbar sein. wenn auch und ich zitiere mal Roland "Es die Frage ist, ob Carsten es sich leisten kann. Früher oder später wird er wohl irgendwie umsteigen müssen"
Aber das gilt für compilierbarkeit von DEINEN code. Ganz anders sieht es da vlt bei der Vielfalt und Verfügbarkeit von "3D-beschleunigter-Software" aus. Mag sein, dass es momentan Engines für Delphi gibt, aber.....in 10 Jahren wenn vlt zb Raytracing stand der Technik ist und man Zusi gerne wieder etwas aufhübschen möchte, haben wir wieder das selbe Problem.

Apropo:
Könntest du mal alle erdenklichen Zusi spezifischen grafik features aufzählen, damit ich mal prüfen kann ob und wie man das mit einer fertigen Engine implementieren kann. angesrpchen hattest du zb Einschnitte, Signallichter, Tunneleingänge, die erstellung von Vertices und Faces über die engine.

grüße
arne

[Max Senft]

Hinweis: Mein Beitrag bezieht sich auf die Diskussion vor der Antwort von Arne von 11:58:07!

Aha! Ok. Also hatte ich teils richtig vermutet.

Das Vorhaben klingt für mich nach einer Lösung wie man es von multiplayerfähigen Ego-Shootern kennt oder kennen kann. Es gibt einen "dedizierten Server", der prinzipiell die Kontrolle über alles behält und letztendlich den korrekten Zustand der Welt darstellt. Die Clients haben die 3D-Engine integriert, sowie das Userinterface. Diese berechnen dann AFAIK anhand des Startzustands inkrementell weiter, außer es kommt zu einem Verbindungsabbruch. Danach wird wieder neu "gesynct". Übertragen werden aber, wie gesagt, nicht Grafikinformationen, sondern ausgeführte Aktionen und meinetwegen die Veränderung der eigenen Position.

Es wäre natürlich interessant mitlerweile quelloffene Engines (damit meine ich nicht nur die Grafik-Engine, sondern die komplette "Engine") zu untersuchen. Quake 2 oder sowas, was "damals" schon gute Grafiken lieferte und doch lange im Einsatz war, könnte ja zumindest Ansätze geben, wie z.B. die Kommunikation ablaufen könnte.

Einziger Unterschied wäre, dass bei deiner VisualZusi (irgendwie muss ich da immer an M$ denken) Idee die komplette Eisenbahn-Technik (Antriebe, Sicherungen, ...) im Zusi-Server-Programm gerechnet würden. Tasteneingabe also ebenfalls über Ethernet.

Dennoch stellt sich die Frage, ob die Arbeit lohnt? Für ein wenig mehr Grafikrealismus (Schatten z.B.) wäre ich ja auch, aber es gibt dann doch wichtigere Dinge...

Gruß
Max

[BorisM]

Ich glaube nicht, dass es sinnvoll ist, ein Netzwerkspiel so zu realisieren, dass der Server weiterhin die Position aller Objekte berechnet, und laufend stapelweise Koordinaten über das Internet schiebt. Du schreibst ja selber:

mal 50 frames pro sekunde macht roundabaout 2,5 bis 3 Mb die sekunde. Das ginge zur Not sogar noch übers Internet.

"zur Not" ist nicht unbedingt die beste Lösung - und dass 3Mbit pro Sekunde noch übers Internet geht, würde ich so auch nicht unbedingt unterstreichen. Da braucht es dann schon auf jeden Fall einen Server mit sinnvoller Anbindung dafür, der dann aber wiederum einen ziemlich großen Trafficverbrauch hat, gleichzeitig hätte der Server weiterhin relativ viel zu berechnen.

Für das Szenario echtes Spiel über das Internet halte ich daher Dein Konzept der Aufgabenverteilung für alles andere als sinnvoll. Viel sinnvoller wäre es hier, nur jeweils den Status der einzelnen sich bewegenden Objekte zu übertragen - also z.B. die Position der Zugspitze (da reicht ggf. sogar ein eindimensionaler Wert), oder die Signalstellung der Signale. Alles andere kann der jeweilige Client ja selber berechnen. Das lässt sich dann aber nicht mehr so einfach realisieren wie Du es Dir vorstellst - das würde eher bedeuten, den Simulator in weiten Teilen nachzuprogrammieren.

Gerade bei Zusi ist es nicht grade sinnvoll Koordinaten durch die Gegend zu schicken, da ja, wie Du selber schon gesagt hast, sich eigentlich kaum etwas verändert. Und ich glaube ehrlich gesagt auch nicht, dass bei richtigen 3D-Spielen laufend in Echtzeit alle möglichen Objektkoordinaten durch die Leitung geschubst werden, sondern dass da auch einiges an Spiellogik auf den jeweiligen Clients läuft - allerdings ehrlich gesagt ohne es wirklich zu wissen.

Was natürlich prinzipiell gehen würde wäre, eine neue Grafik-Engine an den bestehenden Simulator anzukoppeln, aber da würde ich kein TCP/IP nehmen (unnötiger Verwaltungsoverhead), und vorallem würde ich die Schnittstelle nicht dazu nehmen, einen Multiplayermodus zu realisieren. Ob man es wirklich braucht? Klar, das Bild, das Du eingestellt hast, ist natürlich beeindruckend, nur: Diese Grafik erstellt sich nicht von selbst, dazu braucht es auch jemanden, der die Landschaft entsprechend detailliert baut, und bei einem Zugsimulator, wo man man eben dutzende Kilometer Landschaft braucht, ist das nochmal etwas ganz anderes als bei einem Spiel, wo man vielleicht mit maximal 10km/h unterwegs ist und nicht mit 160.

[Frank Wenzel]

...PS: wer mal Blut lecken möchte:

DONE.
Landschaft / Weg auf deinem Bildchen sieht aus, als wäre es von einem Foto, wie eine Synthese von Streetview+HUD-Informationen. Entnehme ich deinem Bildlink richtig, dass das aus dem Spiel Crisis2 entstammt?

[Arne M]

@Max Senft
Ey Salü. Gaansche mia mo s Saaland griese ? (Aich sin en ex-Määzischa)

Dennoch stellt sich die Frage, ob die Arbeit lohnt? Für ein wenig mehr Grafikrealismus (Schatten z.B.) wäre ich ja auch, aber es gibt dann doch wichtigere Dinge...

Nja C++ würde jedenfalls ermöglichen, dass wir die vorhandenen Ressourcen ( i. d. R. Carsten ) nicht einmal von den "wichtigeren Dingen" abziehen müssen.


Noch ein Anhang zu einer 3D-Engine:
Die Leistungsfähigkeit und der Funktionsumfang von Grafik-Hardware steigt rasant. So schnell, dass man als Einzelner wohl kaum durch direkte OpenGL programmierung mitkommt. Eine Engine ist in der Regel mit ihren vorgängern kompatibel. Es genügt also meist eine Art Update.
Natürlich muss der Objektbauer bei vielen neuen Effekten auch erst mal Objekte bauen, die diese ausnutzen. Aber abwärtskompatibilität ist in der Regel immer sichergestellt.

ass das aus dem Spiel Crisis2 entstammt?

Si, Senior. Wenn auch Langweilig siehts extrem gut aus ^^

grüße
arne

[Frank Wenzel]

...

ass das aus dem Spiel Crisis2 entstammt?

Si, Senior. Wenn auch Langweilig siehts extrem gut aus ^^

grüße
arne

Ah, ok. Das Spiel interessiert mich nicht die Bohne, aber die Grafik ist wirklich absolut beeindruckend und habe ich so noch nie gesehen. Ist das wirklich einfach so aus der Spielhandlung heraus entstanden? Kennst du vielleicht eine Seite, auf der diese Technik hinter dieser fotorealistischen Darstellung beschrieben ist?

[RWMatze]

Dahinter streckt die CryEngine 3 von CryTek

http://mycryengine.com/" target="_blank

[Arne M]

Nja die Cryengine... sieht zwa klasse aus ist aber schlecht erweiterbar.

Willst du richtig was damit anfangen und nicht nur die minimale sdk, dann musst du halt zahlen.

[Michael_Poschmann]

Ich mische mich an dieser Stelle mal kurz ein und möchte eine Passage in Boris Wortmeldung hervorheben:

Diese Grafik erstellt sich nicht von selbst, dazu braucht es auch jemanden, der die Landschaft entsprechend detailliert baut, und bei einem Zugsimulator, wo man man eben dutzende Kilometer Landschaft braucht, ist das nochmal etwas ganz anderes als bei einem Spiel, wo man vielleicht mit maximal 10km/h unterwegs ist und nicht mit 160.

Hier liegt meines Erachtens der Hase im Pfeffer. Aus der Bauerfahrung der letzten Jahre kann ich ableiten, daß mit einem Vortrieb von etwa 20 bis 25 km Strecke je "Bastler-Mannjahr" zu rechnen ist. Wohlgemerkt bei Qualitätsmaßstäben, die in der aktuellen Demo zu "erfahren" sind. Sicherlich lässt sich da noch ein wenig Eye Candy einbauen, aber für ultimative, fotorealistische Diorahmen haben wir schlicht nicht genug Bau-Kapazitäten.

Leider von meiner Seite daher ein wenig Wasser in den Wein, rein aus Pragmatismus.

Gruß
Michael

[Arne M]

Hier liegt meines Erachtens der Hase im Pfeffer

Keine Angst, niesen wir er trotzdem nicht!

Ja, natürlich braucht es länger ein detailiertes Objekt zu bauen , als ein grobes. Aber das hat in erster Linie nichts mit der Maschine zu tun, die das Bild rendert und was die kann. Es geht in erster Linie um Effekte, die sich sowieso von selbst berechnen. (bsp schatten oder lichter oder partikeleffekte ( so wie die strahlen die durch die bäume leuchten)

Erst im 2. schritt der grafikverbesserung muss der landschaftsbauer ran. Aber auch hierzu gibt es eine lösung. Die welt ist nicht nur ein durcheinander, ihr liegen bestimmte strukturen zugrunde. Und dese kann man einprogrammieren. viele solcher algorithmen sind auch opensource. Ich finde nicht, dass das den streckenbau erheblich einschränken dürfte. Ein haus muss man nicht detailierter bauen, als heutzutage. Man sollte vlt nur textur schärfer machen - aber das bedeutet keinen mehraufwand.

Um euch mal eine vorstellung davon zu geben hab ich mal ein video rausgesucht:
http://www.youtube.com/watch?feature=pl ... aAN4zSkY24" target="_blank

Ein bepflanzungs beispiel könnte so aus sehen: Man geht in die natur und zählt wie viele sorten eines typs auf zb einer fläche von 10x10m sind. Nun generiert man in Zusi ein objekt und ermittelt wie groß die wahrscheinlichkeit ist, dass sich diese anzahl der exemplare auf einem quadratmeter oder so befinden und generiert ein zufallszahl, die dann darüber entscheidet ob in diesem teil die pflanze gesetzt wird. (oder ähnliche algrithmen, war jetz frei erfunden) Ich bin zuversichtlich, wenn man solche algrithmen erst mal hat, sie schnell in großer zahl schreiben kann.

grüße
arne

[Michael_Poschmann]

Hallo Arne,

Ein haus muss man nicht detailierter bauen, als heutzutage. Man sollte vlt nur textur schärfer machen - aber das bedeutet keinen mehraufwand.

liegen Dir hierzu bereits Erkenntnisse aus der Praxis in Bezug auf die Umsetzbarkeit vor?

Gruß
Michael
der bisweilen froh war und ist, nach bis zu zwei Jahren intensiver Recherche zu einzelnen Objekten in Privatsammlungen, Heimatvereinsunterlagen und Stadtarchiven überhaupt noch Unterlagen zu regionaltypischen Bauten zu finden

[Arne M]

liegen Dir hierzu bereits Erkenntnisse aus der Praxis in Bezug auf die Umsetzbarkeit vor?

Wie meinst du das jetzt?
also was das Erstellen eines darstellenden Programmes angeht:
-JA!! Ich habe mehrjährige Programmiererfahrung und kenne mich aus im Umgang mit 3d-Engines.

was die Implementierbarkeit der Schnittstelle in Zusi anbelangt:
-NEIN. Das kann nur Carsten beurteilen. Machbar dürfte es auf jeden Fall sein, unklar ist mir nur wie viel Aufwand es beudeutet.

Falls du Angst hast, dass plötzlich all deine mit Mühe gebauten Häuser wertlos würden:
NEIN! das werden sie natürlich nicht! Sie werden genauso dargestellt und genauso aussehen! Detailierter zu bauen hat in erster Linie was damit zun, wieviel Detail deinen Ansprüchen genügt, niemand ist dazu gezwungen wegen einem Mehr an grafischen Effekten seine Objekte vom Detailgrad auf einen gefühlt gestiegenen Ansrpuch des Users anzupassen. Du kannst auch jetz schon in Zusi3 ultra detailiert bauen, der einzige unterschied ist nur, dass dein Objekt zb keinen Schatten werfen wird.


grüße
arne

[Michael_Poschmann]

Hallo Arne,

liegen Dir hierzu bereits Erkenntnisse aus der Praxis in Bezug auf die Umsetzbarkeit vor?

Wie meinst du das jetzt?

Keine Sorge, ich hatte keinesfalls vor, Deine fachlichen Fertigkeiten infrage zu stellen.

Falls du Angst hast, dass plötzlich all deine mit Mühe gebauten Häuser wertlos würden: NEIN! ... Du kannst auch jetz schon in Zusi3 ultra detailiert bauen, der einzige unterschied ist nur, dass dein Objekt zb keinen Schatten werfen wird.

Ich überlege hingegen, wer mit all der schönen Technik die Modelle bauen soll, die diese Features der Fotorealistik nutzen. Basis ist hierbei die hoffentlich halbwegs realistische Einschätzung der Schaffensleistung der Beteiligten im Zusi-Umfeld in den vergangenen Jahren. Potentialabschätzung und Hinweise auf reale Probleme beim Streckenbau hatte ich ja geliefert. Und beim effizienten Ressourceneinsatz sehe ich, persönlich motiviert und daher natürlich subjektiv, noch andere Aufgabenfelder. Was das Programm selbst angeht, bin ich da sicher nicht in einer Entscheider-Rolle. Aber für den Streckenbau versuche ich weiterhin, zwischenzeitlich bewährte Qualitätsmaßstäbe umzusetzen, welche den Spagat zwischen Exaktheit der Darstellung und Projektfortschritt meistern sollen.

Sprich: Werden derartige Möglichkeiten in der Praxis dann auch ausgeschöpft? Oder droht die Gefahr, hier Mannstunde um Mannstunde in die Implementierung zu stecken, "weil es die Technik halt hergibt" - und in der breiten Nutzung kommt das gar nicht an? Ich weiß, ich neige zu Kassandra-Rufen.

Michael

[Matthias S.]

Wenn ich Carsten richtig verstanden habe, ist die in der Demo gezeigte Grafik auch nicht als Endzustand zu verstehen. Effekte wie Schatten oder Regen wird es wohl auch ohne "externe Grafik" irgendwann geben.

[Timey]

leute das wär ne Grafik

http://www.youtube.com/watch?v=qkgK1aUJ ... re=related" target="_blank

ps3 hab ich.. nur das game kostet 100€