Gamen met multi-core processors: zinvol of niet?

Reacties

« 1 2 3 »

Door ikwilhet, maandag 14 maart 2005 19:31

Bij games ligt de bottleneck toch meestal bij de Video kaart. CPU heeft hier weinig invloed op (vanaf een bepaald niveau). Dus dan snap ik niet waarom dual core dan voor games prestatie winst oplevert?

Door Countess, maandag 14 maart 2005 19:32

er zijn genoeg games waar je boven een bepaalde videokaart geen extra FPS meer ziet omdat de cpu te bottlenek is geworden, zeker op wat minder hoge resoluties of zonder AA en FA

Door Derice, maandag 14 maart 2005 19:33

Probeer Flight Simulator 2004 eens. Die vind dat wel lekker hoor extra CPU power naast een dikke videokaart.

Door _l_Arjan_l_, maandag 14 maart 2005 19:34

Bij SLI is duidelijk de processor de bottleneck.

Door Hielko, maandag 14 maart 2005 19:34

Daarnaast; juist doordat er nu meer power beschikbaar is kunnen er nu realistischere physics geimplementeerd worden, een betere AI etc.

Door abraxas, maandag 14 maart 2005 19:44

't aansturen van de graphics wordt veel ontzien door de gpu tegenwoordig, maar een game engine is meer dan alleen wat direct3D of opengl calls..

in een single threaded game engine (en dat zijn 99% van de engines) gebeurt er op 1 de cpu maar 1 ding tegelijk.. AI, geluid, physics, netwerk, input, etc... het ene wacht dus altijd op 't andere.

als dat dus parallel kan, is daar winst te behalen (je kunt per gerenderde frame theoretisch 2x zo veel uitvoeren op je cpu). en dat kan ook wel, maar lastig, omdat game engines vaak alles "per frame" afhandelen... parallel is dat dus enigszins problematisch, omdat de render-thread wel per frame alles doet, maar de andere threads vrolijk hun werk doen zolang ze daar de tijd voor krijgen van de scheduler.

hielko: het kan, maar dat wordt steeds minder dankzij steeds indrukwekkender wordende physics en AI, en het steeds simpeler aansturen van de gpu (d.m.v. shaders, geometry instances, displacement mapping, e.d.)

