News Shooter-Klassiker: Max Payne bekommt Pathtracing - schon wieder

[_Amelie_]

Äh, Dir ist schon klar, dass RT nur Licht macht? Es verändert nichts an Kanten, Texturen und Oberflächen.

Falsch. Das is doch mit einer der Gründe. Realistisches Licht, abhängig vom material, albedo, roughness etc.. etc.. All das kann Raster einfach net.

 

[Cleriker]

In 4K braucht man kein DLSS Balanced. Da reicht locker DLSS Performance. Das gilt auch für FSR 4. Dann noch 2x FG und das ist gut spielbar.

Reicht wofür? Um bei schnellen shootern ein ruhiges Bild zu bekommen? Ja, wahrscheinlich.
Für die gleiche Bildqualität wie in quality oder balanced aber ganz klar nicht. Solch pauschale Aussagen helfen niemandem.

Hast du das Blindtestvideo zu multi framegen gesehen? Da gab's falsch dargestellte Farben bei Lichtkanten. Die sind bei einfacher FG seltener und bei quality statt balanced weg. Dabei handelte es sich aber um cyberpunk, Nvidia techdemo. In keinem anderen Spiel ist dlss so gut implementiert und dennoch sieht man Unterschiede.

 

[G4mest3r]

Falsch. Das is doch mit einer der Gründe. Realistisches Licht, abhängig vom material, albedo, roughness etc.. etc.. All das kann Raster einfach net.

Und immer noch nur Licht und Reflexionen. Falsch? Du gibst Dir ja schon selbst die Antwort.
Wie Du schon sagst: "abhängig vom Material". Nichts, aber auch gar nichts verändert RT am Material, seinen Eigenschaften und deren Wirkung. Das muss erst alles definiert werden, bevor RT da realistisch wirken kann.
In älteren Titeln ist das oft noch nicht einmal ausreichend definiert.

Btw. Materialeigenschaften, Albedo und Oberflächeneigenschaften werden auch in Light-Maps von Shadern, Bump-Mapping usw. bei Raster genutzt. Natürlich nicht so realistisch wie in RT mit Lichtbrechung, Krümmung, Diffuser Beleuchtung, Reflexion in Reflexion. Aber braucht es das immer? Gerade bei so alten Retro-Titeln?

Wie gesagt, da gäbe es so einiges anderes, das man erst mal überarbeiten könnte und teilweise sogar muss, bevor selbst RT so richtig wirken kann.

Du hast ein mittelmäßiges Gemälde und rahmst das jetzt in einem teuren aufwendigen vergoldeten Barrock-Bilderrahmen. Wirkt auf die Entfernung hochwertig, macht das Gemälde aber nicht besser

 

[Mr.Floppy]

Geht so... Eine 5070ti schafft hier im Test in 4k gerade mal 31 fps mit dlss balanced. Gleiche Einstellungen, aber 1440p sind es noch immer unter 60 fps. Also nein, geht nicht wirklich.

Krass. Eine RTX 5080 hier, gepaart mit einer (vergleichsweise) Uralt-CPU (Ryzen 9 3900X), schmeißt bei 3360x1440 in DLSS Balanced (ich habe zwar einen 5120x1440, spiele aber fast alles nur in 21:9 statt 32:9) fast durchgehend 3-stellige fps aus und ich habe es daher auf 60 fps begrenzt, und damit läuft die GPU recht leise und auch nicht sonderlich warm.

Ich bin froh, keinen 4k Monitor befeuern zu müssen. Ultrawidescreen ist mir wichtiger und zudem ist die Auflösung, in der ich spiele, nur 58,3 % von 4k. Also massig Reserven für die GPU.

 

[PCGH_Torsten]

Selbstverständlich.

Aber hard assets neu zu designen und einzubauen ist viel viel Arbeit und hat keine Buzzwords, während Pathtracing in ein bestehendes Spiel zu bauen vergleichsweise wenig Aufwand ist und man mit "PATHTRACING!!!" grade super Klicks sammeln kann.

Nicht falsch verstehen, natürlich ist das hier besser als nichts, aber ein echtes Remaster wäre bei dem Ding wirklich eine Granate.

Eigentlich gehört Max Payne zu den Titeln, bei denen gerade die Beleuchtung der größte Schwachpunkt ist. Die Texturen waren dagegen seinerzeit Weltklasse und sind vergleichsweise gut gealtert und die Animationen vollkommen angemessen für den ohnehin eher einfachen Spielinhalt. Licht dagegen trägt enorm zur Stimmung der düsteren Levels bei.

Natürlich ist nach einer vollständigen PT-Umsetzung dann alles andere limitierend und könnte man ein erhebliche Verbesserung auch durch Implementierung eines aktuellen Rasterizers erreichen. (Oder noch besser: Einer auf dem Stand zwischen Alien Isolation und Witcher 3.^^) Aber: Dafür müsste man genauso jedes einzelne beleuchtungsbezogene Asset anfassen und sogar noch weitaus umfangreicher modifizieren als für Pathtracing. Also warum nicht gleich richtig, vor allem als Hobbyprojekt? Ehe das fertig ist, haben Grafikkarten & KI mit etwas Glück auch genug Leistung.

 

[PCGH_Raff]

Remedy ist hoffentlich gerade dabei, das alles in Northlight umzusetzen, während wir darüber reden.

MfG
Raff

 

[Nuallan]

Reicht wofür? Um bei schnellen shootern ein ruhiges Bild zu bekommen? Ja, wahrscheinlich.
Für die gleiche Bildqualität wie in quality oder balanced aber ganz klar nicht. Solch pauschale Aussagen helfen niemandem.

Es geht nicht darum, ob es noch besser geht, sondern ob es reicht, ob der Tradeoff es wert ist für Pathtracing, und da sollte die Antwort klar sein. Natürlich sind Balanced & Quality jeweils (minimal) besser als niedrigere Presets.

Das Standard-Modell M bei DLSS 4.5 ist explizit für den Performance-Modus in 4K optimiert, und in Blindtests vor nativ+TAA.

Hast du das Blindtestvideo zu multi framegen gesehen? Da gab's falsch dargestellte Farben bei Lichtkanten. Die sind bei einfacher FG seltener und bei quality statt balanced weg. Dabei handelte es sich aber um cyberpunk, Nvidia techdemo. In keinem anderen Spiel ist dlss so gut implementiert und dennoch sieht man Unterschiede.

Niemand sagt mit FG hat man ein perfektes Bild. Aber FG macht mit Pathtracing (genau dafür wurde es damals von Nvidia released) oft den Unterschied zwischen flüssig und Ruckelorgie. Also nehme ich natürlich Pathtracing+FG und seine kleinen Macken, statt kein PT und kein FG.

Das scheinen viele so zu sehen, sonst würde nahezu niemand mit PT zocken.

 

[_Amelie_]

Hast du das Blindtestvideo zu multi framegen gesehen? Da gab's falsch dargestellte Farben bei Lichtkanten.

Ja, ganz schlimm. Da wurde mit der Lupe geschaut, was man bemängeln kann und ob man überhaupt einen Unterschied sieht. Das war doch der Zweck des Videos, und das wusste jeder, der da mitgemacht hat. Da sind sich doch alle einig, oder? Dass man es mit Gewalt suchen musste und selbst beim Lag kaum was feststellen konnte, spricht doch gerade für Frame Generation – also die von Nvidia selber, nicht diese Flickenlösungen durch Lossless Scaling. Die war natürlich nicht schön, aber halt auch zu erwarten.

Und trotz dieser geradezu super Performance und Qualität, die ja sogar von den Testern bescheinigt wurde, weil sie es erst beim Lag bemerkt haben – und selbst das fiel bei DLSS Frame Generation von Nvidia super gering aus, wie Raff ja ausgiebig kommentiert hat – blenden wir die visuelle Qualität von Path Tracing einfach aus? Dass es sogar flüssig in dreistelligen FPS-Raten läuft? In 4K? Really? Wie wäre es stattdessen, sich einfach mal daran zu erfreuen, dass das heute möglich ist? Wieso muss immer in allem das Schlechte gesucht werden? Verstehe ich echt nicht.

Wenn du dir selbst das Leben schwer machen willst, indem du absichtlich moderne Features wie Frame Generation ignorierst, stur auf DLSS Quality beharrst – wo du, und da wette ich mit dir, im Blindtest bei bewegtem Bild und ohne 10x-Ranzoomen im Standbild eh keinen Unterschied sehen würdest – und dich dann über die angeblich nicht ausreichende Leistung einer 4090 echauffierst... dann kannst du das tun. Aber diese Meinung ist halt kein Maßstab.

Ich würde alle anderen Effekte in einem Spiel runterdrehen und DLSS auf niedrigere Stufe nehmen und Frame Generation immer einschalten, bevor ich Path Tracing ausschalte. Dazu ist der Unterschied einfach zu krass.

 

[Cleriker]

Schön, dass ihr euch da was einbildet gejesen zu haben, geschrieben habe ich nirgends, dass ich auf PT verzichten würde.
Ich, und das habe ich schon die letzten zwanzig Jahre hier geschrieben, würde immer lieber auf eine schnellere Karte warten, statt auf Bildqualität zu verzichten.
Warum muss ich Fragmente, Fehlfarben und Unschärfe in Kauf nehmen, nur um sofort spielen zu können? Denn davon scheint ihr beide ja auszugehen.

Wollt ihr mal versuchen euch auf das zu beziehen was jemand wirklich schreibt, statt euch was hin zu halluzinieren und dann darauf abzugehen? Wie wär's?

 

[Rollora]

Äh, Dir ist schon klar, dass RT nur Licht macht? Es verändert nichts an Kanten, Texturen und Oberflächen.

Äh nein. Bzw jein:
Traditionelles Rendern (Rasterizing): Du hast sowieso zuerstmal nur Kanten/Texturen/Oberflchen.
Und dann kommen 100 verschiedene simulierte Effekte dazu die oft "übereinander gelegt" werden.

Raytracing macht das alles in einem sehr aufwändigen Verfahren - in einem Zug.
Und macht es für Entwickler viel einfacher. Es ist im prinzip ein simpler Algorithmus der einen Strahl losschickt und der alle möglichen Oberlfächen berührt, dabei für realistisches Licht sorgt. Inklusive Reflektionen, Lichtbrechung etc.

Also vieles was Shader sehr aufwändig und mit vielerlei Tricks machen.

Dabei ist die aktuelle Form eine hybride Technologie. Aber Ray/Pathtracing überholt die alte Technologie (Rastern, also 100 Tricks aneinanderreihen) nun und es macht keinen Sinn noch lange in reines Rastern zu investieren.
Ray/Pathtracing ist nunmal die Zukunft

Und immer noch nur Licht und Reflexionen. Falsch? Du gibst Dir ja schon selbst die Antwort.
Wie Du schon sagst: "abhängig vom Material". Nichts, aber auch gar nichts verändert RT am Material, seinen Eigenschaften und deren Wirkung. Das muss erst alles definiert werden, bevor RT da realistisch wirken kann.
In älteren Titeln ist das oft noch nicht einmal ausreichend definiert.

Ja, aber das ist schnell erledigt. Du gibst einer Textur Reflexionseigenschaften eventuell noch Lichtbrechung.
Hingegen wenn du das alles deinen Shadern noch beibringen musst etc, musst du diese schreiben, definieren, du musst eigentlich überall Tricks anwenden. RT macht des in einem.

Btw. Materialeigenschaften, Albedo und Oberflächeneigenschaften werden auch in Light-Maps von Shadern, Bump-Mapping usw. bei Raster genutzt. Natürlich nicht so realistisch wie in RT mit Lichtbrechung, Krümmung, Diffuser Beleuchtung, Reflexion in Reflexion.

Du gibst dir selbst die Antwort. Ja, bei RT reicht es eben RT anzuwenden, sofern die Eigenschaften von Materialien definiert sind. Das ist übrigens vielfach einfacher als Shader zu schreiben sie zu platzieren, Lightmaps vorzuberechnen etc.

Aber braucht es das immer? Gerade bei so alten Retro-Titeln?

ja schon .Wenn man schon was uraltes (wir reden hier von einem Viertel Jahrhundert) modernisiert, dann doch am besten mit der besten verfügbaren Technik. Noch dazu da Max Payne mit seinem realistischen Look und Feel geglänzt hat, passt das viel besser als es jetzt irgendwie künstlich zu machen.

Wie gesagt, da gäbe es so einiges anderes, das man erst mal überarbeiten könnte und teilweise sogar muss, bevor selbst RT so richtig wirken kann.

So tragisch ist das gar nicht und macht schon viel die KI.
In 5 Jahren vielleicht sogar schon völlig stelbstständig, dass man im Editor die KI sitzen hat die einem da hilft.

Du hast ein mittelmäßiges Gemälde und rahmst das jetzt in einem teuren aufwendigen vergoldeten Barrock-Bilderrahmen. Wirkt auf die Entfernung hochwertig, macht das Gemälde aber nicht besser

ich schau mir lieber ein Mittelmäßiges Gemälde unter echtem LIcht an, als es mit künstlichem irgendwie zu probieren... verstehe den Vergleich nicht

 

[G4mest3r]

Äh nein. Bzw jein:Traditionelles Rendern (Rasterizing): Du hast sowieso zuerstmal nur Kanten/Texturen/Oberflchen.
Und dann kommen 100 verschiedene simulierte Effekte dazu die oft "übereinander gelegt" werden.

Raytracing macht das alles in einem sehr aufwändigen Verfahren - in einem Zug.
Und macht es für Entwickler viel einfacher. Es ist im prinzip ein simpler Algorithmus der einen Strahl losschickt und der alle möglichen Oberlfächen berührt, dabei für realistisches Licht sorgt. Inklusive Reflektionen, Lichtbrechung etc.

Also vieles was Shader sehr aufwändig und mit vielerlei Tricks machen.

Das ist mir alles bekannt.
Diese 100 (sind es genau hundert? Oder ungefähr oder eigentlich nur <30?) simulierten Effekte, gibt es nicht ohne Grund.
Sie stellen abstrahiert primitiv und >>sehr ressourcenschonend<< einen visuellen Zustand her, der ausreichend überzeugend ist.
(Btw. Shader machen es eben nicht "sehr aufwendig", sondern abstrahiert rechengünstig. Ja, man muss diese Shader alle Editieren und verwalten, aber die Berechnungen -Tricksereien- sind ja eben genau darum da: um es mit möglichst Ressourcenschonend umzusetzen.

Egal, wieviel physikalisch Korrekter und realistischer noch RT ist - wie due schon sagst: es ist ein sehr aufwendiges Verfahren (also aufwendig im Sinne von Rechenintensiv).
Daher ja auch die extremen Leistungseinbrüche und hohen Hardwareanforderungen.

Und mein Ding ist: solange die Hardware noch nicht an dem Punkt ist, dass das unbemerkt auf Durchschnittshardware fast einfach so nebenher mitläuft, bevorzuge ich die "günstigeren" anderen Tricksereien, die gut genug sind.
Besonders, wenn es andere Dinge gibt, die grafisch noch viel mehr ins Gewicht fallen, als ein paar Lichtstrahlen.

Es ist wie immer: man kann Optimierungsaufwand reinstecken und etwas sehr effektiv und ressourcenschonend machen, oder man ist bequem, ballert was hin und lässt die Hardware und den Kunden das Ressourcenproblem haben.
Man erkauft sich Bequemlichkeit vorne, durch Ressourcenverbrauch hinten.

Und noch mal zur Erinnerung: wir reden hier nicht von einem neuen Spiel - einer Grafikbombe, wo ich alle Register ziehe und das neueste State of the Art ausfahren möchte, das technisch möglich ist.
Wir reden von einem ALTEN Titel, der viel Überarbeitung an anderen Stellen viel dringender bräuchte, als rechenintensive Lichtspiele.

 

[Rollora]

Das ist mir alles bekannt.
Diese 100 (sind es genau hundert? Oder ungefähr oder eigentlich nur <30?) simulierten Effekte,

Es sind - je nachdem wie genau man es haben will 1 (globali Lichter Gen ein) oder viele.
Und am Ende nähert man sich dem Realismus mit viel Entwicklungsaufwand an, kommt aber niemals dorthin, wo man mit simplen "Raytracing an" hinkommt.

Egal, wieviel physikalisch Korrekter und realistischer noch RT ist - wie due schon sagst: es ist ein sehr aufwendiges Verfahren (also aufwendig im Sinne von Rechenintensiv).

Ja dann ist das halt so, über höhere Auflösungen, AA Modi etc jammert auch niemand mehr

Daher ja auch die extremen Leistungseinbrüche und hohen Hardwareanforderungen.

Und mein Ding ist: solange die Hardware noch nicht an dem Punkt ist, dass das unbemerkt auf Durchschnittshardware fast einfach so nebenher mitläuft, bevorzuge ich die "günstigeren" anderen Tricksereien, die gut genug sind.

Dann dürfte sich aber nur eine neue Grafik Technologie durchsetzen oder?

Besonders, wenn es andere Dinge gibt, die grafisch noch viel mehr ins Gewicht fallen, als ein paar Lichtstrahlen.

Beim modernen Detailgrad fällt mir Grad nicht viel ein, was einen noch größeren Unterschied macht als realitätsnahes Licht

Es ist wie immer: man kann Optimierungsaufwand reinstecken und etwas sehr effektiv und ressourcenschonend machen, oder man ist bequem, ballert was hin und lässt die Hardware und den Kunden das Ressourcenproblem haben.

Das Problem ist, dass schon vor Jahren klar war, dass um mit Rastern den Look von Raytracing zu erreichen inzwischen so viel Aufwand notwendig ist, dass RT eben schon teilweisen flotter ist.
Leider haben wir GPU Hersteller die zu lange auf Rastern gesetzt haben, sonst wäre die Entwicklung längst abgeschlossen

Man erkauft sich Bequemlichkeit vorne, durch Ressourcenverbrauch hinten.

Und besseren Look

Und noch mal zur Erinnerung: wir reden hier nicht von einem neuen Spiel - einer Grafikbombe, wo ich alle Register ziehe und das neueste State of the Art ausfahren möchte, das technisch möglich ist.

Dann einfach eine Mod installieren.
Wenn ich das ganze komplett modernisiert haben will ist 2026 das Rückständige Rasteriting Only nicht mehr Zeitgemäß

Wir reden von einem ALTEN Titel, der viel Überarbeitung an anderen Stellen viel dringender bräuchte, als rechenintensive Lichtspiele.

Geschmack ist halt unterschiedlich

 

[G4mest3r]

[...]

NOCH MAL! Es geht nicht um einen aktuellen Grafikkracher.

Es geht um ein altes Spiel, das dementsprechend alt aussieht und auf das Du jetzt tolles und performancehungriges Licht klatschst.

Es gibt glaube ich wichtigeres, um die Fassade aufzuwerten.


Das würde auch sehr schnell ersichtlich, wenn man die Spieler vor die Wahl stellte, 4k-Texturen, bessere Rag-dolls, Animationen und glattere Oberflächen zu haben, oder realistische Lichteffekte mit teurer Hardware und viel Rechenleistung...
Ich glaube, man würde sehr schnell sehen, was die meisten wählen würden: Preis/Leistung - den größten Effekt, mit dem kleineren Aufwand.
Ich behaupte, dass mehr Leute 4k-Textur-Mods runterladen, als RT-Mods.

 

[Rollora]

NOCH MAL! Es geht nicht um einen aktuellen Grafikkracher.

Es geht um ein altes Spiel, das dementsprechend alt aussieht und auf das Du jetzt tolles und performancehungriges Licht klatschst.

Es gibt glaube ich wichtigeres, um die Fassade aufzuwerten.


Das würde auch sehr schnell ersichtlich, wenn man die Spieler vor die Wahl stellte, 4k-Texturen, bessere Rag-dolls, Animationen und glattere Oberflächen zu haben, oder realistische Lichteffekte mit teurer Hardware und viel Rechenleistung...
Ich glaube, man würde sehr schnell sehen, was die meisten wählen würden: Preis/Leistung - den größten Effekt, mit dem kleineren Aufwand.
Ich behaupte, dass mehr Leute 4k-Textur-Mods runterladen, als RT-Mods.

Und warum nicht beides? 4K Texturmods gibts längst, was fehlt ist echte Beleuchtung in einem Spiel das schon vor 25 Jahren einen möglichst realistischen Look haben wollte.
Animationen sind mir völlig wumpe, aber falsches Licht finde ich inzwischen zum Kotzen,

 

[G4mest3r]

Und warum nicht beides? 4K Texturmods gibts längst, was fehlt ist echte Beleuchtung in einem Spiel das schon vor 25 Jahren einen möglichst realistischen Look haben wollte.
Animationen sind mir völlig wumpe, aber falsches Licht finde ich inzwischen zum Kotzen,

Weil es hier nicht um beides ging, sondern nur um den RT-Mod.

Natürlich kannst Du immer, wenn Du das Fundament optimiert und runderneuert hast, noch das Sahnehäubchen aufsetzen. Es macht nur kein Sinn, ein Sahnehäubchen aufzusetzen, wenn unten noch alles im Argen ist.

Und ganz ehrlich: soooo realistisch war der Look jetzt auch nicht. So eckige und kantige Körper, Gesichter usw.
Das war damals noch toll, im Vergleich was es davor gab. Aber "realistisch" würde ich heute dafür nicht mehr in den Mund nehmen

 

[Rollora]

Weil es hier nicht um beides ging, sondern nur um den RT-Mod.

Natürlich kannst Du immer, wenn Du das Fundament optimiert und runderneuert hast, noch das Sahnehäubchen aufsetzen. Es macht nur kein Sinn, ein Sahnehäubchen aufzusetzen, wenn unten noch alles im Argen ist.

Und ganz ehrlich: soooo realistisch war der Look jetzt auch nicht. So eckige und kantige Körper, Gesichter usw.
Das war damals noch toll, im Vergleich was es davor gab. Aber "realistisch" würde ich heute dafür nicht mehr in den Mund nehmen

Ich schrieb ja auch von damals, und am ehesten entspricht nunmal realistischeres Licht einem Update, die Animationen waren damals schon Hölzern

 

[_Amelie_]

Ich finde es geradezu wild, wie hier immer noch argumentiert wird, dass realistische Beleuchtung so unwichtig sein kann und Texturen so viel wichtiger. Texturen sind nicht erwähnenswert, wenn man das mit guter Beleuchtung vergleicht. Ich kann mir das hier wirklich nur noch so erklären, dass Personen gute Beleuchtung in Bewegung noch nie gesehen haben oder diese nicht realisieren. Ich sage das schon seit Jahren, seit ich das erste Mal Reshade RTGI genutzt habe und mir auf einmal ein Licht aufging im wahrsten Sinne des Wortes. Ich hatte damals eine Radeon und habe dann erst verstanden, was mir entgeht. Hab die nicht mal verkauft, sondern direkt eine 4080 Super geholt. Eine Offenbarung war das, dann Cyberpunk mit Path Tracing zu spielen. Ganz anderes Game.

Und so transformiert gute Beleuchtung Games. Wieso gibt es wohl diese Path-Tracing-Mods? Gerade weil es so einen Unterschied macht.

 

[G4mest3r]

@Rollora

Ach, guck mal! Das könnte Dir gefallen. Genau passend zum Thema:
Sehr down-to-earth Zusammenfassung und Fact-Check der zeitlichen Abläufe und aktuellen Situation durch Hardware Unboxed [YoutubeVideo "Was Ray Tracing a Scam?"]

Eingebundener Inhalt

youtube.com/watch/?v=nzen0AvINrI

An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Alle externen Inhalte laden Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.
Für mehr Informationen besuche die Datenschutz-Seite.

Und erleichtert es die Spielentwicklung? Erlaubt es, den Fokus auf Qualität und andere Features zu setzen, bei gleichzeitiger Eindämmung der Entwicklungskosten? - Wie sieht es aktuell um dieses unbewiesene Postulat aus?

 

[Rollora]

@Rollora

Ach, guck mal! Das könnte Dir gefallen. Genau passend zum Thema:
Sehr down-to-earth Zusammenfassung und Fact-Check der zeitlichen Abläufe und aktuellen Situation durch Hardware Unboxed [YoutubeVideo "Was Ray Tracing a Scam?"]

Eingebundener Inhalt

youtube.com/watch/?v=nzen0AvINrI

An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Alle externen Inhalte laden Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.
Für mehr Informationen besuche die Datenschutz-Seite.

Und erleichtert es die Spielentwicklung? Erlaubt es, den Fokus auf Qualität und andere Features zu setzen, bei gleichzeitiger Eindämmung der Entwicklungskosten? - Wie sieht es aktuell um dieses unbewiesene Postulat aus?

Ich schaue keine Videos wenn es geschrieben ginge, aber, dass Raytracing die Spieleentwicklung erleichtern würde (müsste man nicht Rücksicht auf pures Tastern nehmen) liegt auf der Hand.
Das ist in etwa so als würde man sagen Rechnen außerhalb des Zahlenraum 10 ist kompliziert und unnötig. Ersteres stimmt schon erfüllt halt einen höheren Zweck.
Man kann sich natürlich gegen überlegene, aber teurere (was die Berechnung betrifft) Technik wehren, keine Frage

Raytracing kostet mehr Leistung, erfüllt halt aber mehrere Schritte in einem.
Jeder normal denkenden Mensch versteht, dass es sinnvoll ist, Schritte abgenommen zu bekommen. Außer man ist abhängig von Klicks und Desinformation, dann könnte ich mir vorstellen ein Video vom Gegenteil zu machen. Ich schaue mir morgen an ob ich Recht hab.

Edit: Oh wow, ouch jetzt hab ich mich doch erniedrigt den Clickbait zu schauen. Bzw kurz durchzuzappen. Das hält man ja im Hirn nicht aus: natürlich wird eigentlich nicht Raytracing technologisch beleuctet, sondern die schlechten Beispiele der Implementierung und es wird darauf eingegangen, dass nicht-raytracing oft performanter ist und bei gleicher performance besser aussieht. Typischer ragebait eigentlich, entweder versteht der Redakteur die Technologie nicht, oder er versteht sie wohl, will aber eben Klicks. Und genau auf sowas fallen die Leute dann rein.
In einigen Jahren wenn dann alles Raytraced ist wird man halt sagen "ja JETZT ist es überlegen, damals war es nicht". Was dumm ist... aber was will man dagegen tun.
Das ist wie gegen die Trump anhänger reden oder so. Da helfen auch Fakten und Perspektiven nix.
Sorry aber: du wirst am Ende nicht drum rumkommen: entweder viele Tricks die sich der Realität annähern, oder einein einfachen, rechenintensiven.

 

[G4mest3r]

Ich schaue keine Videos wenn es geschrieben ginge, aber, dass Raytracing die Spieleentwicklung erleichtern würde (müsste man nicht Rücksicht auf pures Tastern nehmen) liegt auf der Hand.
Das ist in etwa so als würde man sagen Rechnen außerhalb des Zahlenraum 10 ist kompliziert und unnötig. Ersteres stimmt schon erfüllt halt einen höheren Zweck.
Man kann sich natürlich gegen überlegene, aber teurere (was die Berechnung betrifft) Technik wehren, keine Frage

Raytracing kostet mehr Leistung, erfüllt halt aber mehrere Schritte in einem.
Jeder normal denkenden Mensch versteht, dass es sinnvoll ist, Schritte abgenommen zu bekommen. Außer man ist abhängig von Klicks und Desinformation, dann könnte ich mir vorstellen ein Video vom Gegenteil zu machen. Ich schaue mir morgen an ob ich Recht hab

Du verstehst das die ganze Zeit falsch.
Ich wehre mich nicht per se gegen die Technik an sich.
Ich wehre mich gegen den unsinnigen Einsatz vor allen anderen sinnvolleren Verbesserungen.
Darum geht es die ganze Zeit.

Solltest Du tatsächlich das Video mit guten kritischen Überlegungen schauen (Hardware Unboxed ist ja nun nicht irgendwer unbekanntes oder unseriöses), behalte mal im Hinterkopf:
"wenn Raytracing doch die Spielentwicklung erleichtert, dann wird sie ja auch wieder günstiger zu bewerkstelligen und ermöglicht, den Preis wieder attraktiv zu gestalten".

Sehen wir das? Gibt es belege dafür?


Btw., Performance sollte immer ein Thema sein. All diese extra-Schritte entstanden aus einem Grund: weil das Performance-budget nun mal beschränkt ist, und es Sinn macht, extra-Aufwand zu betreiben.
(Oder ist Dave'S Garage vom pensionierten MS-Ingenieur Dave Plummer etwa auch Desinformation?
Zur Not könnte ich Dir die Transcripts schicken - kannst aber auch selber abrufen und lesen, wenn "Video-hören" zu viel ist )

Spoiler: Transcript: "Was Ray Tracing a Scam?" | Hardware Unboxed

I've been testing and reviewing PC
hardware for 27 years now, and I still
remember testing the GeForce 256 SDR and
DDR graphics cards for the first time.
Since then, I have tested a lot of GPUs.
I've played a lot of games, and it's
been a lot of fun. I've seen many new
technologies come and go, but perhaps
the most controversial of which has been
hardware accelerated ray tracing, a
technology that promised to
revolutionize gaming eight years ago
now. So based on everything we know to
this point, was RA tracing actually a
scam?
Back in 2018, Avidia CEO Jensen Wong
took to the stage for an almost 2-hour
presentation where he repeatedly
emphasized that with ray tracing,
you're going to see a lot of writing
about this in the future.
Developers no longer needed to spend
months faking lights with shadow maps or
reflection probes. By applying the laws
of physics, the lighting just works. He
went on to claim that the GeForce 20
series offered the biggest generational
leap in the history of computer
graphics.
Crushing Pascal and best of all, pricing
was set at just $4.99 for the RTX 2070
and models were set to be on shelves
everywhere September 20th. Ultimately,
the claim was that these GPUs were must
buys. You must experience ray tracing.
you wouldn't want to play games without
it. The problem is most of that wasn't
true. To date, ray tracing hasn't
transformed gaming and it's my opinion
that GeForce 20 series owners were sold
array tracing live. I'm not even sure if
we can say that most games released
since then even support ray tracing. And
for the ones that do, the vast majority
of them only enable it as an optional
feature. The truth is I was never really
that sold on the ray tracing dream. When
it comes to promised technologies, I'm
more of a I'll believe it when I see it
kind of reviewer. And with ray tracing,
I really did need to see it. And then
having seen it, I'm still yet to believe
it. In the case of the GeForce 20
series, it simply was not powerful
enough to properly utilize real-time ray
tracing, leading to underwhelming RT
effects and performance. The game
support list was also shockingly short.
12 months after the initial release, we
could point to just two games where you
might want to enable ray tracing. Those
titles being Metro Exodus and Control.
There were a few other games with ray
tracing at the time, but we felt those
titles were extremely underwhelming,
like the noisy and largely pointless RT
reflections in Battlefield 5, for
example. Now, although the rayraced
effects were quite impressive in those
two best case examples, the performance
unfortunately was very underwhelming. If
you wanted to play at over 60fps, you'd
need to lower the resolution to 1080p,
which Nvidia tried to play off as
perfectly fine, pointing to the Steam
hardware survey data that showed most
gamers use 1080p displays. We found that
response unacceptable though, especially
given a GPU like the RTX 2060 Super,
which was now available at the time we
received that response from Nvidia.
Well, that GPU was for the most part a
1440p product. When it came to ray
tracing though, 1440p was so far removed
from the realms of possibility that no
one would ever consider it. Even at
1080p with medium levels of ray tracing
enabled in a game like Control,
performance fell well short of 60fps and
at a cost of $400 US. I think most
gamers would expect at least 60fps at
1440p. And even the more expensive
models like the $500 RTX 2080, they
weren't even close to delivering 60 fps
at 1440p with ray tracing enabled.
Nvidia's other response to our criticism
at the time was to simply turn down
graphic quality settings or use DLSS.
However, we failed to understand why
anyone would turn down settings just to
enable ray tracing. After all, ray
tracing was heavily touted by Nvidia as
a premium graphics feature, a sort of
cherry on top, if you will. So, you
would already be playing with higher
ultra quality settings and then turn ray
tracing on to take things to that next
level. Surely gamers don't want to use
medium or low presets and then enable
ray tracing. That seems to make very
little sense. As for enabling DLSS, that
will improve your frame rate with ray
tracing enabled, but it also improves
your frame rate with ray tracing
disabled. It's also well worth noting
that back then when we were talking
about these responses from Nvidia, they
were talking about DLSS1, which put
simply just it sucked. It was really,
really bad. The DLSS version uh that we
sort of know today, that wasn't released
until 18 months after the RTX 20 series,
and even then, it was much longer until
DLSS 2.0 was widely available.
Not only that, but as I alluded to a
moment ago, upscaling doesn't
fundamentally close the performance gap.
So gamers had to pick between
significantly higher performance or ray
tracing. And that's not to mention the
visual artifacts caused by DLSS that
were more noticeable at the lower
resolutions that you were forced to use
when using ray tracing. And in fact, we
strongly recommended avoiding using DLSS
at 1080p back then, as the results just
weren't good. So, in summary, a year
after release, Nvidia could really only
point to two games that were released
with ray tracing support and RTX 20
series owners should or at least
consider playing them with the feature
enabled. And those two games were again
Metro Exodus and Control. The caveat
here being that most will have to play
at 1080p and even then 60 fps will be
difficult to achieve without using a
medium quality settings which again we'd
argue defeats the purpose of using ray
tracing to begin with. At this point, it
started to become very clear to us that
heavily weighing review recommendations
on ray tracing support and performance
was a poor choice given many of the most
popular games didn't actually benefit
from the inclusion of ray tracing. And
this first became evident with Call of
Duty Modern Warfare, which received ray
traced shadows. Now look, this was a
nice enough feature for the single
player campaign, but for the multiplayer
portion of the game, which is what keeps
players coming back and keeps them
engaged long term, ray tracing was
completely worthless and not something
many gamers would enable. Ray tracing
also came to Fortnite, a game that can
look visually spectacular, but also
never does regardless of your hardware.
And this is because the best way to
actually play the game is using the
popular performance mode. That's sort of
a stripped down quality mode designed to
maximize performance and visibility. So
while RA tracing certainly could offer
an additional layer of immersion for
single player storydriven games for
multiplayer and in particular fast-paced
shooters, it was pretty worthless. In
fact, it was it was absolutely
worthless. And it's not like the GeForce
20 series GPUs were going to get faster
and better at ray tracing over time. If
they couldn't run the early ray traced
effects at the launch of the technology,
what hope did they have of running
better, higher quality effects in games
released years later? And that has
certainly played out at this point as
even the highest end GPUs from the RTX
20 and even the 30 series will struggle
with effects like modern path tracing.
So, for these reasons and more, I
personally wasn't too excited about ray
tracing. And look, I was perfectly
willing to accept that ray tracing was
the future of gaming. So, the r/vidia
fans and myself at least agreed on that
much. But cramming our reviews and
recommendations full of ray trace data
wasn't something I was prepared to do,
despite Nvidia's best efforts to get me
to do just that. Now, you might be
asking, why wasn't I willing to drink
the Kool-Aid? and jump aboard the ray
tracing train. Nvidia fans will be quick
to say it's because we favor AMD. We're
Radon shills here at Harbor Unboxed. But
if you're willing to do just some basic
research, you'll discover that that
narrative doesn't make sense. We
regularly reference the superiority of
Nvidia GPUs, claiming AMD needs to
heavily undercut Nvidia's pricing in
order to compete, and that's something
we very much do believe. We also
criticize both AMD and Nvidia when it's
warranted.
The fact is, we simply don't care for
either of these brands, and there's
plenty of supporting evidence for that
claim. Now, the real reason for why I
wasn't willing to go all in on the ray
tracing hype is because, as I said at
the start of this video, I've been doing
this for a very long time. I've been
doing it long enough to see through the
And I knew what Nvidia was
serving up with the RTX 20 series was
mostly Those GPUs were never
going to do any meaningful levels of ray
tracing. And to this date, they
certainly haven't. And look, while some
GeForce RTX 2060 owners were content
playing a game like Control at 1080p
with medium settings and medium RT
enabled at 40 FPS, that was a heavily
compromised experience. And it was not
what Nvidia promised you. In fact, it is
worth noting that Tim made a video about
2 years ago now looking at how the RTX
2060 aged after 6 years of ray tracing
development. And spoiler alert, the
results were not good. And we did our
best to make it work. But even at 1080p
in a game like Ratchet and Clank Rift
Apart, using the lowest possible quality
preset, once we enabled ray tracing, the
RTX 2060 fell below 60fps.
And that was with DLSS quality upscaling
enabled at again 1080p. So, not a great
experience. Anyway, if you want to
examine the results in that video more
closely, I'll provide a link in the
video description. So, go check that
out. But getting away from these single
player games like Control and Metro
Exodus, for me personally, ray tracing
had a much bigger problem even back in
2019. And it's one that it struggled
with to this very day. You see, for a
lot of games, ray tracing is pointless.
It adds nothing of value, and for that
reason, you simply wouldn't use it. And
many gamers don't. Part of this is
because of the performance, but also
part of it is because of what it changes
visually. In fact, it's not even just
about a type of game, but also a type of
gamer. For example, if I was to play
Shadow of the Tomb Raider, which I did,
by the way, quite a good game, I don't
want to be playing it at 1080p on an RTX
2060 at just over 50 fps with ray trace
shadows. I want to be ideally playing it
at over 120 fps at 1440p. In order to
achieve that level of performance, I
would simply reduce quality settings to
hit my targeted frame rate. And only if
uh at the targeted frame rate or perhaps
above it would I then increase the
visual quality settings. But make no
mistake, the priority would always be
the frame rate first, not the visuals.
Of course, I understand this isn't all
gamers. Some of you are happy gaming at
lower frame rates, 60fps or less, and
you'll prioritize the visuals. That's
perfectly fine. But when it comes to
multiplayer games, particularly
fast-paced shooters, the majority of
players prioritize the frame rate. And
it's here that ray tracing has proven to
be useless even in 2026. In fact, 2
years ago now, we pled some data with
viewers asking what their ideal target
frame rate was for shooters, and the
majority voted more than 140 fps. and I
myself fall into that category. Not only
that, but 88% of those of you who voted
voted for a frame rate target of at
least 100 FPS. And that's a pretty
difficult frame rate to achieve in the
majority of titles supporting ray
tracing. Still, I think it was
reasonable that way back in 2018 that
you might have imagined by now, 2026,
all the latest online shooters would be
using some form of road tracing by
default. it would just be something that
GPUs have supported for at least 5 years
now. So, game engines would naturally
support it. But that isn't the case at
all. It's still very much an optional
feature. And for that reason, most
gamers are opting not to use it. No one
who wants to win is turning on ra
tracing in a game like Fortnite, for
example. Not only is the performance
horrendously poor, but it makes spotting
enemy players extremely difficult. So,
you just end up handicapped on two
fronts, latency and visuals. There is no
denying that the hardwarebased ray
tracing in Fortnite looks incredible. It
It really does. And I much prefer how
the game looks with it enabled. So,
don't get me wrong there. It does look
fantastic. However, the performance
isn't good and visibility is horrible
when compared to the more competitive
performance mode. And this makes the
high quality settings used when enabling
hardware ray tracing very difficult to
play. And as a result, it places anyone
using the highest quality settings in
Fortnite at a serious disadvantage.
Here's some quick examples from some of
the gameplay I recorded for this video.
In this example, I'm in my own builds
editing out to see if there are any
players around me. As you can see, the
hardware RT configuration looks great,
but it's also by far the most difficult
to spot enemy players. Basically, any
player 100 meters or further away is
impossible to spot. And we see when
sticking with the epic quality settings,
but using ambient occlusion and screen
space reflections, it is much easier to
see players at distance.
But by far best of all for visibility,
is the performance mode, which yeah,
again, it looks crap visually. It was
quite an adjustment for me to start
using this, but in terms of
competitiveness, it provides not only
the best FPS performance, but by far the
best visibility.
In this next example, I'm box fighting
in the builds, and with hardware ray
tracing enabled, it's incredibly dark.
And if we pause the video here, as the
player is breaking through my wall with
the game maxed out, I can't really tell
where the player is. And it's much the
same problem when using ambient
occlusion and screen space reflections
with the epic quality settings. Though
the image is overall a bit brighter,
which does improve visibility a little
bit. But when we use the performance
mode, it's a massive competitive
advantage. Here I can already see the
player allowing me to take aim much
sooner hitting my pump shot for 170 to
the head. If we rewind, this is what I
would have been dealing with had I
played the game maxed out. There's just
crap everywhere. And as you can see,
hitting that shot would have been
considerably more difficult. And in this
example, you can see just how much more
difficult it is to see the player
through a simple window edit with the
graphic quality settings maxed out when
compared to the performance mode.
Zooming in provides a very clear example
of just how much more difficult it is to
play Fortnite using highquality
settings. The visible top half of the
enemy player is completely shadowed with
the graphic settings maxed out, while
the performance mode provides a clear
view, allowing me to easily hit my shot
and then reset the wall, hold the wall
to block the enemy shot, and then
re-edit it to eliminate them. Still, the
difference between these quality
settings isn't always night and day. In
this passage of play, the maxed out
quality settings don't really provide
that much of a disadvantage. Though
having said that, the much lower frame
rate would have made hitting this
perfect flick shot that much more
difficult. Having played competitive
shooters and real-time strategy games
for the better part of three decades
now, I knew RA tracing wasn't going to
be all that was promised, at least not
for decades after initial release. And
there's simply no getting around the
fact that this isn't stuff that I've
just made up, stuff that I personally
believe. It is a widely held belief when
asking our viewers if they prioritize
frame rate or graphical quality for
multiplayer games like Counterstrike,
Apex Legends, Valerant, Fortnite, Call
of Duty, and Battlefield. As for some of
the examples, the overwhelming majority
voted for FPS. And supporting that data,
sort of personal stories, but I'll add
them anyway. Bit of anecdotal evidence.
I can't recall the last time someone who
plays these sort of games said to me,
"Steve, I want to upgrade my PC so I can
increase the visuals in Call of Duty."
That's not really something that's ever
happened. Pretty much every time it's
something like, "Steve, what do I need
to upgrade so that I can comfortably sit
above 200 FPS in a game like Fortnite?
Maybe using the performance mode or, you
know, whatever game it happens to be
that they're playing." So given all of
that, a feature that heavily reduces
performance while also making it more
difficult to spot enemy players simply
doesn't make sense. And I'm not saying
ray tracing makes it more difficult to
spot enemy players in all games. Some of
the examples I looked at it does. That's
just one part of it. It's not
necessarily the rule, but what it does
do is heavily reduce performance. And
that pretty much is a rule. Now, I am
sure at some point in the future this
will change. And by default, games, even
the multiplayer shooters that I've been
talking of, they'll use ray tracing as
it, you know, won't be optional and
therefore you simply can't just turn it
off in order to gain a performance
advantage. There'll be a a baseline
there just like there's a baseline for
games today that generally speaking
makes them look better than games from
15 years ago. I think that's safe to
say. Again though, you might have
expected that future to be now, 2026,
because we've been hearing that ray
tracing is the future for like 8 years
now. But it seems like that future is
still at least, I don't know, maybe
another 8 years away. But even for you
single player gamers, it's been an
underwhelming journey so far. I think
it's safe to say to date, there's really
not been that many good ray tracing
titles that you can point at and even
less that you can call truly
transformative. And worse still of the
truly transformative examples we have,
they all require high-end GPUs.
Seriously high-end GPUs, mind you, like
an RTX 4090 or the 5090. So, it's far
from a mainstream technology. You're
not, for example, enjoying path tracing
and Cyberpunk on an RTX 5060 Ti. Not in
any practical sense, anyway. So given
all of that, it's not particularly
shocking that just 2 years ago now, we
asked the simple question, when
available, do you play with RA tracing
enabled? Of the 50,000 people that
voted, just 15% of them said they do,
and they do so while using the maximum
settings. So I guess there's your
high-end representation right there,
your 4090 and 5090 owners. Another 7%
said they enable ray tracing with the
medium to low settings. And then another
26% said they sometimes use ray tracing,
sometimes they don't. Then we had 52% of
all the people who voted saying they
don't use any ray tracing at all, citing
no noticeable visual improvements or the
performance it is simply too large to
justify using it. While piecing this
video together, I did decide to recreate
that 2-year-old poll to see if the
sentiment from gamers had changed.
Unfortunately though, we can no longer
create polls with five options. end
certification is even affecting the
YouTube polls. Anyway, I just decided to
roll the no options into a single
category. So, that's the change we've
had to make there. And what's
interesting is the yes maximum RT
settings percentage is still 15%. While
7% still voted yes, but using the medium
to low RTFX, while the majority voted
that they use RT in some games, but not
others. And then the next largest voter
base said that no, it's not worth it.
they don't use ray tracing. So even
after all of this time, we can group
nearly 80% of all gamers into the they
sometimes use ray tracing or not at all
category. And that is a shocking
statistic for a technology that 8 years
ago now was set to revolutionize gaming
according to Nvidia. And the reality is
for a lot of single player gamers is
they just want to enjoy the story and
the gameplay of the game that they're
trying to play. Having high quality
visuals, you know, sure it's nice. It
can add to the experience, but much of
the enjoyment comes from the actual game
play. So, if enabling ray tracing makes
the game harder to run, outputting a
lower FPS, well, that makes the gaming
experience worse. It's not going to be a
winning feature.
And this ties into a lot of what we're
seeing with modern games. With GPU so
expensive and upgrades out of reach,
many gamers just want the titles they're
interested in to run well on their
hardware. There's a growing sentiment
that game visuals have peaked. We often
see comments saying that they can't
really tell the difference between RT on
and off and that games don't look
substantially better today with fancy
features like ray tracing than they did
8 years ago before the technology was
first released. That's in direct
contradiction to what Jensen promised
all those years ago. How could ray
tracing truly be a must-have technology
that you should spend more on your GPU
for if a sizable portion of gamers don't
think the visual upgrade is noticeable
enough to justify the performance hit?
And doesn't that marketing speak now
sound pretty questionable when this is
the state of ray tracing nearly 8 years
later? Where is that promised future? At
some point, ray tracing will be a
dominant feature that all gamers can
enjoy using. But it feels like we've
been saying that a lot. It's always
about the future, not about the now.
This is where gamers that specifically
bought a GPU to use ray tracing
basically got scammed. The early RTX
enabled hardware is not powerful enough
to play modern ray tracing games. And
the games that were available during the
card's lifespan, they're extremely
underwhelming. a couple of tech demo
type experiences here and there, but
mostly those GPUs were used for regular
rolled rasterization.
If you happen to have bought an RT
enabled GPU for multiplayer gaming,
you've gotten burned especially hard.
None of today's popular multiplayer
titles are best played with RT enabled.
It hurts performance. It makes the game
harder. And there's no clear path to a
future where ray tracing even makes
sense in a multiplayer title. developers
have spent the early parts of the ray
tracing era getting their games to work
on as many potato quality GPUs as
possible to maximize sales and the
player base rather than bothering with
high-end visual features. And then for
single player games, yeah, ray tracing
can be a nice addition if you own a
high-end GPU, but for the normies out
there with mid-range hardware, if
anything, the push to integrate ray
tracing has made games harder to run for
those PC gamers. And in some cases, it's
done so with no clear benefits,
especially if gameplay is the priority.
So, has it made these games easier to
develop? Well, all I'm seeing are
development costs go through the roof,
not the other way around. Unfortunately,
gaming seems to have become little more
than a battleground where companies like
Nvidia do their best to leverage
technologies to their own advantage
rather than the advantage of their
customers who used to be gamers before
they became AI data centers. So, yeah,
that's been pretty disappointing to
watch over the years, but it is what it
is. Anyway, I think I'll end the video
there. If you enjoyed it, you know what
to do. Subscribe for more content. We
also have the join button or Patreon if
you want to support the channel and get
access to some more Harbor Box goodness
like monthly live streams, behind the
scenes content, Q&A stuff. There's
things. Check it out if you're
interested. If not, perfectly fine. And
I would like to thank you for watching
this video. I'm your host, Steve. See
you again next time.

Spoiler: Transcript: "Why your NEW computer is SLOWER than your OLD computer" | Dave's Garage (Dave Plummer)

Hey, I'm Dave. Welcome to my shop. I
want to start today with a slightly
uncomfortable thought that the machine
sitting on your desk right now is so
absurdly powerful compared to what we
had in the 1990s that if you could
somehow send it back in time, people
would assume it came from a government
lab or possibly a UFO. Dozens of cores,
gigabytes upon gigabytes of RAM, storage
so fast it would have looked like
sorcery. GPUs that can brute force
scenes in real time that we used to fake
with big render farms.
Yet, there is a very decent chance that
this miracle machine of yours takes
longer to open a Discord window than an
ordinary 486 used to take to boot,
launch its editor, and let you get
actual work done. And that ought to
bother us. Not because this is going to
be one of those sepia tone nostalgia
rambles where we all pretend that 1994
was a golden age and nobody's sound card
drivers ever exploded. They exploded
constantly. Old software had bugs,
crashes, installer madness, security
holes that you could sail a barge
through, and user interfaces that
occasionally felt like they'd been
designed by a committee of staplers. I'm
not asking to go back. I, for one, do
not want to relive cooperative
multitasking, config.cis, and whatever
dark pact your printer driver had made
with the devil. But there was one thing
that old software got right, and it got
it right because it had absolutely no
choice. It respected the machine, and by
extension, it respected your time. Back
then, performance wasn't a nice extra.
It wasn't the final polish pass. It
wasn't a thing you worried about after
you shipped version one and the one-star
review started landing like mortar
rounds. It was the job. Memory had a
budget. Startup time had a budget. Disc
footprint had a budget. CPU usage had a
budget. If your feature blew the budget,
then your feature did not ship or
something else got cut or you stayed
late and made it smaller, faster, or
simpler until it behaved. There wasn't
this casual assumption that hardware
would float all the boats. Back then,
hardware was the ocean. It was trying to
drown you every day. And working that
way changes the way you think. If you've
only ever built software and machines
with essentially infinite headroom by
comparison, it can be hard to explain
just how intimate the relationship used
to be between the code and the hardware.
Say what you will about Gates and Allen,
but the reality is that they still
managed to fit a fully featured basic
interpreter into 8K. Why 8K? Because
they didn't have 12K. It's really that
simple. It's like the old Monty Python
song.
And so developers became intimately
familiar with the landscape of living
with less of everything that you
actually wanted. And it wasn't just RAM
because CPUs were thousands of times
slower. A page fault wasn't some
abstract systems term. It was a thing
that you actually felt. A cache miss
wasn't academic. It was a difference
between smooth and sticky. A memory
allocation inside the wrong loop was not
probably fine. It was a stutter on the
screen or a disc thrash or worse a
support call. You learn to care about
locality, about allocation patterns,
about avoiding needless abstraction and
hot paths, about not parsing the same
thing twice, about not copying buffers
around just because the architecture
diagram looked cleaner that way. You
learned in short that every line of code
has mass of some kind. And here's the
really important part. When the hardware
got faster, we should have kept that
discipline and used the extra headroom
to make software richer, more
responsive, more robust, more
delightful. Fast hardware should have
brought us excellence. Instead, in a lot
of cases, it brought us permission to
waste it. And that's the plot twist
because modern software is not slow
mainly because modern programmers are
suddenly dumb. It's a comforting little
myth for us old guys. But like many
comforting myths, it just isn't true.
Today's developers are working with
bigger systems, nastier threat models,
more concurrency, more platforms, more
accessibility requirements, more
internationalization, more networking,
more legal and privacy and compliance
baggage. The world is just a lot more
complicated. The problem is not that
engineers got worse. The problem is that
our incentives got worse, our
constraints got looser, and our
standards quietly slid from excellent to
acceptable. And once you notice that,
you start seeing the same pattern
everywhere. The first big change for the
worse is abstraction without cost
accounting. Now, I like abstractions.
I'm not one of those maniacs who thinks
everybody should write everything in raw
wind32 and hand rule link list by candle
light. I mean, yeah, that's how I wrote
task manager, but there's a time and a
place for everything. Abstractions are
how actual civilization works. The right
abstraction can make an entire class of
bugs disappear and can let a small team
build something that once required a
small army. That's all goodness. But the
dirty little secret is that abstractions
are never free. They hide complexity
from the programmer by moving it
elsewhere. And that somewhere else is
usually your CPU or your memory
subsystem, your battery or your storage
or your network. So now you click on a
simple little utility and what actually
happens is that an auto updator, a
telemetry pipeline, a web rendering
engine, a JavaScript runtime, a package
ecosystem the size of Belgium, probably
a sandbox layer, a GPU compositor, a
sync client notification broker, and a
framework that itself depends on six
other frameworks because somebody needed
a fancier drop-own menu back in 2021.
Every layer made sense to somebody in
isolation. Collectively though, they
form a kind of performance sedimentary
rock and then we all stand around
puzzled that the app needs 800 megabytes
of RAM to display three text fields in a
button. The old discipline was that if
you wanted to add a new layer, you had
to understand and feel the cost. The new
habit is that when you add a layer, you
assume that somebody else's hardware
department will eat that bill. And
that's fine until the bill reaches the
user. And that leads to the next
deterioration, business incentives. Old
commercial software absolutely cared
about revenue, but it sort of lived or
died based on fit or finish. If your
word processor felt laggy, or if your
spreadsheet ate too much memory, if your
graphics package took forever to paint
the screen, people noticed immediately
because the product lived on the desktop
and the experience was the product.
Today, an awful lot of software sold on
a different basis. Recurring
subscriptions, monthly active users,
engagement, feature velocity, crowd
attachment, cross-ell opportunities,
telemetry completeness, experimentation,
throughput. You can practically hear
applause for them adding new
capabilities, but nobody gets a standing
ovation for cutting startup time in half
unless it was so bad before that it
threatened to churn the user base. And
so the organization learns what to
reward. If feature work gets promotions
and performance work gets a polite nod
in the retrospective, you will get
features and not performance. If teams
are measured on story points closed and
not regressions prevented, you will get
motion and not refinement. If nobody
owns endtoend responsiveness because one
team owns a shell and another owns the
back end and another owns the o layer
and another owns the metrics client and
another owns the experiment framework,
then nobody really owns the waiting
time. In the end, the user just
experiences it as the app feels big and
heavy, which is one of those devastating
phrases that doesn't map neatly to any
one backlog item and therefore gets
neglected for years. We have in a lot of
places lowered the bar from making the
experience excellent to making it just
not awful. Not this is fast, this is
elegant, not this opens instantly and
just gets out of my way. Just well, it
doesn't suck on the laptop once it's
warmed up. And that's not a standard.
That's just an apology with a budget
attached. Now, once you stop demanding
excellence, another skill begins to
atrophy, and that's whole system
understanding. Back in the day, if you
were working close to the metal, you had
to know where the time was going. Even
in a system utility like task manager,
you didn't get to just shrug and say
that MFC probably handled it. You had to
know if you were allocationheavy,
branchy, IO bound, memory bound,
painting too often, invalidating too
much of the window, copying data one
time too many, or doing work on the UI
thread that had no earthly business
being there. And a lot of these
instincts came from necessity, but they
were skills because at the time on the
hardware of the day, they actually
mattered. For example, the reason that
the Windows 95 clock doesn't show you
seconds was to avoid paging in the code
that painted that once per second
because somebody instrumented, tested,
and actually measured it and discovered
that it was material to the RAM pressure
on the base system. Windows 95 had a
severe RAM budget, and it was another
case of every bite being sacred. And so,
no seconds for you. Today, many teams
can successfully compose services, wire
APIs together, stand up their CI
pipelines, and deploy globally without
having much intuition at all about cache
behavior, branch prediction,
vectorization, allocator pressure, wire
format, bloat, n plus1 query patterns,
or why that innocent looking JSON
transformation suddenly turned a fast
request path into an interpretive dance
number. And again, this is not because
they're lazy or stupid. It's because the
industry stopped consistently teaching
and rewarding those instincts except in
a few very specialized corners. We
taught the people how to ship. We did
not always teach them how to make the
machine sing. And if that loss of
systems literacy were the only problem,
maybe veteran code reviewers could catch
it. But modern software has another
trick up its sleeve. Dependency
explosions. Software today is often more
assembled than it is written. You want a
date picker, a markdown parser, a chart
control, a logging framework, a state
container, an HTTP client, a theme
engine, and a build plugin. And before
launch, you've imported enough third
party code to recreate a minor empire.
Some of that is sensible. Reinventing
everything yourself is not a badge of
honor. But there used to be a quiet
assumption that the dependency had to
justify itself. Now the default is often
the reverse. pull it in first, worry
about it later. Which means you're
picking up not just functionality, but
also startup costs, memory use, security
exposure, update churn,
incompatibilities, and entire nested
dependency trees that you'll never fully
understand. Old software can be too
monolithic. Modern software can be way
too porous. Somewhere between those
extremes lies software that is composed
carefully, where a dependency is treated
like a liability until proven useful. We
just don't do enough of that. And then
just as all these habits have become
normal, along the way comes AI with a
can of gasoline. Now, I'm not anti-AII.
I think AI is going to be super useful
in software development. And in some
areas, it already is. It's good at
scaffolding, at wrote transformations,
at test generation, at surfacing
boilerplate, at documentation drafts, at
helping you navigate unfamiliar APIs,
and at getting you unstuck. That's real.
But API also reflects the median
patterns of his training data. And
median code is not usually lean,
ruthless, and performanceconscious code.
It is plausible code, verbose code,
layered code, defensive code. Code that
solves a stated problem in a
recognizable way, but not necessarily
the best way. And that matters to me
because a mediocre developer can only
produce mediocre code at human speed,
whereas AI can produce it at industrial
speed. Recently, I've been working on an
AI to solve the old arcade game
Robbitron. And in my UI, I have a video
preview of the running games. Now, the
preview in the UI was written by AI, and
it was slow. So, I started to debug it.
And pretty quickly, I discovered that it
was shoveling the video bits across my
nice, efficient socket interface that I
had created for it, just as I had asked,
except it was doing it in B 64 encoded
JSON, just about the most inefficient
way possible. And if you didn't check,
you would never know. And the danger is
not that AI will write that one awful
routine that everybody spots. The danger
is more that it will write a thousand
slightly over abstracted, slightly
overallocating, slightly overdependent
chunks of code that all look reasonable
in review, all pass the tests, all
satisfy the tickets, and together add up
to a product that is bloated, battery
hungry, memory greedy, and mysteriously
hard to make it any faster. AI is very
good at creating code that clears the
bar of it works. It has no real native
instinct for this is a hot path and
every cycle here matters. You have to
impose that instinct from the outside.
And I do try to do it in most of my
prompts and you should too. Which brings
us to the practical question. How do
companies manage code quality and
performance when the code is
increasingly produced by AI? The answer
is not to ban AI. It's to stop
pretending correctness is the whole
game. A unit test passing tells you that
the code is functionally acceptable.
It's mostly what I look for. But it
tells you almost nothing about whether
the code is elegant, maintainable,
efficient, or respectful of the user's
machine in time. That means performance
has to become a first class build
artifact just like correctness. And so
yes, for anything meaningful, companies
should absolutely be using internal
benchmarks continuously for every build.
Yes, for critical paths, yes, without
apology. Startup time, steadystate
memory, key transaction latency, page
load times, allocation counts, battery
impact, idle CPU usage, network
roundtrip time, database query counts.
They should not be mysterious numbers
that somebody checks when there's a
fire. They should be visible,
historical, and gated. If you can fail a
build because a unit test broke, you can
fail a build because a startup
progressed by 18% or because idle memory
grew by 300 megabytes for no user
visible gain. Now, that doesn't mean
that every commit needs to run a 6-hour
performance gauntlet and on warehouse of
machines. Be sensible. Fast smoke test
benchmarks on every merge for the hot
pads. Deeper scenario benchmarks on
dedicated hardware nightly. Full release
qualification before you ship.
representative workloads, not vanity
microbenchmarks, fixed test machines,
not whichever monster workstation
happened to be under some engineer's
desk. And especially for AI generated
code, you want profiling and regression
detection that can see through code that
looks clean but is doing dumb work
unnecessarily. Because AI will
absolutely write you a beautifully
structured little catastrophe if you let
it. And I would go further than
benchmarks. Organizations need explicit
budgets, not vague aspirations, real
budgets. This feature may add no more
than x milliseconds to the cold start.
The screen may consume no more than y
megabytes at idle. This background
service may not wake up the CPU more
than z times per minute. The sync loop
gets and network requests, not an
unbounded little party of retries and
polling. Budgeting sounds very
unromantic until you realize it is
exactly how the best old software got
made. Because here's the thing,
constraints are not the enemy of
creativity. They are what keeps
creativity from turning into sprawl.
Constraints promote the best kinds of
creativity, the kind required to make
apparent miracles happen. Vendors also
need to take dependency review
seriously. Every dependency should
answer a simple question. What does this
buy the user and what does it cost them?
Not the team, the user. And if the
answer is, well, it makes this faster to
ship. That's fine. But then be honest
that you are quite literally spending
the user's RAM and battery to save your
schedule. Sometimes that trade is worth
it. Often it is not. We should at least
make people say it out loud. And as
consumers, we've been too forgiving. We
normalize a lot of nonsense. We accept
note-taking apps that require an account
before they'll let you type in it. We
accept utilities that install background
services because maybe someday you'll
want clouds sync for your calculator. We
accept applications that burn CPU while
minimized that need a network round trip
to open up a local file that feel
sluggish until the second launch because
they're warming caches as if the
computer exists to patiently prepare the
software for its own eventual
competence. We need to stop treating
bloat as an unavoidable law of nature
because it isn't. It's a market outcome
created by the reality of what we as
consumers are willing to pay for.
Enterprise buyers can help by including
performance and footprint in their
procurement requirements rather than
just security questionnaires and feature
matrices. Consumers can help by
rewarding software that actually fills
sharp, local, responsive, and
respectful. And reviewers can help by
talking about memory and battery and
about startup time the way they talk
about the new features. Because once
those things affect sales, suddenly they
become strategy. The optimistic part of
this, and I do want to end on an
optimistic part, is that none of this is
unsolved or unsolvable. We know how to
build great software. We knew it when we
had 4K and paper tape. We knew it when
we had 8 megs of RAM and spinning rust.
We know it now with hardware that would
have seemed magical to our younger
selves. The answer is not to go
backwards. It is to carry forward the
right instincts from an era of scarcity
into an era of abundance. By all means,
keep the memory safety, keep the
accessibility, keep the
internationalization, the crash
reporting, the cloud backups, the modern
tooling, the managed runtimes where they
make sense, and the package ecosystems
where they're justified. Keep all the
good stuff, but bring back the respect.
Bring back the idea that software should
be lean by default. That latency is a
bug, that idle CPU is suspicious, that
startup time really matters, that
dependencies are not merely decorative
and that hot paths deserve human
attention, and that faster hardware
should make the experience feel
luxurious, not merely survivable. The
takeaway isn't that old programmers were
better. The lesson was that constraints
produced good judgment. They force you
to ask what really matters. They force
you to understand your machine and your
code, and they force you to choose
wisely. And maybe that's the real thing
old software got right. It had taste
imposed on it by reality. Today we have
to impose that taste on ourselves. If we
do, we can have something better than
old software and better than most modern
software, too. We can have software that
is safe and rich and beautiful and
connected and still feels immediate.
Software that honors the absurd power of
the hardware beneath it instead of
casually burning it for warmth. Software
that doesn't merely avoid sucking, but
that actually aspires to excellence. And
I think that's worth demanding. If you
found this episode interesting,
entertaining, or at least mildly
inflammatory in a productive way, I'd be
honored if you would consider
subscribing and leaving me a like. In
the meantime, and in between time, I
hope to see you next time right here in
Dave's