Standalf | 23.07.07 v 15:40

Ahoj, pouzivam Dev-Cpp a k ty smule nemam moznost se ucit z ceskych kurzu co jsem nasel. Mozna by nebylo od veci uvezt, ze zdrojaky napsany tady ve visual studio (nebo v cem) nejdou kompilovat v dev-cpp, pise to milion chyb. Chapu ze to pise chyby, ale nechapu proc, zda se mi to tak neflexibilni.

Moribundus | 02.07.07 v 23:43

Nechci tim rozhodne rici, ze mas prepsat vsechny sve programy okamzite do Pythonu, ja sam jsem dal prednost Lue (a konfigurakum s Lua syntaxi, aby je mohla Lua snadno parsovat). Pouze se snazim rict, ze Python neni zbytecnym jazykem.

Moribundus | 02.07.07 v 23:37

Tu mas odkaz na rozhovor, ve kterem clovek od Firaxis vysvetluje, proc zvolili prave Python a ne Luu.
http://games.slashdot.org/games/05/10/27/059220.shtml?tid=206&tid=11
viz otazka 8.

Ona flexibilita Pythonu (a tedy vysoka modovatelnost hry) vyrazne prodluzuji jeji zivotnost a tedy prodejnost.

EVE Online pouziva prozmenu Stackless Python a jeji tvurci si jej nemohou vynachvalit, Viz www.eve-online.com/faq/faq_07.asp

Tak prijemny zbytek noci :)

Moribundus | 02.07.07 v 23:32

K tem benchmarkum, prosim posuzuj relevantni data. Prvni benchmark je pet let stary (2002). Co se druheho benchmarku tyce, nemyslim si, ze test trech zakladnich operaci na plovouci carce ma nejakou objektivni vypovedni hodnotu o vykonu jazyka nasazeneho v realnych podminkach (nehlede na to, ze autor sam priznava, ze nikdy predtim s pythonem nic nedelal). Pokud se podivas na odkaz na benchmark, ktery jsem daval ja, zjistis, ze je jednak je aktualni (02 Jul 2007) a jednak jsou testy provadeny na mnohem sirsim spektru "aplikaci" ktere resi slozitejsi a ruznorodejsi problemy, nez jen zakladni aritmeticke operace. Vysledky? Python se vetsinu casu drzi docela slusne - drtivou vetsinu casu bezi rychleji jak PHP, Perl i Ruby (chudacek :D).

Lide z Cryteku delaji profesionalni praci, o tom zadna. Spickove optimalizovane maji vsechny potencialni bottlenecky sveho enginu a zbytek hry klidne muze bezet napsany v Lue, nebo Pythonu (lide z Cryteku dali prednost Lue). Dokud neni skriptovaci jazyk pouzit v kritickem bode programu, nejedna se o zadnou tragedii.

K tvym ultimatnim rychlostem take jeden citat (viz wikipedie).

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Code Complete, Page 594).

K te Qt pod widlema. Tedka je taky free jako pod Linuxem, ale porad se jedna o celou verzi GPL licence, ktera nuti programatora pouzit stejnou licenci i pro svuj program, coz vyhovuje filosofii 99% aplikaci pod linuxem, ale pro komercni vyvoj se nehodi. Pristup panu z Trolltechu je plne pochopitelny, jedna se o profesionalni tym, ktery vyviji komercni produkt jako kazdy jiny tym/firma. To, ze je jejich produkt k dispozici free, je jedine dobre (snad spatnym krokem byla jejich stara QPL licence, ktera nebyla opravdu free pod widlemi, takze v dusledku je vetsina Qt aplikaci pouze pod Linuxem). A ja osobne proti Qt knihovne nic nemam (jeste jsem ji nezkousel), ale pokud bych mel vyvijet komplexni multiplatformovou "okenni" aplikaci, pravdepodobne bych po teto knihovne sahl, jelikoz nabizi radu funkci nad spravu oken, ktere mohou programatorovi usnadnit zivot (podobne jako je .NET obsahly). Ale toto uz je opravdu otazka osobnich preferenci, nekdo by mohl prosazovat MONO, nebo jine knihovny (ci jejich kombinace).

Jo a u .NETu jsem uvozovky prehlidl :) Je to skoda, Microsoft se snazi o dve veci zaroven - vytlacit Javu z trhu a posilit pozici Windows. Nicmene tyto dve veci se jaksi vylucuji, i kdyz C# by mohlo mit docela velkou sanci proti Jave.
S temi materialy nezavislym vyvojarum mohl myslet registrovani standardu pro CLI. Jenomze .NET neni standardizovan cely (alespon, co jsem cetl/slysel), takze Microsoft si tu drzi jistou exkluzivitu :-/

A jeste dodatek k POSIXu. Mas pravdu, ze je v zakladu stejny, ale ne vzdycky si vystacis s tim zakladem :-/

Navic v nekterych pripadech neni ani kompatibilita mozna a programator nemuze ocekavat, ze dana funkce se bude chovat na obou platformach stejne (krasnym prikladem je filesystem, nebo multithreading, ktery maji windows uplne svuj vlastni).

Ale priznam se bez muceni, ze jsem v tomto smeru trochu zaujaty. Vubec se mi nelibi, ze muj soucasny projekt vypada jako derave kalhoty plne #ifdef _MSC_VER zaplat. :-(

Esaras | 02.07.07 v 19:28

Jen bych dodal ze POSIX je sice na widlich jinak ponekud jinak implementovan a radu veci ignoruje ale v zakladu je stejny(jinak by to nebyl standard ze :D).

K tomu .NETu, jak sis mohl vsimnou, tak to pod zastitou MS bylo v uvozovkach, jak uz si psal oni tento krok provedli proto aby se vlk nazral a koza zustala cela. Nepodileli se na tom vyvojarske firmy MS primo, ale poskytli materialy nezavislym vyvojarum (nebo tak nejak mi to ten borec z MS rikal). Mimojine .NET je pod linuxem celkem pomaly, takze to uz radeji javu.

Verim ti ze se scriptovaci jazyky pouzivaji denne, ale jestli sis vsiml, tak z tech testu co jsem tu daval linky je vsude python nejpomalejsi, takze kdyz uz bych mel pouzit nejaky scriptovaci jazyk, tak bych si zvolil asi neco rychlejsiho, protoze polozme si ruku na srdce ty rozdily tam byli velke. Sice rikas ze se tam neprovadeji miliony cyklu, coz je bezesporu pravda, ale to mas tam par milisekund, nekde dalsich par a muze se to docela solidne nasbirat. Nesnazim se ti rict ze jsou k nicemu, akorat nevidim konkretni problem kde bych pythonu upotrebil. Jsou mnohem rychlejsi scriptovaci jazyky (i kdyz treba maji nejake nedostatkdy, ktere se ve velke vetsine pripadu daji nejak obejit, vyladit apod.). Treba na poli tvorby webovych aplikaci bychom si to jiste bez scriptovacich jazyku jiz asi nedovedli predstavit.

Ja zastavam aplikace s ultimatni rychlosti a tomu se taky prizpusobuju (treba borci z cryteku si najali specielni tym, ktery se nepodili na vyvoji enginu ale provadi optimalizace kodu a myslim ze tato snaha prinesla kyzeny vysledek, to jen takova poznamka). Jak sem jiz psal dosud sem nemel potrebu sahnout k pythonu (pro me je python proste desne pomaly a tak pravdepodobnost ze po nem nekdy sahnu je skoro nulova) nebo jinemu podobnemu jazyku a to uz se resil siroke spektrum problemu.

Jak sem psal QT taky nemusim, zvlaste nechapu jejich politiku. Pod linuxem je QT uplne normalne free a pod widlema ji licencujou, to mi trochu nejde do hlavy, ale neznam blize tu problematiku, takze nevim co je tam v pozadi.

A k tomu typkovi co vse drti v PHP, jak rikam proti gustu zadny disputat. Pokud tvori v oblasti kde se to da takto praktikovat, tak proc ne.

Taky se mej hezky, nad tim co si psal se urcite zamyslim (pokusim se bez predsudku :-))

Zakoncil bych zajimavym citatem :-)

"When I invented the term 'object-oriented' I didnot have C++ in mind."

Alan Kay

;-)

Moribundus | 02.07.07 v 00:27

Jo a jeste jsem si vzpomel. Qt je sice i na win platforme, ale je tam problem s licenci, ktera je "plna" GPL, takze nelze Qt pouzit bezplatne pro vyvoj komercnich aplikaci. Lepsi alternativa je knihovna Gtk+, ktera sice neposkytuje tolik funkci, co Qt, ale je pod LGPL. Tk ma tusim podobnou non-restriktivni licenci. Jinak makra typu _T jsou opet microsoft specific a vyzaduji vice pece pri prevadeni mezi platformami :P

Ja myslel, ze tato debata neni o tom, co je komu blizsi, ale o tom, ze skriptovaci jazyky nejsou zbytecne.

Mj. znam cloveka, ktery vse pise v php, pokud ma moznost volby. Vcetne napr. bankovnich aplikaci (nejen webovy soft). Zni to desive, ale ten clovek je profik a verim, ze opravdu vi, co dela.

Jinak happy coding :D

Moribundus | 01.07.07 v 17:28

V nekterych vecech ams pravdu, to bezpochyby, jen mi prijde, ze obcas jsou tve nazory trosku zkreslene. Napriklad POSIX standard je hodne mizerne implementovany Microsoftem (vim o cem mluvim), funkce tam sice jsou obdobne, ale kdyz se podivas poradne, tak zjistis, ze microsofti implementace napr. ignoruje polovinu hodnot apod. Novejsi POSIX funkce nezna visualko vubec.

Pokud by ses podival na licenci Cry enginu, tak je licencovan (ostatne jako vsechny ostatni pro enginy) vcetne zdrojovych kodu. Skriptovaci jazyky jsou zde kvuli tomu, aby se tech nekolik set tisic radku kodu nemuselo pokazde kompilovat znova, ne aby zakaznik nemel pristup ke zdrojovemu kodu. Konfiguracni soubory jsou samozrejme rychlejsi variantou, ale postradaji flexibilitu skriptovacich jazyku. Jakmile budes chtit udelat neco, s cim programator predem nepocital, musis ho zavolat a on musi do programu novou ficuru manualne pridelat (tj. musi rozsirit konfiguraky) a to nikdo nechce.

Jinak DevC++ jsem nezkousel, ale pouzivam MingW a to ma opravdu tech 100MB a nebouziva lib format pro knihovny, ale linuxovy .a a .o, takze nevim, jak by se to snaselo s ostatnimi win knihovnami. A jak jsem psal, nemam notebook, ktery by tyto problemy samozrejme resil :) Pozadavky klienta byly velmi specificke a myslim si, ze standardni knihovny, ktere se vejdou do 10MB by mi na to nestacili.

Mj. Mono neni pod zastitou MS, spise si myslim, ze to je duvod, proc doslo ke "spolupraci" MS a Novellu, ktera stala novel hooodne velkou sumu penez jako vyrovnani za udajne porusovani autorskych prav Microsoftu (nebo patentu, nebo co to microsoft tvrdil). Vsak jsme o teto afere vsichni slyseli. Kdyby MS podporoval aktivne multiplatformovost .NETu, mel bych ho mozna radeji :) Jinak si myslim, ze .NET muze byt prijemnou alternativou pro vyvoj pod MS platformou (WinAPI jiz opravdu zastaravalo). Hry bych ale v C# nedelal :)

http://shootout.alioth.debian.org/

Tu je link na aktualni benchmarky ruznych jazyku, muzes i srovnat zdrojove kody. Python si vede ze skriptovacich jazyku docela dobre, ale je tu krasne videt, ze ne kazdemu jazyku sedne vse. Myslim, ze v jednom pripade je python rychlejsi nez C++ :P ale take je to jeden ze 20ti.
Nesmi se ale zapomenout, ze analyza behu programu nespociva ve srovnani par benchmarku. Skutecny vykon muze byt uplne jiny (a hlavne se cyklus neopakuje milionkrat ale treba jen tisickrat a vysledny cas je tedy v mikro/milisekundach).

Skriptovaci jazyky se pouzivaji na denni bazi, pokud mi neveris, precti si o tom nejake clanky, reference spolecnosti, rozhovory s vyvojari, knihy atd. Mozna se bojis, ze by pouziti skriptovaciho jazyka zpusobilo bottleneck ve tvem programu, ale je daleko vetsi sance, ze bottleneck vznikne prave v casti programu psane v C++ (nebo primo v hardwaru, coz je castym pripadem u her). Samozrejme, pokud nepotrebujes skriptovaci jazyky, nemusis je pouzivat. Ale chci videt, jak budou lide delat pluginy pro velkou multiplatformovou aplikaci. Napisi je v C++ a pak zkompiluji pro vsechny platformy?

Dekuji za diskuzi a zkus se nad nekterymi mymi argumenty zamyslet. Myslim si, ze v dobe dvoujadrovych procesoru a pameti, ktere se pocitaji na gigabajty se neni treba obavat zpomaleni, ktere nastane v interpretu skriptovaciho jazyka, nez je rizeni predano zpet C++ kodu. Pokud by toto bylo porad problemem, nepouzivaly by se ani jazyky typu java C#, atd. byt jsou optimalizovane JIT kompilatorem (ktery je mj. k dispozici i pro Luu a Python). Tot vse, preji prijemny zbytek odpoledne.

Esaras | 01.07.07 v 11:34

http://tenser.typepad.com/tenser_said_the_tensor/2006/08/python_vs_perl_.html - tady je dokonce pri jedne operaci python az 149x pomalejsi (slow down je vuci C++).

Takze jestlize pouzit nejaky scriptovaci jazyk pro vyvoj hry, pak to urcite nebude python. Nehadam se s tebou o jinych jazycich, jen rikam ze nevidim smysl pythonu. Jinak Java i C# celkem solidne C++ v jednom testu co sem nekdy drive videl celkem solidne pokorila, myslim ze se jednalo o nejakou komunikaci na siti, nejaka operace s IS nebo tak neco, nevim presne, to bych kecal. Kazdopadne to byl jeden test z cca 20ti-30ti.

Zaverem bych rekl asi tolik, ja napisu nejaky argument, ty se mi ho snazis zpochybnit a samozrejme obracene. Je samozrejme na kazdem co je mu k srdci blizsi. Ja jsem si zvolil jako nastroj C++ a nemam jediny duvod ho opoustet a jeste me nikdy (zatim, musim zaklepat :D) nezradilo. Jako alternativni jazyk s uspechem zatim pouzivam C#. Takze si myslim ze tato diskuze by mohla byt nekonecna a tak bych ji asi ukoncil, akorat tady delame OT, hadat se muzeme i jinde :D. Kazdopadne diky za nazory a diskuzi, byla velmi zajimava :D, ale jak rikam, to je jako u politiku, jeden tvrdi to a ten druhy to rika presne obracene a nikdy se nedomluvi.

Esaras | 01.07.07 v 11:33

Takze co jsem nasel:
http://furryland.org/~mikec/bench/

Dalsi link bude vzhedem k antispamove ochrane FG v dalsim prispevku

Esaras | 01.07.07 v 11:33

S unicodem se v C++ dela uplne bez problemu, daji se vyuzivaji se ruzna makra (resp. se pouzivaji makra typu TEXT, _T... viz. napr. dokumentace MSDN).
SDL zase tak zly neni, i kdyz diky multiplatformnosti ztraci trochu obratnost, ale nic co by se nedalo poresit. Pak je tu jeste QT (ktere teda moc nemusim) a v tomto pripade je kod plne prenositelny. Jinak jestli si podrobneji zkoumal API, tak jsi urcite zjistil, ze kazda API funkce pro widle ma svou presnou alternativu v Linu a take tu mame standard POSIX. Takze portace projektu pro dalsi platformu je otazka nahrazeni WinAPI funkcema za API fce jineho OS (pripadne i vstupni datove struktury). A jak sem psal pokud programer nepise jako prase, tak to ma upravene v radu nekolika desitek minut (v zavislosti na velikosti projektu a schopnosti oddelit API casti od zbytku kde je ho netreba).

Haskell si vystihl dobre, "je ponekud neobratny", nadruhou stranu kdyby ses prvne naucil funkcionalne programovat, tak bys to asi bral jako samozrejmost.

U toho enginu si nejsem jistej jestli si me pochopil spravne. Chtel jsem tim rict ze nac by ostatnim davali kompletni zdroje enginu, kdyz jim muzou dat knihovny a scriptovaci jazyk, pomoci ktereho s nim mohou manipulovat. Protoze preci jen lexikalni a syntakticka analyza toho scriptovaciho jazyka si vezme jisty strojovy cas cpu(pak uz zalezi na konkretni implementaci scriptovaciho jazyka) Btw nerikam ze vlastni scriptovaci jazyk se neda pouzit pro engine, ale nevidim duvod pouzit konkretne (dle meho nazoru pomerne pomaly) python.

K tomu umistovani v cry enginu 2> "This allows designers to build complex levels without needing to write C++ code or LUA scripts." neboli Designer ma moznost vytvaret level nez nutnosti znat C++ nebo LUA. Jedine kde se pouziva v CrySis enginu Lua je to vyvoj AI a rekl bych ze az bude inteligence ve finalni fazi bude prepsana do C++ (pouze moje domenka, btw python tam nejak nevidim :D). Je mi jasne ze kazdy engine bude vyuzivat nejake scripty k drobne konfiguraci, tim procentualnim vyjadrenim sem myslel stezejni pozici scriptovacich jazyku podilejicich se primo na vyvoji hry.

Delal jsem i vetsi projekty a krome par konfiguracnich souboru sem nemel nutnost pouzit scripty (to uz zalezi na kazdem zda je zvoli ci ne, ja davam prednost konfiguracnim souborum a zbytek Cpp).

Jak si povidal o te uprave primo na miste, tak si ani tak neprotirecim, protoze pokud ten projekt vyvijis, a davas to na cilovy pocitac, tak se predpoklada ze ty knihovny (bez kterych by program stejne nejel) si prineses s sebou. Ted me mozna ukamenujes ale dev c++ (IDE i s kompilatorem) ma 13 MB :D:D:D:D. A pokud pouzivas externi knihovny, tak je ti to stejne celkem jedno, protoze ty potrebne funkce beres z nich a nezajima te jake knihovny ma k dispozici prekladac(samozrejme to "nezajima" je mysleno s jistou mirou nadsazky). Vzdycky ladim programy na miste a nikdy nebyl problem a to jak pod win tak pod linem(a kdyz je problem notebook to jisti ;-)).
No rychle si to bezesporu mel, ale porad mi unika ta pointa proc bych to mel v cpp pomaleji. V C++ se s HW pracuje naramne dobre, takze vzhledem k tomu ze nevim o presne jakou problematiku se pri reseni tve prace jednalo, tak si to nejak nedovedu predstavit.

Jeste bych se vratil k tomu poslednimu prispevku. Hezky si to obratil proti me :D:D, se musi uznat, ale tim hotovym produktem sem nemyslel zrovna python :D:D.

Mimojine jaky je tvuj nazor na .NET? (docela me prekvapilo ze se .NET "implementoval" do linuxu a to pod iniciativou microsoftu a rovnez vyslo neoficialni vyvojove prostredi pod "zastitou MS" Mono). Podrobneji jsem se o .NETu rozepsal v jednom predchozim clanku, ktery se tu neodeslal bohuzel diky betaverzi safari cely, ale co no :D. Jedna se o jeden z mala jazyku pro ktery mam pochopeni protoze vsechny projekty ktere jsem v nem doposud delal, jsem me neuveritelne rychle a efektivne, presto ze vykonostni pomer (co se tyce casu na potrebneho k provedeni jakesi testovaci ulohy) C++:C#:Java je zhruba 19%:39%:42% (nekde to testovali). A jak sam jiste vis interpretovane jazyky jsou 10-100x pomalejsi nez napr C++ (samozrejme v zavislosti na jazyku). Python vs. C++ jsem nikdy v prime konfrontaci netestoval(Zkusim zapatrat na internetu).

Moribundus | 01.07.07 v 02:08

Jeste si musim rypnout...ano, UnrealScript je psany v C++, Python a Ruby taky, takze to jeste samo o sobe nic neznamena :P A mas pravdu, ze se nezacina od piky, pouzije se jiz hotovy produkt (treba Python :P). A jak jiz jsem zminoval API OS je prave ta vec, ktera neni temer vubec prenositelna mezi platformami. Navic existujici knihovny nemusi byt zrovna v pouzitelnem/prenositelnem stavu a jejich hledani a testovani take zabere cas. Mj. jak se dela s unicode v C++? V Pythonu paradne, v Ruby a Lue vubec :D

Moribundus | 30.06.07 v 21:41

Jo, pokud programator vi, co dela a nepouziva ruzne microsofti rozsireni jazyka (a nepouziva veci, ktere Microsfot neimplementoval :)), pak se da kod portovat bez problemu. Ale porad je spousta detailu, ktere se lisi na jednotlivych platformach (zejmena na windoze). Pokud pouzivas teda multiplatformove toolkity (jako treba SDL) nemas takovy problem, ale tyto toolkity ti casto nedavaji takovou svobodu a moznost kontroly, jakou by sis predstavoval (treba SDL :D)

V Haskellu jsem delal jeden semestr, kdyz jsem jej mel na skole. Kdyz si zvyknes na ty rekurze, tak se v tom dela velice pekne, funkce jsou vyjadrene pekne matematicky, jak maji byt, vsechno je pekne a prehledne (jak kdy teda :D) V C++ nebyva reseni algoritmu rekurzi zrovna nejlepsim resenim, protoze pri tom pekne cvici zasobnik :-/ Faktem je ale, ze vstup/vystup je v Haskellu ponekud neobratny (jo a OpenGL knihovnu, nebo neco na ten zpusob jsem videl take, zajimavy zazitek ;))

Dovol mi rozptylit tve zamlzene predstavy ohledne hernich enginu :D Skriptovani NENI soucasti nejuzsiho jadra enginu, tj. skriptovani nema s renderovanim, audiem, siti atd. nic spolecneho. Skriptovani slouzi k organizaci levelu, chovani uzivatelskeho rozhrani, skriptovani umele inteligenc atd. Cilem je, aby mel designer co nejvetsi volnost, "otravoval" programatory co nejmene a samozrejme, aby spatnym prikazem neshodil cely engine (je chybou se domnivat, ze UnrealScript se pouziva pouze v licencovanych programech a ne v samotnem Unrealu). Ten je do prostredi, ve kterem skript bezi vetsinou ruznymi zpusoby vyexportovan, takze designer napriklad muze enginu rict akorat nakresli model, oziv bota/uspi bota atd. a podminky, za kterych k tomuto dochazi mohou byt velmi propracovane. Zpomaleni tu samozrejme je, ale vetsina vypoctu probiha v samotnem enginu, skriptem kod pouze "proleti". Navic na soucasnem hardwaru je toto zpomaleni opravdu zanedbatelne, engine travi vetsinu casu pocitanim fyziky, ai, nebo renderovanim milionu trojuhelniku a do toho mu skriptovani vubec nezasahuje.

Tvuj odhad 10% je trochu vedle, spise bych rekl tak 90-99%. Cry engine 1 i 2 podporuje skriptovani v jazyce Lua (viz stranky firmy Crytek, nebo databaze enginu na devmasters.net). Skriptovani ma opravdu zabudovane temer kazda hra. Mozna by to tu mohlo platit obracene, jako jsi predtim rikal o Pythonu: delas-li malou hru, skriptovani nepotrebujes, delas-li vsak velky projekt, neobejdes se bez nej.

PS: Na C++ mi chybela moznost program na miste doladit podle svych potreb. Byly to jiste prumyslove masiny, ja musel take dekodovat, co mi od nich chodilo a dokumentace nebyla zrovna nejlepsi, takze jsem to musel dodelavat na miste. S tim samotnym kompilatorem si trosku protirecis :P bez knihoven by mi byl asi jako mrtvemu zimnik :) Jenom MingW ma okolo 100MB (spousta se postahuje z netu). Navic MingW pouziva gcc, ktere ma jiny format knihoven a nevim, jak bych v tom pripade pouzil externi knihovny, ktere jsem potreboval. Zkompilovat si je znova? Fjuu. Jinak teda proti gcc a glibc nic nemam, mam je daleko radeji nez jejich "visualni" protejsky, ale pod windows to preci jen neni to prave orechove).
Take tim, ze jsem program byl schopen dodat tak rychle a tim padem levneji (a udrzba programu je velmi snadna), jsem prebral zakazku konkurenci. Ostatne toto je take snad jediny duvod, proc se vubec Delphi (nebo nedej boze C++ Builder) tesi takove popularite.

Esaras | 30.06.07 v 18:43

No co se tyce te multiplatformnosti, tak na tom prekvapive neni c++ zase az tak spatne jak pises pokud programator neni prase. C++ ma sice omezeny pocet standartnich knihoven, ale v dnesni dobe internetu to neberu jako nevyhodu, cca 2 minuty na netu a najdes jakoukoliv knihovnu (skoro). Nektere hry jak pises pouzivaji scripty (i kdyz na ukor drobneho spomaleni), ale ten podil neni zase az tak markantni, typoval bych ze by ses vlezl do 10% mozna i to je vysoka latka.

Ano borlandi prekladac patri mezi nejhorsi, neznamena vsak ze se VCL neda pouzivat efektivne.

Haskell verim ze je na matematiku rychlejsi jak C++, protoze jak sem jiz psal vychazi z matematickych teorii a diky a taky jak sem psal se vetsina operaci provadi rekurzivne coz umoznuje chod na multijadrovych systemech bez jakychkoliv optimalizaci (btw dokonce sem na haskell videl OpenGL knihovny :D uz se vidim jak pisu engine v haskellu :D nevim jestli si v nem nekdy psal ale celkem nezvyk psat funkcionalne). Co se tyce lambda abstrakci, tak sem se te neptal co c++ nema co python ma (kdybychom to obratili uzcite by se naslo taky neco co c++ ma a python ne), protoze i kdyz nektery jazyk nepodporuje nejake konstrukce apod. co nejakej jinej, neznamena ze se v nem dana uloha neda resit.

V C++ sem delal programy na analyzu textu, ruzne operace s nim a nemel sem pocit ze by mi neco chybelo. S regularnima vyrazama by to mozna bylo malinko pohodlnejsi ale nemel jsem pocit ze me neco zdrzovalo. (mimojine na to existuje rada knihoven).

No unreal ma sice vlastni scriptovaci jazyk (mimo jine napsany v C++ ;-)) ale hlavnim duvodem neni to ze by chod tohoto enginu potreboval scripty, ale protoze engine neni pouzivan jen pro hru unreal a je licencne prodavan jinym SW studiim (a pripada mi ze si tim chteji chranit vlastni kody a algoritmy, tak tam vrazili jen jakesi rozhrani pro ostatni, alespon to na me tak pusobi). Vem si treba Cry engine, na kterem pobezi CrySis je psanej celej v C++ a to z toho duvodu, ze chteji aby to slapalo jak nejrychleji to jen jde. (Mimojine tato hra pobezi takrka v plne grafice na prumernem cpu, 1-2gb pameti a geforce 7800gtx nebo radeon x1950pro, a jestli si videl co ten engine umi, tak ti muzu rict ze pred tema borcama nelze nic jineho nez smeknout, navic kdyz sem videl jak to v editoru mapy zoomoval nad celou mapu bez jakehokoliv zadrhnuti, tak to me dojalo)

Jiste vyvojovy cas stoji hodne penez, ale ty tady porad vykladas jakoby na C++ jiy nebyly hotovy knihovny. Uz samotne API OS poskytuje celkem dost funkci pro praci se samotnym OS a existuje velka rada knihoven pro vsechno mozne. Takze i kdyz je vyvojovy cas velmi drahy tak si uvedom ze kdyz se zacne psat nejaky projekt tak se ve vetsine pripadu nejede od piky(pokud se nejaka firma nesnazi vyvinout neco revolucniho :D).

Mno jak si psal ze si psal nejaky program pro HW, to by me zajimalo co ti v C++ chybelo, podle me prave na praci s HW (btw co to bylo za HW?)je C++ idealni. No jako tvoja volba, ale to by me teda fakt zajimalo.

Naco instalovat vyvojove prostredi, prekladac ma 10mb a sou free :D:D:D v kombinaci s PSPadem je to super :D:D:D:D. Mimojine nevim proc by ti to v C++ zabralo vice casu, jestli si jen neco podle nejakeho komunikacniho protokolu zasilal neco do HW a zpracovaval si ziskane data, tak je to vcelku jedno kde to pises ne? Ta doba vyvoje je zhruba stejna(si myslim).Tam se nemas kde zdrzovat, proste to nasypes do "roury" a je to(nevim co to bylo za HW tak nemuzu posoudit jestli si delal aplikaci tohoto typu, mozna se pletu).

PS: Nechce se mi to hledat, tak nevim jak sem to presne psal, ale mel sem na mysli ty lidi co si sednou k FG a budou si cist tento tutor. Preci jen kdyz sme na zakladce brali pascal, tak jedinej kdo v programingu dal pokracoval sem byl ja takze nelze soudit co se studenti uci na skole, ale co se uci doma. Na stredni sme jeli ANSI C a C++. A v programingu pokracuju ja, kamos programuje v Jave a to je asi tak vsechno. Takze jak rikam, to co se bere ve skole neni rozhodujici.

PS2:Sem zkousel betaverzi safari, a on nejak orezal ten text z toho editboxu, sem pak zkusil napsat do toho editu nejaky delsi text, oznacil jsem ho cely a jak sem ho zkusil zkopirovat do notepadu tak se zkopirovala jen cast od zacatku, maji to kluci od zelinaru nejak nevychytane :D.

Moribundus | 30.06.07 v 17:00

Vyhody pythonu - jak jsi rikal: netreba kompilace, interpret muze byt embeddovany primo v hostitelskem programu, multiplatformovost, siroky zaber standardnich knihoven. C/C++ ma rozsah standardnich knihoven vcelku omezeny, dalsi nadstavby, ktere pouzivas, nejsou prenositelne (o "dialektech" kompilatoru nemluve - viz MSVC). To, o cem pan, ktereho jsem citoval, mluvil, je to, ze muzes udelat mnohem silnejsi data-driven engine pouzitim prave skriptovacich jazyku. To C++ proste neumoznuje. Nene. Leda, ze by sis implementoval vlastni skriptovaci jazyk, ale to uz nejsme u C++.

Borland C++ je docela prasarna. Navic Borlandi C++ kompilator je mam ten pocit jeden z nejhorsich na trhu :D Nejlepsi produkt firmy Borland bylo Turbo C 2.0, od te doby se Borlandim "ceckum" rika C-- :-)

Ruby on Rails platforma je mj. dobra pro delani slozitych webovych aplikaci (ackoliv Ruby by imho potrebovalo krapet doladit, ale to je jina). A Haskell a obecne funkcionalni programovani je super prave pro matematicke vypocty, myslim, ze jsem videl jakysi dokonce benchmark, kde Haskell byl rychlejsi nez C, nebo C++. Treba lambda abstrakce mi docela chybi v C++ (a python ji ma :P)

Dale napr. prace s retezci a regularnimi vyrazy jsou obrovskou vyhodou napr. Perlu (pokud pracujes hodne s cistym textem - analyza, synteza, muze byt Perl vhodnou volbou) a C/C++ opet tuto funkcionalitu nema (alespon ne ve standardnich knihovnach).

Z Game Programming Gems 6 jsem citoval kvuli tomu, ze preci jenom jsme na serveru o hrach a tato serie knih pojednava o profesionalnim vyvoji her. At se ti to libi, nebo ne, skriptovaci jazyky se pouzivaji v hernimu prumyslu na denni bazi. Firmy, ktere nepouzivaji jiz hotove jazyky si stejne tvori vlastni (napr. UnrealScript). Jak sam urcite moc dobre vis, vyvojovy cas stoji hodne penez. Implementace vlastniho efektivniho skriptovaciho jazyka neni tedy levnou zalezitosti, udelat hru (nebo jakykoliv jiny program) hard-coded je velmi neefektivni a neflexibilni (a ve vysledku stoji opet vice penez).

Jo a kdy bych pouzil python misto C++. Jak jsem rikal, pouzivam vetsinou C++, ale delal jsem jeden program pro specificky hardware, ke kteremu nebylo moc dokumentace a ktery byl hlavne moc objemny a drahy na to, abych u nej mohl pracovat, takze jsem musel psat "naslepo". Zvolil jsem python, program napsal za dva dny a doladil primo na stroji k danemu hardwaru pripojenem. Python jsem volil konkretne kvuli jeho knihovnam (ostatni skriptovaci jazyky nevyhovovaly - pokazde jim neco chybelo). Instalace vyvojoveho prostredi na cilovy pocitac nepripadala v uvahu (nehlede na legalni stranku veci) a navic prostredi pythonu je relativne male (30MB se vsemi knihovnami). Kdybych ten program vyvijel v C++, zabralo by mi to mnohem vice casu (jo a nemam notebook :'(). Doufam, ze to uspokojilo tvou zvedavost ;-)

PS: S tim, proc se na strednich skolach uci Pascal a Delphi mas pravdu. Ja tim reagoval pouze na tve tvrzeni, ze vetsina lidi ma zkusenosti s C.
PPS: Nejak nam ten off-topic prekypel :D Jo a ja odesilam z Opery a pohodicka, ale rekl bych ze ff bude taky v pohode.

Esaras | 29.06.07 v 20:49

Mimojine s Artmanem taky plne souhlasim, kazdy jazyk je vhodny na neco jineho. Nektere sou pro rychle matematicke vypocty, nektere pro jednouduchou tvorbu rozhrani a jine jsou uplne k hov*u :D.

Jo a Moribundus, vsiml sis ze tu delame celkem solidni OT? :D:D:D

Esaras | 29.06.07 v 20:37

Jasne nepotrebuje kompilator, potrebuje interpret, potrebuje behove prostredi, takze pokud ho nemas, tak mas smulu.

"Kazdy jazyk byl navrzen, kvuli nejake mezere na trhu" -> no to by me fakt zajimalo kvuli jake mezere byl navrzen python, at premyslim jak premyslim, tak me nic nenapada. V c++ je efektivne resitelna velka vetsina problemu, az na slozite matematicke operace pro ktere byli navrzeny specielni programovaci jazyky ke kterym zrovna python nepatri.

O tech dalsich jazycich co si napsal si myslim totez co o pythonu krome Lispu a Prologu. Haskell jsem mel moznost poznat a vetsi humus sem jeste nevidel (beru z hlediska psani kodu), ale u tohodle jazyka ten humus nemyslim tak doslovne protoze se jedna o funkcionalni programovani a ne o logicke, takze konstrukce je jina. Haskell vychazi z matematickych teorii a skoro vse probiha rekurzivne (vzhledem k tomu ze tam nejsou logicke operatory ani vazby, cykly...). Haskell je jinej a moc mi nesedel, radeji logiku :D.

Nekteri mi rikaji treba ze v cpp nelze tak rychle psat tzv xichty pro db, ale pokud si vemes treba VCL od borlandu tak ti garantuju ze to budu mit rychleji nez ty v pythonu. Jako nevim jak ty, ale jeste jsem nenalezl problem ktery bych efektivne a rychle v C++ v kombinaci s asm nevyresil.

Na skolach se uci Pascal a Delphi protoze maji jednoduchou syntaxi, jsou srozumitelne, snadno pochopitelne a nazorne.

"Python pouze muze doplnovat to, co C++ nezvlada moc efektivne" -> rekni mi co python zvlada efektivneji nez C++? (tohle neberu s nadsazkou, myslim zcela vazne)

Ten anglickej clanek je moc hezkej, skoro bych rekl ze se ten typek podili na vyvoji pythonu :D:D

A k te posledni vete, ja nevidim jediny rozumny duvod python pouzit, a nenapada me jedina oblast pro pro kterou bych jako jazyk zvolil python misto C++ (s asm) nebo C#, pokud neberu nejakou hodne slozitou aplikaci ktera by se dejme tomu dala psat treba ve fortranu.

Prosimte rekni mi oblast ve ktere by si pouzil python misto C++, chtel bzch o takove vedet. Predem diq.

PS: Na preklepy se vykasli :D
PS2: doufam ze to z mozily prijde dobre :D

Moribundus | 29.06.07 v 17:24

"It can be no coincidence that the rapid growth of interest from the outside has occured simultaneously with the shift inside the industry towards better tools supporting high-level engine access and content creation. Indeed, the sophisticated authoring tools behind many of our products are often the biggest attraction cited by R&D companies and university researchers.
Personally, I think we're finally starting to do things the right way. The era of hard-coded, closed systems is coming to an end. The change-a-number-compile-test-and-repeat cycle has just got to goaway, and in fact it is, if just a little bit too slowly. We are on the brink of an industry-wide renaissance that will see high-level, component based content and gameplay creation that only the top-tier games now exhibit."
Mike Dickheiser, Game Pogramming Gems 6, pg.xv

A nechci pusobit jako zaryty Pythonista, pro svuj soucasny herni projekt jsem dal prednost Lue, pouze nesouhlasim s tim, ze je Python "naprosto zbytecny jazyk"

PS: mnoho preklepu v predchozim prispevku :(

Moribundus | 29.06.07 v 17:15

Nerikam, ze je Python stejne rychly, jako C++. Rikam, ze na soucasnem HW rozdil okem nepoznas (pokud nedelas ty hi-end aplikace). Navic to, ze python nepotrebuje kompilator a je obrovska vyhoda. Artman ma v tomto spravny pristup. Kazdy jazyk byl navrzen, kvuli nejake mezere na trhu, kvuli tomu, ze jinym jazykum neco chybelo. A ne kazdy problem je efektivne resitelny v C/C++. Neodvazim se hadat, co si myslis o ostatnich jazycich vyssi urovne jako jsou napr. Ruby, Haskell, Prolog, Perl, Lisp a dalsi.

Opet si prosim uvedom, ze vetsina lidi nemusi mit stejne nazory jako, stejnou praxi a delat na stejne platforme jako ty. Zkus se na vec podivat z trochu jine perspektivy. Navic mam ten pocit, ze na vesine strednich skol se neuci cecko (skoda), ale Pascal nebo Delphi, takze "vetsina" lidi bude mit zkusenosti spise s temito jazyky a ne s C. Myslim, ze jsem dokonce slysel, ze se kdesi uci prave i Python.

Duvody proc pouzivat Python ti nebudu davat. Vidi ji lide ze spolecnosti jako je Google, Firaxis, NASA, CCP Games (EVE Online), Honeywell, ILM atd. a vidim je i ja. Python neni nahrazkou C++, jak jej mozna chapes ty, Python pouze muze doplnovat to, co C++ nezvlada moc efektivne.

Esaras | 29.06.07 v 11:09

Btw No Flame, piš si v čem chceš :D proti gustu žádný dišputát.

Zdravim

Esaras | 29.06.07 v 11:05

No tak tu betaverzi safari asi odinstaluju :D, Už se mi to tu nechce psát znova. Příště to radeji napíšu z jiného prohlížeče.

Esaras | 29.06.07 v 11:03

Neboj já mam silné nervy, takže mě to jen tak nedojme :D. Je samozřejmě každého věc v čem si píše. Vím že hodně aplikací pro linux je napsaných v pythonu (taky to tak vypadá :-) , btw neříkal sem že ty aplikace nepobeží normálně, jen sem říkal že poběží pomaleji) a dovolím si nesouhlasit že python je skoro stejně rychlý jak C++ (je výrazně pomalejší). Máš sice pravdu že u takhle malých a nenáročných programů HW "stírá" (ve skutečnosti nestírá, ale nejde to znát) rozdíly, ale nevidim důvod se zdržovat něčím jako je python a mezi náma vsadím se že C/C++ umí (alespoň základy) mnohem více lidí nez python. Navíc autor článku psal že to každý může psát v čem chce, ale že autor zvolil C++ je jen jeho rozhodnutí a věc, a dle mého názoru se rozhodl nejlíp jak mohl.
A opět k C#. Nezlob se na mě, ale kdybych se měl rozhodnout jestli napsat program v pythonu nebo v C# tak neváhám ani pikosekundu a troufám si říct to budu mět napsané rychleji než ty v pythonu. Podle mě je python naprosto zbytečný jazyk, nevidím jediný důvod proč se tento jazyk učit a dokud me někdo nepřesvědčí o opaku, tak si stojím za svým ;-).
Nevím co je sice na WinAPI kostrbatého, zastaralé sice je, ale umož

artman | 28.06.07 v 20:49

Hlavně tu kluci nerozpoutejte flame o programovacích jazycích :)..

Každopádně každý jazyk má něco do sebe.. Osobně mám také rád jazyky C a C++ (nedělám hry a neumím v nich ale zdaleka tolik co ty a Esaras), ale zase ne na vše se hodí....

Moribundus | 28.06.07 v 19:28

No tak ted jde o to, jak je tento serial zamereny. Jestli na psani profi 3d enginu, tak tam kraluje C++ kvuli rychlosti a prime praci s pameti (viz konzolove programovani, pdacka apod.). Ja ten clanek ale pochopil, ze se snazi ukazat, jak udelat obycejnou 2d hru stylu a na ty nepotrebujes vykon C++ (nebo proc ne rovnou klasicke C? je rozhodne rychlejsi jak C++). Soucasny hardware stira rozdily mezi C++ a interpretovanymi jazyky u takovychto aplikaci.

Vis, ze treba polovina Civlizace 4 je napsana v Pythonu? Nebo serie Baldur's Gate je zpola psana v Lue (kterou mj. pouzivam pro svuj projekt i ja). Tyto jazyky maji take vyhodu tu, ze jejich knihovny jsou psane primo v C/C+, takze rychlost, zde neni az takovym problemem, navic, jak nam rika pravidlo 80-20, 80% casu behu programu se stravi provadenim 20% kodu (Scott Meyers). Takze profici si napisi herni engine v C++ (nebo si jej licencuji) a "game logic" pisi ve skriptovacim jazyce. Sidu Meierovi se z Pythonu rozhodne zle od zaludku nedela :) Pokud se podivas poradne napr. na Linuxove aplikace, zjistis, ze mnohe jsou napsane v Pythonu a jedou bez zadnych problemu, nektere webservery take bezi na pythonu a nemaji s nim zadne velke komplikace.

Trosku bokem: jsem odkojeny ANSI C a dokrmeny ISO C++ a zase se mi navaluje z C# a Javy prave ze stejneho duvodu jako tobe z Pythonu, ale ruku na srdce a predsudky stranou, rozdily ve vykonu jsou opravdu zanedbatelne, pokud nedelas narocne high-end aplikace, nebo komplikovane matematicke vypocty (pri kterych bys stejne pouzil vhodnejsi jazyky jak C++).

Jeste, abych upresnil, co jsem myslel tim, ze WinAPI je "pase". MSVC 2005 ma takovy zlozvyk generovat vysledny binarni kod pro CLI platformu, takze jsem predpokladal, ze nahradi volani fci WinAPI volanim .NET ekvivalentu (alespon MSDN mi casto pri prochazeni dokumentace neustale nuti .NET nahrazky). Ted jsem si zkousel udelat dva projekty z sablon - prvni .NET a druhy WinAPI obyc. okno a byl jsem na omylu, nenahrazuje (ackoliv verze WinAPI byla dvojnasob velka). Kazdopadne architektura WinAPI je zastarala a oproti objektovym modelum hrozne kostrbata. Navic srovnani s assemblerem neni zrovna prihodne, jelikoz assembler poskytuje vyhodu v manualni optimalizaci oproti vyssim programovacim jazykum, zatimco WinAPI tuto vyhodu nema (obzvaste, je-li vysledny kod stejne generovan pro CLI). To, ze WinAPI pouzivas, jak rikas takrka denne, je jiz tvoje vec :P a nevypovida nic o navycich ostatnich. Taktez to, ze nemas problemy se spravou pameti neznamena, ze zadny zacatecnik (byt treba zkuseny v delphi) s pameti nebude mit problemy (hint: bude :D). A pokud by se jim serial libil a nebyl by zrovna o C++, tak neni problem na nej prejit, ne? Na C++ je tutorialu spousta i na ceskych serverech, treba na builder.cz.

PS: Doufam, ze se tento prispevek do tebe moc emotivne "neopre" ;-)

Esaras | 28.06.07 v 08:23

Hmm, tak se mi ten referát nějak rozjel, se mi to nechce psát znovu, takže ve zkratce co jsem psal.

Python - ten jazyk absolutně odmítám, je vhodný pro tvorbu menších prograrmů, v žádném případě ne pro hru a programy většího rozsahu. Navíc je python DĚSNĚ pomalý. Ano, máš pravdu, sice se v něm tvoří rychleji, ale výsledný program je PODSTATNĚ pomalejší než v C++ a na práci s pamětí se soustředit nemusím, to už ani nevnímám, beru to jako samozřejmost a dělám to už tak nějak automaticky. Někomu by se tvorba her mohla zalíbit natolik že by chtěl pokračovat ve 3d, v tom případě je C++ správnou volbou a ty inicializace si můžeš napsat jen jednou a při novém projektu můžeš vychážet z již napsaného(mimo jiné borci z nehe gamedev udělali do VS05 šablonu na vytváření OpenGL projektu, kde se ti předgenerují tyto inicializace, tuším že něco podobného je i pro DX), jen provedeš drobné korekce.

WinAPI - Nemyslím si že je WinAPI pasé (jakěkoliv API obecně). Používám ho dnes a denně. Vem si klik lidí už zařadilo x86 assembler do archivu a přitom si neuvědomují jak často se dnes používá.

C# to už je jiná, tady už by se dalo o něčem bavit. XNA umožňuje navíc psát pro next-gen konzole jak už si psal. Navíc se v C# dá psát unsafe, takže s pamětí můžu pracovat jako v C++ a pro tvorbu her mohu doporučit. Psal jsem už v mnoha jazycích(na C++ jsem vyrostl takže na něj nedám dopustit :-) ) a jestliže bych za něco vyměníl C++ tak za C# i když to není úplně totéž. .NET je udělanej celkem solidně, ale přesto si myslím že C++ svou pozici jentak neztratí, zatím je stále nejžádanější (hned po něm je java). Na poli herního průmyslu kde se bojuje o každej frame to platí dvojnásob (teda ve většině případů). Autor seriálu mohl použít třeba C#, ale nevidím důvod proč nepoužít C++. Když se na ty kódy podíváš tak do DX se zachází minimálně, a ten kód by měl intuitivně pochopit i začátečník v C++ (C++ je jen nástroj a jak už jsem psal tak je vcelku jedno v čem je to napsané ale programátor by se v tom měl intuitivně zhruba orientovat i když daný jazyk nezná), protože vesměs se jedná pouze o matematiku (až na pár řádků).

PS: Nikoho nesoudímt, ale i kdyby to tak vypadalo, tak mě ber s rezervou, jak vidím skladbu písmen PYTHON tak se mi dělá zle od žaludkum v očích mi šlehají plameny a tečou mi sliny z pusy :D, takže můj mozek je pak pod velkým tlakem a v textu se pak projeví emoce :D

Esaras | 28.06.07 v 07:56

to Moribundus:
"muze mnohem lepe soustredit na samotnou algoritmizaci"
Je sice hezké že se můžes soustředit na samotnou algoritmizaci, ale hlavní problem spočívá v tom že python apod. je nekolikanásobně pomalejší (v nekterých případech je to v řádech desítek násobků) než C++. Taky nesouhlasím s tím že je tvorba v pythonu je "MNOHEM" rychlejší. Je rychlejší, ale já si nad tím raději posedim o něco déle a budu to mít PODSTATN

Moribundus | 26.06.07 v 17:37

Re Esaras: Dekuji za doporuceni, ale obavam se, ze nepadlo na moc urodnou pudu. Jiz to bude nejaky ten patek co programuji v ruznych jazycich na ruznych platformach a ani mi necini problem si pujcit v knihovne kvalitni anglickou literaturu a pocist si hezky v originale, ale o to nejde. Svuj prispevek jsem myslel spise jako navrh na zlepseni (novy tutorial). K tomu pythonu, pokud jsi nekdy neco delal v nejakem z vyssich jazyku (Python, Ruby), das mi jiste za pravdu, ze vyvoj aplikaci v nich trva mnohem kratsi dobu a clovek se pritom muze mnohem lepe soustredit na samotnou algoritmizaci a nemusi resit napr. explicitni spravu pameti, nebo neopravnene pristupy, atd. Pygame modul byl navic vytvoren s tvorbou her na mysli, takze neni zapotrebi cely jeden dil tutorialu na inicializaci okna (a autor nemusi odkazovat ctenare, at si precte dokumentaci k Win32API, ktere je jiz dnes v dobe .NET technologie stejne pase). K tunam kodu: myslel jsem pomer kod/normalni text. Mj. C# je v posledni dobe take dosti popularni a Microsoft velmi podporuje tvorbu her v tomto jazyce, zejmena svou XNA knihovnou (tusim, ze je i "multiplatformova"). C++ opravdu neni zapotrebi, pokud clovek nedela engine, ktery ma budto ambice na komercni uspech, nebo byt zkompilovatelny na vice platformach. Jeste jednou dekuji za dobre minene rady, ale priste nemusis predem nikoho soudit.

Esaras | 21.06.07 v 19:24

To Moribundus> To s tím pythonem si nemyslel vážně že ne? C++ je idealnim jazykem pro tento seriál, navíc autor na začátku psal že si s sebou máte přinést "základní znalost některého programovacího jazyka, ideálně C++". A pokud umíš programovat, tak je ti úplně jedno v čem píšeš. Ten jazyk tvoří tak 5% toho čemu se říká programování. Programing je hlavně o logice a algoritmech. Autor zde používá opravdu jen základy a jestli tomuhle říkáš tuny kódu, tak na to ti opravdu nemám co říct... Navíc autor používá DX jen okrajově, takže ten kód by měl pochopit snad každý kdo umí alespoň trochu programovat. Problém je v tom že většina začátečníků (tím nechci nikoho nijak ponižovat ani urážet) se neumí orientovat v cizím kódu. Jo jinak jestli by si chtěl dělat hry, doporučuju nehe.ceske-hry.cz, kde je tutoriál k OpenGL úplně od základu a ke konci tutoriálu je tam i díl ve kterém je využíváno vertex shaderu. Akorát jestli tomuhle říkáš tuny kódu, tak nevím jestli ti mám doporučit se na tu stránku vůbec dívat :-). Každopádně než se do toho nehe pustíš doporučuju se pořádně naučit programovat (nejlépe v C++). A jestli se hodláš pustit do 3D tak trocha teorie z analytické geometrie se taky hodí. (Učivo středních škol)

Moribundus | 21.06.07 v 16:21

Také mi přijde tento seriál jako trochu nepovedený. C++ opravdu není jazyk pro začátečníky (rozhodně ne pokud se jej mají naučit "hozením do vody") a způsob psaní těchto tutorialů mi taky nepřijde zrovna nejlepší - pro začátečníka je tu tuna kódu, kterému vůbec nerozumí a pro zkušenějšího programátora tu zase není nic nového. Ale abych jen zbytečně nekafral, proc třeba nenapsat tutorial k pythonu a jeho rozšíření pygame? Nebo třeba nějaký tutorial se svolením přeložit. Viz www.python.org a www.pygame.org

pepa | 04.06.07 v 12:22

road firm

Esaras | 03.06.07 v 14:15

Ludva, jestli ti tak moc vadí obsah seriálu, myslím že autor seriálu uvítá jakoukoli pomoc, jakékoliv konstruktivní nápady nebo inovaci. Někdo se snaží dělat něco pro ostatní a ty si zatím nic nepředvedl, tak tu nekritizuj práci jiných. Kdyby si místo buzerace radeji přispěl těm co to neumí, nebo jim nějak poradil, pokud teda umíš alespoň nakreslit ten čtverec v pascalu. A jak psal Marian, tak každý nejak začínal, a pokud vím, nikdo neumí programovat odnarození a ty nejsi vyjímka.

Olalaf | 03.06.07 v 11:00

Ježiš,tyhle hovada co všechno uměj,všechno znaj,ale nic nenapíšou přímo miluju.Většina lidí u těchhle článků říká že to je na hovno,jen proto žýe zrovna ONI to uměj.Možná je to na netu v miliónu verzích,ale kdo zná tenhle server,a komu se nechce šťourat se v cizokrajných stránkách,kde ti ještě nahážou různý viry a spywary a bůhvícoještě,tak ať jde sem.Nechápu,proč vám neustále vadí,že holt někoho baví psát o programovaní pro "n00by" co to neznaj.

Marian | 02.06.07 v 20:49

Ok siláku, zdá se, že se tady zjevil pan Borec. Rád tě tedy přivítám ve svém externím týmu, který připravuje komplexní řešení pro velké banky a nadnárodní korporace. Ovšem pouze pokud zvládneš kompletní profi-cutomizaci formou programování v oblastech DWH, DM, OLAP a Business Intelligence, navíc se zkušeností v optimalizaci prediktivních modelů (polynomální regrese třetího a vyššího řádu) podle Vapnikovovy Statistické teorie učení (nejlépe v mainframe engine KXEN). Nevíš o co gou? Jsem si téměř jist!!! Najdi si to na internetu a až budeš mít opět nějaké připomínky k jednoduchosti zdejšího článku o programování, pak si uvědom, že pro mnoho lidí to velký přínos má. Každý někdy někde začínal...

Ludva | 02.06.07 v 20:08

Ježiš to je nuda... Tenhle serial teda už asi na netu bude v milionu verzích. Opravdu originalita... A hlavně přínos jako svině:D:D:D Vubec nechápu k čemu to je, to bych mohl psát serial jak nakreslit čtverec v pascalu:D

spartan13 | 02.06.07 v 10:06

Sice ta hra, kterou autor chce popsat a naprogramovat není zrovna nejlepší a samozřejmě nejtěžší.
Ale někde se začít musí a aspoň pro někoho, kdo začíná to má velký přínos.

Esaras | 01.06.07 v 09:15

Jinak určitě je fajn, že je na FG tento seriál, alespoň hráči zjistí že udělat hru není zase až tak jednoduchá záležitost a příště než budou kritizovat nějaké vady ve hrách , tak si to rozmyslí, protože už budou vědět jak složité je naprogramovat různé efekty apod. Osobně bych pro tento seriál zvolil OpenGL, protože jeho kód je podstatně čitelnější, pro začátečníka srozumitelnější a efektivnější. Jeho konstrukce jsou snadno pochopitelné a výsledný kód je kratší. Ale je to věc názoru, protože nadruhou stranu zase v OpenGL si nekteré věci proste musíte "ošéfovat" sami.

artman | 31.05.07 v 21:45

Jsem téhož názoru jako Esaras. Já v jazycích C/C++ dělám více než rok a sice hry nedělám (cvičím hlavně algoritmy, matiku, logiku), ale přesto můžu říci, že pracovat v těchto jazycích není žádná sranda. Strašně hodně člověku dovolí a pokud nemá zkušenosti, lehce začně dělat docela hrubé chyby, které pak vedou k podobným hláškám..

Osobně jsem za tenhle seriál rád, nemohu ho ovšem doporučit úplným začátečníkům (viz výše + Esarasův text)... Každopádně komu nesedne tohle, může v budoucnu očekávat něco nového :)...

Jinak programování je hrozně fajn, ale člověk musí mít hroznou trpělivost.. Ale je to tvůrčí činnost a efekt, když se daří, je nepopsatelný :).. Tak se nevzdávejte....

Esaras | 31.05.07 v 19:08

Nakopej sem obsah celého buildlogu. Jinak jak si psal ze v c++ neděláš dlouho tak bych ti radeji doporučil, aby ses nejdříve naučil pořádně c++. Byť se jedná o triviální projekt, přesto už to nejsou základy a neznalost c++ tě jen brzdí a aby si nedopadl potom tak, že nebudeš umět ty jednodušší věci, budeš se v tom ztrácet, tak to budeš lepit stylem ctrl+c, ctrl+v a moc z toho mít nebudeš. (Nechcu tě od toho odrazovat, ale programovat se musíš učit postupně).

Jan Kohout | 31.05.07 v 17:45

2Leonidas: Podle zde uvedeného výpisu to nejsou chyby, ale jen warningy - tedy varování, že něco může dělat neplechu, ale jinak by kód měl být spustitelný...

Leonidas | 30.05.07 v 18:45

Omlouvám se ,ale v komentářích k prvnímu dílu bych se dočkal odpovědi asi za... hodně dlouho.
Používám Dev-C++ a ten mi při kompilaci zdrojového kódu hlásí chybu..
řádek 70
[Warning] passing NULL used for non-pointer argument passing 1 of `HWND__*

a

[Warning] argument to non-pointer type `long unsigned int' from NULL

Nějak tomu popisu nerozumím a ani programování v C++ nedělám dlouho...

UnHynek | 30.05.07 v 15:41

eMan: Freegame neni jen o hrani her, myslim si, ze takovyto serial ma velky prinos! Konecne - nechces napsat take serial? Mohlo by to byt zajimave! Myslim to vazne :-))

eMan | 30.05.07 v 15:23

na FG tohle nemá co dělat., navíc to není nejlíp napsaný a navíc je to blbě zformátovaný, nečitelný ..... :( :(