catfish: dat is echt niet te vergelijken.. een gpu is ontiegelijk parallel en kan dus vrij eenvoudig ook met meerdere cores (of gpu's) werken, omdat het verwerken van deze data gewoon van die aard is. het is niet voor niets dat gpu's van steeds meer pipelines worden voorzien. de vertices zijn nu eenmaal ontzettend goed parallel te verwerken.

Door Hielko, maandag 14 maart 2005 19:47

Volgens het artikel van AnandTech kan de overhead van alle DirectX API Call's en het OS in sommige gevallen ruim 50 procent zijn van de totale processor belasting. Best nog een flinke hap dus.

Door catfish, maandag 14 maart 2005 19:59

kan wel zijn, maar 3dfx en nu ook nvidia slagen erin de gfx te verdelen over 2 identieke kaarten, dan moet dat voor cpu's ook kunnen

Door Jack Flushell, dinsdag 15 maart 2005 09:48

kan wel zijn, maar 3dfx en nu ook nvidia slagen erin de gfx te verdelen over 2 identieke kaarten, dan moet dat voor cpu's ook kunnen

Kwestie van totaal niet weten waar je over blaat.
Een scherm in 2 stukken verdelen is stukken eenvoudiger dan software maken dat dual threaded is.

Bovendien zijn de prosessormakers er DUS al in geslaagd dual cores te maken...

Na ja.. je reactie is zo

dat het gewoon moeilijk is erop te reageren...

Door Green.Velvet|IA, maandag 14 maart 2005 20:04

Bij games ligt de bottleneck toch meestal bij de Video kaart. CPU heeft hier weinig invloed op (vanaf een bepaald niveau). Dus dan snap ik niet waarom dual core dan voor games prestatie winst oplevert?

Jij hebt duidelijk nog nooit nagedacht hoeveel rauwe CPU power er bij komt kijken om de collissions te testen in een 3D high speed shoot-m-up met heel veel objecten. Om dat wat deftig te doen is het 1 redelijk complex en heb je 2 veel power nodig.

Door henk_DE_man, dinsdag 15 maart 2005 12:20

Dit is toch eigenlijk niets nieuws?

Arcade systemen gebruiken al jaren lang meerdere CPUs. Tripple 68000 had je al in de jaren 80.

Op console gebied was de Sega Saturn een extreem voorbeeld van multi-cpu hardware. De general purpose CPUs waren een Dual Hitachi SH-2, maar er waren daarnaast vele andere co-processors aanwezig.

Of het door verkeerde marketting kwam, een slechte developper kit, of gewoon domme pech, maar zowel de consument als de developper

op het ding. Heel erg jammer, want de potentie was hoog.

Ik hoop dus dat het dual core of mischien zelfs wel SMT / dual core / dual cpu verhaal voor de PC games niet hetzelfde lot zal ondergaan.

Door Olaf van der Spek, maandag 14 maart 2005 20:15

Bij games ligt de bottleneck toch meestal bij de Video kaart.

Er bestaan meer game genres dan FPS hoor. En zelfs bij FPS is de CPU niet altijd de bottleneck.

Heb je het nieuwsbericht over de physics processing unit gezien?
Zoveel CPU bottlenecks zijn er dus nog.

Denk bijvoorbeeld eens aan een RTS waar AI (onder andere path finding) voor honderden units moet worden gedaan.

Denk ook aan bijvoorbeeld achtergrondtaken (VoIP, p2p, etc).

Door Ikke_Niels, maandag 14 maart 2005 20:49

In geval van windowed spelen speelt je processorkracht ook een hele grote rol.

Door nAFutro, maandag 14 maart 2005 23:37

Als je bedenkt dat je soms met onboard geluid bijna 10% van de fps kan verliezen is een dual core toch wel een leuk idee. En anders kun je misschien ander processor taken tegelijk doen, encoden van muziek, beetje rommelen met vmware/virtual pc...

Door H!GHGuY, maandag 14 maart 2005 19:34

op zich zijn huidige games toch ook al multi-threaded?
alleen worden deze dan door 1 proc afgewerkt zodat er minder kans is op synchronisatiefouten.

of heb ik het hier fout?

ik denk echter dat een multi-core/threaded aanpak ook niet zo moeilijk hoeft te zijn.
als je de juiste taken in aparte threads stopt, kan je zo mooi knutselen om ze wat uit te balanceren en eventueel kun je met prioriteiten en pauseren van threads die tijdelijk klaar zijn wel tot een mooi vloeiend geheel kan komen. Maar dit is natuurlijk slechts een theoretische en simpel verpakte oplossing...

Door Hakker, maandag 14 maart 2005 19:37

er zijn maar weinig games die daadwerkelijk van meerdere cores gebruik maken... De Quake en Doom 3 engine zijn er een voorbeeld van maar daarnaast zou ik er zo snel niet meer 1 kunnen verzinnen.

Door zonoskar, maandag 14 maart 2005 21:21

De DOOM3 engine is (was bij release van D3) niet multi-threading. Ik ondervond iig geen prestatie winst op mijn dual Xeon machine.

Door cc bcc, maandag 14 maart 2005 21:33

Doom 3 loopt op 1 cpu, en Q3 was wel multithreaded maar dat was bij een update komen te vervallen.

Door TBCdevil, maandag 14 maart 2005 19:37

ik ben ook van die mening, dit komt allemaal ten goede voor de steeds complexere architectuur die in games wordt gestoken.

Door SG, dinsdag 15 maart 2005 19:18

"op zich zijn huidige games toch ook al multi-threaded?"
Nee OS zijn al lang Multitread maar dan in time sliced schedular achter mekaar.
Apps en vooral games zijn vaak groten deels niet multitread.
Veel Games gebruiken mischien al wel een extra threadje voor taken die anders de boel platleggen zoals load thread's

Als je Load Threads een game SMP enabled mee bombadeerd dan klopt het wel

Maar 'n skiboxje op 'n XL wielbased sprinter Merc bus is ook geen load verbetering in tegenstelling tot een dubbel assige aanhangwagen.

Echt SMP is als je zware taken splits in thread''s

Door rtgo, maandag 14 maart 2005 19:35

De huidige games zullen wellicht weinig winst behalen met meerdere CPUs/CPUcores maar de toekomst ligt toch in dat type processors. En aangezien computers niet alleen voor hi-end games worden gebruikt zullen de ontwikkelaars zich toch maar moeten aanpassen.
Ik geloof zelf niet dat het uiteindelijk duurder wordt om spelletjes te ontwikkelen. De kennis voor multithread programeren neemt natuurlijk gewoon toe als het normaler wordt om het te gebruiken. Het zal dus wel een kwestie worden van door de zure appel heenbijten.

Door TheOneLLama, maandag 14 maart 2005 19:56

Bedenk ook dat waarschijnlijk de consoles van de "grote 3" (in ieder geval Sony en MS) multicore zijn.

Sterker nog, dit zijn straks "in-order" procesoren, wat betekend dat als je huidige complexe code (zoals AI) erop zou draaien (die niet gebruik kunnen maken van de nieuwe snellere graphics / floating point / vector), de performance stukken minder wordt als op de huidige systemen. Het zal daarom cruciaal zijn dat er gebruik wordt gemaakt van parrallelisatie.

Door solatis, maandag 14 maart 2005 22:56

Precies! Parallel computing wordt met de dag normaler; tegenwoordig krijgt elke programmeur op z'n hbo of academische opleiding wel met threads en de bijkomende problemen ( synchronizations, deadlocks, race conditions, etc ) te maken...

Bijkomend effect is dat de softwarewereld zich steeds meer gaat beseffen hoe handig design patterns zijn; onderzoekers lossen lastige, generieke problemen op en beschrijven de oplossingen in de vorm van pattern languages. Deze kunnen dan in projecten gebruikt worden ...

Door cdwave, dinsdag 15 maart 2005 11:31

Parallel computing heeft niks met threads te maken. Je moet hierbij meer denken aan het gelijktijdig kunnen uitvoeren van berwerkingen die onafhankelijk zijn, zoals in het stukje (4 waarden optellen):

x := a + b;
y := c + d;
s := x + y;

In bovenstaand stukje code kunnen de eerste twee regels parallel uitgevoerd worden, want ze zijn onafhankelijk. De derde moet wachten op het resultaat van de eerste twee regels. Om hierbij over threads te praten is onzin - als je deze code door twee threads zou laten uitvoeren zou je meer CPU tijd verstoken in beheer van semaphoren (wachten op de eerste resultaten x en y) dan in de werkelijke berekening. Een "slimme" CPU zou dit door hebben en als hij over twee "ADD" circuits beschikt een bewerking als s := a+b+c+d de helft sneller kunnen uitvoeren (2 ipv 3 cycles nodig)

Patterns zijn een goed idee maar verspreiden zich als een kwaadaardige ziekte door de code door incompetente programmeurs die hun onkunde erachter willen verschuilen. Het doel lijkt tegenwoordig te zijn om zoveel mogelijk patterns in je code te stoppen, in plaats van gewoon te gebruiken wat je echt nodig hebt.

Door SG, dinsdag 15 maart 2005 19:09

Pattern moet je zien als een middel " om het wiel steeds opnieuw uit te vinden" tegen te gaan.
Pattern's zijn beproefde oplossingen voor bepaalde problemen. Wat in houd dat je weer wat inkort op software design tijd. Toverwoord is re-use. Wat goed is voor time to market.
Voordeel is je krijgt een robust en manageble design die ook redelijk uitbreidbaar is in een korte tijd.
Nadeel kan zijn Pattern's zijn niet toegespits op performance.
Maar dat hoeft geen probleem te zijn Complexe game design eisen een hogere orde benadering ivm design en managing ervan dit gaat te koste van wat snelheid maar men wint tijd en minder bugs door de systeem eisen ietje te verhogen.
Optioneel kan je in het design gaan hacken/optimizen voor performance zelfs zover dat het niet meer conform het design is door short cuts en veroorzaakt twee maal zo lange tijd Q&A testing. Dan als er een design aanpassing komt heb je grote problemen.

Game script engine geld ook het zelfde heel flexible. Verkort game ontwikkeling aanzienlijk, maar kost ook performance maar de voordelen zijn veel groter dan het nadeel.

Ik neem aan dat een beetje sucsesvolle Game software huis wel raad weet met pattern's en die ook optimaal toepast. Of heb je het over indie game developers. Die zijn vrij in hun doen en laten wat voor methode maar te gebruiken. en hebben nog vaak niet die ervaring van de gevestigde orde.

Door BenTheMan, maandag 14 maart 2005 19:37

Is het niet duurder omdat het een nieuwe manier van werken is en deze nog doorontwikkeld moet worden om er efficient mee om te kunnen gaan?

Door mjtdevries, dinsdag 15 maart 2005 10:47

Je sluit de spijker op zijn kop.

De game-wereld heeft nul komma nul ervaring met multithreaded programmeren. En dat kost ze dus nu heel veel extra programmeer tijd omdat je op een andere manier moet gaan denken/ontwerpen.

Wat dat betreft is de game wereld vreselijk conservatief. Ook wat betreft AI bv. Dat kostte altijd veel te veel cpu tijd dus werd er gecheat.
Nu hebben we bij veel games cpu tijd over, maar nog steeds zitten AI's zwaar te cheaten.

Galciv dat door Anandtech werd aangehaald heeft een hele sterke AI zonder te cheaten. Maar als je het de developer vraagt dan vind hij het helemaal geen bijzondere AI.
Maar hij had gewoon geen ervaring met games, en ging dus niet automatisch een AI schrijven die zat te cheaten. En daardoor kwam ie dus met de beste AI die ooit in een game is gemaakt. Dat zegt toch wel iets nietwaar?

Overigens is Galciv ook multithreaded omdat de developers nooit in het stramien van het singlethreaden vastgezeten hebben. Bij OS/2 werd multithreading gigantisch gepushed, en als beginnende developers gingen zij dus automatisch threads gebruiken.

Wat dat betreft is het dan ook erg jammer dat Anandtech geen interview met Brad Wardell (ontwerper van Galciv) heeft gehouden, want hij heeft immers al vele jaren ervaring met multithreading in games.

Wat ook jammer is, is dat anandtech niet even heeft getest in hoeverre multicores enige zin hebben bij hedendaagse games. (Al was het maar een bevestiging dat het geen zin heeft)

Door fidelio675, dinsdag 15 maart 2005 12:10

Dat is zwaar overdreven. Elk spel wat netwerk/multiplayer ondersteunt gebruikt wel degelijk threads. Je kan netwerk communicatie echt niet singlethreaded afhandelen.
Dus ik denk dat het wel zal meevallen met dat nul kommal nul ervaring.

Sommige games zijn vrij eenvoudig, die updaten elk frame de positie van een tiental vijanden en de positie van de kogels die je hebt afgeschoten. Maar games met enkele honderden tegenstanders en ingewikkelde pathfinding kan de updates in een aparte thread uitvoeren, een voordeel is dan ook dat het blijft lopen zelfs al haperen je frames wat.

Door mjtdevries, dinsdag 15 maart 2005 14:38

Alleen heb je er geen zier aan dat netwerk communicatie multithreaded afgehandeld wordt, want dat vreet geen bergen cpu!
(Vandaar ook mijn opmerking over het testen van huidige games, want dan had je dat meteen kunnen constateren)

Wat betreft je opmerking over het gebruiken van threads in games ben ik het met je eens. Ik heb hier al vaak betoogd dat je op vrij simpele wijze effectief gebruik kunt maken van threads in games zonder dat je voor deadlocks bang hoeft te zijn.

Neem alle realtime spellen met meerdere tegenstanders. Voor elke tegenstander kun je een aparte thread gebruiken omdat die in realtime spellen toch onafhankelijk van elkaar de AI berekeningen moeten kunnen doen.
Voor met name vliegsimulators die altijd zeeer zwaar cpu limited zijn kun je al heel makkelijk grote presatiewinst halen op die manier.

Door ijdod, dinsdag 15 maart 2005 15:17

Die multithreading valt denk ik in de praktijk nogal tegen. Dat de API en OS/drivers in feite aparte threads zijn is logisch, dat zijn feitelijk andere applicaties. maar dat wil nog niet zeggen dat dit in de game zelf ook multithreaded wordt gedaan.

Als ze de netcode op die manier scheiden, zou je ook al verwachten dat ze hetzelfde doen met de GFX en AI.

Door Franckey, maandag 14 maart 2005 19:40

Dit geld niet alleen voor games maar voor alle software dat software speciaal ontworpen moet zijn om meerdere CPU's te gebruiken. Toch kan 2 CPU's in 1 systeem wel nuttig zijn omdat Windows zelf op 1 CPU kan draaien en alle app's op de 2e CPU gestart kunnen worden. Zo heb je minder last van het feit dat Windows steeds meer CPU tijd nodig heeft.

Door Bram77, maandag 14 maart 2005 19:49

Er zou eigenlijk een soort multi-thred applicatie moeten komen die er b.v. voor zorgd dat ook single-tread programma's multi- kunnen draaien. Een soort parser? (of noem je dat anders in deze situatie?) Anders wordt het produceren van software veel duurder (tijd rovender) en complexer.
In deze context denk ik dat het niet ten goede zal komen van de software. Als de software duurder wordt, zullen de meeste kopers kiezen voor de goedkopere, single-thread software. De producenten zullen dus proberen te zorgen dat het produceren van de multi-thread software zo min mogelijk tijd in beslag zal nemen om te kunnen concureren met de multi-thread software. Waardoor de kwaliteit van de software niet omhoog zal gaan.

Door Franckey, maandag 14 maart 2005 21:00

Compilers zouden automatisch meerdere CPU's moeten gebruiken als er in een programma meerdere threads worden gebruikt. Dan valt het ontwikkelen van software wel mee, het hoeft niet moeilijker te zijn dan het nu is om met meerdere threads te werken.

Door reddog33hummer, dinsdag 15 maart 2005 00:40

Het grote probleem is dat zodra je normale singe threaded programm's gaat parralleliseren je nondeterminisme krijgt. Als je iets dus paralell maakt verander je het gedrag. Om iets parallel te maken zonder dat het gedrag veranderd is bijna onmogelijk.

Door wouter veltmaat, dinsdag 15 maart 2005 00:45

Voor oa OSX en Unix smaken is er vanuit het OS (extra) ondersteuning voor dual core hardware dus wat dat betreft hoeft ook het Wintel platform hier niet in achter te blijven.
Maar een ontwikkelaar kan niet zomaar lukraak processen aan verschillende CPU's aanwijzen. Daar moet nog steeds over worden nagedacht.

Door mjtdevries, dinsdag 15 maart 2005 10:51

Sorry hoor, maar als je nou duidelijk totaal niet weet waar je het over hebt, houd dan gewoon je mond.

Elk OS dat ondersteuning heeft voor multi-cpu systemen heeft automatische ook ondersteuning voor multi-core. Voor het OS gezien zit daar namelijk geen verschil in.

Verder zal een ontwikkelaar ook nooit processen aan verschillende cpu's toewijzen. Dat is namelijk een taak voor het OS.
Het enige waar een ontwikkelaar voor moet zorgen, is dat er verschillende taken (threads) lopen zodat het OS die kan toewijzen.

En dan maakt het ook niet uit of je 1 of 2 of 4 processoren in je systeem hebt. Je OS zorgt er altjid voor dat de taken zo goed mogelijk verdeeld worden.

Door catfish, maandag 14 maart 2005 19:55

Het ontwikkelen van multi-threaded software is aanzienlijk complexer en duurder dan het ontwikkelen van single-threaded software waardoor het deels slechts probleemverplaatsing is. In plaats van het hardwareontwerp wordt het softwareontwerp de kritieke factor om hogere prestaties te kunnen halen. Desondanks is het een technologie met erg veel potentie.

intel heeft al jaren geleden (bij de start van het itanium project) dat dit toch de juiste weg is
hardware wordt namelijk ook alsmaar complexer = grotere kans op fouten en cpu's zijn veel moeilijker te patchen dan een stuk software... het lijkt mij logisch waar de toekomst dus zit

kijk naar de cell chip van IBM/Sony, dit is ook multicore based

Door mjtdevries, dinsdag 15 maart 2005 10:53

De hele business weet al jaren dat dit de juiste weg is. (IBM heeft multithreading al zeer zwaar gepushed bij OS/2 Warp)

Alleen de game industrie loopt op dit gebied gewoon vreselijk achter.

Door b3n666, maandag 14 maart 2005 20:08

Waarom maken zie niet een soort load balancer in de software? Dat gebeurt ook bij gpu's (sli en ati's versie daarvan). Het kan toch nooit zo heel veel werk zijn om een stukje software te laten checken of er 2 cores aanwezig zijn en als dat het geval is de taken te verdelen onder de cores.

Ik heb er niet echt veel verstand van ofzo maar het lijkt mij dat als je een soort driver voor multicores voor een game maakt dat dat nooit zo heel erg duur kan zijn. Plus dat je in de game zelf niks hoeft te proggen wat weer minder tijd kost en het minder moeilijk maakt. Het maken ervan kost dan wel weer tijd maar die was je toch al kwijt en op zo'n manier kan je het imo ook makkelijker upgraden.

Door Hielko, maandag 14 maart 2005 20:11

Je vergeet iets; de taken die je hebt moeten wel te verdelen zijn over meerdere processors. Als je bijvoorbeeld als de volgende twee berekeningen wilt doen:

1) x := 10
2) x := x + 1

Dan heeft het geen enkel zit om instuctie 2 tegelijk met instructie 1 uit te voeren, want instructie 2 heeft het resultaat van instructie 1 nodig voordat ie kan beginnen.

Door kipusoep, dinsdag 15 maart 2005 09:31

Misschien sla ik de plank volledig mis maar volgens mij klopte er iets niet:

1) x := 10
2) x := x + 1

Moet dat niet zijn:

1) x := 10
2) z := x + 1

Anders staat er namelijk

2) 10 := 10 + 1

Door phaas, dinsdag 15 maart 2005 09:37

Als x geen constante is, zie ik het probleem niet zo.

Door abraxas, maandag 14 maart 2005 20:12

wat jij voorstelt is helaas onmogelijk, omdat je in tegenstelling tot bij load balancing met afhankelijkheden zit... "normaal" in een game engine wordt het ene na het andere uitgevoerd.. hierdoor is de volgorde van wat er gebeurt 100% voorspelbaar.. multithreaded zal deze aanpak herzien moeten worden. geluid is afhankelijk van gebeurtenissen in de physics bijvoorbeeld, wanneer physics berekent worden en de frame nog niet gerenderd is maar de physics thread weer tijd krijgt, zal er wederom physics berekend worden.. betekent dit dat de vorige physics berekeningen genegeerd mogen worden? lijkt me niet, een collision situatie zal alsnog gerenderd moeten worden.. tis maar een voorbeeld, maar zo zijn er werkelijk duizenden te verzinnen.

Door Steffy, maandag 14 maart 2005 20:13

Ik weet dat er in ieder geval 1 game is die er gebruik van maakt en dat is Quake 3. Vroeger draaide Quake 3 duidelijk beter op een Dual P3 weet ik wel, in de tijd van de voodoo 2 en 3. Of het zinvol was is een 2e maar voor de gein proberen was altijd leuk.

Of de extra proc zin heeft is ook maar de vraag, physics bv heeft men al een andere oplossing voor die zelfs sneller is dan een 2 CPU, die extra kaart die er voor op de markt gaat komen. En AI is ook maar de vraag, geen enkele game die ik gespeeld heb heeft AI, alles wat voor AI door moet gaan tegenwoordig is gewoon slecht, HL2 zou super AI hebben en dat was zelfs brak te noemen, van AI kunnen we nie spreken en kan me niet voorstellen dat de AI die nu gebruikt wordt berekent moet worden, of ze gaan er in de toekomst pas gebruik van maken maar dan is het zeker op dit moment voor AI niet nodig, Animaties lijken me ook geen processor vreten en geluid zal mits je een goeie geluidskaart hebt ook niet echt nodig zijn.

Kortom, ik twijfel er zelf sterk aan, op dit moment lijkt het mij niet zinvol maar misschien ligt het over 2 jaar anders hoor, dat kan best.

Door Makkelijk, maandag 14 maart 2005 21:49

De meeste simulatie games hebben wel weer een AI die enorm veel processor tijd op eet, zoals RCT3. Dit komt niet omdat de AI zo geniaal is, maar omdat er zo veel individuen in je spel rondlopen.. die zouden hiervan kunnen genieten doordat je de AI dedicated op de ene processor doet, en de berekening van physica, graphics en geluid op de andere..

Door El_Muerte_[TDS]541, maandag 14 maart 2005 20:18

Beetje off-topic maar de fout word zo vaak gemaakt.
Het is UnrealEngine 3 niet Unreal 3 Engine. Epic voert nu (eigenlijk al een redelijke tijd) een wat meer consitente naamgeving voor hun engine, het heet nu gewoon UnrealEngine met daar achter een major achtig iets.

« 1 2 3 »

Op dit item kan niet meer gereageerd worden.

19:52	Philips werkt aan nanogeheugen
15:40	Hackers overheid veroordeeld tot cel- en taakstraffen

Nieuws I/O

Shortcuts

Categorieën

Gerelateerde content

Reacties

13:01 Nieuws

16:49 Productreviews

17:48 Vraag & Aanbod

25-05 Jobs

16:41 Etc.

17:51 Reacties

17:53 Forum

25-05 Gesponsorde acties

00:16 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines