Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 99 reacties
Bron: ExtremeTech

Valve heeft aangekondigd dat het een multithreaded versie van zijn Source-engine gaat bouwen. Het bedrijf ziet het gebruik van meer dan een rekenkern als 'de belangrijkste ontwikkeling sinds 3D-kaarten.' Met name de introductie van quadcore-cpu's belooft volgens Valve veel goeds: 'Vier cores zijn meer dan twee keer zo interessant als twee cores', aldus developer Tom Leonard. Met twee cores kunnen de framerates opgevoerd worden, maar met vier cores komt er genoeg capaciteit beschikbaar om complexere systemen mogelijk te maken. Rook- of misteffecten zouden bijvoorbeeld een stuk realistischer kunnen worden, en om dat te bewijzen zal het bedrijf binnenkort een 'particle physics'-benchmark uitbrengen die optimaal van de schaalvoordelen van multicoresystemen gebruikmaakt.

Valve logoHet grootste probleem dat multithreading voor gameontwikkelaars biedt, is hoe het werk het beste over de verschillende cores verdeeld kan worden. Als elke core een aparte taak krijgt, wordt de aanwezige rekenkracht niet optimaal benut, en bovendien is het lastig om de diverse taken synchroon af te handelen. Een ander alternatief is om taken in veel kleine, vergelijkbare stukjes te verdelen, maar lang niet alle rekenwerk leent zich voor deze benadering. Valve wil een mengvorm van deze twee benaderingen gebruiken, die het bedrijf 'Hybrid Threading' heeft genoemd. Door de technologie zoveel mogelijk in de Source-engine te verwerken, hoeven de programmeurs zich niet meer met de threading-architectuur bezig te houden en kunnen ze zich concentreren op het spel zelf. De engine moet ondertussen zorgen dat de cores optimaal benut worden.

Prototypes van de software schalen volgens Valve-gamegoeroe Gabe Newell uitstekend op de drie cores van de Xbox 360, en toepassing in games zal volgens hem dan ook niet lang op zich laten wachten. Daarbij speelt het online distributiesysteem Steam een belangrijke rol: zodra de hybrid-threadingsoftware klaar voor gebruik is, krijgen Valve-klanten deze op hun pc. Voor Episode 1 van de populaire Half-Life-franchise zal binnenkort een upgrade worden uitgerold waarmee multicorechips betere framerates zullen produceren, en met Episode 2 moet een volwassen Hybrid Threading-engine zijn debuut maken. Die software wordt in de eerste helft van volgend jaar verwacht.

Heel veel losse deeltjes in Half-Life 2
Moderatie-faq Wijzig weergave

Reacties (99)

Ik moet wel zeggen dat Valve altijd voorop loopt met de nieuwste technologien. Ze waren ook 1 vd. eerste developers die 'n 64bits game uitbrachten.
Hoezo een van de eerste? Quake 3 had al SMP en Unreal heeft het ook al eeuwen geleden aangekondigd. Dit zijn er slechts twee, maar wel twee gigantische.
EDIT: he gets verslagen.
Dat Source trouwens niet op Linux is komt gewoonweg omdat het met DirectX is gemaakt. Quake is op OpenGL gebouwd (John Carmack is een groot voorstander van open source). Unreal 3 gaat ook draaien op DirectX dus die zal later naar Linux komen als 'ie überhaupt wordt geport.
Quake is op OpenGL gebouwd (John Carmack is een groot voorstander van open source)
Deze twee gedeeltes van de zin hebben echter geen zak met elkaar te maken :). OpenGL is niet "open source", het is een graphics API die op veel platformen beschikbaar is. Je zou echter ook best een Direct3D op Linux kunnen implementeren.

De reden dat Quake op OpenGL draait heeft puur en alleen te maken met het feit dat OpenGL ooit wat lekkerder werkte dan Direct3D deed, maar dat is sinds versie 8 van D3D al niet meer zo en Carmack heeft dat ook allang toegezegd. Maar ja, als je ervaring hebt met ogl én het draait ook nog eens op linux en mac, waarom zou je dan overstappen? :)

