Runescape wordt opgepoetst

Ontwikkelaar Jagex brengt een nieuwe versie van zijn gratis mmo-game Runescape uit. De bètatest van RuneScape High Detail is voorlopig alleen toegankelijk voor betalende spelers.

Runescape, dat gratis kan worden gespeeld, is met name populair onder tieners. Net als het origineel moet de nieuwe versie in een webbrowser worden gespeeld. De grootste vernieuwing is dat het spel voortaan gebruik kan maken van de grafische kaart in de pc waarop wordt gespeeld, zodat het spel op een volledig scherm te bewonderen is. De nieuwe Runescape stelt daarom eisen aan de computer van de speler. De grafische kaart moet minimaal over 64MB geheugen beschikken, er moet minstens 256 MB ram-geheugen aanwezig zijn en de processor moet een snelheid hoger dan 1,5GHz hebben. Daarvoor krijgt de speler dynamische schaduwen en belichting, betere watereffecten en textures met een hogere resolutie. Verder moet Java 1.4.2 zijn geïnstalleerd, al wordt Java 1.6 aangeraden.

De bètaversie is voorlopig alleen voor betalende leden van Runescape beschikbaar. Ontwikkelaar Jagex geeft aan de test te zijner tijd uit te zullen breiden, zodat ook niet-betalende spelers toegang krijgen.

Reacties (79)

[kamerplant]

Hmm dit grafische geweld in Java? Gaat dat soepel lopen op een gemiddelde computer? Iemand die hier ervaring mee heeft?

[alex3305]

Java is in principe een snellere taal (native!) dan bijvoorbeeld C++, echter moet de VM (virtual machine) een hoop vertalen waardoor het lijkt dat een hoop van de snelheid wegvalt.

Echter is er in Java heel goed OpenGL (en DirectX zelfs ook dacht ik) aan te sturen en dat is gewoon net zo snel als in een andere taal.

[.oisyn]

Java is in principe een snellere taal (native!) dan bijvoorbeeld C++, echter moet de VM (virtual machine) een hoop vertalen waardoor het lijkt dat een hoop van de snelheid wegvalt.

Wat een onzin . Als je de VM geheel weg zou denken, dan is Java slomer omdat je in die taal de memory management niet kan tunen aan de specifieke usecases van je applicatie, wat in C++ wel kan. Verder heeft het compleet geen support voor bepaalde intrinsics, zoals SIMD instructies. De meeste gangbare C++ compilers ondersteunen wel een manier om (bijvoorbeeld op het x86 platform) variabelen te koppelen aan SSE registers en daar SSE operaties op uit te voeren, wat direct compileert naar de relevante assembly instructies.

De reden waarom een VM in theorie sneller kan zijn dan voorgecompileerde code (want dat is het: dynamic vs. static, en niet Java vs. C++ - Java zou je native kunnen compilen en ook C++ code zou dynamisch in een VM gedraaid kunnen worden) is omdat je tijdens runtime optimalisaties kan doen voor het platform waar het op draait, zoals de manier waarop je voor bepaalde objecten geheugen alloceert e.d.. In de praktijk zijn er echter nog weinig voorbeelden van gezien, en die voorbeelden die er bestaan gaan voornamelijk om basaal geschreven C++ code die veel sneller had kunnen zijn als het anders was ontworpen.

Echter is er in Java heel goed OpenGL (en DirectX zelfs ook dacht ik) aan te sturen en dat is gewoon net zo snel als in een andere taal.

Het aansturen wel ja. Maar ik geloof niet dat je er enig idee van hebt wat daaraan vooraf gaat . De 3d rendering API (OpenGL, D3D) is vrij low-level en roep je pas op het laatste moment aan. Daarvoor moet je al efficient bepaald hebben wat er op je scherm te zien is, wat door welke lichten belicht en 'beschaduwd' moet worden, moet je de groepen polygonen sorteren op eigenschappen (gebruikte vertex- en indexbuffers, textures, renderstates, etc.) om het aantal statechanges te verminderen en zoveel mogelijk polygonen in één keer te kunnen tekenen. Dit proces vereist veel rekenwerk en er wordt een hoop geheugen rondgeslingerd. Iets wat in C of C++ goed te doen is met hun compiler intrinsics, ruwe pointers en custom memory management.

Maar Java en C++ zijn dan ook geen echte concurrenten van elkaar. Een van de design-principes van C++ is dat het snel en efficient moet zijn. Van Java is het juist dat je er robuuste software mee kunt schrijven dat in principe overal draait.

[Mr_Light]

dan is Java slomer omdat je in die taal de memory management niet kan tunen aan de specifieke usecases van je applicatie

Ik weet niet waar jij je info vandaan haald, maar omdat je mischien expliciet het memory moet regelen betekend niet dat je er geen controle over hebt er zijn een lego aan technieken beschikbaar. Je kan (onder andere) de strategie aanpassen en je kan hints in je code opnemen. Niet kan tunen is kolder, dat veel mensen het niet weten/doen is een ander verhaal.

In de praktijk zijn er echter nog weinig voorbeelden van gezien, en die voorbeelden die er bestaan gaan voornamelijk om basaal geschreven C++ code die veel sneller had kunnen zijn als het anders was ontworpen.

quercus verhaal gemist zeker, zulke corner cases zijn het nu ook weer niet.

In Java kan men misschien niet expliciet SIMD gebuiken, maar dat het geen SIMD support klopt toch ook niet helemaal. De JVM maakt er wel degelijk gebruik van, dit is niet 'compleet' en daarom zijn ze er nog verder mee bezig. De mogelijkheid om expliciet SIMD te gebruiken in java valt buiten de filosofie van de taal.

De mogelijkheid om direct objecten naar geheugen te mappen om direct te kunnen communiceren met andere onderdelen van het systeem, mist geloof ik nog. (in C/C++ vervullen structs die rol.

Het gat in hoeverre die er is is in ieder geval dermate klein dat snelheid niet meer het grootste bezwaar is om geen java te gebruiken. Andere factoren wegen veel zwaarder; Tools, middleware en support voor C++ zijn veelvuldiger, soms überhaupt beschikbaar en volwassener.

Maar Java en C++ zijn dan ook geen echte concurrenten van elkaar. Een van de design-principes van C++ is dat het snel en efficient moet zijn. Van Java is het juist dat je er robuuste software mee kunt schrijven dat in principe overal draait.

ik zie niet helemaal waarom die eigenschappen perpendiculair zouden zijn.

[.oisyn]

Ik weet niet waar jij je info vandaan haald, maar omdat je mischien expliciet het memory moet regelen betekend niet dat je er geen controle over hebt

Bedoel je niet juist dat je het niet expliciet moet regelen (want dat moet in C++ juist)? Verder raise je wel een fair point, hoewel ik me afvraag in hoeverre ik het kan finetunen zoals ik dat in C++ kan. Heb je hier documentatie over?

quercus verhaal gemist zeker

Wat, die PHP interpreter geschreven in Java? En dat wil je aandragen als voorbeeld dat code in Java sneller is dan vergelijkbare code in C++? Ammehoela. Nou heb ik sowieso al geen hoge pet op van Zend, maar ik durf best te beweren dat het mogelijk is om in een native taal een implementatie te maken die ook 4x zo snel is als de huidige PHP implementatie in C.

Het spijt me zeer, maar ik vind het niet echt getuigen van inzicht als je dit als argument aanhaalt. Stel ik zou een simpel programma maken dat een lijst van 1 miljoen integers sorteert in C++ en in Java. In C++ gebruik ik een bubblesort, in Java een quicksort danwel radix sort. Zie daar, het bewijs: Java is sneller dan C++. Ik mag hopen dat je begrijpt dat dit voorbeeld geen valide argument is. Net als dat het Quercus ook geen valide argument zou kunnen zijn. Pas als de implementatie in Java overeenkomt met de implementatie in C neem ik het aan als valide argument. Ik heb alleen geen tijd of zin om dat te controleren, dus wellicht dat jij dat uit kunt sluiten? Sowieso is er al het probleem dat mod_php draait onder Apache en Quercus onder Resin, wat natuurlijk al niet meer vergelijkbaar is.

maar dat het geen SIMD support klopt toch ook niet helemaal

Ik zeg ook niet dat de VM er geen gebruik van maakt, ik zeg dat jij (als programmeur) er geen gebruik van kunt maken. De effectiviteit van SIMDing compilers is (helaas nog) ver te zoeken

[Reactie gewijzigd door .oisyn op 22 juli 2024 18:33]

[Mr_Light]

Bedoel je niet juist dat je het niet expliciet moet regelen (want dat moet in C++ juist)?

hihi woeps. ge-edit

Heb je hier documentatie over?

In een handige plek, heh, ben bang van niet. Er zitten veel pareltjes tussen slides van javaone/jug en verwante sessies van de bijbehorende conferenties. Ook is er het nodige verspreid te vinden in blogs. Daarnaast zitten er dingen verstopt tussen andere lange verhalen over performance algemeen. Hopelijk vergeef je het me als ik niet mijn hele avond er aan spendeer om deze terug te zoeken.

Dingen die je waarschijnlijk als had gevonden staan vermoedelijk wel hier:
http://java.sun.com/perfo...e/whitepapers/tuning.html (gedateerd 2005) Kiezen van de juiste garbage collector kan best grote impact hebben.

Fancier /onbekende dingen moet je denken aan:
Geheugen dat er standaard gereserveerd word bij een nieuw thread kan je opgeven(als je heel veel kort levende threads gebruikt kan dit handig zijn.
Technieken voor het manage van lifecylces van je objecten en wat de (sun) jvm blindelings wel kan weg optimaliseren.

En dat wil je aandragen als voorbeeld dat code in Java sneller is dan vergelijkbare code in PHP?

Hier bedoel je waarschijnlijk c++ (zend interperter voor php is volgens mij in c++ ) Maar nee dat was mijn punt niet helemaal. Ik probeerde meer een kanttekening te plaatsen bij 'basaal'.

Java blijft sneller worden bij c++ verandert er minder(daar koop je trouwens helemaal niets voor, maar om een of andere rede vonden mijn vingers dat ik dat moest typen )

Er is een budget van tijd, energie en/of geld en binnen dit kader is het verschil dat nu tussen c++ en java ligt niet heel significant als je de kunde van de developer er bij betrekt. (wat je eigenlijk ook zelf zegt middels je voorbeeld)

Ik zeg ook niet dat de VM er geen gebruik van maakt, ik zeg dat jij (als programmeur) er geen gebruik van kunt maken. De effectiviteit van SIMDing compilers is (helaas nog) ver te zoeken

Ja, ok, ligt aan je perspectief, als jij je code zo opschrijft dat je er zo goed als zeker van uit kan gaan dat het gebruikt word, gebruik je het nog altijd niet direct zelf. Ik heb me er niet ver in verdiept ik herinner me alleen de discussie dat iemand klaagde over SIMD support en dat het antwoord was dat de jvm optimalisatie uitvoert mbv SIMD sinds (ik dacht) 1.4 en dat het wat serieuze vormen aan nam in 6 en 7. Hij melde dat het idd nog al tricky was. Ik zal me er nog een keer verder in gaan verdiepen.

[.oisyn]

Technieken voor het manage van lifecylces van je objecten en wat de (sun) jvm blindelings wel kan weg optimaliseren.

Hmm, nou krijg ik het idee dat we het niet over hetzelfde hebben. Vooral als ik even de alinea van tegen het einde van je reactie erbij haal:

Er is een budget van tijd, energie en/of geld en binnen dit kader is het verschil dat nu tussen c++ en java ligt niet heel significant als je de kunde van de developer er bij betrekt. (wat je eigenlijk ook zelf zegt middels je voorbeeld)

Daar ben ik het helemaal mee eens, maar het punt was dat de VM voor het grote deel verantwoordelijk was voor het soepel laten lopen van Java (dmv optimalisaties die min of meer automatisch tailored zijn aan het gebruik van de applicatie omdat ze at runtime plaatsvinden).

Waar deze discussie mee begon is de opmerking van alex3305 die zei dat Java juist langzaam was door de VM. Reinste kolder natuurlijk, het is juist andersom - Java kan door de VM juist goed meekomen met native talen . Vandaar mijn punt - als je de VM uit Java weg zou denken zou het stroperig gaan werken wegens taalconstructies die het mist (zoals ruwe pointers, maar denk ook aan het feit dat elke method automatisch 'virtual' is terwijl je daar in C++ voor kunt kiezen - voor het aanroepen van een virtual method betaal je een performance penalty om de simpele reden dat de CPU niet vantevoren weet waar de call naartoe leidt, wat een pipeline flush als gevolg heeft).

That said, niets weerhoudt je ervan (iig niet de C++ specificatie) om een C++ applicatie in een VM te draaien, zodat die gebruik kan maken van dezelfde voordelen .

Hier bedoel je waarschijnlijk c++

Euh ja idd, "woeps" van mijn kant

[SIMD in Java]

Hmm interessant, daar zal ik het eea over opzoeken

[YopY]

En dat komt omdat Java's openGL bibliotheken gewoon in C/C++ geschreven zijn, is een .dll die in Java ingeladen wordt.

En Java vs native talen, tsja. De meest eenvoudige vergelijking is dat C/C++ beter is met number-crunchen, iets wat veel gebeurt in 3D-apps. Daartegenover staat dat Java weer beter (en sowieso makkelijker) is mbt geheugen, omdat ze niet elk stukje geheugen eerst moeten reserveren en weer vrijgeven, maar ipv daarvan gewoon blokken geheugen pakt en gebruikt.

Ik heb zelf nog geen goede 3D engine (en games daarin) voor Java gezien, ze zijn er wel, maar nog lang niet met de kwaliteit, functionaliteit en snelheid die native talen hebben.

[3raser]

De grafische kaart moet minimaal over 64MB geheugen beschikken, er moet minstens 256 MB ram-geheugen aanwezig zijn en de processor moet een snelheid hoger dan 1,5GHz hebben.

Dat lijkt me dus duidelijk.

[Bitage]

Minimale specs zeggen dus niets, dat is gewoon de hardware die je in eerste instantie nodig hebt om het te draaien, of het dan allemaal soepel loopt is 2.

[kamerplant]

Errh niet dus.
De hoeveelheid videogeheugen zegt nagenoeg niets. "1,5GHz" is ook weinig zeggend. Een Core2Duo 1,5GHz is wel wat anders dan een P3 1,5GHz

[MacPoedel]

64MB zal dan zoiets zijn als een GeForce 2 of 3, en met 1.5GHz bedoelen ze natuurlijk een P4 1,5GHz of gelijkaardig.

[Krentenbol]

Zoals hier te zien is, is een GeForce 3 het minimum voor de verbeterde graphics.

[bbr]

Dat Is ook zoiets vaags. Heb hier een P4 2.66 GHz,
als gemiddelde consument zou je dus zelfs denken dat een Core2Duo van 1.66 GHz gewoon langzamer zou zijn.

"back in the days" was runescape wel erg traag en moeizaam. Maar misschien dat met nieuwe computers, en nieuwe java versies het nu wel beter loopt.

[3raser]

Ik vraag me af hoe lang die nieuwe versie erover doet om te laden. Met hoog detail fullscreen spelen zal ongetwijfeld wel wat bandbreedte gebruiken, maar dit wordt niet genoemd in het artikel.

[Bosmonster]

Fullscreen of niet maakt natuurlijk niet uit voor de bandbreedte. Verder zijn die paar simpele models en (nog steeds) low-res textures ook niet heel zwaar op een beetje moderne internet verbinding.

[3raser]

Fullscreen kan inhouden dat de pixels vergroot worden, maar ook dat er met dezelfde pixelgrootte meer inhoud op je scherm past. In het laatste geval zal dit waarschijnlijk meer bandbreedte kosten aangezien er meer gesynchroniseerd moet worden.

[Krentenbol]

En het ís het laatste geval, dus er wordt meer bandbreedte gebruikt.

[YopY]

Maakt niet uit, dezelfde data wordt in beide gevallen overgestuurd. Of denk je dat ze gek genoeg zijn om twee formaten textures te gaan onderhouden?

[Verwijderd]

Als 3raser al zei: een groter scherm met de zelfde pixelgrootte, betekend meer inhoud. Niet gedetailleerdere textures, maar wel meer objecten in beeld die synchroon moeten lopen met de server. Afhankelijk of deze objecten buiten beeld ook synchroon lopen, zal dit dus mogelijk meer bandbreedte vragen.

[feppie64]

Alle textures worden omzet naar instructies. Daardoor zijn ze veel kleiner dan plaatjes. Deze instructies worden op je computer weer omgezet tot textures. Dat scheelt dus al een hoop bandbreedte.

Bron: Development Diary van Jagex

[wimjongil]

Het duurt niet heel lang om te laden, alleen de eerste keer (en elke eerste keer nadat er een update van Jagex zelf is geweest, en wanneer je je cache hebt opgeschoond). De eerste keer duurt het een minuutje ofzo, maar je kan er gewoon iets naast doen

[Baazie]

de bandbreete word niet veel meer hoor,
je download namelijk de client als je laad (in C:\WINDOWS\.jagex_cache_32)
daar word het spel opgeslagen dus als je later er weer op wil gaan zal hij die cache weer laden zodat het heel kort maar duurt, aleen na een update word de cache ook geupdate zo duurt het wat langer..

oftwel het is net of je wow in hoge resolutie zet of laag blijft ong het zelfde

Off topic:
zo maken ze gebruik van de client in privat server

[miw]

Game laadt over een gewone ADSL lijn in ongeveer 50 seconde. Communicatie overhead tijdens het spelen kan iets zijn toegenomen. De meeste objecten worden tamelijk gecomprimeerd opgestuurd, zodat de load op de servers redelijk binnen de perken blijft.

[DeTeraarist]

Een gewone ADSL lijn heb je vanaf 128K tot een mbitje of 10. Iets meer details dus graag

[Verwijderd]

Mooi is dat, de 'geweldig nieuwe grafische kwaliteit' ten toon willen stellen middels een 320x240 Youtube video .

Het enige wat je op die resolutie kan zien is dat ze meer detail in de textures hebben toegevoegd, en dat er in sommige gevallen nu een achtergrond is toegevoegd.
Dat zegt verder dus niks over de kwaliteit van deze extra details, alleen dat het hoogstwaarschijnlijk meer capaciteit van de PC zal eisen (wat ze ook aangeven).

[YopY]

Dat zegt verder dus niks over de kwaliteit van deze extra details, alleen dat het hoogstwaarschijnlijk meer capaciteit van de PC zal eisen (wat ze ook aangeven).

Daar tegenover staat dat er nu hardware accelleratie voor de 3D zooi is, iets wat in de huidige versie nog niet het geval is. Het is daarom goed mogelijk dat deze versie zelfs sneller gaat draaien dan de vorige versie.

[Who Am I?]

Heb dit spel echt heel veel gespeeld vroeger! Vond het echt heel erg leuk, het enige wat erg jammer is, dat er via verschillende 'tips en truc' sites keyloggers werden geinstalleerd waarop mensen je wachtwoord konden achterhalen. Ik ben verschillende malen al mijn items kwijtgeraakt en ook mijn account, gelukkig kon je wel je account terugkrijgen door te bewijzen dat die van jou was, maar uiteindelijk ben ik hem toch kwijtgeraakt. Heel erg jammer. Wat wel een heel sterk punt van Runescape is, dat het voor een groot deel gratis is! Een WOW concurrent zal het niet worden denk ik, daarvoor is de grafische omgeving van WOW te goed. Het wordt idd erg veel gespeeld onder middelbare scholieren tot een jaar of 16.

Ik heb nooit ceats gezocht of watook. Mijn broertje speelde het ook op mijn PC, misschien dat ik hem maar de schuld moet geven.
Over natuurlijke selectie, ik had een combat level van 114 toen ik stopte, max was geloof ik 156 in die tijd. Ben ook 2 jaar member geweest.

[Reactie gewijzigd door Who Am I? op 22 juli 2024 18:33]

[marcieking]

Dat proces heet natuurlijke selectie

[Bosmonster]

Keyloggers installeren nog steeds niet vanzelf. Daar zul je nog steeds toestemming voor moeten geven of een zeer slecht beveiligde/ongepatchte computer voor moeten hebben.

M.a.w., dat doe je toch echt zelf.

[Verwijderd]

Als je een "omgLOLleukfilmpje.exe" naar de gemiddelde (pre)puber stuurt dan ben je al klaar.

[Bitage]

Ondanks dat de reactie boven mij wordt weggemod, zit er weldegelijk een kern van waarheid in. Veel mensen letten niet op met wat ze openen en doen maar wat (en dan spreek ik over de leek, van een tweaker mag je wel oplettendheid en kennis verwachten) en dat vormt toch echt een probleem, zowel voor die mensen zelf (virussen en andere meuk) als mede voor de hele internet gemeenschap (botnets, wormen etc.).

[Reactie gewijzigd door Bitage op 22 juli 2024 18:33]

[Punksmurf]

Hij heeft het over "vroeger" maw een paar jaar geleden op zijn minst. De tijd dat Fx nog niet bestond en IE zo lek was als een vergiet. Zo heel gek is het dan ook niet dat je geïnfecteerd raakte op onbetrouwbare sites. De kans is er nu nog steeds natuurlijk, maar toch een stuk minder.

[bbr]

WoW is ook erg populair, en daarvan is je account nog niet gestolen dan?
Keyloggers zullen niet "zomaar" op je computer komen, dan heb je toch echt iets gedownload wat je niet had moeten doen.

Cheats of hacks lopen zoeken misschien?

[OddesE]

Nee hoor. Er zijn enorme aantallen lekken gedicht in Internet Explorer en Outlook waar je als gebruiker niet zelf actief iets hoefde te doen om besmet te kunnen raken. Zoals Outlook die bij het previewen van een mailtje besmet raakte. Aangezien het nieuwste item automatisch geselecteerd wordt als je de inbox opent, en dus gepreviewed, werd je volautomatisch besmet.

[Zamoraak]

Dit hebben ze zeker ook gedaan omdat de helft weg was gegaan.

[alex3305]

Deze update zat er al een tijd aan te komen en zoiets moet toch weer eerst van de grond af aan ontwikkeld worden wil je het kunnen realiseren. Vergeet daarnaast ook niet het ellenlange testen.

Overigens denk ik dus niet dat ze deze 'update' hebben doorgevoerd vanwege een terugloop van spelers, want anders hadden ze het wel voor iedereen beschikbaar gesteld.

[miw]

De helft die wegging was voor de spelmaker niet echt een probleem omdat de kosten van misbruik (aka goldfarmers die betaalden met gestolen credit cards) waarschijnlijk groter waren dan het verlies aan abbonementsgelden. De huidige variant heeft dus minder last van allerlei misbruik en biedt daarom een veel gezondere basis om verder te groeien.

[Reactie gewijzigd door miw op 22 juli 2024 18:33]

[Noxious]

Dit spel heeft me nooit echt geboeid maar misschien zit ik ook wel in de verkeerde leeftijdscategorie.

Een aantal jaren geleden toen ik stage liep bij het systeembeheer op een Mavo/Havo school speelde zowat de halve school dit in de pauze in de mediatheek. Dat was dan wel de gratis versie.

[leeuwtje1]

jij bent lekker positief over runescape, en dat met zo'n nickname.

(Zamorak: God van het kwaad in runescape)

Heb het als 'klein jongetje' veel gespeeld. maar toch naarmate ik wat ouder ben geworden de betere spellen leren kennen. Het is ook voornamelijk gericht op de jongere spelers, al zat dat mischien niet de intentie zijn.

[Laidback Luc]

Ik vind het nog altijd een leuk spelletje om te spelen na 4 jaar...Wel vaak tijden gehad dat ik het kotsebeu was

Het laden duurde heel lang gisteren, ook een ondragelijke lag de hele tijd. Maar dat zal wel veranderen..Het is er wel meer kinderlijk uit gaan zien, ook zijn er nog heel wat graphische bugs te fixen. Full screen is wel lache maar moet alleen nog wennen aan het gebruiken van de F1-12 knoppen want in full screen is het niet fijn om met de muis te switchen tussen inventory en andere schermpjes.

Ook zijn de kosten van membership met 1$ omhoog gegaan maar dat valt nog mee

[DragonXZ]

Ik was gestopt met dit spel, verveelt en zag er niet uit. Maar ik word nu wel nieuwsgierig hoe het er nu uitziet. Misschien dat ik nog wel is inlog.

[miw]

Als niet abbonee krijg je alleen de mogelijkheid om in een soort demo naar de graphics te kijken. De nieuwe engine is alleen in een beta release beschikbaar voor het spelen door abbonee's. Knap wat er met een Java engine aan grafische truuks uitgehaald kan worden. Dat te doen met een tamelijk uitgebreide spel wereld is een flinke prestatie.

[n0valyfe]

Ik draai een 2 jaar oude PC, AMD Athlon 1.7 GHz en 1GB ram, het loopt sucky.
Naar mijn ervaringen zou ik zeggen... Core2Duo 1.8GHz (minstens) en toch een Graka uit de 7 series (7600 og hoger) Want anders lukt het je niet.

Ze zeggen minstens graka uit 3 series maar dan bedoelen ze safe mode met klein scherm en niet full screen maar wel de nieuwe textures.

Bij mij loopt het enkel soepel in mijn eigen huis op safe mode

[Verwijderd]

In rs : n0valyfe iemand die op plek 1 heeft gestaan
Naam met opzet gekozen ?