NerdmitHerz schrieb:
dass ne 409 ne 4k karte sein soll und dann brauchst bei der karte DLSS
DLSS oder FSR stören da nicht mal. Es ist nur, ungewohnt. Vorher fast ohne Probleme ein fps-cap bei 144 rein, jetzt sind die 144 je nach Spiel fast schon utopisch. Aber ich liebe den 32“ schön groß.
theGucky schrieb:
Das ist halt das Problem, wenn man den Dollarpreis als Basis nimmt.
Nein, ich habe den Dollarpreis sogar ganz absichtlich genommen, da er eben keine Wechselkursschwankungen unterliegt und man damit relativ gut die Preise nachvollziehen kann. Das ist mit dem € Preis nämlich nicht möglich.
In den USA ist die Umsatzsteuer / Mehrwertsteuer zudem von Bundesstaat zu Bundesstaat unterschiedlich. Kursschwankungen sind für uns hier aktuell unschön, aus Sicht der Hersteller aber nachvollziehbar, wenn sie ihre Bilanzen in USD ausweisen.
Nolag schrieb:
Der Einfluß des Betriebssystems auf die Bildraten wird bei Konsolen eh häufig überschätzt.
Es ist auch weniger das OS als die Software die nebenbei läuft.
Dazu kommt, das bestimmte Sachen ganz anders implementiert werden können.
Cohen schrieb:
Stimmt, seitdem wird auch im Konsolenbereich eh nicht mehr nur für eine fixe Hardware programmiert
Bei Konsolen programmierst du seit mindestens 20 Jahren nicht mehr für fixe Hardware oder „Hardwarenah“. Bereits zu PS2 und Xbox wurden APIs verwendet, um eine gewisse Abstraktion zu erlangen und Portable zu sein.
Man kann aber auch heute noch viele Sachen für eine Konsole optimieren. Fängt schon bei den Shadern an. Geht über die RAM-Assoziation und die Fähigkeiten der CPU.
Dazu kommt, das du auf Konsolen bestimmte Konstrukte aus dem Programm oder ggf. Compiler herauslassen kannst, weil alles bekannt ist.
Es geht hier in der Regel eher darum, was man weglassen kann, nicht unbedingt das, was extra für die Konsole dazu kommt.
aid0nex schrieb:
Seitdem beide Konsolen auf x86 laufen, ist der Vorteil kleiner geworden, das stimmt! (Da die Unterschiede zum PC geringer sind)
Ob ARM, x86 oder PowerPC, die Unterschiede kann man heute mit einem guten Compiler quasi vollkommen aus der Gleichung nehmen. Selbst unterscheide in der Bit-Folge, weil der Compiler entsprechend damit umgehen kann. Solange man ISA spezifisches weg lässt, ist das kein Ding.
Die Hauptprobleme heute für Softwareinteroperabilität ist die Software-Architektur des OS sowie der API, da warten heute wesentlich mehr Unterschiede, die sich auch entsprechend negativ auswirken.
Es ist leichter ein Programm von x86 auf ARM zu Portieren, wenn OS und APIs gleich sind, als von Linux zu Windows, wenn die ISA gleich ist.
aid0nex schrieb:
Er ist jedoch nicht verpufft, das ist falsch.
Ja und Nein. Es ist kompliziert. In der Regel geht es hier um bestimmten Eigenheiten und Eigenschaften. Heute wird auf eine Konsole stärker auf die Eigenschaften der Hardware optimiert, nicht mehr ihre Eigenheiten.
Die Optimierungen auf Eigenheiten übernimmt heute in der Regel das Devkit und dessen Compiler, weil viele Optimierungen eh immer die Gleichen sind.
Das mit den Eigenheiten und Eigenschaften ist allgemein heute ein Problem in der Softwareentwicklung. Optimierstun du auf die Eigenheiten, dann bindest du dich auf lange Sicht mit deinem Quelltext an die Hardware und verliest die Möglichkeit verschiedene Hardware zu verwenden. Optimierst du auf die Eigenschaften, kann es wiederum passieren, dass du die Leistung der Hardware nicht optimal ausnutzt.
Deswegen werden heute auch auf dem PC oft die "Eigenheiten" durch die Treiber optimoiert, die Eigenschaften durch die Entwickler.
