skriptošana

[bubu]

Kompilēšana tas kāds bubulis ?

Ne jau bubulis, bet gan laiks un resursi.

Tā daļa, kas ir performance cricial (renderēšana, vai tml) - to skirpto neredzu jēgu, uzraksti core kodu un strādā. Vai taisi data driven paiplainu.
A pārējā daļa manis pēc var griezties "lēnajos" skriptos.
Tā ka tas teiciens, kas parsti joprojām ir spēkā - katrs rīks paredzēts savam darbam, nav universāla rīka. Arī C++ nav universāls :)

Ir spēļuks, kas jau griežas.
Spēļuku apstādina ar debugeri, pieraksta klāt jaunas metodes, memberus un kodu.
Palaiž tooli un tas pārkompilē tikai vajadzīgos failus, kaut ko pārlinko.
Spēļuks turpina griezties no tās pašas vietas kur apstādināts, tik ar jauno funkcionalitāti.

Izklausās pēc DLL failiem :)

Un kad skriptošana nav atļauta? Pēdējais, kas aizliedza bija Apple uz iOS, bet vēlāk viņi to atcēla, un nu jau labu laiku kā drīkst skriptot. Nevienu citu platformu nezinu, kur aizliegts skriptot.

[snake5]

Skripti ir lēni

http://en.wikipedia.org/wiki/Just-in-time_compilation

Nezinu vai tas rīks izmanto LTCG MSVC gadījumā, jo rīks tiek veidots visām platformām.

Bez tā kompilēšanas ātruma / programmas darbības ātruma tradeoffs kļūst daudz ļaunāks. Jāpietaisa viss pilns ar inline funkcijām, lai iegūtu ātrumu, bet tad pat debug build'u kompilēšana kļūst daaaaudz lēnāka. Nu tiem, kas lieto boost vai iekļauj daudz STL headerus, neciešami ātrumi ir jebkurā gadījumā...

[DeRatizator]

Kompilēšana tas kāds bubulis ?

Ne jau bubulis, bet gan laiks un resursi.

Tā daļa, kas ir performance cricial (renderēšana, vai tml) - to skirpto neredzu jēgu, uzraksti core kodu un strādā. Vai taisi data driven paiplainu.
A pārējā daļa manis pēc var griezties "lēnajos" skriptos.
Tā ka tas teiciens, kas parsti joprojām ir spēkā - katrs rīks paredzēts savam darbam, nav universāla rīka. Arī C++ nav universāls

Ir spēļuks, kas jau griežas.
Spēļuku apstādina ar debugeri, pieraksta klāt jaunas metodes, memberus un kodu.
Palaiž tooli un tas pārkompilē tikai vajadzīgos failus, kaut ko pārlinko.
Spēļuks turpina griezties no tās pašas vietas kur apstādināts, tik ar jauno funkcionalitāti.

Izklausās pēc DLL failiem

Un kad skriptošana nav atļauta? Pēdējais, kas aizliedza bija Apple uz iOS, bet vēlāk viņi to atcēla, un nu jau labu laiku kā drīkst skriptot. Nevienu citu platformu nezinu, kur aizliegts skriptot.

Es domāju, ka tur noteikti bija DLL faili, jo demo griezās uz Win
Nav obligāti performance-critical, bet jebko, priekš ātras izstrades ar C++, būtībā WYSIWYG. Mērķis nebija aizstāt skriptus, tas bija tik viens pielietošanas piemērs.

Tēma bij par skriptiem, tāpēc tos arī piesaucu

[bubu]

Ok, tad tie izklausās vairāk pēc pluginiem, kurus dinamiski ielādē/izlādē, kas izklausās prātīgi un pielietojami.

[bubu]

Skripti ir lēni

http://en.wikipedia.org/wiki/Just-in-time_compilation

JIT's daudzām (un tieši populārākajām) spēļu platformām ir aizliegts user-land kodā.

Nezinu vai tas rīks izmanto LTCG MSVC gadījumā, jo rīks tiek veidots visām platformām.

Bez tā kompilēšanas ātruma / programmas darbības ātruma tradeoffs kļūst daudz ļaunāks.

Nu gan pilnīgas muļķības. LTCG bieži tieši kodu lēnāku pataisa (gan MSVC, gan GCC kompilētājiem). Darbā vairākkārt uz šito esam uzrāvušies reālam kodam, ko šipojam customeriem. Kompilators visu tik inlaino, inlaino, tā rezultātā kods NEŽĒLĪGI ilgi kompilējas, un arī runtaimā performance sliktāka dēļ code bloat'a, kas piesārņo kešatmiņu. Un mēs tajā neizmantojam nekādu STL vai BOOST.
Daudz,daudz,daudz prātīgāk ir lietot PGO - profile guided optimizations, ar to vienmēr iegūs labāku performanci, nekā LTCG.

Nu tiem, kas lieto boost vai iekļauj daudz STL headerus, neciešami ātrumi ir jebkurā gadījumā... :D

Labrīt, visi headeri inlainojās (pēc kompilatora patikas protams) arī bez nekāda LTCG.

[snake5]

LTCG bieži tieši kodu lēnāku pataisa

Hmm, ok, būs jāpapēta dziļāk.

Labrīt, visi headeri inlainojās (pēc kompilatora patikas protams) arī bez nekāda LTCG.

Un es kaut ko pretēju apgalvoju?

[bubu]

Re kur ir kods: http://runtimecompiledcplusplus.blogspot.com/
Vēl neesmu papētijis sourci.

[bubu]

Apskatīju sourci - nekāda maģija tur nav. Parasti dll faili, kuri kompilējas ar studijas kompilētāju (vai tikpat labi var lietot gcc) no sources (cpp). cpp faili runtaimā tiek monitorēti uz izmaiņām. Līdzko kāda izmaiņa, tā spēles dzinējam tiek paziņots, ka modulis mainījies. Spēles kods izlādē veco, izsauc pārkompilēšanu, ielādē jauno dll un instancē jaunos objektos. Apmēram tas pats, ko nodrošina spēļu dzinēji ar tekstūrām - ja ārējais fails izmainījies, tad to var runtaimā referšot, nevajag restartēt tūli/spēlei.

Lielākais čakars kā šito brīnumu izmantot droši vien ir tas kods, kurš izlādē vecos objektus, un instancē jaunos - tas jāraksta manuāli, jo atkarīgs no nokrētās funkcionalitātes, ko tu gribi izmantot. Viss pārējais ir triviāli (cl.exe izsaukšana, dll ielāde/izlāde) - to nodrošina šī RuntimeCPlusPlus bibliotēka.

Tipiska pluginu sistēma. "Memberus pielikt" - ko minēja deratizators - to var tikai plugina iekšienē kā privātu stuffu, viss kā parasti.