2009. december 18., péntek

A natív és menedzselt kód versenye

A .NET rendszer bevezetésének idején ádáz vita folyt arról, hogy vajon a menedzselt vagy a natív kód az, amelyik gyorsabban fut. Voltak, akik az egyikre, míg mások a másikra esküdtek. Sőt, számos mérési eredmény is közszemlére került. Főleg a C/C++ fejlesztők voltak azok, akik jókat nevettek azokon az állításokon, hogy egy menedzselt kód gyorsabb, mint a születésénél fogva natív kód. Ez a vita mára eldőlni látszik, mégpedig a menedzselt, JIT fordító által generált kódok javára. Ez igaz a Java és .NET kódra egyaránt .
Amikor egy C/C++ fordítóprogram előállít egy natív, futtatható fájlt (pl.: Windows alatt egy EXE-t), akkor különböző feltételezésekkel kell élnie, hogy a generálandó kódot majd milyen működési környezetre optimalizálja. Igyekszik az architektúra szerinti legkisebb közös többszörösnek megfelelő futtatható kódot előállítani. Azt azonban nem tudhatja, hacsak a programozó előre meg nem mondja neki, hogy ahol az a kód majd ténylegesen futni fog, hány processzor van, milyen a processzor és/vagy az adott hardver környezete, architektúrája, utasításkészlete, jellemző tulajdonságai, stb. Elképzelhető, hogy a programozó gépének tulajdonságai (ahol a futtatható kód előáll) gyökeresen eltérnek attól, ahol végül is a program majd futni fog.
Egy menedzselt kódnál a programozó, pontosabban fordítóprogram egy gép és architektúra független, köztes kódot állít elő még akkor is, ha a programozó fordítási időben ezt valamelyest befolyásolhatja. Később ezt a már említett .NET vagy Java szerinti gépfüggetlen kódot az adott számítógépen, ahol a futatás történik a JIT fordító fogja röptében végrehajtható, natív, gépi kódra fordítani. A lényeg az, hogy miközben a JIT fordító sorra veszi a köztes kód utasításait, azt is megnézi, hogy az a gép, ahol éppen működik, milyen architektúrával, utasításkészlettel rendelkezik, és ennek megfelelően képes az általa generált gépi kódot fordítás – vagy „jittelés” – közben optimalizálni. Másképp fogalmazva az adott végrehajtási környezetnek leginkább megfelelő futtatható kódot állít elő, ami gyorsabb lehet, mint egy adott környezetben (pl.: C/C++ fordítóval) már előre legenerált, futtatható kód. Ezen kívül a JIT fordító a natív kód generálása előtt képes kiszűrni és eltávolítani az olyan felesleges kódokat is, mint pl.: if(numberOfCpu > 1){...} vagyis a processzorok számának vizsgálatát akkor, ha az adott gépen csak egy processzor van. Ha pedig a gépbe mégis beletesznek egy újabb processzort, akkor a követező futtatásnál a „jitter” ezt már észleli, és a gépi kód előállításakor ennek megfelelően cselekszik.
Persze egy menedzselt kódnak nem csak előnyei, hanem hátrányai is vannak. Az egyik az, hogy a futtatható program első indulása meglehetősen lassú, hiszen a JIT fordítónak a köztes kódból le kell generálnia natív, futtatható, gépi kódot. Természetesen ez a művelet csak egyetlen egyszer hajtódik végre, hiszen amíg a program a maga natív, gépi kódú állapotában a memóriában van, addig azt többször már nem kell natív kóddá alakítania. A másik hátrány, hogy a program futása alatt a JIT által előállított natív kódot tárolni kell a memóriában, emiatt a fizikai memória helyfoglalása lényegesen nagyobb lehet, mint amit egy eleve natív, futtatható program esetén tapasztalunk. Fontos észben tartani, hogy a .NET rendszert „végtelen” nagy memóriára tervezték. Ez az elképzelés a mai átlagos RAM méret mellet (4GB) már nem is olyan naiv.

2009. december 15., kedd

A játékipar nagyjai: Sid Meier

A többség számára bizonyára ismerősen cseng Sid Meier neve, nem véletlenül. Az 1954. február 24-én született kanadai programozó már több mint huszonöt éve van a szakmában, sokan a "számítógépes játékok atyjának" hívják, de nevével akkor is találkozhattunk, ha nem igazán ismerjük munkásságát, ugyanis több tucat játékot adott ki saját név alatt. Karrirerjét 1982-ben a MicroProse megalapításával kezdte — ebben Bill Stealey, az Egyesült Államok Légierejének visszavonult ezredese volt a segítségére — majd következett az az időszaka, melyet ma már csak úgy emlegetünk: "az elsők". A cég megalapítása után három évvel ugyanis kiadták az első igazi repülőgépszimulátort, az F15 Strike Eagle-t, valamint a Silent Service nevű tengeralattjáró szimulátort. Előbbi programból több mint egymillió példányt sikerült eladniuk, ami bizony ma sem rossz eredmény, huszonöt éve pedig egyenesen kiváló volt. A rókabőr fogalmát persze már akkoriban is ismerték a programozók, az F15 Strike Eagle-ből ennek megfelelően még két rész jelent meg (a harmadik 1993-ban), de Sid ezután sem ült sokáig a babérjain, amit legjobban az 1987-ben megjelent Pirates! bizonyított.

Pirates! Gold

A Pirates! volt az első játék, melynek címében ott szerepelt Sid neve, a program teljes címe ugyanis Sid Meier's Pirates! volt. Erre a marketingcselre azért volt szükség, mert bár Sid korai programjainak rengeteg rajongója volt, a MicroProse a Pirates! megjelenésééig szinte kizárólag repülőgép és egyéb harci szimulátorokat dobott piacra, kellett valami, ami átcsábítja a hangsebességhez szokott gamereket az új stílusú játékra. A Pirates! ugyanis annyira új volt, amennyire csak lehetett. Egy kalózt testesítettünk meg benne, aki a 16. és 18. század között próbálta megszerezni a betevő falatra valót — hogy hogyan, azt a játékos döntötte el. Városokat, hajókat és más kalózokat is meg lehetett támadni, de a békésebbek kereskedhettek, valamint kutathattak kincsek és elveszett rokonok után is. Az 1988-ban az év akciójátéka díjat is besöprő program nem csak nyitott játékmenete miatt volt különleges, hanem azért is, mert a pályák minden egyes játéknál mások voltak (a program dinamikusan generálta őket), valamint a programnak nem volt konkrét vége, addig kalózkodhattunk, amíg csak akartunk — igaz, az idő múlásával minden egyre nehezebbé vált a játékban. A program eredetileg Commodore 64-re jelent meg, de pár év alatt szinte minden létező platformra portolták (Apple II (1987), PC (1987), Apple IIGS (1988), Macintosh (1988), Amstrad CPC (1988), Atari ST (1989), Amiga (1990), NES (1991)), melyeken ráadásul kezdetleges másolásvédelemmel is elláttak — a legtöbb platformnál szükség volt pár információra a kézikönyvből ahhoz, hogy el tudjuk indítani a programot. A népszerű szoftvert kétszer is felújították: az 1993-ban piacra dobott Pirates! Gold Windows 3.1-re és Sega Genesisre érkezett, 2004-ben pedig megjelent a teljesen felújított változat, melyet valószínűleg a Karib Tenger Kalózai című filmeposz is nagyban inspirált.
A Pirates! után még jó pár harci szimulátort dobott piacra (F-19 Stealth Fighter, M1 Tank Platoon), de Sid ekkoriban már a stratégiai játékok felé kacsintgatott. A nagy sikerű Railroad Tycoon 1990-ben került piacra, melyet 1991-ben követett az a Civilization, melyet sokan minden idők legjobb játékának tartanak.
Azt már kevesen tudják, hogy Sid Meier legendás játéka tulajdonképpen nem is annyira Sid Meieré. A programozó ugyanis sok ötletet és technológiai fát "vett kölcsön" az azonos nevű táblás játékból, mely Hartland Trefoil 1980-ban publikált Angliában. Nem is ő volt az első nagy programozó, aki el akarta készíteni a játékot, de ő volt az első, aki véghez is vitte, amit akart. Először az Electronic Artsnál dolgozó Danielle Bunten Berry fejében fordult meg, hogy el kéne készíteni a Civilization játékot. Kétszer is nekifogott, de sem 1983-ban, sem 1985-ben nem fejezte be, úgyhogy végül hagyta inkább az egészet. Másodszor a Utopia (az első szimulációs játék) dizájnere, Don Daglow próbálkozott meg a játék elkészítésével 1987-ben, de mikor felajánlottak neki egy vezető állást a Broderbundnál, dobta a projektet.

Civilization

Sid viszont nem dobta, ezzel pedig valószínűleg unokái anyagi jólétét is megalapozta, hiszen a Civilization hatalmas siker lett. A program időszámításunk előtt 4000-ben kezdődött, célunk egy olyan civilizáció létrehozása volt, mely kiállja az idő próbáját. Meier innentől nem is nagyon próbálkozott más típusú játékok készítésével, a Civilization utódjait és klónjait viszont futószalagon szállította. 1994-ben jelent meg az alapjátékra nagyon hasonlító Colonization, mely azonban közel sem lett olyan népszerű, mint testvére. Ennek oka az volt, hogy a játék megnyeréséhez célszerű (de nem kötelező) volt kiirtani az őslakos törzseket, a rabszolgává tétel lehetősége ellenben hiányzott, holott a valós történelemben létezett — emiatt sokan már filozófiai szinten is kritizálták a programot. Elkeseredettségében Sid 1995-ben piacra dobta a többjátékos funkcióval felvértezett CivNetet, mely gyakorlatilag ugyanaz volt, mint a négy évvel korábban megjelent alapjáték. Ezt követte a Civilization II (1996), két harci szimulációs játék (a Gettysburg! és az Antietam! 1997-ben és 1998-ban), majd jött az újabb nagy siker, az Alpha Centauri. A program nagyon hasonlított a Civilizationre, csak épp ott kezdődött, ahol az véget ért: a távoli jövőben, ahol az emberiség elpusztította a Földet, de találtak egy ahhoz tulajdonságaiban nagyon hasonló planétát, ahol újra elkezdték a csatározást. A siker meggyőzte Meiert arról, hogy a jövője ezekben a játékokban van, az elmúlt tíz évben tehát csak úgy jöttek a hasonló alkotások, melyek elődeikhez hasonló sikereket arattak.

Alpha Centauri

Az utóbb felsorolt programokat Sid már az 1996-ban általa megalapított Firaxis Games berkein belül fejlesztette. Érdekes, hogy az úriember több játékában is elrejtette saját nevét, az Alpha Centauriban például van egy rejtett párt (a Firaxis), melynek Sid Meier a vezetője, de említhetnénk a Civilization III legnehezebb fokozatának nevét (Sid) vagy a Civilization IV-ben a barbárok vezetőjét, aki — döbbenetes, de — szintén Sid Meier névre hallgat.

Civilization 4.

Sid Meier volt a második ember, aki felkerült az Interaktív Művészetek és Tudományok dicsőségfalára (Academy of Interactive Arts and Sciences' Hall of Fame), közvetlenül Shigeru Miyamoto, a Nintendo legendás programozója után. 2008-ban életműdíjat kapott a Game Developer's Conference-en.
Bocha

2009. december 11., péntek

A rommá vert Juventus

Hiába vezetett David Trezeguet góljával 1-0-ra a Juventus a Bayern München ellen a Bajnokok Ligája A-csoportjának ki-ki meccsén, a találkozót végül 4–1-re a meggyőzőbben futballozó bajorok nyerték meg, és így a „zebrák” búcsúztak a legrangosabb európai kupasorozattól. Ciro Ferrara, a Juventus edzője a találkozó után nem keresett kifogásokat, elismerte, a német csapat megérdemelte a továbbjutást.

Elbukta a nagy vizsgát a Juventus

„Nagyon sajnálom a klubot, a csapatot és a szurkolókat egyaránt. Fájdalmas kiesni a Bajnokok Ligájából. Nem szereztünk pontot az utolsó két meccsünkön, egyszerűen nem tudtuk kezelni a kiélezett helyzetet, nem voltunk képesek felnőni a feladathoz” – mondta csalódottan az olasz televíziónak a vezetőedző a mérkőzés után.
A szakember nem keresett kifogásokat, elismerte, hogy a müncheniek jobb teljesítményt nyújtottak, és győzelmükkel megérdemelték a továbbjutást. „Minden tekintetben felülmúlt minket a Bayern, igen keveset tettünk le az asztalra. Nagyon nehéz megfogalmazni, mi volt a bukás oka. Ez olyan sorozat, amelyben mindig motiváltnak kell lenned” – fogalmazott kritikusan a Juve mestere.
Természetesen Jean-Claude Blanc, a „zebrák” elnöke sem kerülhette ki az olasz sajtósok kérdéseit. „Túl sok energiánkat emésztette fel az Inter elleni mérkőzés, fizikailag ma nem tudtuk állni a versenyt. A Bayern nagyszerű csapat, és ezen a mérkőzésen kijött a különbség a két együttes között” – mondta rövid értékelésében a presidente, aki arra hívta fel a szurkolók figyelmét, hogy a nehézségekben is ki kell tartani a szeretett csapat mellett.
„Célunk, hogy tovább erősödjünk, és folytassuk a megkezdett munkát úgy, ahogy eddig. Hogy Ferrara marad-e? Természetesen. Megerősítem a pozícióját” – mondta Jean-Claude Blanc.
Louis van Gaal, a vendégek holland vezetőedzője érthető módon sokkal felszabadultabban nyilatkozott a lefújás után. „A Bayern volt a jobb csapat a pályán. Rendkívüli első félidőt játszottunk, amelyben nem volt szerencsénk, mégis tudtunk válaszolni a Juventus találatára, és ez megfordította a mérkőzést. Talán könnyebb volt felkészülnünk az összecsapásra, mert nekünk csak egy eredmény volt elfogadható, de ma este bizonyítottuk, hogy milyen tartásunk van” – dicsérte csapatát a szakember.

2009. december 5., szombat

id Software engine licencek: múlt, jelen, jövő?

Az id Software kétségkívül azon játékfejlesztők közé tartozik, akiket aligha kell bemutatni. Hiszen valószínűleg még a totálisan casual játékosok is hallottak a Doom vagy a Quake sorozatokról, amelyekben felhörgött a láncfűrész, és aprított a balta egyre beljebb haladva. A belsőségek meg kifelé. A fenti okokból kifolyólag az Ideas from the Deep múltját, pontosabban annak 90-es évekbeli csúcsait csupán érintőlegesen kívánjuk boncolgatni cikkünkben, és sokkal inkább a cég jelenére és jövőjére fókuszálnánk.

Wolfenstein 3D

Az id korai történetét elvileg mindenkinek kívülről kell tudnia, még hajnal négykor felkeltve is: Commander Keen, Wolfenstein 3D, Doom, Quake. A cég a játék nevével ellentétben semmi esetre sem háromdimenziós Wolfenstein 3D-vel megteremtette az FPS-ek műfaját, a Doom sorozattal pedig John Carmack, John Romero és kicsiny csapatuk végérvényesen bebetonozta az id nevét a játékfejlesztők nagykönyvébe. Míg az Apogee Software-rel (a Duke Nukem Forevert nagyjából az Özönvíz óta fejlesztő 3D Realms elődje) közösen kiadott Wolfensteinnek hála Carmack megvehette élete első (de korántsem utolsó) Ferrariját, az id által önállóan terjesztett Doom sikere után pedig valóságos flottát építhetett méregdrága sportkocsikból. A történet ezen részét szinte mindenki ismeri, azt a tényt azonban már sokkal kevesebben, hogy a Doom motorjának alapjait Carmack a szintén ekkoriban induló Raven Software Shadowcaster című játéka számára készítette el, a Wolfenstein motorjának felturbózásával. Ettől a ponttól számíthatjuk az id későbbiekben óriási volumenűre felfutott engine-licenceléseit, ami igazán a Doom motorral teljesedett ki, amelyet már tucatnyi játék használt.

Doom

A grafikus motorok licencelésének napjainkban is reneszánszát élő koncepciójának lényege az, hogy az adott cég (jelen esetben az id) elkészít egy grafikus motort, ellátja azt a megfelelő segédprogramokkal és dokumentációval, és az egészet különféle csomagokban kínálja megvételre. A rendszer nagy előnye, hogy a vásárlónak így nem kell alapjaiból megírnia egy grafikus motort, hanem csak módosítania kell a már meglévőt, amellyel nem csupán időt, energiát, hanem jobb esetben pénzt is spórolhat úgy, hogy garantáltan magas szintű grafikát fog kapni. A Doom szériától kezdve az id számára a grafikus engine-ek licencelése különböző cégek számára ha nem is váltotta ki a játékok eladásaiból származó pénzeket, mindenképpen egyre nagyobb szeletet jelentett a cég bevételeiben. Azonban az igazi forradalmat ezen a téren is a Quake első része indította el, amelynek motorját 1996-os megjelenését követően tömegesen vették bérbe: az engine-licencek terén az id voltaképpen egészen a Quake II megjelenéséig abszolút egyeduralkodónak számított.
A Quake azonban egy másik téren is új fejezetet nyitott a cég történelmében, hiszen elkészülte után hagyta ott a céget John Romero. A programozó-designer, majd pedig a designer Sandy Petersen kilépése, és American McGee szintén 1997-es kirúgása bár hivatalosan persze nem rázta meg a céget, nagyon is éreztette hatását a Quake II egyjátékos részében. Az 1997 decemberében megjelent Quake II folytatta elődei hagyományait abból a szempontból, hogy újfent álleejtős grafikát produkált, innovatív elemekkel bővítette a többjátékos opciót, és millió fölötti eladásait is le lehetett kopogni. A kopp-kopp azonban az egyjátékos részt tekintve csak úgy-ahogy valósulhatott meg, lévén a Quake I gótikus dizájnjához, pályatervezéséhez képest a Quake II sci-fi világa meglehetősen vérszegénynek hatott. Nem volt rossz, de az elődök zsenialitása semmi esetre sem jelent meg benne. Az engine-licencek terén azonban megint nagyot domborított az id, hiszen a Quake II motorját az elkövetkezendő három évben többtucatnyi játékhoz használták fel. Mondhatni a licenszek puszta számát tekintve az id a Quake II-vel ért fel a csúcsra, azonban az egyeduralkodása is pontosan a Quake II megjelenésével szinkronban ért véget.

Quake I.

1997 végén ugyanis már mindenki várta egy Epic Megagames nevű stúdió Unreal című FPS-ét, amely nem kisebb célt tűzött ki maga elé, minthogy porba döngölje az id aktuális motorját. A Tim Sweeney vezette csapat korábban főként a Jazz Jackrabbit szériával szerzett relatív ismertséget, a nagy dobás Unrealt pedig majd’ négy évig fejlesztették. Bár kezdetben maximum heveny röhögőgörcsöket generált annak puszta felvetése is, hogy az Epic egy olyan motort fog készíteni, ami vetekszik az aktuális id motorral, a cinikusok ez esetben alaposan mellélőttek. Mondhatni sikerült kilőniük a hajtókat a szarvasok közül. A játék ugyanis 1998 májusában jelent meg, és ekkorra már aligha volt játékos, akinek nevethetnékje támadt az Epic munkájától, lévén az Unreal motor bizony a földbe döngölte a Quake II engine-jét, legyen szó a modellek részletességéről, a fényeffektekről, avagy éppen a hatalmas külső terek használatáról. Az Unreal megjelenése után számos cég bontotta fel a már megkötött szerződéseket az iddel, hogy a forradalmian új Unreal motorra térjenek át.
Bár az id az 1999 decemberében megjelent Quake III motorjával visszavágott, sőt, nagymértékben felülmúlta a pár hónappal korábban debütáló Unreal Tournament alatt dohogó, továbbfejlesztett Unreal motort, a cég bizonyos hiányosságai ekkor már kezdtek kiütközni. Ezek közül az első mindenkinek szembetűnő volt: míg a Quake II egyjátékos része csupán ellaposodott, úgy a Quake III Arena nemes egyszerűséggel nem is tartalmazott egyjátékos részt, pusztán botok elleni harcot. Vérszegény, mondhatnánk. Azonban bár voltak egyesek, akik cinikusan "techdemónak" nevezték a Quake III-at, az egyjátékos rész totális hiányát egy multira fókuszáló játéknak könnyedén elnézte az ember. Ami viszont keveseknek tűnt fel, az a megnyúlt fejlesztési idő volt: miközben a Quake I, és a Quake II megjelenése között mindössze másfél év telt el, a Quake II és a Quake III esetében ez már két évre nyúlt. Ekkor még senki nem gondolta volna, hogy ennek bármiféle jelentőse is lesz a jövőre nézve; pedig lett, több szempontból is.

Quake III.

Az id számára a Quake III megjelenése újfent azzal a felettébb örömteli procedúrával járt, hogy nem győzték lesni a bankszámlák gyarapodását, mind a végül kétmillió körüli eladások, mind pedig a minden korábbit felülmúló engine-licencek miatt. Azonban amint megkezdődtek, és egyre előrehaladottabbá váltak a Doom III fejlesztésének munkálatai, úgy lett napnál is világosabb, hogy az id hőskorszakból megmaradt csapatlétszáma egyszerűen nem képes megfelelő gyorsasággal játékot fejleszteni. Míg a 90-es évek első és második felében elégségesnek bizonyultak a pártucat fős fejlesztőcsapatok, úgy az új évezredben a mind komplexebbé váló játékok egyre nagyobb és nagyobb stúdiókat követeltek. Ehhez képest az id a 2000-es évek elején is mindössze pár tucat emberrel dolgozott, ami azt eredményezte, hogy a várva-várt, szokás szerint forradalmi grafikát ígérő Doom III megjelenési dátuma olyan nagy népi trükköket vetett be, minthogy elkezdett csúszni, csúszni és csúszni... A játékot 2000 közepén jelentették be, és az eredeti tervek szerint 2002 decemberére meg kellett volna jelennie, amit a Doom III határozottan nem tett meg. Megtette azonban helyette az Unreal Tournament 2003, amely 2002 októberében debütált, és bemutatta, mire is képes az Unreal 2.0-ás motor. Ezáltal az id hirtelenjében akkorát csattant a padlón, mint egy jóllakott csótány, hiszen a cég nem volt képes megfelelő választ adni az Epic új enginjére, csupán az immáron három éves Quake III motort tudták megvásárlásra kínálni. Ez pedig vajmi kevésnek bizonyult az új Unreal engine-nel szemben, habár még egészen 2003 végéig jelentek meg Quake III motoros játékok, ezek korábbi szerződések hozományai voltak, nem új vásárlásoké. A Doom III motor azonban, amely elvileg (és a gyakorlatban is) porba alázta volna az Unreal 2.0-t, csak nem akart debütálni, hiszen maga a játék hiányzott alóla. Carmack az engine-t, a Tech 4-et már 2002-re nagyjából végleges állapotba hozta, azonban a már említett, egészen minimális csapat érthető módon nem volt képes a fény terjedési sebességével haladni a tényleges játékelemek elkészítésével. Éppen ezért a Doom III megjelenése folyamatosan csúszott: 2002 végéből 2003 nyara, tele, majd 2004 tavasza lett, amiből végül is 2004 augusztus elején jelent meg a játék. Mindeközben az Unreal 2.0-ás motort tömegével licencelték a cégek, és az Epic belefogott az Unreal Engine 3.0 fejlesztésébe is, ami nem sok jót ígért az id számára. Ezt Tim Seweeney már igazi next-gen engine-nek szánta – ami persze ebben a formában puszta parasztvakítás volt csupán, azonban az Epic lépéselőnye vitathatatlanná vált.
Játékként a Doom III fogadtatása meglehetősen vegyes volt: amint azt magam is leírtam a bő négy évvel ezelőtti ismertetőben, jónak jó játék volt, de semmi esetre sem kiemelkedő, fantasztikus meg pláne nem. A mára már lassan négymillió közelébe kúszó eladások ugyan mindebből semmit nem tükröztek, azonban a szinte tantrikusan emlegetett engine-licencek annál is inkább. A Doom III ugyanis pontosan félidőben jelent meg: az Unreal 2.0 motor ekkor már közel kétéves volt, míg az Unreal Engine 3.0 megjelenésig pedig még két év volt hátra. Mindez azzal járt, hogy az elmúlt két évben rengeteg cég kötelezte el magát az Epic motorja mellett, másrészt szintén sok cég kivárt: bár az Unreal 3.0-ás csoda megjelenési dátumát még nem lehetett tudni, azt azonban már igen, hogy nagyobbat fog szólni, mint az id féle Tech 4. Ennek, és a csillagok minden bizonnyal roppant szerencsétlen együttállásának, továbbá a világgazdasági válság nem létező előszelének köszönhetően a Doom III motor sikere meg sem közelítette, közelíti az id korábbi grafikus motorjaiét. Külsős cégek alig-alig licenszelték azt, sokkal inkább az id "családi körébe" tartozó fejlesztőcsapatok használták, így a Carmack által rendkívül megkedvelt outsourcing jegyében fogant a Quake 4, a Enemy Territory Quake Wars, és a hamarosan megérkező új Wolfenstein is a Doom III motorját használják. Ez azonban, kiegészítve például az idhez szintén közel álló 3D Realms által fejlesztett Prey-jel, illetve még egy-két játékkal, vajmi kevés a korábbi több tucatnyi játékhoz képest. Mindebben persze szerepe van annak is, hogy az id mindig is olyan grafikus motorokat készített, amelyek elsősorban belső terek megjelenítésére voltak optimalizálva, ellentétben a külső terekben is jeleskedő Unreal engine-ekkel. Ez pedig egy alapjaiban elavult koncepció, amit maga Carmack is beismert azzal, hogy bejelentette: új játékuk, a Rage alatt dohogó Tech 5 már hatalmas külső tereket is képes lesz kezelni.

Doom III.

A Rage-et az id 2007 nyarán jelentette be. Ez a játék a Quake óta az első új id franchise lesz. A videók és a képek az idtől megszokott álleejtős mutatványt generálták a nézősereg körében, azonban kérdéses, hogy a játék ténylegesen mikor is fog megjelenni: a csúszások máris megkezdődtek, hiszen az eredeti tervekkel ellentétben a Rage idén már biztos nem kerül a boltokba. Ismerős történet... Technikai szempontból rengeteg innovációt zsúfoltak az új motorba, amely esetében a helyzet némiképpen a Doom III-ra emlékeztet: Carmack szerint az engine voltaképpen már kész van, játék azonban még sehol, és kérdéses, hogy az id mennyiben tudja tartani a meglehetősen lazán vett megjelenési dátumot. "When it’s done." Bíztató.
A csapat létszáma, dacára annak, hogy immáron elérte az id korábbi méreteihez képest szinte gigantomán ötven főt, még mindig rendkívül kicsinek mondható a nagy fejlesztőstúdiók több száz alkalmazottjához képest. Márpedig az idnek alighanem nagy szüksége lenne a Rage megjelenésével vélhetően újból előrekapó engine-licencelésekre, hiszen e tekintetben a Doom III e téren felmutatott rendkívül gyenge eredményeire financiálisan aligha lehet alapozni. Márpedig pontosan a pénzügyi függetlenség az, amelyet az id már megalakulásától kezdve féltékenyen őriz, hiszen ez tette lehetővé a csapat számára, hogy bár játékaikat a Quake-től kezdve az egyik – sőt, ma már a Blizzardal karöltve a – legnagyobb kiadó, az Activision adta ki, a cég megmaradt magánkézben. Némileg furcsa jel, miszerint a Rage már az EA gondozásában fog megjelenni, még akkor is, ha az óriással csupán ezen egyetlen játék kiadásának erejéig kötött szerződést az id.

Rage

S hogy mit hoz a jövő? Fogós kérdés. Összehasonlítva a 90-es és a 2000-es éveket, szembetűnő, hogy az FPS műfaj megalkotója milyen nagy mértékben szorult hátra, miközben a megjelent játékaik száma (a kiegészítőket nem számítva) hétről kettőre esett vissza – már persze abban az esetben, ha a Rage még ebben az évtizedben megjelenik, amire azonban nem nagyon van reális esély. Pedig a nagy visszatérés lehetősége itt van az id előtt: a rivális Epic hivatalosan még csupán alig kezdett bele az Unreal 4.0 motor fejlesztésébe, amelyet elviekben nem szándékoznak hamarabb megjelentetni, mint ahogy a következő konzolgeneráció kijön. Amennyiben a Rage valóban megjelenik idén, úgy az id kitöltheti az Unreal 3.0 és 4.0 motorok közti űrt. Amennyiben viszont további sorozatos csúszásokra kerül sor, úgy már egy ki tudja milyen képességekkel felvértezett Unreal 4.0-ás motorral szemben kell helytállnia a Rage-nek úgy, hogy közben az egyre erősebb CryTek is belekezdett a CryEngine 3 fejlesztésébe. Ezen rivális motorok megjelenése pedig a licencek számának aligha fog jót tenni. Következésképpen magának az idnek sem.

Gerry

2009. december 2., szerda

Hatmillió .NET fejlesztő készíthet linuxos alkalmazásokat

A Novell bejelentette az első kereskedelmi forgalomban is elérhető megoldást, amely segíti a Linux, UNIX és Mac OS X rendszereken futó .NET alkalmazások fejlesztését Visual Studio környezetben. A Microsoft Visual Studio integrált fejlesztőkörnyezetéhez készült új bővítménymodul, a Mono Tools for Visual Studio abban segíti a .NET fejlesztőket, hogy a már megszokott Visual Studio használatával tervezzenek, kódoljanak és tartsanak fenn többplatformos alkalmazásokat. A Mono Tools használatával jelentősen csökkenthető a fejlesztési költség és idő, így a fejlesztők és a független szoftvergyártók gyorsan és egyszerűen bővíthetik piaci és telepítési lehetőségeiket.
"A Microsoft Visual Studio egy integrált környezet, amely a tervezéstől a telepítésig tartó fejlesztési folyamatot egyszerűsíti le" - mondta Cyrill Glockner a Microsoft Corporation üzleti fejlesztéssel, platformokkal és eszközökkel foglalkozó részlegének igazgatója. "A Microsoft Visual Studio Industry Partner Programmal (VSIP) olyan eszközök fejlesztését támogatjuk, amelyek zökkenőmentesen integrálhatók a Microsoft Visual Studio alkalmazással, és segítik ügyfeleink sikeres működését. A Mono Tools for Visual Studio több mint hat millió, .NET rendszert használó mérnök számára teszi lehetővé, hogy a Microsoft eszközeik és saját tudásuk kihasználásával újabb értéket teremtsenek" - tette hozzá Glockner.

A Mono Tools for Visual Studio lehetővé teszi a Microsoft Visual Studio használatában járatos C# és .NET fejlesztőknek, hogy az általuk használt integrált fejlesztő környezetet megtartsák, és hasznosítsák meglévő gyakorlatukat és .NET kód-, tár- és eszközrendszerüket a Linux, UNIX és Mac OS X rendszeren futó alkalmazások fejlesztésére és az alkalmazások átvitelére. A Mono Tools megjelenése előtt a .NET alkalmazások átviteléhez új programozási eszközök elsajátítására és az alkalmazások újraírására vagy átalakítására volt szükség. A Visual Studio használatát ismerő fejlesztők a Mono Tools segítségével közvetlenül a Visual Studio környezeten belül használhatják ki már meglévő ismereteiket és szakértelmüket a többplatformos alkalmazások telépítésére és a kapcsolódó problémák azonosítására. Egyedülálló, többplatformos fejlesztés a Visual Studio rendszerben.
A Mono Tools a Microsoft Visual Studio bővítménymodulja. Ez az eszköz a Novell által szponzorált nyílt forráskódú Mono projektet fejlesztő és támogató mérnökök közreműködésével jött létre. A Mono Tools for Visual Studio legfontosabb jellemzői:
  • .NET alkalmazások fejlesztése és átvitele Linux, UNIX és Mac OS X rendszerekre: a Mono Tools for Visual Studio használatával a független szoftverszállítók, vállalati fejlesztők és fejlesztési szolgáltatásokat nyújtó vállalkozások jelentős mértékben csökkenthetik a többplatformos alkalmazások fejlesztési költségeit, és időt takaríthatnak meg meglévő .NET alkalmazásaik nem Windows platformra történő átvitelekor.
  • Kulcsrakész virtuális és szoftverkészülékek létrehozása .NET alkalmazásokkal az integrált készülékek fejlesztésére alkalmas funkcióval. A Mono Tools for Visual Studio azonnali integrációt biztosít a SUSE Studio Online alkalmazással, ami pedig lehetővé teszi a SUSE Linux Enterprise Server vagy openSUSE készülékek gyors fejlesztését és tesztelését.
  • Integrált átviteli elemzőeszköz: sok .NET fejlesztő nem tudja, hol kezdjen neki az alkalmazások átviteléhez egy nem Windows-alapú platformra, ez a probléma azonban gyorsan megoldható a Mono Tools-szal.
  • Alkalmazások futtatási és hibakeresési lehetősége a Mono-ban, a Visual Studio rendszeren belül: a Mono és a .NET, valamint a Linux és a Windows közötti inkompatibilitások elkülönítéséhez. Ezzel a funkcionalitással könnyebben megkereshetők azok a problémák, amelyek befolyásolhatják a többplatformos fejlesztést.
  • Automatizált csomagolás a SUSE Linux Enterprise Server és openSUSE rendszerek esetén, amely előkészíti az alkalmazásokat a Linux rendszerre történő azonnali telepítésre.
"A Mono Tools for Visual Studio összekapcsolja a világ egyik vezető fejlesztői platformját, a Visual Studiot és a világ egyik vezető platformját, a Linuxot" - mondta Miguel de Icaza, a Mono projekt alapítója és a Novell fejlesztői platformokért felelős részlegének alelnöke. "Ügyfeleink részéről már régen felmerült az igény, hogy .NET alkalmazásaik Linux, UNIX és Mac rendszerekre történő átvitele könnyebb, egyszerűbb és zökkenőmentesebb legyen. Eszközeink Visual Studio rendszerbe történő integrálásával lehetővé tesszük a Windows és a .NET rendszereket jól ismerő fejlesztők számára alkalmazásaik gyors megjelentetését a Linux-piacon. A független szoftverszállítók pedig szoftvereiket azonnal futtatható készülékként jelentethetik meg" - tette hozzá Icaza.

A Mono Tools for Visual Studio már elérhető. Háromféle termékkiadás kapható: a Professional Edition (magánszemélyeknek) 99 dollárért, az Enterprise Edition (legfeljebb egy fejlesztő egy szervezeten belül) 249 dollárért és az Ultimate Edition 2499 dollárért, amely korlátozott kereskedelmi engedélyt biztosít a Mono terjesztésére Windows, Linux valamint Mac OS X rendszereken, és öt fejlesztői licencet tartalmaz. Minden termékverzió mellé egy éves termékfrissítési előfizetés jár.

Sting

2009. november 29., vasárnap

A játékipar nagyjai: John D. Carmack

John D. Carmack nevét azt hiszem, hogy nem kell bemutatni a belső nézetű lövöldözős játékok kedvelőinek. A ma 39 éves, családos embert minden idők egyik legzseniálisabb programozójaként tartják számon, de emellett érdekes hobbijairól és egyéb furcsaságairól is híres. Hölgyeim és uraim - íme John Carmack!

Carmack 1970. augusztus 20-án, I. István király szentté avatásának 887. évfordulóján született Kansasben. Már fiatal korában is nagy érdeklődést mutatott a számítógépes rendszerek iránt, amit kiválóan példáz, hogy az ifjú Carmack 14 évesen barátaival betört egy iskolába, ahonnan Apple II-es számítógépeket szerettek volna ellopni. Mivel az akció nem sikerült valami jól, Carmackot elkapták a rendőrök, majd őrizetbe vették és pszichiátriai vizsgálatnak vetették alá, melyből kiderült, hogy abszolút nem érez empátiát más emberek iránt. Az ifjú titán egyébként két középiskolát is megjárt (a Shawnee Mission East Középiskolát és a Raytown South Középiskolát), majd a Missouri–Kansas City Egyetemre jelentkezett, ahová az SAT-ban (Scholastic Aptitude Test, magyarul iskolai adottsági teszt) elért eredményeinek - 780 pont matematikából, a maximális pontszám 800 — köszönhetően fel is vették. Az egyetemista élet viszont úgy tűnik, hogy nem igazán jött be a bitek világában sokkal otthonosabban mozgó gólyának, aki két félév után úgy döntött, hogy inkább szabadúszó programozóként tengeti tovább napjait. Mint az a következő oldalon taglaltakból látszani fog, a fiatalember élete egyik legjobb döntését hozta meg akkor.
Carmack lassan betölti a negyvenet, még mindig a programozás az élete, ám 2000 januárja óta házas ember, pár éve pedig családapa, fia jelenleg öt éves. Feleségével, Katherine Anna Kanggel a 1997-es QuakeCon játékfesztiválon találkozott, ahol a hölgy megállapodott Johnnal, hogy amennyiben össze tud hozni megfelelő számú versenyzőt, a programozó lehetővé teszi az első női Quake bajnokság megrendezését. Mivel az 1996-ban megjelent lövöldözős játéknak akkoriban még látszólag csekély női rajongótábora volt, ez egy elég lehetetlen vállalkozásnak tűnt, de Katherine valahogy mégis össze tudott szedni hatszáznál is több versenyzőt, minek következtében meg tudták rendezni a versenyt, melynek első helyezettje 2000 USD-vel és egy kétfős kaliforniai úttal lett gazdagabb. Carmack három évvel később feleségül is vette a rakétavetőt jól kezelő Katherine-t, akivel azóta is házasok. A hölgy egyébként a Kaliforniai Egyetemen szerzett diplomát marketing tanulmányokból, de a számítógépes játékok jobban vonzották, hiszen együtt dolgozott Johnnal a Quake második és harmadik részén, segédkezett a Kingpin megalkotásában, majd a mobiljátékokra váltott, jelenleg az id Mobile vezetője.

A Wolfenstein 3D-tól a Doomig

Szabadúszóként Carmack két játékot írt, mindkettőt Nite Owl Publications adta ki — a Shadowforge-ot 1989-ben, a Wraith: The Devil's Demise-t 1990-ben fejezte be. Tehetségét látva 1990-ben felkereste a Softdisk, akiknek a Softdisk G-S-en, azaz egy Apple IIGS számítógéphez írt publikáción dolgozott. Itt ismerkedett meg John Romeroval és Adrian Carmackkel, az id Software későbbi társalapítóival. 1990-ben futószalagon adták ki Carmack újabb és újabb játékait, a kis csapat ugyanis azt a feladatot kapta, hogy a Gamer's Edge program keretében minden hónapban új, az átlagosnál rövidebb játékokat fejlesszenek a szolgáltatás előfizetőinek. Miközben ezeken dolgoztak, a fiatalok összedobták a Commander Keen nevű platformjáték első részét, melyet nem a Softdisk, hanem az Apogee Software adott ki shareware játék formájában. A sikeren felbuzdulva Romero és a két Carmack megalapította az id Software-t, ahol a maguk szájíze szerint fejlesztettek, játékaikat pedig jellemzően továbbra is az eddig említett két vállalat adta ki.

Pillanatkép a Wolfenstein 3D-ből

A nagy áttörés 1992. május 5-én jött el, mikor shareware formájában napvilágot látott a Wolfenstein 3D, a világ első belső nézetű lövöldözős (FPS) játéka. A játék grafikus motorja a kor szintjéhez képest lenyűgöző volt, nagy részét John írta C és x86 Assembly nyelveken, Tom Hall csak a munka kis részét tudhatta magáénak. Bár a cím alapján három dimenziós játékra gondolhatnánk, a Wolfenstein gyakorlatilag két és fél dimenziós volt, tehát 2D-ben rajzolt ki háromdimenziós hatású környezetet - a jelenséget 2,5D vagy pseudo-3D néven szokták emlegetni. A motor gyakorlatilag egy egy dimenziós mélységi buffert használva határozta meg, hogy mely falak és objektumok legyenek kirajzolva, a technológiát ray-castingnak hívják, mely a ray-tracing egy speciális esete. Bár az engine akkoriban gyönyörűnek számító képi világot adott, megvoltak a hátrányai, emberünkkel fel és lefelé nem tudtunk nézelődni, a pályák pedig egy síkban helyezkedtek el, azaz nem voltak emeletek. Kevesen tudják, de nem a Wolfenstein 3D volt az első ilyen technológiával készült játék, az id Software annak megjelenése előtt a Hovertank 3D-ben és a Catacomb 3D-ben is használta az eljárást, de ezek a játékok csupán 16 színű EGA grafikával rendelkeztek. A Wolfenstein 3D grafikus motorját egyébként további öt játék használta, de mivel a kódot 1995-ben Carmack nyílttá tette, az alapjátékot szinte az összes létező platformra portolták, mostanában iPhone-on játszhatunk vele.
1992-ben a csapat tagjai a Wolfenstein 3D kiegészítő lemezén dolgoztak, John pedig elkezdte fejleszteni új-generációs játékmotorját. A cél a még inkább szemet gyönyörködtető grafika volt, de a programozó mindezt a gépigény alacsonyan tartásával kellett, hogy megteremtse, mivel az akkori PC-k még nem voltak elég erőteljesek ahhoz, hogy valódi 3D-ben számoljanak. A Doom névre hallgató, azóta kultikussá vált játék 1992. december 10-én érte el a közönséget, akiknek bizony tátva maradt a szájuk. A nevét egy Tom Cruise filmből (A pénz színe) kölcsönzött jelenetből vett program Carmack új grafikus motorjára épült, mely bár még mindig ál-3D-s megoldás volt, mérföldekkel körözte le elődjét. A legfontosabb újítás, hogy megjelentek a szintbeli különbségek, textúrázva volt a padló és a plafon, valamint az új motor lehetővé tette, hogy a pályatervezők szakítsanak az elődben lévő labirintusra emlékeztető pályarendszerekkel, a falaknak ugyanis nem kellett merőlegesnek lenniük egymásra. A látványvilágon sokat dobtak a fény- és árnyékeffektek, valamint hogy mozgás közben a játékos karja és az abban lévő fegyver himbálózott, ami némi mozgásérzetet adott a játékosnak. A program kétségkívül legimpozánsabb része mégis az volt, hogy gond nélkül elfutott egy 4 MB RAM-mal rendelkező 386-os számítógépen, amit Carmack a Binary Space Partitioning (bináris térfelosztás) nevű rendszerrel ért el, mely gyorsasága zálogául tartalmazott pár megkötést - a pályákon nem lehettek szobák egymás alatt, továbbá a játékos nem nézhetett szét akármilyen szögben a pályákon, mert akkor nagy torzulás lépett volna fel.

A Doom első része

Mivel az internetre rengeteg információ szivárgott ki már a játék megjelenése előtt, a rajongók folyamatosan arról kérdezték a fejlesztőket, hogy mikor lesz kapható a játék, akik az azóta már szállóigévé vált mondattal válaszoltak: Amikor kész lesz. A játék végül kész is lett, a siker pedig nem maradt el, 1995-ben egy felmérés szerint több mint 10 millió számítógépre volt feltelepítve a program, mely jelentős problémákat okozott a munkahelyeken is, az alkalmazottak ugyanis nagy dugókat okoztak a helyi hálózaton játszott deathmatchekkel. Mivel 1995 végén a program több számítógépre volt feltelepítve, mint a Windows 95, a Microsoftot egy ideig erősen foglalkoztatta az id Software felvásárlásának gondolata. Ez végül nem történt meg, de megkérték a stúdiót, hogy készítsék el a programot Windows 95 alá is, ezzel mintegy szemléltetve a rendszer képességeit. A Doom95 nevű program egyik érdekessége, hogy az azt bemutató videóba még Bill Gatest is bedigitalizálták. A Doomból azóta készült egy erősen B kategóriás akciófilm is, melyben egy Dr. Carmack nevű professzor is szerepet kapott, akit Robert Russell játszik el.

Élet a Doom után, avagy a Quake sikertörténete

Bár a Doom legnagyobb konkurense, a Duke Nukem 3D 1996-ban megjelent, Carmack ekkor már jó ideje a következő nagy lépésen, a Quake első részén dolgozott, mely június 22-én le is taszította a 3D Realms programját az FPS-ek (azaz akkoriban még "Doom-klónok") képzeletbeli trónjáról. A Quake volt az első program, mely valódi, valós idejű 3D-s megjelenítést alkalmazott. A kód nagy részét ezúttal is Carmack írta, de az Assembly optimalizálásnál és egyes algoritmusoknál nagy segítségére volt Michael Abrash is.
A Quake megjelenésének idejében még nem léteztek a mai értelembe vett 3D gyorsítókártyák, a hangok és a mesterséges intelligencia mellett tehát a grafikus számítások is a központi processzor vállára voltak téve - ugyebár 100 MHz alatti Pentium processzorokról beszélünk. Az engine gyorsaságát az tette lehetővé, hogy a 3D-s pályák - azaz a környezet és a konstans tereptárgyak - előre be lettek rendelve, játék közben tehát nem kellett ezekkel számolni a processzornak. A motor egyébként a Doom engine-hez hasonlóan bináris térfelosztást használt, de a látványvilágon sokat dobott a lightmap és 3D fényforrásokon alapuló fény/árnyék megjelenítés, melyet a Quake megjelenése után a legtöbb program át is vett - korábban szektor bázisú statikus fénymegjelenítést alkalmaztak a programok - a Doom 3 megjelenésekor egyébként Carmack megint egy új eljárást vezetett be, de erről majd később. A Quake technológiai újításairól a jövőben egy külön cikket tervezünk publikálni, a további részletekről tehát ebben a cikkben nem kívánunk értekezni. Annyit viszont még megjegyeznék, hogy a program az idő múlásával OpenGL alapú 3D-gyorsítást is kapott, ami tovább emelte a látványvilágot. Ezt az engine-t egyébként rengeteg játékban használták, erre épül minden idők egyik legnépszerűbb többjátékos taktikai lövöldözős játéka, a Half-Life motort használó Counter-Strike is.

Quake 1 és 3

A folytatás 1997. november 30-án jelent meg. A Quake II az egyjátékos módra volt kihegyezve, épp ezért sosem volt olyan komoly versenyjáték, mint a sorozat első és harmadik része. A Quake II-ben találkozhattunk először színes fényekkel, plusz ebben már alapból támogatva voltak a 3D gyorsítókártyák, de alapjaiban a Quake első részének motorjára épült.
A Quake harmadik része ezzel szemben csak és kizárólag többjátékos módot tartalmazott, a mai napig ez az egyik legnépszerűbb lövöldözős játék. Ezt követte 2004-ben a Doom harmadik része, melynél Carmack rengeteget dolgozott az új motoron, ami azonban az erősödő konkurencia miatt technikai áttörései ellenére sem tűnt akkora durranásnak, mint a Quake első része - ebben az is szerepet játszott, hogy elképesztően nagy gépigénye volt. Carmack talán a Doom 3 motorjának fejlesztése során volt szakmai karrierje csúcsán, a két nagy videókártya-gyártó szinte egymást torkát tépve versenyzett John elismerő szavaiért - "úgy gondolom, hogy a Doom most jobban fut Geforce-on". Persze nem kell féltenünk az öreg Carmackot, hiszen jelenleg a Rage nevű félig autós, félig lövöldözős akciójátékon munkálkodik, ami ugyebár akkor fog a boltok polcaira kerülni, amikor készen lesz.

John Carmack furcsa hobbijai

John Carmack amellet hogy kiváló programozó, három dologról ismeretes: a nyílt forráskódú szoftverekért folytatott harcáról, a Ferrari-gyűjtő szenvedélyéről, valamint az űrrakéta-építő kísérleteiről.
Kezdjük ez utóbbival, hiszen minden bizonnyal ez a legérdekesebb a trióból. Carmacknak saját űrrepülési vállalata van, melynek neve Armadillo Aerospace. A programozó - bár nem fejezte be az egyetemet - a vállalat mérnökeként tevékenykedik, egyelőre úgy tűnik, hogy relatíve sikertelenül. Legutóbb 2004-ben járta be a sajtót az egyik sikertelen rakétaindításuk híre, mikor is egy 35.000 dolláros, körülbelül 5 méter hosszú egységet kívántak az űrbe juttatni. Már a startnál komoly problémáik adódtak, a tüzelőanyagnak ugyanis nem volt elég magas az indítási hőmérséklete, amit az Armadillo Aerospace lelkes csapata további hajtóanyag hozzáadásával kívánt orvosolni, sikertelenül. A rakétát végül ki tudták lőni, az elérte a kívánt magasságot, ahol stabilizálták a röppályáját is, ám sajnálatos módon kifogyott a benzin, minek következtében a közel 10 millió forintos űrrakéta lezuhant, darabjai pedig egy 400 méter sugarú körben szétszóródtak. Szinte csodával határos, hogy a fedélzeti kamera által rögzített anyag megmaradt, amit a vállalat honlapján meg is lehetett tekinteni. A vállalat azóta is építgeti az űrrakétákat, az öt éve kissé balul elsült kísérletért pedig valószínűleg kárpótolta őket az a 350.000 dollár, amit a 2008-as Northrop Grumman Lunar Lander Challenge verseny győzteseként vehettek át.
Carmack a Ferrarik iránt érzett szenvedélyéről is híres, ami elég jól mutatja, hogy gyakorlatilag meg sem érezte az olasz sportautók árához képest babajátéknak tűnő rakéta kudarcát. Bár John autóparkjáról nincsenek pontos információink - emberünk ugyanis eléggé elzárkózik a nyilvánosság elől - úgy hírlik, hogy szinte teljes a kollekciója. A kocsikkal kapcsolatos egyik legérdekesebb esemény, hogy 1998-ban az első e-sportolóként számon tartott Dennis "Thresh" Fong ugyanis a Red Annihilation Quake versenyen elnyerte Carmack 328-as Ferrariját (ami úgy 60–70.000 dollárt ért), amin úgy fellelkesült, hogy még évekig versenyzett a Quake első három részében és Starcraftban is – több-kevesebb sikerrel. Miután a fiatalember felhagyott az aktív játékkal, megalapította az xFire nevű céget, melyet 2006-ban 102 millió dollárért adott el - igen, ez 20 milliárd forint.

John munka közben

Azonban ez és a rakétaépítés is eltörpül amellett, amit John a szabad szoftverekért folytatott harca során tett. Tegyük hozzá, nem volt nehéz dolga, csupán annyit csinált, hogy pár évvel azok megjelenése után nyílt forráskódúvá tette grafikus motorjait - persze csak akkor, amikor kellően sok fejlesztő liszenszelte tőle, ugyanis mind a Doom, mind a Quake engine-re több száz kiváló játék épül. John ugyanis úgy gondolja, hogy a programozáshoz az eltökéltségen kívül egy számítógép, valamint megfelelő mennyiségű pizza és diétás kóla kell. Az általa készített motorokból minden bizonnyal tehetséges programozók ezrei lestek el fogásokat, mondhatjuk tehát, hogy Carmack gondosan eltervezett mindent arra az időre, amikor ő már a Marson fogja megálmodni a Doom nyolcadik részének forgatókönyvét. Nem kell tehát aggódni, hiszen valószínűleg John D. Carmack nyugdíjba vonulása után is el leszünk látva kiváló 3D-s motorokkal – viszont attól se féljünk, hogy az úriember egyhamar abbahagyja azt, amiben a legjobb.

Bocha

A Juve-Bayern dönt a továbbjutásról

Juventus elleni hazai, 2–0-s győzelmével megszerezte a csoportelsőséget a labdarúgó Bajnokok Ligája A jelű kvartettjében a Girondins Bordeaux. A Bayern München 1-0-ra kiszenvedte a győzelmet a Maccabi Haifa ellen, így a német rekordbajnok az utolsó fordulóban élet-halál meccset játszik Torinóban. A bajoroknak győzni kell a továbbjutásért, a Juventusnak elég az iksz is.

Szárnyal a Bordeaux: a francia bajnoknak a csoportgyőzelem is megvan a Juve legyőzésével (Fotó: Reuters)
Szárnyal a Bordeaux: a francia bajnoknak a csoportgyőzelem is megvan a Juve legyőzésével (Fotó: Reuters)

Az első félidő Bordeaux-ban sem volt sokkal jobb, 45 perc alatt összesen négyszer találta el a kaput a két csapat… Az egyébként is végig enyhe fölényben játszó Girondins hagyta ki a legnagyobb ziccert, a 38. percben Maruan Samah egyedül lépett ki, de Gigi Buffon hárítani tudta lövését. Fordulás után aztán hamar megszerezték a vezetést a franciák, Jaroslav Plasil szabadrúgása után Fernando emelkedett a legjobban, és fejesével szemben Buffon tehetetlennek bizonyult (1–0). A Juve válaszát Diego próbálta postázni – löketét Carrasso hatástalanította –, majd a brazil irányító Alessandro Del Piero előkészítése után kihagyott egy nagy ziccert is. Del Pieró számára ezzel véget is ért a meccs, a fiatal Ciro Immobile váltotta fel, Amauri helyére pedig Giovinco állt be – a Juve támadójátéka ettől sem lett pörgősebb. A 93. percben Samah bólintott egyet egy szöglet után, végleg lezárva a nyitott kérdéseket – a Girondins teljesen megérdemelten nyert 2–0-ra.
A torinóiak bordeaux-i bukásukkal magukat hozták nehéz helyzetbe, így az utolsó fordulóban hazai pályán a továbbjutás eldöntéséért meccselnek a Bayernnel.

Windows kómában avagy a fekete halál

Nemrégiben találkoztam a következő jelenséggel: a Windows Vista mikor az asztalt betöltené, fekete képernyőre vált, egérkurzor mozog, viszont semmire nem reagál! Csökkentett módban ugyan az a helyzet! Elérhetetlen a gép. A jelenség teljesen váratlanul ért, mivel gond nélkül dolgoztam a géppel, majd készenléti állapotba került és onnan már soha többé nem tért vissza. Mondanom sem kell, vírusirtó volt a gépen. Nekem csak egy megoldás jutott eszembe, az újratelepítés. Hogy ne kelljen ezt átélnie mindenkinek, megosztom a webes nyomozásom eredményeit.

Steel bejegyzése

Találkoztam 2009.10.14-én egy elég érdekes jelenséggel, megosztom, más ne kínlódjon annyit. A Win Xp bootolás után, amikor az asztalt betöltené, fekete képernyőre vált, egérkurzor mozog, viszont semmire nem reagál, sem jobb gomb sem taskmgr, sem semmi. Csökkentett módban, legutólsó helyes confignál is ugyanez a jelenség. Az XP áll és vár, és nem reagál semmire. Mivel viszonylag nagy számban fordult elő, elkezdtem vírust keresni bőszen, természetesen 4 víruskeresőből 4 semmit nem talált. Neveket nem mondanék! Többféle Malware, stb. eltávolító következett a találat szintén semmi.
Felhívtam az egyik vírusirtó cég hazai forgalmazóját, akinek meglepően jó a supportja, de most eredmény semmi. Nem hallottak még a jelenségről, nem tudnak mit mondani.(Jelen pillanatban pedig a vonalaik átmenetileg túlterheltek! Most már biztos hallottak róla :-)
Végső elkeseredésemben elkezdem böngészni a filerendszert, és a helyi profoil/local settings-ben találtam egy gyanús állományt ypdgfw.bak néven. (Egyébkén csak egy dektop.ini van ott.) Azt átmozgattam egy mappába, reboot, és XP indul mint ha mi sem történt volna. Hurrá!
Jöhet a többi gép, meg a pofára esés, Local settingsben semmi.... (jelenség: fekete halál) Kis gondolkodás, aztán rákerestem a fájlméretre a teljes meghajtón. A windows mappában megvolt. Más néven. Legyógyít reboot, örülés. Szóval ha valaki találkozik a jelenséggel, ne aggódjon. Be kell bootolni miniPe lemezről, és rákeresni a windows mappában 18432 byte méretü állományokra. Lesz néhány, de van benne egy amelyiknek a neve többnyire értelmetlen karakterhalmaz, a dátuma pedig 2009.03.21 ha ezt eltüntetitek, aztán reboot minden megy tovább...
Én kb a 100. ilyen gépen vagyok túl 2 nap alatt, és szerintem ez folytatódik. Közben utánaolvastam a dolognak, (elméletileg a Win32/Daonol.F vírusról van szó) meg elküldtem a Nod víruslaborjába egy pár állományt, de még nem kaptam válasz. Ha valakinek valami konkrétabb ifója van, ne fogja vissza magát!

Microsoft reakció

Kedves Viszonteladó Partner,
Több helyről kaptunk információt arról, hogy a WindowsXP aktuális frissítése közben a PC “lefagyott” és csak a kurzor látszott a fekete képernyőn. Mérnökeink utánanéztek a problémának és a következőkre jutottak:
A problémát valószínűleg egy virus fertőzés okozza. Általában a C:\Documents and Settings\Local Settings\ vagy a C:\Windows\ mappában található egy 18432 bájt méretű fálj. Mivel változó helyen fordul elő és változó néven, ezért a méretére kell rákeresni. A munkamenet a következő:ha van lehetőség, át kell kötni a merevlemezt egy működő rendszerre. Méret alapján keresni kell a fáljra. Ezután kitörölni vagy átnevezni. Visszahelyezni a merevlemezt az eredeti számitógépbe, és inditani a rendszert.
Illetve a Start\Futtatás…\regedit és törölni kell a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Drivers32 útvonalon azt a midi nevet, ahol az érték a C:\Documents and Settings\”user”\Local Settings\-al kezdődik és az 18432 bájt méretű előbb kitörölt fájlra mutat.

A probléma oka részletesebben

A Microsoft Magyarország értesülései szerint az utóbbi napokban számos felhasználó találkozott olyan problémával, hogy számítógépén a korábban jól működő Windows XP rendszer hirtelen nem indul be teljesen - a képernyő fekete marad, csak a kurzor látható rajta.
A szoftvercég szerint ezt az általában Microsoft Update frissítések telepítése után előforduló problémát vírusfertőzés okozhatja és megoldásként fájlok, illetve registry kulcs törlését javasolják. A finn F-Secure antivírus gyártó részletesen utánajárt a problémának és az általuk talált adatok igazolták a gyanút: az események valóban egy fertőzéssel kezdődnek.
A Delf.phk néven ismert, 15.872 bájt méretű trójai program a gépre jutva véletlenszerű néven a lemezre írja magát. A kártevő ezután hozzákezd a rendszer alaposabb megfertőzéséhez: letölt és telepít egy Kates.j nevű jelszólopó programot, amely beépül a felhasználói környezetbe. Ez a 18.432 bájtos kártevő az alábbi Windows API komponenseket manipulálja rejtett működése érdekében: kernel32.dll, advapi32.dll és user32.dll.

Bajt okozhatott a jó szándékú változtatás

A felhasználók által tapasztalt problémát éppen az okozhatja, hogy egy nemrég megjelent Microsoft Update frissítés biztonsági okokból változtatást eszközölt a fenti DLL rendszerfájlokon. A kártevő, amely addig szépen, csendben ügyködött a gépen, a javítófoltozás után már nem tud teljesen betöltődni és ez akadályozza az általa behálózott Windows felhasználói környezet indítását - a képernyő fekete marad.
Az eset fő érdekességét a ritkasága jelenti, mivel a modern kártevők mindent megtesznek az észrevétlen, a felhasználó számára láthatatlan működés érdekében. A netes bűnözők célja az, hogy ártó szoftvereik a lehető legtovább rejtve ügyködhessenek a feltört gépen - miközben ők értékesítik annak spam-küldő és DDoS hálózati támadó kapacitását, illetve visszaélnek a felhasználótól ellopott személyes azonosítókkal. Komoly műszaki hiba szükséges ahhoz, hogy a módszer lelepleződjön és most éppen ezt történt!

Van segítség!

Szerencsére a Windows-t fejre állító Kates.j mentesítésre több út is kínálkozik. Ha a gépet sikerül annyira beindítani, hogy a háromgombos kombináció (Ctrl+Alt+Del) hatására megjelenjen a Feladatkezelő ablaka, akkor ott lehet új folyamatot indítani, például webről elérhető víruskereső, vagy ingyenes egyedi mentesítő program futtatása céljából.
Ha ez nem lehetséges, akkor a gépet külső forrásból is át lehet vizsgálni. Erre a célra elérhetők a neten vírusirtót tartalmazó ún. Rescue CD csomagok, amelyeket például a finn F-Secure és az orosz Kaspersky Lab biztonsági cégek weblapjáról is ingyen le lehet tölteni indítólemezre írás céljából.
Hozzáértők kézzel is mentesíthetnek, bakizással azonban tönkre lehet tenni a Windows-t, így a feladat odafigyelést igényel! Töröljük a kártevő által létrehozott registry kulcsot:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32\midi9"véletlenszerű_név.bak 0yAAAAAAAA"
Keressük meg és nevezzük át a véletlenszerű nevű, 15.872 és 18.432 bájtos fájlokat a \Documents and Settings\felhasználó_neve\Local Settings\ alatt és a Windows rendszermappában. (A törlés csak akkor javasolt, ha nagyon biztosak vagyunk a dolgunkban!)
A gép sikeres beindítása után mindenképpen futtassunk le a Windows alatt is egy teljes körű ellenőrzést, hogy meggyőződhessünk arról, nem maradt további rejtett kártevő a gépen és a későbbiekben is vigyázzunk a Windows rendszer épségének fenntartására - amihez a víruskereső, kémprogramirtó és személyi tűzfal folyamatos futtatása elengedhetetlen!

- Flaxcom, F-Secure, Net Academia nyomán -

2009. október 29., csütörtök

Fejezetcímeket a fejlécbe

Ha a fejezetcímeket szeretnénk megjeleníteni a dokumentumunk fejlécében, akkor a következők teendőek. Nagy anyagban a fejezet címére hivatkozás:
Az első lépés az, hogy könyvjelzővel megjelöljük a fejezet címét, amire hivatkozni szeretnénk. Ezt a következő képen érdemes megtenni.
  1. Jelöljük ki a fejezet cím teljes szövegét. A bekezdés vége jelet hagyjuk ki!
  2. Nevezzük el a kijelölt szöveget könyvjelzővel.
  • Beszúrás > Könyvjelző parancs
  • Adjuk meg a könyvjelző nevét. Szóköz ne legyen benne, mert azt nem fogadja el.
  • OK gomb klikk!
Nos eddig meg is volnánk. Most álljunk oda a doksiban, ahova a hivatkozást szeretnénk beszúrni. Ha most a bekezdés címét szeretnénk megjeleníteni a hivatkozásban, akkor a következő a teendő:
  1. Beszúrás > Mező parancsot hajtsuk végre.
  2. A megjelenő párbeszédpanelben keressük meg a Ref mezőt.
  3. Ha megtaláltuk ott fog ránk várni a könyvjelző neve, amit az előbb hoztunk létre.
  4. Jelöljük meg a könyvjelzőt és kattints az OK gombra.
Ha oldalszámmal szeretnénk hivatkozni, akkor pont ugyanezt kell tennünk csak a PageRef mezővel.

2009. október 28., szerda

Juventus–Maccabbi Haifa (1-0) 2009

A Juventus Giorgio Chiellini második félidő elején fejelt góljával 1–0-ra legyőzte a Maccabbi Haifát, és a második helyen áll a Bordeaux mögött.
Az Öreg Hölgy francia támadója, David Trezeguet elégedetten nyugtázta a három pont begyűjtését, de csapata játékában talált kivetnivalót. „Nem vagyunk teljesen elégedettek azzal, amit támadásban nyújtunk – értékelt Trezeguet. – Még mindig nem szerzünk elég gólt, túl sokat foglalkozunk a védekezéssel."
„Ennek ellenére nagyon örülünk a győzelemnek, hiszen fontos három pontot gyűjtöttünk be, és az ellenfél nagyon megnehezítette a dolgunkat – folytatta a 32 éves csatár. – Ismétlem, nagyon sok munka vár még ránk, de tudunk hová fejlődni."

2009. október 16., péntek

Magyarország világbajnoki bronzérmes!

A magyar válogatott 1–1-es rendes játékidő után tizenegyesekkel legyőzte Costa Ricát az Egyiptomban zajló U20-as világbajnokság bronzmérkőzésén, így hatalmas sikert elérve legjobb európai csapatként a harmadik helyen zárta a tornát. Urena a 81. percben szerzett vezetést a közép-amerikaiaknak, Koman Vladimir büntetőből tíz perccel később egyenlített. A tizenegyespárbajban Gulácsi Péternek nem lehetett gólt lőni, tőlünk azonban Németh Krisztián és Varga Roland is betalált, így következhetett a magyar ünneplés…

Örömszavak

"A saját teljesítményemet nem szeretném értékelni, a csapat viszont egy nagyon jó világbajnokságon van túl. Remélem, hogy a felnőttek között is sokra viszi ez a társaság" – nyilatkozta a 91. percben sorsdöntő büntetőt értékesítő Koman Vladimir a Magyar Televíziónak a lefújás után.

Határtalan magyar öröm: miénk a bronzérem! (fotó: Reuters)

"Ezt a sikert közösen értük el. Az egész stáb rengeteget tett érte, és azok is, akik ma nem jutottak szóhoz" – szerénykedett Gulácsi Péter, akinek a Costa Rica-iak nem tudtak túljárni az eszén a tizenegyespárbajban.

One, Two, Tao

Eredetileg a TAO Framework beüzemeléséről szerettem volna írni, de mint mindenben itt is megelőztek és egy nagyon profil leírást találtam róla magyar nyelven MaNiAc tollából! Mivel jobbat nemigen tudnék írni ezért egyszerűen plagizálom a bejegyzést. Ne felejtsük a plágium a szakmai elismerés és a hízelgés legmagasabb foka! :)

