| Re:DC-zeit und Homebrew/Technik |  |
>deswegen mag ich diese generation auch am liebsten. die ideen wie probleme angegangen wurden und die effizienz der lösungen sind einfach interessant.
>es betrift auch streaming-lösungen und kaschieren von ladezeiten. die aufzüge in metroid prime sind bekannt. richtig cool fand ich Jak&Dexter - manchmal stolpert er und fliegt auf die Fresse; dass macht er immer dann wenn der abschnitt noch nicht fertig geladen ist usw usw
Das ist wirklich mal einfallsreich und war mir tatsächlich nicht bekannt. XD
>DoA2 hat halt diesen Anime-Puppen-look. Eher simpleres Texturing, geht mehr auf Polygonzahl. Und mal vom Waifu-genönns abgesehen, richtig technisch und spielerisch saubere Spiele (also die Nachfolger auch).
Ich nehme mal an, dass die Vorgehensweise bei den Figuren mit bedingt hat, dass die Umgebungstexturen wiederum unheimlich gut waren bei dem Spiel? Stilistisch war das schon sehr smart alles.
Die Texturqualität bzw. wohl eher die Farbtiefe der Texturen war ja auch immer das, was die DC wiederum von der PS2 (dank der Farbbeschränkung bei der Komprimierung?) abgehoben hat, gerade im direkten Vergleich im Falle von Ports. Die grafisch am besten gealterten Spiele (wozu ich auch so Sachen wie Power Stone zähle), setzen ja sehr auf detaillierte Texturierung bei im Normalfall eingeschränkten Arealen.
>Ich denke VF4 wäre - ohne allzu grosse Abstriche im Vergleich zu PS2 - auch auf dem Dreamcast gegangen.
Das überrascht mich. Dachte, das wäre bei einer Zielsetzung von 60fps weit über dem, was das DC zu leisten in der Lage gewesen wäre (vor allem in Hinblick auf die Backdrops).
>Resident Evil 4 auf der PS2 bewegt sich übrigens polygon-mässig (bei 30 fps) in durchaus DC-tauglichem bereich. Beleuchtung müsste aber imo (noch) weiter reduziert werden.
Interessant und würde man aufgrund der Charaktermodelle auch nicht direkt vermuten.
>>Muss zugeben, dass das alles bereits vollkommen außerhalb meines Verständnishorizonts liegt, da ich mich mit Programmierung null auskenne. Ich werde es mal einem Kumpel zu lesen geben, für den es interessant sein dürfte (wobei er aktuell eher am N64 interessiert ist, aber auch DC Fan ist), damit es nicht ganz umsonst war. ;) Sorry.
>
>ich hab wie gesagt die PS1-N64 generation geskipt damals, und mich erst danach kurz mit der Hardware beschäftigt. Ohne jetzt allzu fies sein zu wollen - N64 würd ich nicht programmieren wollen ;)
Hehe, ich glaube da interessiert ihn aktuell auch eher das Spiele-Modding als die Hardware-Architektur bzw. er verfolgt, was sich bei ersterem so tut. Hatte mir z. B. letztens folgendes Video verlinkt:
[https://www.youtube.com/watch?v=lw6rzcA_qQg]
Ist schon interessant, was auch da an Optimierungen möglich zu sein scheint und für Projekte laufen.
>es hörte sich zu sehr nach "bottleneck auf bottleneck" an. speicheraufbau, mini texturen-cache, sound in software etc etc.
Will nicht zu sehr mit ständigen Fragen nerven, aber kannst du einschätzen, ob der Speicheraufbau tatsächlich für die oft schlechten Framerates der N64 Spiele verantwortlich war? Hatte dazu Unterschiedliches gelesen (auch mal Z-Buffering als Grund), aber nichts Eindeutiges. Evtl. weil es nicht eindeutig ist.
>SEGA hat mit der Dreamcast genau das gemacht was Nintendo später mit dem Gamecube gemacht hat. Sich hingesetzt, sich die aktuelle Hardware (Sat/N64) angeguckt und genau überlegt wieso diese so scheisse ist. Und nahezu alles ausgemerzt was zu Problemen führte. Beim N64->Gamecube was es v.a. der Speicher- und Cache "aufbau". Satoru Iwata hatte sogar zur E3 2001 (glaub ich) ausführlich davon geredet, dass die Balance immens wichtig ist, und ist mehrmals auf das speicher-system eingegangen.
>Beide Konsolen - also Dreamcast und Gamecube - stellen in meinen Augen eine perfekt-ausbalanzierte Hardware für den Preisrahmen (waren doch beide <300dollar, glaub ich) dar. Einfach, kostengünstig, leistungsfähig. Klar beide haben auch ihre Problemzonen...
Der GC stellt da wirklich eine interessante Ausnahme innerhalb des Hardware Repertoires von Nintendo dar. Liest sich nach deren durchdachtester Hardware.
>PS2 ist irgendwie... wir wollen BUMS... packen da viel zeug rein, durchsatz bis zum geht-nicht-mehr, haben selber keine Ahnung wie und wozu das gut ist, haben keine guten compiler, geschweige denn irgendeine gute Doku wie wo was wozu. Die VUs müssen in assembler programmiert werden in einem etxra dialekt - gute doku, ähm... Also alles ganz ganz wahnsinnig komplex gemacht und verkackt komplett beim hardware-bildausgang, also etwas was nicht über software revisionen zu fixen geht, das problem blieb bis zum ende.
>Nach ner Zeit lernen die Entwickler viele Tricks wie bestimmte Bereiche der Hardware für welche Operationen benutzt werden können und die Hardware erweisst sich als ziemlich leistungsfähig (siehe die letzten erschienen Spiele). Ich glaube aber nicht dass vieles von Kutaragi & co so gedacht war. Bei PS3 lief die Vorgehensweise dann ja eher schief.
>Für hardcore Programmierer/Optimierer ist aber PS2 der feuchte Traum
>ich finde die PS2 am interessantesten, allerdings beschäftige ich mich dann doch mehr (und lieber) mit der Dreamcast
>reflexionen können zB wie folgt gemacht werden. entweder kamera entsprechend setzten und das ganze auf eine temporäre textur rendern. oder die gesamte geometrie an einer bestimmten Fläche spiegelverkehrt reproduzieren und die polygone die als Spiegel fungieren entweder komplett unsichtbar machen oder mit einer halbtransparenten textur versehen.
Das grundlegende Prinzip beider Methoden ist mir an sich denke ich klar. Mir ging es speziell darum, dass man bei PS2 Spielen wie Tekken Tag auch darüber hinausgehende Reflexionseffekte hatte (siehe die Wasserfützen im folgenden Video, wo es am deutlichsten ist, dass die Transparenz innerhalb der Textur selbst zu variieren scheint):
[https://www.youtube.com/watch?v=6ySqRhPb8vI&t=3m8s]
Sowas kennt man vom DC afaik ja an sich gar nicht. Der Effekt bei besagtem Bosskampf in Headhunter sieht allerdings ähnlich aus, wobei es nicht so wirklich gut zu erkennen ist aufgrund des Regens in besagter Szene. Bei Tekken Tag wurde diese Technik (ich nehme mal an, dass es die gleiche ist in allen Stages) ja auch in anderen Stages verwendet, um eine Art Bump Mapping zu faken.
Bei Lament of Innocence gibt es das auch in ähnlicher Form an zwei Stellen, u.a. mit gespiegelter Geometrie:
[https://www.youtube.com/watch?v=WaNYfNGvIRg&t=5h24m45s]
[https://www.youtube.com/watch?v=WaNYfNGvIRg&t=5h11m]
Wirkt so, als würde man innerhalb der Textur (bzw. Texturebenen?) bei der Transparenz variieren und auch unterteilen können in eine Ebene der Textur mit Glanzeffekt/Reflexion und eine ohne diese Eigenschaft, was dann diesen Oberflächeneffekt vorgaukelt. Habe mich immer gefragt, wie das genau funktioniert und ob es was Hardware-spezifisches ist, da eigentlich nur auf der PS2 in der Form vorhanden. GC und XBox brauchten solche Umwege ja dank richtigem Bump Mapping vermutlich eh nicht, allerdings habe ich mich gefragt, ob sowas auf der DC theoretisch auch möglich gewesen wäre, selbst wenn es in der Praxis dann zu ineffizient wäre aufgrund der von dir beschriebenen Speicher-Problematik.
>die zweite variante macht nur sinn wenn es das level layout zulässt. bei variante 1 renderst du ja in eine textur, die du dann entsprechend auf ein objekt draufklebst. dreamcast unterstützt ja hardware-textur-kompression, allerdings müssen diese schon von vornherein entsprechend vorliegen - die CPU schafft keine VQ kompression in echtzeit (kA was SH4 da braucht, auf jedenfall mehrere/viele sekunden minimum, wenn es sonst nichts zu tun hat). also renderst du das in eine unkomprimierte textur. und vergleich mal eine komprimierte png und eine unkomprimierte bmp datei... diese textur muss dann in den 8MB vram liegen. dazu kommt noch "twiddling" dazu (speichern in einem anderen speicher layout, ist aber nicht sonderlich kompliziert), nur wenn eine textur "twidded" ist, ist beim rendern billiniares Filtering optimal, ansonsten gibts nen klitzekleinen hickup im PVR-chip (er wirds schon rendern, nur nicht optimal schnell). Headhunter hat da wo es Spiegelungen gibt, einfachen aufbau und wenige modelle.
Ah okay, also aufgrund der Speicherbeschränkung nur auf wenigen Objekten gleichzeitig einsetzbar. Wie sieht es da eigentlich aus mit den Glanzeffekten, wie man sie bei Space Channel No5 auf den Figuren hat (meistens sind diese ja untexturiert)? hat Gleiches Prinzip? Die Kristalle in Ecco wirken auch recht effizient gemacht.
>Im Netz gabs ja von SEGA fans immer die Schreie, das PVR VQ kann und 128mb texturen in 8Mb passen blabla. Es ist alles nicht soo einfach. PS2 kann Texturen komprimieren quasi on-the-fly (also nicht per frame, aber immerhin *machbar*) - die hardware ist flexibel (und parallesierbar) genug. Es wurde auch oft so verwendet
Bzgl. des DC ist die Verehrung ja bei vielen wirklich enorm. Also sowohl gewesen, als auch immer noch. Da ist sicherlich eine Menge „nicht wahr haben wollen“ involviert. Kann mich noch einigermaßen dran erinnern, wie "witzig" es damals wurde, als Soul Calibur 2 erschien. ;)
>MDK (der erste, von 96) auf dem PC hatte übrigens absolut geniale Ideen für Spiegel und Transparenzen - es war ALLES gefaket :D und sah so geil aus!
Erinnere mich. Fand ich damals auch sehr nice. :)
>>Vielen Dank für die ganzen Infos. In meinem Falle wohl leider teils Perlen vor die Säue, da ich da wie gesagt nichtmal Laie bin, aber gibt sicher einige Leute hier, die damit mehr anfangen können. :)
>
>und trotzdem hast du bis zu ende gelesen :)
Klar, mega interessant halt, mal wirklich tiefergehende Statements zu bekommen von jemandem, der Ahnung von der Hardware-Architektur hat und bestimmte Dinge nüchtern einschätzen kann. Gibt ja ansonsten hauptsächlich Diskussionen zu dem Thema, die dann eher den elendingen console wars zuzuordnen sind.