Hoe betere optimalisatie van games de geheugencrisis kan verzachten

De geheugencrisis als wake-upcall? Zo optimaliseer je games in de rampocalyps

De geheugencrisis grijpt om zich heen en maakt in de techwereld steeds meer slachtoffers. Door de honger naar geheugen voor AI worden onder meer consoles, geheugensticks, videokaarten en laptops duurder. Gamen dreigt een elitehobby te worden. Of kunnen gameontwikkelaars hun games zo optimaliseren dat nieuwe games ook voor gamers met oude hardware toegankelijk blijven?

"Het zou mij niet verbazen als we toch nog wat innovatie en daarmee verbeteringen op audiovisueel gebied gaan zien, omdat je bij gelijkblijvende hardware beter moet optimaliseren." Collega Jurian deed die uitspraak begin maart in de podcast naar aanleiding van de geheugencrisis. Hij zag het als een van de weinige potentiële lichtpuntjes. Maar hoe optimaliseer je als gameontwikkelaar games voor mindere hardware en, vooral, minder ram?

Peter 'Durante' Thoman

Dat is iets waar Peter 'Durante' Thoman alles over kan vertellen. Thoman is bekend van de mod DSfix voor de originele versie van Dark Souls op pc. Zijn bedrijf PH3 Games heeft gewerkt aan de ports van verschillende games voor de pc, PlayStation 5, Nintendo Switch en Switch 2, zoals meerdere games in de Trails- en Ys-series.

Bottlenecks in processen opsporen

Games optimaliseren begint meestal met profilers. Deze tools laten zien welke onderdelen het meest gebruikt worden tijdens processen en dus de meeste kans hebben om de bottleneck te zijn. "Als je gewoon gaat optimaliseren zonder dat je weet wat er precies gebeurt, werkt dat meestal helemaal niet", zegt Thoman.

De ontwikkelaar vertelt dat er twee soorten veelgebruikte profilers zijn: samplingprofilers en tracingprofilers. De samplingprofiler onderbreekt het programma een bepaald aantal keer per seconde om te zien welke threads waarmee bezig zijn. Wanneer dat tijdens een langere periode gebeurt, wordt duidelijk welke functies het systeem het vaakst gebruikt.

Het nadeel is dat deze methode alleen werkt voor een cpu: bij een gpu zijn de processen daarvoor te complex. Zelfs bij cpu-workloads kunnen 'nepbottlenecks' ontstaan door afhankelijkheden in parallelle processen. Als thread 1 negentig procent van de tijd wacht op thread 2, lijkt het alsof thread 1 de bottleneck is, omdat hij negentig procent van de tijd met één proces bezig is.

Een screenshot van Tracy

Ontwikkelaars gebruiken daarom vaak tracingprofilers als Tracy. Die laten met gekleurde balken zien hoe de threads in elkaar haken. Tracy maakt het mogelijk om de programma-uitvoering frame voor frame te inspecteren. Gebruikers kunnen precies zien welke functies het programma aanroept, hoeveel tijd die functies in beslag nemen en hoe ze elkaar beïnvloeden in een multithreaded omgeving.

Eerst schrappen, dan optimaliseren

Volgens Thoman zijn er grofweg vijf factoren waarmee je rekening moet houden tijdens de optimalisatie: compute van de gpu en de cpu, geheugenbandbreedte van de gpu en cpu en de geheugenbandbreedte tussen de gpu en cpu.

"In mijn ervaring ben je eigenlijk nooit beperkt door de rekenkracht", zegt Thoman. "Dat gebeurt alleen als het programma al extreem goed geoptimaliseerd is of je iets wilt doen dat in structuur simpel is, maar wel intensief."

In zijn blogs begint de ontwikkelaar het optimalisatieproces vaak met 'laaghangend fruit'. Meestal komt dat neer op het verwijderen van processen die niet hoeven plaats te vinden.

"Stel je voor dat je de inverse kinematica continu bijwerkt. Inverse kinematica draait om de positionering van botten ten opzichte van de omringende geometrie", legt Thoman uit. "Dat is niet zo belangrijk. Het is wel behoorlijk intensief en het kan voorkomen dat je dit bijwerkt voor npc's die niet eens in beeld zijn. Dat klinkt misschien gek, maar de eenvoudigste aanpak is om het voor álle npc's te doen. Je moet extra werk verrichten om te bepalen wie wel en wie niet in beeld is."

"Je kunt dus rekenwerk volledig elimineren zonder de uiteindelijke resultaten te beïnvloeden", vervolgt hij. "Dat is natuurlijk de ideale situatie voor optimalisatie en vaak een van de efficiëntste dingen die je kunt doen. Eigenlijk hoef je pas na te denken over hoe je het werk sneller of efficiënter kunt doen, wanneer je het punt hebt bereikt waarop je voornamelijk de noodzakelijke taken uitvoert."

Makkelijker gezegd dan gedaan

Dat klinkt eenvoudig, maar dat is het volgens Thoman zeker niet: "In de praktijk is het heel makkelijk gezegd. Het is niet in alle gevallen even makkelijk gedaan. Het geval dat ik schetste klinkt heel simpel. Dat is het misschien in sommige gevallen ook wel. Maar er zijn veel dingen waarin je aanzienlijk werk moet steken om bijvoorbeeld efficiënt uit te zoeken waarom je iets niet hoeft te doen of wat je wél moet doen."

Zo is het soms nodig om een compleet nieuwe acceleratiestructuur op te zetten, zegt Thoman. Deze datastructuur versnelt ruimtelijke zoekopdrachten in spellen, zoals de locatie van en onderlinge afstand tussen personages, voorwerpen en gebouwen bepalen. De acceleratiestructuur groepeert objecten op basis van hun positie. Hierdoor kan het systeem in één keer groepen objecten uitsluiten die niet relevant zijn voor een specifieke berekening, in plaats van dat het deze berekening voor elk afzonderlijk object moet doen.

Thoman: "Zonder goede acceleratiestructuur besteedt het systeem bijna net zoveel tijd aan het uitzoeken wat het wel en niet moet doen als aan alle assets renderen."

Geheugen was nooit de beperkende factor bij pc-ports

En het werkgeheugen? Hoe zit het met het optimaliseren daarvoor? Tot op heden was dat zelden de focus van pc-optimalisatie, legt Thoman uit: "Wanneer je een port maakt van een consolegame, heb je op de console waarschijnlijk minder geheugen dan op de pc. Dus als je een pc-versie van een consolegame maakt, is ramgebruik waarschijnlijk niet een van de dingen die je specifiek gaat optimaliseren."

DDR5-geheugen is rap in prijs gestegen door de tekorten.

