| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
tangent
Založen: 28. 07. 2007
Příspěvky: 28
|
 Zaslal: 31. srpen 2007, 01:45:03 Předmět: Kompilace skriptu do vyssiho prog. jazyka misto do bytecode |
 |
|
Procital jsem si MD-ho stranky o Krkalovi a narazil jsem na poznamku o moznosti kompilovani skriptovaciho jazyka do vyssiho programovaciho jazyka ala C/C++ a nasledne kompilace klasickym kompilatorem do DLL knihovnicky. Nejdriv se mi zdalo ze to slysim prvne a ze tim tvorba vlastniho skriptovani musi ztracet na zajimavosti a flexibilnosti a navic predstava ze si napisu nejakou gramatiku pro nejaky YACC (Yet Another Compiler Compiler), ten mi vyplivne kod pro muj kompilator na miru, ktery vezme muj vlastni skriptovaci jazyk a udela z nej opet kod ala C++, ktery se bude zase znova prekladat v cizim kompilatoru silena az trochu uchylna [neco jako byla myslim ve Star Wars hlaska nejakeho robota pri pohledu na tovarnu: "Stroje vyrabeji stroje, jak perverzni..."  ].
Dneska ale nemuzu usnout , tak jsem o tom premyslel, co je tim vlastne mysleno. Zatim jsem kdysi zustal nekde ve fazi psani frontendu kompilatoru a trochu jsem se desil az navrhnu nejaky vlastni bytecode a virtual machine, jaka hruza bude potom v necem takovem hledat chyby (zpusobene chybami ve VM a kompilatoru, ne v napsanych skriptech), za pomoci nejakych na koleni napsanych debuggeru a podobne.
A proto se mi najednou zda myslenka tohoto "vyssiho kompilovani" najednou skoro genialni - moct takove chyby odhalovat s komfortem jaky nabizi dnesni debuggery typu toho ve Visual Studiu apod., jak bude vysledny kod cisty a prehledny oproti nejakemu kvazi-ASM, vyhnout se spinave praci pri navrhovani a ladeni bytecode a VM a pritom neprijit o ten pozitek ze mi neco bude bezet na vlastnim skriptovacim jazyce. Nehlede na zanedbatelne vysledne zpomaleni! Doslo mi ze o necem takovem byl asi TENTO clanek na GameDevu (ktery jsem uz pro ten napad zavrhnul;)) a ze o tom vlastne neslysim prvne. Jak jsem ho prelouskal, tak me to jenom navnadilo a nejspis se touto cestou vydam...
A proto konecne klasicka otazka, pro ty co tento system pouzili/pouzivaji: jsou s tim spokojeni, nebo narazili na nejake zadrhele ci omezeni? A ti co ne, co je odradilo? A kdo se na to teprve chysta, tak pro co se rozhodne?
Napadaji me argumenty proti v tom pripade, ze nekdo dela nejaky gamemaker pro co nejsirsi masu lidi, tak je tam potreba toho dodatecneho kompilovani a vlastneni onoho kompileru, to ale zatim neni muj pripad... Diky za vase postrehy a zkusenosti a doufam ze mi tu nezustane jenom tenhle vycerpavajici monolog z nespavosti ...
_________________
They made me do it |
|
| Návrat nahoru |
|
 |
Mnemonic
Založen: 28. 07. 2007
Příspěvky: 93
|
| Zaslal: 31. srpen 2007, 07:55:59 Předmět: |
|
|
Ono zalezi na tom, co od skriptovani ve tve hre ocekavas/pozadujes. Z hlediska programatora herniho engine vidim dve zasadni vyhody skriptu:
1) Moznost kdykoliv ulozit hru -> tj. serialozovat aktualni stav celeho VM, vsech skriptu, promennych, stacku. To bys s nativne spustenymi "skripty" delal tezko.
2) Moznost napsat si jednoduse vlastni multithreading. Nektere hry na mem enginu maji v jednu chvili spusteno klidne pres sto threadu. Nedovedu si moc predstavit delat neco takoveho pres nativni thready. S tim souvisi moznost thread kdykoliv pozastavit a pockat na nejakou udalost (a v te chvili treba ulozit stav, viz bod 1).
Ale samozrejme zalezi na pristupu ke skriptovani. Jsou urcite aplikace, kde by vyse popsane duvody nebyly podstatne, napr. pokud by "skripty" fungovaly podobne, jako DLL s herni logikou v Quake 2/Half-Life. |
|
| Návrat nahoru |
|
|
Quiark
Založen: 29. 07. 2007
Příspěvky: 816
Bydliště: Chlívek 401
|
| Zaslal: 31. srpen 2007, 10:15:49 Předmět: |
|
|
Já osobně bych to nepoužil. Asi i proto, že bych si ani nevytvářel vlastní jazyk, ale spíš použil Python, Lua a nejspíše .NET.
_________________
Mám strach |
|
| Návrat nahoru |
|
|
MD
Založen: 29. 07. 2007
Příspěvky: 437
Bydliště: Praha
|
| Zaslal: 31. srpen 2007, 10:29:57 Předmět: |
|
|
No ja na tohle udelal diplomovou praci. Takze to, co je ted na strankach Krkala ve fazi specifikace, je nyni uz hotove (teda ne vsechno!!) (a jako diplomka odevzdane). Na CH to publikuju, jen co dodelam statnice a budu mit trosku casu.
Myslenka mit netrivialni skriptovaci jazyk a kompilovat ho do C++ a to pak dale do dll je hodne dobra. Hlavni vyhoda je v moznosti kontrolovat a ladit vystup (beznym C++ debuggerem), take nemusite programovat interpret a nativne prelozene dll je samozrejme ryclejsi nez to interpretovani. Nevyhoda puvodne byla v jiste uzivatelske neprivetivosti, ale to jsem ted celkem vyresil. Dale by se delal hur vlastni debugger.
Co se tyce sily tak v C++ dosahnete imho te same jako pri interpretovani. Virtualni masina (runtime) se vyuziva v obou pripadech.
Moznost kdykoli ulozit hru je samozrejme podstatna. Krkal to umi, protoze pracuje s posilanim zprav a mezi takty je stack nulovy.
Multithreading by asi taky nejak sel (jde o to to vymyslet). Krkal misto toho pouziva zpravy. Je to takove deterministictejsi a bez deadlocku.
Jinak tangente, ja jsem ti posilal mail, ze se klidne muzes na cokoli ptat, celkem rad tyhle veci prodebatuju (nedorazil?) Jedna z vlastnosti noveho Krkala je i univerzalni pouzitelnost. Pokud by se ti hodil muj kompiler a runtime, je mozne je pouzit ve tve aplikaci. (Jen zatim nikde nemam publikovano, co to ted umi, sorry ... casem to napravim) No proste kdyby byl zajem at uz pro pouziti ci o vymenu zkusenosti, tak se klidne ozvi.
_________________
- play with objects - www.krkal.org - |
|
| Návrat nahoru |
|
|
MD
Založen: 29. 07. 2007
Příspěvky: 437
Bydliště: Praha
|
| Zaslal: 31. srpen 2007, 10:35:51 Předmět: |
|
|
| Quiark napsal: |
| Já osobně bych to nepoužil. Asi i proto, že bych si ani nevytvářel vlastní jazyk, ale spíš použil Python, Lua a nejspíše .NET. |
Presne tak, je treba zvazit alternativy. Krkal samozrejme umi neco, co tyhle jazyky neumi (jinak bych ho nedelal, nebo ze by jo? ) Jestli nekdo z vas bude vybirat, tak bych se rad zeptal na duvody proc se rozhodl pro to nebo ono. Diky
_________________
- play with objects - www.krkal.org - |
|
| Návrat nahoru |
|
|
MD
Založen: 29. 07. 2007
Příspěvky: 437
Bydliště: Praha
|
| Zaslal: 31. srpen 2007, 11:03:16 Předmět: Re: Kompilace skriptu do vyssiho prog. jazyka misto do bytec |
|
|
| tangent napsal: |
| a trochu jsem se desil az navrhnu nejaky vlastni bytecode a virtual machine, jaka hruza bude potom v necem takovem hledat chyby (zpusobene chybami ve VM a kompilatoru, ne v napsanych skriptech) |
 To neni jen predstava, ono to tak skutecne je. Puvodni Krkal byl delany jako projekt na MFF. Ja delal runtime a programoval hru Krkal. Kompilator a interpret tehdy delal Jirka. Puvodni jazyk byl jeste pekne prasackej (C pointery). Tak si asi umite predstavit jake to bylo, kdyz to najednou spadlo. Chybu jsem mohl mit ja ve hre nebo Jirka v kompilatoru nebo ja v runtimu. Proste peklo a ze treba tech chyb v kompilatoru tam bylo milion! Tehdy jsme mohli kompilovat jak do mezikodu tak do C++ a za ty skripty v C++ jsem byl opravdu vdecny.
V neve verzi je spusta opatreni, ktery snizuji chybovost.
_________________
- play with objects - www.krkal.org - |
|
| Návrat nahoru |
|
|
MD
Založen: 29. 07. 2007
Příspěvky: 437
Bydliště: Praha
|
| Zaslal: 31. srpen 2007, 11:21:32 Předmět: |
|
|
Jeste takova ilustrace, jak ty kompilovane skripty mohou vypadat. Taky nejsou uplne citelne.
Krkal C 3.0:
| kód: |
void CalculateMove() {
if (!moving && @Placeable.IsPlaced()) {
if (votes)
votes->SetCount(0);
$VoteForMove();
EvaluateResult();
}
} |
C++:
| kód: |
// class: $Moves$BE70_09A1_EF92_529B
// method: $Moves$BE70_09A1_EF92_529B.CalculateMove$BE70_09A1_EF92_529B
void _KSF_75_CalculateMove(CKerMain *KerMain) {
CKerContext &ctx(*KerMain->KerContext);
OPointer thisO = ctx.KCthis;
CScript *Script = (CScript*)KerMain->KS;
if (!thisO.get<int>(Script->_KSV_29_Moves_moving) && Script->_KSDM_31_IsPlaced(KerMain, thisO.Cast(Script->_KSC_32_Moves_Placeable))) {
if (thisO.get<ArrPtr<OPointer>>(Script->_KSV_34_Moves_votes))
thisO.get<ArrPtr<OPointer>>(Script->_KSV_34_Moves_votes)->SetCount(0);
KerMain->call(48, thisO, Script->_KSID_35_VoteForMove, 0);
KerMain->call(49, thisO, Script->_KSID_36_EvaluateResult, 0);
}
} |
_________________
- play with objects - www.krkal.org - |
|
| Návrat nahoru |
|
|
tangent
Založen: 28. 07. 2007
Příspěvky: 28
|
| Zaslal: 31. srpen 2007, 11:30:36 Předmět: |
|
|
Smolil jsem to nez se pripojil do diskuze MD, tak se omlouvam jestli neco opakuju a stejne to postnu
| Mnemonic napsal: |
1) Moznost kdykoliv ulozit hru -> tj. serialozovat aktualni stav celeho VM, vsech skriptu, promennych, stacku. To bys s nativne spustenymi "skripty" delal tezko.
2) Moznost napsat si jednoduse vlastni multithreading. Nektere hry na mem enginu maji v jednu chvili spusteno klidne pres sto threadu. Nedovedu si moc predstavit delat neco takoveho pres nativni thready. S tim souvisi moznost thread kdykoliv pozastavit a pockat na nejakou udalost (a v te chvili treba ulozit stav, viz bod 1). |
Mozna ze jsem do toho po te chvilce uplne neproniknul, stacil jsem si to tak dvakrat prolitnout (tim padem budu jedine rad kdyz me nekdo upozorni na neco co jsem nedomyslel ), ale IMHO ten clanek co jem odkazoval v prvnim prispevku dava docela podrobny navod jak tohle realizovat...
ad2) zakladem pro dosazeni takoveho pseudo-paralelniho chodu je vyuziti standard C funkci setjmp() a longjmp() pro ulozeni stavu programu a celeho stacku do nejakeho obycejneho bufferu a jeho nasledneho obnoveni. Tim padem muzes podle me skakat i v nativnim kodu mezi jednotlivymi multitaskovanymi ulohami (bloky) a jeste mozna mnohem cisteji nez pri nejaky vlastni home-made verzi na bytecodu
ad1) se dvojkou souvisi i jednicka, kdyz jsem v nejakem stavu schopny zasejvovat v pameti docasne vsechny moje bezici "procesy", tak nevidim problem ulozit je misto v pameti do souboru pro celkovy "sejv".
Autor toho clanku jeste uvadi ze je takhle schopny mit najednou ne stovky, ale treba i tisice takovych "vlaken", aniz by byl vysledny kod nejak vyrazne pomalejsi oproti kteremukoliv zbytku kodu programu (hry) a bez nejakych extra naroku na pamet.
Proto bych sem napsal jeste dalsi dva plusy tohoto postupu co me napadly...
1. Zadna ztrata na multiplatformnosti ci necem podobnem, autor to uspesne odzkousel i na platformach Linux, PS2.
2. Nadherne ciste propojeni mezi naskriptovanou DLL knihovnickou od designeru spolu s dodatecnymi DLL knihovami programatoru pro skripty/situace ktere potrebuji vyuzivat jadra hry.
MD: jasne, mail dosel. Omlouvam jestli to vypadalo ze jsem te zasklil, promyslel jsem konkretni napady/namety a tenhle thread mel byt vicemene odpovedi pro tebe, aby z tech myslenek neco zustalo i na foru pro ostatni
_________________
They made me do it |
|
| Návrat nahoru |
|
|
tangent
Založen: 28. 07. 2007
Příspěvky: 28
|
| Zaslal: 31. srpen 2007, 11:48:20 Předmět: |
|
|
| Mnemonic napsal: |
| Nedovedu si moc predstavit delat neco takoveho pres nativni thready. |
jeste uvedu, aby to nematlo ostatni co to tu budou treba cist a nechce se jim procitat ten clanek, ze reseni nad kterym se tu zatim tak tetelim blahem a je popsane v tom clanku nepouziva zadna klasicka systemova vlakna, ale vyuziva jenom odskoku na vhodnych mistech a casech vramci bloku jednoho vlakna.
_________________
They made me do it |
|
| Návrat nahoru |
|
|
MD
Založen: 29. 07. 2007
Příspěvky: 437
Bydliště: Praha
|
| Zaslal: 31. srpen 2007, 11:56:15 Předmět: |
|
|
jj, primocare propojeni mezi skriptem a enginem nebo jinou, uzivatelem dodanou dll, je taky plus.
Co se tyce threadu, tak toho jsem se bal a sel jsem jinou cestou. Pokud by kazdy zivy objekt mel svuj thread, tak to musi mit velkou rezii. Optimum je mit tolik threadu, kolik je procesoru (jader). Uznavam ze ne vsichni se tohohle pravidla drzi Ale mit treba tisic threadu je podle me uz zvrhlost.
Pri navrhu tech skriptu to chce v minimalni mire pouzivat prasarny (jako napriklad longjump) Je to asi analogie toho, proc nepouzivat goto. Longjumpum jsem se vyhnul, ale mam tam jine veci, hlevne silene pretypovavani, musi mi platit ze napriklad sizeof(muj_smartpointer) == 4, data v pameti nevyzaduji zarovnavani a podobne. Ono se tomu neda vyhnout, ale radil bych to minimalizovat nebo alespon o tom vedet a vedet, ze se to muze nekdy vymstit.
Toereticky by se dal skript i prevest i do C# nebo do Javy a nepouzivat zadny unsafekod. Jen by to bylo pomalejsi a pracnejsi.
Krkal vyuziva pro simulaci zijicich objektu zpravy. Asi takhle (Conway's Game of Life):
| kód: |
// Life is controlled by a special floor
class Mattoni {
string @Placeable.Image = "kamenyA.png";
int @Placeable.Z = 0;
void @MapPlaced() {
int x = @Placeable.X;
int y = @Placeable.Y;
int balonky = @Map.GetCount(x=x-1, y=y-1, dx=3, dy=3, type=$Balonek);
if (@Map.GetCount(x=x, y=y, type=$Balonek)) {
if (balonky <= 2 || balonky >= 5)
@Map.Get(x=x, y=y, type=$Balonek)[0]->@Destructor() end; // zniceni na konci taktu (opet zprava)
} else {
if (balonky == 3)
Vytvor() end; // zprava na konec taktu
}
@MapPlaced() timed 330; // zprava za 330 ms
}
void Vytvor() {
Balonek b = new Balonek();
@Map.PlaceAt(b, @Placeable.X, @Placeable.Y);
}
} |
_________________
- play with objects - www.krkal.org -
Naposledy upravil MD dne 31. srpen 2007, 12:00:45, celkově upraveno 1 krát |
|
| Návrat nahoru |
|
|
MD
Založen: 29. 07. 2007
Příspěvky: 437
Bydliště: Praha
|
| Zaslal: 31. srpen 2007, 11:58:19 Předmět: |
|
|
| tangent napsal: |
| ale vyuziva jenom odskoku na vhodnych mistech a casech vramci bloku jednoho vlakna. |
Takhle uz se mi to libi.
_________________
- play with objects - www.krkal.org - |
|
| Návrat nahoru |
|
|
tangent
Založen: 28. 07. 2007
Příspěvky: 28
|
| Zaslal: 31. srpen 2007, 14:01:20 Předmět: |
|
|
| MD napsal: |
| Pri navrhu tech skriptu to chce v minimalni mire pouzivat prasarny (jako napriklad longjump) Je to asi analogie toho, proc nepouzivat goto. Longjumpum jsem se vyhnul, ale mam tam jine veci |
jenom se radsi zeptam jestli jsme se vzajemne pochopili. Myslis vyhnout se konstrukcim ala goto v tom vytvarenem skriptovacim jazyce, nebo v tom nasledne vyplivnutem kodu treba v C++.
Kdyz jsem mluvil o tech longjmp-ech, tak to totiz byl jenom prostredek k zajisteni toho ze muzes skript bezici na jednom objektu po chvili zamrazit, ulozit si stack a podobne do bufferu (pomoci te funkce setjmp()), odskocit si na chvili vykonavat skript jineho objektu a pak se pomoci longjmp() vratit na ten puvodni objekt a vyvolat jeho stack atd., az se na nej zase dostane rada.
Myslel jsem teda ty jumpy k zajisteni toho "multithreadingu", ne ze bych je pouzival v tom samotnem skriptovacim jazyce pomoci nejakych "goto" prikazu...
Pochopili jsme se spravne?
_________________
They made me do it |
|
| Návrat nahoru |
|
|
JohnyDog
Založen: 17. 08. 2007
Příspěvky: 66
|
| Zaslal: 31. srpen 2007, 14:23:55 Předmět: |
|
|
Opravte me jestli se mylim, ale mel jsem za to ze dneska se od pouzivani green (vlastnich) threadu spis ustupuje ? Je pravda ze nektere OS maji s vetsim poctem nativnich threadu problemy co do vykonu, ale imho nevyhody green threadu prevazuji, vezmeme treba jenom dost problematickou moznost podpory multi-core/smp.
_________________
 |
|
| Návrat nahoru |
|
|
tangent
Založen: 28. 07. 2007
Příspěvky: 28
|
| Zaslal: 31. srpen 2007, 14:40:17 Předmět: |
|
|
Kdyby clovek delal nejkou vlastni Javu nebo .NET tak bych to mozna jako problem videl, ale u skriptovani ve hre, kde na skriptech bezi jenom nejaka jednoducha rozhodovaci a udalostni logika, tam ani moc ne. Kdyz si vezmes ze potom by ti nezbylo nic jineho nez jak psal MD pro kazdy aktivni objekt ve hre (a zejich muzou byt stovky) zakladat vlastni systemove vlankno, nebo neco takoveho... kdo by se s tim pak programoval
_________________
They made me do it |
|
| Návrat nahoru |
|
|
MD
Založen: 29. 07. 2007
Příspěvky: 437
Bydliště: Praha
|
| Zaslal: 31. srpen 2007, 14:46:09 Předmět: |
|
|
Ja chapu na co ty longjumpy jsou dobry. Pokud bys to chtel delat tim stylem, jak pisou v tom clanku (urcite si ho casem prectu ), tak bud muzes pouzivat setjump longjump (proc ne, je to prasarna, ale nutna..) a nebo pracovat s vlastnim stackem, to se hodi pro jazyky, ktery longjump nemaji. Ja u nekterych volani vlastni stack pouzivam, ale z jinych duvodu - potrebuju specialne predavat parametry. Napriklad u zprav - tam jsou parametry uchovavany ve zprave, a kdyz prijde cas, tak jsou prekonvertovany na muj vlastni stack a metoda s nimi pak pracuje. Jasne je to rezie navic, ale ja nechtel programovat zadny lowlevel veci. Tou analogii s goto jsem chtel naznacit jen to: pouzivej prasaren co nejmene, ale obcas jsou nutny. Myslim v C++, az budes navrhovat ten virtualni stroj.
_________________
- play with objects - www.krkal.org - |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