Overigens heeft Carmack ook al aangegeven dat hij de X360 een heerlijk platform vind om op te ontwikkelen (en dat ben met 'm eens, hoewel de hoge memory latencies wel ruk zijn omdat debug builds dan extra sloom draaien), en daar heb je geen OpenGL op draaien. Boeit ook niet, want een 3D rendering API is gewoon een 'means to an end' en ze verschillen helemaal niet zoveel van elkaar, dus welke API je ook pakt, het gaat toch wel vrijwel op dezelfde manier.

Reken er trouwens maar op dat de komst van Direct3D 10 een enorme vuiststomp in de maag van OpenGL zal zijn in de gamesindustrie als het ogl consortium de nieuwe features niet snel genoeg standaardiseren (niemand zit erop te wachten om voor ATi en nVidia hardware verschillende codepaths te implementeren, zeker niet als D3D dat zo heerlijk wegabstraheert), en gezien de logheid van het consortium zal dat wel niet.
OpenGL bevat het woordje "Open" omdat het ook "Open" is.

Dat je bij de nVidia drivers nou niet de source krijgt is wat anders (en die hebben hun eigen libgl.so)

Maar OpenGL is wel degelijk Open.
Open Technologie.
Ach, wat heeft Direct3D 10 nu helemaal te bieden dat OpenGL niet allang heeft? Telkens als ze wat nieuws hebben in Redmond is het weer "Oh oh oh, deze nieuwe Microsoft technologie gaat de wereld helemaal veranderen! De concurrentie gaat weggevaagd worden!" En uiteindelijk gebeurt er dan altijd... Helemaal niets.

http://en.wikipedia.org/wiki/Direct3D#New_Features

Het enige wat OpenGL niet allang heeft is geometry shaders. Nou, op naar OpenGL 2.2 dan... En dingen als "paging of graphics memory" ed. lijken me een kwestie van een driver update, en dan kan al je OpenGL software met die feature overweg. Lijkt me een stuk handiger dan dat je weer een hele nieuwe API moet leren...
Ach, wat heeft Direct3D 10 nu helemaal te bieden dat OpenGL niet allang heeft?
Goede (hardware-onafhankelijke) support voor rendertargets, geometry instancing, texture wrapping (niet coordinate wrapping, maar dit: http://msdn.microsoft.com...tures/texturewrapping.asp)...

Er is vast nog veel meer, maar ach.
Het kan ook geen toeval zijn dat de laatste tijd steeds meer grote engines op Direct3D overstappen. Carmack wordt een beetje de laatste der Mohikanen.
Direct3D ondersteunt features vaak gewoon eerder en/of beter dan OpenGL, en dat scoort bij developers. Zelfs bij Carmack, getuige zijn uitlatingen over de XBox360.
@merethan:
Maar OpenGL is wel degelijk Open.
Open Technologie.
Dat ontken ik ook helemaal niet, maar het is geen open source, hence mijn punt. Overigens kun je afvragen wat dat woordje Open nou eigenlijk betekent. Sure, je mag vast geen DirectX implementeren op linux en dat vervolgens DirectX noemen, maar niemand kan je tegenhouden om dezelfde interface onder een andere naam te releasen. Het netto resultaat is hetzelfde.

@hansg:
Momenteel vrij veel. Maar dat is het punt helemaal niet, het punt is dat D3D10 alle features op een standaard manier ondersteunt, transparant van de gebruikte hardware. OpenGL heeft daar in het begin altijd veel moeite mee gehad - zo werkten de shaders in den beginne op nVidia hardware anders dan op ATi hardware, omdat shaders nog niet waren opgenomen in standaard opengl en de vendors dus met hun eigen incompatible extensions kwamen. De extensions maken OpenGL flexibel, maar het is ook meteen haar zwakste punt. In D3D werkt alles gewoon out-of-the-box op een standaard manier, en voor nieuwe features zul je dan helaas moeten wachten op een nieuwe update van de API.

OpenGL heeft nogal lang gedaan over versie 2.0, en pas toen het uitkwam kon het zich eindelijk meten met D3D8. Nu is D3D10 weer een enorm drastische verandering tov D3D9, en de meeste developers nijgen nu al naar D3D. Als D3D10 straks uit is en het duurt weer een hele tijd voordat OpenGL met een fatsoenlijke update komt, zullen de meeste devvers al D3D10 gebruiken. Zeker gezien het feit dat OpenGL's leven op Vista niet helemaal zeker is. Voor de meeste gamedevelopers zijn andere PC platformen dan Windows namelijk helemaal niet interessant, en als je dan moet kiezen tussen een cleane API in de ene hand en eentje die een brei van (non-standaard) extensions is in de andere, dan is de keuze wel vrij snel gemaakt.
de Unreal3 engine is tegelijk geport als de console versies aangezien de PS3 ook OpenGL gebruikt ;)
er is een port voor Linux en Mac OS X "niet gek aangezien de Linux developer ook de mac versie doet".

de unreal3 engine is 100% cross-platform sinds dat Ryan Gordon de basis code geport heeft naar Linux/OSX.

*edit* Gordan in Gordon
Quake 3 had er wel een cvar voor maar als ik het me goed herinnerde merkte je daar zo goed als niks van (edit: in patch 1.32 die uitkwam na ik gestopt was met Q3 schijnt er het eea veranderd te zijn daar aan), en Unreal Tournament 2007 (en andere games op Unreal Engine 3.0) moet nog uitkomen. Denk dat je van Valve wel mag zeggen dat ze de eerste zijn die SMP toevoegen aan de huidige generatie games, iets dat waarschijnlijk wel weer ingewikkelder is geworden aangezien games complexer worden met physics enzo.
Helaas voor mij als Linuxer met een een dual CPU machine had +r_SMP 1 op Quake3 geen merkbaar effect, omdat de SMP routines op Linux erg anders waren als op Windows, daarom zou het later nog een keer voor Linux komen. (ze deden Windows eerst vanwege de grotere gebruikers groep, Linux is niets meer van gekomen.) Ik meen dat het wel al in IOquake3 zit. (de doorontwikkelde Quake3 Engine van Icculus.org)
Gears of War komt al zeer binnenkort uit, en maakt gebruik van alle drie de cores van de XBOX360, deze game is ook gebouwd op de Unreal 3.0 engine. ik zie echt niet waarom Valve nou zo vooruitstreevend is, al wacht ik wel met smart op een HL2 engine met nog betere effecten :)
Vooruitstrevend omdat ze schijnbaar een framework hebben gecreeerd die veel moeilijk werk uit handen neemt en gelijk makkelijker toepasbaar is op andere multicore omgevingen dan bijv. de XBox360 (= lees PC en misschien in de niet zo zeer nabije toekomst ook PS3...).
Hiermee kunnen de meer junior programmeurs meteen beter werk leveren. Gemak dient de mens.
Mjah,

Dit valt naar mijn idee wel wat tegen.

De jongens achter Unreal en Quake zijn minstens net zo vooruitstrevend.
Het zijn gewoon engine bouwers.

Zo ondersteunen ze bij Valve nog steeds geen Linux binaries, waar ze deze bij Quake en Unreal al tijden beschikbaar zijn.
Dus jij meet de innovativiteit aan de hand van het beschikbaar zijn van Linux binaries? Lekker boeiend...aangezien de meeste gamers Windows gebruiken en dan de rest hoofdzakelijk Apple gebruikers zijn...
Geen linux bin's? dan gebruikt het vaak erg veel code van vooral MS waardoor het moeilijk innoverend kan zijn.
Dus - even deze redenatie volgend - exact hetzelfde product, met exact dezelfde features kan volgens jou wel innovatief zijn als het in Java is geprogged en niet innovatief zijn als MS C# is gebruikt als programmeertaal???
Waar slaat dat op? Nofi verder, ik heb veel pro-Linux nonsense gehoord in mijn leven, maar dit slaat werkelijk alles.Wat heeft de gekozen script/programmeertaal te maken met hoe innovatief een product is?

Ik ben zelf software-ontwikkelaar, en voor de innovatieviteit en featurerijkheid van een product maakt het over het algemeen totaal niet uit welke taal wordt gebruikt. Met VB, C++, Java, C# etc. kun je in principe gewoon exact hetzelfde voor elkaar krijgen. Bovenstaande redenatie - dat innovativiteit afhankelijk is van gekozen platform - is zo non sequitur als ze komen, en heeft weinig anders dan jouw persoonlijke voorkeur voor Linux als basis.

Games ondersteunen op dit moment nauwelijks multi-core, en zeker geen physics op multicore. Dat Valve dit wel gaat doen is innoverend, en daarbij maakt het totaal niet uit of ze dat doen m.b.v. C# of m.b.v Java (of enige andere taal die wel jouw goedkeuring kan wegdragen).
Multi-platform is een keuze/feature, niet een graadmeter voor de innovativiteit van een bepaald product, en zeker niet voor de innovativiteit op gebied van multi-core gebruik voor physics.

@MooieLaarzen hieronder:
Ach, dat zijn we wel gewend hoor. Moderatie als volgt:
* Pro-Linux statment (ongeacht of er iets van klopt): Score++
* "Negatieve" reactie op pro-Linux statement (ongeacht of die klopt): Score--
;)
Zie ook de post van lolandros hieronder.

Ik meet het onder andere aan het beschikbaar zijn van linux mede omdat dit aangeeft dat de engine zelf een groot deel van de problemen zelf oplost.

Grafisch een eigen render engine die niet alleen directX gebruikt (opengl), Eigen scripttaal, en niet leunend op .NET, (uscript + compiler), SMP opties, file system abstractie (unreal,quake) etc etc.

Meestal is het al dan niet beschibaar zijn van linux binaries een erg goede indicatie hoe de rest van de source in elkaar steekt. Geen linux bin's? dan gebruikt het vaak erg veel code van vooral MS waardoor het moeilijk innoverend kan zijn.
@killercow:

Je redenering gaat niet op. Je beweert nu dat een engine vooruitstrevend is als hij alles zelf doet en ieder wiel opnieuw heeft uitgevonden.

Je kan moeilijk vooruitstrevend zijn als je eerst alle basisfunctionaliteit zelf moet ontwikkelen, en dan pas aan de nog-niet-bestaande features kan beginnen.
@killercow

opengl en directx zijn beide bestaande api's, dus dan zou geen enkel spel innovatief zijn :P

Ik wil er wel in mee gaan dat games voor Linux ontwikkelen innovatief is, hoewel dat ook steeds vaker gebeurd. Maar dat je daarmee kunt stellen dat als iets niet voor Linux is ontwikkeld is, het minder innovatief is gaat wat ver. Kunt ook prima op andere fronten innoveren.
Ook dat klopt niet, als jij de eerste bent die 2 APIs koppelt en daarbij een product maakt wat nog niemand eerder gemaakt heeft is het innovatief. Het hele idee dat APIs er invloed op hebben klopt gewoon niet. Met of zonder API, software kun je altijd innovatief maken.

En Valve maakt innovatieve software, dat blijkt uit hun nieuwe idee, maar net zo goed uit hun oude ideeën!
Grafisch een eigen render engine die niet alleen directX gebruikt (opengl)
Alsof het uitmaakt of je DirectX of OpenGL gebruikt. In beide gevallen gebruik je APIs die de hardware voor je aanspreken. Het verschil zit hem in de details... heeft weinig met innovatie te maken.
Eigen scripttaal, en niet leunend op .NET, (uscript + compiler)
Tsja, een scripttaal is een scripttaal. Van het wiel opnieuw uitvinden wordt niemand beter. Bijna alle scripttaaltjes komen toch ongeveer op hetzelfde neer.
Sowieso worden die scripttaaltjes vaak weer met kant-en-klare oplossingen gebouwd als bison/yacc en dergelijke.
SMP opties
Ook daar zal het weinig uitmaken of je een linux-library gebruikt voor threads of de Windows API (behalve dan dat de Windows-API naar mijn mening krachtiger is op dit vlak, waardoor je juist MEER je problemen zelf op kunt lossen, maar ook dit zijn slechts details).
file system abstractie (unreal,quake) etc etc.
Je bedoelt die .PAK files van Quake bv? Dat zijn gewoon zip-bestandjes, ook niet echt innovatief, gewoon even de zip-library geleend. Okee, niet door MS geschreven, maar ook niet door henzelf.

Ik snap ook niet dat je linux als voorbeeld noemt. Op een platform als de PS2 wordt juist veel meer zelf ontwikkeld, omdat daar geen kant-en-klare oplossingen zijn (tenminste, niet als je het een beetje goed wilt laten draaien... de PS2-hardware is zo afwijkend dat je echt geen OpenGL wilt gebruiken, dat is totaal inefficient).
Maar vaak wordt het spel op zich daar niet echt beter van. Wel een leuke tour-de-force voor programmeurs.
Dus met directx en .net kun je per definitie niet innoverend zijn?
Da's natuurlijk onzin.
Waarom wordt Cheetah's post nu weer met 'overbodig' gemodereerd? Hij gaat gewoon inhoudelijk op een bewering in.
Hier ben ik het niet mee eens als jij alle basis functies opnieuw gaat ontwikkellen weet je ook als bedrijf hoe alles in de kleinste detail werkt.

Dit kan best wel veel voordelen hebben om een "vooruitstrevende" engine te bouwen.

ook kan je zo nog-niet-bestaande features ontwikkellen en daarbij de basis functies zodanig aanpassen dat je ook nog een extra performance winst eruit kan halen.

Edit: @Mooielaarzen
@cheetah,

Nee tuurlijk niet, jij kan wel lekker bashen op de pro linux user (want das ook hip, en scoort punten tegewoordig), maar ondertussen leg jij mij woorden in de mond die ik nooit gezegd heb.

Ik ben zelf ook software developper, dus das is een loos argument.

Mijn redenatie is als volgt:
Als een pakket/game engine voor 100% op bestaande api's leunt kan moeilijkER innovatief zijn.
Zelf ontwikkelen ipv directx of opengl/al gebruiken... Ben je echt zo ontzettend dom dat jeniet weet dat er mensen met geld achter zo'n game developer zitten?!
Wat denk je hoe die geldschieters denken?! "Ownee, ontwikkel maar lekker alle api's zelf, ik doe het wel met een paar miljoen winst minder"

Sommige mensen hebben echt geen idee hoe de wereld in mekaar steekt...
kwa linux heeft valvle ook genoeg te bieden.
dus ik snap je punt niet!
Ze lopen helemaal niet zo voor, er zijn al genoeg andere engines die hier ook al lang mee bezig zijn. Het is alleen het feit dat Valve nogal een highprofile heeft vanwege Half Life...
Vast, maar zowat alle andere dingen die ze publiceerden waren al door anderen uitgebracht... Far-Cry ring a bell? ;) Kijk wij hebben physics etc, crytek ook, kijk we hebben SM3, crytek ook, kijk we hebben HDR, crytek ook.
Maar het is wel zo dat je graag het beste uit je hardware wilt halen en het is mooi dat ze daar goed hun best voor doen!
Ik hoop dat ze dan ook wat belasting weghalen van de GPU, zodat mensen met een mindere videokaart maar wel een dual core cpu ook een grafisch zware game kunnen spelen...
Je GPU ga je niet ontlasten met je CPU...daar zijn ze helemaal niet fatsoenlijk tot in staat.
Je gpu is gewoon goed in adnere dingen dan je cpu. lees maar eens over raytracen. Dat wordt ook nog interessant bij 4 cores....
Ik denk dat dit betekent dat er wel degelijk wat werk van de FPU naar de CPU verplaatst gaat worden. Hoe moet ik het me anders voorstellen dat er ze bij Valve gebruik willen maken van multi core cpu's? Als nu 1 core gebruikt wordt, en straks 2 core's zodat er meer gerenderd kan worden, dan komt die extra rendering toch door die extra core en dus door de cpu?
De CPUs doen vooral voorbereidend werk voor het renderen. Zoals het bepalen van wat er wel of niet zichtbaar is, of het animeren van karakters... of natuurlijk de fysica... om maar eens wat te noemen.
Het renderen zelf MOET met de GPU gebeuren, ten eerste omdat een GPU sowieso vele malen efficienter is... ten tweede omdat het bijna onmogelijk is om de GPU en CPU samen te laten renderen.
Het renderen met 2 GPUs (SLI/CrossFire) is vaak al enigszins problematisch.
een CPU doet al een groot deel van de graphics vooral in de source engine.
de GFX word alleen gebruikt om de beelden te renderen.


Valve richt zich vooral op quadcores (of meerdere cores)
dat is ook best logisch. het is echter niet zo dat 1 core voor physics is , 1 core voor ai, 1 core voor graphics, etc omdat ze dan nog vast komen te zitten, alle taken vormen namelijk nogsteeds 1 thread. het aantal taken houd bij 8 toch wel op.
ze willen dus alle taken een oneindig aantal threads kunnen geven, zodat ook het verschil tussen een 8 en 16 core nog zeker uitmaakt voor de performance.
(dus bijvoorbeeld: 6cores/threads voor physics, 4 voor AI, 5 voor graphics, 1 als management)

om te voorkomen dat de threads elkaar in de wielen zullen rijden, is er een aparte core (1 van de 4/8/16/~) die alle threads managed en zorgt dat ze in de goede volgorde uitkomen.

conclussie:
het klinkt aardig maar het gaat je niet veel schelen op je dual core.
Jij weet waar je het over hebt zeg, denk jij dat ze nu spellen gaan maken voor specifiek 4 cores, dat zou enorm dom zijn van valve, ze gaan gewoon proberen zoveel mogelijk asynchroon te laten uit rekenen over meerdere threads, die dan weer onderverdeeld worden onder meerdere cores.

En "een CPU doet al een groot deel van de graphics vooral in de source engine.
de GFX word alleen gebruikt om de beelden te renderen."

Een CPU doet daar niet zo veel voor de graphics alleen voor de voorbereiding, wat is zichtbaar wat niet, en de renders worden echt enkel en alleen door de GRAPHICS (GFX) kaart gedaan.

Half Life 1 kon je wel heel geinig software rendered uitvoeren overigens. Mijn P1-166Mhz 48MB ram draait het nog zo nu en dan :P
Helaas, de reden dat die videokaarten bestaan is juist omdat ze veel beter zijn in het grafische werk dan 'gewone' CPU's. Ik denk dat het niet veel uit zou halen.
Dit geeft toch aan de voordelen die de XBox360 nu al teweeg brengen voor PC spellen.

Tuurlijk zijn er al enkele dual-core PC gebruikers maar het grootste gedeelte van de gamers heeft een single-core systeem.

Doordat de XBox360 een vast hardware platform heeft en de SDK redelijk transparant is om er gemakkelijk een PC versie te maken, heeft het multi-core ontwerpen een snellere vaart gekregen.

Of Valve eerder klaar is dan de Unreal engine voor UT2007 moet echter blijken, want als het goed is, is die ook uiterst geoptimaliseerd voor multi-core.

@Rafe, Als alles volgens de planning gaat, dan komt UT2007 gelijk uit met de PS3 launch, al zou dat de Amerikaanse PS3 launch datum kunnen wezen, dan nog is de kans groot dat het komt voordat Valve klaar is. De XBox360 versie en dus ook de PC versie zullen namelijk zeer snel volgen of tegelijk komen met de PS3 versie.

@the_stickie, de hoogste kloksnelheid ligt nog steeds bij de Single-Core Intel Extreme en AMD FX series. En de meeste high-end gamers maken daar gebruik van. Tevens heb je dan vaak veel meer aan het kopen van zeg een 8800GTX in combinatie met een AMD64 4800+ dan een middelmatige videokaart met een Core2Duo E6800 CPU.
Ik denk eerder dat ze op de PC ontwikkelen en porten naar de Xbox 360 eigenlijk.

Verder:
So how will the technology be brought in? Gabe Newell: "I can see us creating content specifically for the people that have it, in the first place. You can imagine something similar to what we did with Lost Coast. Then, just like we've seen with HDR lighting, the rest of the market catches up and we can roll it out across wider ranges of content."

[..] So, expect a stand-alone piece of content first, coming in before Episode Two launches next year. Then, expect to see the support roll in through future Valve releases, including Episode Two itself. Valve engineers also told us to expect performance improvements in Episode One and other Valve games, although third party mods may not have any performance benefit.
(bron: artikel op Bit-tech)
Volgens de planning dus eerder HL2 geüpdate dan UT2007 uit zal zijn.
Da's het grote voordeel van Steam, ze kunnen hun games 'on the fly' updaten.. In het begin waren veel mensen niet blij met Steam, maar dat systeem begint steeds meer z'n vruchten af te werpen..
De eerste game die gebruik maakt van de Unreal Engine 3 is niet UT2007 (welke zeker niet tegelijk met de PS3 launch zal uitkomen, maar dat terzijde).

De eerste game is Rainbow Six: Vegas / Gears of War (US release vs Europe release, blah blah, scheelt een paar dagen) en die komen beide in de komende 2 weken uit. Ergo de multithreaded UE3 zal zeker voor de multithreaded Source Engine uitkomen (als een daadwerkelijk product dat op de plank ligt)... Maar goed, lekker belangrijk ;)
ach, high-end games worden gemaakt voor high-end gamers met high-end systemen...
Dat jan-met-de-pet nog geen dual systeem heeft boeit dan niet. mensen die persé half-life "de laatste nieuwe" willen spelen hebben al lang een dual-core en anders kopen ze die wel bij hun volgende SLI-setup (oid ;) )
Naderhand zullen dan wel games uitkomen gebaseerd op dezelfde engine die minder veeleisend zijn en/of uitkomen in een tijdperk waarin multicores al meer gemeengoed zijn. B)
Voor Episode 1 van de populaire Half-Life-franchise zal binnenkort een upgrade worden uitgerold waarmee multicorechips betere framerates zullen produceren, en met Episode 2 moet een volwassen Hybrid Threading-engine zijn debuut maken.
Krijgt de originele HL2 ook nog die update of zijn alleen de nieuwere episodes bevoorrecht?
Het zou wel handig zijn met al die gigantische texture packs zoals die van Fakefactory en zo :9
Ze updaten de engine, zowel HL2 als Ep1 en 2 gebruiken de Source engine en zullen dus ook 'geupdate' worden.
Maar de engine update komt pas later (bij HL2: Episode 2). Er komt binnenkort alleen een patch uit voor Episode 1 die ook voor "Hybrid Threading" zou zorgen, maar slechter is dan de echte engine update (die dan voor alle Source spellen geldt...).


