Játékfejlesztés Java nyelven?
2005-07-21T18:47:46+02:00
2005-09-05T08:06:29+02:00
2022-07-26T23:57:32+02:00
  • Nem is arról van szó hogy ekzakt módon lehet-e mérni hanem arról hogy mindent lehet jól és rosszul is megcsinálni.
    Mutasd a teljes hozzászólást!
  • Carmack egy zseni a maga területén, de az a terület a programozásnak csak egy kis szelete. Plusz az ő véleménye is változik, eddig szilárdan OpenGL hívő volt, de a következő játékait már X-Boxra optimalizálja, D3D-vel.

    Carmack bacsi elmondta annak idejen, hogy mi a baja a DirectX-szel. Aztan a 9-re mar megvaltoztak azok a reszek, amiket kifogasolt, igy tehat akar irhat arra is...
    Mutasd a teljes hozzászólást!
  • De nem hinném, hoyg egy számlázóproginál ilyen exakt módszerekkel ki akarják mutatni, hogy melyik a gyorsabb, mivel ott a sebesség majdhogynem indiferens. Más tényezőket meg nem hinném, hogy olyan jól lehet mérni, mint az FPS-t.
    Mutasd a teljes hozzászólást!
  • Ez minden területén így van a programozásnak, kivéve a "helló világ" kategóriájú dolgokat. Egy adatbáziskezelőt, de akár egy számlázóprogit is meg lehet csinálni jobban és rosszabbul.
    Mutasd a teljes hozzászólást!
  • "A jatekok is csak "sima" mezei szoftverek, ami egy "kicsit" tul van lihegve, illetve misztifikalva."

    Ezt aláírom, de szerintem nincsenek annyira túlmisztifikálva, mert ha feltételezzük, hogy a nagy cégeknél nagyon jó programozók dolgoznak (Valve, ID Software), akkor mégiscsak azt látjuk, hogy még ő köztük is hatalmas különbségek tudnak lenni. Vagy ott vannak az amatőr motorok. Nagy részükre csak csúfnév az, hogy motor, inkább techdemo gyűjteményre hasonlítanak, de van köztük is jó, ami valamilyen csoda folytán mégsem veri meg a nagy motrokat. És akik ezeket csinálták, azok is jó programozók. És ha ekkora szemmel látható különbség van (funkcionalitásban nem, de sebességben igen), az már talán okot adhat rá, hogy tiszteljük a játékfejlesztőket...
    A Carmack féle személyi kultusz az szerintem is túlzás, de erről ő nem tehet.
    Mutasd a teljes hozzászólást!
  • Valoban szuksege van a vilagnak meg jobban erositeni az M$-t?

    Ez egy jó kérdés. Valójában azonban a platformválasztásnál nem az a fő szempont hogy kit erősítek/gyengítek vele hanem az hogy a célomat mennyi erőforrás felhasználásával tudom elérni.

    Lehet hogy az M$ is szeretne jo sok penzt latni ebbol a licenszelosdibol?

    Nem hiszem. Ő csak sok windowst szeretne eladni és elkerülni a linux, macos, stb. terjedését a windows rovására. Ami azt illeti ez végül is érthető.

    Amúgy ilyen irányú tervet speciel még nem láttam a M$ részéről, de szvsz hosszabb távon ez lenne a logikus lépés.

    Az engine-ek alapjában véve hasonló dolgot csinálnak, csak az egyik ebben jobb a másik abban. Viszont a 3D motor és a program logikája + a grafika, zene, pályák, stb már ma is elég gyakran elválnak, szvsz logikus lépés lenne ezt az elválasztást API szinten is "szentesíteni". Persze mint mondtam én nem igazán vagyok otthon a játékprogramozásban...
    Mutasd a teljes hozzászólást!
  • "Más típusú feladathoz másféle eszköz kell. De kétlem hogy egy 500 000 soros C# ügyviteli program kisebb programozói kvalitásokat igényelne a fejlesztőktől mint egy 10 000 soros C++-os játékprogi."
    Ezzel 100% ban egyetertek. Sot! A jatekok is csak "sima" mezei szoftverek, ami egy "kicsit" tul van lihegve, illetve misztifikalva.

    "És ezt az architektúrát jobban kihasználhatja egy .NET mint egy unmanaged C++."
    Valoban szuksege van a vilagnak meg jobban erositeni az M$-t?

    "a terület a programozásnak csak egy kis szelete." Mondom ezzel teljesen egyetertek. Igazabol problema megoldasrol van szo, semmi masrol. Es a cel szentesiti az eszkozt mint tudjuk.

    "Másrészt szvsz egy idő után a 3D motorok le fognak válni a játékfejlesztésről"
    Lehet hogy az M$ is szeretne jo sok penzt latni ebbol a licenszelosdibol?
    (Netan elfojtani akar az id-t akar a valve-t, meg a tobbit?)
    Meg mindenki ugyanazt hasznalna, hogy minden egykaptafara feszulne? Nem hiszem hogy ez olyan klassz lenne.
    Pont az a jo, hogy van x fajta engine, amit ha van penz hasznalsz, ha tudsz jobbat, akkor meg megcsinalod.
    Mutasd a teljes hozzászólást!
  • Hogy majd egyszer (szerintem az meg joval odebb van) valami levaltja a C/C++ -t az lehetseges, de nem hiszem hogy a C# lesz az, vagy az überbrutal .NET kornyezet.

    Erre azért ne nagyon fogadj. Bár a vasak fejlődése lassulni látszik, de azért így is egyre gyorsabbak lesznek, és főleg egyre többféle architektúra lesz elérhető. És ezt az architektúrát jobban kihasználhatja egy .NET mint egy unmanaged C++. Plusz a több proci mellett a szemétgyűjtés sem akkora tragédia, különösen ha a program több szálon fut, és a többi szál amúgy is előre dolgozik (Pl. egy játékban számolja a pályán kívüli, a játékostól független eseményeket, és csak ez lassul le a szemétgyűjtéstől).

    Termeszetesen a seged progik irasanal, abszolut realis a .NET-ben valo fejlesztes, bar nem hiszem hogy egy komoly fejleszto csapatnak elonyere valik, ha elhulyiti az embereit.

    Más típusú feladathoz másféle eszköz kell. De kétlem hogy egy 500 000 soros C# ügyviteli program kisebb programozói kvalitásokat igényelne a fejlesztőktől mint egy 10 000 soros C++-os játékprogi.

    Szerintem irjatok egy mail-t Carmack-nak, es kerdezzetek meg rola a velemenyet.

    Carmack egy zseni a maga területén, de az a terület a programozásnak csak egy kis szelete. Plusz az ő véleménye is változik, eddig szilárdan OpenGL hívő volt, de a következő játékait már X-Boxra optimalizálja, D3D-vel.
    Másrészt szvsz egy idő után a 3D motorok le fognak válni a játékfejlesztésről és ugyanúgy plug-in rendszerben lesznek részei a D3D-nek mint ahogy ma a video codecek részei a windowsnak. Tulajdonképpen ma is többnyire külső engine-t használnak a játékfejlesztő cégek, egy rakás progi van aki Quake3 motort használ, Pl. Jedi Knight II és Academy.
    Mutasd a teljes hozzászólást!
  • Annak szántam aki szerint igen. Tudom hogy más szemlélet kell (állítom h ez a Delphi-é, engem nem zavar mit gondolnak, eddig azt használtam, ez ugyanolyan szinte, ja, meg Java-ra is hasonlít, de az elve nem), én egyetértek veled.
    Nem úgy értettem, hogy lehet úgy programozni benne, mint a Win32-ben, (én általánosítva inkább a Régit használnám) hanem hogy egy csomó általános gyakorlatbeli dolog megmaradt. Pl. eddig ott volt a CopyMemory, most meg nincs pointer, nem lehet ilyet játszani. De mégiscsak lehet, mert ahol értelme van, ott az osztálynak "véletlenül" pont van olyan metódusa, ami pont ezt fogja csinálni -most a tömbökre gondoltam-. Byte tömböt is lehet csinálni stb. Ez mind ilyen dolog (és bazi egyszerű dolgok), szval állítom, hogy ott csücsül a régi, egy bizonyos szempontból. Nekem a .NET abban hozott egy szemléletbeli váltást, ahogyan a "komponensekre" tekintek, eddig elutasítotam mindent, ami classlib (Delphi-é), mert lassít, nem hatékony, fele se kell stb. Most meg érdemes használni, legalábbis szerintem, engem az győzött meg, hogy még az sincs megszabva, hogy milyen szinten van a .NET implementáció alábástyázva hardveresen. (Jó, ez már utopisztikus, de elvileg lehetne a jelenleginél jobban is.)
    Persze mindenki más dolgokat szeret csinálni, egy számviteli programot író személy valóüszínűleg jobban hajlik a tömegtermelés felé, vagy akármelyik profi (ha nem lenne egyértelmű, én még csak tanulok, és nem is pont programozást) is keres egy jó kis komponenst magának, de az új elgondolás alapján ezt érdemes is így tenni, ésszerű határok között.
    Mutasd a teljes hozzászólást!
  • Az oldal aszondta nem ment el az üzim, sebaj így legalább nyomatékos...
    Mutasd a teljes hozzászólást!
  • Bocsika!
    NÁLAM Gyk. = "gyakorlatilag", és nem "gyengébbek kedvéért", de remélem senki nem hitte h hülyének nézem...
    Mutasd a teljes hozzászólást!
  • Ajjaj, nem akartam flame-et!
    Gyk. nálam nem "gyengébbek kedvéért" értelemben szerepel sehol sem, hanem "gyakorlatilag" helyett...
    Mutasd a teljes hozzászólást!
  • Amit tudtommal nem is tudod befolyasolni, mikor induljon, meg mit csinaljon.


    Konkrétan nem, de tudod, hogy milyen helyzetben indul el, és te magad bármikor kezdeményezheted, szval ha vmikor biztosítani akarod, hogy ne induljon el, akkor végigsöpörteted, és egy darabig nem lesz. Pl. betöltöttél vmit, jó sok szemét bent maradt, és nem akarod, hogy később jusson eszébe takarítani, akkor kiadod. Persze ehhez az is kell, hogy utána már ne nagyon akarjál memo-t foglalni, ilyen szempontból meg lényegtelen, hogy akarsz-e vagy sem, mert visszakanyarodva az alaphelyzethez, ha ebben a szituban nem foglalnál jelentősen több memóriát futás közben, akkor már nem is indulna be a GC, ha eddig nem tette volna.
    Azt, hogy mit csináljon, valóban nem tudjuk befolyásolni, csak azt, hogy milyen régi szemetet takarítson el, ami tekintve, hogy az lenne az egyik értelme a .NET-es GC-nek, hogy töredezettségmentesíti a memóriát, jobb, ha mindent eltakarít egyszerre, szerintem.
    Mutasd a teljes hozzászólást!
  • Én sem, azért kérdeztem.

    Az 'elhülyítés' téves hozzáállás szerintem, hiszen nem ugyanarra a feladatra valóak. Egészen más szemléletre van szükség, ami felszinesen nézve egyszerű. Aztán meg mégsem.

    Az egy dolog, ha egy C++ fejlesztő úgy akar dolgozni .NET-ben mint Win32 környezetben. De ebben az esetben ő a hülye:)
    Mutasd a teljes hozzászólást!
  • Nem neztem a kodot, de gondolom tudod mi a jelentese a static fuggvenynek.

    Igen tudom, és nem egészen ez. Az a lényege, hogy példányosítás nélkül is meg lehessen hívni a függvényt, de ezt te is nagyon jól tudod, és ez fontos lehet, ha mindenképpen úgy kell valamit megoldani, ahogy a nem OOP rendszerekben meg lehetne tenni. Gyk. ezek nem is igazi metódusok. Azzal hogy memóriaszempontból számítana sokat, azt nem tudom mire érted, mert egy metódus mindenképpen egyszer tárolódik, ha példány specifikus akkor is, szval ilyen szempontból teljesen mindegy. Ha arra gondoltál, hogy egyszer akarod meghívni, és nem akarsz neki osztályt konstruálni, ami viszont eszik memo-t (gondolom így értetted), akkor igaz amit mondtál. Én arra céloztam, hogy egy MS által kiadott papiros szerint lassabb meghívni a static fv-ket. Persze ez így önmagában nem helytálló, de nem volt kedvem megnézni hogy értik, csak kivettek nélhány gyakori műveletet, hogy xy gépen mennyi idő volt lefutnia, és a "call static method" nem volt éppen gyors, az persze lehet, hogy a végeredményt tekintve ez indiferens...
    Mutasd a teljes hozzászólást!
  • Ezzel nem értek egyet. Minden ugyanúgy működik .NET-ben is, még ha nem is szeretnék ezt észrevenni, akkor is.
    ///Maximum C++hoz képest hülyíti el, de nem onnan állnak át sokan.
    Mutasd a teljes hozzászólást!
  • 'a .NET-ben valo fejlesztes (..) elhulyiti az embereit.'


    Érdekes elgondolás. Vagy csak belemagyarázom?
    Mutasd a teljes hozzászólást!
  • "egy elinduló szemétgyűjtési algoritmus"
    Amit tudtommal nem is tudod befolyasolni, mikor induljon, meg mit csinaljon.

    "egy ügyviteli programnál"
    Ezzel teljesen egyetertek.

    "világban idővel a C# szépen leváltja majd a C++-t a játékfejlesztőknél is."
    Hogy majd egyszer (szerintem az meg joval odebb van) valami levaltja a C/C++ -t az lehetseges, de nem hiszem hogy a C# lesz az, vagy az überbrutal .NET kornyezet.

    Termeszetesen a seged progik irasanal, abszolut realis a .NET-ben valo fejlesztes, bar nem hiszem hogy egy komoly fejleszto csapatnak elonyere valik, ha elhulyiti az embereit.

    Szerintem irjatok egy mail-t Carmack-nak, es kerdezzetek meg rola a velemenyet.
    Mutasd a teljes hozzászólást!
  • A játékiparhoz nem igazán értek, de ami keveset az alapján a .NET (vagy java) class libek egy játékprogiban nem sokat osztanak vagy szoroznak. Ugyanakkor ott fontos a realtime közeli futás, azaz Pl. egy elinduló szemétgyűjtési algoritmus nem biztos hogy jól jönne. De lehet hogy tévedek, mondom a játékírás nem az én területem. De Pl. egy ügyviteli programnál 20% sebességkülönbség sem annyira számottevő amikor a progi az ideje jelentős részében vagy az SQL szerverre vagy a user inputra vár. De amúgy sebesség szempontjából tényleg nem lehet annyira rossz a managed rendszerek helyzete, elvégre java-ban már évek óta fejlesztenek szerver-oldali dolgokat, márpedig egy webkiszolgálónak nagyon nem mindegy hogy egyszerre 10 vagy 100 embert tud kiszolgálni adott idő alatt...

    Ráadásul a dolgok változnak, a mai többprocis, multiarchitektúrás (32 bit, 64 bit, intel, amd, kiskutyafüle) világban idővel a C# szépen leváltja majd a C++-t a játékfejlesztőknél is.
    Mutasd a teljes hozzászólást!
  • Nem neztem a kodot, de gondolom tudod mi a jelentese a static fuggvenynek.
    (Hogy az adott osztalybol mindegyik peldany csak egy fuggvenyt hasznal, es termeszetesen csak egy helyen van a kodban.) Memoria szempontbol nagyon is jelentos.

    "Amúgy ha lenne olyan teszt, amin software rendering menne, és nagy guruk írták volna meg minden részről (mint ahogy ez általában nem így van, sőt...), akkor az talán érdekelne."
    Talan ha annyira hajde kemeny lenne (sebesseg szempontjabol) a C# vagy akar a java, talan mar akkor regen abban fejlesztenenek a nagy guruk...
    Semmi flame, csak a tenyek.

    Termeszetesen a .NET kornyezet termelekenyseget nem vitatom.

    (Utolag)
    Ha az a bizonyos sebesseg kulonbseg csak 2% lenne, akkor ezzel a hatalmas termelekenysegi mutatoval, amit a .NET osztalyak mutatnak, miert nem ebben dolgoznak a jatekipar oriasai
    ( ahol tudva levo az ido, es a proci telsesitmeny hianya ) ?
    Mutasd a teljes hozzászólást!
  • C# RulZ, szerintem is!
    Mutasd a teljes hozzászólást!
  • Na szóval, bár már mégcsak ránéztem a C# kódra, az már feltűnt, hogy amit nem lett volna muszály, azt is static tagfüggvényekbe rakták, ami azért nagyon jó, mert MSDN-en valahol láttam egy szép táblázatot, hogy mi mennyire lassú, és miért nem kéne használni (szerintük) túl sokszor, de nem baj...
    //aztán majd ha meglátom, hogy ez így jó, akkor majd visszavonom
    Mutasd a teljes hozzászólást!
  • Na megnéztem a link-et. Legalábbis a táblázatokat, meg, hogy milyen gépen stb. Szerintem abszolút irreális, főleg ez a matrix multiply-os dolog, szval annak lehet hogy megnézem a forrását, hogy mit barmoltak el benne (biztos fent van az is) (nem vagyok akkora guru, de ez durva, mindig megtaláltam a .NET-ben a megoldást azokra a helyzetekre, amikor így elszállt a sebesség). Annál is inkább, mert elméletben az is számítana, hogy ne első futtatása legyen adott programnak, stb...
    Amúgy visszatérve az OGL-es teljesítményhez. Már a csatlakozás módja a külső "könyvtárhoz" determinálja a későbbi teljesítményt, mert míg régen is úgy volt, hogy akármilyen dll-hez "kapcsolódni" lassabb volt, mintha az "exe-be belefordítottad volna", ez most is így van, de lenne rá ok bőven, amiért nagyon lehúzhatná az összteljesítményt (unmanaged alapból, meg el lehetne rontani szépen egyébként is). Ehelyett meg még pozitív változást is elkönyvelhetünk, hogy konkrétan mit azt nem tudom, de elvileg most már a domain részeként muszály egyedileg berántania a külső könyvtárat a memóriába. És itt máris ott tartunk, hogy fontos volt megnézni, hogy mit tud OGL-el, mert nem sokat érne, ha szintetikus környezetben mindent verne, gyakorlatban meg nem kifejezetten.
    Ez az oka annak, amiért azt mondom, hogy de, szabad periféria-szerűségre is írni tesztet (ne a vinyóra várjon pont, mert azzal úgy sem tudnak mit kezdeni, de konzollal lehet szórakozni, mert ott már lehet nagy eltérés is).
    Amúgy ha lenne olyan teszt, amin software rendering menne, és nagy guruk írták volna meg minden részről (mint ahogy ez általában nem így van, sőt...), akkor az talán érdekelne.
    Mutasd a teljes hozzászólást!
  • Novemberre van datálva a megjelenés.
    Mutasd a teljes hozzászólást!
  • Tudtommal még nem jelent meg, a prof verzióra van valami go-live program amivel már addig is fejleszthetsz rá amíg meg nem jön a végleges. Ha jól emléxem erre az évre ígérik - és lassacskán már illenék megjelennie.
    Mutasd a teljes hozzászólást!
  • Ki tudja a VS2k5 megjelent már, ha nem akkor mikor fog?
    Mutasd a teljes hozzászólást!
  • Az hogy miben írták csak olyan szempontból érdekes hogy managed-e a visual studio 2k5 vagy nem. Azon belül már tökmind1 hogy C++-ban írták-e vagy Visual Basic-ben (bár én speciel .NET alatt csak C#-ot használnék, a managed C++ elég perverz egy állat, a vizuábézik meg kell a fenének).
    Mutasd a teljes hozzászólást!
  • Ezek azért nem egyszerű dolgok. Vegyük Pl. a string kezelést. Ezt meg lehet írni C# nyelven is (ha jól emléxem a mono-ban így volt megírva amikor utoljára néztem), és meg lehet írni assemblyben is. Nyilván ez utóbbi gyorsabb lesz. Viszont ha csinálsz egy sebességtesztet amiben van stringkezelés is akkor egyből nem a rendszer sebességét méred hanem a stringkezelés implementációjáét. Ugyanakkor a fejlesztő szemszögéből nézve nagyon nem mindegy hogy mennyire is gyors a "gyári" stringkezelés...
    Mutasd a teljes hozzászólást!
  • A linken levo masodik tablazatban levo adatok mar-mar arra hajlanak, hogy a Java gyorsabb mint a .NET. (Ez engem is meglep, mert sok jot hallottam a .NET sebessegerol.) De nem neztem at en sem reszletesen a benchmarkot.
    Tanulsagkepen azert az levonhato, hogy hasonlo konkurrens technologiakrol van szo, vegulis nekunk fejlesztoknek addig jo, amig versenyeznek egymassal sebessegben is.
    Mutasd a teljes hozzászólást!
  • Ebben igazad van, tényleg nem ez a jó példa, de míg a legtöbb nyers erőorientált dolognál (mittomén saját logika bármire) annyire nem számít a sebesség, addig pont ott igen, ahol külső cuccokat használ. ebbe nem nagyon akarok belemenni, iagazad van benne, nem ezt akartam alátámasztani nagyon, és a cucc idézet volt.
    10-20% eléggé sok. Én szempontomból.
    Egyébként arra pont nem válaszoltál, ami a fő bajom, hogy nem indokoltad meg azzal a mondattal az állításodat. A link-kel talán, de most nem tudom megnézni. Folyt. köv.
    Mutasd a teljes hozzászólást!
abcd