Dat betekent niet dat het niet mogelijk is: "We hebben recent een Nintendo Switch-versie gemaakt voor een game die als eerste op de PlayStation 5 uitkwam. De Switch heeft natuurlijk niet zoveel geheugen als de PlayStation 5. Voor die game en voor veel midrange- tot high-end games is veel van het geheugengebruik te wijten aan textures en de geometrie. Het gaat echt om de assets."

Betere compressie van textures

Een van de manieren om dat geheugengebruik terug te dringen is textures comprimeren. Daarbij zou nog winst te behalen zijn door een alternatieve techniek in te zetten, maar bij pc-games doen ontwikkelaars dat niet.

Vaak gebruiken zij BC7 voor texturecompressie. Dat is een formaat om textures efficiënt te comprimeren. BC7 deelt textures op in 4x4-texturepixels, zogenoemde texels. Elk blok is 128bit. Om de details van verschillende textures te kunnen behouden, gebruikt BC7 verschillende modi.

Textures met ingewikkelde patronen krijgen bijvoorbeeld een modus met drie verschillende kleurgebieden. Textures met subtiele kleuren krijgen een modus met minder verschillende kleurgebieden, maar preciezere kleuren. Sommige modi kunnen ook transparantie weergeven.

Op veel andere platforms, waaronder mobiel en de Nintendo Switch, gebruiken ontwikkelaars meestal adaptive scalable texture compression, ofwel astc. Astc is flexibeler dan BC7, omdat het variabele blokgroottes ondersteunt. Elk blok is nog steeds 128bit, maar de texels kunnen 4x4 tot 12x12 groot zijn. Daarmee kunnen ontwikkelaars bepaalde textures met minder detail opslaan, zoals achtergrondobjecten en egale muren. Dat bespaart vram, zonder dat het kwaliteitsverschil voor het menselijk oog zichtbaar is.

"Astc is wat beter, maar om de een of andere reden krijg je dat niet op pc-hardware. Dat is jammer, omdat je met die techniek in sommige gevallen relatief makkelijk het geheugengebruik van textures met 30 procent zou kunnen verlagen met vrijwel gelijkwaardige kwaliteit."

Thoman vermoedt dat het ontbreken van astc voor pc-hardware te maken heeft met licentiekwesties: "Ik weet het niet zeker, maar waarschijnlijk kost het een paar cent extra per gpu als ze die technologie willen integreren."

Volgens de ontwikkelaar zou het ook kunnen dat gpu-fabrikanten het voordeel van de betere technologie niet vinden opwegen tegen de extra kosten van de integratie. "Een BC7-texture is ongeveer vier keer kleiner dan een ongecomprimeerd bestand. Misschien vinden ze de relatief kleine extra compressie gewoon niet belangrijk genoeg."

Een voorbeeld van astc-compressie

De verliezen bij slechte geometriecompressie

Hoewel pc-ontwikkelaars dus werken met een wat minder efficiënte compressietechnologie, denkt Thoman dat er bij texturecompressie niet veel winst te boeken is. "We beschikken over goed ontwikkelde compressietechnologieën en die worden al in de meeste games gebruikt. Er komen nog steeds pc-games uit met ongecomprimeerde textures voor elementen die eigenlijk gecomprimeerd zouden moeten zijn. Maar in de meeste games is texturecompressie redelijk goed uitgevoerd."

Dat geldt niet voor de compressie van geometrie van games, oftewel de 'skeletten' onder de textures. "Veel pc-versies van games en versies voor andere platforms die niet erg beperkt zijn in hun geheugen, zijn extreem inefficiënt in de opslag van geometrie." 3d-modellen in games bestaan uit polygonen. De vertices, de hoekpunten van die polygonen, worden volgens Thoman vaak 'gewoon' opgeslagen als een lijst met 32bit-floats.

Dat loopt al snel op als onder andere de eigenschappen voor de positie van de vertex (bestaande uit een x-, y- en z-coördinaat), de normaal (bestaande uit een nx-, ny- en nz-waarde) en de tangent (tx-, ty-, tz- en tw-waarde) van elke vertex allemaal als 32bit-waardes worden opgeslagen.

Verspilling

"Dat is echt verspilling", zegt Thoman. "Voor een Nintendo Switch-port hebben we het geheugenverbruik per vertex met meer dan de helft verminderd, zonder dat de visuele kwaliteit er ook maar enigszins onder lijdt. Dat is gewoon door een geschiktere numerieke representatie te kiezen voor elk aspect van elke vertex. Dat kan vooral in het geheugengebruik van de gpu veel schelen."

Wat een 'geschikte numerieke representatie' is, hangt af van de situatie, legt de ontwikkelaar uit. "Het simpelste is om de 32bit-floats op te breken in helften van 16 bits, maar soms verlies je daarmee informatie. Bij de coördinaten van textures krijg je precisieverlies als die textures groter zijn dan 1024 bij 1024 pixels." Dat probleem is bij 16bit-integers niet aanwezig. Integers werken wel met discrete stappen. Daardoor is de positionele precisie beperkt, wat kan leiden tot problemen als shimmering.

Ook de informatie die de ontwikkelaar in de specifieke float moet opslaan, is van belang voor de keuze om een 16bit- of 32bit-float te gebruiken. "Dat proces is altijd een soort hiërarchische uiteenzetting van alle informatie", aldus Thoman. "Als je 32 bits hebt om één punt in je hele virtuele stad te definiëren, is dat natuurlijk niet veel. Maar als je 32 bits hebt om de positie van een arm ten opzichte van een romp te definiëren, is dat extreem veel. Zelfs met 16 bits ben je dan waarschijnlijk nog steeds preciezer dan met de 32bit-float in je hele stad."

In cache

De beste 'werkgeheugenoptimalisatie' is ervoor zorgen dat het systeem het werkgeheugen helemaal niet hoeft aan te spreken, zegt Thoman. "Met sneller werkgeheugen kun je de latency bijvoorbeeld met een factor twee verkleinen. Dat klinkt als een grote winst. Maar het verschil tussen een datastructuur die in cache blijft en een die buiten de cache gaat, is veel groter. Het verschil daartussen is ongeveer een factor 100."

AMD bracht onlangs de Ryzen 5800X3D opnieuw uit, een processor die door zijn grote L3-cache uitstekend presteert in games.

"Je snellere geheugen is mooi meegenomen, maar als iemand de datastructuur zou optimaliseren, zou dat een veel groter verschil maken dan welke hardwarewijziging dan ook. Ik denk dat de grootste impact van de optimalisatie in de meeste applicaties – niet alleen games – te danken is aan aanpassingen aan datastructuren en algoritmes waardoor ze efficiënter omgaan met de cache. Dat geldt voor zowel de cpu als de gpu."

Het geheugengebruik en de cache-efficiëntie optimaliseren gaat bovendien vaak hand in hand, zegt Thoman. "Als je je geheugenverbruik vermindert, zijn je datastructuren kleiner en passen ze beter in de cache. Als een gpu een gecomprimeerde BC7-texture rendert, is dat sneller. Dat komt niet alleen door het lagere geheugengebruik, maar ook doordat het systeem de texturecache van de videokaart efficiënter kan inzetten."

Waarom porten zo vaak niet goed lukt

Bij PH3 werken in totaal drie werknemers aan games porten en optimaliseren. Toch zet PH3 Games vaak zeer geoptimaliseerde ports neer. Zo wist de studio de fps van de pc-versie van Ys X: Nordics op zijn testsysteem bijna te verdrievoudigen. Waarom lukt het grote uitgevers dan soms niet om goede pc-ports te maken, zoals bij Monster Hunter Wilds, Star Wars Jedi: Survivor en The Elder Scrolls IV: Oblivion Remastered?

Het resultaat van de optimalisaties van PH3 in Ys X: Nordics. Versie 0.1 draaide op 106 fps.

Volgens Thoman komt dat waarschijnlijk vaak meer door zakelijke beslissingen dan onkunde. "Het komt vaak voor dat niemand die in het bedrijf zakelijke beslissingen neemt, intrinsiek geeft om pc-ports. Dan moet er dus een duidelijk verband zijn tussen slechte optimalisatie en slechtere bedrijfsresultaten. Anders geven ze geen prioriteit aan het maken van een betere port."

Het probleem ligt volgens Thoman niet bij de mensen. "Ik weet zeker dat er mensen bij de grote studio's zijn die een game voor de pc kunnen optimaliseren. Maar als je een goede port wilt maken, kost dat waarschijnlijk een paar maanden tijd voor een paar man. Daarbij moeten ook een paar senior technische engineers helpen. Dan kan het prima. Het is geen magie."

Minder ram te koop, meer optimalisatie

Volgens Thoman kunnen de ramtekorten game-uitgevers mogelijk aansporen om hun pc-ports beter te optimaliseren. "Monster Hunter Wilds kreeg flinke kritiek vanwege prestatieproblemen op pc. Een van de redenen dat de uitgever opmerkte dat het spel niet goed liep, is dat het negatieve recensies op Steam kreeg. Dat merken uitgevers wel degelijk op."

"Steam-reviews zijn niet perfect, maar over het algemeen is het goed dat er een directere feedbackloop is naar uitgevers bij problemen met games", vervolgt Thoman. "Dat betekent dat ze er misschien meer aandacht aan besteden. Ik denk dat dit ook kan gebeuren met onnatuurlijk hoge prestatie-eisen in het algemeen, vooral nu niemand het zich kan veroorloven om zijn pc-hardware te upgraden."

"Ik denk dat het er simpelweg op neerkomt dat steeds meer mensen op oudere hardware gaan spelen", voorspelt de ontwikkelaar. "Als ze dan niet de prestaties zien die ze verwachten, zullen ze dat ook luider laten horen. En dat zou weleens iets kunnen veranderen."

_{Redactie: Imre Himmelbauer • Eindredactie: Marger Verschuur}

Reacties (104)

[Argantonis]

Goed om hier eens wat over te schrijven om van het stereotiepe 'moderne software developers zijn lui' af te komen. Het kost gewoon tijd (en dus geld) om te optimaliseren. Als dat niet nodig is omdat RAM goedkoop is, dan betalen bedrijven liever wat minder aan software dev uurtjes. Als de noodzaak er (weer) is dan kan er nog best een hoop slimmer gedaan worden. De drijfveer is winst, niet of iemand wel of niet lui is.

[bonus]

Ik zat/zit nog steeds in de retro demo scene club en daar was het altijd van " Je hebt 1Mb en daar moet je het mee doen". Als je dan ziet wat daar mogelijk is met zo weinig processorpower en geheugen dan moet er toch in de moderne machines een hoop te halen zijn. Dus optimaliseren was een must, maar met de komst van de PC werd dat steeds minder gedaan. "Werkt het niet of niet snel genoeg dan moet je geheugen bij prikken" was de standaard oplossing Dus misschien is een keer een crisis in deze niet eens zo slecht, wordt er eindelijk weer eens gekeken naar optimalisatie. Code en geheugen gebruik kunnen zeker beter...
Misschien dat het voor AI (waardoor het mede allemaal ontstaan is) ook eens een optie om er in te bouwen, maximaliseren van de code door minimalisatie ervan. Misschien dat dan de honger naar meer geheugen ook een beetje gestild wordt...

[Reactie gewijzigd door bonus op 3 juli 2026 07:31]

[S2S]

Ik denk dat AI hier uitermate voor geschikt is. Kan mooi profilen en de code herschrijven en aanpassen , daarna testen en de resultaten bekijken . Ik gebruik dit al in websites, kun je ook profilen en de cpu threads vooral de main optimaliseren.

[Reactie gewijzigd door S2S op 3 juli 2026 08:12]

[3raser]

Dus jij wilt de veroorzaker van het probleem die extreem veel energie, processing en geheugen verbruikt gaan gebruiken om software te optimaliseren die eigenlijk niet geoptimaliseerd had hoeven worden als AI niet had bestaan.

[IngamerX]

Correcte redenatie.

Het ding is; AI is er nu eenmaal. In that case you gotta change the way you play the game.

Hetzelfde met energie prijzen (ja ook hier, mede aangezwengeld door energie slurpende AI). Dit is weer een drijfveer voor verduurzaming.

Mensen zijn lui en corporates winst gedreven, daardoor zal doorgaans de weg van de minste weerstand worden gekozen. Impopulaire maatregelen en omstandigheden zijn nodig om verandering teweeg te brengen.

Wat een positieve insteek vandaag vanuit dit artikel, en dat einde van de week met weekend op de stoep

[3raser]

Ik begrijp natuurlijk wat je bedoeld. Maar onderaan de streep vererger je zo het probleem van waaruit deze optimalisaties voortkomen.

AI maakt hardware duur > games hebben optimalisatie nodig om met minder geheugen te kunnen werken > Ontwikkelaar gebruikt AI voor optimalisatie > AI heeft nog meer geheugen nodig om aan vraag te kunnen voldoen.

Een soort AI-inflatie. Maar dan in geheugentekorten in plaats van valuta.

[IngamerX]

Hoeft niet toch?

Het doel/idee is dat de netto uitkomst is dat AI door AI optimalisaties sneller efficiënter wordt dan dat toepassing/gebruik groeit. Dat is de gedachtegang.

Of dat mogelijk is is natuurlijk een tweede. Risico is absoluut het scenario wat jij schetst. Maar in dit geval is de insteek van het artikel en de comments daaromheen gericht op de kansen.

[PCG2020]

Volgens mij heeft @bonus het daar niet over. Het gaat om het optimaliseren van AI-code zelf, dus waarop de AI draait, niet van de code die AI genereert. AI is ook programmatuur en als die veel efficiënter kan werken, is dat natuurlijk ook winst. Het zou dan natuurlijk wel mooi meegenomen zijn wanneer de output ook geoptimaliseerd wordt.