Snippet Compiler: pehelysúlyú Visual Studio alternatíva

Egy fantasztikus és jópofa bejegyzés Molnár Gergő tollából. Kötelező darab! VS Kuka! :)

Előfordult már, hogy valamilyen kódot, kód-részletet ki szerettünk volna próbálni? Nyilván igen (ha nem, fölösleges is tovább olvasni). Ilyenkor egy új Visual Studio megnyit... krrr, krr... New Project... krrrrr rrr, konzolos alkalmazás, rrrrkrrrr...
Szóval zseniális IDE a Visual Studio, de az ilyen ötsoros alkalmazásokhoz az ionágyúval verébre kategória. Felmerül a lehetőség, hogy egyszerűen Notepad-ben megírjuk a kódot, aztán jöhet a csc.exe, de az meg a másik véglet: enni ugyan alig kér, viszont adni se ad sokkal többet. Intellisense, syntax highlight nélkül mit érek én? Akkor már ennyi erővel lehetne edlin is... (Az megvan, hogy ez az MS-DOS 5.0 óta minden Microsoft oprendszerben ott van? A hetesben is. Nem, nem az MS-DOS 7.0-ban, az ablakos hetesben.)
Mindent összevetve, egyik sem jó megoldás. Kellene egy lightweight Visual Studio, amire az ember csak rábök, és már írhatja is a kódot.
Mit ad isten: van ilyen, úgy hívják, hogy Snippet Compiler. Egyszerű, mint Kiszel Tünde, de a legszükségesebb dolgokat tudja. Az installja 1 MB és egy .zip kibontását jelenti, szemvillanás alatt indul.
Ja, és a legjobb, hogy az "Add Reference..." ablak (itt Tools -> References) körülbelül 0.05 sec alatt ugrik föl. Na ezt csinálja utána a Studio!

2009. október 15., csütörtök

SharpZipLib

Ugyan a C#-nak van beépített tömörítő függvénye, de én mégis jobban preferálom a sharpdevelop SharpZipLib könyvtárának függvényeit. Állandó probléma a tömörítő könyvtárak API-jával hogy körülményesek, és ritkán vannak olyan függvények hogy "itt az adat tömörítsd". Ez különösen igaz a BZIP2-re, amit eredetileg stream észrevétlen tömörítésére terveztek de nagy ereje miatt általánosan használt lett. Ezért írtam két függvényt bináris adat ki és betömörítésére BZIP2-vel. Ahhoz hogy használjuk az alábbi függvényeket, hozzunk létre egy hivatkozást (project menü > add reference) az ICSharpCode.SharpZipLib.dll-re (a Visual Studio majd bemásolja az exe mellé). És itt a kód:
   using System;
using System.IO;
using System.Text;
using ICSharpCode;

namespace Ird_ide_a_programod_namespace_et
{
class BZip2
{
///
/// Adat tömörítése BZip2-vel.
///

/// Tömörítendő adat.
/// Tömörített adat.
public static byte[] Compress(byte[] data)
{
try
{
MemoryStream output = new MemoryStream();
ICSharpCode.SharpZipLib.BZip2.BZip2OutputStream bout =
new ICSharpCode.SharpZipLib.BZip2.BZip2OutputStream(output);
bout.Write(data, 0, Convert.ToInt32(data.Length));
bout.Close();
output.Close();
return output.ToArray();
}
catch (Exception e)
{
throw (e);
}
}

///
/// BZip2-vel tömörített adat kitömörítése.
///

/// Tömörített adat.
/// A memóriában foglalható max. hely. (byte)
/// Kitömörített adat.
public static byte[] Decompress(byte[] data, int MaxData)
{
try
{
MemoryStream input = new MemoryStream(data);
ICSharpCode.SharpZipLib.BZip2.BZip2InputStream b_in =
new ICSharpCode.SharpZipLib.BZip2.BZip2InputStream(input);
byte[] output = new byte[MaxData];
b_in.Read(output, 0, MaxData);
b_in.Close();
input.Close();
return output;
}
catch (Exception e)
{
throw (e);
}
}
}
}

C# teljesítménymérés

Mai napon le akartam mérni, hogy egy módszer mennyi idő alatt old meg egy feladatot és elkezdtem keresgélni, hogy mivel lehet pontosan mérni a sebességet. A DateTime.Now.Ticks-es módszerről azt olvastam, hogy nem ad pontos eredményt. De ráleltem egy egyszerű és pontos megoldásra: a System.Diagnostics.Stopwatch osztályra! A használata:
namespace StopWatch
{
class Program
{
static void Main(string[] args)
{
List outs = new List();

// Létrehozunk egy példányt az osztályból
Stopwatch s = new Stopwatch();

// Elindítjuk
s.Start();

for (int i = 0; i < nums.Count; i++)
{
if (i % 2 == 0) outs.Add(i);
}

// Majd megállítjuk
s.Stop();

// Kiírjuk a futás idejét milliszekundumban
Console.WriteLine("For: {0} ms", s.ElapsedMilliseconds)
}
}
}
Remélem sokan megismertetek egy jó módszert a kódok futási sebességének mérésére!

2009. október 4., vasárnap

EA Games vs Documents Folder

Az ember szívesen lazít videojátékokkal. Főleg akkor, ha azok színvonalasok, mint az EA játékai. Személyes kedvencem a FIFA és a Need for Speed sorozat. Nemrégiben le is töltöttem a FIFA és az NFS legújabb részeit: FIFA 10 és NFS Shift. A kifejezetten hosszú telepítés után remegő kézzel klikkeltem play ikonra és vártam … vártam … hogy elém táruljon egy szép új izgalmas világ. De ezzel szemben csak egy hatalmas ERROR-t kaptam egy kis ablakba bekeretezve. Ilyen ritkán van, mindig minden pöccre indul a masinán. Gondoltam akkor majd az NFS fog megvigasztalni, klikk and play! Yes! A játék felpörög az intro lepadlóz, minden nagyon zsír. Készítem a profilom és ekkor közli velem ez a dög, hogy nem képes menteni a profilt! Árhhhhh! Kettőből semmi. Akkor majd a SIMS 3 fog boldog perceket szerezni nekem, szóval: download, install, click and play és … szerintetek? Elindult? Naná, hogy nem! Fatal Error és társai…szóval egy EA Games sem indult el a gépemen. Ekkor beindultam és becsületbeli ügynek éreztem a hiba kinyomozását.
  1. Első körben a legújabb VGA driver-t telepítettem. Semmi hatás.
  2. 10 GB szabad helyet hoztam létre a merevlemezen. Semmi hatás.
  3. Leszedtem minden CodecPack-ot. Semmi hatás.
  4. Kilőttem minden háttérben futó folyamatot. Semmi hatás.
Ekkor, mint derült égből a villámcsapás, jött a NAGY ötlet! Mit is mondott az NFS Shift? A profil mentése sikertelen (unable to save profile). Hmmm. Hova is szoktak menteni a játékok? Csak nem a… Dokumentumok mappába? De igen! Gyorsan meg is lestem a jogokat és annak ellenére, hogy rendszergazda voltam a gépemen nem tudtam létrehozni új mappát benne! Basszus!

Megoldás

Jobb klikk a Dokumentumok mappán és klikk a Tulajdonságok feliraton. Ekkor a következő ablak tárul elénk:
Válasszuk a Biztonság fület, ezen az oldalon válasszuk ki a szerkeszteni kívánt felhasználót és a Szerkesztés nyomógomb segítségével adjuk meg magunknak azt ami jár: Teljes hozzáférés. A beállítások után az NFS Shift képes volt már elmenteni a profilt, a FIFA 10 is elindult, mert létre tudta hozni a FIFA 10 mappát a Dokumentumok könyvtárban és ez nem volt máshogy a SIMS 3 esetében sem. Szóval 4-5 óra játék helyett ezzel lazítottam.
Érdekes, hogy az EA programozók nem készültek fel erre a hibára. Nem is feltételezték, hogy a Dokumentumok mappa írásvédett lehet. Pedig lehet! Ez olyan amatőr programozói hiba, de tényleg! Csak ennyit kellet volna tenniük: Try { Fájl létrehozása } Catch { Windows(”IO Error”) } avagy a Windows jogosultságkezelése kicsit faramucika és nem csak őket, hanem engem is igen megszívatott.
Összefoglalva: az EA játékok szeretnek a Dokumentumok mappába mindenféle csudadolgot létrehozni ezért legyen jogosultságunk az íráshoz/olvasáshoz valamint jó ha tudjuk, hogy azon a meghajtón keresi a Dokumentumok mappát amelyre magát a játékot telepítettük! Ha a Dokumentumok mappa a C meghajtón van de a játék mondjuk az F meghajtón akkor az még cifra lehet. Erről ennyit.

Híd a Java és a .NET között

A Microsoft támogatásával hidat vert a Java és a .NET közé egy francia cég. A Noelios által gondozott Restlet nyílt forrású REST (Representational State Transfer) framework legújabb változata már képes együttműködni az Ado.NET Data Servicessel.
Bodnár Ádám, 2009. szeptember 29.

Mindez azt jelenti, hogy a Restlet kiterjesztése segítségével Java alkalmazásokból is könnyen elérhetők az Ado.NET szolgáltatások. A legfontosabb problémát az Ado.NET esetében az autentikáció jelenti, ugyanis az Ado.NET adatszolgáltatások rendkívül sok metaadatot használnak az azonosításhoz, amelyeket fel kell dolgozni. A Microsoft saját kliensein (.NET és Silverlight) kívül eddig csak PHP-ból voltak könnyen elérhetők az Ado.NET szolgáltatások, a Restlet továbbfejlesztésének köszönhetően ez most már a Java nyelven írt alkalmazások számára sem jelent akadályt.
A Restlet lényegében Java-osztállyá alakítja ezeket a metaadatokat és így a Java alkalmazásokból ugyanúgy elérhetők a távoli Ado.NET szolgáltatások mint a lokális entitások, a többiről a Restlet futásidejű komponense gondoskodik. A fejlesztők a lehető legtöbb gyakori felhasználási modellt lefedték már, de a funkcionalitás még nem teljes.
Az Ado.NET Data Services viszonylag új kezdeményezés a Microsoftnál. A korábban Astroria projekt néven ismert technológia URL-eken keresztül teszi lehetővé adatok lekérdezését, írását, felülírását vagy törlését egy adatforrásban, legyen az adatbázis, XML vagy bármilyen fájl. A Restlet használatával a Java-programok is csatlakozhatnak a Microsoft adatbázisaihoz, a Windows Azure cloud platformon futó adatszolgáltatásokhoz, vagy bármilyen .NET platformhoz.
A Restletről és a működésről további információ a Noelios weboldalán, valamint a Microsoft Interoperability blogban lehet olvasni. A Reslet letölthető a Noelios oldaláról.