Hirdetés
- Kormányok / autós szimulátorok topikja
- OLED monitor topic
- AMD Navi Radeon™ RX 9xxx sorozat
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Apple MacBook
- Vezeték nélküli fülhallgatók
- Autóhifi
- iPad topik
Új hozzászólás Aktív témák
-
#50
urandom0
senior tag
Kisgépkezelő
#49
válasz
Kisgépkezelő
#49
üzenetére
2 féle tile lesz összesen, abból 8-at el lehet tárolni egy bájton, a textúrájuk meg egy 8 bites pattern lesz, mint a régi szép(??) időkben. Az összes pálya elférne egy akkora helyfoglalású területen, mint ez a hozzászólásom
-
válasz
pusszycat
#45
üzenetére
Ez a Bomb Jack így ránézésre nincs egy hét meló Godotban, és abból is 5 nap a tileset megrajzolása. Ha hozott anyagból (értsd ingyenes assetekből) dolgozik az ember, akkor meg max 2 nap.
De írhatunk hozzá saját engine-t is, úgy röpke fél év, és lesz is egy játszható alfa verzió
-
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.
-
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.
Igen... és mindezt 3 platformra (merthogy a fejlesztés Linuxon+Windows-on zajlik, a végeredménynek pedig Androidon kell futnia). És megírod mellé (szintén mindhárom platformra) az ablakkezelő eseményeket, ami főleg Androidon izgalmas, ahol teljes kontextusvesztés van, ha a felhasználó átlép másik appra. Ez már messze nem a "megnézel egy tutorialt" szint, hanem ez már az a szint, hogy ismered a Win32-t, ismered az X11-et, ismered a Cocoa-t (ha Mac-re is ki akarod adni a játékot), tudsz fordítani mindegyikre, ismered a C-t, a GCC-t, a MINGW-t, az Objective-C-t, a Win32 API-t, a GTK-t... és a végeredmény TÖK UGYANAZ lesz, mint ha fognád a GLFW-t/LWJGL-t, és egyszerűen használnád. Legalábbis elméletben ugyanaz lesz, a gyakorlatban valószínűleg lassabb és bugosabb. Arról nem is beszélve, hogy ha jön egy újabb Android verzió, ahol mondjuk valami apróság változik az appok életciklusában (volt már rá példa, nem is egyszer), akkor mehetsz vissza low level szintre, hogy legalább az intent-ed megjelenjen. Vagy ha mondjuk X11 helyett valaki Wayland-en szeretné futtatni, azt is meg kell oldanod... rengeteg plusz munkát vesz magára az, aki erre adja a fejét, teljesen értelmetlenül.
A több ezer polygon nyilván csak egy random szám volt részemről, a lényeg az, hogy a Java is van elég gyors ahhoz, hogy egy bizonyos határon belül lehessen benne játékot fejleszteni. Azt nem állítom, hogy eléri a C sebességét, de nagyon sok mindenre bőven alkalmas így is.
Backface culling eleve ott az OpenGL-ben, távolság ellenőrzés pedig attól függően van az engine-ben, hogy mennyire low level. Nyilván, ha magad írod az engine-t, akkor ezt is magadnak kell megírnod, meg a teljes fizikát, ami megint rengeteg plusz idő tud lenni, attól függően, mennyire bonyolult a fizikád. Az én játékomban elég egyedi, de viszonylag egyszerű fizika van, így nem használtam külön libet hozzá. De ha komolyabb fizika kell, akkor behúzza az ember mondjuk a Box2D-t, és akkor van merev test fizika, ütközéskezelés, joints kezelés, bounce, gravitáció, stb.
-
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.
-
ezek valójában pár soros problémák platformonként
Csak a glfwCreateWindow 73 sor, és ez még nem csinál semmi mást, csak elkészíti az ablakot, és beállít néhány alapvető jellemzőt. Lehet, hogy ha kevésbé általános függvényt írnák rá, meg lenne mondjuk 40 sorból, de az még akkor is csak egy platform, ez a függvény viszont az alatta lévő platform ablak létrehozó rutinját hívja meg. És nekem ezzel gyakorlatilag semmi dolgom nincs, elindítom, fut Linuxon, Windows-on, Androidon. És maga a GLFW egy 23 éves cucc, az LWJGL 18 éves, mindkettő kiforrott, agyon vannak tesztelve, teljesen feleslegesnek látnom nulláról kezdeni. Ott lyukadnék ki, hogy lenne egy nagyon alapszintű rendererem, valószínűleg tele bugokkal, és örülnék, ha egyáltalán lefordul az összes célplatformon, nem hogy még magasszintű math library-t is legyen benne, meg OpenAL, megsatöbbi. Az ilyesmi demoscene versenyre való, nem élő fejlesztésre, ahol lehetőleg 100 éven belül kell produkálni egy játszható végeredményt.
A másik pedig a sebesség, ami miatt mindenképpen rossz lesz...
Ha a sebesség rossz lesz, az 99%-ban biztos, hogy azért lesz rossz, mert valamit rosszul csináltam, és nem az alattam lévő Java/LWJGL/GLFW miatt. A Java bőven elég gyors (főleg Androidon) ahhoz, hogy több ezer polygont le tudjon renderelni másodpercenként, a GLFW pedig 90%-ban C, kiforrott, tesztelt cucc, úgyhogy valószínűleg nem az lesz a szűk keresztmetszet sebesség tekintetében.
Egyébként az elején a játék pont azért volt lassú, mert a korai verzióban az inicializálásnál az összes itemet (pálya hosszától függően 100-150-200 item) kiraktam a pályára, és minden frame-ben többször is mozgattam őket (ahogy haladt az űrhajó előre). Átírtam ezt a részt, hogy mindig csak 1 képernyőnyi távolságra rakja ki az itemeket előre, a 12 FPS-ből hirtelen lett 24.
-
Pikari
veterán
Kifejezetten a cikkírónak reflektáltam, ő értette, de az ő dolga, ha hallgat rám, vagy sem. Egyébként az asm már túl alacsony szint játékfejlesztéshez (meg az asm betétek is), minőségi javulást nem okoz, csak feleslegesen rabolja az időt. Én régebben (még az athlon xp korszakban) előszeretettel használtam asm betéteket, amikor még a gcc nem volt annyira okos, mint mostanság, de letettem róla viszonyhag hamar, amikor kb minden compiler upgrade után lehetett üldözni a különféle anomáliákat, így inkább maradtak az alap algoritmikus megvalósítások. Illetve a régi dosos platform kódomban maradtak asm betétek a vbe és a sound blaster inicializálásához és vezérléséhez, máshová a fene se kívánná őket, milyen érdekes párhuzam egyébként az, hogy már dos alá se értek semmit ezek a libraryk, és ha egy vonal húzásánál komolyabb dolgokat akartál implementálni, akkor kénytelen voltál nulláról felhúzni az egészet.
-
De mit szeretnél ezzel mondani? Ha mondjuk én is doktríner akarnék lenni, akkor mondhatnám, hogy csak assemblyben szabad programot írni, de ennek nincs értelme...
És lehet szidni a magasabb szintű nyelveket, de a hosszú távon jól működő megoldások mögött általában egy végletekig csiszolt alacsonyabb szintű funkciós készlet van, ezért nem igaz, hogy a Java vagy a Python szükségszerűen lassú lenne.
-
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).
-
Szerintem saját engine vagy framework mindenképp többlet munkát igényel, a teljes fejlesztés alatt. Rengeteg olyan dolog van, amit egy komplett engine már eleve tartalmaz. Sok olyan dolog van, amit kezelni kell, de elsőre nem triviális, pl. mobiloknál az eltérő floating point pontosság. Ezt egy shaderben 2 sorban ki tudod kényszeríteni.
A cross-platform dolgokról nem is beszélve, a LibGDX képes fordítani PC-re (Windows/Linux/Mac), Androidra, Mac-re, sőt webre is, és az egyes platformokhoz tartozó háttérmunka nagy részét is lekezeli. Pl. automatikusan létrehozza neked a játék ablakát bármelyik oprendszeren, beállítja az OpenGL kontextust, stb.
Még egy egyszerű audio réteg is van benne, ami pont elég arra, hogy zenét vagy effekteket le tudj játszani, minimális effekteléssel (pitch, pan, stb.).
Van benne hálózatkezelés is (socket és http), ha ezt C alatt kellene megcsinálni, szívhatnék a BSD socketekkel, ami azért valljuk be, komplexebb feladatoknál elég problémás tud lenni, és rengeteg hibalehetőséget rejt magában.
Aztán van benne egy csomó segédosztály, pl. matekhoz egy rakat síkidom metszetét számoló függvény, mátrixműveletek, bézier-algoritmus, stb.Maga a LibGDX egyébként API szempontjából jó. Ha egy általános játék frameworkre lenne szükségem, én is valami ilyesmit csinálnék.
Ami borzasztóan el van rontva benne, az a widget rendszere, a Scene2d.ui. Emiatt akadtam ki igazából, lehetetlenül sz*r az egész. A LibGDX előtt Go-ban írtam egy kicsi memóriajátékot, ott az Ebiten UI-t használtam. Az sem egy leányálom, de a Scene2d.ui-hoz képest még az is sokkal használhatóbb.A shaderezést azért erőltettem, mert azt eleve GPU számolja, és ha egyszer a GPU-nak át lett adva minden adat, akkor onnantól a CPU gyakorlatilag mentesül a számítás alól arra az időre, amíg a GPU dolgozik. A gyakorlatban viszont látványos shadert írni baromi nehéz, másrészt van, amikor nem kapsz vele plusz sebességet, mert egy sima sprite renderelése is HW gyorsított. Úgyhogy egyes effekteket inkább megrajzoltam Inkscape-ben, és sima sprite-ként használom őket, így legalább látványosabbak, és nem is lassúak.
Play Store-ban fogom publikálni egyelőre, aztán később lehet, hogy lesz Steam-es változat is. iOS-ben nem gondolkodok, esetleg csak a nagyon távoli jövőben.
-
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?
-
Fú, nagyon nem értek egyet veled. A Java egy jó nyelv, és elég sok komoly projekt született benne (a C# talán jobb, de én nem használok MS cuccokat - bár ha Godotra váltok, úgyis a C#-ot fogom használni).
A C-t ismerem, írtam már benne pár programot, és az OpenGL-t is ismerem valamennyire, foglalkoztam már vele korábban.
A C-nek vannak nagyon jó alkalmazási területei, de eszembe se jutna nagyobb projektet (értsd bármit, ami három sorral több egy hello worldnél) írni C-ben, legfeljebb, ha nagyon low level szinten kellene dolgoznom. Mondjuk valami beágyazott cucc, kernel, driver, akármi. Vagy ha tényleg iszonyat gyors sebességre lenne szükségem.Ha a LibGDX-szel szívás van, akkor a C-vel hatszor annyi szívás lett volna, főleg, ha pure OpenGL-ben álltam volna neki a játéknak, mindenféle engine nélkül. Még mindig nem tartanék sehol sem, de harcolhatnék a buffer overflowokkal, az undefined behaviorökkel, a memória leakekkel, a dangling pointerekkel ... ilyenekbe még a profik is belefutnak.
Kinek hiányzik ez?És amúgy minek kéne ide a C-t erőltetni?
Nézz ide, ez a tesztkészülékem (Androidra készül a játék): [kép]Egy ezervéves, törött kijelzőjű ZTE Blade A31, kb. a piacon kapható leggyengébb készülék. Úgy vagyok vele, ha ezen szépen fut, akkor mindenen szépen fog futni, márpedig ezen elég szépen fut (igaz, jó pár órát öltem már optimalizálásba, mert az elején nagyon lassú volt rajta, de ez nem a Java hibája). Nagyjából nulla értelme lett volna ideerőltetnem a C-t, főleg, hogy a megjelenítést így is az OpenGL végzi, az effektek egy részét eleve shaderben írtam meg, tehát igazából csak a logika, ami a konkrét Java.
Sokkal rosszabb választás lett volna a C.
Sőt, pont ott hibáztam, hogy nem egy magasabb absztrakciós szinten lévő engine-t választottam, amiben nem kell minden apróságot nekem megírnom. -
Pikari
veterán
A javat tényleg hiba volt megtanulnod, főleg úgy, folyamatosan vesztett a népszerűségéből. 30 éve alatt nem is igazán írt benne senki semmi értelmeset, persze ez nem zavarta az ilyen "a nagy cég meg a bank ennélkül nem megy, mert ebben írt valaki egyszer egy hello worldot" típusú vásári mutatványosokat, akik aztán a technológiájukat megpróbálták mindenhova behányni, mint az ajtón kopogtató jehovisták, ugyanis visítva szarják össze magukat a gondolattól, hogy egyszer majd esetleg el kell menniük DOLGOZNI. Aztán ennek a bekoronázására jön a sok csodalibrary, az általad a sírjából előtúrt libgdx, ami azért létezik, hogy a nyelv silányságait elfedve olyan szintű sebességet és flexibilitást biztosítson, mint egy kukából kiszedett pentium2-esen a dosos djgpp.
De ezek helyett most a vásári mutatványozás legcsúcsát a python képviseli, ami immáron nem 10 hanem kb 100szoros sebesség- és memóriaveszteség mellett tud polygonokat kidobálni a képernyőre, tehát a javanál sokkal szarabb csapdába is zárhattad volna magad.
Mi tehát a megoldás? Igazából itt az alap gond nem az, hogy melyik csodanyelvet használtad, hanem maga az a tény, hogy csodanyelvet akartál használni. Nem hibáztatlak, időt akartál spórolni. Ezért próbáltál keresni valami tömegnyelvet, valami tömeglibraryval, ami teljesen logikus. Elvégre, miért akarnál már mások által ezerszer megírt triviális dolgokkal küzdeni, amikor talán csak egy csettintésre is megvan? Eddig teljesen logikusan gondolkodtál, és teljesen igazad van.
A baj ott kezdődik, hogy ezek a bohócnyelvek mind hulladékok, és alkalmatlanok arra, amire te használni akartad. Miért? Mert összemosódik a nyelv a platformmal, a libraryk a nyelvvel, másrészt pedig azért lássuk be, nem mindegy, hogy mondjuk egy polygon beanimálása 5 órajel, vagy 5ezer, bármennyire is verik magukat ezekre a nyelvekre. Lehetne ilyen nyelvet JÓL is megcsinálni, de nem csinálnak. Minden hasonló nyelvet úgy készítenek el, hogy az azt elkészítő a saját platformjára, vagy a saját delíriumos, hugyban fetrengő téveszméire optimizálja. Pl a microsoft a saját cuccait a microsoft platformspecifikus megoldásaival összedrótozza (pl visual basic) és a tényleges funkcionalitáshoz megkerülhetetlen a gazdaplatformmal való teljes integráció, mint ahogy az androidos java is igazából egy android platform köré épített python szerű valami.
Ott hibáztad tehát el a dolgot, hogy nem a c-t tanultad meg, meg mondjuk direktben az openglt, mert hogy te nem tanulod meg mittudomén a pointereket, a mallocot, nem tanulsz meg polygont kidobálni, nem vesződsz obj betöltő megírásával, megspórolod azt a pár hetet, ehelyett tulajdonképpen bemásztál a saját koporsódba, nem a saját céljaidnak megfelelő környezetet írtál meg, hanem egy kívánalmaidnak alkalmatlan és gyakorlatilag teljesen használhatatlan keretkörnyezetben varázsolni kezdtél, az eredmény pedig annyira fájdalmas és szörnyű lett, hogy a visszavonulásodat is bejelentetted.
Egyébként nagyon hasznos és jó, hogy beleestél ebbe a kelepcébe, ugyanis többet ezt a hibát nem fogod elkövetni. Megtanultad, hogy NEM szabad játékot fejleszteni. Legközelebb rendesen fogod csinálni. A dolgokat a torkuknál fogva fogod megragadni, minden szakmát nulláról kell megtanulni, villanyt szerelni se úgy mész, hogy nem érted, mi az a feszültség... Legközelebb olyan környezetet írsz magadnak, ami fölött teljes a kontrollod, és amiben a megírni kívánt játékot meg tudod írni úgy, ahogy akarod.
-
Valamilyen szinten biztos, hogy megmarad a Java, de egyre kevesebb új projektet indítanak benne, mint ahogy PHP-ben is. Én ezt látom, bár statisztikát nem tudok hozni (biztos van egyébként).
---
Én is viszek egy Java-s projektet a munkahelyemen, több, mint egy éve fejlesztgetem. Frissen végzett programozó kolléga első kérdése: "De miért nem webes technológiákban írtad? Az mindenhol fut."... -
#18
UnA
Korrektor
ergoGnomik
#17
válasz
ergoGnomik
#17
üzenetére
Csatlakoztam a témához, ennyi.
És nem volt offtopik.
-
#16
UnA
Korrektor
ergoGnomik
#11
válasz
ergoGnomik
#11
üzenetére
A kijelentés frontend és desktop vonalon még igaz lehet, de a backend esetén abszolút nem igaz.
Az, hogy van néhány csilivili fullstack project Javascriptben, az hosszú távon nem fogja kiszorítani a Java beágyazottságát.
-
#14
Klaus Duran
senior tag
urandom0
#5
-
#12
urandom0
senior tag
ergoGnomik
#11
válasz
ergoGnomik
#11
üzenetére
Szerintem is, de hát nem rajtam múlik. Ha rajtam múlna, a JavaScript megmaradt volna azon a szinten, hogy a weboldalon egy prompt ablakot feldob a felhasználónak, az beírja a nevét, az oldal meg üdvözli. Ennyi.
A Rust is jó egyébként, de egyelőre eléggé szűk területen használják. A Go-ra ugyanez igaz. A PHP csillaga is eléggé leáldozóban van, mondom ezt úgy, hogy évekig használtam backendre, és mai napig szeretem.
A Scheme, Haskell, és még ide lehetne sorolni a Lisp-et, Prologot, Fortrant, meg sok másik nyelvet is. Végső soron lehet ezekkel is foglalkozni, csak elég nehéz munkát találni velük. -
#11
ergoGnomik
tag
ergoGnomik
tag
Backend? JavaScript, TypeScript.
Frontend? JavaScript, TypeScript.
Desktop? JavaScript, TypeScript...
Ami szerintem a világ szégyene...
Meg esetleg Kotlint.
Miért nem Rustot? Vagy Go-t? Vagy PHP-t?
Vagy Scheme-et? Vagy Haskellt? 
-
Én is dolgoztam CNC-ben, majdnem 5 évet. Mi a 2D-s programokat írtuk kézzel, a 3D-t programmal generálták modell alapján.
Aztán a vége felé elkezdtek bevezetni a termelésben egy másik programot (fene se emlékszik már a nevére), ami a 2D-s programot is megírta modell alapján. De simán el tudom képzelni, hogy ezt is meg tudja csinálni már az AI.Most egyetemen dolgozik, itt is megy ezerrel az "éjájosítás". AI alapú Moodle kurzus készítés, AI alapú plágiumkereső, AI alapú e-learning rendszer... elképesztő, tényleg, milyen sok területre beette már magát.
-
Egy 2D-s sidescroller űrhajós játék, ahol az a cél, hogy idő alatt eljuss A-ból B-be, és közben elkerüld az aszteroidákat. Közben vannak felvehető itemek, lehet űrhajókat vásárolni (mindegyiknek más-más tulajdonságai vannak), az űrhajókból flottát építeni...
Nem túl bonyolult igazából, a nehézséget az okozza, hogy előtte nem foglalkoztam szinte semennyit sem játékfejlesztéssel, és hogy majdnem mindent magam csináltam, a fizikát (ezzel rengeteg szórakoztma), a hangokat, a grafikát (Inkscape-ben kezdtem el rajzolgatni az űrhajókat, de közben megtanultam a Blendert olyan szintre, hogy vállalható űrhajókat készítsek vele, és azóta van vagy 15 3D-s űrhajóm
), a hangokat. Jó, a végén már tényleg sokat segített az AI.Melyik másik játékhoz hasonlít? Nem tudok mit mondani, nem ismerem a játékokat, nem is szoktam játszani. Keresek, de nem is találok hasonló mechanikájú játékot.
-
#5
urandom0
senior tag
Klaus Duran
#4
válasz
Klaus Duran
#4
üzenetére
Milyen területre váltottál?
-
#4
Klaus Duran
senior tag
Ha belefáradtál azt megértem, majdnem egy idősek vagyunk. Mondjuk én régebben belefáradtam és visszaléptem egyet a szakmámban, mondhatni droidnak.
De sokkal nyugodtabb vagyok. Most én megyek mások idegeire, mint ahogy régen az enyémre mentek.
De ez nem követendő példa.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
A játékról lehet tudni valamit? Vagy melyik másik játékra hajaz?
Én turbo pascalban titkosítő programot írtam, ami egy szöveget titkosítva jelenít meg vagy fordítva. Tetszett benne, hogy lekonvertálta exe -be.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Microsoft Surface Pro // Surface // Surface laptop 10.gen i5, Ryzen // 12,5 13,5 15 //
- Bomba ár! Lenovo ThinkPad L480 - i5-8GEN I 8GB I 256GB SSD I 14" FHD I HDMI I Cam I W11 I Gari!
- Konzol felvásárlás!! Xbox Series S, Xbox Serries X
- Alkalmi ár! Gamer Notebook! Acer Nitro 15 - I7 11800H / RTX 3060 / 16GB DDR4 / 512 SSD + 1TB HDD
- GYÖNYÖRŰ iPhone 13 128GB Starlight- 1 ÉV GARANCIA, Kártyafüggetlen,MS3435
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest