Skyrim kan na patch overweg met Large Address Aware

Ontwikkelaar Bethesda heeft een patch vrijgegeven voor The Elder Scrolls V: Skyrim. De pc-versie van de game kan door de patch overweg met Large Address Aware, wat meer geheugen vrijmaakt voor de rpg en een hack overbodig maakt.

Een nieuwe patch, die automatisch aangeboden wordt via Steam, waardeert The Elder Scrolls V: Skyrim op tot versie 1.3.10.0. De patch maakt meer geheugen vrij voor de pc-versie van de game, wat de stabiliteit ten goede moet komen. Door de patch kan de game overweg met Large Address Aware, waardoor 3GB ram beschikbaar is voor het spel, waar de game het tot nu toe met 2GB moest stellen. Modders hadden al eerder een methode ontdekt om de game gebruik te laten maken van Large Address Aware.

Niet alleen de pc-versie van het spel kampt met geheugenproblemen. Begin december was er enige ophef over de versie voor de PlayStation 3. Josh Sawyer, project director van het met dezelfde engine gebouwde Fallout: New Vegas, gaf aan dat de lag die de PS3-versie van The Elder Scrolls V: Skyrim ondervindt, veroorzaakt wordt door de manier waarop de gameconsole savegames opslaat. Bethesda erkent dat de game op de PS3 last heeft van lag, maar stelt dat dit niets te maken heeft met de manier waarop de game data opslaat. De ontwikkelaar verwacht de lag bij de PS3-versie pas in toekomstige patches te kunnen oplossen.

Update, donderdag 22 december, 11.50: Ter verduidelijking: Op een 64bit-OS zorgt de Large Address Aware-vlaggetje op de executable dat het programma de volledige 4GB kan gebruiken. Op een 32bit-besturingssysteem doet het LAA niets, tenzij de gebruiker de 3GB-bootoptie in Windows XP of de IncreaseUserVA-switch in Vista gebruikt. Ook in die gevallen krijgt de applicatie slechts maximaal 3GB tot zijn beschikking.

Reacties (70)

[arjen9551]

Ga dit in FPS schelen of juist voornamelijk laadtijden?

[Dwarrelegel]

Zover ik heb begrepen voornamelijk tegen crashes. Ook zal het gebruik van texture mods makkelijker worden omdat het niet meer nodig de 4gb mod te installeren.

Wat ik me afvraag is of het nu nog maximaal 3gb is. Want de mogelijke mod geeft 4gb zover ik heb gezien.

[.oisyn]

Wat ik me afvraag is of het nu nog maximaal 3gb is. Want de mogelijke mod geeft 4gb zover ik heb gezien.

Dat lijkt me eerder omdat mensen niet helemaal lijken te begrijpen wat de "hack" precies doet. Ook de berichtgeving van tweakers.net is onvolledig.

"Large address aware" is een vlaggetje op een executable die aangeeft dat de app om kan gaan met een user space die de volledige 4GB virtual address space beslaat. Zonder deze optie zijn alleen de onderste 2GB te gebruiken, en wordt de bovenste 2GB voor het OS gebruikt.

Op een 64 bits OS resulteert het gebruik van dit vlaggetje in een volledige 4GB voor eigen gebruik voor de app. Op een 32 bits OS doet het in principe geheel niets, tenzij je de /3GB boot optie in Win XP of de IncreaseUserVA boot optie vanaf Vista gebruikt. Maar zelfs in dat geval krijgt de app slechts maximaal 3GB tot zijn beschikking.

Het frappante is ook dat die bootoptie standaard uit staat. Als jij dus een 32 bits OS draait en nooit aan die bootoptie hebt gezeten dan zal de LAW patch gewoon in z'n geheel niets uitmaken.
http://msdn.microsoft.com...re/ff556232(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/Aa366521

[Reactie gewijzigd door .oisyn op 27 juli 2024 03:23]

[Ventieldopje]

Waarom ze dan niet gewoon een 64bit editie van het spel uitbrengen is mij nog een raadsel, dan zijn dit soort hacks niet nodig meen ik

[.oisyn]

64 bits is geen sinecure. Pointers worden ineens 2x zo groot, en dat kan er voor zorgen dat er ook veel meer geheugen nodig is dan in 32 bits. In de praktijk stijgt het geheugengebruik bij een switch naar 64 bits gemiddeld met zo'n 50 tot 75% in een game. Dus je hebt ten eerste meer fysiek geheugen nodig, en ten tweede zorgt dit ook voor meer chache misses en dus zal de boel slechter performen.

[mjtdevries]

Begrijp ik het dan goed dat die pointers blijkbaar naar data wijzen die meestal net zo groot is als de pointer zelf? Anders snap ik niet dat het geheugengebruik ineens zo sterk toeneemt.

Juist als je heel veel geheugen gebruikt verwacht ik eigenlijk dat een pointer meestal naar een groot blok data wijst? En dan maakt het niet uit dat die pointer zelf 2x zo groot is?

Ik weet dat je een gamedeveloper bent, dus ik twijfel niet aan je bewering, maar ik probeer het beter te begrijpen.

P.S. ik snap wel dat die /3GB bootoptie standaard uit staat, want dat levert al snel meer problemen op dan dat het oplost. (zeker in game PCs waar je al snel meer dan 1GB voor het OS/system nodig hebt)

[.oisyn]

Vergeet niet dat die blokken data zelf ook weer uit pointers kunnen bestaan. Zeker in een game als Skyrim heb je te maken met ontzettend veel verwijzingen voor alle gamedata. En daarnaast heb je ook nog te maken met alignment. De compiler zal een pointer in 64 bits alignen ook op 8 bytes. Als je eerst een datastructuur had met een 32 bits int, gevolgd door een pointer, gevolgd door een 32 bits int, dan is de grootte van die structuur in totaal 12 bytes voor een 32 bits executable. In 64 bits wordt het ineens 24 bytes - tussen de eerste int en de pointer zit 4 bytes padding om de pointer te alignen, en na de laatste int zit ook weer 4 bytes padding om ervoor te zorgen dat als de structuur in een array gebruikt wordt het volgende element ook weer goed gealigned is. Had je de structuur in eerste instantie anders opgeschreven, door de 2 ints naast elkaar te zetten, dan ging hij van 12 naar 16 bytes.

Maar natuurlijk, als je het hebt over bijvoorbeeld texture of sound geheugen dan staat daar alleen pixel- en sampledata in. Wat dat betreft was ik wat te kort door de bocht, mijn bewering gaat specifiek op voor game data, maar alle content data is natuurlijk de bulk van een game (al zal het meeste wel naar video mem gekopiëerd worden)

[Reactie gewijzigd door .oisyn op 27 juli 2024 03:23]

[SuperDre]

SImpel een pointer in 32bits is 4 bytes, een pointer in 64bits is 8 bytes, dus als je gebruik maakt van 64bit pointers ben je 2 keer zoveel plek kwijt..

[Tsurany]

Het is alleen een dirty fix tegen de crashes. Als het spel crasht omdat er teveel in het geheugen geladen is dan is dat gewoon een programmeer fout. Dan kan je zorgen dat onnodige zaken uit het geheugen geladen worden waardoor het geheugen niet zo vol loopt of zorgen dat er meer geheugen gebruikt kan worden maar daarmee stel je de crash uit. Zorg er liever voor dat de game fatsoenlijk met swappen om kan gaan en dus niet hoeft te crashen als er geheugentekort is.

Volgens mij trouwens exact hetzelfde probleem als bij Oblivion. Elke actie die je uitvoert wordt opgeslagen in je samegame. Deze acties moeten ook weer ingeladen worden om een gamewereld op te zetten waarbij alles wat je doet blijvende gevolgen heeft. Als elk wapen dat je ooit dropt daar bewaard moet blijven neemt dit natuurlijk flink wat geheugen in. Dan blijft het geheugengebruik stijgen en in het geval van Oblivion en Skyrim zorgt dit voor crashes. Hoe langer je doorspeelt hoe sneller deze voorkomen.
Echter als je weet dat dit kan gebeuren moet je dus een oplossing vinden om te zorgen dat zodra het geheugen vol zit de applicatie gaat swappen of een andere methode vind om wel de snelheid te behouden maar niet te crashen bij vol geheugen. Een crash simpelweg omdat geheugen vol zit is onacceptabel en mag gewoon niet 'opgelost' worden door meer geheugen toe te kennen.

[Reactie gewijzigd door Tsurany op 27 juli 2024 03:23]

[Verwijderd]

Het feit dat het spel crasht door teveel geheugen gebruik is één ding, dat dit een 'programmeer fout' betreft heb je echter niet onderbouwd. De reden dat veel mensen Skyrim op een PC spelen heeft te maken met de betere graphics i.c.m. met het toegang hebben tot meer geheugen (deze patch borduurt daar mooi op verder).

Met het aangeven dat ze volgens jou de game beter kunnen aanpassen zodat deze 'fatsoenlijk met swappen om kan gaan' sla je echter volledig de plank mis.

[Tsurany]

Waarom sla ik dan de plank mis? Dat heb jij niet onderbouwd. Ik ben geen programmeur, ik weet niet exact waarom de applicatie crashed. Wat ik wel weet is dat de applicatie crashed door een gebrek aan geheugen, dat hoort niet te gebeuren. Wanneer een applicatie in geheugennood komt dient daar een oplossing voor te zijn. Dit zal dan een vorm van swappen moeten gaan zijn simpelweg omdat je toch data moet bewaren, kan dat niet in het geheugen moet het naar de pagefile toe. Dit zal trager zijn maar het alternatief is data vernietigen.

Op het moment dat jou applicatie bij geheugengebrek niet fatsoenlijk kan swappen maar er voor kiest om te crashen betekent het dat er ergens een programmeerfout is gemaakt. Kan in het design zijn of in de daadwerkelijke code, maar een applicatie die crashed wanneer het tegen de van te voren bekende limieten aan loopt is slecht ontwikkelwerk. Performance decrease is dan nog 'acceptabel', een crash is dat zeker niet.

Wat ze nu doen is het punt wanneer de applicatie gaat crashen uitstellen, zodra de applicatie nu 3 of 4GB gebruikt zal hij alsnog crashen want er zal precies hetzelfde gebeuren. Enkel nu duurt het langer totdat het limiet bereikt wordt en zal dat in veel situaties wellicht niet meer voorkomen. Je fixed het alleen niet, je stelt het uit.

Stel je kassa software crashed als meer dan 50 items gescanned worden zonder af te rekenen, dan is dit limiet verhogen naar 100 items geen fix maar een workaround. Het probleem is nog aanwezig, een probleem dat niet voor zou mogen komen.

[Japs]

Mee eens, maar als je het formeel bekijkt, is swappen niks anders dan het geheugen vergroten, en verschuif je nog steeds het probleem, zonder het op te lossen

Immers swap file heeft ook beperkte opslagcapaciteit, waar je niet vannuit mag gaan (misschien heeft iemand nog maar 10MB vrij op zijn HDD...niet slim, maar het is zeker mogelijk in de praktijk).

Dus de enige echt 100% robuste manier is bij starten van de applicatie een bepaalde minimale hoeveelheid opslag te reserveren (in RAM en/of HDD), en niet te starten als die niet beschikbaar is. Die opslag mag dan alleen door de applicatie gebruikt worden, waardoor er dus een harde ondergrens is aan de beschikbare hoeveelheid opslag.
De applicatie moet dus in elke state in essentiele vorm kunnen blijven draaien binnen die minimale geheugen hoeveelheid.

Vervolgens moet de applicatie indien nodig kunnen terugschalen in geheugen footprint naar die hoeveelheid, waarbij op een nette manier weggooien van minst relevante data de laatste optie is (maar zeker moet zijn geimplementeerd).

In geval van een game zou je bijvoorbeeld kunnen kiezen voor uit het geheugen gooien van bepaalde textures, en deze te vervangen door 1 kleur. Terwijl bijhouden van dingen als de essentiele spelvoortgang (hoever ben je met een quest, waar ben je, wat heb je bij je etc.) ten alle tijden moet worden behouden (en dus ook per definitie in de gereserveerde geheugen ruimte moet passen).

Het spel blijft dan speelbaar (hoewel het er niet charmant uitziet), zonder integriteitsprobleem.

Als ik even niet onderbouwd mag speculeren: het zal voor een dergelijke omvangrijke complexe game gewoon te veel tijd/geld kosten om een game zo robuust te maken, terwijl je met workarounds 99% van de problemen kan afdekken...want hoe leuk ook...een game is nu eenmaal geen kritieke applicatie (zoals in boordcomputers van een vliegtuig, of medische apparatuur)

[Verwijderd]

Tsurany, je bent met je laatste paragraaf volledig uit de bocht gegaan en het ontbreekt aan logica.

Gegeven 1: Stel dat je maar 80 producten verkoopt in je winkel (maximum geheugengebruik skyrim).

Gegeven 2: Je software crasht momenteel wanneer er 50 producten worden ingescand.

Methode: De software pas je wat aan waardoor deze nu 100 producten kan inscannen.

Resultaat: Je harde limiet is dus meer dan wat je software ooit zal kunnen gebruiken.

Is dit dan geen oplossing? Want dit is concreet wat er hier nu gebeurd is. Hou er trouwens rekening mee dat de recommended system specs 4GB zijn.

Jij negeert gegeven 1 in je hypothese en stelt in principe dat de enige oplossing het verwijderen van de limiet is, maar dat is fysiek onmogelijk, natuurwetten enzo...

[Reactie gewijzigd door Verwijderd op 27 juli 2024 03:23]

[.oisyn]

dat dit een 'programmeer fout' betreft heb je echter niet onderbouwd

Sorry, maar meer dan de helft van zijn post bestaat uit een goede onderbouwing waarom dat is. Op het moment dat je geen harde limiet kunt stellen aan de hoeveelheid gebruikt geheugen in een worst case scenario (zoals dat voor de meeste games wel kan), dan moet je iets gaan verzinnen waardoor je dat toch wél kan doen, door data die je voor een tijdje niet nodig hebt op disk op te slaan en pas weer in te lezen als je het wel weer nodig gaat hebben. Het is echt niet zo dat op ieder moment alle data beschikbaar moet zijn in het geheugen.

[Reactie gewijzigd door .oisyn op 27 juli 2024 03:23]

[Ireyon]

Locatie van opgeslagen items is niet meer dan een X,Y coördinaat van het item zelf, of de container waar het item ligt opgeslagen.De engine rendert dan het itemmodel om dat coördinaat heen. Lijkt mij dat dit een baar bytes zijn. Hiermee moet je toch echt wel miljarden items hebben opgeslagen om de limiet te bereiken. Keuzes in je quests zouden toch ook niks anders dan een variabele moeten zijn (HeeftDraakVerslagen=0 bijvoorbeeld).

Ben dan wel geen programmeur of ik denk te simpel

[Spockz]

De manier die jij voorstelt is zo wel erg linear. Maar als je meer bij wilt houden, als welke quests tegelijkertijd aan de gang zijn en hoe je dan door de verhaallijn gaat krijg je al een boom structuur. Nu moet je bedenken dat voor elk item dat je verplaatst de nieuwe locatie wordt opgeslagen. En dan moet je eens rondkijken naar hoeveel items er eigenlijk zijn, hoeveel boeken, hoeveel potions, etc. Dan moet je toch opeens wel een hoop onthouden.

[sygys]

Het is onzin dat dit de game zou moeten laten crashen. Alle wapens vijanden e.d. staan namelijk al opgeslagen in de database, alleen de positie van deze wapens wordt anders. en wellicht de stats van dit object.

Uiteraard wordt een savegame steeds groter, maar al wordt deze 300 MB dan nog zou dit vlekkeloos moeten werken. Je hoeft namelijk maar een deel van de savegame ineens in te laden afhankelijk van de positie waar je je bevind op de map. Als je aan ieder object in een savegame een sector hangt kun je vooraf aangeven of bepaalde gegevens wel of niet ingeladen hoeven te worden in de sector waar je je op dat moment bevindt.

Zo kunnen de gegevens van de sector ingeladen worden de 8 sectoren rondom. de rest kan onder het spelen worden ingeladen.

Het is uiteraard een behoorlijk ingewikkeld proces maar daar zijn hun de ontwikkelaars voor en ik niet.. Ik kan me wel voorstellen dat deze game op de PS3 een hoop meer problemen krijgt, omdat deze een hoop minder werkgeheugen heeft en de hardware ver achterhaald is.

Ze kunnen er wel een 7 core CPU in zetten, maar als het geheugen en de videochip bagger zijn dan heb je daar vrij weinig meer aan op een gegeven moment.

[Paul - K]

Ik denk eerder in de maximale weergave en lag problemen

[Haan]

Geen van beide denk ik, het gaat wel schelen in de stabiliteit van de game, dus minder crashes.

[Rockvee2]

Volgens mij slaapt er iemand die dit nieuwsbericht maakt. Het gaat over dat er voor de 32 bit versies van windows (4GB) dat skyrim daarmee overweg kon. Dit kon al met de 64 bit maar nu ook met de 32 bit.

[Korben]

Voor 64-bit OS'en was dit zeker niet zo. Het verschil is dat (zoals al eerder genoemd) bij een 32-bit OS de maximale hoeveelheid aanspreekbaar geheugen 3 GB wordt, en voor een 64-bit OS wordt dat 4 GB.

[.oisyn]

Volgens mij snap jij niet helemaal wat de optie precies doet. Skyrim is een 32 bits app, zonder de /LARGEADDRESSAWARE linker optie zal hij ook op een 64 bits systeem maar 2GB aan geheugen aan kunnen spreken.

[Bartjeh]

Nu alleen nog zorgen dat windows 32 bit om kan gaan met 4gb.

edit:
@ hieronder het ging mij erom dat hij aangaf dat degene die het artikel schreef zat te slapen, ondertussen zegt hij 32bit (4gb). Blijkt maar weer dat internet een slecht medium is om zoiets duidelijk te maken met zo een opmerking.

[Reactie gewijzigd door Bartjeh op 27 juli 2024 03:23]

[Chaoss]

dat is een beperking van het 32bit systeem... kan dus niet "opgelost" worden. Om meer geheugen te kunnen adresseren zul je toch echt een 64bit OS moeten gebruiken.

[.oisyn]

Het is een mythe dat 32 bits OS'en niet meer dan 4GB aan geheugen aan kunnen spreken. Voor x86 is er een speciale feature genaamd Physical Address Extension (ondersteund vanaf de Pentium Pro) die het mogelijk maakt om in totaal 64GB aan geheugen te addresseren. De 32 bits server OS'en van MS kunnen dat ook, maar de client OS'en niet - drivers moeten dat namelijk ook ondersteunen, en veel drivers voor consumer hardware doen dat niet.

[Reactie gewijzigd door .oisyn op 27 juli 2024 03:23]

[naikon]

Technisch gezien worden hierdoor echter de geheugen adressen van fysiek geheugen wel degelijk 64bits (waarvan 36bits nuttig). Een PAE aware OS is dus hybride. De hele virtual memory laag van het OS moet hier namelijk rekening mee houden, net zoals inderdaad drivers die of altijd geheugen onder de 4GB moeten allocaten of bounce buffers moeten aanmaken voor hardware die alleen 32bit DMA doet.

[BeerenburgCola]

Nitpick: een 32bits systeem zou wel met 4GB om moeten kunnen gaan.

[Reactie gewijzigd door BeerenburgCola op 27 juli 2024 03:23]

[Seroth]

Het artikel is niet zo degelijk nee. Naast de rare fout m.b.t. de ontwikkelaar (BioWare?!) is de omschrijving van wat de patch nu doet ook vreemd; "Door de patch kan de game overweg met Large Address Aware." Stilistisch gesproken, zou je dan niet eerder zeggen "Door de patch is de game nu "Large adress aware" (geworden)"? Immers is het spel zich nu van het voltallig geheugen "bewust". Je gaat niet overweg met bewustzijn; je bent ergens van bewust of niet.

Ontopic: Leuk dat het er eindelijk in gepatched is. Jammer dat dit allemaal niet bij de launch werkt. Van nieuwe games verwacht ik toch wel dat ze gebruik kunnen maken van de vaak 4+ GB die de meeste moderne gamers toch wel in hun bak hebben zitten. Verder ook jammer dat de game zo buggy is. De random crashes halen me helemaal uit het verhaal, en dat terwijl de game zó super vet is! Ik vermaak me ontzettend als ik in de wereld zit, maar als er weer eens iets mis gaat dan gaat er toch iets van de glans, van de magie, verloren.

[Dj Neo Ziggy]

Waarom deze game het sowieso nodig heeft snap ik niet. Het process van skyrim is ~800mb en nooit meer.

Verder heb ik exact hetzelfde: Wat een meesterlijk spel, maar dat het zovaak crashed en dat de quest bugged zijn. (heb er onderhad al 7 staan, die je dan met je console verder kan brengen)

[naikon]

Wat je in windows als "geheugen gebruik" ziet in de taskmanager is alleen dat gedeelte geheugen dat daadwerkelijk gebruikt word en waarvoor fysiek geheugen is gealloceerd. Dit noemt men de "working set". Het is mogelijk dat Skyrim veel meer virtueel geheugen nodig heeft dan fysiek geheugen, meer dan zijn standaard address space (2GB) toelaat.

[The Zep Man]

Van nieuwe games verwacht ik toch wel dat ze gebruik kunnen maken van de vaak 4+ GB die de meeste moderne gamers toch wel in hun bak hebben zitten.

Je mag verwachten, maar de meeste spellen komen nog steeds alleen in 32-bit x86 builds uit. Hierdoor kunnen deze spellen effectief maar 3 GB gebruiken, ook op 64-bits besturingssystemen.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 03:23]

[M2M]

Wat ik vreemd vind is dat er geen 64bit executable gemaakt is. De hardware gaat zo gigantisch snel vooruit, en er vanuit gaande dat het volgende deel pas over 4+ jaar verschijnt zou een 64 bit executable een hoop hoofdpijn kunnen schelen. Waarom? Mods. Overal 2048x2048 texturewerk overheen, open cities, dorpjes en huisjes. Momenteel gedaan omdat de performance in elkaar zakt als dat allemaal gerendered moet worden en het geheugengebruik gigantisch toeneemt.

Maar eigenlijk dus niet nodig zolang de game voldoende geheugen kan reserveren en je een beetje fatsoenlijke machine hebt staan. Aangezien de nieuwe reeks videokaarten van AMD volgens hun eigen propaganda al 50% meer FPS geeft denk ik dat een 64 bits gamecode wel handig zou zijn.

[R4gnax]

Wat ik vreemd vind is dat er geen 64bit executable gemaakt is. De hardware gaat zo gigantisch snel vooruit, en er vanuit gaande dat het volgende deel pas over 4+ jaar verschijnt zou een 64 bit executable een hoop hoofdpijn kunnen schelen.

De reden hiervoor is waarschijnlijk dat de onderliggende Gamebryo engine een waar mijnenveld is. Er is al meermalen gezegd dat die engine niet deugt. Als het een beetje lelijke code is dan zitten er allerlei 32-bit specifieke ranzige geheugen 'optimalisaties' in die compleet stuk gaan als je een 64-bit executable probeert te bouwen.

Daarnaast zijn de consoles nog steeds 32-bit en daarvan is de XBox360 (hoe jammer ook) de leading SKU voor Bethesda. De PC versie is daarbij slechts een slappe port. Je mag wat dat betreft al héél blij zijn dat Bethesda zelf nu met een LAA patch gekomen is.

[KingKoning]

Opvallend. Op gamer.nl wordt gesproken over 4 GB.... en jullie spreken over 3?

en dat is ook wat ik in de link in jullie artikel zie... http://store.steampowered.com/news/7061/

foutje misschien? net als ontwikkelaar Bioware?

[Reactie gewijzigd door KingKoning op 27 juli 2024 03:23]

[Waking_The_Dead]

Volgens die andere link in het artikel is het 3GB voor 32-bit systemen en 4GB voor 64-bit systemen.

[BrutalDave]

Dat lijkt me logisch...

[.oisyn]

Maar alleen als je je 32 bits OS boot met een speciale boot optie (4GT Ram tuning zoals hieronder beschreven), wat standaard dus uit staat.

[BeerenburgCola]

Links volgen die in het artikel genoemd worden:

On 32-bit editions of Windows, applications have 4 gigabyte (GB) of virtual address space available. The virtual address space is divided so that 2 GB is available to the application and the other 2 GB is available only to the system.

The 4-gigabyte tuning (4GT) feature, formerly called 4GT RAM Tuning, increases the virtual address space that is available to the application up to 3 GB, and reduces the amount available to the system to between 1 and 2 GB.

Van: http://msdn.microsoft.com...b613473%28v=vs.85%29.aspx

[Boeteloes]

Dus als je game nog niet crashed hoef je dus ook niet te updaten. Prima, ik laat hem lekker zo. Ik lees veel slechte verhalen over het updaten van deze titel. Dat je er juist bugs bij krijgt en dat zo soort onzin.

[Waking_The_Dead]

Als je Skyrim speelt op je PC, dan is dat dus via Steam. En via Steam gebeuren de updates automatisch. Je hebt dus niet de keuze om niet te updaten. De eerstvolgende keer dat je Steam opstart, zal voor Skyrim automatisch een update worden binnengehaald.

@hieronder: OK, je kan er inderdaad voor kiezen om hoegenaamd niet te updaten. Maar wat ik eigenlijk bedoelde maar verkeerd verwoord heb, is dat je er niet kan voor kiezen om één specifieke update niet te accepteren. Je kan je updates wel tijdelijk uitzetten, maar als er nadien een nieuwe update komt (gratis DLC bijvoorbeeld) die je wel wilt, dan zal je toch verplicht alle eerdere updates ook moeten binnenhalen.

[Reactie gewijzigd door Waking_The_Dead op 27 juli 2024 03:23]

[Sisko]

Je kan dit spel ook in offline mode spelen, dus je hebt wel keuze of je wel of niet update.

[PepijnK]

Je kan in Steam in de opties van het spel instellen dat je niet wilt dat het automatisch geüpdate wordt.

[R4gnax]

Bepaalde patches kunnen dan echter nog steeds door de leverancier geforceerd geinstalleerd worden, wat schijnbaar al eens gebeurd is voor Skyrim.

[Reactie gewijzigd door R4gnax op 27 juli 2024 03:23]

[Hot Pixel]

Je kunt per game aangeven of hij wel-of-niet automatische updates moet binnenlepelen.

[DJ TerraByte]

Met de nieuwe Large Arrow Aware patch zullen veel avontuurs erachter komen dat met een pijl in de knie, alles een stuk lekkerder "loopt".

Maar serieus, dit is de eerste patch die de technische mankementen verzacht.
Nu is er meer ademruimte voor de code.
De lag die zelfs zichtbaar was op een uitgebreid Core i7 systeem moet nu toch wel uitblijven.

Ik vraag me alleen af of de fouten in mijn eerdere post over Skyrim ooit opgelost gaan worden...

[Sinester]

De lag die zelfs zichtbaar was op een uitgebreid Core i7 systeem moet nu toch wel uitblijven.

Lag? heb geen lag mee gemaakt met deze game, en dat op een Phenom x4

Heb je niet toevallig de controller nog aan staan, dat wil wel eens voor een trage muis zorgen

[KoenHalfwerk]

of je vergeet gewoon boink uit te zetten die gpu wu'tjes aan het maken is (zoals ik gister)

[YopY]

Mooi zo: Ik kan het spel simpelweg niet spelen zonder de large address aware patch, zonder die patch crasht hij gewoon regelmatig, gewoon klap uit crash to desktop ook. Ik vind het apart dat ze dit niet gelijk aangezet hebben.

[BeerenburgCola]

2GB op de PC niet genoeg ?
Je vraagt je dan of hoe Skyrim in hemelsnaam werkt op een console, met maar 256MB of 512MB "vrije" ram (afhankelijk van de console).
Slurpt windows zoveel op of hebben ze de console versies zwaar lopen optimaliseren ? (iets wat ook niet 100% gelukt is).

[R4gnax]

Slurpt windows zoveel op of hebben ze de console versies zwaar lopen optimaliseren ?

Geen van beiden. De console versies maken simpelweg gebruik van de allerslechtste kwaliteit textures, wat een enorme reductie in geheugengebruik inhoudt.

Het is dan ook niet voor niets dat de meeste PC gamers waarbij Skyrim vaakt crasht aan het spel hebben liggen sleutelen met high-res texture packs. 'Vanilla' Skyrim heeft op de PC verhoudingsgewijs weinig problemen.

[gimbal]

Textures hoeven op de pc geen systeem geheugen te slurpen; daar is nu juist het videogeheugen voor. Hangt er vanaf hoe efficient dit geprogrammeerd is natuurlijk, wellicht dat textures op hogere kwaliteit niet tegelijk in het videogeheugen kunnen verblijven dus zal er wat geswapped moeten worden. Maar ze hoeven zeker weten niet allemaal in het systeemgeheugen rond te hangen.

[Guiding]

Nou zoals letterlijk in het artikel staat:

De patch maakt meer geheugen vrij voor de pc-versie van de game, wat de stabiliteit ten goede moet komen.

[Verwijderd]

Allemaal leuk die extra voorziening om meer geheugen te gebruiken, maar ik (en waaronder ook andere) hoop op een betere crossfire scaling, want nu zijn 2 kaarten slechter dan 1.

[wicked1980]

Het is bizar wat er allemaal wordt bijgehouden in het spel. Als je in het begin van het spel een pijl in een deurpost schiet, dan zit hij er na 50 uur spelen nog steeds, ook al ben je in de tussentijd niet meer in de buurt van die deur geweest. En zo gaat het eigenlijk met alles, ook met het looten werkt het zo, die bandiet die je hebt gedood en gedeeltelijk berooft, die heeft na tig speeluren nog steeds dezelfde inventory

[maffiaric]

dat maakt het wel lekker realistisch. kan ik persoonlijk heel erg waarderen.

[R4gnax]

Het is bizar wat er allemaal wordt bijgehouden in het spel. Als je in het begin van het spel een pijl in een deurpost schiet, dan zit hij er na 50 uur spelen nog steeds, ook al ben je in de tussentijd niet meer in de buurt van die deur geweest. En zo gaat het eigenlijk met alles, ook met het looten werkt het zo, die bandiet die je hebt gedood en gedeeltelijk berooft, die heeft na tig speeluren nog steeds dezelfde inventory

Niet precies. Als je dezelfde map cell een maand lang (ingame tijd) niet bezoekt, zou deze moeten resetten.