chartest 2 #2

dev Comments Off
Jul 312011

Tovább dolgoztam a lentebb említett chartest progin – a screenshot most is ugyanaz lenne. :) Tovább gondoltam, hogyan működjön a kamera, mert az ok, hogy eddig is követte a karaktert, de a pályának nem voltak határai, hanem csak végtelenül ismétlődött. (Tudom, erről is kellett volna shot, de sry, szerintem ez az egész nem egy nagy szám. :))

Most már normálisan megáll a kamera a széleken, és a karakter kamerától függetlenül is fel tudja fedezni a pálya szélét – tehát nem mindig van a kamera közepén – persze mindezt úgy csinálom, hogy a 2D kamerát tetszőleges későbbi objektumra is rá lehet majd állítani.

Sajnos az a bizonyos hiba még mindig fennáll, egészen valószínű, hogy valami scheduling hiba lesz, – tehát a frame-enkénti update-et érintő – durván 1 másodpercenként megakad egy pillanatra, érezhetően. Nehéz valami ilyet debugolni, amikor a cpu használat úgy közel 0%, és azt is nehéz elképzelni, hogy egy 2d render megterhelje a vga-t, amikor mostani játékok… hát mennek. ;)

debug

dev Comments Off
Jul 242011

Tegnap egész nap újfent karakter kódolásokkal vacakoltam python 2-ben, mert mint említettem a pdf reader részben volt egy nem triviális hack, amiről azt hittem, hogy problémát okoz. Hát a hack az valóban hack volt, de nem okozott problémát. :)

Először is a pdf nem adatcserére való. Ez persze mindenki számára nyilvánvaló, aki kicsit is ért a dolgokhoz… mennyivel egyszerűbb lenne, ha xml-ből kéne xml-t csinálnom. :) Na de ezt küldik, ezzel kell kezdeni valamit, és amúgy is, azt hiszem ami xml-t küld az oep, annak is iso-8859-2 a kódolása! Nem utf-8 – abszurd lenne! – és még csak nem is windows-1250! :)

Szóval a tegnapi napom azzal ment el kb., hogy próbáltam megtalálni a hiba okát, – extra szóközök az adatfolyamban – és ezért átnéztem a python 2 és 3 dokumentációját, néztem egyszerű pdf 1.3 syntaxt, számtalan debug print-et csináltam a programból, mire rájöttem a következőkre:

  1. Windows alatt a c-python alapból 16bites unicode-ba kódol, linux alatt 32bites belső kódolás a default.
  2. A pdf syntax-ot olvasva kiderült, hogy kb. úgy működik, ahogy gondoltam, és a kód, ahogy átírtam a readert olyan, amilyennek lennie kell.
  3. És így az extra karakterek nem szóközök, hanem null karakterek az adott unicode környezet byte-számától függően.
  4. Szóval a hacket kitöröltem, minden létező string-et átírtam pythonban unicode stringre – bár ezt inkább csak a következetesség kedvéért – és próbáltam keresni egy karakter encodert, ami normálisan olvassa az adatot unicode-ból.
  5. De valójában a kódolás is mindegy, hiszen ha bármit is írok, az a python ‘belső magánügye’, hogy hány biten tárolja, szóval nekem nem kéne látnom annyi extra null karakter, amit látok.
  6. Tehát valahol mégis csak van egy alap ascii konverzió valamelyik függvénynél, amit használok, (ami megpróbálja 8-bites stringként kezelni a több bites unicode byte stream-et,) annak ellenére, hogy már minden stringem unicode string.
  7. Szóval próbáltam átírni 1-2 függvényt saját implementációra, és amikor olvastam a dokumentációt, akkor láttam, hogy valóban, az egyik module (StringIO) c implementációja nem támogatja a unicode-ot, csak a python implementáció.

Szóval kitöröltem minden debug szemetet meg a hack-et is… kitöröltem a kódból EGY karaktert, és minden szép és jó azóta. True story.

Aztán hogy a munkahelyi környezetben mi lesz, az egy más kérdés, de ha rajtam múlik persze mindenhol unicode/utf-8. :) Mindenesetre poén, hogy nem eldobja a unicode inputot az ezt nem támogató class… hanem itt-ott tök más helyeken látsz unicode meg ascii errort. A programozás szépségei – még jó, hogy szeretem csinálni. :)

sqlite

dev Comments Off
Jul 212011

Egy újabb lépéssel közelebb került már a proof-of-concept prototípus, merthogy az eddig kinyert adatokat némi szintaxis tanulás után egyszerű volt sqlite-ba fésülni. (Aki nem tudná, ez kb. egy 1 file-os sql adatbázis.) A további sql gondokat valószínűleg leginkább a unicode karakter kezelés fogja jelenteni, de ez már nem nagy probléma.

Egyfajta ellenőrzésként még meg próbálok befésülni egy másik, már félig elkészült programból adatokat, hogy összevessem mindet – és ha ez elkészül, akkor effektíve amióta ezeket a pdf-eket kapja a kórház, a bennük lévő adatok bármilyen időközre és összefüggésben lekérdezhetőek lesznek… csak az sql-en kívül is valami felületet kéne eszkábálni hozzájuk. :)

Amúgy a lekérdezés meglepően gyors, ha valami miatt szükségét érzem majd a webes felület és az adatbázis közötti kapcsolat korlátozásának, az inkább lesz a hálózati sávszélesség, semmint a lekérdezés sebessége miatti aggodalom.

nginx

dev Comments Off
Jul 182011

Tudtam, hogy el fog jönni az idő, amikor majd magamnak kell konfigurálni egy webservert – és ez el is jött. Szóval keresgéltem, és már elkezdtem ismerkedni a nginx-szel, ami elég kicsi és mégis elég sok mindent tud, hogy később se legyen probléma vele. Persze alapból benne van az ubis repo-ban, de ezenkívül még windows binary formában is letölthető, szóval bent is ki tudok próbálni dolgokat a mezei munka-desktop gépen. Próbáljunk csak cross-platfrom-ok maradni. :)

Úgyhogy az első benyomás pozitív – de persze én azok közé tartozom, akiknek nem kell minden létező beállításhoz valami checkbox egy skinelt GUI-n. :) Valami python+cgi-szerű dolgot kellene belőni alá értelemszerűen, de ehhez újabb pythonos dolgokat kell megtanulnom – majd úgyis leírom, ha egyszer kész lesz a konfig.

validálás

dev Comments Off
Jul 162011

A munkám miatt most többször elgondolkoztam azon, hogy mennyire éri meg köztes lépésben xml-lé alakítani a külső adatokat adatbázisba fésülésük előtt. Értelemszerűen ez egy plusz lépés, és mivel 1-2 konverter úgyis használ favágó módszereket, talán nem is lenne nagy különbség, ha közvetlenül a beolvasó részbe írnám bele a database commit-ot is. (Az egyik konverter pl. egy lib nem egyértelmű függvényét írja át explicit még kevésbé egyértelműre, és ez a duplán nem egyértelmű függvény szolgáltatja az effektív adatokat. :))

Ugyanakkor a köztes nyelv segít ezeket a nem hordozható kódrészeket elkülöníteni azáltal, hogy az adatfolyam többi részét függetleníti tőlük, és amit most még fontosabbnak érzek, az a külső eszközzel történő validálás lehetősége. Igaz, hogy programon belül is lehet ellenőrizni, hogy egy-egy adat pl. 5 számjegyből áll, vagy csak ilyen-olyan betűket tartalmaz-e (kódoknál), és habár leírva mindez elég triviálisan hangzik, az implementáció egyáltalán nem feltétlen lenne az. Ugyanis:

  1. ezeket a szabályokat a kezelhetőség érdekében előbb-utóbb úgyis külön részbe, modulba mozgatná az ember,
  2. a szabályok valószínű mindig függenének az adatot tartalmazó adattípus (class/type) tulajdonságaitól is, még dynamic typing-ot használó nyelvekben is,
  3. és a 2. problémát nem biztos, hogy 100%-osan át lehetne hidalni pl. duck-typinggal, már pedig a dokumentum vagy legyen valid vagy invalid, nem pedig ‘nem tudom’ vagy ‘null’, vagy hogy jobban érthető legyen: invalid, mert nem ismerem fel az egyik adat típusát (pedig amúgy lehet, hogy valid adatot tartalmazna).
  4. Végeredményben az adatszerkezethez saját, nyelven belüli api-t kéne kialakítani a hosszútávú használhatóság érdekében, és még ha a nyelv külön támogat is ilyen ellenőrző feltételeket, akkor is csak a nyelvi környezeten belül lenne mindez elérhető – adott esetben az adatbázisrésszel együtt csak.

Az xml persze megoldás lehet ezekre a problémákra, hiszen különálló, külön értelmezhető dokumentum/api, amihez már léteznek kiforrott validáló eszközök. Azt rémlem, hogy használata kiszűri a GIGO lehetőségét, valamint függetleníti az adatbázis mechanizmust a konverterektől, úgyhogy ha majd le akarom cserélni az adatbázist, elég csak egy xml beolvasót írni, ami lényegesen egyszerűbb, mint hard coded adatok közt nyúlkálni. Legalábbis ezt hiszem. :)

Ezenkívül egyéb haszna is lenne, de ezek most a legközvetlenebb gyakorlati dolgok, úgyhogy most csak erről írtam, és nem a még távolabb lévő utópiáról. :)

Elmúlt 1-2 napban azon dolgoztam, hogy az alábbi chartest programot – amiről a screenshot van – átírtam pygame használatról (SDL-binding) pyglet használatra (opengl-es lib), és sikerült. Sőt, normálisan működik a vsync is, szóval tearing sincs… de persze van más probléma helyette. :)

