Hoofdcategorieën

Runescape wordt opgepoetst

Door Paul Hulsebosch, woensdag 2 juli 2008 14:00, views: 19.903

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.

Hier had een filmpje kunnen staan maar je browser heeft blijkbaar geen flash-support of javascript is uitgeschakeld...

Volgende 14:33
Vorige 13:29

Reacties

«  1  2  3  »

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.



Klopt.
Als die gasten van AoC nou eens gratis trials uit gaan geven of uberhaupt de friendskeys werkend maakt dan zou het al een stuk sneller gaan.
Ik ga niet eerst 50 euro neertellen voor een zoveelste mmo waar ik m'n twijfels bij heb, anders had ik 'm al gecheckt.

Mensen die mijn guild verlieten voor AoC beginnen langzaam aan weer terug te komen... Dus de hype is er wel af.

Ik denk dat dit wel mee valt, Runescape heeft een beetje een kinderlijk karakter (zoals ik het beoordeel) dit heeft World of Warcraft niet. Wat ik altijd wel mis, en dat is voor mij een reden om dit soort spellen niet te spelen, zijn de grafische details.

Doel je dan op spellen in de webbrowser of MMORPG games over het algemeen? Als je bijvb. Age of Conan bekijkt, dan is deze game grafisch absoluut niet slecht. Ook games als LOTRO zien er niet slecht uit. Ook WoW heeft geen slechte graphics, al valt deze niet te vergelijken met AoC en LOTRO.


Ten eerste: Hij zegt juist dat RuneScape een kinderlijk karakter heeft. En juist dat WoW dit niet heeft.
Daarnaast heeft hij helemaal gelijk. Het spel heeft mij nooit veel geboeit. WoW trouwens ook niet is gewoon niet mijn spel.
Ik zie wel vaak kleinere kinderen ermee spelen(oudsten zitten in de brugklas).

Dat zijn de spelers die het kinderlijk maken, de echte spelers, die of er voor gaan, of die vanaf het begin al spelen zul je dat nooit horen zeggen. Let maar eens op, de mensen die zoo schreeuwen doen de hele tijd zo dom. Dat zijn ook totaal niet rerespecteerde spelers, maar die heb je overal!!

Alle spelers zijn echte spelers, groot, klein, serieus, schreeuwers.

Dat valt wel mee. Zo heel erg veel beter is het er nu ook weer niet uit gaan zien ;)
EDIT: Het was trouwens ook wel tijd dat er iets aan de graphics gedaan werd. Als ze het nog wat mooier maken en de videokaart ondersteuning uitbreiden en je niet meer met de muis moet rondlopen, maar met de WASD keys, ga ik het zeker te weten weer spelen! :)

[Reactie gewijzigd door TKing]


Imho het enige waar WoW het lastig mee gaat krijgen de komende paar jaren is de nieuwe MMO game waar Blizzard aan bezig is of zeer misschiens Warhammer online maar voor de rest zie ik weinig concurentie die WoW van zijn troon kan stoten

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?]


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.

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

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]


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.

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?

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.

Dat proces heet natuurlijke selectie :)

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.

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.

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.

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

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?

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.

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 >:)

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.

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

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 :Y)

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

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

wat heeft de grafische omgeving met het al dan niet gratis zijn te maken?
Wow zal niet gratis worden tenzij het spelers aantal laag zou worden (wat niet snel zal gebeuren) & minstens de ontwikkelingskosten zijn terugverdiend(wat wss al zal gebeurd zijn.)

Als je bij ons (middelbare school) dit speelt wordt je uitgelachen. Het wordt voroal door wat kinderlijkere kinderen en neurderige types gespeeld.

Ik ken wel mensen uit groep 7-8 die dit spelen, daar is het ook meer voor bedoeld.

[Reactie gewijzigd door Zamoraak]


Gratis spellen zullen nou eenmaal eerder gedaan worden door mensen die er geen geld uit aan willen / kunnen geven. Dus tjah, scholieren / kinderen zal hoofdzakelijk je doelgroep zijn.
Is toch niet zo vreemd lijkt me.

Neurderige types? En Tweakers.net is zeker de site voor popi-jopi mensen? :+

@ Runescape, ik heb het nooit gespeeld, maar ik weet wel dat er erg veel met accounts gesjoemeld wordt. Echter is dat misschien ook door de naïviteit van kinderen en jong-volwassenen die 'echt' denken items erbij te krijgen als ze hun wachtwoord maar afgeven.

Daarnaast vind ik het wel een verbetering qua grafische kwaliteit. Eindelijk een ontwikkelaar die de 'echte kracht' van Java laat zien!

Jaaa... de echte kracht van Java, zoals in Football Manager 08. Sorry maar Ik blijf erbij dat Java niet echt een Game Platform is. Beetje jammer dat Runescape alleen maar mooier kon dus dat het niet moeilijk was om daar verbeteringen in aan te brengen.

Ik ben van de middelbare school af en het maakte niemand wat uit of je nou rs speeld of wow.

het spel speel je als je het aanspreekt dus niks in een leeftijd categorie plaatsen

offtopic
Defenitie van nerd ?
http://www.encyclo.nl/begrip/nerd wat doe jij dan op de computer? :Y)

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

(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.

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

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.

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 :P

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

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

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.

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.

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.

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.

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.

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.

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]


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.

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 :P
[SIMD in Java]
Hmm interessant, daar zal ik het eea over opzoeken :)

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

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.

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]


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

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 :)
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 14:33
Vorige 13:29
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: