Playstation2-Technologie schlecht?

[Wechselbalg]

Gut. Danke für die Ausführungen. :) Kann ich mir dann jetzt etwas eher vorstellen und ruht vielleicht auf meinen eigenen Vorlieben, denn erst mal will ich meist immer vernünftig gefilterte und gute Texturen und Effekte jeglicher Art sind dann meistens eher das Tüpfelchen auf dem i für mich.

Wäre es denn ein sehr großer Aufwand oder Kostenfaktor gewesen der Playstation 2 mehr Grafikspeicher zu geben, oder Mip Mapping zu integrieren?

Ich warte ja immer noch auf das Spiel, das auch optisch dann zulegt, weil es 512 MB braucht und wo nicht einfach eher mittelmäßige Texturen unkomprimiert verwendet werden.

[Asmodeus]

...
Wäre es denn ein sehr großer Aufwand oder Kostenfaktor gewesen der Playstation 2 mehr Grafikspeicher zu geben, oder Mip Mapping zu integrieren?
...


Den GS-Chip der PS2 gab/gibt es auch mit 32MB EDRAM, allerdings eben nicht für die Konsole, da diese Version erst 2002 Marktreife erlangte. (Hoffe, die Jahreszahl stimmt.)

EDIT: Verbaut wurde dieser GS-Chip im sogenannten GScube von Sony. Wobei mich interessieren würde, wieviele von den Dingern überhaupt verkauft wurden und wo sie zum Einsatz kamen.

Gruss, Carsten.

[micki]

Wäre es denn ein sehr großer Aufwand oder Kostenfaktor gewesen der Playstation 2 mehr Grafikspeicher zu geben, oder Mip Mapping zu integrieren?

ich denke schon, dass das ziemlich aufwendig wäre, nicht nur von den herstellungskosten und der konstruktionskomplexität, aber auch die performance wäre sehr gedrückt worden.
das ist aber dann schon theorie, da könnte vielleicht demirug mal mit seinem wissen einspringen ;).

MfG
micki

[Ganon]

gc hat auf dem grakachip ebenfalls 3MB-edram (ich weiß aber nicht wie fix das ist, dürfte aber weit aus schneller als das ram sein).

Der eRAM ist Baugleich mit dem Arbeitsspeicher. Also auch 1T-SRAM und kein eDRAM. Nur halt 6,2ns statt 10ns und breiter Angebunden. ca. 10 GB/s. Also 3mal so schnell wie der MainRAM.

Soweit ich weiß liegt der Vorteil beim GameCube an der recht intelligenten Technik. Das Dekomprimieren der Texturen geschiet in Echtzeit und somit ohne Zwischenspeicher, wenn ich Julian Eggebrecht von Factor5 richtig verstanden habe. Auch soll das FSAA nicht so viel Leistung fressen, da alles erst beim Zeichnen passiert und somit auch FrameGrabber nur Screenshots ohne FSAA bekommen.

[mboeller]

aber der speicher ist eben nicht nur als texturspeicher und auch nicht als einziger texturspeicher konzipiert. texturen hällt man ebenfalls im normalen ram, deswegen ist es ja auch so extrem schnell konzipiert worden (mehrmals schneller als damals ram in pcs).


Falsch!

Die Texturen müssen alle durch den 1200MB/sec Flaschenhals zw. EE und GS durch. 1200MB/sec oder wie man heute sagt 1.2GB/sec sind selbst für 1999 sehr wenig, vor allem da ja alle Polygone auch noch durch dieses Nadelöhr müssen und man einige Texturen per Frame mehrmals laden muss da man sich die alten immer wieder aus dem Speicher schießt. Das ganze Texturmanagement muss AFAIR zudem von Hand erfolgen. Da läuft praktisch nichts automatisch ab.

[Jesus]

Technische Daten:


Die Hälfte davon ist nicht "ganz richtig", um es vorsichtig auszudrücken... :rolleyes:

[Monkey]

Die Hälfte davon ist nicht "ganz richtig", um es vorsichtig auszudrücken... :rolleyes:


dann copy-paste doch die richtigen?

[deekey777]

Wie kommt man nur auf 76GFlops???
[...]

MfG
micki

Das ist der Wert, mit dem für die GF3 auf der AppleExpo 2001 in Tokyo laut geworben wurde. (Dort wurde auch die Doom 3 Engine auf einem Powermac G4&Geforce 3 der Öffentlichkeit gezeigt.)

[micki]

Falsch!

Die Texturen müssen alle durch den 1200MB/sec Flaschenhals zw. EE und GS durch. 1200MB/sec oder wie man heute sagt 1.2GB/sec sind selbst für 1999 sehr wenig, vor allem da ja alle Polygone auch noch durch dieses Nadelöhr müssen und man einige Texturen per Frame mehrmals laden muss da man sich die alten immer wieder aus dem Speicher schießt. Das ganze Texturmanagement muss AFAIR zudem von Hand erfolgen. Da läuft praktisch nichts automatisch ab.
Falsch!
texturen werden per DMA in der EE mit 2.4GB transportiert (128bit bus mit 300MHz mit read+write operationen vom DMA-controller), die VU1 hat einen eigenen path zum GS wo dann geometrie reingefüttert wird, insgesammt gibt es 3mögliche paths um geometrie zum GS zu schicken. AFAIK ist diese bandbreite mehr als AGP8 konnte und für die kleinen texturen der ps2 auch mehr als genug.
das texturemanagement macht jede gute engine eh selbst, auf konsolen sowieso.
zudem zeichnet man alles was dieselbe textur benötigt hintereinander weg, was dafür sorgt das man jede texture maximal ein mal pro frame uploaded.

MfG
micki

[Polydeukes]

ich war damals von der Grafikleistung der PS2 nach dem ganzen Hype sehr enttäuscht: da wurden einem fotorealistische Filmgrafik und Spielwelten wie aus einem Guss versprochen (bezeichnend auch der Name für den "Überprozessor": Emotion Engine). Und was hat man bekommen? Unscharfe Texturen, Geflimmer ohne Ende und teilweise eine Grafik die aussieht wie ein PS1 Spiel mit geringfügig höherer Texturqualität. Sony erfüllt erst 2006 das Versprechen, das 1999 gegeben wurde (Fotorealismus).

[micki]

Das ist der Wert, mit dem für die GF3 auf der AppleExpo 2001 in Tokyo laut geworben wurde. (Dort wurde auch die Doom 3 Engine auf einem Powermac G4&Geforce 3 der Öffentlichkeit gezeigt.)
da hat dann aber jemand "operationen/s" mit "floatingpoint operationen/s" ganz link vermischt.

MfG
micki

[micki]

ich war damals von der Grafikleistung der PS2 nach dem ganzen Hype sehr enttäuscht: da wurden einem fotorealistische Filmgrafik und Spielwelten wie aus einem Guss versprochen (bezeichnend auch der Name für den "Überprozessor": Emotion Engine). Und was hat man bekommen? Unscharfe Texturen, Geflimmer ohne Ende und teilweise eine Grafik die aussieht wie ein PS1 Spiel mit geringfügig höherer Texturqualität. Sony erfüllt erst 2006 das Versprechen, das 1999 gegeben wurde (Fotorealismus).
man würde denken du hast nach der enttäuschung gelernt... nun glaubst du wieder deren versprechen ;)

was mich sorgt ist, dass nun alle spiele verblurt werden unter dem deckmantel von HDR... aber das ist OT.

[mboeller]

leider ist die angabe falsch was die graphicchips betrifft
xbox hat afaik 220MHz


AFAIR 233 MHz


wenn es ums "peak" ginge, wäre die ps2 mit ca 300Mio/s knap vor 250Mio/s vor der XB, aber wie gesagt, diese werte sind absolut nicht vergleichbar, da kann man auch mal nen p4 VS g70 vergleichen



PS2 "peak" ist 66Mio Poly/sec. Mehr passen anscheinend nicht durch den 1200MB/sec Bus durch. Der GS hat ein peak von 75Mio clipping glaube ich.

[micki]

AFAIR 233 MHz




PS2 "peak" ist 66Mio Poly/sec. Mehr passen anscheinend nicht durch den 1200MB/sec Bus durch. Der GS hat ein peak von 75Mio clipping glaube ich.
die triangles müssen nicht durch den bus, da sie backfaces sind. das kann man also schon in der vu verwerfen. so misst man das bei der xb-gpu auch. das hat mal ein nv-guy im opengl.org forum geschrieben, als man dort versuchte die 125M auf einer gf4TI zu erreichen. man war dort weit vom peak entfernt afaik waren nur 25% mit sichtbaren tris zu erreichen.

MfG
micki

[mboeller]

die triangles müssen nicht durch den bus, da sie backfaces sind. das kann man also schon in der vu verwerfen. so misst man das bei der xb-gpu auch. das hat mal ein nv-guy im opengl.org forum geschrieben, als man dort versuchte die 125M auf einer gf4TI zu erreichen. man war dort weit vom peak entfernt afaik waren nur 25% mit sichtbaren tris zu erreichen.

MfG
micki

sag ich ja, das mit dem clipping glaubte ich. der GS hat aber eine max. rate von 75Mio laut Sony marketing docs! Leider komme ich erst Do nach hause und kann das Zeug posten wenn gewünscht.

Ich hab damals alles zur PS2 downgeloaded was ging. Schließlich brauchte ich Munition gegen die verkorkste Architektur. :)

[micki]

kann ich auch gerne machen:


Primitives per second:
150million points
50million textured sprites
75million untextured triangles
37.5million textured triangles


fill rate of 2.4-giga pixel

btw. das ist aber nun das was der GS kann. diese werte sind bei der xbox-gpu nicht besser!

[Jesus]

dann copy-paste doch die richtigen?

Brauch ich nicht, das weiss ich so. Bspw. hat die DC nicht 24MB Speicher sondern 16 (+8MB VRAM).
Wenn mans so angeben würde wie hier müsste man bei der PS2 40MB anstatt 32MB angeben (32+4+2+2 iirc).

[Der Namenlose]

du kannst eben sehr viele alphablend riesenpolys zeichnen, z.B. richtig aufwendige graphikeffekte kannst du komplett in der VU generieren und sorglos in vom rasterizer zeichnen lassen.


Große Polygone soltle man auf der PS2 aber eigentlich nicht zeichnen, wenn sie größer als 32 (?) Pixel sind dann bricht die Leistung auf ca die Hälfte ein. Das liegt daran, dass der GS nochmal einen kleinen Cache hat, in dem die eigentlichen Zeichenoprationen stattfinden. Dieser wird von den 4MB bedient, und deshalb wird auch die enormen internen Bandbreite gebraucht. Sonst wäre es noch viel langsamer. Habe noch nie etwas gesehen, was auf so ineffiziente Weise Bandbreite verschwendet. Ich denke mal PC Grafikchips haben einen ähnlichen Aufbau, allerdings nutzen sie ihre Speicherbandbreite wesentlich effizienter. Das selbe Caching Problem tritt übrigens auf, wenn die Textur nicht ideal skaliert ist für den momentanen Renderingprozess. Auch dann bricht die Leistung stark ein. Auf wirklich jeder PC-Grafikarte kann man einfach texturierte Riesenpoligone mit voller Leistung zeichen, die dann Dankautomatischem MipMapping (ok, bei Voodoo1 mußte man da wohl noch etwas selber rechnen) gut aussehen. Auf der PS2 komtm man da nur auf 25% wenn man naiv vorgeht.
Von fehlenden Blending Modes die schon die Voodoo1 konnte möchte ich mal gar nicht erst anfangen. Und natürlich kann man BumpMappnig zusammen frickeln. Mit 6 Passes und umkopieren zwischen den Farbkomponenten. Aber dann bliebt von der Leistung auch nichts mehr übrig. Das ist ja das traurige, eigentlich ist die Hardware schon herausfordernt. Nur kommt man dann am Ende mit Mühe auf ein Ergebnis, dass man anderswo wesentlich einfacher haben kann.
Aber natürlich führen alle diese Beschränkungen dazu, dass PS2 Games ihr ganz eigenes Aussehen haben.

[micki]

ich hatte was von 2560bit breiten cachelines im kopf was den GS angeht. stimmt aber schon, man kann das ding so nicht vollspeed fahren, aber man geht eh nicht davon aus, dass es viel reuse bei pixeln gibt. der cache soll hauptsächlich wohl für massig particlen mit alphablend sein.

riesenpolygone bringen auf älteren karten nen einbruch, weil du bei großen polys ja auch wohl keine mipmap benutzt sondern wahrscheinlich die höchste stuffe der texture. dabei kannst du gerade bei älteren karten viel cacheloss haben was die texturen betrifft, da hat es manchmal was gebracht wenn man z.b. ne 2d karte zeichnete (übersichts map), diese dann in kleinere stücke zu teilen. mit dxt1 komprimierten texturen war es mit 256*256 ok. (ne 2d karte mit vielen layern kann ganz schö sucken ;) )

MfG
micki

[Der Namenlose]

ich hatte was von 2560bit breiten cachelines im kopf was den GS angeht. stimmt aber schon, man kann das ding so nicht vollspeed fahren, aber man geht eh nicht davon aus, dass es viel reuse bei pixeln gibt. der cache soll hauptsächlich wohl für massig particlen mit alphablend sein.


2560bit (*125Mhz = 40GB/s) ist die Gesamtbreite der Anbindung der 4MB embedded Speicher. Wobei es sich glaube ich auf verschiedene Pfade (lesen, schreiben, Textur, Backbufferm ZBuffer, aufteilt).

[GloomY]

klar wirds komplizierter. Die leute die für Xbox360 und PS3 proggen werden da pionierarbeit leisten müssen, ganz klar. Allerdings geht mir dieses ewige gemeckere von Newell, Carmack und co. auf die Nerven. Das ist halt die Zukunft. Denen wären doch 10GHz Singlecore CPU`s noch am liebsten :|Ja selbstverständlich. Jedem wären 10 GHz SingleCore CPUs lieber als QuadCore mit 2,5 GHz. Ist doch klar. Wenn man nicht perfekt parallelisieren kann, sagt Amdahl's Law, dass die SingleCore CPU schneller ist. Wieviel hängt vom Grad der Parallelisierbarkeit ab.
Es scheint dir wohl nicht pups zu sein, dass diverse Leute nicht deiner Meinung sind, wenn ich mir den Thread so ansehe. Du hast wohl auch monatelang behauptet, dass SPEs Streamingprozessoren sind und hast jeden für blöd erklärt, der das anzweifelte.SPUs sind für Streaming ausgelegt, d.h. sie sind beim Streamen extrem schnell. Trotzdem kann man auf ihnen auch skalare Ops ausführen, das bloss sehr viel langsamer. Damit nutzt man die Fähigkeiten der SPUs nicht annähernd aus.

Es wird also wohl kaum einer was anderes als Streaming auf den SPUs ausführen...
Habe nur aus einer Quelle kopiert, für die Richtigkeit der Angaben übernehme ich keine Gewähr.Du hast noch nicht mal die Quelle angegeben. :nono: Dein Post sieht so aus, als ob das alles von dir stammt. Die Schuld hinterher auf andere zu schieben, überzeugt mich hierbei nicht.


Noch mal allgemein zum Thema, nachdem ich den gesamten Thread gelesen habe:
Ich stimme bei meiner Meinung größtenteils mit Coda, Zeckensack und Payne überein. Das Hardwaredesign ist nicht gerade gut, von ausgewogen kann keine Rede sein. Der von Zeckensack angesprochene Tausch von Geometrieleistung gegen Textur-Fähigkeit ist eine sehr zweischneidige Sache. Bei Titeln, welche durch große Poligonzahlen graphisch profitieren können, mag das ja durchaus schön und beeindruckend sein. Aber es gibt eben auch andere Spiele, die sehr gerne schöne Texturen haben wollen (Rennspiele jeglicher Art) und wo reine Poligonmengen keine schöne Grafik erzeugen.

Die Vernachlässigung der Texturfähigkeiten der PS2 ist ein Designfehler, weil man beim Entwurf der Hardware grundsätzlich darauf achten sollte, dass diese für den Großteil des Einsatzgebietes gut geeignet ist und nicht nur für eine kleinere Teilmenge.(*)

Egal was dann letztendlich an Spielen dabei herauskommt, ist für mich die PS2 rein technisch betrachtet eine Fehlkonstruktion, weil sie ganz einfach unausgeglichen ist.


(*) Das ist u.a. genau auch einer der Kritikpunkte beim P4. Super-geile ADD-Performance, aber bei Bitshift oder FP-DIV sieht es schwarz aus.

[Lost Boy]

Ja selbstverständlich. Jedem wären 10 GHz SingleCore CPUs lieber als QuadCore mit 2,5 GHz. Ist doch klar. Wenn man nicht perfekt parallelisieren kann, sagt Amdahl's Law, dass die SingleCore CPU schneller ist. Wieviel hängt vom Grad der Parallelisierbarkeit ab.


Ja, haste natürlich recht. Multicore ist aber die zukunft. Mich nervt es einfach wenn Carmack, Newell und co. ständig rumheulen und sich beschweren. Allerdings sollte man id und Valve auch nicht als maßtab nehmen. Maßstäbe werden ganz andere setzen, Z.B Polyphony, NoughtyDog oder Kojima Produktions.

SPUs sind für Streaming ausgelegt, d.h. sie sind beim Streamen extrem schnell. Trotzdem kann man auf ihnen auch skalare Ops ausführen, das bloss sehr viel langsamer. Damit nutzt man die Fähigkeiten der SPUs nicht annähernd aus.

verstehe ich nicht so ganz. ich sage mal ganz vorsichtig, eine SPU könnte man auch als vollwertige CPU sehen :sneak: lasse mich aber auch gerne korrigieren.

also warum sollen die SPU´s speziel für streaming ausgelegt sein?

[Coda]

Mich nervt es einfach wenn Carmack, Newell und co. ständig rumheulen und sich beschweren.Alle Entwickler "heulen" deswegen rum, weil es für sie Mehrarbeit bedeutet. Vor allem wenn man solche idiotischen CPU-Konzepte bringt die es einem noch schwerer machen als klassische Architekturen im Multicore-Gewand.

Allerdings sollte man id und Valve auch nicht als maßtab nehmen.John Carmack hat mit Quake damals einiges an Pionierarbeit geleistet was sich bis heute in Egoshootern hartnäckig hält. Der Mann hat soviel Erfahrung dass es fast eine Frechheit ist ihn überhaupt beurteilen zu wollen ohne überhaupt Ahnung davon zu haben.

[StefanV]

Mich nervt es einfach wenn Carmack, Newell und co. ständig rumheulen und sich beschweren.

Hast du schonmal IRGENDWAS programmiert?!
Weißt du, wie groß der Unterschied zwischen Single Threaded und multithreaded ist?!

Weißt du, das Demirug sich auch deswegen schon beschwerte und 'rumheulte'?!
Weißt du, das Multithreaded recht lustig sein kann, wenn man mal 'nen Fehler sucht?!

Allerdings sollte man id und Valve auch nicht als maßtab nehmen. Maßstäbe werden ganz andere setzen, Z.B Polyphony, NoughtyDog oder Kojima Produktions.
LOL, natürlich.

Tschuldigung, aber das klingt so a la: 'mir passt das Gesicht von denen nicht, die Meinung auch nicht, die können garkeine Ahnung haben, was sind das überhaupt für Typen?!'



verstehe ich nicht so ganz. ich sage mal ganz vorsichtig, eine SPU könnte man auch als vollwertige CPU sehen :sneak: lasse mich aber auch gerne korrigieren.

also warum sollen die SPU´s speziel für streaming ausgelegt sein?
Wenn man das könnte, warum sind dann die ganzen Entwickler am 'rumheulen?!

Ev. weils doch nicht so ganz einfach ist?!

[Lost Boy]

John Carmack hat mit Quake damals einiges an Pionierarbeit geleistet was sich bis heute in Egoshootern hartnäckig hält. Der Mann hat soviel Erfahrung dass es fast eine Frechheit ist ihn überhaupt beurteilen zu wollen ohne überhaupt Ahnung davon zu haben.

etwas ahnung habe ich allerdings doch. vielleicht bin ich (noch) nicht auf deinem Level, aber es reicht, um zu behaupten dass John Carmack in Zukunft KEINE Maßstäbe setzen wird. Welche maßstäbe hat den die overhypte Doom 3 Engine gesetzt? In meinen Augen garkeine. Quake ist ein alter hut und interessiert heute niemanden mehr.

Alle Entwickler "heulen" deswegen rum, weil es für sie Mehrarbeit bedeutet. Vor allem wenn man solche idiotischen CPU-Konzepte bringt die es einem noch schwerer machen als klassische Architekturen im Multicore-Gewand.

nur weil du diese konzept nicht verstehst, heisst es noch lange nicht, dass es idiotisch ist. Welche qualifikation gibt dir überhaupt das recht, dieses konzept als idiotisch zu bezeichnen?

[GloomY]

verstehe ich nicht so ganz. ich sage mal ganz vorsichtig, eine SPU könnte man auch als vollwertige CPU sehen :sneak: lasse mich aber auch gerne korrigieren.Vollwertig in dem Sinn, dass sie Turing-mächtig ist. Man kann also mit ihr alles berechnen, was man auch sonst mit anderen CPUs berechnen kann.

Wie schnell die einzelnen Operationen allerdings sind, ist eine ganz andere Frage.
also warum sollen die SPU´s speziel für streaming ausgelegt sein?Es fehlt jegliche Hardware für Branch Prediction. Und ein falsch vorhergesagter Sprung kostet 18 clock cycles!
Code, welcher viele Sprünge enthält, die nicht zu 99% nur in eine Richtung gehen, wird fürchterlich auf den SPUs laufen, trotz dem Vorhandensein von Branch-Hint Befehlen.

Dazu kommt, dass die SPUs in-order sind. Zusammen mit der 6 cycle load-to-use Latency aus dem lokalem Speicher und den 2 cycles (!) für den Register-Zugriff kommt es bei skalarem Code immer und immer wieder zu Wartezyklen.

Außerdem ist der SIMD-Durchsatz einfach genial: 4 FP-MAD (single-precision) Ergebnisse pro Takt. Das schreit einfach nach Streaming. Mit AFAIK 6 Takten Ausführungslatenz bleibt die skalare Performance weit hinter den Möglichkeiten der vektorisierten, bei der man - wie oben erwähnt - eben jeden Takt so ein Ergebnis fertig stellen kann.

[Coda]

etwas ahnung habe ich allerdings doch. vielleicht bin ich (noch) nicht auf deinem Level, aber es reicht, um zu behaupten dass John Carmack in Zukunft KEINE Maßstäbe setzen wird. Welche maßstäbe hat den die overhypte Doom 3 Engine gesetzt? In meinen Augen garkeine. Quake ist ein alter hut und interessiert heute niemanden mehr.Mit der Aussage hast du dich eben selbst ins Abseits begeben.

Doom 3 mag technisch zu früh gekommen sein, deshalb war die Performance eher schlecht und das Artwork eingeschränkt, aber das dynamische Licht ist absolut Zukunftsweisend. F.E.A.R., UE3, Far Cry und noch einige andere setzen genau darauf auf. Vor allem im Bereich Stencil-Schatten hat der Mann einiges geleistet um sie Salonfähig zu machen.

[Lost Boy]

Hast du schonmal IRGENDWAS programmiert?!


Ja. Mein interesse galt bis jetzt (wird auch in zukunft so sein) in erster linie Konsolen. habe bisher an zwei Hobbyprojekten für Dreamcast und PS2 mitgewirkt. bin ja noch jung :biggrin:

Tschuldigung, aber das klingt so a la: 'mir passt das Gesicht von denen nicht, die Meinung auch nicht, die können garkeine Ahnung haben, was sind das überhaupt für Typen?!'

Was haben denn Valve und id bisher weltbewegendes für Konsolen gemacht? genau, fast garnichts. In zukunft werden andere teams die "Big Player" für die spieleentwicklung für konsolen sein, so einfach ist das.

[Lost Boy]

Doom 3 mag technisch zu früh gekommen sein

achja? sollte es nicht ursprünglich flüssig mit ner GF4 laufen?? :rolleyes:

Vor allem im Bereich Stencil-Schatten hat der Mann einiges geleistet um sie Salonfähig zu machen.

Da muss ich dir allerdings doch recht geben. Quake war damals aber wircklich in allen Bereichen absolut revolutionär und zukunftsweisend. und wenn man diese tatsache beachtet, ist die doom3 engine für mich mehr als eine kleine entäuschung.

[Coda]

achja? sollte es nicht ursprünglich flüssig mit ner GF4 laufen?? Es gibt keine Engine dieser Art die schneller läuft. Stencil Shadows verbraten nunmal Unmengen an Füllrate.

[Onkeltom421]

Wie kann es denn sein das Die Doom3engine auf ner GF4 vorgstellt wurde und vernünftig lief?

[Gast]

Warum hat sich Betamax nicht durchgesetzt?
oh man :lol: Wie lange muß das Ding noch herhalten? Warum hat sich Windows angesichts von OS/2 durchgesetzt? blah blah
Oder anders: Warum flamest du eigentlich rum wenn du nichtmal weißt von was du sprichst? :|
Feuer mit Feuer?
Oder noch anders: Warum heult ihr eigentlich wie kleine Kinder wenn es um euer Spielzeug geht, dass ich noch nicht mal kaputtmachen will?
Du legst außer "das Design ist schwachsinnig" hier nicht viel auf den Tisch. Und wenn ein gutes Spiel rauskommt, dann 'willst Du nicht wissen' welcher Aufwand dahinter steckte. Und auch wenn, woher solltest Du auch?

Ich empfinde das nicht so, daß Du mir jetzt versuchst mein altes Lieblinsspielzeug kaputt zu machen. Es ist nur so, daß Du für mich steif und feste Quark erzählst.

Ziel war 8MB Videoram und 64MB Hauptspeicher. War in der damaligen Kalkulation und Herstellungsdichte aber leider nicht drin. Natürlich schade. Die 4Mb Videoram waren für mich übrigens seit anbeginn das einzige was ich sofort als Schwachsinn bezeichnet habe. Sonst war die Kiste 100% DER Treffer. Die Entwickler, PC und PS1 gewonnt, waren zwar am Anfang sehr wohl am stöhnen, aber mit jedem Quartal waren die Spiele besser. Und das hält bis heute an. Irgendwannmal hat man es drauf.

@Payne.
Erzählen tue ich auch viel, Die "KonsolenKiddi" :D

[Jesus]

achja? sollte es nicht ursprünglich flüssig mit ner GF4 laufen?? :rolleyes:

Eigentlich wars ne GF3:)

[Coda]

Es ist nur so, daß Du für mich steif und feste Quark erzählst. GloomY und Zeckensack sind da ganz anderer Meinung. Ich weiß nicht wie oft du dieses Forum besuchst, aber du solltest wissen dass diese Personen genau wie ich einiges an Erfahrung in Sachen HW haben.

Es ist mir eigentlich auch völlig egal was du glaubst, der Thread ist tot. Sobald es um "ihre" Konsolen geht und das diese eventuell sogar Schwächen haben könnten werden manche zu gehirntoten Zombies.

[Neon3D]

hier ist eine recht übersichtliche tabelle der konsolen. die angaben sollten stimmen.


http://www.game-fiction.ch/docs/techspecs.html

[TheGoD]

Die ist allerdings schon ziemlich veraltert, schau dir mal die Angaben zu XBox und Gamecube an.

[Neon3D]

hast du nen anderen link ?

[TheGoD]

CPU: 128 bit "Emotion Engine" clocked at 294 MHz (later versions 299 MHz), 10.5 million transistors
System Memory: 32 MB Direct Rambus or RDRAM (note that some computers use this type of RAM)
Memory Bus Bandwidth: 3.2 GB per second
Main processor: MIPS R5900 CPU core, 64 bit
Co-Processor: FPU (Floating Point Multiply Accumulator × 1, Floating Point Divider × 1)
Vector Units: VU0 and VU1 (Floating Point Multiply Accumulator × 9, Floating Point Divider × 1), 128 bit
Floating Point Performance: 6.2 GFLOPS
3D CG Geometric Transformation: 66 million polygons per second (1)
Compressed Image Decoder: MPEG-2
I/O Processor interconnection: Remote Procedure Call over a serial link, DMA controller for bulk transfer
Cache Memory: Instruction: 16KB, Data: 8KB + 16 KB (ScrP)
Graphics: "Graphics Synthesizer" clocked at 147 MHz
DRAM Bus bandwidth: 47.0GB per second
DRAM Bus width: 2560-bit
Pixel Configuration: RGB:Alpha:Z Buffer (24:8, 15:1 for RGB, 16, 24, or 32-bit Z buffer)
Maximum Polygon Rate: 75 million polygons per second (1)
Dedicated connection to: Main CPU and VU1
Sound: "SPU1+SPU2"
Number of voices: 48 hardware channels of ADPCM on SPU2 plus software-mixed channels
Sampling Frequency: 44.1 kHz or 48 kHz (selectable)
I/O Processor
CPU Core: Original PlayStation CPU (MIPS R3000A clocked at 33.8 MHz or 37.5 MHz)
Sub Bus: 32 Bit
Connection to: SPU and CD/DVD controller.
Interface Types: 2 proprietary PlayStation controller ports, 2 proprietary Memory Card slots using MagicGate encryption, Expansion Bay (DEV9 or PCMCIA on early models) port for Network Adaptor, Modem and Hard Disk Drive, IEEE 1394 (2), Infrared remote control port (2), and 2 USB 1.1 ports with an OHCI-compatible controller.
Disc Media: DVD-ROM (CD-ROM compatible) with copy protection. 4.7GB capacity, a few are DVD-9 (8.5 GB


CPU: 32-Bit Micro PGA2 733 MHz Intel Pentium III, soldered in. (Some sources, such as The Xbox Linux Project, state that the processor is in fact a Mobile Celeron, though it is generally accepted that it is a Pentium III) processor, with a 133 MHz FSB
368 double precision MIPS (Whetstone) per CPU
605 integer MIPS (Dhrystone) per CPU
Graphics Processor: 233 MHz custom chip named the NV2A, developed by Microsoft and nVIDIA (based on of the GeForce 3 but with 2 vertex shaders to the GeForce 3's single vertex shader, and a lower core clock speed)
Total (shared) Memory: 64 MB DDR SDRAM running at 200 MHz, supplied by Hynix or Samsung depending on manufacture date and location
Memory Bandwidth: 6.4 GB/s
Polygon Performance: 125 million flat-shaded polys/second
(Microsoft figure. Some critics assert that the Xbox's polygon-per-second number is exaggerated by unrealistic testing conditions.)
Sustained Polygon Performance: 100+ M/s (transformed and lit polygons per second)
Micropolygons/particles per second: 125 M/s
Particle Performance: 125 M/s
Simultaneous Textures: 4
Pixel Fill Rate - No Texture: 4.0 G/s (anti-aliased)
Pixel Fill Rate - 1 Texture: 4.0 G/s anti-aliased
Compressed Textures: Yes (6:1 through use of DDS)
Full Scene Anti-Aliasing: Yes
Micro Polygon Support: Yes
Storage Medium: 2-5x DVD (XFAT), 8 gigabyte hard disk (new consoles contain a 10GB physical hard drive, though it is formatted to only use 8GB, uses XFAT), optional 8MB memory card for savegame transfer
I/O: 2-5x IDE DVD, 8 or 10GB IDE hard disk, USB memory card (flash)
Audio Channels: 64 3D channels (up to 256 stereo voices)
3D Audio Support: Yes, 5.1
MIDI DLS2 Support: Yes
AC3 (Dolby Digital) Encoded Game Audio: Yes (via TOSLINK)
Broadband Enabled: Yes (10/100base-T ethernet)
DVD Movie Playback: Yes (separate DVD Playback Kit/Remote required)
Maximum Resolution (2x32bpp frame buffers +Z): 1920(vert.)x1080(horiz)
Note: NTSC (Non-HD) TV's have less than 500 horizontal lines. PAL TV's have less than 600 horizontal lines.
EDTV and HDTV Support: 480p/720p/1080i (see game boxes for supported resolutions).
Controller Ports: 4 proprietary USB ports



CPU: SH-4 RISC CPU with 128 bit graphic computational engine built-in (operating frequency: 206 MHz 360 MIPS/1.4 GFLOPS)
Graphics Engine: PowerVR2 CLX2, capable of drawing around 7 million polygons per second (though rarely pushed this far; the models for the polygons would become a limiting factor, chipping away video memory for the textures)
Memory: Main RAM: 16 MB (Hyundai), Video RAM: 8 MB, Sound RAM: 2 MB
Sound Engine: Super Intelligent (Yamaha) Sound Processor with 47MHz 32-Bit ARM7 RISC CPU core built-in (64 channel PCM/ADPCM)
GD-ROM Drive: 12x maximum speed (when running in Constant Angular Velocity mode)
GD-ROM: Holds up to 1.2 GB of data. A normal CD-ROM holds 700 megabytes.
Inputs: USB-like "Maple Bus". Four ports support devices such as digital and analog controllers, steering wheels, joysticks, keyboards and mice, and more.
Dimensions: 189 mm x 195 mm x 76 mm (7 7/16" x 7 11/16" x 3")
Weight: 1.9 kg (4.4 lb)
Color: White
Modem: Removable; Original Asia/Japan model had a 33.6 kbit/s; models released after September 9, 1999 had a 56 kbit/s modem
Broadband: these adapters are available separately and replace the removable modem
HIT-400: "Broadband Adapter", the more common model, this used a Realtek 8139 chip and supported 10 and 100 Mbit speeds.
HIT-300: "Lan Adapter", this version used a Fujitsu MB86967 chip and supported only 10 Mbit speed.
Color Output: Approx. 16.77 million simultaneous colors (24 bit)
Storage: Visual Memory Unit ("VMU") 128 Kb removable storage device and 4x memory cards that hold four times as much data



Central processing unit
Name: "Gekko"
Producer: IBM
Core Base: PowerPC 750CXe, 43-mm² die (modified PowerPC 750 RISC with 50 new instructions)
Manufacturing Process: 0.18 micrometre IBM copper-wire technology
Clock Frequency: 485 MHz
CPU Capacity: 1125 Dmips (Dhrystone 2.1)
Internal Data Precision:
32-bit Integer
64-bit Floating-point, usable as 2x32-bit SIMD
External Bus:
1.3 gigabyte/second peak bandwidth
32-bit address space
64-bit data bus; 162 MHz clock
Internal Cache:
L1: instruction 32KB, data 32KB (8 way)
L2: 256KB (2 way)
[edit]
Graphics processing unit
Name: "Flipper"
Producer: ArtX/Nintendo (ArtX was acquired by ATi Technologies in 2000 and is now a part of ATi)
Manufacturing Process: 0.18 micrometre NEC embedded DRAM process
Clock Frequency: 162 MHz
Embedded Frame Buffer:
Approximately 2 megabytes in capacity
Sustainable latency of 6.2 nanoseconds
RAM type is 1T-SRAM
Embedded Texture Cache:
Approximately 1 megabyte in capacity
Sustainable latency of 6.2 nanoseconds
RAM type is 1T-SRAM
Texture Read Bandwidth: 10.4 gigabytes/second (at peak)
Main Memory Bandwidth: 2.6 gigabytes/second (at peak)
Fill Rate: 648 megapixels/second
Pixel Depth:
24-bit RGB / RGBA
24-bit Z-buffer
Image Processing Functions:
Fog
Subpixel anti-aliasing
8 hardware lights
8 pixels pipeline
hardware nurbs
Alpha blending
Virtual texture design
Multi-texturing, bump mapping
Environment mapping
MIP mapping
Bilinear filtering
Trilinear filtering
Anisotropic filtering
Real-time hardware texture decompression (S3TC)
Real-time decompression of display list
Hardware 3-line deflickering filter
[edit]
Audio specifications
Producer: Macronix
Clock Frequency: 81 MHz
Instruction Memory:
8 kilobytes of RAM
8 kilobytes of ROM
Data Memory:
8 kilobytes of RAM
4 kilobytes of ROM
Simultaneous Channels: 64 channels
Encoding: ADPCM
Sampling Frequency: 48 kHz
206mb graphics
"Dolby Pro Logic II" in analog audio out
AC3 signal through "digital out" with D-erminal cable
[edit]
Other system specifications
System Floating-point Arithmetic Capability: 10.5 GFLOPS (at peak) (MPU, Geometry Engine, HW Lighting Total)
Real-world Polygon Performance: 6 million to 12 million polygons/second (at peak) (assuming actual game conditions with complex models, fully textured, fully lit, etc.)*
Main RAM:
Approximately 24 megabytes in capacity
Sustainable latency of 10 nanoseconds
RAM type is 1T-SRAM
(Even though DDR-SDRAM is significantly faster, since the PowerPC 750CXe can not address DDR-SDRAM, it is not used.)

Auxiliary RAM:
Approximately 16 megabytes in capacity
81 MHz in speed
RAM type is DRAM
Disc Drive:
Drive type is Constant Angular Velocity (CAV)
Average access time is 128 milliseconds
Data transfer speed is between 2 megabytes per second and 3.125 megabytes per second
Disc Media:
Based on DVD technology
Diameter is 3 inches in length
Producer is Matsushita (Also known as Panasonic)
Approximately 1.5 gigabytes in capacity
Controller Ports: 4
Memory Card Slots: 2
Analog Audio/Video Outputs: 1
Digital Video Outputs: 1 *
High-speed Serial Ports: 2
High-speed Parallel Ports: 1
Power Supply: AC Adapter DC12 volts x 3.25 amperes
Physical Measurements of Entire System: 110 mm (H) x 150 mm (W) x 161 mm (D). [4.3"(H) x 5.9"(W) x 6.3"(D)]
* The Digital output was removed in a hardware revision in May 2004. Models without the port are DOL-101. [3] The original system with the port is model DOL-001.


Wikipedia ist dein Freund... :wink:

[aths]

Muss ich wirklich exakt anführen was an dem Ding scheiße ist? Wäre nicht schlecht.

[aths]

wieviel kann ein mensch schreiben ohne dass es das geringste mit dem quote zu tun hat?Das hat mittelbar imo durchaus was damit zu tun. Die PS2 schleppt das ganze PS1-Zeug mitsich – ein wichtiger Grund für den Erfolg. Ähnlich sah es bei den x86-Chips aus.

[aths]

Klar kann ein Spiel auch Spaß machen wenn es wie blöde flimmert, scheiß Texturen hat und ggf. noch ruckelt. ABER DAS IST HIER EGAL. Es geht darum ob die PS2-Technik nun schlecht ist, oder nicht. Und momentan ist die Meinung hier wohl "schlecht", da keiner so richtige Vorteile der Technik nannte, außer vielleicht hohe Polygon-Anzahl.Das hängt davon ab. Eigentlich bin ich dafür, Konsolen-Hardware so einfach wie möglich zu bauen, um eine schmerzlose Programmierung zu erlauben. Außerdem halte ich es für wichtig, auf Texturleistung zu achten. Nun kann die PS2 zwar recht viele Pixel pro Sekunde berechnen, aber die Grafikunit bietet nur Singletexturing. Das ist für aktuelle Engines selten dämlich, wenn man zum Auftragen mehrerer Texturen mit Alphablending arbeiten muss.

Andererseits bin ich auch für Vielfalt, und damit auch für Konzepte, die meinem Geschmack widersprechen. Es wäre sicher möglich gewesen Hardware zu bauen, die mehr Vorteile in sich vereint als es die PS2 tut (in man bestimmte Nachteile reduziert hätte) aber nach welchem Maßstab will man jetzt Bewertungen wie "gut" oder "schlecht" abgeben? Resident Evil 4 sieht auf dem Cube sehr gut, auf der PS2 deutlich schlechter aus. Andersrum sind auf der PS2 Spiele möglich, die der Cube nicht packt. Es sind eben unterschiedliche Ansätze.

In Gran Turismo 3 (und 4) hat ein einzelnes Auto sehr viele Polygone – ich kenne kein Spiel zu damaliger Zeit, welches annähernden TV-Realismus à la Gran Turismo 3 bot. Ohne "schlechte" PS2 wohl kein Gran Turismo 3 und 4. Wurden die Spiele trotz, oder dank PS2-HW ermöglicht?

[Jesus]

GloomY und Zeckensack sind da ganz anderer Meinung. Ich weiß nicht wie oft du dieses Forum besuchst, aber du solltest wissen dass diese Personen genau wie ich einiges an Erfahrung in Sachen HW haben.

... nur bringen diese auch einleuchtende Argumente.

[micki]

Das hat mittelbar imo durchaus was damit zu tun. Die PS2 schleppt das ganze PS1-Zeug mitsich – ein wichtiger Grund für den Erfolg. Ähnlich sah es bei den x86-Chips aus.
und was hat das ganze mit meiner frage zu tun, ob praktische erfahrung bei einem kritiker der ps2-hardware besteht?

[san.salvador]

Das hängt davon ab. Eigentlich bin ich dafür, Konsolen-Hardware so einfach wie möglich zu bauen, um eine schmerzlose Programmierung zu erlauben. Außerdem halte ich es für wichtig, auf Texturleistung zu achten. Nun kann die PS2 zwar recht viele Pixel pro Sekunde berechnen, aber die Grafikunit bietet nur Singletexturing. Das ist für aktuelle Engines selten dämlich, wenn man zum Auftragen mehrerer Texturen mit Alphablending arbeiten muss.

Andererseits bin ich auch für Vielfalt, und damit auch für Konzepte, die meinem Geschmack widersprechen. Es wäre sicher möglich gewesen Hardware zu bauen, die mehr Vorteile in sich vereint als es die PS2 tut (in man bestimmte Nachteile reduziert hätte) aber nach welchem Maßstab will man jetzt Bewertungen wie "gut" oder "schlecht" abgeben? Resident Evil 4 sieht auf dem Cube sehr gut, auf der PS2 deutlich schlechter aus. Andersrum sind auf der PS2 Spiele möglich, die der Cube nicht packt. Es sind eben unterschiedliche Ansätze.

In Gran Turismo 3 (und 4) hat ein einzelnes Auto sehr viele Polygone – ich kenne kein Spiel zu damaliger Zeit, welches annähernden TV-Realismus à la Gran Turismo 3 bot. Ohne "schlechte" PS2 wohl kein Gran Turismo 3 und 4. Wurden die Spiele trotz, oder dank PS2-HW ermöglicht?
Man stelle sich vor wie GT 4 mit 6 oder gar 8 MB Vram aussehen könnten... :rolleyes:
Die PS2 Lässt sich vielleicht gut mit einem 500 Liter Fass vergleichen, dass nur ein Loch mit einem Durchmesser von zwei Zentimeter hat (Flaschenhalsanalogie).

[Coda]

Wäre nicht schlecht.Na gut, weils ihrs seid.

1. Der GS kann nur Singletexturing, kein Multipass
2. Er erreicht nur ohne Textur den Durchsatz von 16Pixel/Cycle, also 2,4GTexel/s mit einer Textur nur noch die Hälfte (wozu überhaupt die Frambuffer-Bandbreite?)
3. Sämtliche Vertexdaten die der GS zeichnen soll kommen von VU1 über den Uplink.
4. Diese müssen pro Pass neu übertragen werden, es gibt keinen Vertexbuffer auf dem GS.
5. Falls nicht genügend Speicher in den eh schon mageren 32MiB zur Verfügung steht muss VU1 pro Pass die Transformationen neu durchführen.
6. Für das ganze Zeug muss von der VU1 eine spezielle für den GS gerechte "Kommandosprache" erzeugt werden für jeden Pass.
7. 1MiB VRAM ohne Texturkompression (Framebuffer abgezogen)
8. Alle Transfers vom Speicher außer zur EE müssen wenn sie performant abgewickelt werden sollen asynchron durch den DMA-Controller ausgeführt werden (auch wenn Texturen ausgetauscht werden müssen, was öfters der Fall ist)
9. Man muss ständig aufpassen, dass die Daten die man verwenden möchte auch rechtzeitig am Zielort sind.
10. Die CPU hat sogar einen "Scratchpad" Speicher, der nicht gecached ist und auch nicht viel schneller als das normal RAM mit dem man rechnen soll wenn der DMA-Controller gerade am Hauptspeicher saugt.

Usw. usw. Die ganzen Zusammenhänge sind in dem Ding alles andere als trivial und man muss alles selber machen.

Zum Vergleich: Bei der Xbox lad man nen Vertexshader, setzt das Multitexturing-Setup und lässt das Ding rendern, dazu ist alles in einem vereinten Speicher.

[mboeller]

2560bit (*125Mhz = 40GB/s) ist die Gesamtbreite der Anbindung der 4MB embedded Speicher. Wobei es sich glaube ich auf verschiedene Pfade (lesen, schreiben, Textur, Backbufferm ZBuffer, aufteilt).


150MHz x 1024bit für die 8 TMU's ( direkter "Draht zw. eDRAM und TMU's)
weitere 1024bit für die 8 "Blending-Units"
+ 512bit um die Texturen zu den 8 richtigen TMUs zu bekommen.


macht 2560bit x 150MHz

[mboeller]

Na gut, weils ihrs seid.

1. Der GS kann nur Singletexturing, kein Multipass
2. Er erreicht nur ohne Textur den Durchsatz von 16Pixel/Cycle, also 2,4GTexel/s mit einer Textur nur noch die Hälfte (wozu überhaupt die Frambuffer-Bandbreite?)
3. Sämtliche Vertexdaten die der GS zeichnen soll kommen von VU1 über den Uplink.
4. Diese müssen pro Pass neu übertragen werden, es gibt keinen Vertexbuffer auf dem GS.
5. Falls nicht genügend Speicher in den eh schon mageren 32MiB zur Verfügung steht muss VU1 pro Pass die Transformationen neu durchführen.
6. Für das ganze Zeug muss von der VU1 eine spezielle für den GS gerechte "Kommandosprache" erzeugt werden für jeden Pass.
7. 1MiB VRAM ohne Texturkompression (Framebuffer abgezogen)
8. Alle Transfers vom Speicher außer zur EE müssen wenn sie performant abgewickelt werden sollen asynchron durch den DMA-Controller ausgeführt werden (auch wenn Texturen ausgetauscht werden müssen, was öfters der Fall ist)
9. Man muss ständig aufpassen, dass die Daten die man verwenden möchte auch rechtzeitig am Zielort sind.
10. Die CPU hat sogar einen "Scratchpad" Speicher, der nicht gecached ist und auch nicht viel schneller als das normal RAM mit dem man rechnen soll wenn der DMA-Controller gerade am Hauptspeicher saugt.

Usw. usw. Die ganzen Zusammenhänge sind in dem Ding alles andere als trivial und man muss alles selber machen.

Zum Vergleich: Bei der Xbox lad man nen Vertexshader, setzt das Multitexturing-Setup und lässt das Ding rendern, dazu ist alles in einem vereinten Speicher.


du hast noch was "vergessen". Die TMU's sind 8x1 in Scanline organisiert. Das heißt bei vielen kleinen Polygonen, für die die PS2 angeblich wie geschaffen ist geht die Effizienz des GS voll in den Keller.

[Coda]

Ja war ja auch nur ein Ausschnitt. Mehr ist mir gerade nicht eingefallen :ugly:

[aths]

und was hat das ganze mit meiner frage zu tun, ob praktische erfahrung bei einem kritiker der ps2-hardware besteht?Er hat auf die Teilfrage nach dem "Scheiß" geantwortet.

[aths]

Na gut, weils ihrs seid.

1. Der GS kann nur Singletexturing, kein Multipass
2. Er erreicht nur ohne Textur den Durchsatz von 16Pixel/Cycle, also 2,4GTexel/s mit einer Textur nur noch die Hälfte (wozu überhaupt die Frambuffer-Bandbreite?)
3. Sämtliche Vertexdaten die der GS zeichnen soll kommen von VU1 über den Uplink.
4. Diese müssen pro Pass neu übertragen werden, es gibt keinen Vertexbuffer auf dem GS.
5. Falls nicht genügend Speicher in den eh schon mageren 32MiB zur Verfügung steht muss VU1 pro Pass die Transformationen neu durchführen.
6. Für das ganze Zeug muss von der VU1 eine spezielle für den GS gerechte "Kommandosprache" erzeugt werden für jeden Pass.
7. 1MiB VRAM ohne Texturkompression (Framebuffer abgezogen)
8. Alle Transfers vom Speicher außer zur EE müssen wenn sie performant abgewickelt werden sollen asynchron durch den DMA-Controller ausgeführt werden (auch wenn Texturen ausgetauscht werden müssen, was öfters der Fall ist)
9. Man muss ständig aufpassen, dass die Daten die man verwenden möchte auch rechtzeitig am Zielort sind.
10. Die CPU hat sogar einen "Scratchpad" Speicher, der nicht gecached ist und auch nicht viel schneller als das normal RAM mit dem man rechnen soll wenn der DMA-Controller gerade am Hauptspeicher saugt.

Usw. usw. Die ganzen Zusammenhänge sind in dem Ding alles andere als trivial und man muss alles selber machen.

Zum Vergleich: Bei der Xbox lad man nen Vertexshader, setzt das Multitexturing-Setup und lässt das Ding rendern, dazu ist alles in einem vereinten Speicher.Schön: Xbox macht das, was wir (vor allem aus dem PC-Bereich) so kennen. Sony wählte einen anderen Ansatz. Schlecht: Erfahrungen aus dem PC-Bereich sind beinahe wertlos. Gut: Speziell für die PS2 entwickelte Spiele sind unverwechselbar. Die PS2 ist – entgegen der Werbung – nicht als Grafikmonster geschaffen. Na und? Wenn die Spiele so aussehen, wie sie das jetzt tun, kann ich damit leben.

Für Resident Evil nehme ich den Cube, für GT4 die PS2 – the right tool for the right job. (Eine Xbox speziell für NFS kaufe ich aber nicht, da genügt mir die PS2-Version.)

[aths]

Man stelle sich vor wie GT 4 mit 6 oder gar 8 MB Vram aussehen könnten... :rolleyes: Falls noch MIP-Mapping, gar trilineare Filterung geboten würde: Besser. Obwohl ich es nicht glaube, habe ich noch ein bisschen Hoffnung, dass man auf der PS3 die PS2-Spiele in besserer Qualität spielen kann (zur Not per Supersampling realisiert.)

[RoKo]

4. Diese müssen pro Pass neu übertragen werden, es gibt keinen Vertexbuffer auf dem GS.
Ein Vertexbuffer in einem reinen Rasterizer wäre aber auch reichlich Fehl am Platz.

[micki]

Na gut, weils ihrs seid.
1. Der GS kann nur Singletexturing, kein Multipass

gibt nur multipass, multitexturing ist nicht enthalten in hardware. (realisiert man durch überlappende tris)


2. Er erreicht nur ohne Textur den Durchsatz von 16Pixel/Cycle, also 2,4GTexel/s mit einer Textur nur noch die Hälfte (wozu überhaupt die Frambuffer-Bandbreite?)
gibt einige dinge, im besonderen particle, die ohne texturen auskommen. diese werden in massen direkt in der VU1 generiert und mit vertexcolors versehen.


3. Sämtliche Vertexdaten die der GS zeichnen soll kommen von VU1 über den Uplink.

gibt insgesammt 3 paths zum GS, nicht alle daten kommen also von VU1.



4. Diese müssen pro Pass neu übertragen werden, es gibt keinen Vertexbuffer auf dem GS.
der vertexcahce ist auf der VU, 16kb. also nicht auf nur 24vertices wie z.b. bei der xbox limitiert, sodass die VU nicht immerwieder, unnötig, dieselbe transformation durchführen muss.


5. Falls nicht genügend Speicher in den eh schon mageren 32MiB zur Verfügung steht muss VU1 pro Pass die Transformationen neu durchführen.

nein, fertig transformierte (und geclippte) geometrie kann in den internen 16kb abgelegt werden, wird bei multipass auch oft so gemacht. z.b. bei den fahrzeugen in GT4.


6. Für das ganze Zeug muss von der VU1 eine spezielle für den GS gerechte "Kommandosprache" erzeugt werden für jeden Pass.

nein, afaik kann man das einmal erzeugte format mehrmals in den GS kicken.


7. 1MiB VRAM ohne Texturkompression (Framebuffer abgezogen)

wobei man oft mit 4bit oder 8bit pro pixel hinkommt. man verwendet auch keine 'teuren' normalmaps, sodass 1MB von einem extrem schnellen speicher sehr viel ist, verglichen z.b. mit dem relativ langsamen allroundmem der xbox.


8. Alle Transfers vom Speicher außer zur EE müssen wenn sie performant abgewickelt werden sollen asynchron durch den DMA-Controller ausgeführt werden (auch wenn Texturen ausgetauscht werden müssen, was öfters der Fall ist)
jap, währenddessen können die recheneinheiten rechnen, wäre ja blöd wenn sie dazu verdammt wären speicher zu scheffeln. zum vergleich mit anderen konsolen: der einzig performante weg dort an speicher zu kommen, ist zu hoffen, dass der betreffende bereich noch im cache liegt, ansonsten gibt es ein cachemiss der locker 100cycles verschwenden kann.


9. Man muss ständig aufpassen, dass die Daten die man verwenden möchte auch rechtzeitig am Zielort sind.
emm... ja, so ist die welt. auch auf dem pc muss man einen texturebuffer füllen, bevor man die texture benutzen kann, selbst die konsolen mit den "unified" speichern müssen zumindestens quadweise immerwieder texturen in ihren cache nachladen.


Usw. usw. Die ganzen Zusammenhänge sind in dem Ding alles andere als trivial und man muss alles selber machen.

...man kann alles selber machen, was bei anderen systemen nicht gegeben ist. wenn man nicht alles selber machen möchte, kann man ne oGL lib nutzen. die zwar recht performant ist, aber nicht das letzte bisschen aus der ps2 rauskratzt.
auf anderen systemen muss man damit halt leben. bzw. kann man sich auf der xbox die commandos reverse enginieren und so wie in dx3 kleine "executive buffer" zusammenstellen, die dann wie die commandos and den GS in der ps2, in einer hardwarenahen und performanten art und weise ablaufen.


Zum Vergleich: Bei der Xbox lad man nen Vertexshader, setzt das Multitexturing-Setup und lässt das Ding rendern, dazu ist alles in einem vereinten Speicher.
zum vergleich: bei der ps2 setzt man ein VU1 programm, kann darin geometrie generieren, es gibt von sony sogar ein sample bei dem die ganze geometrie eines kleinen spiels in der VU generiert wird. man muss also nicht für jedes kleine dumme objekt einen renderaufruf machen. dazu hat jeder prozessor seinen optimierten, dedizierten speicher, sodass sich die einheiten nicht ständig um bandbreite 'streiten' müssen.

[Jesus]

Danke, sehr aufschlussreich. :rolleyes:

Da sieht man mal wieder wie sehr sich Theorie und Praxis unterscheiden können...

[Gent!eman]

Path of Neo soll ja Normal Mapping haben, ist dachte, das wäre ein DX8-Shader-Feature

[micki]

btw: http://www.bringyou.to/games/PS2.htm
sollte man sich mal durchlesen um sich mal eine vorstellung machen zu können, die über ein paar leistungswerte hinaus geht.

MfG
micki

[aths]

Path of Neo soll ja Normal Mapping haben, ist dachte, das wäre ein DX8-Shader-FeatureHrm? Dot3-Operationen sind auch in DirectX7 möglich, wenn auch erst in DirectX8 Pflicht. Bestimmte Formen eines Dependend Reads für EMBM sind auch erst ab DX8 Pflicht – aber schon in DX6 vorgesehen.

[Jules]

Path of Neo soll ja Normal Mapping haben, ist dachte, das wäre ein DX8-Shader-Feature
die ps2 kann man zwischen dx7-dx8 platzieren

das mit path of neo hab ich auch mal gehört
aber bump maps sind generell nicht auf der ps2 machbar

aber die experten hier werden uns schon aufklären

[aths]

die ps2 kann man zwischen dx7-dx8 platzieren

das mit path of neo hab ich auch mal gehört
aber bump maps sind generell nicht auf der ps2 machbarWozu, wenn man es über Geometrie machen kann? Für feine Details wie mit Bumpmapping ist die PS2 nicht optimiert, aber das Ding ist offenbar dafür gedacht, Geometrie als Geometrie zu rendern und nicht Geometrie zu faken.

[aths]

btw: http://www.bringyou.to/games/PS2.htm
sollte man sich mal durchlesen um sich mal eine vorstellung machen zu können, die über ein paar leistungswerte hinaus geht.Wenn ich das sehe – müsste ich für die PS2 proggen, würde mir übel. Auf der anderen Seite, mit profunder Erfahrung in Dingen PS2-Programmierung müsste man da Dinge realisieren können, die andere Hardware so nicht bietet. Das Rendern prozeduraler Strukturen gefällt mir außerordentlich. Zum Glück muss ich das Teil nicht programmieren.

[Jules]

Wozu, wenn man es über Geometrie machen kann? Für feine Details wie mit Bumpmapping ist die PS2 nicht optimiert, aber das Ding ist offenbar dafür gedacht, Geometrie als Geometrie zu rendern und nicht Geometrie zu faken.

ok
das stimmt auch wieder :D
aber du willst doch keine 200k polys für ne figur verschwenden
die ps2 kann (imo) wirklich einiges
aber nicht soviel

(man bedenke noch gegner und umgebung.........vielleicht bei einem BEAT´em UP :D )
aber ich versteh schon worauf du hinaus wills
und grundsätzlich geb ich dir auch recht

edit:
PS: ich finde dieses faken (vorgaukelei) sowieso fürn arsch
um nicht zu sagen hasse ich es
und außerdem finde ich es viel schöner wenn polygon-teile durch die umgebung fliegen und dabei häuserfassaden "wirklich" demoliert werden

[micki]

das mit path of neo hab ich auch mal gehört
aber bump maps sind generell nicht auf der ps2 machbar
doch, es ist möglich, aber es macht bisher kein spiel, weil es zu aufwendig ist (das schlimme ist wohl der textureverbrauch).


Wenn ich das sehe – müsste ich für die PS2 proggen, würde mir übel. Auf der anderen Seite, mit profunder Erfahrung in Dingen PS2-Programmierung müsste man da Dinge realisieren können, die andere Hardware so nicht bietet. Das Rendern prozeduraler Strukturen gefällt mir außerordentlich. Zum Glück muss ich das Teil nicht programmieren.

wie schon gesagt, gibt es oGL implementationen. aber die PS2 ist nunmal ein spielzeug für lowlevel-guys. leute die früher gerne softwareraster schrieben, die cpu des diskettenlaufwerks für berechnungsbeschleunigung nutzten und keinen tweak ungenutzt ließen um das letzte aus der VGA graphik eines 386 zu erhalten, diese leute haben mit der ps2 ein spielzeug dass 1000mal mehr spass macht als jedes spiel dass darauf rauskommt ;)
sowas hätte eigentlich nen würdigen nachfolger verdient... informe einer ps3... mit 4cell drinne *hehehe*....

gerade deswegen wundert es mich, dass zeckensack gegen die ps2 technik wettert... er hat wohl kein blut geleckt bisher ;)

MfG
micki

[micki]

ok
das stimmt auch wieder :D
aber du willst doch keine 200k polys für ne figur verschwenden
die ps2 kann (imo) wirklich einiges
aber nicht soviel

(man bedenke noch gegner und umgebung.........vielleicht bei einem BEAT´em UP :D )
aber ich versteh schon worauf du hinaus wills
und grundsätzlich geb ich dir auch recht

edit:
PS: ich finde dieses faken (vorgaukelei) sowieso fürn arsch
um nicht zu sagen hasse ich es
und außerdem finde ich es viel schöner wenn polygon-teile durch die umgebung fliegen und dabei häuserfassaden "wirklich" demoliert werden
willst du wirklich 200kpolys auf 300k pixel bringen? *Fg*, da hilft dir dann kein filtering der welt, ohne AA gibt es nur noch krisseln *G*.. man würde aber natürlich auf texturen verzichten können *haha*

aber afaik wären 300k tris/frame möglich.

MfG
micki

[Jules]

...........Zum Glück muss ich das Teil nicht programmieren.

wenn ich was drauf hätte würd ich gerne mal was dafür machen
also als guter programmierer würds mich reizen, aber ein termingerechtes spiel für das ding rauszubringen ist wohl die hölle auf erden :D

[aths]

ok
das stimmt auch wieder :D
aber du willst doch keine 200k polys für ne figur verschwenden
die ps2 kann (imo) wirklich einiges
aber nicht sovielNatürlich nicht – mit 200k - 250k sollte man einen kompletten Bildschirm füllen. Aber 10k reichen für ein Modell hoffentlich.

gerade deswegen wundert es mich, dass zeckensack gegen die ps2 technik wettert... Gerade zeckensack sehe ich nicht wettern, im Gegensatz zu einigen anderen. Müsste ich für die PS2 was echtzeitigfähiges programmieren, würde ich garantiert wettern – nicht, weil die Leistung zu niedrig sei (wie Coda in seiner Aufzählung m. E. impliziert) sondern weil es schwierig sein dürfte, die Architektur vernünftig auszulasten. Man müsste den Code parallelisieren und viel Zeit ins Tuning stecken. Das ist ein unüblicher Ansatz. Was Erzeugung 3D-Grafik angeht habe ich sowas wie eine Pipeline im Kopf (nicht verwechseln mit der Pixelpipline der GPU, das ist nur ein Teil der ganzen 3D-Pipeline) doch solche Konzepte sollte man bei der PS2 vergessen.

[zeckensack]

Gerade zeckensack sehe ich nicht wettern, im Gegensatz zu einigen anderen.Danke dass du das richtig gelesen hast.

Ich weiß immer noch nicht wo ich geschrieben haben soll die PS2-Technik sei "scheisse [sic]" (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3752038#post3752038).

Jetzt endgültig EOD meinerseits.

[Coda]

gibt nur multipass, multitexturing ist nicht enthalten in hardware. (realisiert man durch überlappende tris)Ja meinte ich.

gibt einige dinge, im besonderen particle, die ohne texturen auskommen. diese werden in massen direkt in der VU1 generiert und mit vertexcolors versehen.Und sagte ich was anderes?

gibt insgesammt 3 paths zum GS, nicht alle daten kommen also von VU1.Die Vertexdaten kommen alle von VU1.

der vertexcahce ist auf der VU, 16kb. also nicht auf nur 24vertices wie z.b. bei der xbox limitiert, sodass die VU nicht immerwieder, unnötig, dieselbe transformation durchführen muss.Das ist doch kein Vertexbuffer für mehrere Megabyte Vertexdaten. Und das auf der VU ist kein Vertexcache sondern vor allem lokaler Arbeitsspeicher der auch vom Program verwendet werden muss.

Dieser 24 Vertex Post-Transform Cache bei der XBox-GPU ist nur bei indizierten Daten dazu da dass sie nicht nochmal transformiert werden, nicht für komplette Modelle. Bei der XBox ist nochmaliges Transformieren auch viel weniger nötig, weil der Chip sehr gute Multitexturing-Möglichkeiten bietet.

Du redest anscheinend von Sachen von denen du keinen blassen Schimmer hast - bei allem Respekt.


nein, fertig transformierte (und geclippte) geometrie kann in den internen 16kb abgelegt werden, wird bei multipass auch oft so gemacht. z.b. bei den fahrzeugen in GT4.Siehe oben.

nein, afaik kann man das einmal erzeugte format mehrmals in den GS kicken.Natürlich kann man. Siehe oben.

wobei man oft mit 4bit oder 8bit pro pixel hinkommt. man verwendet auch keine 'teuren' normalmaps, sodass 1MB von einem extrem schnellen speicher sehr viel ist, verglichen z.b. mit dem relativ langsamen allroundmem der xbox.1MiB ist zu wenig. Das sieht man an allen PS2-Spielen

jap, währenddessen können die recheneinheiten rechnen, wäre ja blöd wenn sie dazu verdammt wären speicher zu scheffeln. zum vergleich mit anderen konsolen: der einzig performante weg dort an speicher zu kommen, ist zu hoffen, dass der betreffende bereich noch im cache liegt, ansonsten gibt es ein cachemiss der locker 100cycles verschwenden kann.Das ist ja schön - Trotzdem ist es schwerer zu programmieren. Schonmal dran gedacht, dass ich hier vor allem die Programmierung kritisiere?

emm... ja, so ist die welt. auch auf dem pc muss man einen texturebuffer füllen, bevor man die texture benutzen kann, selbst die konsolen mit den "unified" speichern müssen zumindestens quadweise immerwieder texturen in ihren cache nachladen.Nein so ist die Welt nicht. Es gibt beim PC keine asynchronen Transfer wo man Race-Conditions oder ähnlichen Quatsch erzeugen könnte. Alles ist schön sequentiell.

...man kann alles selber machen, was bei anderen systemen nicht gegeben ist. wenn man nicht alles selber machen möchte, kann man ne oGL lib nutzen. die zwar recht performant ist, aber nicht das letzte bisschen aus der ps2 rauskratzt.
auf anderen systemen muss man damit halt leben. bzw. kann man sich auf der xbox die commandos reverse enginieren und so wie in dx3 kleine "executive buffer" zusammenstellen, die dann wie die commandos and den GS in der ps2, in einer hardwarenahen und performanten art und weise ablaufen.Für die Spiele die halbwegs mit der Xbox mithalten müssen reicht sicher nicht die "OGL-Lib".

zum vergleich: bei der ps2 setzt man ein VU1 programm, kann darin geometrie generieren, es gibt von sony sogar ein sample bei dem die ganze geometrie eines kleinen spiels in der VU generiert wird. man muss also nicht für jedes kleine dumme objekt einen renderaufruf machen. dazu hat jeder prozessor seinen optimierten, dedizierten speicher, sodass sich die einheiten nicht ständig um bandbreite 'streiten' müssen.Alles halbwegs richtig, trotzdem geht es hier um die einfache Programmierbarkeit und da ist die PS2 einfach eine Katastrophe.

[Coda]

Danke, sehr aufschlussreich. :rolleyes:

Da sieht man mal wieder wie sehr sich Theorie und Praxis unterscheiden können...Halt du dich doch raus. Immer bloß rumstänkern und denen die vorgeben Ahnung zu haben und deiner Meinung sind gibst du Rückendeckung.

Nochmal zum mitschreiben: Ich halte die PS2 für Schrott weil das Design unnötig komplex zu beherschen ist, nicht wegen den Spielen und auch nicht wegen dem was hinten rauskommt.

Schön: Xbox macht das, was wir (vor allem aus dem PC-Bereich) so kennen. Sony wählte einen anderen Ansatz. Schlecht: Erfahrungen aus dem PC-Bereich sind beinahe wertlos. Gut: Speziell für die PS2 entwickelte Spiele sind unverwechselbar. Die PS2 ist – entgegen der Werbung – nicht als Grafikmonster geschaffen. Na und? Wenn die Spiele so aussehen, wie sie das jetzt tun, kann ich damit leben.Von dir hätte ich gedacht, dass du inzwischen verstanden hast von was ich rede - scheinbar nicht.

[Gent!eman]

Kann dann ne Geforce2 auch Normal Mapping? Und NM ist doch BM, aber in Neo wohl gefaket

[Coda]

Kann dann ne Geforce2 auch Normal MappingJa kann sie. Auch eine GeForce 256.

[Jesus]

Halt du dich doch raus. Immer bloß rumstänkern und die die Vorgeben Ahnung zu haben und deiner Meinung sind gibst du Rückendeckung.

Nochmal zum mitschreiben: Ich halte die PS2 für Schrott weil das Design unnötig komplex zu beherschen ist, nicht wegen den Spielen und auch nicht wegen dem was hinten rauskommt.

Von dir hätte ich gedacht, dass du inzwischen verstanden hast von was ich rede - scheinbar nicht.

OK, du hälst es für Schrott. Aus rein theoretischen Gründen, ohne jemals dafür programmiert zu haben, oder alle Details zu kennen. Ich masse mir sowas nicht an, obwohl ich auch nicht ganz blöd bin, aber das akzeptiere ich :rolleyes:

[Coda]

Ich kenne genug Details und Entwicklerkommentare um mir sehr gut eine Meinung darüber bilden zu können, dass die Xbox eklatant einfacher zu programmieren ist. Die PS2 ist nach gängiger Meinung das absolut schlimmste was es im Konsolenmarkt jemals gab in diesem Zusammenhang.

Ihr könntet euch ja selber mal ein wenig Schlau machen im Internet zu dem Thema anstatt euren Geist gegen sämtliche Sachen die nicht in euer Weltbild passen zu verschließen.

[Jesus]

Ich kenne genug Details und Entwicklerkommentare um mir sehr gut eine Meinung darüber bilden zu können, dass die Xbox eklatant einfacher zu programmieren ist.

Das bestreitet auch niemand (das mit dem einfacher zu programmieren...)

[Coda]

Aua. Und von was rede ich schon den ganzen Thread?

Ich sage nur dass die PS3 nicht einfach zu programmieren ist - fertig aus. Könntet ihr mal bitte eure religiöse "meine Konsole ist die beste"-Überzeugung hier rauslassen. Mir ist das sowas von egal.Nochmal zum mitschreiben: Ich halte die PS2 für Schrott weil das Design unnötig komplex zu beherschen ist, nicht wegen den Spielen und auch nicht wegen dem was hinten rauskommt.Kapisch?

Ach ja: Das sie zu wenig Texturspeicher hat, das kannst du mir auch noch anrechnen. Dazu steh ich aber auch. An Sonys stelle hätte ich einfach den GS noch an den RAM mit angeschlossen um von dort direkt Texturen samplen zu können. Evtl. auch 8-16MiB externer Texture/Vertexspeicher. Dann wäre das Konzept wirklich recht gut gewesen.

[RoKo]

Ich möchte mal kurz darauf hinweisen, dass es komplett sinnfrei ist, darüber zu diskutieren, ob man etwas letztlich als Schrott bezeichnen kann oder nicht. Überhaupt provoziert man von vornherein sinnlose Streitereien, wenn man eine Diskussion damit beginnt, etwas als Schrott zu bezeichnen.

@Coda: In Deinem einen Zitat ging es um die PS3 und das andere war erst brandneu.

[Coda]

@Coda: In Deinem einen Zitat ging es um die PS3 und das andere war erst brandneu.Im zweiten nicht. Aber ob PS2 oder PS3 ist auch egal was das angeht. Wobei die PS3 da schon wesentlich besser ist.

Überhaupt provoziert man von vornherein sinnlose Streitereien, wenn man eine Diskussion damit beginnt, etwas als Schrott zu bezeichnen.Wahrscheinlich. Aber manche muss man mal wachrütteln.

[Jesus]

Ich möchte mal kurz darauf hinweisen, dass es komplett sinnfrei ist, darüber zu diskutieren, ob man etwas letztlich als Schrott bezeichnen kann oder nicht. Überhaupt provoziert man von vornherein sinnlose Streitereien, wenn man eine Diskussion damit beginnt, etwas als Schrott zu bezeichnen.

@Coda: In Deinem einen Zitat ging es um die PS3 und das andere war erst brandneu.

ACK, aber was CODA hier macht ist die Gleichsetzung von "schwerer" (oder besser gesagt ungewohnt, not PC like) Programmierung mit Schrott. Nur weil etwas nicht so ist wie man es gerne hätte ist es nicht gleich Schrott!

[Coda]

Das Konzept ist Schrott (ja, davon handelt der Thread, auch wenn die Hälfte die mir negativ antwortet auf etwas völlig anderes eingeht). Die Konsole an sich und was man damit machen kann vielleicht nicht (ich hab das Ding nicht und kenne auch die Spiele nicht).

Sony hätte mit etwas mehr Verstand weit mehr aus dem Transistoraufwand rausholen können.

Ich würde auch nicht anders reden wenn ich das Ding im Zimmer stehen hätte und damit tolle Spiele spielen würde. Ich muss das Zeug ja zum Glück nicht programmieren.

[zeckensack]

OK, du hälst es für Schrott. Aus rein theoretischen Gründen, ohne jemals dafür programmiert zu haben, oder alle Details zu kennen.Jetzt nochmal ganz von vorn, und stellvertretend für den ganzen Rest.


Hat dir schonmal ein Film gefallen? Oder misfallen? Also hast du schonmal eine Meinung zur Qualität eines Films gehabt? Und hast du schonmal einen Film gedreht, finanziert, oder ein Drehbuch geschrieben?

===============

Hattest du schonmal eine Meinung zu Musik? Und hast du jemals selbst ein Musikstück geschrieben, gespielt, aufgenommen oder abgemischt?

===============

Hattest du schonmal eine Meinung zu einem Auto? Und hast du jemals ein Auto konstruiert?

===============

Hattest du schonmal eine Meinung zu einem Grafikkartentreiber? Und hast du jemals einen (Teil eines) Grafikkartentreibers geschrieben?

===============

Hattest du schonmal eine Meinung zu Windows? Und hast du jemals ein OS programmiert?

===============

Hattest du schonmal eine Meinung zur Qualität von Essen? Und hast du jemals einen Acker bewirtschaftet oder ein Tier geschlachtet?

===============

Hattest du schonmal eine Meinung zum Aussehen eines Gartens oder einer Parkanlage? Und hast du jemals Rasen, Blumen, Büsche und Bäume gepflanzt und geplegt?

===============

Antworten und selbst drauf kommen: deine Argumentation ist für den Arsch.

[aths]

1MiB ist zu wenig. Das sieht man an allen PS2-SpielenBei "Battlestar Galactica" sehe ich das nicht.

Das ist ja schön - Trotzdem ist es schwerer zu programmieren. Schonmal dran gedacht, dass ich hier vor allem die Programmierung kritisiere?Dann halte ich deinen Ausdruck in den älteren Posts für ziemlich schwammig.

Von dir hätte ich gedacht, dass du inzwischen verstanden hast von was ich rede - scheinbar nicht.Ich habe bislang nur verstanden, dass zeckensack weiß, wovon er redet.

Angesichts des Links von micki halte ich die PS2 für einen programmiertechnischen Albtraum. Wer hat Design erstellt hat, war entweder auf Speed oder hatte ernste familiäre Probleme. Oder er war so genial (oder so doof), dass er die Fähigkeiten des durchschnittlichen Programmierers weit überschätzte. Trotzdem würde ich nicht sagen "Das Konzept ist Schrott". Die PS2-Architektur ist schwer auszunutzen, aber hat ihre Stärken. Gerade im Konsolenbereich sind solche Insellösungen noch am ehesten vertretbar.

Eine Hardware, die mehr als 5 Jahre lang hält, darf auch unüblich aufgebaut sein. Gerade Konsolen, die als dediziertes Spielgerät herhalten sollen und nicht nur konvertierte PC-Spiele in niedriger PAL-Auflösung rendern dürfen mit ihrer Architektur überraschen – das Design der PS2 erscheint mir ziemlich flexibel. Feintuning ist nötig, aber genau das ist auf Konsolen auch machbar. Bei Gran Turismo poppen z. B. bestimmte Dinge offenbar nicht entfernungsabhängig auf, sondern dann, wenn der Test während der Entwicklung ergab, dass trotz des Renderns des Objektes noch volle Framerate gewährleistet ist. Wer sein Spiel auf alle möglichen Systeme portieren möchte, wird angesichts der PS2 stöhnen. Wer gleich für die PS2 entwickelt, muss sich zunächst mal richtig Gedanken machen, er kann nicht gleich Code einhacken.

Auf der PC-Schiene lehne ich proprietäre Spielereien ab, im Konsolenbereich zählt für mich nur was hinten rauskommt. Auf die PS2 ist schwer zu optimieren – na und? Nicht "na und" ist hingegen Sonys Devkit-Politik.

[Coda]

Angesichts des Links von micki halte ich die PS2 für einen programmiertechnischen Albtraum. Wer hat Design erstellt hat, war entweder auf Speed oder hatte ernste familiäre Probleme. Oder er war so genial (oder so doof), dass er die Fähigkeiten des durchschnittlichen Programmierers weit überschätzte. Trotzdem würde ich nicht sagen "Das Konzept ist Schrott".Irgendwie halte ich das Ganze für ein Oxymoron. Ist aber wohl Ansichtssache ;)

[aths]

Das Konzept ist Schrott (ja, davon handelt der Thread, auch wenn die Hälfte die mir negativ antwortet auf etwas völlig anderes eingeht). Die Konsole an sich und was man damit machen kann vielleicht nicht (ich hab das Ding nicht und kenne auch die Spiele nicht).Das ist glaube ich das, was die anderen sehen (du hast das Teil nicht) und dir vorwerfen: Gleich starke, und subjektive Bewertungen wie "Schrott" als Wahrheit hinstellen.

Ich würde auch nicht anders reden wenn ich das Ding im Zimmer stehen hätte und damit tolle Spiele spielen würde. Ich muss das Zeug ja zum Glück nicht programmieren.Ob du anders reden würdest, kannst du nicht wissen, nur vermuten.

Sony hätte mit etwas mehr Verstand weit mehr aus dem Transistoraufwand rausholen können.Ja klar, 8x Multitexturing, MIP-Mapping und ein paar MB mehr Video-RAM, und man hätte trotz der weiterhin komplexen Programmierung Killer-Hardware. Seien wir froh, dass Marktführer Sony keine Killer-Hardware gebaut hat und somit noch etwas Auswahl am Markt besteht. Nachteil: Bei Vielfalt am Markt braucht man mindestens zwei Konsolen, um eine gewisse Bandbreite an optimierten Spielen abzudecken. Vorteil: Es gibt weiterhin einen Kampf der Konzepte. Da ist es doch aus Prinzip gut, wenn nicht jeder à la Microsoft kleine Standard-PCs baut, sondern neue, unübliche Lösungen ausprobiert.

[Coda]

Das ist glaube ich das, was die anderen sehen (du hast das Teil nicht) und dir vorwerfen: Gleich starke, und subjektive Bewertungen wie "Schrott" als Wahrheit hinstellen.Ich habe glaube ich immer zumindest gesagt, dass ich nicht die Konsole für Schrott halte sondern eben das Konzept. Das geht auch so aus dem ersten Post hervor. Aber egal jetzt.

Das mag ja subjektiv sein, ist aber auch eine recht gängige Meinung in manchen Berufsgruppen :D

Ja klar, 8x Multitexturing, MIP-Mapping und ein paar MB mehr Video-RAM, und man hätte trotz der weiterhin komplexen Programmierung Killer-Hardware.Das Multitexturing wäre relativ egal, weil das Ding genügend Füllrate hat. Es mangelt nur extrem an VRAM. Etwas externer Speicher für den GS hätte dem Ding wirklich gut getan.

Seien wir froh, dass Marktführer Sony keine Killer-Hardware gebaut hat und somit noch etwas Auswahl am Markt besteht.Hm, das verstehe ich nicht. Du meinst dann hätte es nur noch Cross-Platform-Spiele gegeben? Womöglich hast du recht.

[aths]

Irgendwie halte ich das Ganze für ein Oxymoron. Ist aber wohl Ansichtssache ;)Meine Einstellung zu Konsolen-HW ist eine ganz andere als zu PC-Hardware. Im PC-Bereich ist die Entwicklung fließend, so verlange ich Features auch schon dann, wenn deren Umsetzung freundlich gesagt bezüglich der Performance noch Spielraum nach oben zulässt. Außerdem möchte ich weitgehende Einheitlichkeit sowohl im Feature-Set als auch in der Performance der Features.

Bei Konsolen kann man sich mal den Atari 2600 ansehen. Das Ding berechnet jede Bildschirmzeile neu. Die nächste Zeile muss fertigberechnet werden, während die aktuelle ausgegeben wird. An ROM hast du 4 kiB, an RAM hast du 128 Byte – und da muss auch noch der Stack rein. Nachteil: Fürchterliche Programmierung. Vorteil: Da statische Objekte nicht billiger sind als animierte (jedes Bild muss ohnehin neu berechnet werden) kann man sie gleich animieren. Bei den 2600-er Spielen ist oft viel los. Der Atari 2600 ist wohl die langlebigste Konsole aller Zeiten. Die Hardware ist ein Zugeständnis an damalige Möglichkeiten – wen stört das, wenn der Programmier fähig ist?

So auch bei der PS2: Es ist mal was anderes. Mit besonderen Stärken und Schwächen. Was stört mich 1 MiB Texturspeicher, wenn ich Gran Turismo spiele? Man kann sich gerne darüber echauffieren, was Sony alles hätte besser machen können. Dann bitte mit Formulierungen wie "Die PS2-Hardware halte ich für Schrott" und nicht "Das Konzept ist Schrott".

[aths]

Ich habe glaube ich immer zumindest gesagt, dass ich nicht die Konsole für Schrott halte sondern eben das Konzept. Das geht auch so aus dem ersten Post hervor. Aber egal jetzt.

Das mag ja subjektiv sein, ist aber auch eine recht gängige Meinung in manchen Berufsgruppen :D

Das Multitexturing wäre relativ egal, weil das Ding genügend Füllrate hat. Es mangelt nur extrem an VRAM. Etwas externer Speicher für den GS hätte dem Ding wirklich gut getan.Multitexturing ist in jedem Fall günstig. Wenn man mit Texturen arbeiten will, sollte man imo 8x MT bieten – die GF3 z. B. hatte nur 4x MT. Zu wenig, imo, da zu unflexibel. (Da braucht mir keiner mit dem Performance-Argument kommen. Wenn die Skybox nur Singletexturing und das meiste nur Dualtexturing bekommt, wäre genug Füllrate da, um bestimmte einzelne Objekte mit 5 und mehr Texturen zu belegen. Von der GF4 Ti will ich gar nicht erst reden – hier limitiert das Featureset die Leistung. Per se schlecht.)

Zum Schrott: Wieso "egal jetzt"? "Ist Playstation2-Technologie schlecht?" – die Frage kann man erörtern, in dem man zunächst Kriterien aufstellt, nach denen man beurteilen möchte. Ich nehme an nicht der einzige zu sein, der bei dir und anderen das Gefühl hat dass erst die Antwort kommt 'Ja! Schlecht! Schrott!' und dann erst Kriterien gesucht wurden.

Was den Einstieg in die Programmierung angeht ist die PS2 schlecht geeignet. Was die Anforderung einer üblichen 3D-Engine an die Hardeware angeht ist die PS2 ebenfalls schlecht geeignet. Prinzipiell ist die PS2 für die Darstellung flimmerfreier texturierter, oder detailliert texturierter Szenen schlecht geeignet. So weit gehe ich mit. Das Konzept per se für schlecht zu halten geht mir zu weit – wir haben hier eine Konsole. Auch Konsolen könnten so vergurkt sein, dass man sie einfach nur als "schlecht" bezeichnen müsste – wie prüft man das? Imo bleibt als einzig stichhaltiges Argument ein Vergleich der Spiele untereinander. Da zeigt sich dass die PS2-Grafikeinheit die schwächste in ihrer Konsolengeneration ist. Aber die Unterschiede sind nun auch nicht gleich Welten.

Hm, das verstehe ich nicht. Du meinst dann hätte es nur noch Cross-Platform-Spiele gegeben? Womöglich hast du recht.Dann würde es (in relevanten Stückzahlen) womöglich nur noch die Playstation-Serie geben.

[StefanV]

OK, du hälst es für Schrott. Aus rein theoretischen Gründen, ohne jemals dafür programmiert zu haben, oder alle Details zu kennen. Ich masse mir sowas nicht an, obwohl ich auch nicht ganz blöd bin, aber das akzeptiere ich :rolleyes:
Nein, die PS2 ist scheiße, eben weils unnötig kompliziert ist, das Teil zu beherrschen.

Die X-Box ist nur ein umgebastelter PC, das sollte jeder hinbekommen, das Teil einigermaßen zu proggen.

Und der GC ist einfach eine Konsole, die im Aufbau äußerst simpel und klar strukturiert ist.

Bei der Playstation 2 schauts ganz anders aus, denn da weiß niemand so genau, was SoNie letztendlich wollte und eben genau deswegen ist sie so scheiße, weil da kein klares Konzept hintersteckt sondern mehrere halbe.

[StefanV]

Angesichts des Links von micki halte ich die PS2 für einen programmiertechnischen Albtraum. Wer hat Design erstellt hat, war entweder auf Speed oder hatte ernste familiäre Probleme. Oder er war so genial (oder so doof), dass er die Fähigkeiten des durchschnittlichen Programmierers weit überschätzte. Trotzdem würde ich nicht sagen "Das Konzept ist Schrott". Die PS2-Architektur ist schwer auszunutzen, aber hat ihre Stärken. Gerade im Konsolenbereich sind solche Insellösungen noch am ehesten vertretbar.
Oder aber er hatte kein klares Ziel vor Augen, hat aber ein paar Geniale Ideen gehabt, aber irgendwie nicht in der Lage war, diese Ansätze zu vervollständigen und zu vollenden.

Wenn man ganz fies ist, würd man jetzt behaupten, das der Chefentwickler in der Mitte des Projektes das Handtuch geworfen hat und sich verpieselte :)

[Coda]

Och bitte, können wir den Thread jetzt ruhen lassen. Es war eine Art Waffenstillstand in Sicht X-D

[Lost Boy]

doch, es ist möglich, aber es macht bisher kein spiel, weil es zu aufwendig ist (das schlimme ist wohl der textureverbrauch).


Habe einige Bump Mapping Tech-Demos für den Dreamcast gesehen, in Spielen allerdings nicht.

Auf der PS2 habe ich in der richtung bisher nix gehört oder gesehen.
Bin vorhin mal auf das hier gestoßen:

Ghost Hunter

http://surgemag.com/images/Fall2004/Reviews/Ghost%20Hunter/large/Octattack.jpg

EDIT: Bump Mapping aufm DC

http://www.pvrdev.com/pub/PC/doc/f/Bump%20Mapping%20Comparison_files/image024.jpg

http://home.swipnet.se/~w-33411/dreamcastbumpmapping300poly166stat60fps.jpg

[Jesus]

Antworten und selbst drauf kommen: deine Argumentation ist für den Arsch.

Sorry, aber deine Vergleiche sind für den Arsch ;)

Ich kann mir auch keine Meinung über Musik bilden die ich nie gehört habe. Nur weil mir die Richtung nicht gefällt muss die Musik nicht schlecht sein...

[aths]

Nein, die PS2 ist scheiße, eben weils unnötig kompliziert ist, das Teil zu beherrschen.Nein, dein Ausdruck ist scheiße, weil du eine subjektive Wertung auf ein einzelnes Kriterium, welches für die meisten irrelevant ist, als Tatsache hinstellst.

Bei der Playstation 2 schauts ganz anders aus, denn da weiß niemand so genau, was SoNie letztendlich wollte und eben genau deswegen ist sie so scheiße, weil da kein klares Konzept hintersteckt sondern mehrere halbe.Wenn du Herstellernamen richtig schreiben kannst, hört dir vielleicht auch mal jemand zu.

[Gast]

Habe einige Bump Mapping Tech-Demos für den Dreamcast gesehen, in Spielen allerdings nicht.

Auf der PS2 habe ich in der richtung bisher nix gehört oder gesehen.
Bin vorhin mal auf das hier gestoßen:

Ghost Hunter

http://surgemag.com/images/Fall2004/Reviews/Ghost%20Hunter/large/Octattack.jpg

EDIT: Bump Mapping aufm DC

http://www.pvrdev.com/pub/PC/doc/f/Bump%20Mapping%20Comparison_files/image024.jpg

http://home.swipnet.se/~w-33411/dreamcastbumpmapping300poly166stat60fps.jpg


gegen gutes bump mapping stinkt meines Erachtens doch jedes shader-feature ab

[Coda]

gegen gutes bump mapping stinkt meines Erachtens doch jedes shader-feature abUnd gegen die Undifferenziertheit dieser Aussage stinkt auch so einiges ab X-D

[aths]

gegen gutes bump mapping stinkt meines Erachtens doch jedes shader-feature abSchon mit primitiven DX8 Pixelshader 1.1-Shaderfeatures kann man besseres Bumpmapping zaubern als diese PowerVR-Demo zeigt.

[Gast]

Es ist mir eigentlich auch völlig egal was du glaubst, der Thread ist tot. Sobald es um "ihre" Konsolen geht und das diese eventuell sogar Schwächen haben könnten werden manche zu gehirntoten Zombies.
Sorry, aber schwachsinnig ist kein Synonym für schwach. Von wegen Gehirntot...

[Gast]

Ach ja: Das sie zu wenig Texturspeicher hat, das kannst du mir auch noch anrechnen. Dazu steh ich aber auch. An Sonys stelle hätte ich einfach den GS noch an den RAM mit angeschlossen um von dort direkt Texturen samplen zu können. Evtl. auch 8-16MiB externer Texture/Vertexspeicher. Dann wäre das Konzept wirklich recht gut gewesen.
Hast ja auch recht. Leider lies die Kalkulation so einiges nicht zu. Meinten die Kaufmänner jedenfalls. Ohne Frage hätte man die PS2 WESENTLICH besser machen können. Man hat revolutionäre (imho) Vorkonzepte aber nicht bis zur ihrer endgültigen Reife entwickeln können. Und wenn, dann nur noch auf dem Papier. Bleibt halt zu hoffen, daß sie aus den Fehlern lernten und die PS3 nur schwierig und nicht sehr kompliziert zu programmierien ist.

"Kleine PCs" als Konsolen will ich jedenfalls nicht haben. Bravo aths. Ich hab ehrlich gesagt auch absolut keinen Spaß an Portierungen. Die sind irgendwie per se mistig. PC->Konsole ebenso wie Konsole->PC. Deswegen bin ich für die leichte Kompliziertheit, damit nicht jeder Depp "per Script" konvertiert :( Die Konsolenheinis ärgern sich dann nämlich genauso wie die PC-Heinis!

[mboeller]

gibt insgesammt 3 paths zum GS, nicht alle daten kommen also von VU1.


Wie kommst du immer auf die 3 paths?

Zwischen EE und GS gibt es nur einen Bus, und der erreicht 1200MB/sec. Was im EE so passiert interessiert mich hierbei eigentlich mal nicht. Siehe auch hier: http://www.technology.scee.net/files/presentations/agdc2002/PS2forPCprogrammers.pdf

[mboeller]

An Sonys stelle hätte ich einfach den GS noch an den RAM mit angeschlossen um von dort direkt Texturen samplen zu können. Evtl. auch 8-16MiB externer Texture/Vertexspeicher. Dann wäre das Konzept wirklich recht gut gewesen.

Sehe ich ähnlich. Sowas hätte IMHO schon gereicht:



EE <--> NB <--> GS
| |
| |

32MB RDRAM ( 2x16bit)


oder noch besser


EE <--> NB <--> GS
| | |
| | |

48MB RDRAM ( 3x16bit)




Und noch ein paar schöne Links die zeigen das die Entwickler mit der Konsole massive Probleme hatten:

http://www.technology.scee.net/files/presentations/agdc2002/PerformanceAnalyser.pdf

und

http://www.technology.scee.net/files/presentations/PSP/HowFarHaveWeGot.pdf

Man beachte die MPixel / Frame und die Auslastung des VU0. Die Dokumente sind von Sony aus den Jahren 2002 und 2003!

[mboeller]

Schon mit primitiven DX8 Pixelshader 1.1-Shaderfeatures kann man besseres Bumpmapping zaubern als diese PowerVR-Demo zeigt.


Der PVR2DC konnte auch kein Dot3 sondern nur eine einfachere Variante von BumpMapping. Ich glaube sowas wie 1/N, bin mir aber nicht sicher welches BumpMapping der Chip benutzte.

Was mich bei der PS2 immer wieder gewundert hat ist, das die Entwickler nicht einmal diese Variante von BumpMapping benutzt haben:

http://vcg.isti.cnr.it/activities/geometryegraphics/bumpmapping.html

CLUT kann der GS ja und der EE hat jede Menge Prozessorleistung (für damalige Verhältnisse). Das ganze hätte also funtionieren sollen.

Oder liege ich hier komplett falsch?

[Spasstiger]

gegen gutes bump mapping stinkt meines Erachtens doch jedes shader-feature ab

Und was sieht daran jetzt so toll aus? Da hab ich schon wesentlich besseres in Echtzeit gesehen.

[Gast]

Klar. Deshalb hat UT2003 auch deutlich bessere Texturen als jegliche Konsolen-Portierungen von heute.

Da hat mal zur Abwechslung der Texturspeicher auf PCs sogar limitiert.
Da beißt du dir aber selbst in den Schwanz - katzenmäßig. Wieso hat UT2003 dann bessere Texturen, wenn bei Doom3 der Texturspeicher nicht gereicht haben soll? Liefert Epic bei UT2003 eine Texturspeichererweiterung mit?

[Spasstiger]

Da beißt du dir aber selbst in den Schwanz - katzenmäßig. Wieso hat UT2003 dann bessere Texturen, wenn bei Doom3 der Texturspeicher nicht gereicht haben soll? Liefert Epic bei UT2003 eine Texturspeichererweiterung mit?

Bei Doom 3 liegen die Texturen in doppelter Ausgabe vor, einmal die 32 Bit TGA für die Diffusemap, dann 24 Bit für die Normal- und Heightmap und dann nochmal 8 Bit für die Specularmap. Hinzu kommt, dass Texturkompression bei Normal-Maps ganz üble Folgen haben kann.

[Coda]

Dreifach manchmal. Diffuse, Gloss & Normalmap. Dazu kommen "Shader" die noch mehr Texturen verwenden.

Man beachte die MPixel / Frame und die Auslastung des VU0. Die Dokumente sind von Sony aus den Jahren 2002 und 2003!Es ist noch viel kranker als ich gedacht hab X-D

[micki]

Und sagte ich was anderes?
das war lediglich die antwort auf deine frage.


Die Vertexdaten kommen alle von VU1.
es gibt 3paths für über die man vertexdaten schicken kann. gerade erste gehversuche auf der ps2 snd meisten ohne VU1, nur mit direkten zusammenstellen der GS commandos mittels cpu. dinge wie GUI/HUD werden ohne VU1 gemacht,das wäre total overpower. man legt sich dafür meistens einen commandobuffer zusammen, im normalen ram und kickt das mit der cpu am ende des frames rüber.


Das ist doch kein Vertexbuffer für mehrere Megabyte Vertexdaten. Und das auf der VU ist kein Vertexcache sondern vor allem lokaler Arbeitsspeicher der auch vom Program verwendet werden muss.

nein, das ist leider ebenfalls falsch, für code gibt es seperate 16kb, es ist für code weder möglich in den "codesegment" zu schreiben, noch möglich aus dem "datensegment" ausgeführt zu werden.


Dieser 24 Vertex Post-Transform Cache bei der XBox-GPU ist nur bei indizierten Daten dazu da dass sie nicht nochmal transformiert werden, nicht für komplette Modelle. Bei der XBox ist nochmaliges Transformieren auch viel weniger nötig, weil der Chip sehr gute Multitexturing-Möglichkeiten bietet.

wie gesagt, bei der ps2 ist es ebenfalls nicht nötig, da die transformierten daten in VU1 abgelegt werden können und immerwieder zum GS gekickt werden.


Du redest anscheinend von Sachen von denen du keinen blassen Schimmer hast - bei allem Respekt.
das behauptet der, bei dem fast jede einzelne der 10 anprangerungen der ps2 falsch sind, suess!



1MiB ist zu wenig. Das sieht man an allen PS2-Spielen
die meisten spiele nutzen einen großteil ihres normalen speichers um dort die texturen zu halten. ich wüste garnicht wie ich in einem spiel erkennen sollte welche 5% der texturen die sind, die permanent im speicher gehalten werden, und welche die 95% sind die pro frame neu aus dem hauptspeicher nachgeladen werden.


Das ist ja schön - Trotzdem ist es schwerer zu programmieren. Schonmal dran gedacht, dass ich hier vor allem die Programmierung kritisiere?
schonmal dran gedacht, dass "ich komme gerade von der uni und kann c#"-n00bs garnicht erst an die programmierung ps2 drankommen? die die dafür sorgen müssen, dass es perfekt läuft, sind leute mit oft 20jahren erfahrung mit konsolen, keine kinder. diese leute kommen mit dem der konsole locker klar.
die die man in den medien immer heulen hört sind leute die aufmerksamkeit brauchen. wenn du mal das glück hast mit nem engine-guy einer größeren japanischen firma zu sprechen, dann wirst du sie dahinschwärmen hören wie genial es ist die ps2 zu programmieren, welche winkelzüge sie nutzen, dass sie z.B. auf einen "sync" von DMA-textureupload und VU1 verzichten und stattdessen mit hardgecodeten ausgerechneten werten davon ausgehen, dass es synchron läuft....


Nein so ist die Welt nicht. Es gibt beim PC keine asynchronen Transfer wo man Race-Conditions oder ähnlichen Quatsch erzeugen könnte. Alles ist schön sequentiell. in deinen träumen vielleicht, in der realität hast du Race-Conditions. dafür sind sogar linux-kernels des öfteren mal anfällig gewesen, sodass man vom user in den kernelmode kam.
und in spielen nutzen sowas manche kiddies um im multiplayer server abkacken zu lassen.


Für die Spiele die halbwegs mit der Xbox mithalten müssen reicht sicher nicht die "OGL-Lib".
für spiele die die ps2 voll ausreizen reicht auch nicht das api der xbox wie du vielleicht aus meinem link oben entnehmen konntest.


Alles halbwegs richtig, trotzdem geht es hier um die einfache Programmierbarkeit und da ist die PS2 einfach eine Katastrophe.
einfache programmierbarkeit ist vorhanden. aber damit bekommst du halt nur 80% der leistung und 50% der möglichkeiten der ps2. und zumindest was die leistung betrifft, hast du das selbe dilema auf allen konsolen. um die restlichen 20% zu erhalten die in einer hardware möglich sind, mußt du tief in den morast steigen.
das muss man beim cube machen, bei der ps2 und auch bei der xbox.

für den fall dass du zufaul sein solltest den link oben zu nutzen, gerne nochmal

Pushbuffers. Pushbuffers are the native rendering format of the Xbox GPU. When DirectX is used on the Xbox, the rendering instructions are converted into pushbuffers for execution on the GPU. A small subset of commands within the main render loop: draw primitive, z-writes, set vertexbuffer, select vertexshader, set pixelshader, etc, were reverse engineered to determine the resulting pushbuffer code. This was then used to develop an offline converter application that constructs a large pushbuffer for the whole level.
ist also genau das, was dir die oGL implementierung auf der ps2 bietet. und auf der ps2 und xbox machst du dir so die cpu zum bottleneck.

MfG
micki

[Gast]

Und was sieht daran jetzt so toll aus? Da hab ich schon wesentlich besseres in Echtzeit gesehen.

meine einfach das bm einer der effekte ist, die mich am meisten beindruckt haben so beim giants kabuto und das nur mit dot3. neuere effekte flashen mich nicht so, bloom nervt, höchstens noch die regentropfen bei nfs-mw.

gibts die bei der ps2/gc auch?

[Coda]

schonmal dran gedacht, dass "ich komme gerade von der uni und kann c#"-n00bs garnicht erst an die programmierung ps2 drankommen? die die dafür sorgen müssen, dass es perfekt läuft, sind leute mit oft 20jahren erfahrung mit konsolen, keine kinder. diese leute kommen mit dem der konsole locker klar.Schau dir mal das Paper von mboeller an. Die VU0 wird im Durchschnitt zu 1-2% ausgelastet.

Außerdem hat schwere Programmierbarkeit nicht unbedingt was mit Beherschbarkeit zu tun sondern primär damit dass es ewig dauert.

in deinen träumen vielleicht, in der realität hast du Race-Conditions. dafür sind sogar linux-kernels des öfteren mal anfällig gewesen, sodass man vom user in den kernelmode kam.
und in spielen nutzen sowas manche kiddies um im multiplayer server abkacken zu lassen.Woa. Ich rede von der 3D-API. Schon klar, dass es bei Multithreading auf Multi-CPU Systemen zu Race-Conditions kommen kann, das ist aber ein ganz anderes Thema.

das behauptet der, bei dem fast jede einzelne der 10 anprangerungen der ps2 falsch sind, suess!Also alle 10 sind mal garantiert nicht falsch und an allen ist zumindest was wahres dran.

[micki]

===============

Hattest du schonmal eine Meinung zu Musik? Und hast du jemals selbst ein Musikstück geschrieben, gespielt, aufgenommen oder abgemischt?

===============

Hattest du schonmal eine Meinung zu einem Auto? Und hast du jemals ein Auto konstruiert?

===============

Hattest du schonmal eine Meinung zu einem Grafikkartentreiber? Und hast du jemals einen (Teil eines) Grafikkartentreibers geschrieben?

===============

Hattest du schonmal eine Meinung zu Windows? Und hast du jemals ein OS programmiert?

===============

Hattest du schonmal eine Meinung zur Qualität von Essen? Und hast du jemals einen Acker bewirtschaftet oder ein Tier geschlachtet?

===============

Hattest du schonmal eine Meinung zum Aussehen eines Gartens oder einer Parkanlage? Und hast du jemals Rasen, Blumen, Büsche und Bäume gepflanzt und geplegt?

===============

natürlich darf jeder eine meinung haben ohne wirklich plan davon zu haben, ich glaube kaum dass ein redaktur aus der bildzeitung ahnung hat von der sache die er schreibt, er muss lediglich ahnung haben wie er schreiben muss. aber die kompetenz dieser aussagen sind dann auf entsprechendem niveau "der harry potter film war total klasse" "der harry potter film war total mies"
ja und?

ps2-tech ist lecht
ps2-tech ist super
ja und?
"ja ich kenn leute die gesagt haben, dass sie schlecht ist"
"ja ich kenn leute die gesagt haben, dass sie super ist"
emm.. jaa..

wenn das die grundlage für das hier ist, hätte ich den thread eher in der spielwiese aufgemacht. denn dann ist es nur meinungsbashen und wiederkauen von den meinungen von anderen. wir können ja jeder mal 10 zitate von leuten die die ps2 gecodet haben zusammenquoten, 10für "ich komm nicht damit klar, total schwer und so" und 10für "ich hab aufs onanieren verzichtet, weil ps2 so geil, weil zeit sparen = mehr coden, weil.. ich muss weg ps2 coden".


aber der sinn diese threads entzieht sich mir ein wenig. was hällst du denn von den leuten die nie gecodet haben, aber aufgrund der ganzen paper eine entscheidung fällen konnten das 3dnow/sse schlechter ist. ?

MfG
micki

[micki]

Schau dir mal das Paper von mboeller an. Die VU0 wird im Durchschnitt zu 1-2% ausgelastet.
ich glaube in meinen papern war die zahl in der nähe von 10%


Außerdem hat schwere Programmierbarkeit nicht unbedingt was mit Beherschbarkeit zu tun sondern primär damit dass es ewig dauert.
ja, aber die qualität der toolbase und die anforderungen an die programmierer hat nicht direkt etwas damit zu tun ob die technologie der hardware gut/schlecht ist. wenn das die grundlage wäre, wäre der gamecube der xbox voraus.


Woa. Ich rede von der 3D-API. Schon klar, dass es bei Multithreading auf Multi-CPU Systemen zu Race-Conditions kommen kann, das ist aber ein ganz anderes Thema.
passiert auch unter singleprozessor systemen. ganz einfach dann, wenn es nen task-/threadswitch gibt und eine "wichtige" operation nicht richtig abgesichtert ist. das passiert sehr sehr selten unter windows, in relation zur ps2. aber wenn es mal passiert, dann würde ich lieber 10ps2 engines coden, statt diesen bug unter win reproduzieren und nachvollziehen zu wollen!


an allen ist zumindest was wahres dran.
schön das du es auch so siehst und schade dass der überwiegende teil deiner aufzählung nicht wirklich den tatsachen entsprich.

aber ich stimm dir in deiner oberen aussage auch gerne zu, die ps2 stellt unter den konsolen die höchsten ansprüche an den programmierer. die toolbase ist im vergleich zum gc und xbox sehr bescheiden.

aber was die hardware angeht, ist die ps2 nicht schlecht. alle neuen konsolen setzen auf mehrere cpus/theads die die rechenlast unter sich aufteilen. die ps2 war vor 5jahren auch schon soweit. es gab kein miniOS so wie es auf den next-gen konsolen ist, sodass man alles jedesmal von selbst machen mußte. aber unter std-c++ gibt es auch keinen garbagecollector, was c++ in meinen augen auch nicht ein argument dafür wäre, dass c++ schlecht ist.
damals hätte es sicherlich viele gegeben die die ps2 schlechtreden würden, wenn sie diesen "enormen overhead" aufzwingen würde... "ein betriebssystem auf einer konsole? *harharhar*" und heute ist es harte realität. (natürlich gab es ein BIOS, schon alleine wegen dem kopierschutz;) )

MfG
micki

[aths]

meine einfach das bm einer der effekte ist, die mich am meisten beindruckt haben so beim giants kabuto und das nur mit dot3. neuere effekte flashen mich nicht so, bloom nervt, höchstens noch die regentropfen bei nfs-mw.

gibts die bei der ps2/gc auch?Regentropfen habe ich auf der PS2 in NFS MW und U2, auf dem Cube (wo ich nur NFS U2 habe) leider nicht.

[aths]

Der PVR2DC konnte auch kein Dot3 sondern nur eine einfachere Variante von BumpMapping. Ich glaube sowas wie 1/N, bin mir aber nicht sicher welches BumpMapping der Chip benutzte.

Was mich bei der PS2 immer wieder gewundert hat ist, das die Entwickler nicht einmal diese Variante von BumpMapping benutzt haben:

http://vcg.isti.cnr.it/activities/geometryegraphics/bumpmapping.html

CLUT kann der GS ja und der EE hat jede Menge Prozessorleistung (für damalige Verhältnisse). Das ganze hätte also funtionieren sollen.

Oder liege ich hier komplett falsch?Ich habe die Realisierung, die auf der Website vorgestellt wird, nicht in Gänze verstanden, aber halte es für kaum echtzeitfähig, die Bumpmapping-Shades pro Sekunde oft genug per CPU auszurechnen und in eine Textur rendern zu lassen.

[Simon]

das ist der beweis: nintendo sux
Als ob Regentropfen das ultimative Feature der PS2 gegenüber dem GameCube sind :mad:

Enrico, der leider keinen GC mehr hat...

[Ganon]

Als ob Regentropfen das ultimative Feature der PS2 gegenüber dem GameCube sind :mad:

Scheint sowieso eher der Entwickler verbockt zu haben, denn in vernüftigen Spielen wie Metroid Prime ist sowas drinnen.

[mboeller_nicht_eingelogt]

Ich habe die Realisierung, die auf der Website vorgestellt wird, nicht in Gänze verstanden, aber halte es für kaum echtzeitfähig, die Bumpmapping-Shades pro Sekunde oft genug per CPU auszurechnen und in eine Textur rendern zu lassen.

Das nette an dem ganzen ist ja, das nicht die gesamte Bumpmap geändert wird, sondern nur die CLUT für die Bumpmap. Die ist wesentlich kleiner und der Aufwand dadurch wesentlich geringer. Außerdem schreiben sie im PDF noch das die CLUT nicht für jedes Frame neu berechnet werden muss, sondern nur wenn sich die Position/Blickrichtung "wesentlich" ändert.

Auf der Webseite gibt es unten 2 PDF's; das obere beschreibt diese Art Bumpmapping.

Manfred

[GloomY]

[...] Was die Anforderung einer üblichen 3D-Engine an die Hardeware angeht ist die PS2 ebenfalls schlecht geeignet. Prinzipiell ist die PS2 für die Darstellung flimmerfreier texturierter, oder detailliert texturierter Szenen schlecht geeignet. So weit gehe ich mit.Gut. Und was ist mit den Spielen, die schöne Texturen wollen? Sag' nicht, dass es sowas auf der PS2 nicht geben würde. Dafür denke ich gibt es genügend Beispiele. Das Anwendungsgebiet der PS2 schliesst solche Spiele mit ein. Die anderen Spiele, die durch große Poligonmengen zu schöner Grafik kommen, sind kein Ausgleich dafür, dass die PS2 für einen Teil ihrer Anwendungen technisch betrachtet nicht oder nur schlecht geeignet ist. Und was sagt uns das also über das generelle Design? Wenn ich böse wäre, würde ich sagen: Ziel verfehlt.


Die Folien aus dem Link von mboeller zeigen noch sehr viel stärker auf, dass der Hardwareentwurf nicht ausgewogen ist. Die größte Performancelimitierung kommt (gemittelt über alle getesteten Spiele) von der CPU her, die ständig unter den viel zu kleinen Caches leidet. Anstatt da Transistoren in Unmengen an Vektoreinheiten zu stecken, die sowieso niemand benutzt, wären diese in Form von größeren Caches sicherlich besser aufgehoben gewesen.
Klar kann man beim Hardwareentwurf nicht umbedingt vorhersehen, was die Spielentwickler nun genau nutzen werden. Aber man muss als Hardwareentwickler wenigstens ungefähr abschätzen, wie leistungsfähig die einzelnen Komponenten und wie groß die Anforderungen an diese sind. Das scheint mir hier kaum gelungen zu sein.
Das Konzept per se für schlecht zu halten geht mir zu weit – wir haben hier eine Konsole. Auch Konsolen könnten so vergurkt sein, dass man sie einfach nur als "schlecht" bezeichnen müsste – wie prüft man das? Imo bleibt als einzig stichhaltiges Argument ein Vergleich der Spiele untereinander. Da zeigt sich dass die PS2-Grafikeinheit die schwächste in ihrer Konsolengeneration ist. Aber die Unterschiede sind nun auch nicht gleich Welten.Ich denke, dass die PS2 eine ganz nette Konsole ist, mit der man sehr schön spielen kann. :) Bloß darum geht es nicht. Hier wird rein die Technologie betrachtet, mehr nicht.

[betasilie]

Ich habe glaube ich immer zumindest gesagt, dass ich nicht die Konsole für Schrott halte sondern eben das Konzept. Das geht auch so aus dem ersten Post hervor. Aber egal jetzt.

Das mag ja subjektiv sein, ist aber auch eine recht gängige Meinung in manchen Berufsgruppen :D
Das mag die gängige Meinung viele dieser Berufsgruppe sein und wahrscheinlich derer, die einfach keine Low-Level Cracks sind. Keine Frage, die PS2 richtig intelligent zu nutzen ist schwer, aber es gibt genung Teams, die es drauf haben, das zeigt die Software.

Nur weil viele Devs meckern über die Hardware, heißt das noch lange nicht, dass nicht ausreichend viele Devs es drauf haben mit dem Ding unzugehen und dann bietet die PS2 eine Architektur, die trotz diverse Falschenhälse enorm viel möglich macht. Wenn das nicht so wäre, würde es nicht so exzellente Software geben, die sogar die wesentlich jüngere XBox teilweise alt aussehen lassen, die ja viel stärker sein soll und viel leichter zu programmieren ist.

[betasilie]

Bei "Battlestar Galactica" sehe ich das nicht.

Dann halte ich deinen Ausdruck in den älteren Posts für ziemlich schwammig.

Ich habe bislang nur verstanden, dass zeckensack weiß, wovon er redet.

Angesichts des Links von micki halte ich die PS2 für einen programmiertechnischen Albtraum. Wer hat Design erstellt hat, war entweder auf Speed oder hatte ernste familiäre Probleme. Oder er war so genial (oder so doof), dass er die Fähigkeiten des durchschnittlichen Programmierers weit überschätzte. Trotzdem würde ich nicht sagen "Das Konzept ist Schrott". Die PS2-Architektur ist schwer auszunutzen, aber hat ihre Stärken. Gerade im Konsolenbereich sind solche Insellösungen noch am ehesten vertretbar.

Eine Hardware, die mehr als 5 Jahre lang hält, darf auch unüblich aufgebaut sein. Gerade Konsolen, die als dediziertes Spielgerät herhalten sollen und nicht nur konvertierte PC-Spiele in niedriger PAL-Auflösung rendern dürfen mit ihrer Architektur überraschen – das Design der PS2 erscheint mir ziemlich flexibel. Feintuning ist nötig, aber genau das ist auf Konsolen auch machbar. Bei Gran Turismo poppen z. B. bestimmte Dinge offenbar nicht entfernungsabhängig auf, sondern dann, wenn der Test während der Entwicklung ergab, dass trotz des Renderns des Objektes noch volle Framerate gewährleistet ist. Wer sein Spiel auf alle möglichen Systeme portieren möchte, wird angesichts der PS2 stöhnen. Wer gleich für die PS2 entwickelt, muss sich zunächst mal richtig Gedanken machen, er kann nicht gleich Code einhacken.

Auf der PC-Schiene lehne ich proprietäre Spielereien ab, im Konsolenbereich zählt für mich nur was hinten rauskommt. Auf die PS2 ist schwer zu optimieren – na und? Nicht "na und" ist hingegen Sonys Devkit-Politik.
Dem kann mich nur anschließen. Gerade im Konsolensektor sind solche Insellösungen möglich und sogar Vorteilhaft, weil man auf diese Weise ein Potenzial schaffen kann, was zwar anfangs schwer auszureizen ist, aber auf Lange Sicht von vorteil ist. Zweitens ist, wie ich schonmal schrieb, von Vorteil, dass hauseigene Studios zeitweise einen technologischen Vorsprung haben können, so dass der Konsolenhersteller sich damit einen Vorteil erschafft, was die Softwarentwicklung angeht.

Wo, wenn nicht auf Konsolen, kann man eine exentrische, aber potente Architektur einsetzen? Konsolen haben eine Lebensspanne von ca. 8 Jahren, was sowas absolut rechtfertigt. Im Gegenteil, ich finde es sogar wesentlich besser, als nur einen leicht modifizierten PC einzusetzen.



Wenn auf der XBox1 so leicht zu entwickeln ist, und die guten Studios das bevorzugen, dann frage ich mich doch, wieso Toptitel auf der XBox1 trotz öberflächlich stärkerer Hardware und leicht zu handbareren Entwicklungsplattform die PS2 Konkurrenten nicht toppen können. Das leigt wohl daran, dass die Topstudios die PS2 im Griff haben und sich der Entwicklungsaufwand lohnt.

[grakaman]

Wenn auf der XBox1 so leicht zu entwickeln ist, und die guten Studios das bevorzugen, dann frage ich mich doch, wieso Toptitel auf der XBox1 trotz öberflächlich stärkerer Hardware und leicht zu handbaren Entwicklungsplattform die PS2 Konkurrenten nicht toppen können. Das leigt wohl daran, dass die Topstudios die PS2 im Griff haben und sich der Entwicklungsaufwand lohnt.

Das liegt daran, dass außer solchen Fanboys wie dir niemand die große Menge an PS2 Spielen für grafisch konkurrenzfähig hält, im Vergl. zu GC und XBOX.

[betasilie]

Das liegt daran, dass außer solchen Fanboys wie dir niemand die große Menge an PS2 Spielen für grafisch konkurrenzfähig hält, im Vergl. zu GC und XBOX.
Aha, außer mich zu beleidigen kommt da nichts mehr mit Inhalt? :rolleyes:

Und wenn shcon Fanboy, dann doch bitte Nintendofanboy, weil das die einzige Firma ist, die in meinen Augen was besonderes hat.

[aths]

Das nette an dem ganzen ist ja, das nicht die gesamte Bumpmap geändert wird, sondern nur die CLUT für die Bumpmap. Die ist wesentlich kleiner und der Aufwand dadurch wesentlich geringer. Außerdem schreiben sie im PDF noch das die CLUT nicht für jedes Frame neu berechnet werden muss, sondern nur wenn sich die Position/Blickrichtung "wesentlich" ändert.Dann "poppt" die neue Struktur plötzlich rein. Man muss für die Color LUT die Indexmap neu berechnen, das ist nicht billig.

Auf der Webseite gibt es unten 2 PDF's; das obere beschreibt diese Art Bumpmapping. PDFs bitte ohne '. Wenn ich Zeit habe, sehe ich mir die PDFs mal an.

[rpm8200]

Hab den thread nicht gelesen. Finde lediglich dass man Sony mit keinem einzigen Euro unterstützen sollte. Sicher, M$ ist auch nicht viel besser und hat auch n Haufen Leichen im Keller. Allerdings was sich Sony mit dem Rootkit erlaubt hat, hat mich dazu bewogen in keinem Fall nochmal etwas von Sony oder SonyBMG zu kaufen.

Just my 2cents...

[aths]

Gut. Und was ist mit den Spielen, die schöne Texturen wollen? Die haben mal so richtig Pech gehabt.

Sag' nicht, dass es sowas auf der PS2 nicht geben würde. Dafür denke ich gibt es genügend Beispiele. Das Anwendungsgebiet der PS2 schliesst solche Spiele mit ein. Die anderen Spiele, die durch große Poligonmengen zu schöner Grafik kommen, sind kein Ausgleich dafür, dass die PS2 für einen Teil ihres Anwendungen technisch betrachtet nicht oder nur schlecht geeignet ist. Und was sagt uns das also über das generelle Design? Wenn ich böse wäre, würde ich sagen: Ziel verfehlt."Schließt" bitte mit ß.

Keine Konsole, die auf den Massenmarkt zielt, kann alles gleich gut können. Man könnte versuchen, so eine Konsole zu entwerfen – mit dem Ergebnis, dass sie im Endeffekt alles gleich schlecht kann, oder unheimlich teuer ist.

Die PS2 offeriert eine Hardware-Architektur, die bestimmte Dinge besonders gut und andere Dinge nur sehr schlecht kann – genau wie jede andere Konsole nicht nur Stärken hat. Resident Evil 4 sieht auf dem Cube nun mal deutlich besser aus. Bei der PS2-Umsetzung nehme ich nicht an, dass Capcom geschlampt hat, sondern dass die Hardware mehr einfach nicht hergibt. Und der Unterschied ist krass. Allerdings gibts mehr als Resident Evil. Ein Autorennen mit der Fahrphysik und der Grafik von GT4 habe ich auf dem Cube noch nicht gesehen.

Die Folien aus dem Link von mboeller zeigen noch sehr viel stärker auf, dass der Hardwareentwurf nicht ausgewogen ist. Die größte Performancelimitierung kommt (gemittelt über alle getesteten Spiele) von der CPU her, die ständig unter den viel zu kleinen Caches leidet. Anstatt da Transistoren in Unmengen an Vektoreinheiten zu stecken, die sowieso niemand benutzt, wären diese in Form von größeren Caches sicherlich besser aufgehoben gewesen.
Klar kann man beim Hardwareentwurf nicht umbedingt vorhersehen, was die Spielentwickler nun genau nutzen werden. Aber man muss als Hardwareentwickler wenigstens ungefähr abschätzen, wie leistungsfähig die einzelnen Komponenten und wie groß die Anforderungen an diese sind. Das scheint mir hier kaum gelungen zu sein.Die PS2-HW kann dann ausgewogen genutzt werden, wenn sie so genutzt wird, wie beim HW-Design vorgesehen. Jetzt haben viele Spiele ein anderes Anforderungspotenzial. Pech für die PS2. Die PS2 ignoriert praktisch den Ansatz, Geometrie mit Texturen oder Bumpmapping zu faken und offeriert das Rendering in echter Geometrie mit Polygonfarben. Im gewissen Sinne ist sie damit sozusagen zu fortschrittlich. (Das Fehlen vom MIP-Mapping ist trotzdem eine Frechheit.)

Caches sind bei der PS2 soweit ich das sehe nicht unbedingt zur Performance-Steigerung da, der Cache ist im Vergleich zur sonst verfügbaren (hohen) Bandbreite nicht schnell genug. Größere Caches hätte die Hardware verteuert. Dass Vector Units so wenig genutzt werden, ist auch dem Unvermögen des Programmierers geschuldet, der kein PS2-angepasstes Software-Design beherrscht. Ohne detaillierte Datenfluss-Analyse und Handoptimierung bleibt viel Potenzial brach liegen. Sony stellt dem Programmierer über die Vektor-Units sehr viel Rechenleistung zur Verfügung. Leider kann man die nicht so leicht nutzen wie es wünschenswert wäre. Meinst du, Sony hat ohne Analyse drauflosentwickeln lassen? Mit ihrer Einschätzung, was Entwickler in einigen Jahren brauchen würden, lagen sie etwas daneben. Du kannst jetzt natürlich aus der Retroperspektive mit Leichtigkeit Ratschläge geben, was Sony besser gemacht haben könnte.

Ich denke, dass die PS2 eine ganz nette Konsole ist, mit der man sehr schön spielen kann. :) Bloss darum geht es nicht. Hier wird rein die Technologie betrachtet, mehr nicht.Auch "bloß" bitte mit ß.

Die reine Technologie ist ein interessanter Ansatz, von dem sich einige Ideen – wie das parallele Laufen mehrerer Rechenchips – in der kommenden Konsolengeneration noch stärker auswirken werden. Was die Grafikausgabe angeht lässt Sony jetzt Spezialisten ran, da haben sie wohl eingesehen, dass man nicht alles selber machen sollte, wenn man sich da nicht auskennt.

Die Stärke der (ohnehin etwas in die Jahre gekommenen) PS2 ist nicht unbedingt texturierte Grafik. Dafür kann sie andere Sachen sehr gut – deshalb würde ich nicht gleich über die "reine Technologie" herziehen. Ich bin froh, dass es unterschiedliche Technologie-Ansätze auf dem Markt gibt. Obwohl ich aus Programmierersicht die PS2-Architektur wohl ablehnen würde – Vielfalt ist imo ein höheres Gut als Hardware, die jedem faulen Entwickler entgegen kommt. Was ich Sony bei der PS2 anlaste, sind nicht nur gewisse Versäumnisse in der Grafik-Ausgabe, sondern auch die Devkit-Politik. Nintendo laste ich ich allerdings auch einiges an, und bei Microsoft weigere ich mich, die bisher überhaupt als Konsolenhersteller wahrzunehmen, oder irgendeine Windows-Art oder DirectX-Technologie im Konsolenbereich zu akzeptieren.

[Aquaschaf]

Jetzt nicht speziell zur Playstation 2, aber einmal dem Hype um Multicore-Prozessoren und neue Konsolen mit parallelen Prozessoren entgegen: folgt nicht aus Amdahl's Gesetz, dass eine Spiel-Engine sich denkbar schlecht parallelisieren lässt?

Man kann nur Aufgaben innerhalb eines Frames parallelisieren und auch da hängen einige Dinge unabänderlich voneinander ab. Außerdem, bei 30FPS wird ein Frame in 0.0333sec berechnet. Wenn sich jetzt irgendetwas parallelisieren lässt, das 5% des Rechenaufwands ausmacht (0.0017sec) lohnt sich das schon wegen dem entstehenden Overhead kaum.

Oder mach ich da einen Denkfehler?

[Gast]

Regentropfen habe ich auf der PS2 in NFS MW und U2, auf dem Cube (wo ich nur NFS U2 habe) leider nicht.

Bitte bitte bitte WaveRace spielen!Die Regentropfen sind da nur gimmick.
Die Lichtbrechung aller Objekte unter Wasser mit VERTEX-Wellenbewegung... :):)
Kein anderes Jetski-Game(Systemübergreifend) hat das je geschaft, Ganz abgesehen vom perfekten Gameplay

[Gast]

Was ich Sony bei der PS2 anlaste, sind nicht nur gewisse Versäumnisse in der Grafik-Ausgabe, sondern auch die Devkit-Politik. Nintendo laste ich ich allerdings auch einiges an, und bei Microsoft weigere ich mich, die bisher überhaupt als Konsolenhersteller wahrzunehmen, oder irgendeine Windows-Art oder DirectX-Technologie im Konsolenbereich zu akzeptieren.


Richtig,Win und DX Zeugs hat nichts aber auch gar nichts auf Konsolen zu suchen.SegaRally2 auf DC hat gezeigt wie man mittels WinCE einen solch herausragenden Titel in die ruckelnden Abgründe schubst.

Eine Frage noch,da es ja zum Glück auf PS2 bspw. kein DX... gibt,was für APIs werden dort benützt?

[Coda]

Jetzt nicht speziell zur Playstation 2, aber einmal dem Hype um Multicore-Prozessoren und neue Konsolen mit parallelen Prozessoren entgegen: folgt nicht aus Amdahl's Gesetz, dass eine Spiel-Engine sich denkbar schlecht parallelisieren lässt?

Man kann nur Aufgaben innerhalb eines Frames parallelisieren und auch da hängen einige Dinge unabänderlich voneinander ab. Außerdem, bei 30FPS wird ein Frame in 0.0333sec berechnet. Wenn sich jetzt irgendetwas parallelisieren lässt, das 5% des Rechenaufwands ausmacht (0.0017sec) lohnt sich das schon wegen dem entstehenden Overhead kaum.

Oder mach ich da einen Denkfehler?Nein hast du nicht. Aber es ist schon auch einiges parallelisierbar.

[aths]

Jetzt nicht speziell zur Playstation 2, aber einmal dem Hype um Multicore-Prozessoren und neue Konsolen mit parallelen Prozessoren entgegen: folgt nicht aus Amdahl's Gesetz, dass eine Spiel-Engine sich denkbar schlecht parallelisieren lässt?

Man kann nur Aufgaben innerhalb eines Frames parallelisieren und auch da hängen einige Dinge unabänderlich voneinander ab. Außerdem, bei 30FPS wird ein Frame in 0.0333sec berechnet. Wenn sich jetzt irgendetwas parallelisieren lässt, das 5% des Rechenaufwands ausmacht (0.0017sec) lohnt sich das schon wegen dem entstehenden Overhead kaum.

Oder mach ich da einen Denkfehler?Multichip-Systeme sind jetzt ein Zwang, da ein vergleichbar rechenstarkes Singlechip-System zu teuer würde. Das Spieldesign wird sich anpassen müssen.

Nicht alles braucht man pro Frame. KI kann zum Beispiel auch mittelfristige Entscheidungen treffen.

Peilt man eine bestimmte Framerate an, dürfen die einzelnen Berechnungsabschnitte zusammengenommen auch bei einem Singlechip-System eine bestimmte Zeit nicht überschreiten. Hier könnte man zwar noch Loadbalancing machen – z. B. zulasten der Physik mehr KI-Berechnungen oder so, aber das Problem, innerhalb eines bestimmten Zeitraums fertig sein zu müssen, bleibt ja (typisches Echtzeitproblem.) Loadbalancing ist auch bei Multichip-System performant möglich, sofern die Architektur durchdacht wurde: Mehrere Chips rechnen mit dem gleichem Programmcode am gleichen Datenstrom, eine Verteilerlogik beschickt immer einen Chip, der gerade fertig ist, mit neuen Blöcken.

Natürlich muss die Kausalität eingehalten werden – aber warum soll, als andere Idee, nicht Chip 1 die Schatten für das nächste Frame berechnen, während Chip 2 KI und Physik für das übernächste Frame macht? Dass man alles innerhalb eines Frames parallelisieren müsste, sehe ich nicht.

[Iratages]

Bitte bitte bitte WaveRace spielen!Die Regentropfen sind da nur gimmick.
Die Lichtbrechung aller Objekte unter Wasser mit VERTEX-Wellenbewegung... :):)
Kein anderes Jetski-Game(Systemübergreifend) hat das je geschaft, Ganz abgesehen vom perfekten Gameplay

Auf PS2 gabs auch ein Jet-Ski, da sah das Wasser vielleicht genial aus. War aber nicht so gut wie WR.

[Gast]

Das leigt wohl daran, dass die Topstudios die PS2 im Griff haben und sich der Entwicklungsaufwand lohnt.

was für sony spricht, sind die performance analyzer, die es ja schon bei der psx gab. sowas würde microsoft doch nie machen, eher würden sie noch ein mini-os booten lassen. insofern wird die xbox1 max zu 70% ausgenutzt und wird es auch in zukunft nicht mehr dank 360.

[micki]

was für sony spricht, sind die performance analyzer, die es ja schon bei der psx gab. sowas würde microsoft doch nie machen, eher würden sie noch ein mini-os booten lassen. insofern wird die xbox1 max zu 70% ausgenutzt und wird es auch in zukunft nicht mehr dank 360.
natürlich gibt es sowas von ms, sowohl für xbox als auch für windows...

[Aquaschaf]

Multichip-Systeme sind jetzt ein Zwang, da ein vergleichbar rechenstarkes Singlechip-System zu teuer würde. Das Spieldesign wird sich anpassen müssen.

Aber es braucht kein vergleichbar rechenstarkes Singlechip-System um die selbe praktische Leistung zu erzielen.

Über KI kann man glaube ich allgemein kaum Aussagen treffen, es hängt davon ab ob sie direkt auf Eingaben des Spielers reagieren muss. Bei Physiksystemen macht Vorberechnung auch nur begrenzt Sinn; nehmen wir an in einem Shooter schießt der Spieler auf eine Dose und stößt sie so von einem Tisch. Wenn der Spieler im darauffolgenden Frame noch einmal darauf schießt, dann stimmt die erste Vorberechnungen der Dosen-Positionen nicht mehr.

Aus der Sicht des Spiels sind die Eingaben des Spielers ja zufällig, was über Vorberechnung von einem Frame hinausgeht kann schnell dazu führen dass sich das Spiel laggy anfühlt.

[micki]

aths geht es wohl eher darum, dass man an mehreren frames rechnet und nicht nur ein frame sequentiel abarbeitet.

das birgt natürlich einiges an overhead an sich, denn die daten müssen dafür ja eventuell mehrmals im speicher vorhanden sein und die einzelnen stages müssen synchronisiert werden.

MfG
micki

[Aquaschaf]

aths geht es wohl eher darum, dass man an mehreren frames rechnet und nicht nur ein frame sequentiel abarbeitet.

Ein Spiel hat einen ständigen Strom an Eingaben (durch den Spieler), von denen viele Dinge abhängen und die aus Sicht des Spiels für jeden Frame zufällig sind. Weiter als einen Frame in die Zukunft kann man kaum etwas berechnen.

[micki]

Ein Spiel hat einen ständigen Strom an Eingaben (durch den Spieler), von denen viele Dinge abhängen und die aus Sicht des Spiels für jeden Frame zufällig sind. Weiter als einen Frame in die Zukunft kann man kaum etwas berechnen.
leider macht man das heutzutage schon. du siehst oft frames auf dem bild, die 5frames zurückliegen, das wird sich mit Aths vorschlag noch weiter steigern, wobei das zufolge hat dass dir framerate steigt. die latenz bis du deinen input dargestellt bekommst bleibt also relativ gleich.

btw. es geht hier nicht darum zukünftige frames zu bearbeiten, sondern vergangene.

MfG
micki

[Aquaschaf]

Dazu hätte ich aber gerne Beispiele. Wenn meine Eingaben erst mit 5 Frames Latenz auf dem Bildschirm erscheinen würden, dann würde sich das Spiel sehr träge anfühlen.

[Jesus]

Dazu hätte ich aber gerne Beispiele. Wenn meine Eingaben erst mit 5 Frames Latenz auf dem Bildschirm erscheinen würden, dann würde sich das Spiel sehr träge anfühlen.

Glaube ich nicht, du wirst es kaum schaffen im selben Frame deine Bewegung zu analysieren, die neuen Weltkoordinaten (oder was auch immer) und die Reaktionen der Gegner darauf zu berechnen.

[Coda]

Dazu hätte ich aber gerne Beispiele. Wenn meine Eingaben erst mit 5 Frames Latenz auf dem Bildschirm erscheinen würden, dann würde sich das Spiel sehr träge anfühlen.Was glaubst du warum Far Cry bei niedrigen Frameraten träge wird...

[Aquaschaf]

Glaube ich nicht, du wirst es kaum schaffen im selben Frame deine Bewegung zu analysieren, die neuen Weltkoordinaten (oder was auch immer) und die Reaktionen der Gegner darauf zu berechnen.


Bei 30FPS bedeuten 5FPS Latenz 160ms. Das ist sehr fühlbar.

Was glaubst du warum Far Cry bei niedrigen Frameraten träge wird...

Ok, aber das ist doch ein Argument dafür so etwas nicht zu tun.

[micki]

Bei 30FPS bedeuten 5FPS Latenz 160ms. Das ist sehr fühlbar.



Ok, aber das ist doch ein Argument dafür so etwas nicht zu tun.
du hast keine wahl, die latenz wird immer bleiben (natürlich varriiert sie, aber auf schlechteren rechnern werden normalerweise dann nur 3 statt 5 frames latenz entstehen).
das einzige was sich ändert ist, ob du in den 200ms die du an latenz hast, 5bilder, oder 20 bilder sehen kannst.
es dauert nunmal seine zeit bis alle dinge verarbeitet wurden, die latenz wird sich nicht wegmachen lassen. das ist mit ein grund weshalb manche leute meinen sie können einen unterschied zwischen 30 und 60fps merken. bei singlecore systemen senkt sich die latenz einigermassen. jedoch lässt sich die performance nicht so einfach steigern wie mit mehreren cores. (was die hardware angeht)

[Coda]

Ok, aber das ist doch ein Argument dafür so etwas nicht zu tun.Schon. Ein Frame im Vorraus rendern schadet wirklich nicht und bringt schon sehr viel, weil dadurch die GPU und CPU weitaus unabhängiger sind.

Im nVIDIA-Treiber kann man auch ein Prerender-Limit einstellen, dass ich auf 1 setze (standard ist 3 oder 4 iirc).

[Aquaschaf]

Gegen einen Frame im Vorraus hab' ich ja nichts, aber ich glaube nicht dass der Gewinn durch Vorberechnung von 3-5 Frames das schlechtere Spielgefühl rechtfertigt.

[Coda]

Da bin ich auch deiner Meinung. Bei einem FPS ist das ein Unding, bei einem Rollenspiel geht wohl bischen mehr.

[StefanV]

Kommt halt drauf an, was für eine Reaktionszeit gefordert ist.

Ist eine kurze Reaktionszeit Sinnvoll (Action Spiele), machts keinen Sinn, 5 Frames und mehr im Vorraus zu berechnen, bei einem 'lahmen Spiel' wie z.B. Strategie oder Adventures ists nicht wirklich tragisch...

[san.salvador]

Glaube ich nicht, du wirst es kaum schaffen im selben Frame deine Bewegung zu analysieren, die neuen Weltkoordinaten (oder was auch immer) und die Reaktionen der Gegner darauf zu berechnen.
Es gab mal ein PC Spiel, in dem man die Latenz zwischen 1 und 7 Frames einstellen konnte. Ich weiß leider nicht mehr welches das war. Aber ich weiß sehrwohl, dass dieses Spiel spätestens ab einer Latenz von =>3 Frames unspielbar wurde.

[Gast]

Auf PS2 gabs auch ein Jet-Ski, da sah das Wasser vielleicht genial aus. War aber nicht so gut wie WR.

War warscheinlich schönes Shader-Wasser...vielleicht mit einfacher Polygonanimation
Das muß kombiniert werden mit echt animierten Polygonwellen,nur WaveRace.

[aths]

Aber es braucht kein vergleichbar rechenstarkes Singlechip-System um die selbe praktische Leistung zu erzielen.

Über KI kann man glaube ich allgemein kaum Aussagen treffen, es hängt davon ab ob sie direkt auf Eingaben des Spielers reagieren muss. Bei Physiksystemen macht Vorberechnung auch nur begrenzt Sinn; nehmen wir an in einem Shooter schießt der Spieler auf eine Dose und stößt sie so von einem Tisch. Wenn der Spieler im darauffolgenden Frame noch einmal darauf schießt, dann stimmt die erste Vorberechnungen der Dosen-Positionen nicht mehr.

Aus der Sicht des Spiels sind die Eingaben des Spielers ja zufällig, was über Vorberechnung von einem Frame hinausgeht kann schnell dazu führen dass sich das Spiel laggy anfühlt.Nicht die gesamte sichtbare Spielwelt ist von einem Frame aufs nächste vom Spieler beeinflussbar. Wenn sich im Hintergrund Bäume im Wind wiegen, kann der Spieler dort wenig machen. Auf Multichip-Systemen könnte ein Chip die aktuelle, unmittelbare Physik machen und ein zweiter die nicht beeinflussbare Physik. Der zweite Chip könnte einige Frames voraus berechnen und wenn er ein Limit erreicht hat, meldet er an, dass er erst mal für andere Aufgaben zur Verfügung steht. Bekommt er dann einen anderen Job, der ihn länger als 1 Frame beansprucht ist das dann nicht schlimm, da er ja schon einige Frames voraus fertiggestellt hat.

Bei KI sehe ich das ähnlich: CPU-Units in direkter Umgebung zum Spieler sollten schnell reagieren. (Wobei selbst bei 5 fps im Voraus und einer geringen Framerate von nur 25 fps die Verzögerung nur 0,2 Sekunden beträgt – echte Menschen reagieren ja auch nicht sofort. Ein zweiter KI-Algo könnte die allgemeine Lage analyisieren und die großen Entscheidungen treffen: Umzingelungs-Taktik, oder erst mal für neue Ressourcen sorgen etc. Es wäre auch denkbar, entkoppelt von der "Auswirkungs-KI" eine Analyse laufen zu lassen, welche versucht, den Spieler zu beurteilen. Die laufend aktualisierten Ergebnisse werden als Parameter zur "Auswirkungs-KI" eingespeist. Der Computer passt sich dann an den Spieler an. Zwar nicht sofort, aber das wäre auch nicht nötig.


Stell dir als Anwendungsbeispiel in einem Rollenspiel eine Stadt vor, in der jeder Bewohner zunächst seiner Arbeit nachgeht und nur dann auf den Spieler reagiert, wenn er in dessen Nähe ist.

Gegen einen Frame im Vorraus hab' ich ja nichts, aber ich glaube nicht dass der Gewinn durch Vorberechnung von 3-5 Frames das schlechtere Spielgefühl rechtfertigt.Warum immer so in tradionellen Bahnen denken? Einige Teile können 1-2 Frames im voraus berechnet werden, andere Teile noch weiter im Voraus. Zum Beispiel sollte die Kameraführung möglichst direkt auf die Eingabe reagieren. Auch das Auslösen eines Schusses sollte möglichst in gefühlter Echtzeit geschehen. Und bei Autorennen will ich eine direkte Reaktion auf meine Eingabebefehle. (Hier sehe ich z. B. GT4 im Vorteil zu NFSU2.) Weil man demnach Teile der Berechnungen möglichst aktuell halten sollte heißt das nicht, dass in solchen Spielen prinzipiell alles gleichmäßig aktuell gehalten werden muss.

Die jetzigen Singlechip-Systeme reichen schon für recht anspruchsvolle Spiele aus. Was man durch Multichip-Architekturen an möglicher Rechenleistung dazugewinnt, kann man für Zusatz-Effekte nutzen. Hintergrund-Animationen zum Beispiel.

[Aquaschaf]

Mein anderer Standpunkt rührt wahrscheinlich daher, dass ich die Zukunft von Spielen nicht unbedingt bei Weltsimulationen mit Physik und großer Mengen an AI-Agenten sehe. Sicher wird es solche Spiele geben, aber ich finde anderes interessanter ;)

Eine andere Hypothese: es ist Absicht, dass Konsolenhardware schwer zu programmieren bzw. auszulasten ist. Einerseits macht man Portierungen auf andere Plattformen unattraktiver. Andererseits führt man damit künstlich eine Steigerung der Optik von Spielen im Verlauf des Lebenszyklus der Konsole ein - im Laufe der Zeit bekommen Entwickler erst raus wie sie alle Resourcen des Geräts ausnutzen.

[RLZ]

Bei KI sehe ich das ähnlich: CPU-Units in direkter Umgebung zum Spieler sollten schnell reagieren. (Wobei selbst bei 5 fps im Voraus und einer geringen Framerate von nur 25 fps die Verzögerung nur 0,2 Sekunden beträgt – echte Menschen reagieren ja auch nicht sofort. Ein zweiter KI-Algo könnte die allgemeine Lage analyisieren und die großen Entscheidungen treffen: Umzingelungs-Taktik, oder erst mal für neue Ressourcen sorgen etc. Es wäre auch denkbar, entkoppelt von der "Auswirkungs-KI" eine Analyse laufen zu lassen, welche versucht, den Spieler zu beurteilen. Die laufend aktualisierten Ergebnisse werden als Parameter zur "Auswirkungs-KI" eingespeist. Der Computer passt sich dann an den Spieler an. Zwar nicht sofort, aber das wäre auch nicht nötig.
Das lässt sich als Multiagentensystem realisieren, wobei ein Scheduler den einzelnen Agenten je nach Aufgabe und Entfernung unterschiedlich Rechenleistung zur Verfügung stellt.
Im Prinzip kann man sich für die Vorausplanung einen simplen Offline-Planer holen, da man von einem festen Weltzustand ausgeht, ein Ziel erreichen will und einen Plan dafür braucht. Alles nichts neues... Wird in Spielen imo auch schon eingesetzt.

Stell dir als Anwendungsbeispiel in einem Rollenspiel eine Stadt vor, in der jeder Bewohner zunächst seiner Arbeit nachgeht und nur dann auf den Spieler reagiert, wenn er in dessen Nähe ist.
Das Auftauchen des Spielers in der Nähe ist ein Event und das Reagieren eine Aktion für die KI. Ich weiss aber nicht was dies mit Vorausplanung zu tun hat?

[aths]

Das Auftauchen des Spielers in der Nähe ist ein Event und das Reagieren eine Aktion für die KI. Ich weiss aber nicht was dies mit Vorausplanung zu tun hat?CPU-Stadtbewohner könnten einzeln simuliert werden. Wenn sie Hunger haben, essen sie was etc – erste Ansätze davon gibts in "Tropico". Rein gescriptete Bewohner sind zwar performancegünstiger, aber weniger flexibel – wenn z. B. der Brunnen vergiftet wird, muss dies explizit vorher im Script bedacht werden. Als einzelne KI-Objekte, die untereinander agieren können, reagieren sie auch auf unvorhergesehene Spieler-Handlungsweisen (hoffentlich reagieren sie einigermaßen nachvollziehbar.) So lassen sich auch recht einfach einzelne Persönlichkeiten realisieren (mittels unterschiedlicher Gewichtung der Input-Daten, also der jeweiligen Wahrnehmung der Umwelt.)

[RLZ]

Rein gescriptete Bewohner sind zwar performancegünstiger, aber weniger flexibel – wenn z. B. der Brunnen vergiftet wird, muss dies explizit vorher im Script bedacht werden.
>95% solcher Verhaltensweise kann als einfache Statemachine modelliert werden, die auf bestimmte Eventtypen reagiert. Die Wahrnehmung Brunnen vergiftet wirst du auch immer irgendwie in Code fassen müssen. Es sei denn du willst erstmal sich einen Bewohner vergiften lassen, damit ein Lernprozess eintritt.
Dann krieg Als einzelne KI-Objekte, die untereinander agieren können, reagieren sie auch auf unvorhergesehene Spieler-Handlungsweisen (hoffentlich reagieren sie einigermaßen nachvollziehbar.)
Was dann einfach ein lernfähiges Multiagentensystem wäre.
So lassen sich auch recht einfach einzelne Persönlichkeiten realisieren (mittels unterschiedlicher Gewichtung der Input-Daten, also der jeweiligen Wahrnehmung der Umwelt.)
Da gibt es sehr viele Möglichkeiten abgesehen von einfacher Gewichtung.
Ich sehe auch hier nicht den Aspekt der Vorausplanung, sondern nur eine lernfähige Reaktivebene der Agenten.
Wenn du ein Bespiel gebracht hättest, indem man nicht nur auf ein neues klassifizierbares Faktum reagieren muss, sondern der Agent vor einem neuen komplexen Problem steht (ala produzier die neue Waffe x, Agent schmeisst einen (HTN-)Planer an und löst mit seinen Fähigkeiten die Aufgabenstellung), wäre es ok. Sowas wäre auch neu in Spielen. :D

[aths]

Mein anderer Standpunkt rührt wahrscheinlich daher, dass ich die Zukunft von Spielen nicht unbedingt bei Weltsimulationen mit Physik und großer Mengen an AI-Agenten sehe. Sicher wird es solche Spiele geben, aber ich finde anderes interessanter ;)Welche denn zum Beispiel?

Eine andere Hypothese: es ist Absicht, dass Konsolenhardware schwer zu programmieren bzw. auszulasten ist. Einerseits macht man Portierungen auf andere Plattformen unattraktiver. Andererseits führt man damit künstlich eine Steigerung der Optik von Spielen im Verlauf des Lebenszyklus der Konsole ein - im Laufe der Zeit bekommen Entwickler erst raus wie sie alle Resourcen des Geräts ausnutzen.Dass man Konsolen mit Absicht kompliziert macht, um dem Entwickler das Leben schwer zu machen, glaube ich nicht. Ich nehme an, dass man sich bei der Frage zwischen einfacher Ausnutzung oder mehr Spezial-Leistung eher fürs letztere entscheidet, und die resultierende Komplexität eben in Kauf genommen wird.

[Aquaschaf]

Welche denn zum Beispiel?

Ich find es umgekehrt einfacher: für welche Spiele braucht man denn Physik und sehr viele AI-Agenten als wirklichen Mehrwert und nicht einfach bloß weil es neu ist und Technik sowie Budget es zulassen?

[betasilie]

Ich find es umgekehrt einfacher: für welche Spiele braucht man denn Physik und sehr viele AI-Agenten als wirklichen Mehrwert und nicht einfach bloß weil es neu ist und Technik sowie Budget es zulassen?
Für alle Spiele braucht man viel Physik und für alle Speiel mit viel Statisten braucht man viel KI.

Physik lässt die Umwelt realer erscheinen und ne gute KI ist im Endeffekt weniger aufwendig, als wenn man für jeden Mist Scripte schreiben müsste. Ich denke, wenn sowas erstmal massiv eingesetzt wird, wird man es nicht mehr wegdenken können. ... Ich kannte auch genug Leute, die meinten, dass in Spielen Physiksimulation überhaupt nciht notwendig ist und heute kann man es sich nicht mehr wegdenken.

[aths]

>95% solcher Verhaltensweise kann als einfache Statemachine modelliert werden, die auf bestimmte Eventtypen reagiert. Die Wahrnehmung Brunnen vergiftet wirst du auch immer irgendwie in Code fassen müssen. Es sei denn du willst erstmal sich einen Bewohner vergiften lassen, damit ein Lernprozess eintritt.

Was dann einfach ein lernfähiges Multiagentensystem wäre.

Da gibt es sehr viele Möglichkeiten abgesehen von einfacher Gewichtung.
Ich sehe auch hier nicht den Aspekt der Vorausplanung, sondern nur eine lernfähige Reaktivebene der Agenten.
Wenn du ein Bespiel gebracht hättest, indem man nicht nur auf ein neues klassifizierbares Faktum reagieren muss, sondern der Agent vor einem neuen komplexen Problem steht (ala produzier die neue Waffe x, Agent schmeisst einen (HTN-)Planer an und löst mit seinen Fähigkeiten die Aufgabenstellung), wäre es ok. Sowas wäre auch neu in Spielen. :DJa, es gäbe sehr viel mehr Möglichkeiten.

Dass man vorausschauend "denken" kann wäre in diesem Beispiel insofern angebracht, als dass die einzelnen Bewohner auch längerfristige Entscheidungen treffen. Zum Beispiel könnten sie ihre Ressourcen analysieren und daraus eine Todo-Liste erstellen. Diese wird nur dann geändert, wenn kurzfristig Ereignisse eintreten, die das erzwingen. Jedenfalls ist bei einer solche KI über größere Strecken keine Frame-weise Synchronisation notwendig. Man kann die KI weiter als ein Frame voraus "denken" lassen, jedenfalls für den Großteil der KI-Objekte.

[aths]

Ich find es umgekehrt einfacher: für welche Spiele braucht man denn Physik und sehr viele AI-Agenten als wirklichen Mehrwert und nicht einfach bloß weil es neu ist und Technik sowie Budget es zulassen?Ich finde es umgekehrt umgekehrt einfacher: Wie sollen sich zukünftige Spiele von heutigen noch absetzen? In NFSMW z. B. wiegen sich Bäume im Wind. Das gabs früher bei Autorennspielen nicht. Doch sorgen solche Hintergrund-Effekte dafür, dass die Welt lebendig und glaubwürdig erscheint.

Ok, in diesem Beispiel lässt man einfach ein Vertexprogramm (nun egal ob auf CPU oder GPU) ablaufen, um die Geometrie-Animation hinzubekommen. Da benötigt man keineswegs Multichip-Systeme.

Wenn du bei Shootern echte Physik hast, die so fordern ist, dass sie eine komplette CPU belegt, ermöglicht das bei guter Umsetzung ein besseres Eintauchen in die Spielwelt und eine größere Bandbreite an Lösungsmöglichkeiten.

[RLZ]

Dass man vorausschauend "denken" kann wäre in diesem Beispiel insofern angebracht, als dass die einzelnen Bewohner auch längerfristige Entscheidungen treffen. Zum Beispiel könnten sie ihre Ressourcen analysieren und daraus eine Todo-Liste erstellen. Diese wird nur dann geändert, wenn kurzfristig Ereignisse eintreten, die das erzwingen.
Tjo das wird wohl Teil meiner Diplomarbeit werden. X-D
Jedenfalls ist bei einer solche KI über größere Strecken keine Frame-weise Synchronisation notwendig. Man kann die KI weiter als ein Frame voraus "denken" lassen, jedenfalls für den Großteil der KI-Objekte.
Generell hat man bei Multiagentensystemen normalerweise keine frameweise Synchronisation. Man gibt der KI halt regelmässig (von mir aus auch frameweise) eine gewisse Rechenzeit. Die kann man dann per RoundRobin oä verteilen. Dafür spuckt die KI Aktionen an die Spieleengine aus, was zu erledigen ist.
Wenn die KI nicht mindestens soweit gekapselt ist hat jemand Pfusch produziert.

[Gast]

Ja, ganz abgesehen davon ist die Grafik von GT3 auch nur gut weil man sie auf einem TV und mit einem relativ hohem Sichtabstand gesehen hat. Würde man das Spiel auf einem PC-Monitor zu Gesicht bekommen würde keiner das Wort gute Grafik un den Mund nehmen...

Ich betreibe die PS2 (wie auch meine X-Box 360) per Upscan Converter (was anständiges für viel Geld) am TFT,die PS2 seit 2001.
Auch darauf sieht es gut aus.

Das ist ein Äpfel-Birnen Vergleich hier: in 4 Jahren sieht X-Box 360 Grafik auch dementsprechend aus und die Hardwarebasis ist ebenfalls fürn Arsch.

Heisst es dann auch wieder "die hatte nur 512 MB Ram,wie konnte man so einen Quatsch machen?"?

Jedes Stück Hardware wird nunmal von der Zeit eingeholt.

[Gast]

Bin grad fertig geworden mit dem lesen aller Seiten und muss denjenigen zustimmen die sagen die Technik der PS2 ist Schrott,bzw. war es auch schon zum damaligen Zeitpunkt.

Allerdings muss ich dann fairerweise auch sagen: die aktuellen Grafikkarten sind auch Schrott.
Schließlich boten damalige Karten ein anständiges AF,das bringen heutige nicht mehr.

Und ebenfalls Schrott ist dabei auch der Grafikkartenram.
Warum nur 512 MB?
Warum nicht 4 GB oder mehr?
Dann müssten die Programmierer nicht diese elendig hälichen Texturkomprimierungen einsetzen und Texturen könnten so aussehen wie sie erschaffen wurden.
Preis für diese Karten wäre mir egal,ich zahle jeden.

[Trailblazer]

Warum nicht gleich unified memory, warum keine sockel für gpu auf board. die mainboard sind schrott, die ewigmitgezogenene x86-kompatibilität ist schrott, das bs ist schrott und frisst die halbe hardware-leistung

[aths]

Bin grad fertig geworden mit dem lesen aller Seiten und muss denjenigen zustimmen die sagen die Technik der PS2 ist Schrott,bzw. war es auch schon zum damaligen Zeitpunkt.

Allerdings muss ich dann fairerweise auch sagen: die aktuellen Grafikkarten sind auch Schrott.
Schließlich boten damalige Karten ein anständiges AF,das bringen heutige nicht mehr.

Und ebenfalls Schrott ist dabei auch der Grafikkartenram.
Warum nur 512 MB?
Warum nicht 4 GB oder mehr?
Dann müssten die Programmierer nicht diese elendig hälichen Texturkomprimierungen einsetzen und Texturen könnten so aussehen wie sie erschaffen wurden.
Preis für diese Karten wäre mir egal,ich zahle jeden.Das Posting war im letzten Absatz wohl ironisch gemeint?

Texturkomprimierung kann, bei vernünftigen Tools, fast ohne sichtbare Verluste eine 4:1-Komprimierung ermöglichen.

[aths]

Tjo das wird wohl Teil meiner Diplomarbeit werden. X-D

Generell hat man bei Multiagentensystemen normalerweise keine frameweise Synchronisation. Man gibt der KI halt regelmässig (von mir aus auch frameweise) eine gewisse Rechenzeit. Die kann man dann per RoundRobin oä verteilen. Dafür spuckt die KI Aktionen an die Spieleengine aus, was zu erledigen ist.
Wenn die KI nicht mindestens soweit gekapselt ist hat jemand Pfusch produziert.Klingt vernünftig.

Schachprogramme haben ebenfalls das Problem, nur eine gewisse Zeit zur Verfügung zu haben. Entsprechend versucht man, schon mal vielversprechende Züge herauszusuchen um dort in die Tiefe gehen zu können, und vor allem möglichst schnell die schlechten Züge aus dem Suchbaum zu werfen. Weil ich ein extrem lausiger Schachspieler bin, werde ich vom Computer immer wieder überrascht, wie clever er ziehen kann. In Computerspielen bekommt man meist nach einiger Zeit mit, wie der Hase läuft, und versucht, die KI mittels Ausnutzung ihrer Schwächen zu schlagen. Zum Beispiel ist die KI in WC3 extrem mies. Schafft man es, den CPU-Gegner eine Weile hinzuhalten, bis seine Hauptgoldmine und Expansion leer ist, hat man gewonnen.

(Btw, "regelmäßig" bitte mit ß schreiben.)

[GastY]

Das Posting war im letzten Absatz wohl ironisch gemeint?

Texturkomprimierung kann, bei vernünftigen Tools, fast ohne sichtbare Verluste eine 4:1-Komprimierung ermöglichen.

Ich bin dennoch der Meinung das unkomprimierte Texturen,wenn auch nur "subjektiv",immer besser aussehen.

So,das alles mit absulut winkelunabhängigem AF und "HDR"(Ja 32 o. 64Bit genau wäre natürlich schön*träum*)+AA*16 in der 1600er flüssig.Wie schon erwähnt die Karten kriegens nicht hin sonst würden die Hersteller sich nicht todoptimieren.

Wahrscheinlich wären auch ein Gigabyte Vram nötig,natürlich mit 512er Interface,sonst ruckelt das HD-AF .Alles nur Ausreden der Hersteller und Kohlemacherei.Oder wieso sind GF4-Karten so beliebt und wieder aktuell?

[aths]

Ich bin dennoch der Meinung das unkomprimierte Texturen,wenn auch nur "subjektiv",immer besser aussehen.

So,das alles mit absulut winkelunabhängigem AF und "HDR"(Ja 32 o. 64Bit genau wäre natürlich schön*träum*)+AA*16 in der 1600er flüssig.Wie schon erwähnt die Karten kriegens nicht hin sonst würden die Hersteller sich nicht todoptimieren.

Wahrscheinlich wären auch ein Gigabyte Vram nötig,natürlich mit 512er Interface,sonst ruckelt das HD-AF .Alles nur Ausreden der Hersteller und Kohlemacherei.Oder wieso sind GF4-Karten so beliebt und wieder aktuell?Ich weiß nicht genau, was du sagen möchtest.

1024 MiB RAM? Da bin ich sofort dabei. 2048 MiB? Kann man durchaus ausnutzen (und nicht nur auslasten). Trotzdem sollte man weiterhin, wo möglich, Texturkomprimierung verwenden. Der Handel bei Texturkomprimierung ist so: Man gewinnt durch die dank Komprimierung höhere mögliche Auflösung mehr Qualität, als man durch die Qualitätskompromisse der Farbauflösung wieder verliert.

Voll winkelunabhängiges AF würde massiv Transistoren verballern. Winkelabhängigkeit à la Geforce 3 und Geforce 4 Ti sehe ich als gangbaren Kompromiss. Das ist aber nicht so sehr die Frage des Speicher-Interfaces. Und Spiele-Geometrie, die 1600x1200 nicht eckig aussieht, ist derzeit noch rar.

[GastY]

Ich weiß nicht genau, was du sagen möchtest.

1024 MiB RAM? Da bin ich sofort dabei. 2048 MiB? Kann man durchaus ausnutzen (und nicht nur auslasten). Trotzdem sollte man weiterhin, wo möglich, Texturkomprimierung verwenden. Der Handel bei Texturkomprimierung ist so: Man gewinnt durch die dank Komprimierung höhere mögliche Auflösung mehr Qualität, als man durch die Qualitätskompromisse der Farbauflösung wieder verliert.

Voll winkelunabhängiges AF würde massiv Transistoren verballern. Winkelabhängigkeit à la Geforce 3 und Geforce 4 Ti sehe ich als gangbaren Kompromiss. Das ist aber nicht so sehr die Frage des Speicher-Interfaces. Und Spiele-Geometrie, die 1600x1200 nicht eckig aussieht, ist derzeit noch rar.

Ach so,dachte GF3/4 waren voll WU?Wie dem auch sei...Aber dieses Niveau bitte wieder.Meine6800U sieht schon deutlich schlechter aus wie meine GF3,doch 7800GTX?! Oje...dann doch lieber PointSampling-Texturen:)Spaß:)

[Coda]

7800GTX filtert auf HQ inzw. genauso gut (oder schlecht) wie eine 6800.

[dildo4u]

Ich weiß hier gehts eher um Technologie als solches aber ich möchte hier mal den FPS Black als Beispiel bringen zu was die PS2 am Ende ihres Lebenscyclus noch in der Lage ist.

http://ps2media.ign.com/ps2/image/article/663/663731/black-20051102101259230.jpg

http://ps2media.ign.com/ps2/image/article/663/663731/black-20051102101256886.jpg

http://ps2media.ign.com/ps2/image/article/663/663731/black-20051102101257714.jpg

http://ps2media.ign.com/ps2/image/article/645/645809/black-20050826014428048.jpg

http://ps2media.ign.com/ps2/image/article/656/656426/black-20051005115559043.jpg

Durch die hohe Verbreitung der PS2 Hardware hoffe ich das noch lange Zeit neue und gute Games für die Konsole erscheinen.

[Monkey]

WHAT!!

das schaut ja mal suuper geil aus! hmm vielleicht sollte ich mal den kleber von der ps2 schublade abmachen und gt4 gegen ein anderes aktuelles game eintauschen

[aths]

Ach so,dachte GF3/4 waren voll WU?Wie dem auch sei...Aber dieses Niveau bitte wieder.Meine6800U sieht schon deutlich schlechter aus wie meine GF3,doch 7800GTX?! Oje...dann doch lieber PointSampling-Texturen:)Spaß:)Dass das Gegenteil von Winkelabhängigkeit à la R300/R420 (und R520 Standard) nun gleich "Winkelunabhängigkeit" sei, ist ein weit verbreiterter Irrtum.

Die GPU kennt beim Filtern nicht direkt die Winkel, in denen man die Textur sieht. Das Pixel im Texture Space wird für LOD-Berechnungen auf ein Parallelogramm vereinfacht. Beim isotroper Filterung wird anstelle des Parallelogramms eine quadratische Fläche gefiltert. Dabei ist das Quadrat von der Fläche her größer (da man keine "Spitzen" oder "Zacken" des Parallelogramms weglassen darf, sonst: Flimmern.) Problem: Ist das Parallelogramm sehr dünn, kommen bei einer quadratischen gefilterten Fläche sehr viele Texel-Daten rein, die eigentlich nicht zum Kernel gehören. Folge: Unschärfe.

Je stärker verzerrt die Textur (zum Beispiel bei Wand- oder Boden-Texturen) desto länglicher der echte Kernel, desto unschärfer das Ergebnis bei isotroper Filterung.

Beim AF versucht man nun, mehrere isotrope Samples (also Quadrate) so in das Parallelogramm zu legen, dass seine Fläche – aber auch nur seine Fläche – erfasst wird. Und das ist schwieriger als man denkt. Eine GPU, die volle Winkelunabhängigkeit bieten soll, müsste an dieser Stelle hochkomplizierte Rechnungen in sehr hoher Genauigkeit ausführen. Da sparen auch Geforce 3 und Geforce 4. Aber sie sparen vereinfacht gesagt nur so viel, dass man es kaum sieht. Die WA beim NV40, G70, R300, R420 und R520-Standard-AF kann man durchaus sehen.


Bei Konsolen (à la PS2) kann ich WA-AF als Kompromiss akzeptieren, aber meines Wissens wird nicht mal das geboten.

Durch die hohe Verbreitung der PS2 Hardware hoffe ich das noch lange Zeit neue und gute Games für die Konsole erscheinen.Ich sehe heute noch ständig alte PS1-Spiele in der Grabbelkiste. Die Konsole ist über 10 Jahre alt. Trotzdem wird noch Software verkauft.

[Gast]

Ich sehe heute noch ständig alte PS1-Spiele in der Grabbelkiste. Die Konsole ist über 10 Jahre alt. Trotzdem wird noch Software verkauft.Aber doch nicht für die PSX ... das kaufen sich PS2-Besitzer.

Es gibt sogar PSX-Spiele, die emuliert auf der PS2 besser laufen als auf einer echten PSX (und damit meine ich nicht Texturfilter oä). ZB Final Fantasy IX. Das Original-Laufwerk ist bei dem Spiel überfordert, sodass Kämpfe zu Beginn immer fürchterlich stocken (sogar die Musik gerät aus dem Tritt). Das hielt ich früher immer für eine Unzulänglichkeit von ePSXe, aber das ist es nicht.

Wenn man in der Systemkonfiguration der PS2 die Laufwerksgeschwindigkeit in der PSX-Emulation auf "volles Rohr" stellt, verschwinden diese Probleme.

Ich *hust* postuliere dann mal die Existenz von Spielen die nicht für die PSX entwickelt wurden, sondern lediglich zur PSX kompatibel sind.

[MegaManX4]

Vollwertig in dem Sinn, dass sie Turing-mächtig ist. Man kann also mit ihr alles berechnen, was man auch sonst mit anderen CPUs berechnen kann.

Wie schnell die einzelnen Operationen allerdings sind, ist eine ganz andere Frage.
Es fehlt jegliche Hardware für Branch Prediction. Und ein falsch vorhergesagter Sprung kostet 18 clock cycles!
Code, welcher viele Sprünge enthält, die nicht zu 99% nur in eine Richtung gehen, wird fürchterlich auf den SPUs laufen, trotz dem Vorhandensein von Branch-Hint Befehlen.

Dazu kommt, dass die SPUs in-order sind. Zusammen mit der 6 cycle load-to-use Latency aus dem lokalem Speicher und den 2 cycles (!) für den Register-Zugriff kommt es bei skalarem Code immer und immer wieder zu Wartezyklen.

Außerdem ist der SIMD-Durchsatz einfach genial: 4 FP-MAD (single-precision) Ergebnisse pro Takt. Das schreit einfach nach Streaming. Mit AFAIK 6 Takten Ausführungslatenz bleibt die skalare Performance weit hinter den Möglichkeiten der vektorisierten, bei der man - wie oben erwähnt - eben jeden Takt so ein Ergebnis fertig stellen kann.

Die Frage ist, was stellt man dann am besten mit den SPUs an? Bitte jetzt nicht "Streamen" antworten, da kann ich mir generell jetzt kein Beispiel vorstellen.

[MegaManX4]

Falls noch MIP-Mapping, gar trilineare Filterung geboten würde: Besser. Obwohl ich es nicht glaube, habe ich noch ein bisschen Hoffnung, dass man auf der PS3 die PS2-Spiele in besserer Qualität spielen kann (zur Not per Supersampling realisiert.)

Wäre es möglich das Supersampling ohne Kompatibilitätsprobleme zu integrieren wäre? Ich mein, FF-X oder GT4 würden so erst richtig aufdrehen.

[micki]

Die Frage ist, was stellt man dann am besten mit den SPUs an? Bitte jetzt nicht "Streamen" antworten, da kann ich mir generell jetzt kein Beispiel vorstellen.
z.b. kollisiontest, da kann man sehr schön alles mögliche gegeneinander crashen. die liste der kollisionen kann so ohne große abhängigkeiten erstellt werden, das ist also auf n-cpus möglich.

[MegaManX4]

z.b. kollisiontest, da kann man sehr schön alles mögliche gegeneinander crashen. die liste der kollisionen kann so ohne große abhängigkeiten erstellt werden, das ist also auf n-cpus möglich.

Na das hört sich doch gut an. Dann gehe ich recht in der Annahme das auch die auch für "Physik" eingesetzt werden können, ähnlich der PPU von Ageia? Auf jeden Fall wäre es wohl performanter als einen General Purpose Core dran rechnen zu lassen.

Ich habe mir, aufgrund der momentanen RPG Flaute auf dem PC auch eine PStwo zugelegt. Gleich mit ModChip(nicht was ihr wieder denkt), damit ich Grandia 3, Xenosaga und FF12 in NTSC ohne PAL Balken spielen kann. Zum Glück gibts im Netz genug Importhändler.

Habe mich eigentlich immer gegen Konsolen gesträubt, was micht aber wundert ist wie anders die Spiele/das Spielgefühl sind/ist.

Klar, Texturen grisseln enorm, was mich gerade bei GT4 ziemlich stört. Trotzdem bin ich gerade von den Effekten und dem massiven Polygoneinsatz begeistert (FFX).

Momentan scheint es mir als ob sich die Konsolenentwickler bei First Party Spielen einfach mehr Mühe geben um bestimmte Dinge zu realisieren. Oder aber die Architektur der PS2 zwingt die Entwickler dazu einfach mal andere Wege zu gehen.

[aths]

Wäre es möglich das Supersampling ohne Kompatibilitätsprobleme zu integrieren wäre? Ich mein, FF-X oder GT4 würden so erst richtig aufdrehen.Ich nehme an, dass für die PS1/PS2-Kompatibilität noch PS2-Hardware verbaut wird, und man in PS2-Spielen demzufolge nur PS2-Grafik erwarten kann. Würde der PS2-Rasterizer vom PS3-RSX emuliert, solle Supersampling möglich sein. Theoretisch auch Multisampling mit Transparency AA und für Texturen Auto-MIP-Mapping mit erzwungener anisotropen Filterung.

Nur 4x sparse grid Supersampling wäre für GT4 schon der Hammer, aber ich erwarte von der PS3 da nichts. Schon deshalb, damit man die glatteren Kanten durch die HDTV-Auflösung als Argument für PS3-Spiele nutzen kann.

[micki]

Na das hört sich doch gut an. Dann gehe ich recht in der Annahme das auch die auch für "Physik" eingesetzt werden können, ähnlich der PPU von Ageia? Auf jeden Fall wäre es wohl performanter als einen General Purpose Core dran rechnen zu lassen.
für sowas sind die vielen kleinen cores der ps3 durchaus geeignet, was aber der trick ausmacht ist, dass die "intelligenz" der normalen cpus ausgebaut wurde und dafür massig stumpfe power drinne steckt.


Klar, Texturen grisseln enorm, was mich gerade bei GT4 ziemlich stört. Trotzdem bin ich gerade von den Effekten und dem massiven Polygoneinsatz begeistert (FFX).

Momentan scheint es mir als ob sich die Konsolenentwickler bei First Party Spielen einfach mehr Mühe geben um bestimmte Dinge zu realisieren. Oder aber die Architektur der PS2 zwingt die Entwickler dazu einfach mal andere Wege zu gehen.
auf pc muss man jeden effekt auf jeder art von konfiguration zustande bringen, am liebsten wäre den leuten wenn ein spiel auf einem notebook mit onboard-graka flüssig läuft und auf einem multicore-multigpu-system gerade mal so noch flüssig läuft weil es die fähigkeiten davon perfekt in hochqualitative graphik umsetzt. natürlich darf es auf dem notebook nicht sonderlich schlecht aussehen und natürlich muss es auf highendkisten vieeel besser aussehen...
auf der konsole machst du es einmal und du darfst dir sicher sein es wird überall laufen. du darfst deine arbeitszeit investieren um es flüssiger zu machen und/oder mehr effekte einzubauen. und du mußt dich nicht mit treibern, OS usw. rumärgern. du darfst nicht nur die übelsten tricks einbauen, die leute freuen sich sogar darüber und du mußt kein schlechtes gewissen haben, weil du beführtest es läuft irgendwann nicht, weil die leute rausfinden dass du entgegen deren "how-to"s handelst *hehe* und dann die treiber tweaken...

vielen entwicklern wäre es auch sehr lieb, wenn man die architektur nicht komplett neu aufsetzt, sondern weiterentwickelt. sehr viel mehr leistung, ein wenig mehr features und sonst gleich. dann würdest du schon von anfang an auf der ps3 imposante graphik sehen statt pc-graphik.

[GloomY]

Die Frage ist, was stellt man dann am besten mit den SPUs an? Bitte jetzt nicht "Streamen" antworten, da kann ich mir generell jetzt kein Beispiel vorstellen.Das wäre aber eine passende Antwort ;)

Beispiel: Stell' dir ein Bildbearbeitungsprogramm vor. Du öffnest ein Bild und veränderst die Helligkeit - sagen wir um +10%. Dazu müssen für jeden Pixel die R-, G- und B-Werte mit dem Faktor 1,1 multipliziert werden. Das Programm, welches diese Operation ausführt, sieht folgendermaßen aus (Pseudocode):
Für jeden Pixel
Lese R-, G- und B-Werte aus Speicher in drei Register
Multipliziere alle drei Register mit 1,1
Schreibe Register zurück in Speicher
nächster PixelWas hier als "Stream" bezeichnet wird, ist der Speichertransfer vor und nach der (immer gleichen) Arithmetikoperation - d.h. vom Speicher in den Prozessor und danach wieder vom Prozessor zum Speicher. Hier werden nicht einzelne Werte geladen und verändert sondern auf einen Schlag gleich mehrere Millionen (Foto mit einigen Megapixeln) und zwar alle auf die gleiche Art und Weise. Das ist eben das SIMD Prinzip, was fast zwingend Streaming vom Speicher in den Prozessor und zurück bedeutet.

Verständnisfrage: Warum hilft bei solchen Anwendungen Cache nicht oder nur sehr wenig?
z.b. kollisiontest, da kann man sehr schön alles mögliche gegeneinander crashen. die liste der kollisionen kann so ohne große abhängigkeiten erstellt werden, das ist also auf n-cpus möglich.Es geht doch nicht um die Parallelisierung zwischen den SPUs sondern um die (effiziente) Nutzung der SPUs selbst. Das eine hat mit dem anderen doch nichts zu tun.
Wenn du die Kollisionserkennung vektorisieren kannst, dann ist gut; Wenn nicht, dann ist nicht gut. Unabhängig davon kannst du diese Operationen dann eben noch über deine n SPUs parallelisieren - egal ob jede SPU effizient arbeitet oder nicht.

[MegaManX4]

Das wäre aber eine passende Antwort ;)

Verständnisfrage: Warum hilft bei solchen Anwendungen Cache nicht oder nur sehr wenig?


Weil die Daten die zur Veränderung gebraucht wurden, nach der Bearbeitung selten ein zweites Mal benutzt werden? Cache ist ja dafür da häufig benutzten Code zwischenzuhalten damit dieser Code nicht ständig aus dem mehr oder weniger langsamen RAM nachgeladen werden muss.

Aber die immer gleichen Arithmetikoperationen, also das eigentliche "Rechenprogramm", im Cache vorzuhalten müsste doch von Vorteil sein. Begehe ich da irgendeinen Denkfehler?

Aber die Ar

[Jesus]

Das hier sowieso schon OT ist, CELL BE communication benchmarked:

http://hpc.pnl.gov/people/fabrizio/papers/ieeemicro-cell.pdf

[GloomY]

Weil die Daten die zur Veränderung gebraucht wurden, nach der Bearbeitung selten ein zweites Mal benutzt werden? Cache ist ja dafür da häufig benutzten Code zwischenzuhalten damit dieser Code nicht ständig aus dem mehr oder weniger langsamen RAM nachgeladen werden muss.Ja, Cache bringt nur etwas, wenn Daten oder Code wiederverwendet wird.
Aber die immer gleichen Arithmetikoperationen, also das eigentliche "Rechenprogramm", im Cache vorzuhalten müsste doch von Vorteil sein. Begehe ich da irgendeinen Denkfehler?Da die Arithmetik auf alle Datenelemente die gleiche ist (SIMD), muss man nicht für jede elementare Operation die Art und Weise der Arithmetik angeben sondern kann das für einzelne größere Blöcke machen (z.B. jede Operation zwischen Vektorregistern). Dann wird für jedes Datenelement in diesem Vektorregister die gleiche Arithmetik ausgeführt - was je nach Größe der Vektorregister verschieden lang dauert.

Bei einem "echten" Vektorrechner, der mehrere hundert Kilobyte für das Registerfile zur Verfügung hat (die darüber hinaus auch noch zur Compile-Zeit in verschiedene Größen unterteilt werden können) und diese üblicherweise entsprechend groß sind, reicht die Dauer einer Operation zwischen Vektorregistern aus, um die Latenz zum Holen der nächsten Instruktion aus dem Hauptspeicher zu überbrücken. Daher kann ein "echter" Vektorrechner vollkommen ohne Cache auskommen.

Da Cell "nur" 128 Bit Vektorregister hat und somit z.B. nur 4 Elemente à 32 Bit (z.B. Single-precision FP) enthält, muss man schon irgend eine Art und Weise von Cache oder eben von addressierbarem Speicher haben, aus dem man immer wieder schnell den nächsten Befehl nachladen kann. Das ist beim Cell der lokale Speicher der SPEs.

[Gast]

http://media.ps2.ign.com/media/788/788661/imgs_1.html

Sieht imo hammer aus!

[Gast]

http://media.ps2.ign.com/media/788/788661/imgs_1.html

Sieht imo hammer aus!

solange man nur die miniaturen ansieht ja, fullscreen sieht es aber sehr bescheiden (höflich ausgedrückt) aus.

[Spasstiger]

So ungefähr würde es in Fullscreen auf einem Röhren-TV aussehen:
http://img156.imageshack.us/img156/3994/valkyrie28tz.jpg
http://img136.imageshack.us/img136/2175/valkyrie17bx.jpg

[betasilie]

So ungefähr würde es in Fullscreen auf einem Röhren-TV aussehen:
http://img156.imageshack.us/img156/3994/valkyrie28tz.jpg
http://img136.imageshack.us/img136/2175/valkyrie17bx.jpg
Klar. Noch schlimmer hättest Du wohl nicht kompremieren können? :|

Und wie ein Fernsehbild aussieht, wissen wir wohl alle.

[Spasstiger]

Klar. Noch schlimmer hättest Du wohl nicht kompremieren können? :|
Für die Komprimierung kann ich nichts, die waren bei IGN so mies komprimiert. Hab extra noch versucht, durch die Scanlines und durch Kontrastanpassung die Kompressionsartefakte zu minimieren, um die Screenshots halbwegs gut aussehen zu lassen. Die Objektdetails scheinen jedenfalls ganz ordentlich zu sein für eine 6 Jahre alte Konsole.

[betasilie]

Achso, die Quelle war Schuld an den Komprimierungsartefakten. Dann nehme ich das natürlich zurück. :)

Ist halt generell etwas schwer sowas zu simulieren, besonders da die Projektionsschärfe und Brillianz der Fernseher sehr stark streuen. Es gibt Röhren da sieht ein RGB Bild umwerfend gut aus, und auf anderen Röhren denkt man, dass es sich nicht um das selbe Spiel handelt, weil alles so verwaschen ist.

Bei manchen TVs hat man sogar das Gefühl, dass deren Maske nichtmal Pal voll hinbekommt, wenn man sich die Fonts anschaut.

[Gast]

Trotzdem, die Grafik ist umwerfend und für PS2-Verhältnisse revolutionär.
Die Texturen sind ungewohnt detailreich und der Polygoncount ist ausgesprochen hoch.Ich bin froh,dass die grafische Fahnenstange mit God of War längst noch nicht erreicht zu sein scheint. Dazu kommt, dass wenn dieses Spiel in englischer Sprache erscheint, die Playstation2 Emulation wohl so weit fortgeschritten sein wird, dass der Traum von hochauflösenden, flickerfreien PS2-Spielen wohl Wirklichkeit wird.

[Gast]

Sind grafisch eigentlich die besten PS2-Games der XBOX überlegen?

AFAIK hatte ja die XBOX bessere Grafik. Aber für die PS2 kommen immer noch Games raus, die sehr gut optimiert sind. Was ist mit der XBOX? Kommt da noch etwas oder ist die praktisch tot?

[ESAD]

ich sehe nichtmehr wirklich einen sinn darin games für ps2/xbox zu veröffentlichen... und für ps2 was kommt denn da? das letzte große war doch god of war und sonst nur filmversoftungen und singstar/buzz oder?

[Gast]

Finds schon geil die erste paar Seiten zu lesen, kann ich nur jedem empfehlen, soviel BS, tut echt weh :(

An forderster Front natürlich StefanV alias Payne, mein Gott, du argumentierst wie eh und je, jetzt wetterst ja gegen die PS3, wohl auch Hardwareschrott.

Witzig wie eine so schrottige Hardware wie die PS2, Games wie God of War 2 auf den Schirm zaubern konnte, davon konnte Dreamcast nur träumen.

[Gast]

Also haben die top-Games auf der PS2 bessere Grafik am Ende doch noch als die Xbox?

Mein subjektiver Eindruck: Abgesehen von ganz wenigen Leuten wegen XBMC interessiert sich für die Xbox im Gegensatz zur PS2 kaum noch jemand. PS2 ist AFAIK auch mehr wert, auch wenn da keine HDD usw. dabei ist...

[Gast]

lol der gast

[X-Force]

also riddik auf der xbox übersteigt die fähigkeit der ps2 bei weitem, sowas habe ich nich mal ansatzweise auf der ps2 gesehen

ist es auch bekannt das die ps2 zu derben ruckelorgien neigt ? bzw die entwickler mit der grafik übertreiben ? beispiel killzone, besonders schlimm bei split screen und shadow of the colossos mit gefühlten 10fps

[Ringwald]

Warum postet man 2 Jahre später mit der Frage ob die PS2 Grafisch nun doch besser war? Spiel mal Fable, Sudeki, Kotor, Jade, Yager, Halo 2 und so weiter :wink:

[DaBrain]

Bessere Technik heisst nicht gleich bessere Grafik.
Ich weiss nicht warum die Leistungsfähigkeit einer Konsole immer an der Grafik der Titel gemessen wird.

Ich denke gute Grafik setzt sich so zusammen:

Technische Vorraussetzungen+Entwicklungszeit+Geld+Talent+Stil+Innovation (auch technischer Art)

[SgtTynis]

ich sehe nichtmehr wirklich einen sinn darin games für ps2/xbox zu veröffentlichen... und für ps2 was kommt denn da? das letzte große war doch god of war und sonst nur filmversoftungen und singstar/buzz oder?

Silent Hill Origins und God of War: Chains of Olympus sollen auch noch auf der PS2 released werden.

[Ringwald]

@DaBrain
Es geht hier aber um die Technische Sicht.
Das Content und gute Artist wichtig sind, sollte klar sein ;)

[StefanV]

Witzig wie eine so schrottige Hardware wie die PS2, Games wie God of War 2 auf den Schirm zaubern konnte, davon konnte Dreamcast nur träumen.
God of War ist mir wohl bekannt, habs durchaus ein paar mal gespielt.

Das Grundproblem der PS2 bleibt aber bestehen, nämlich der viel zu geringe Bildspeicher und das (meist) nicht vorhandene LOD/Mip Mapping, was zu Flimmern führt, besonders die Stille Ebene bei Final Fantasy X und X-2 sind hier hervorzuheben, empfindliche Personen sollten beim Spielen einen Eimer nebem dem Stuhl haben...

[DaBrain]

@DaBrain
Es geht hier aber um die Technische Sicht.
Das Content und gute Artist wichtig sind, sollte klar sein ;)

Ja, und ich sage, dass man dafür die Grafik der Titel nur sehr bedingt heran ziehen kann.

Ich denke ganz einfach dass die PS2 besser ausgereitzt wurde als die Xbox.

Hätte Square als ein gigantisches Projekt, einen Final Fantasy Teil für die Xbox heraus gebracht (keine Portierung mit PS2 Content!), mit einem FF-typischen Budget and Zeit und Geld, dann hätte es warhscheinlich grafisch um einiges mehr aus der Konsole geholt, als es die anderen Xbox Titel getan haben.

[Ringwald]

Ja das kann man schon so sagen.
Also wenn wir im Bereich der PAL Auflösung bleiben, dann konnte man sicherlich so einiges zaubern was mit heutigen next gen Spielen konkurieren könnte.
Schauen wir uns mal Driv3er an.
http://img444.imageshack.us/img444/927/1074531375pr1.jpg
http://img444.imageshack.us/img444/9681/1074531455fp5.jpg
Wenn man sich die Grafik anschaut, so wäre GTA 4 schon durchaus möglich.

[Coda]

Mit der Grafik von GTA3. Und komplett anderem Content.

[Nightspider]

Ja das kann man schon so sagen.
Also wenn wir im Bereich der PAL Auflösung bleiben, dann konnte man sicherlich so einiges zaubern was mit heutigen next gen Spielen konkurieren könnte.
Schauen wir uns mal Driv3er an.
http://img444.imageshack.us/img444/927/1074531375pr1.jpg
http://img444.imageshack.us/img444/9681/1074531455fp5.jpg
Wenn man sich die Grafik anschaut, so wäre GTA 4 schon durchaus möglich.

Wenn du die Auflösung nochmal halbierst, wäre GTA4 durchaus möglich. Weil du dann die ganzen Details weglassen kannst, die man ey nicht sieht. ;D

[Ringwald]

Ach kommt, ein paar fette Filter drauf und schon sieht man die matschigen Texturen nicht mehr :tongue: