Hirdetés
- Send to qBittorrent (with SavePaths): Egy apró Firefox kiegészítő qBittorrenthez
- Ikea PAX gardrób és a pokol logisztikája – egy Ikea-horror igaz története
- -TongFang- Medion Erazer Beast 16 X1 - induló teszt így kora délután..."CB R23"
- Pi-hole és a Telekom Sagemcom F@st 5670 DNS beállítása
- A Magyar Néphadsereg emlékére
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- GoodSpeed: A RAM-válság és annak lehetséges hatásai
- Magga: PLEX: multimédia az egész lakásban
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- D@reeo: Pi-hole és a Telekom Sagemcom F@st 5670 DNS beállítása
- Ketogén étrend
- sziku69: Szólánc.
- [K2]: AnyDesk átverés
Új hozzászólás Aktív témák
-
Pikari
veterán
Ehhez most a komplett élettörténetemet le kéne írnom, de megpróbálom pár szóban lerövidíteni. Én enginefejlesztéssel foglalkoztam főleg 1998tól kezdve, így elég nehéz válaszolni a kérdésedre. Ekkor még először dosra dolgoztam (text mode only), és játékokat viszonylag ritkán írtam, de természetesen tudok időintervallumokat mondani.
Dosról elrugaszkodva, 2000-től kezdve aztán nem akartam megtanulni a windózt, így én is third party engine-alapokat és egyéb toolokat használtam kezdetleges enginek megírásához, ezekkel játék gyanánt kezdetben egyszerű komolytalan 2d ugrálós cuccokat írtam tipikusan 1-2 napnyi munkával. Aztán egyszerűbb mászkálós RPG-ket, kalandjátékokat és szerepjátékokat írtam már az akkori saját 3D engine kezdeménnyel, azzal az enginevel két olyan játékot írtam, amivel játszani is lehetett (nem csak wasd röpködés volt, meg nem ilyen low effort valami). Azzal egy-egy valamire való játék kb 1-2 hónap alatt készült el (egy 2002-ben és egy 2004-ben).
Ezen a ponton kb ugyanazok a problémák fogalmazódtak meg bennem, mint amiket a cikkben leírtál, egyszerűen túl gagyi volt a végeredmény, nem lehetett velük haladni. Végül 2006ban az egyetemen tanultam meg a C programozási nyelvet. Emellé elsajátítottam az openglt, és írtam magamnak egy rendes 3d enginevel összeintegrált game enginet, és egy ideig hivatásszerűen is ezzel foglalkoztam, ekkor viszont csak az enginet írtam az ügyfeleim részére, de játékot nem.
Ezután kidobtam az openglt és azt az enginet is, és új enginet írtam (részben a régi refaktorálásával) - új rendererel, de közben már nem volt igény oylan fajta enginekre, amiknek a gyártásával foglalkoztam, így annak a biznisznek vége lett, és visszadegradálódott hobbivá, és már nem ezzel foglalkozok hivatásszerűen nagyon régóta.
De hobbiként igen - úgyhogy ezt követően írtam az enginemmel egy rpg játékot (alone in the dark szerű, előrerenderelt háttér) ahol magának a játéknak a megírása az enginemben kb másfél hét volt (de magának a game enginenek a megírása természetesen több hónapon át tartott, az engine részt 2018 körül írtam újra, a játékot magát 2020 körül).
Az utolsó játékomat pedig (ami egy szöveges, képes kalandjáték) DOS-ra írtam (8088 processzorhoz) ahol kb egy hét aktív munka volt az engine, aztán 1 hét maga a játék. Ez a dosos játék az utolsó befejezett játékom (és ez ráadásul saját enginet kapott c-ben assembly betétekkel) ez két éve volt.
Szóval ha most ezt ki kéne átlagolnom, akkor azt kéne mondanom, hogy egy játék elkészítése pár hét, max 2-3 hónap az éppen aktuális saját enginemben ÚGY, hogy az évek során közben írtam összesen vagy 8 enginet (de nem azért, mert hogy újra kellett volna írni okvetlenül, hanem azért, mert úgy döntöttem, hogy az előző valamiért nem felel meg) de magának az enginenek az elkészítése 2-3 hónap (és nem azzal foglalkoztam látástól vakulásig, bár volt olyan időszak is sajnos). Viszont egy enginevel végtelen mennyiségű játékot tudsz készíteni, szóval nyilván nem kell minden játék kedvéért írni egy újat (azóta már én sem írok engineket). Most pedig megint írok egy játékot (szintén előrerenderelt háttér előtt mászkálósat) de mivel csak heti fél napot tudok maximum foglalkozni vele, vagy még annyit se, így az maximum jövőre fog elkészülni, de kb azt mondanám, hogy annak a fejesztési ideje is nettó 1-2 hónap lesz max.
-
Pikari
veterán
Én megírtam a platform kódot windowsra, dosra, és linuxra. Bill+egér+joystick+hang kezeléssel együtt pár száz sor platformonként. Androidra nem írtam meg, mert az a platform annyira nem érdekel, komolyan nem is akartam foglalkozni vele, így ott SDL-re wrappereltem a saját függvényeimet. Időközben már nem foglalkozok egyáltalán androiddal. A mac apijáról nem tudok semmit, de azt gyanítom, hogy nem kell hozzá emberfeletti erőfeszítés, csak egy délutánt kell rászánnod.
Egyébként a waylandban van beépített X emulátor a kompatibilitás megtartása kedvéért, tehát nem szükséges átírnod pusztán azért, mert waylandot használó grafikus felületet használ a felhasználó. Mint ahogy az alsa kódot se kell átírnod azért, mert a felhasználó gépén pulseaudio van, hiszen a rendszer attólmég visszafele kompatibilis.
Culling alatt nem backface cullingra gondoltam, az eleve az opengl dolga már, hanem pl frustum cullingra (ez egy kifejezés a képernyőn nem látszó objektumok szűrésének egy módjára), vagy épp a mögötted lévő objektumok kiszűrésére. Ezt lehetőleg modell szinten érdemes gyakorolni, pl hogy a modellrenderelő függvény már az előtt visszatérjen, és eldobja ezeket a nem látszó modelleket, hogy bármiféle kirajzolással kapcsolatos műveletet elvégezne, vagy az openglt matatná. Ez a gyakorlatban szép kis sebességelőnyt képes hozni.
A fizikával kapcsolatban szerintem jól döntöttél, elég ritkán kell igazi fizika, a legtöbb esetben elég valami nagyon egyszerű collision rendszer, amit egyébként szintén lehet, és érdemes az enginebe integrálni, mert elég hamar megvan, aztán lehet újra és újra használgatni.
-
Pikari
veterán
Miért akarnád a glfw-t újraimplementálni, mit számít, hogy hány sor? Megnézel egy rendes tutorialt, ami natív kódon alapszik, és létrehozod az alapján az opengl-re alkalmas ablakodat, kb soha életedben többé nem kell hozzányúlnod. Igazság szerint ezeket a platformspecifikus részeket egy külön fájlba szokták írni az emberek, pl a windows specifikus kódokat egy fájlba, a linux specifikus részeket megint egy külön fájlba, és így tovább, és akkor lehetőleg ugyanaz a függvények neve, hogy később már lehetőleg ne kelljen ifdefkedni.
A Java bőven elég gyors (főleg Androidon) ahhoz, hogy több ezer polygont le tudjon renderelni másodpercenként
Uhhhh
Igazi kóddal meg most tartunk alsó hangon másodpercenként hardvertől függően kb ~1-10 milliárd textúrázott + árnyalt polygonnál Egyébként culling és távolságellenőrzés mindenhol kell, meg mindenféle piszkos trükkök sokasága, ha rendes sebességet akarsz, de normál esetben ezt magában az engineben implementálják le a fejlesztők, nem utólag kell vele zsonglőrködni. Szóval ez is tipikus példája annak, hogy dolgozol egyszer rendesen, vagy alacsony minőségű megoldásokra építesz valamit, amivel folyamatosan zsonglőrködni kell, hogy élvezhető végeredményt adjon.
Ha nekiállsz pityeregni, hogy márpedig te nem tanulsz meg ablakot létrehozni, mert neked nincs arra 3 perced, neked rögtönkellminden azonnal, meg varázslás és szeretet, és inkább addig a 3 percig is macskás videókat nézel a tiktokon, akkor lelked rajta. Én nem vitatkozom, azt csinálsz, amit akarsz, de én figyelmeztettelek, hogy minden egyes zsongőrmozdulattal csak magadnak önként dugdtad fel a a lónak a bizonyos szervét egyre mélyebbre.
-
Pikari
veterán
Minden processzornak kicsit más a floating point pontossága, még x86on generációk között is. Ezt egy library nem fogja önmagában megoldani neked, de játékoknál eddig nekem még nem okozott problémát. Illetve egyetlen egyszer, még szoftveres renderelés idejében - két polygon között lett egy üres csík amd k5 processzorokon, mert pont úgy kerekítődött az érték bizonyos nézőpontokból, és ezt végül egy -0.00001 taktikus beszúrása oldotta meg. De ez egy igencsak extrém eset volt, és nyilván kb 5 másodperc extra agymunkát igényelt.
Azért az opengl kontextussal ellátott ablak létrehozása nem egy olyan fajsúlyú feladat, amiért doktori fokozatokat osztogatnak. De meg kell vallanom, hogy régebben én is ilyeneket használtam crossplatform megoldásokhoz, C-hez kb 100 ilyen library volt, pl egy egyszerű glutban még joystickkezelés is volt, hogy azzal se kelljen fárasztania magát az embernek. Aztán ha az ember komolyan veszi a dolgot, akkor rájön, hogy ezek valójában pár soros problémák platformonként, sőt, natívan sokszor egyszerűbb is megírni, mint valami megkérdőjelezhető minőségű és licenszű libraryra rábízni. Valójában 1-2 napot spórolsz ezekkel az életedből, de valójában a hátadra ragasztasz vele egy szellemet, amit onnantól kezdve hordozhat a végtelenségig a játék, featureok hiányát, minőségromlást, esetleg strukturális változásokat is kikényszerítve.
Egyébként minden "rossz". Ugyanis nem úgy fogja megvalósítani a dolgokat egyik sem, ahogy te szeretnéd, és ettől lesz rossz. Nem fog kézreállni, és nem fogsz benne tudni hatékonyan dolgozni. A másik pedig a sebesség, ami miatt mindenképpen rossz lesz. Mert nincs kontrollod afölött, hogy egy bizonyos függvény mekkora overheadet fog okozni, milyen elvek mentén fogja megvalósítani a funkcionalitását. Lehet, hogy te mondjuk egy bizonyos dolgot meg akarsz hívni framenként 100 ezerszer, közben meg csak ezerszer tudod, különben bezuhan a sebesség, emiatt megintcsak át kell írni, át kell tervezni valamit, emiatt lesz rohadtul gáz használni ezeket (és nem az a dolog csimborasszója, amit írtál, hogy a kukából kiszedett törött kijelzős telefonon hány fpsen forgatja a 8 db sprájtot).
-
Pikari
veterán
Én úgy látom, hogy inkább az alacsonyabb szintű megoldás fele kellene elmozdulnod, ugyanis a leírásod alapján pont a túl magas szintű megközelítés okozta a többletmunkát, és a felesleges nyújtózgatást neked. Lehet, hogy úgy érzed, hogy egy alacsony szintű megoldás többletmunkát okozna még ehhez képest is. Ez kizárólag a projekt legelején igaz, amíg felhúzod az alap 3d enginet magadnak, utána viszont közvetlenül egy olyan kódbázis jön létre, aminek a fő célja a kívánt taszk megvalósítása, amiben így már rendkívül gyorsan és hatékonyan tudsz haladni. Például amit említesz, hogy az effekteket shaderekben írtad meg, egy 2d űrhajós repkedős játékhoz talán felesleges is, így azzal is rengeteg időt vesztettél, így én ezt inkább hátránynak tartom, hogy ilyen megoldásokra kellett fanyalodnod.
Egyébként hol tervezed publikálni a kész játékot? Felteszed valami gyűjtőoldalra, vagy csak csinálsz neki egy weboldalt, ahonnan le lehet tölteni majd?
-
#14
Klaus Duran
senior tag
urandom0
#5
Új hozzászólás Aktív témák
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- One otthoni szolgáltatások (TV, internet, telefon)
- Nem indul és mi a baja a gépemnek topik
- NBA és kosárlabda topic
- A fociról könnyedén, egy baráti társaságban
- Yettel topik
- Milyen házat vegyek?
- X140M1F4N károsultjai
- Milyen okostelefont vegyek?
- Nvidia GPU-k jövője - amit tudni vélünk
- További aktív témák...
- Eladó Samsung 24" Full HD LED monitor (S24C450B)
- 2013 Late 27 iMac - 1TB HDD i5 core4 24GB RAM 2GB GTX
- Bomba ár! Toshiba Portege R930 - i5-3GEN I 4GB I 320GB I DVDRW I 13,3" HD I HDMI I Cam I W10 I Gari!
- Bomba ár! Toshiba Portege X30-E - i5-8250U I 8GB I 256SSD I 14" FHD I Cam I W11 I Garancia!
- Bomba ár! Toshiba Satellite Pro A40-D - i5-7200U I 8GB I 256SSD I 14" HD I Cam I W11 I Garancia!
- ÁRCSÖKKENTÉS ASUS HD6870 videókártya
- ASUS ROG Zephyrus G14 - 14" WUXGA 144Hz - Ryzen 9 6900HS - 16GB - 1TB - Win11 - RX 6800S 8GB - HUN
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5060 8GB GAMER PC termékbeszámítással
- Nokia 8 Sirocco / 6/128GB / Kártyafüggetlen / 12Hó Garancia
- Eladó Samsung Galaxy S22 8/128GB / 12 hó jótállás
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest