Články

Jaké jsou druhy licencí a možnosti licencování software a co z jednotlivých variant plyne pro uživatele a vývojáře? Musí být otevřený software nekomerční?

Jedinečná česká kniha o vývoji počítačových her! Pojďte se spolu s českými odborníky a profesionály z oblastí game designu, managementu, marketingu, médií a dalších oblastí herního průmyslu podívat do zákulisí vývoje moderních interaktivních aplikací! Texty jsou určené jak samotným zájemcům o vývoj her, tak všem, kteří touží něco nového se dovědět.

Co je to hra? Jak fungují herní světy? Jaké jsou role v týmu a jakou cestou se nápad stává hotovou hrou, kterou si můžete koupit v obchodě? Jaké jsou možnosti distribuce a proniknutí na trh? Jaká média ovládají českou herní scénu? Jaký je potenciál využití her ve školách a vzdělávání? Jak fungují a vydělávají online hry? A co umělá inteligence? A není samotná realita, v níž žijeme, vlastně hra? Jaké jsou možnosti licencování, co je to otevřený a svobodný software? Jaké jsou možnosti podpory vývojářů v ČR a EU? Jaká bude budoucnost herního odvětví a vůbec moderní lidské "on-line" společnosti?

Kniha byla vydána 12. května 2011, 134 stran B5.

V tomto článku se pokusíme implementovat snadno použitelnou třídu kamery, která bude vhodná pro pohyby v obecném 3D světě, například pro nějakou střílečku - myš mění směr natočení a šipky na klávesnici zajišťují pohyb. Přestože budeme používat maličko matematiky, nebojte se a směle do čtení!

Nápad na tento článek se objevil v době, kdy jsem se pokoušel na svůj počítač nainstalovat Gentoo Linux a byl nucen pracovat několik dní výhradně v textové konzoli. Nečekejte ode mě žádné advanced techniky spojování programů a podobné unixové vychytávky, ale spíše reklamu na uživatelsky příjemný software pro textový režim. Článek je určen spíše pro začátečníky.

Také vás zaráží rychlost gigantických správců pracovního prostředí typu KDE nebo Gnome? Což takhle zkusit PekWM, jeden z alternativních správců oken, který se vyznačuje pohodovým vzhledem, vysokou rychlostí a téměř absolutní konfigurovatelností?

Dvacátý čtvrtý díl je shrnutím celé série o multiplatformní knihovně SDL. Celý text je strukturován podle jednotlivých článků, u každého je uveden úvodní odstavec spolu se seznamem SDL příkazů, které v něm byly probrány. Na konci naleznete také PDF k vytištění.

V dnešním, (téměř) závěrečném dílu o knihovně SDL se pokusím shrnout všechny věci, na které jsem během psaní seriálu pozapomněl, popř. kterým jsem se z důvodu své neznalosti nevěnoval pozornost. Mimo jiné se budeme věnovat SDL_RWops, YUV video overlay, nahrávání sdílených knihoven za běhu aplikace a proměnným prostředí.

V dnešním dílu seriálu o knihovně SDL se budeme věnovat podpoře tzv. vícevláknového programování. Podíváme se na vytváření nových vláken a samozřejmě také na jejich synchronizaci, která nikdy nesmí chybět.

Další oblastí knihovny SDL, kterou si popíšeme, bude API pro práci s CD-ROM. Po přečtení tohoto článku byste měli být schopni si vytvořit jednoduchý CD přehrávač, který zahrnuje přehrávání a pauzy, listování a pohyb ve skladbách a také vysouvání mechaniky pro vložení nového disku.

Ve 20. dílu dokončíme popis knihovny SDL_mixer. Budeme se bavit především o hudbě a speciálních efektech, jako je nastavení rozdílné hlasitosti levého a pravého kanálu nebo simulace ztišení vlivem vzdálenosti zdroje zvuku od posluchače.

Vše, co se týká SDL audio funkcí, už máme probráno, takže se zkusíme podívat na rozšiřující knihovnu SDL_mixer. Knihovna SDL_mixer poskytuje snadno použitelné funkce pro mixování zvuků a hudby. Je vhodná obzvlášť pro ty, kterým připadá standardní SDL audio API příliš nízkoúrovňové a strohé.

V tomto dílu konverzemi zvuků dokončíme popis funkcí, které SDL poskytuje pro audio. Druhá část článku bude věnována rozšiřující knihovně SDL_sound, která slouží pro dekódování zvuků z .MP3, .MID, .OGG a dalších běžně rozšířených formátů.

V dnešním dílu o knihovně SDL začneme nový tematický celek, budou jím zvuky a hudba, které přinesou konec všem tichým aplikacím. Na první pohled by se mohlo zdát, že si musí naprostou většinu funkčnosti napsat programátor sám, nicméně je možné používat již hotový mixer v podobě rozšiřující knihovny SDL_mixer, který odstraní většinu námahy.

V dnešním dílu se podíváme na systémové časovače a funkce pro práci s časem. Na konci budou také v rychlosti zmíněny rychlostní optimalizace včetně výpočtu FPS.

V dnešním dílu o knihovně SDL dokončíme popis událostního systému. Budeme se mimo jiné věnovat změnám velikosti okna, jeho aktivacím a deaktivacím, posílání uživatelských zpráv a dalším věcem, které ještě zbývá probrat.

Joysticky, kniply, páky a jiné ovladače bývají nedílnou součástí většiny her, hlavně simulátorů. Tento díl bude věnován právě jim.

Na řadě je další vstupní zařízení, tentokrát se jedná o myš. Opět se budeme věnovat jak událostem, tak přímému přístupu.

Pravděpodobně nejpoužívanějšími vstupními zařízeními počítače jsou klávesnice a myš, v našem seriálu začneme právě klávesnicí. Podíváme se na ni jak z událostního pohledu, tak "přímým" přístupem a uděláme první krok k interaktivním hrám.

Na konci minulého dílu jsme nakousli základní práci s událostmi, dnes budeme pokračovat. Tento článek je primárně věnován práci s frontou událostí, ale jelikož ještě nevíme nic o unionu SDL_Event, bude částečně probrán i on.

Seriál se přehoupl do druhé desítky, příště už na počítání přestanou stačit prsty ;-). Ale ještě než se tak stane, probereme si komunikaci aplikace se správcem oken, což v sobě zahrnuje změnu titulku okna, minimalizaci, přepínání do/z fullscreenu a několik dalších věcí. Ke konci bude také přidán lehký úvod do zpracování událostí.

V dnešním dílu bude popsána knihovna SDL_ttf, která slouží pro výpisy textů do scény. Se zobrazením textů a především s českými znaky bývá někdy potíž, nicméně použití SDL_ttf je velice jednoduché a naprosto bezproblémové.

Díky přímé podpoře OpenGL umožňuje SDL renderovat i 3D grafické objekty, které se staly nepsaným standardem naprosté většiny dnešních her. Tentokrát se tedy budeme věnovat podpoře OpenGL v SDL.

Tentokrát se ponoříme trochu více do hloubky, popíšeme si SDL grafické struktury a tyto znalosti následně využijeme k přímému přístupu k pixelům obrázku. V závěru budeme také měnit kurzor myši.

V tomto dílu budeme dále rozvíjet naše znalosti o SDL grafice. Předvedeme si například, jak vyplnit surface barvou, jak docílit toho, aby určitá barva byla transparentní (průhledná), jak nastavit průhlednost i takového surface, který neobsahuje alfa kanál, a další užitečné věci.

Dnes se podíváme na grafické funkce poskytované knihovnou SDL. Vzhledem k rozsáhlosti tohoto tématu zde budou uvedeny pouze nejzákladnější věci, podrobnostem se budeme věnovat až v následujících dílech.

V minulém dílu jsme si dopodrobna vysvětlili inicializaci SDL, ale ještě něco málo zbylo - nastavení vlastností a vytvoření okna. Jak brzy zjistíme, v porovnání např. s Win32 API je tato činnost v SDL mnohem jednodušší.

V první části článku se podíváme na konvenci názvů SDL funkcí a speciální datové typy, které SDL přináší. Ve druhé části bude popsána inicializace a deinicializace SDL.

Ve druhé části série si ukážeme, jak nainstalovat SDL, a dále budou uvedeny "step-by-step" návody na vytvoření SDL projektů v gcc, MS Visual C++ a Dev-C++.

V této sérii článků se vám představí knihovna SDL, která slouží pro vývoj her a multimediálních programů a jejíž největší předností je možnost zkompilovat zdrojový kód pro všechny běžně používané operační systémy. Ukázkové programy budou napsány v jazyku C/C++ a zkompilovatelné minimálně pod operačními systémy GNU/Linux a MS Windows.

Každý, kdo někdy programoval částicové systémy, se jistě setkal s problémem, jak zařídit, aby byly polygony viditelné z jakéhokoli směru. Nebo-li, aby se nikdy nestalo, že při natočení kamery kolmo na rovinu částice, nebyla vidět pouze tenká linka. Složitý problém, ultra jednoduché řešení...

Ještě než se pustíte do čtení tohoto textu, měli byste vědět, že není součástí oficiálních (anglických) NeHe Tutoriálů. Napsal ho "pouze" jeden z překladatelů, kterému chybělo něco na způsob trochu ucelenějšího úvodu do tak obrovské problematiky, jakou představuje programování 3D grafiky, her a ostatně všeho okolo OpenGL.

Tento neplánovaný díl je především reakcí na diskuze k dílům minulým. Nebudu se moc věnovat věcem, jako je číslování verzí DirectX nebo omyl s DirectPlay, protože je v současné chvíli nepovažuji za podstatné. Berte ho spíše jako úvahu na téma: Jaké opravdu zásadní chyby jsem při psaní udělal... a že jich bylo dost :-(

III. Hodně lidí si myslí, že je výhodnější používat Direct3D, protože v sobě standardně obsahuje podporu absolutně nejnovějších funkcí grafických karet. Jak je to ale s podporou vlastností, které OpenGL umí od samého počátku své existence?

IV. Každý asi ví, že se Direct3D vyvíjí převratnou rychlostí, Microsoft neustále uvolňuje jednu verzi za druhou, takže s největší pravděpodobností bude tato knihovna podporovat všechny převratné efekty nových grafických karet. V článku se tedy budeme orientovat především na OpenGL a jeho rozšíření (extensiony).

V. V jednom z předchozích dílů jsme se věnovali programátorskému hledisku práce v našich dvou knihovnách. Na toto téma nyní navážeme jejich architekturou, se kterou souvisejí další výrazné výhody a nevýhody.

VI. Jelikož náš seriál vychází na serveru, který se primárně zabývá Linuxovými technologiemi, zkusíme porovnat, jak snadno respektive obtížně lze přenést OpenGL a Direct3D programy do tohoto a dalších ne-Windows systémů. Dále se podíváme i na rychlost renderingu.

VII. V posledním díle seriálu, abyste neřekli, že Direct3D kritizuji jen já sám, uvedu citaci jednoho (téměř profesionálního) vývojáře her, který narozdíl ode mě, má s DirectX spoustu praktických zkušeností a asi ví, o čem mluví. Dále se podíváme na projekt Fahrenheit a stručně si popíšeme, jak se portují Windows programy do jiných systémů.

Knihovny jako OpenGL nebo DirectX nejsou pro uživatele až tak důležité, pro ně jsou to jenom dvě prázdná jména. Může jim být naprosto jedno, jak program uvnitř funguje. Návrh a hlavně celková použitelnost API je důležitá primárně pro programátory. Právě oni s ním pracují, nikdo jiný. V tomto díle budeme porovnávat především délku kódu, který se musí napsat, aby program něco udělal.

Nedávno vyšel na root.cz článek Linuxové hry (47): Unreal Tournament 2004. Jeho autor při popisu "Technické stránky věci" uvedl ne zcela šťastnou větu: Bohužel je vidět, že v oblasti 3D grafiky se OpenGL nemůže DirectX v kvalitě obrazu rovnat. a doplnil ji několika podrobnostmi. Pojďme se spolu podívat jestli je to pravda, nebo ten největší nesmysl, jaký kdy svět slyšel.

Na emailu se mi některé, většinou začátečnické, dotazy neustále opakují, jako příklad lze uvést problémy s knihovnou GLAUX a symbolickou konstantou CDS_FULLSCREEN v Dev-C++. Doufám, že tato stránka trochu sníží zatížení, ale pokud si stále nevíte rady, nebojte se mi napsat. Doufám, že nebude vadit, když sem umístím i ten váš problém.

Když jsem přibližně před půl rokem (podzim 2003) přecházel z MS Windows na operační systém Linux, měl jsem relativně velké potíže se zprovozněním OpenGL. Nejedná se sice o nic složitého, nicméně pro tehdy nic nechápajícího Woqa uživatele (analogie na Frantu uživatele :-) to byl naprosto neřešitelný problém.

Radomír Vrána mě požádal o radu, jak vypočítat průsečík dvou 2D přímek. Rozhodl jsem se, že mu místo obecných matematických vzorců pošlu rovnou kompletní C++ kód. Nicméně mi trochu přerostl přes hlavu, a tak vznikla kompletní třída přímky v obecném tvaru. Kromě průsečíku umí určit i jejich vzájemnou polohu (rovnoběžné, kolmé...), úhel, který svírají nebo vzdálenost libovolného bodu od přímky. Doufám, že tento můj drobný úlet nebude moc vadit :-]