Elég jól használható a pyglet is, de kicsit erőlködősebb az api-ja, mint a pygame-nek. A sprite és image használat elsőre egyáltalán nem volt triviális, és összességében sem érződik teljesen kiforrottnak a 2D kezelés, ami nélkül viszont csak egy opengl ‘frontend’, ami meg ugyanúgy működik pygame+opengl-lel. Esetleg csak annyi különbséggel, hogy pygletben több nem deskriptív hibaüzenetet láttam eddig, mint pygame-ben összesen. :)

Ráadásul van valami zavaró akadozás a video renderben ubi és win alatt is – ami pygletnél opengl, tehát a vga csinálja – pont úgy, mint még az első ut-ban. És mivel minden ilyen dolog a színfalak mögött történik, csak remélhetem, hogy én csináltam valamit rosszul – nem pedig valami Don Quijote csatát vívok az apival. Pedig a hw használat szép dolog lenne.

EDIT: nem sikerült reprodukálni az említett hibát, szóval nagyon jó, hogy random néha nem megy rendesen… A screenshot meg teljesen ugyanaz lenne, mint a lenti. :)

xml writer

dev Comments Off
Jul 112011

Mint mondtam már jó pár embernek, új munkaköröm van, és szerencsére ez most több programozást jelent. :)

Elkezdtem adatkonvertereket írni, illetve még csak egyet, mert szándékomban áll a bejövő adatokat xml-be rakni, hogy később automatikusan validálni lehessen a konvertálások eredményeit. Persze, ahogy akartam, hogy működjön az xml output, ahhoz nem találtam megfelelő module-t…

Mivel a legtöbb adat rekord szerkezetű, ezért ahelyett, hogy valami giga-DOM-ot akarnék felépíteni, inkább egyfajta fordított SAX-parser kellett volna, ami képes soronként, egymás után, on-the-fly írni az xml-t.

Egyszóval írok magamnak egyet, csak ezzel is elmegy 1-2 nap. :)

tiled loader

dev Comments Off
Jul 112011

Valamelyik hétvégén fél nap alatt írtam egy tiled map loadert – van egy ilyen ingyenes map editor, amivel könnyen lehet old-school pályákat rajzolni – persze cask azt a részét, ami kell, meg igazából nem is egy igazi engine, csak egy sima renderer egy egyszerű próba animációval.

A különleges inkább az volt, hogy se ezt a pályát, se értelemszerűen a rajzokat nem én csináltam, hanem nyúltam valahonnan, és ez jó arra, hogy rákényszerítsen az alaposabb, nem favágó módszereket használatára. :)

project 0: #5

dev Comments Off
Apr 212011

nagyon fontos fejlemény, elsőként kell megemlíteni, hogy z0d elkezdett opengl-t tanulni, és a nyissunk meg egy opengl ablakot rész már egész jól megy neki..! :) mindenesetre ez azt jelenti, hogy már ketten dolgozunk az ügyön, amit már-már a maximum létszámnak gondoltam az elején is. :) jobb is, hogy lesz valami új world, egy új környezet, amit lehet programozni, mert kicsit eljutottam egy olyan szintre az engine-nel, aminél már nem sok valódi haszna volt újabb dolgokat rakni bele, így meg ha minden jól megy majd lesz egy egészen használható valami… valami. woot! :)

van jó pár ingyenes játék engine amúgy, ilyen-olyan fejlesztői környezetek, de nem érzem olyan meggyőzőnek azt, hogy most valaki más akármilyen api-ját tanuld meg ahelyett, hogy magad csinál a saját céljaidnak megfelelőt, mert habár ez utóbbi kétségtelenül több munka, de mégis jobban fogod tudni mi miért és hogyan van, és jobban megfelel majd a saját igényeidnek is. ezenkívül ha meg ennyire spórolni akar valaki az idejével, lehet hogy jobb, ha modot ír valamelyik megfelelő eszközkészlettel rendelkező játékhoz. de persze ez csak az én véleményem, és honnan tudhatnám amúgy is? :)

project 0: #4

dev Comments Off
Mar 122011

na tegnap összedobtam egy második, az engine-t – illetve hát engine-wannabe-t ^^ – használó progit. így bármilyen változtatás az engine alap dolgain egyből a 2 játékban/demoban is érezhető, és ezáltal remélhetőleg könnyebb lesz függetleníteni az engine-t a konkrét játékspecifikus dolgoktól. egyrészt minél inkább sikerül a high-level dolgokat elkülöníteni az engine-től, annál jobb illetve hatékonyabb lesz a munka vele (az 1 demo/napot most egész jónak érzem), másrészt a modularitása ellenére még mindig nem elég könnyen használható, mert az se jó, ha szükségtelenül elaprózódnak a dolgok, és úgy kell keresgélni mindent…

mindenesetre egy újabb lépés megvan, most talán majd összedobok egy egyszerű platformert vagy valami újabb hasonló szintű dolgot a további tesztelésre. kicsit várom, hogy valamiféle komolyabb akadályba ütközzek a state machine kóddal, vagy hogy jobban körvonalazódjon, hogy hogyan férne be a kódba egy message system, de ha meg mindent meg lehet majd oldani ezzel a kóddal – annál jobb! ^^

© 2011 zero or more Suffusion theme by Sayontan Sinha