[bzzzt]

Het verschil met games is dat het voor de grote AI bedrijven al lang als extreem noodzakelijk wordt gezien een hoge efficiëntie te bereiken. Als je voor miljarden aan GPUs koopt en energie in gigawatts afneemt is iedere procent die je kan besparen relevant.

[dmantione]

Tot op zekere hoogte. Waar we de afgelopen decennia mee bezig zijn geweest is de gehele computer voor de programmeur verborgen te houden. Dat maakt de programmeur productiever, maar als de programmeur verder van de hardware af staat, bemoeilijk dat optimalisatie. Dat geldt voor menselijke programmeurs, maar ook voor KI-programmeurs.

Een KI weet waarschijnlijk wel dat een quicksort sneller is dan een bubble-sort. En hij weet waarschijnlijk ook wel iets over de worst-case in een quicksort.

Een KI weet weinig over optimalisatie zodat data in de cache van de processor valt. Of in hoeverre de processor kan vectoriseren. Je kunt een KI waarschijnlijk wel sturen om code te wijzigen ten einde dat soort optimalisatie tot stand te brengen, maar dan gebruik je jouw programmeerkennis, niet die van de KI.

[Simkin]

Offtopic maar wel heel leuk om te delen als reactie op jouw reactie :-) https://marincomics.com/sota/

Imagine storing a full music video with music and graphical effects on a single 3.5" disk in the Amiga format that had a capacity of 880KB. This is what the "State of the Art" demo was. A full MTV quality music video executed in realtime on a forty year old machine, the Commodore Amiga with 7.16 MHz and half a Megabyte of RAM.

One of the most striking aspects of this demo is its use of animated vector sequences converted from real-life video footage. Rendering images using geometric shapes like lines and curves.

[Argantonis]

Ja ik kom ook nog uit die demo scene, ruim 30 jaar geleden met m'n 11 jaar in Basic en Pascal mooie bewegende beeldjes maken. C waagde ik me nog niet aan tot ik het tijdens m'n studie moest leren.

Maarja hoe mooi dat er toen ook uit zag, echt verkopen kon ik zoiets niet. Uiteindelijk is dat meer hobbie/puzzelen en da's leuk maar ik wil er ook graag m'n geld mee verdienen. En dat houdt nou eenmaal in dat 'goed genoeg' goed is, en extra tijd beter kan worden besteedt aan meer mogelijkheden bieden. Totdat het écht te langzaam wordt. Daarmee is dit geheugentekort inderdaad een mooie impuls, want zomaar uitgaan van dat de hardware het wel oplost werkt niet meer. Al was dat sowieso al niet zo voor de dingen waar ik me mee bezig hou nu, want containers met minder hoge specs starten bespaart al geheugen. Maar ik hou me sowieso niet bezig met of ik misschien beter een short kan gebruiken ipv int want dat is voor onze doelen echt gerommel in de marge, terwijl je dat in de demo scene allemaal moet hyper-optimaliseren.

[Sando]

Ik zat/zit nog steeds in de retro demo scene club en daar was het altijd van " Je hebt 1Mb en daar moet je het mee doen". Als je dan ziet wat daar mogelijk is met zo weinig processorpower en geheugen dan moet er toch in de moderne machines een hoop te halen zijn. Dus optimaliseren was een must, maar met de komst van de PC werd dat steeds minder gedaan.

Dat denk ik inderdaad ook altijd als ik weer een app van 100 MB moet downloaden die vroeger 500 KB zou zijn geweest.

Aan de andere kant, Farbrausch heeft 2 jaar gewerkt aan .kkrieger. Valve heeft ook 2 jaar gewerkt aan Half-Life, en 2 jaar aan Portal.

Het is een beetje analoog aan het comprimeren van bestanden: Hoe groter de compressiefactor, hoe meer tijd het kost.

[NotWise]

Je hebt deel gelijks, alleen gebruikt de "Fuij club" waar jij op doelt gestandaardiseerde machines. De PC wereld daarentegen kent ontelbare hardware- en software configuraties (en versies). Om alles te optimaliseren is onbegonnen werk. Dus is "goed, goed genoeg" Bovendien kan optimaliseren (waar jij specifiek op doelt) qua kosten niet uit. We hebben het hier over commerciële software met doorlooptijden/deadlines. Daarbij wordt vaak gekeken naar wat concurrenten doen, feestdagen e.d., daar wordt naartoe gewerkt.

[Sissors]

Niet direct zo relevant voor games, maar meer in zijn algemeenheid heb ik nu een paar keer (op het internet) aan devs gevraagd waarom als ze zeggen dat ze geen regel code meer schrijven, AI doet alles, ze dan nog vast moeten blijven zitten aan zaken als Electron, Webview, etc. Laat het dan allemaal lekker native draaien als je toch de code zelf niet schrijft!

Helaas tot nu toe was elke reactie alsof ze water zagen branden, danwel dat ik overduidelijk te dom was om softwaredevelopment te begrijpen. Dus ik snap nog steeds niet als je de daadwerkelijke code toch door een LLM laat schrijven, waarom kan het niet in veel geoptimaliseerdere programmeertalen? (En nogmaals, dit is een algemeen iets, ik snap dat Unreal Engine niet in Python is geschreven).

[PeterVO]

Om goed met AI software te schrijven moet je als developer wel weten wat er uitgespuugd wordt door het AI systeem. Er zijn in deze wereld meer developers die met web technologieen om kunnen gaan dan hard core developers voor talen als C++, rust, ...

De vraag is om veel features te maken in weinig tijd (en tijd is geld, denk aan €100 per uur of meer aan kostprijs). Vaak krijg je met web technologieen meer gedaan met minder regels code (helaas). In veel gevallen maakt het ook nog eens niet zo veel uit voor de performance. Er zijn vaak maar een paar stukken van de code waar je moet optimaliseren. Deze zijn vaak wel geschreven in gecompileerde talen en worden dan gebruikt door de web frontend stack.

[Nathilion]

€100 per uur voor een developer... en daarbij compleet voorbij gaan aan de kosten van het gebruik van AI. Want AI is niet een €20 per maand abbonnementje bij OpenAI. AI tokens zijn duur, erg duur. De kosten per token (elektriciteit, water, afschrijving, etc.) kunnen oplopen tot duizenden euro's. En een beetje vibecoden jast er al een dozijn of meer doorheen zonder dat je daadwerkelijk iets oplevert.

Uber en Meta, met hun beruchte 'token maxxing' programma's, zijn er al van terug gekomen. Die bedrijven joegen een paar honderd miljoen aan tokens er in een paar maand doorheen. Voor die hoeveelheid geld, t.o.v. de opgeleverde features, had je ook aardig wat ontwikkelaars kunnen inhuren.