Het lijkt me iig een goede zet ;) en het zou heel handig kunnen worden in de toekomst :).

CS 2.0 (of 4.0 als je CS:CZ als 2.0 en CS:S als 3.0 telt) :9~
de engine is dezelfde bij alle source games.
dus HL2 gebuikt inderdaad dezelfde engine als EP2
dus HL2 heeft ook de beschikking over HDR en straks multithreading.
echter heeft HL2 geen content die gebruikt maakt van deze functies (geen HDR maps etc.)
dus ja, het is ook in HL2 beschikbaar, nee het word niet benut.

kijk maar eens in de map van je steamaps.
de source engine is gewoon 1 pakket.
counterstrike, HL2 of wat dan ook, is enkel content. de engine en de versies van deze, zijn overal hetzelfde.
het enige wat verschilt is de content (maps, models, etc)
vraagje, Dark Mesiah gebruikt ook de source-engine, en wordt ook verkocht via steam, maar is volgens mij spel met een eigen install van de source-engine. krijgt de de update dan ook? of wordt die weer los beschikbaar gesteld?

ik heb het spel zelf niet maar meestal als een engine wordt gelicend voor een ander spel gelden dit soort updates niet. kijk maar naar de unreal 1 engine. daar zijn meerder patches voor uitgebracht maar enkel voor unreal 1 en unreal tournament ook echt toegepast.

vraag me af hoe valve hier mee omgaat?
In theorie ja.
Ik verwacht van niet.

Of HL2 kwa interface nog aansluit is nog maar de vraag. Wellicht komen er nieuwe/andere parameters bij kijken richting de interface van de engine.

De praktijk is altijd weerbarstig. API's of geen API's.
Toch wel:
So, expect a stand-alone piece of content first, coming in before Episode Two launches next year. Then, expect to see the support roll in through future Valve releases, including Episode Two itself. Valve engineers also told us to expect performance improvements in Episode One and other Valve games, although third party mods may not have any performance benefit.
(bron: artikel op Bit-tech) :)
Ik denk dat ze bedoelen dat binnenkort een soort van provisorische patch komt en dan met de launch van Ep 2 komt de uiteindelijke toepassing van multithreading.
Das ik kan beter wachten op quadcores dan dat ik over een maand de dual core ga kopen? Ik denk dat die quad cores heel erg duur gaan worden en dat de meerderheid toch voor de dual core gaan omdat die toch wat goedkoper is.
aan de ene kant wel. als je het hele artikel leest zul je lezen dat valve vooral in quadcores geintereseerd is.
Zo kun je blijven wachten.

De octa-cores staan ook al op de roadmaps
Goh, en Intel heeft al een 80-core gedemonstreerd.

Ja, zo kun je wel blijven wachten, na Octa-cores zullen de Hexa-cores komen.

En wie weet joh, misschien komt er wel een doorbraak waarmee blijkt dat single core weer veel beter werkt.

Niemand kan ver in de toekomst kijken, dus wachten op "the one" is nutteloos.

[CRAP]Level te hoog...
"na Octa-cores zullen de Hexa-cores komen."

Octa = 8
Hexa = 6

Volgens mij bedoel je het net andersom, of heb ik iets gemist? :Y)

Maarja, in principe kun je blijven wachten, en zodra je besluit iets te kopen is het al weer achterhaald.
niet geheel waar.

Als ik nu een redelijke videokaart zou willen kopen, kan je beter een paar weken wachten, want dan zijn de prijzen waarschijnlijk aardig gedaalt vanwege de nieuwe videokaarten die dan uitkomen. Zal wel iets van 30% dalen. Zeker het wachter waard.
Bartjuh, dan moet je dus wel goed redeneren. Jij zegt dat je nu beter kunt wachten voor een redelijke videokaart, maar datzelfde kon je ook een paar maanden terug zeggen, de redelijke tot goede kaarten van toen zijn nu inmiddels gedaald (de x1900 serie bijvoorbeeld). En over een paar maanden kun je dit weer zeggen, want er blijven nieuwe kaarten uitkomen.

Dit geldt niet alleen voor videokaarten, maar ook voor cpu's.
Heb net even gezocht en ben er dus ook al achter gekomen dat de goedkoopste quadcore dalijk uitkomt 700 tot 800 dollar gaat kosten. Om even te vergelijken heb ik daarvoor een dual core met mobo, geheugen en grafische kaart. Klinkt allemaal wel leuk van vale om dit te gaan doen maar waarom beginnen ze niet eerst met dual core en gaan ze daarna niet gewoon verder met een quadcore.

(jammer dat je een dual core niet kan overklokken naar een quadcore :P)

En inderdaad, als je het zo gaat bekijken kan je nog beter 2 maanden wachten op een nieuwere grafische kaart en een nieuwe mobo, dat schiet niet op...
De Sega Saturn had al de beschikking over een dual core processor, alleen waren er jammer genoeg niet zo heel erg veel developers die de technologie erg goed beheersten. Het AM2 team, dat de Virtua Fighter serie heeft gemaakt voor de Saturn, had wel de skills in huis om dual core tot z'n recht te laten komen. En, eigenlijk was het ook de bedoeling om de game Shenmue, die later voor de Dreamcast is uitgebracht, op de Saturn te laten verschijnen. Er zijn beelden in omloop van de Saturn versie die echt heel erg mooi zijn voor een 32 bit systeem!

Valve is dus helemaal niet zo vooruit strevend als dat ze zelf, en anderen, beweren. Ik zeg niet dat ze bij Valve een stelletje amateurs hebben werken of zo, maar de PR afdeling heeft toch wel een groot mondje af en toe vind ik. Persoonlijk vind ik het woord "praatjesmakers" er wel bij passen. Al dat gehype rondom Half-Life 2 was ik ook niet zo kapot van eerlijk gezegd. Uiteindelijk vond ik het maar een gemiddelde shooter, waar een hele hoop dingen uit gelaten waren, die eerst wel belooft werden.
Ik vroeg me al af welke spellen tegenwoordig gebruik maken van dual/quadcore. Blijkbaar niet zoveel gezien het feit dat dit nieuws is.

Alleen maar goed overigens aangezien Word en Excel toch echt niet sneller starten op een fijne dualcore.....

Mooi bedrijf dat Valve. Hulde !
Supreme Commander en Alan Wake zijn in ieder geval twee voorbeelden van games die quadcore gaan ondersteunen.
Inderdaad. Intel heeft voor Alan Wake al een optimalisatie voor Quadcore doorgevoerd:

Er zijn bij Youtube al vele filmpjes van te vinden:

http://www.youtube.com/watch?v=3j6rR-Xv2Ro
Evenals Unreal Tournament 2007 en andere games gebaseerd op Unreal Engine 3.0.
Adobe Reader is in minder dan een seconde gestart op mn X2 4800+ :)
M.a.w. die PhysiX kaarten kunnen ook wel de prullenbak in.
Omdat ze het over particle physics hebben?

Misschien wel, misschien niet.

Laten we eerst maar afwachten wat dat precies gaat betekenen, en dan zien of het een het ander uitsluit, aanvult, of dat ze naast elkaar bestaan.
M.a.w. die PhysiX kaarten kunnen ook wel de prullenbak in.
Een PhysX kaart is vele malen sneller dan een quadcore-processortje hoor, als het op fysica aankomt.
PhysX zou kunnen floppen als er geen support van spellen komt, maar niet omdat een CPU hem overbodig maakt, want een CPU kan absoluut niet tippen aan de prestaties van een PhysX-kaart.
De meeste mensen hier schijnen zich niet te realiseren hoe moeilijk het kan zijn is om effectief te multithreaden.

Quake had het dan wel SMP ondersteuning, maar het leverde nauwelijks iets op. Veel algorithmes zijn niet zo makkelijk te splitsen. En dan komt er ook nog redelijk wat administratie bij, om te zorgen dat de synchronisatie goed verloopt, je geen dead-lock's veroorzaakt, etc etc.
Er zit meer aan vast dan simpelweg een paar routines in een aparte thread te laten draaien. Multi-threading is geen sausje dat je zomaar over je engine kunt gieten.

Als Valve dit goed voor elkaar krijgt, dan is dat inderdaad een enorme sprong.

Zou me trouwens niets verbazen als dit nauw samenhangt met het concept om de GPU als physics renderer te gebruiken. In zekere zin is de GPU een super multicore CPU.
Hoezo is een GPU een 'super multicore CPU'? :/
het spel King Kong had al support voor meerdere cores,
dus valve is hier niet als eerste mee.
Dat beweren ze toch ook niet? :) Vraag me wel af wat het eerste spel ooit was dat meerdere CPU's ondersteunde. Quake 3 of was iemand hen ook nog voor?

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True