Víte, vzpomněl jsem si na své začátky s OpenGL, kdy člověk nemohl sehnat téměř žádné informace o OpenGL, jednoduše proto, že žádné neexistovaly. To byl vlastně důvod pro překlady NeHe Tutoriálů a následný vznik tohoto webu. Informací je už nyní relativně dost, ale stále zůstala otázka: Kde začít?

Zobrazíme dětské OpenGL okno v dialogu a budeme mu předávat hodnoty získané z ovládacích prvků (editboxy a radiobuttony). Periodické překreslování OpenGL okna zajišťuje zpráva WM_TIMER - trojúhelník a čtverec budou rotovat.

FPS je zkratka z počátečních písmen slov Frames Per Second, která by se dala do češtiny přeložit jako počet snímků za sekundu. Tato tři písmena jsou spásou při spouštění programů na různých počítačích. Vezměte si hru, kterou programátor začátečník vyvíjí doma na svém počítači o rychlosti, řekněme, Pentium II. Dá ji kamarádovi, aby se na ni podíval a zhodnotil. Kamarád má doma P4, spustí ji a vše je šíleně rychlé. Díky FPS se toto nikdy nestane, na jakémkoli počítači půjde hra vždy stejně rychle.

Tento článek vychází z mých zápisků do matematiky z druhého ročníku na střední škole. Tehdy jsem moc nechápal k čemu mi tento obor matematiky vůbec bude, ale když jsem se začal věnovat OpenGL, záhy jsem pochopil. Zkuste si vzít například nějaký pozdější NeHe Tutoriál, bez znalostí 3D matematiky nemáte šanci. Doufám, že vám tento článek pomůže alespoň se základy a pochopením principů.

Už dávno jsem si chtěl naprogramovat vlastní šetřič obrazovky. Měl jsem sice třídu CScreenSaverWnd pro MFC, ale ta nepodporovala OpenGL. U NeHe Tutoriálu 38 jsem našel odkaz na šetřič obrazovky s podporou OpenGL, který napsal Brian Hunsucker. Chtěl bych mu poděkovat, protože na jeho zdrojovém kódu z větší části staví tento článek.