[Sissors]

Nou ja, als ik je ziet dat een agenda widget in Windows nu 130MB geheugen gebruikt, dan is dat natuurlijk ronduit idioot.

En van wat er wordt gezegd door veel developers dat ze nu nul regels code schrijven, verificatie wordt gedaan door een andere Claude agent, etc. Dus als dat helemaal door LLMs wordt afgehandeld, laat het dan lekker een beetje efficienter gaan. Als het is zoals @bzzzt schrijft het probleem is dat de LLMs ook alleen genoeg training hebben voor zulk soort dingen met bijvoorbeeld Webview, dan gaat het natuurlijk alleen maar erger worden: Minder en minder IT'ers zullen zelf code schrijven, dus iedereen blijft bij het bestaande want dat is het enige wat de LLMs aan kunnen. Terwijl ik juist had gehoopt als je toch minder code zelf schrijf, de LLM efficientere talen kan gebruiken.

[Marq]

Wat jij beschrijft zou alleen werken als je de code als 'black box' beschouwd. Dat betekend dat je de code nooit leest, maar alleen naar de buitenkant van het systeem kijkt, zowel handmatig als via geautomatiseerde tests.

Wanneer je dit doet is alle gedrag van het systeem wat niet in een test beschreven staat, ongedefinieerd. En juist daar zit het probleem. Want wanneer je een LLM instructies geeft zal hij alles wat je niet expliciet definieert zelf in moeten vullen. Daarbij maakt de LLM dus 'keuzes', want anders moet je alsnog elk detail zelf bepalen. Elke keuze die je niet gecheckt hebt is een potentiële bug.

Daarnaast is het ook nog eens zo dat als de code een black box is, je niet meer kunt bepalen hoeveel code een LLM mag wijzigen om een bepaalde wijziging te maken. Dat is een probleem, omdat elke onnodige wijziging mogelijk weer nieuwe bugs introduceert.

Ik geloof niet dat het mogelijk is om tests op zo'n niveau te krijgen dat je dit probleem kunt oplossen. En als dat wel kan, zijn die tests eigenlijk je nieuwe programmeertaal geworden.

[bzzzt]

Veruit de meeste 'web developers' gebruiken tegenwoordig JavaScript/TypeScript (zie https://survey.stackoverflow.co/2025/technology) waardoor LLMs, die zijn getrained op publieke broncode, daar beter mee om kunnen gaan dan dat je een relatief niche taal gebruikt. Daarnaast kan je met een wrapper als Electron natuurlijk gelijk multiplatform releasen. Dat is nog altijd goedkoper en sneller dan AI voor ieder platform native te laten ontwikkelen.

[demonite]

Die developers die zeggen dat ze geen regel code meer schrijven zijn er denk ik in 2 smaken.
1) De overdrijver, die gebruikt AI maar checkt alles en past hier en daar ook nog wel eens wat aan en schrijft dus wel degelijk nog code.

2) De vibe coder, die alles klakkeloos overneemt en steeds minder een clue zal hebben over wat er nou eigenlijk gegenereerd is. Deze schrijft daadwerkelijk geen code meer en zal dus op een gegeven moment niet meer in staat zijn om problemen te kunnen oplossen waar de AI niet uitkomt (zonder andere dingen stuk te maken of omdat het teveel credits kost).

[beeldbuijs]

Hoe lager het niveau is van de programmeertaal, hoe sneller het over het algemeen uit te voeren is door de computer, maar het wordt er niet overzichtelijker op, het draait niet meer op verschillende systemen dus je moet het gaan compileren en testen voor soms wel tig platformen en vooral: Qua onderwerp van dit artikel: geheugenruimte is het meestal juist veel ‘duurder’.

Als ik zie dat bijvoorbeeld Adobe Illustrator nu een paar gigabyte groot is, terwijl het ook weer niet zo bizar veel meer kan dan 30 jaar geleden toen de complete harde schijf van een desktop computer maar een fractie daarvan kon herbergen, vraag ik me af of optimalisatie niet gewoon onbelangrijk gevonden wordt, want de professionele klant heeft toch wel 16, 32 of meer GB aan werkgeheugen.

[_Pussycat_]

Bovendien zijn er ettelijke NES-games die ook van de ellende uit elkaar vallen kwa inefficiëntie. Vroegah' was het allemaal ook niet zo best.

[kujinshi]

Toch vind ik het wel knap hoe perfect veel NES en SNES games waren (geen bugs) en toch gigantische spellen in kleine opgeslagen ruimte. Zie spellen als Final Fantasy VI of Zelda.

Toen was comprimeren en op vanalles letten als programmeur veel meer aan de orde.

[bzzzt]

De eerste Legend of Zelda game past in 128Kb, waarvan slechts een fractie code is. Minder code betekent minder bugs, maar die oude spellen zijn echt niet bugvrij. Het is natuurlijk wel veel overzichtelijker als je code op een paar A4tjes past vandaar dat er geen heel grote issues in zitten meestal.

Daarnaast is het natuurlijk een kwestie van slim hergebruik van resources: een 'nieuw' monster toevoegen door een sprite een ander kleurtje te geven kom je nu niet meer mee weg.

[deknegt]

Als je vermoed dat er in (S)NES games geen bugs zaten, zou ik voor de lol eens kijken naar speedruns. De hele speedrun gemeenschap heeft er een sport van gemaakt om via glitches, code injection (via invulvelden), en RNG manipulation spellen zoals Zelda 2 of Pokémon (oké, dat is GB, maar dan nog) in luttele minuten uit te spelen.

[_Pussycat_]

• Mario en Mega Man kunnen allebei door de muren heen glijden.
• Mario kan door de grond vallen.
• Mario warpt naar foute levels
• TMNT heeft verschoven hitboxes.

De programmeurs hadden veel slechtere mogelijkheden te debuggen, maar er werd toen, net als nu, ook gewoon een berg bagger zo snel mogelijk de deur uitgegooid. Gelukkig waren Nintendo/Sega nog actief als controleurs om het niet al te erg te laten worden; maar dat is bij consoles nu ook niet anders.

[Firecrash]

Goed om hier eens wat over te schrijven om van het stereotiepe 'moderne software developers zijn lui' af te komen. Het kost gewoon tijd (en dus geld) om te optimaliseren. Als dat niet nodig is omdat RAM goedkoop is, dan betalen bedrijven liever wat minder aan software dev uurtjes. Als de noodzaak er (weer) is dan kan er nog best een hoop slimmer gedaan worden. De drijfveer is winst, niet of iemand wel of niet lui is.

Dus is het onwil. En dat is wat mensen roepen...

[Argantonis]

Nee dat is niet wat mensen vaak roepen, vaak wordt het luiheid of onkunde genoemd. Het is idd onwil, maar dan onwil vanuit eigenaren of aandeelhouders, want sneller dan ‘snel genoeg’ levert niks op en de aanname dat hardware toch wel vooruit ging was lange tijd juist.

[PjotrX]

Dat 'lui' is inderdaad een beetje onzin. Daar ga je van uit dat iemand op zijn werk youtubefilmpjes oid aan het kijken is. Dat terwijl het bekend is dat game-developers juist vaak lange periodes van crunch hebben. Dan heb je weken lang elke weekend zitten door te werken en een burnout gekregen om vervolgens door gamers als lui bestempeld te worden, geen wonder dat een groot deel van de oude talentvolle ontwikkelaars uit de industrie gestapt zijn. Het is meer de competatieve markt die ervoor zorgt dat ontwikkelaars deals moeten aannemen van publishers waar ze relatief korte ontwikkeltijd krijgen voor hun project.

[Wolfos]

Tja, ik denk dat het toch veel dingen verwart. Want wat is nou eigenlijk de vraag? We gaan van geheugengebruik van CPU prestaties naar GPU prestaties en dan ineens texture compressie.

Games als Oblivion: Remastered en Monster Hunter: Wilds waren traag door bepaalde architectuurfouten. Gaat dat minder voorkomen? Natuurlijk niet. Fouten blijven gemaakt worden.

Voor de rest zijn games meestal behoorlijk goed geoptimaliseerd tegenwoordig. Zeker op consoles is het momenteel een zeldzaamheid als een game niet op 60FPS draait. Dus als de vraag is- blijft dat zo op huidige consoles? Dan hangt dat puur af van keuzes die al gemaakt zijn omtrent next-gen.

Wat PC's betreft is het inmiddels wel even duidelijk dat 8GB VRAM voorlopig een blijvertje is, dus ik mag hopen dat ontwikkelaars dat blijven meenemen in hun doelstellingen. Anders hebben ze echt niet zitten opletten.

[Giovanni_1]

Het is voor de bedrijven wel gunstiger als mensen de ontwikkelaars de schuld geven in plaats van het bedrijf. Houd de hitte van het probleem wat meer af van het imago van een bedrijf lijkt mij?

[Dutch_CroniC]

Doordat de nieuwe grafische functies makkelijk in een engine zijn toe te passen, is het voor veel ontwikkelaars al gauw genoeg. En het optimaliseren ervan is iets wat zeker wel wat meer kennis vereist. En daar zijn ze vaak te lui voor om tijd in te stoppen.

Er worden namelijk nog steeds wel goed geoptimaliseerde games uitgebracht, maar steeds meer minder geoptimaliseerde games.

De drempel om nu een game te maken is met de meeste engines steeds lager, maar optimaliseren vereist wel wat meer kennis.

[Wolfos]

Er worden namelijk nog steeds wel goed geoptimaliseerde games uitgebracht, maar steeds meer minder geoptimaliseerde games.

Nee, vroeger hadden gamers een veel hogere tolerantie voor prestatieproblemen en bugs. We zijn verwend geraakt.

Er zit juist meer werk in optimalisatie dan ooit. Maar we mopperen over die paar uitzonderingen, romantiseren het verleden, en vergeten voor het gemak even dat Oblivion Remastered juist een voorbeeld is van de optimalisatie van 20 jaar geleden. Toen waren we nog geen stabiele framerates gewend.

[Reactie gewijzigd door Wolfos op 3 juli 2026 16:07]

[Dutch_CroniC]

Ik merk daar anders zelf trgenwoordig meer van dan vroeger toen games wat minder complex waren.

Nu duwen ze er een upscaler tegenaan, nog wat andere effecten via een library en thats it. Juist die zaken zorgen bij mij nu voor framedrops en grafische glitches.

Ook vragen games vaak meer van het systeem dan je zou verwachten. Ik heb geen slappe bak, maar soms denk ik wel dat bepaalde games een stuk beter zouden kunnen draaien als er wat meer aandacht aan gegeven wordt.

Iets waar ik vroeg veel minder 'last' van had.

[Dat_Doen_We_FF]

Als je ziet wat de marketingbudgetten zijn....
Overigens, ik zie het juist wel. Iedereen trekt 1000 bibliotheken in zijn code in.....
https://www.npmjs.com/package/is-even
is-even, gewoon een modulo in een package, heeft een half miljoen downloads per week!
Het bestand met de mentions naar de authors is langer dan de source code, welke natuurlijk gewoon input % 2 == 0 returned lol.

Dus ja, developers zijn lui tegenwoordig.

[Jim de Wit]

Het is zelfs nog erger; dat package is-even heeft een dependency op npm package is-odd (van dezelfde author) en returnet !isOdd(n)

[Dat_Doen_We_FF]

Haha, zo ver was ik niet eens gekomen.
Maar het zegt qua mij betreft eigenlijk wel genoeg dat dat package een half mil per week wordt gedownload. Men kan niet eens meer modulo-en.....

[Jim de Wit]

Ja, je hebt volkomen gelijk! Was het niet Einstein die zei "Er zijn twee dingen oneindig..."?

[L0g0ff]

Oprechte vraag (zonder af te willen doen aan deze dev want wat hij doet is fantastisch!)

Wat zou dan meer energie kosten? Hey AI optimaliseer deze game zodat die op een aardappel draait.

AI is een week aan het stampen en de game draait top op een aardappel. (Code zal spaghetti zijn maar dat is een andere discussie)

Of je doet dat niet en iedereen heeft zware videokaarten nodig om deze game op een next gen hardware te kunnen spelen?

[Harm_H]

Het is heel simpel: AI kan dit nu niet.

Er is nog geen AI algoritme of agent dat zelf profilers gaat draaien en daaruit allerlei correcte conclusies gaat maken. De meeste AI loopt bij grotere opdrachten al helemaal vast. Sterker nog - AI kan heel weinig - waar zijn de applicaties als AI zo goed is als jij denkt? Het is leuk voor prototypes en +20% productiviteit voor ontwikkelaars.

[Wolfos]

Je kunt een AI agent best een profiler laten draaien. Maar alsnog vertrouw ik de opdracht niet.

Als het doel is een bepaald algoritme te optimaliseren dan kan een AI agent dit zeker. Maar een hele game? Dan zit je al snel met subjectieve keuzes. En wie zegt dat de code überhaupt het probleem is?

[mschol]

maar als je code spaghetti is, is het ook een drama voor eventuele updates of patches, dat wil je als developer ook niet lijkt mij?

[graey]

AI met een helder doel, geverifieerde plannen en testmethodes; dan heb je nog wel een competente dev nodig, maar die hoeft niet elke puntkomma meer zelf te typen, en je krijgt geen spaghetti. Als het spaghetti is en het introduceert een nieuwe bug die alleen onder bepaalde omstandigheden voorkomt, wordt debuggen, ook met AI, steeds meer een nachtmerrie.

"Just yeet AI" gaat echt grote problemen op de lange termijn opleveren als er geen beleid bij is.

[S2S]

Maar de code hoeft helemaal niet spaghetti te worden, controle zou ik aan de mens overlaten .

[Daoka]

Ik denk dat dit ligt aan meerdere factoren (aangenomen dat de AI dit lukt natuurlijk). Hoe slecht was het geprogrammeerd? Hoeveel verbetering krijgen we dan? Welke AI model gebruik je? Hoe groot is de game (of beter gezegd hoeveel gaat de AI in)? Hoe populair is de game en wat voor soort game is het? Is het single player game of een multiplayer game (en hoe lang zijn de game servers online en hoeveel spelers).

Maar 1 gigawatt is een miljard watt en bij 10 watt besparing moeten we dus 100 miljoen uren spelen om gelijk te komen en daarna zouden we winst moeten hebben. Nu weten we de verbruik voor dit fictieve project natuurlijk niet maar om een indicatie te geven. Volgens internet verbruiken de grootste AI-datacenters continu ongeveer één gigawatt, wat neerkomt op 24 gigawattuur per dag. Zeg dat dit dan 1% is van de totale verbruik zal verbruiken = 0.24 gigawattuur per dag en je zei een week dus 0.24 * 7 = 1.68 gigawattuur bij 7 dagen. Dus bij 10 watt verbetering 168 miljoen uur gametijd.

Op Tweakers op 6 juni 2023 zie ik een artikel staan over Diablo 4

In een persbericht gepubliceerd door Business Wire zegt Blizzard dat de dungeoncrawler sinds de beperkte release op 1 juni al 96 miljoen uur gespeeld is

Dus ik verwacht wel dat het bijvoorbeeld bij Diablo 4 dus wel een besparing zou kunnen zijn aangezien ze er al een groot gedeelte zijn met 5 dagen. Aangenomen dat de game dan werkt (en de spaghetti code geen problemen geeft in bij verdere updates).

Natuurlijk blijven dit maar voorbeeld getallen. En je moet dus ook rekening houden met dat in geval van Diablo 4 er nog steeds nieuwe content komt zoals dat seizoen 14 een paar dagen geleden is uitgekomen en alle patches die uitgekomen zijn en hoeveel spelers zijn er nog na 3 jaar. De vraag is dus zou je hiervoor dan de AI opnieuw gebruiken, alleen de nieuwe stukken of helemaal niet. Als de eerste patch doen na een dag al komt en dan heb je de AI weer gebruikt dan zal de eerste keer AI dus geen besparing hebben.

[Reactie gewijzigd door Daoka op 3 juli 2026 08:24]

[Finraziel]

De vraag is daarnaast ook, gaat het werkelijk energie sparen aan de client kant? Of draaien we gewoon op een hogere fps met hetzelfde energie verbruik?

Niet dat dat het dan niet waard zou zijn, maar puur vanuit de vraag wat op grote schaal meer energie kost zou ik er niet vanuit gaan dat de meeste mensen hun fps cappen om hun computer zuiniger te maken. Op consoles is dat eventueel natuurlijk wel iets makkelijker af te dwingen.

[Daoka]

Daar heb je zeker een punt. Al zou je op de pc ook wel een beperking kunnen inbouwen. Ja het is inderdaad lastiger om te hanteren omdat bijvoorbeeld een mod of onofficiële patch dit zou kunnen overschrijven maar genoeg mensen kunnen (of durven) dit niet te installeren of weten geeneens dat dit mogelijk is. Daarnaast zijn er ook games die minder of helemaal niet leunen op FPS waarbij de besparing ook aanwezig kan zijn. Ik speel bijvoorbeeld ook veel puzzel spellen waarbij het beeld vaak genoeg stil staat totdat ik iets doe (en zelfs dan nog vaak maar kleine korte bewegingen). Hier ga ik echt geen 200 FPS nodig hebben. Dus ook op de pc zou er besparing kunnen zijn. Al is het de vraag of het dus voor de soorten spellen het waard zou zijn qua AI verbruik en game tijd.

Maar (ondanks dat het een goede punt is) ik ga er eigenlijk ook niet van uit dat dit de bedoeling van de vraag was. Want anders hoef je je niet af te vragen of het besparing kan opleveren als je dus nooit kan besparen door de hogere FPS.

[cdwave]

... Hey AI optimaliseer deze game zodat die op een aardappel draait.

Dat lijkt meer op religie. "Oh Lord, won't you buy me, a Mercedes Benz..."

Ik zie een soort geloof ontstaan dat je AI maar alles kunt laten doen, als je maar de juiste prompt weet te vinden. Magie dus. Vind de juiste toverspreuk...

[AnonymousGerbil]

Hey AI optimaliseer deze game zodat die op een aardappel draait.

Haha, dat gaat natuurlijk niet gebeuren.

Zelfs indien die "ai" in staat zou zijn om zo een taak uiteindelijk uit te voeren gaan de meeste uitgevers van grote spellen daar helemaal niet de centjes in steken die zo een geintje kost.

[Lord Anubis]

Men kan natuurlijk ook AI app of de benodigde buffers kunnen optimaliseren.
Men zou ook AI duurder kunnen maken of een verkoop limiet in zetten.

[The Zep Man]

Men zou ook AI duurder kunnen maken of een verkoop limiet in zetten.

Dat is niet alleen wat men kan doen. Het is iets wat men gaat doen.

[keroner]

Men zou ook AI duurder kunnen maken

Dit zou de beste optie zijn.
Verliesgevende bedrijven die alle energie en hardware opvreten zodat mensen de meest onzinnige dingen kunnen doen voor nop.
AI is goed hoor, voor functioneel gebruik. Geen idee wat de cijfers zijn, maar denk dat 60% van het gebruik onzin of luiigheid is.

[Sissors]

Als er natuurlijk nou één tak in de IT is waar optimalisaties door developers gewaardeerd zullen worden door hun werkgevers, dan is het AI wel. Gezien hoe verschrikkelijk veel geld die besteden aan compute.

[WargamingPlayer]

AI is duur. Reken tussen de $ 7 voor een minder goed model, tot $ 25 voor een heel goed model.

Wij betalen Fable-5 ongeveer $ 34 terwijl een ander Antrophic model, 0,2% minder goed is, maar $ 17 kost.

Dit is per programming solution, niet een heel programma. Wanneer je dus een solution maakt, dan kan bij de verkeerde vraag stelling je zo even in 15 minuten $ 100+ wegpissen.

AI in professionele omgeving is niet goedkoop om code mee te schrijven.

Ik heb zelf beschikking tot alle modellen op mijn werk, maar wanneer ik zie wat dat kost, dan denk ik, wow, hoe in hemelsnaam gaan we dat terug verdienen.

[AnonymousGerbil]

Maak de borst maar nat, want op dit moment rekenen de aanbieders nog niet een tiende van wat ze zouden moeten verdienen om het voor hun kostendekkend te maken.

En die kosten zullen, geheel tegen de klassieke informaticatrends in, voor de voorzienbare toekomst alleen maar stijgen.

[WargamingPlayer]

Dat klopt, en bij ons zijn voor bepaalde modellen ook cap's ingevoerd, voor bepaalde modellen heb je ook een exceptie nodig voor de noodzaak. Waar het begon met "Iedereen moet AI" is het nu steeds meer "AI wordt toch wel een beetje duur".

Aangezien we bijna 400K medewerkers hebben gaan de kosten wel dik meewegen.

[IKON]

Ik geloof hier niet in. De hoeveelheid RAM die door de AI wereld gevraagd wordt is zo gigantisch groot, dat een beetje meer optimalisatie per game (je speelt er altijd tenslotte maar 1 tegelijk) een druppel op een gloeiende plaat is.

Het probleem van slechte optimalisatie is er een van aandeelhouders die zeggen “ik wil nu cashen en niet meer investeren dan dit dus release maar” maar zelf geen idee hebben van hoe een PC of game werkt en het belang niet snappen.

[batteries4ever]

Ik denk dat je dat verkeerd begrijpt: de gedachte is niet de RAM prijzen weer omlaag te krijgen, maar ook bij de huidige prijzen hardware uit te brengen met minder geheugen, die dan alsnog leuke resultaten kan tonen met geoptimaliseerde games. Dat optimaliseren kan noodzakelijk worden als veel gamers systemen met minder geheugen hebben, anders volgen er negatieve reviews storten de game verkopen in.

[IKON]

Ja oké. Ik las het bericht inderdaad als “dan wordt de vraag dus minder en daalt de prijs”, maar dat plak ik er zelf inderdaad een beetje achteraan.

[batteries4ever]

Ik ken dat "been there done that"... maar daar zijn forums voor!

[eheijnen]

Dat principe kan ook op besturingssystemen en "gewone" applicaties worden toegepast...

[Skit3000]

Wat dacht je van websites?

[elmuerte]

"Gewone" applicaties zijn tegenwoordig vaak websites. Dus ja, ook websites.

[vickypollard]

https://thebestmotherfucking.website/

[The Zep Man]

Dit komt overeeen met een eigen voorspelling die ik wel eens genoemd heb: de meeste PC-spellen worden de komende tijd meer ontwikkeld voor oudere hardware ten opzichte van het verleden. Men moet wel om een zo groot mogelijk publiek aan te trekken.

Het is een nare tijd als je instapt. Het is geweldig als je al een PC hebt, zelfs als die al wat ouder is. Het aanbod wordt alleen maar beter. Oude spellen gaan nergens heen (officieel, of in gevallen zonder alternatief via de zeven zeeën), dus er is al een gigantisch aanbod. Die blijft groeien zonder dat grote upgrades nodig zijn.

Als je verder kijkt dan AAA(A), dan kan je zelfs slechts met een Steam Deck aan de slag met de meeste nieuwe spellen. Dit terwijl de Deck volgens sommigen al in 2022 underpowered was. Dit toont aan dat je echt niet veel nodig hebt qua specs.

[Reactie gewijzigd door The Zep Man op 3 juli 2026 13:04]

[PjotterP]

Ja helemaal eens. Ik denk dat de realiteit ook is dat voor heel veel soorten games gewoon het plateau is bereikt wat je aan hardware nodig hebt. Zodra een game niet per se ultra fotorealistisch hoeft te zijn kom je veel oude hardware al een heel eind. En zelfs heel mooie best wel realistisch ogende games draaien nog prima op oudere hardware (death stranding bijv.)

[Pietopdeheuvel]

Het doet mij sterk aan Amerikaanse autos denken.

Nu geheugen duur is, kan het ineens wellicht beter.

[R_Zwart]

Het is altijd de uitkomst van een business case analyse. Altijd denken wat je zou doen als het van je eigen geld gedaan moet worden.

[Pietopdeheuvel]

True, als de benzine goedkoop is, gewoon meer Cubic Inches. Vervolgens komt er een producent die besluit meer te gaan optimaliseren of het anders te gaan doen en ligt die ver voor de rest van de markt. Daarom hebben bv de VS autofabrikanten nog maar de helft van hun thuismarkt, waarvan bijna een derde bij Tesla ligt.

Steeds snellere CPU, GPU's en goedkoop geheugen, geen noodzaak te optimaliseren. Daarom is moderne SW zo bloated, produceert een gaming PC genoeg warmte om een zolderkamer mee te verwarmen. Maar goed, geheugen is eigenlijk nog steeds goedkoop wanneer je naar de lange termijn kijkt.

[Reactie gewijzigd door Pietopdeheuvel op 3 juli 2026 09:43]

[vinx77]

Helemaal mee eens. En dit is ook waar een klein land groot in is:

• Evolve Benchmark van Traverse Research, waar ze o.a. de rendering optimaliseren en natuurlijk benchmarken (Breda, 25 mensen)
• Stream HPC, die algorithmisch en low-level optimalisaties doet op GPU-software en GPU-libraries (Amsterdam, 40 mensen, full disclosure: mijn bedrijf)
• Nixxes, die vele games geoptimaliseerd heeft voor de PC, en erg vloeiend lopen op gewone game-PCs (Utrecht, 130+ mensen, nu onderdeel van Sony)
• Studie "Game Design" in Breda, waar Jakko Bikker optimalisatie-lessen geeft. Deze studenten kom je ook tegen in veel buitenlandse studio's
• Vergelijkbare studie Gametechnologie in Utrecht, waar Jacco ook les heeft gegeven

Er zijn nog wel meer, maar ik ga ervan uit dat deze worden genoemd in een thread. Maar meeste bedrijven zijn onder de 20 mensen. Toch leuk dat op de grens van techniek en gaming in Nederland veel wordt ondernomen.

Zelf had ik nog niet PH3 Games gehoord, maar lijkt een kleine studio in Oostenrijk te zijn. Klinkt als een klein team of freelancer.

[Skyrunner]

Goede zaak.

Code optimaliseren ipv meer hardware bijsteken.

Werkte op C64 ook.

[quazar]

Als je ook een Notepad kunt maken met 2,4kb is het wat frustrerend dat er apps zijn die bijna niets doen maar wel 126MB zijn, die zullen ook wel véél meer geheugen gebruiken dan nodig. Hopelijk kan AI de code minder inefficiënt maken (al heeft AI ook van nature de neiging om grote blobs te schrijven).

Als in; dit geldt bepaald niet alleen voor games. 16GB om een browser, Word en nog wat dingetjes te kunnen draaien is ook absurd.

[Reactie gewijzigd door quazar op 3 juli 2026 07:29]