Dither DOOM

6.1.2018 16:46 | Přečteno: 3563× | Expresivní zabručení | | poslední úprava: 7.1.2018 13:44

Velmi dlouhou dobu mi lezla krkem samplovací nátura enginu hry DOOM (též známo jako idTech1). Textury samotné mají vcelku nízké rozlišení (64x64 a 128x128, pixelů jestli se dobře pamatuju) nicméně vzhledem k omezením dané HW té doby naprosto dostačující. Jenže stačí se přiblížit ke stěně a na obrazovce není nic jiného než obří pole kostek/pixelů. Což platí do dnešního dne.

To mi samozřejmě nedalo, stáhnul jsem si zdrojové kódy Legacy DOOMu a cca. rok zpátky jsem do toho začal rýt. Udělal sem si pár screenshotů a dneska jsem na ně narazil a vzhledem k tomu že mám v úmyslu promazat disk, tak se o ně podělím aspoň tady, ani mi zbytečně nehnijou na disku. Stejně jsem to chtěl udělat už dávno.

Engine

Samotné vykreslování je velice jednoduché. Starají se o něj dvě rutiny: R_DrawColumn_8(void) a R_DrawSpan_8(void) v r_draw8.c:

// ==========================================================================
// SPANS
// ==========================================================================

//  Draws the actual span.
//
//#ifndef USEASM //Hurdler: in tmap.nas the old func is now called R_DrawSpan_8a
// [WDJ] Boom func modified several times
void R_DrawSpan_8(void)
{
    // [WDJ] was ULONG=32bit, use uint_fast32_t which can exceed 32bit in size.
    register uint_fast32_t  xfrac;
    register uint_fast32_t  yfrac;
    register byte *dest;
    register int count;

#ifdef RANGECHECK
    if (ds_x2 < ds_x1 || ds_x1 < 0 || ds_x2 >= rdraw_viewwidth || (unsigned) ds_y > rdraw_viewheight)
    {
        I_SoftError("R_DrawSpan: %i to %i at %i\n", ds_x1, ds_x2, ds_y);
        return;
    }
#endif

    xfrac = ds_xfrac & flat_imask;
    yfrac = ds_yfrac;

    dest = ylookup[ds_y] + columnofs[ds_x1];

    // We do not check for zero spans here?
    count = ds_x2 - ds_x1;

     // [WDJ] note:  prboom has while(count)
    do
    {
        // Lookup pixel from flat texture tile,
        //  re-index using light/colormap.
        *dest = ds_colormap[ds_source[((yfrac >> flatfracbits) & (flat_ymask)) | (xfrac >> FRACBITS)]];
        dest++;

        // Next step in u,v.
        xfrac += ds_xstep;
        yfrac += ds_ystep;
        xfrac &= flat_imask;
    }
    while (count--);
}
//#endif USESASM

//  NOTE: no includes because this is included as part of r_draw.c
//
//-----------------------------------------------------------------------------

// [WDJ] Window limit checks have been added to all the callers of colfunc().

// ==========================================================================
// COLUMNS
// ==========================================================================

//  A column is a vertical slice/span of a wall texture that uses
//  a has a constant z depth from top to bottom.
//
#define USEBOOMFUNC

#ifndef USEASM
#ifndef USEBOOMFUNC
void R_DrawColumn_8(void)
{
    register int count;
    register byte *dest;
    register fixed_t frac;
    register fixed_t fracstep;

    count = dc_yh - dc_yl + 1;

    // Zero length, column does not exceed a pixel.
    if (count <= 0)
        return;

#ifdef RANGECHECK
    // [WDJ] Draw window is actually rdraw_viewwidth and rdraw_viewheight
    if ((unsigned) dc_x >= rdraw_viewwidth || dc_yl < 0 || dc_yh >= rdraw_viewheight)
    {
        I_SoftError("R_DrawColumn: %i to %i at %i\n", dc_yl, dc_yh, dc_x);
        return;
    }
#endif

    // Framebuffer destination address.
    // Use ylookup LUT to avoid multiply with ScreenWidth.
    // Use columnofs LUT for subwindows?
    dest = ylookup[dc_yl] + columnofs[dc_x];

    // Determine scaling,
    //  which is the only mapping to be done.
    fracstep = dc_iscale;
    frac = dc_texturemid + (dc_yl - centery) * fracstep;

    // Inner loop that does the actual texture mapping,
    //  e.g. a DDA-lile scaling.
    // This is as fast as it gets.
    do
    {
        // Re-map color indices from wall texture column
        //  using a lighting/special effects LUT.
        *dest = dc_colormap[dc_source[(frac >> FRACBITS) & 127]];

        dest += vid.ybytes;
        frac += fracstep;

    }
    while (--count);
}

V podstatě je to primitivní. Textury jsou připraveny v paměti (předpokládám že se načítají při načítaní levelu) a pak jsou do cílového bufferu kopírovaný řádek po řádku ve smyčkách s tím že se u nich uplatňuje dopředu vypočtená geometrie a paletové posuny (původní vanilla DOOM běžel v DOSu ve VGA módu 13h, tedy 8-bitové barevné hloubce s barevnou paletou) v závislosti na vzdálenosti od pozorovatele či aktivním power-upu. Stěny jsou vykreslovány od vrchu dolů, zem a strop zleva doprava. Jako poslední se přes ně vykreslý sprajty (Things). Celé se to překlopí do framebufferu a to je celý slavný DOOM. Dodám že původní rutiny psal John Carmack, musely být optimalizované a napsané v assembleru aby je zvládala i běžná tři-osum-šestka (tehdy běžně dostupný HW) a věřte nevěřte, jsou ve zdrojácích dodnes i když jen jako volitelný přepínač v době kompilace. A proto taky škálování textur ve hře je NNI.

Flip-Flop

První nápad byl přehazovat barvy z barevné palety o jednu barvu vedle při tom jak jsou rutiny pro vykreslování volané. Liché volání – barva zůstane taková jak má být, sudé volání – vykreslí se barva o jednu adresu navíc.

Jak je vidět, mnou navržený algoritmus je nevalné kvality, jednak protože místo rozumného ditheru kreslí spíš čáry a jednak protože barevné přechody mezi jednotlivými barvami v paletě jsou někdy tak malé že je to sotva postřehnutelné okem a přitom se kostičky nikam nevytratí. U čtvrtého obrázku jsem doufal že dostanu pěkný skybox, místo toho je sotva vidět nějaký rozdíl oproti klasickému vykreslování.

Naprostou kuriozitou jsou pak velmi temná místa kde už je barevný prostor tak malý, že temná místa mají furt jednu a tu samou barvu a hned vedle běžné palety je barevná paleta pro Invulnerability power-up (taková ta zelená koule která garantuje hráči nesmrtelnost na určitou dobu a přitom obrazovku zabarví do odstínu šedé a bílé barvy) a je jasně vidět že vykreslovač do ní šahá. Když nic jiného, je to aspoň zajímavé jako demonstrace toho jak flip-flop funguje.

Random number generator

Jak pravý staré známe pořekadlo: „Nejde-li to po dobrém, musí to jít po zlém“. A přesně podle něj jsem taky pokračoval. Přimo do vykreslovací rutiny jsem nacpal funkci rand(), trochu modulární aritmetiky a začal vybírat barvy z palety zcela náhodně! Výsledek je ten že to přidá do hry něco jako filmový šum (ve statických obrázcích to není vidět, ale když hra jede tak prostě i když hráč nic nedělá a stojí, obrazovka šumí jako starý zašuměný film ) a také to že je to šíleně náročné na procesor takže nic víc jako demonstrace to ani sloužit nemůže. V odborné hantýrce se tento druh šumu nazývá speckling, není to vůbec nic světoborného a aspoň pro demonstraci je to dobré:

U tohoto se mi potvrdily dvě věci, které jsem si už dávno myslel a sice:

• I pokud by se mi podařilo vymyslet sebelepší texturovací algoritmus, hra byla stavěná na to a vyloženě počítá s tím, že škálování bude probíhat metodou bodového samplování. Různé přepínače, lampy a polovina grafiky spoléhá na to že vykreslování bodů textur (texelů) je ortogonální a pokud ne, hrany některých textur budou rozmazané a nepěkné. Tomu by se dalo předejít nějakou maskou, která by specifikovala které hrany na textuře nechat tak jak jsou a dithrování by se týkalo jen vnitřku textury, jenže to považuji už za overkill a příliš náročné na implementaci než abych se tím zabýval.
• Barevná paleta je sílou a zároveň slabostí enginu samotného. U velmi temných míst je prostor mezi barvami tak strašně malý, že i kdyby byl vykreslovací algoritmus sebelepší, stejně bych se nezbavil úplně posterizace jak je vidět z posledního screenshotu. A nakonec. Ta mi zas až tak moc nevadí, takže proč si přidávat práci?

Unreal texture coordinate space dither

Na sklonku éry SW renderování, tedy těsně před nástupem hardwarově akcelerovaného vykreslování grafika ve hrách s něčím takovým bojoval každý. Velmi dobře bylo filtrování textur pořešeno v Unreal enginu (verze 1). To mělo nějakou formu ditheru (ono u těch těxtur, jestli se dobře pamatuju, toho bylo víc) který vypadal velice dobře a zároveň byl natolik rychlý, že plně polygonální modely a architekturu s dynamickým osvětlováním a veškerou herní logikou v pohodě zvládalo na procesoru vykreslovat Pentium s MMX. A věřte nevěřte Tim Sweeney byl takový sporťák, že se o tento zdařilý kousek podělil:

Unreal's software renderer uses an ordered "texture coordinate space" dither, which (at high enough resolution) looks almost like bilinear filtering.

The idea is simple: at each pixel, offset your texture u,v coordinates based on an ordered dither kernel (two 2x2 lookup tables, one each for U and V, indexed by the screen location (X&1),(Y&1), prior to texel lookup. My dither kernel looks something like this:

          (X&1)==0        (X&1==1)
         +---------------------------------
(Y&1)==0 | u+=.25,v+=.00  u+=.50,v+=.75
(Y&1)==1 | u+=.75,v+=.50  u+=.00,v+=.25

Bohužel Tim Sweeney nebyl takový sporťák aby za 20 let (bože už jsem starý, abych začal leštit rakev, že?) od prvního vydání hry vydal také odpovídající zdrojový kód. Engine byl použitý poprvé ve hře Unreal a později Unreal Tournament. Takže ač to vypadá zajímavě do dnešního dne vlastně nemám páru jak to sakra všechno implementovali. Ne že by teda měl nějakou povinnost to zveřejňovat, ovšem jak tak sleduju nejsem jediný kdo na ten kód už dvacet let čeká jako slepice na flus. Strašně rád bych viděl tohle filtrování právě v DOOMu.

Nakonec dodám, že má-li někdo lepší nápad na filtrovací algoritmus, rozhodně si ho nesyslete a nebojte se o něj podělit. Třeba právě v sekci s komentáři.

Edit: QZDoom

Poslední věc po kterou jsem zvažoval je použití vyšších bitových hloubek (funkce jsou v souborech r_draw16.c, r_draw24.c a r_draw32.c ovšem dodám že jsou momentálně nefunkční), jenže ono je to nakonec zcela zbytečné. Krom toho že je možné využít filtrovacích funkcí v OpenGL ze source portu GZDoom, je také možné využít funkcí SW renderování a to konkrétně v QZDoomu. QZDoom je fork portu GZDoom, konkrétně jeho softwarového renderu, ale s tím že je v něm dodělaná vyšší barevná hloubka a je tak u něj možné využít funkcí jako bineární filtrování nebo mipmap. Dodám že jako GL port je QZDoom s obtížemi schopen provozovat konverze jako Brutal Doom či Project Brutality. Nebo aspoň mně to funguje. A to bez toho aby to šáhlo na GPU. Jenže doporučuji prohlédnout screenshoty. Je to pouze důkaz toho, že na něco takového Doom nikdy nebyl stavěn. Veškeré hranaté objekty jsou krásně rozmazané, z krásných ostnatých Impů jsou jakési nasrané rozmazané fleky a texty jsou absolutně nečitelné. Jako bonus je to velmi náročné na prostředky a můžete zapomenout na to že něco takového spustíte pod DOSem protože ten funguje pouze pod VGA paletou. Prostě málo „Old-School“. Proto mě to taky moc nezajímá.

       

Obrázky

Komentáře

[Kvakor]

Myslím, že největší problém při použití čehokoliv jiného než bodového samplování je existence palety, protože cokoliv, co by bylo shopné (teoreticky) dodat hezčí výsledek, musí operovat v nějakém barevném prostoru a zase to převést zpět, což by ve výsledku bylo dost složité (musela by se hledat nejbližší barva v paletě) a hlavně by to nejspíš vypadalo hnusně (jak bylo řečeno, paleta není rovnoměrně rozložená v RGB krychli)..

Jediná metoda, která by snad šla použít, je snad jen chybová difuze, která je relativně jednoduchá na implementaci a dá se to dělat kompetně celočíselně. Vlastně je to jen chytřejší verze metody flip-flop. Nevýhodou bude to, že to bude vypadat dobře jenom v místech, kde dva body textury mají podobnou barvu, v okamžiku, kdy tam bude např. přechod černá-bílá, bude to vypadat velmi rušivě, podobně jako na pátém obrázku.

Řešení by bylo použít tabulku kombinace dvou barev, respektive indexů do palety, která by říkala, jestli pro dannou kombinaci použít dithering nebo nechat defaultní bodového samplování. Sice by ta tabulka byla docela velká (256x256, tedy 64KB), ale počítat to v reálném čase by při dneší velikostí cache nemělo nejspíš smysl.

Na všechno ostatní by asi bylo třeba převést výstup do truecolor a paletu emulovat, ale mám pocit, že minimálně jedna odvozenina Dooma už přesně tohle dělá ...

[Grunt]

Heh, na jaderného fyzika je vždycky spoleh

Na všechno ostatní by asi bylo třeba převést výstup do truecolor a paletu emulovat, ale mám pocit, že minimálně jedna odvozenina Dooma už přesně tohle dělá ...

Zprvu dodám, že o QZDoomu vim. Dopsal jsem to do zápisku. Když by byl dither ideální a rozlišení dostatečné, přesně nějak takhle by to vypadalo (viz screenshoty naspodu). A proto taky o to nijak nestojím. Ty textury jsou moc malé na to aby se na ně aplikoval bilineární filtr a vůbec do hry nezapadají. Dither z Unrealu pamatuju a vypadal moc dobře u rozlišení 320x240. Proto tomu taky věřím víc. Navíc správně provedený dither který jen šoupe s barvama již použitých textur/jejich texelů by nijak neměnil PLAYPAL, takže hodně, hodně, hodně teoreticky by to mohlo být schopné i běhu v DOSu při rozumné zátěži.

Jediná metoda, která by snad šla použít, je snad jen chybová difuze, která je relativně jednoduchá na implementaci a dá se to dělat kompetně celočíselně. Vlastně je to jen chytřejší verze metody flip-flop.

To jsem taky původně chtěl, konkrétně Floyd–Steinberga (ale asi jen jako demonstraci protože by to bylo moc náročné), jenže nemám páru jak to implementovat. Pokud bych šel pixel po pixelu a kvantoval je bokem ukládal přebytky, tak budiž. Ale ta rutina nic takového nedělá. Jen se nějak vypočítá škálovací funkce, o tu se roztáhne textura a ta se pak už jen kopíruje do *dest a inkrementuje se frakce (frac += fracstep;). Viz. Kopíruje se to po sloupcích a jak je jeden zkopírovaný už se na něj nesahá a další sloupec ani neví co bylo ve sloupci před ním. Ideální pro DMA, ale jak na to pustit dither netuším. Navíc mám strach že náročné výpočty pixel po pixelu by to neúnosně zpomalily.

Nevýhodou bude to, že to bude vypadat dobře jenom v místech, kde dva body textury mají podobnou barvu, v okamžiku, kdy tam bude např. přechod černá-bílá, bude to vypadat velmi rušivě, podobně jako na pátém obrázku.

Toho jsem si vědom. Proto jsem taky mluvil o masce. Dither by jinak nebyl jen na hranách sektorů ale jinak úplně všude. Ale nějak se tím nezabývám. Dneska už stejně nemá smysl něco takového dodělávat.

[R]

Unreal engine na to ma "detail textures". Ak si dostatocne blizko, tak cez povodnu texturu sa namapuje este druha s jemnym zrnitym povrchom. Ale tu by to asi vyzeralo divne, Unreal ma aj zakladne textury vo vyssom rozliseni.

[Heron]

No čéče ale tohle fungovalo snad jen na Glide. Na ostatních rendererech to mělo mipmap, ale i tak, když byl člověk hodně blízko stěny, tak to bylo rozplizlé, ale na glide se k tomu přidala ještě další detailnější textura (ovšem ne z mipmapu, ale to byla textura drobných prasklin apod.).

[R]

Funguje to aj na OpenGL a Direct3D (hraval som to na Rage 128 a Radeone 9100), len sa to musi zapnut v advanced settings. Akurat tam bol nejaky bug, ze to v niektorych momentoch sposobovalo velky pokles FPS.

[Bedňa]

Tie FPS padali na Quake engine pokiaľ viem. To bolo po rokoch odstránené pretože sa prišlo na to že sa to tam nejak posralo a prenášalo sa dvakrát viac údajov ako bolo treba.

Hrával som aj DOOM, ale Quake je Quake a podnes sa na Quake3 engíne hry vyvíjajú a sú lepšie ako niektoré dnešné vyhlasné AAA pecky.

[R]

Quake (1, 2 ani 3) som nehraval, z DOOMu som presiel na Unreal. Uchvatili ma tam hlavne velke exteriery s prirodou, voda, ale aj hudba meniaca sa podla situacie a zvukove efekty (napr. ozvena v jaskyni). Omnoho realnejsie ako Quake.

[Bedňa]

Quake má naozaj slabú zvukovú časť aj s poteraz neodstránenými bugmi.

Mno počas toho vývoja sme si našli frajerky, manželky, narodili sa deti a podnes mám na mnohých kontaky a sem tam si zavoláme. Je to proste srdckovka. Kurňa mám chuť si zapnúť nejakú Quakeovinu :)

[Grunt]

Přílohy:

• ulltrahd_1.png (347210 bytů)
• ultrahd_2.png (644150 bytů)

Jo. O tom sem taky mluvil a zrovna tohle by Doom využil skvěle. Díky tomu že jsou dostupná větší rozlišení vypadají textury v GL portech strašně. Řešení? UltraHD Pack. Jenže problém je že navzdory obrovské velikosti vypadá při pohledu z větší dálky ještě hůř. Já když jsem ho poprvé nainstaloval jsem hledal který WAD jsem přepsal nebo co jsem vlastně udělal špatně. Nic. Takhle blbě to prostě vypadá standardně. Proto také nejsem fanoušek takových řešení.

[Heron]

To filtrování máš vypnuté schválně?

Jak z blízka, tak z dálky se mi to zdá celkem ok:

01

Nelíbí se mi ta barva, ale jinak to vypadá jak tráva:

02

Detailní textury to celkem má, ale evidentně problém se zarovnáním:

03

A některé detaily jsou úsměvné :D

04

[Grunt]

To filtrování máš vypnuté schválně?

No dobrý a teď si to pusť v SW renderu. Proto říkám vyšší rozlišení automaticky neznamená vyšší přidanou hodnotu. Ty původní textury (opravdu mají různé rozlišení) vypadají dobře a chybí jim maximálně nějaká vrstva detailů podobně jako to měl Unreal.

[Heron]

No dobrý a teď si to pusť v SW renderu.

Ok, beru. Sice mi to přijde jako trochu umělá podmínka, ale ok, nemám nic proti.

[Grunt]

Přílohy:

• Unreal_smoothfalse1.png (586685 bytů)
• Unreal_smoothfalse2.png (338806 bytů)
• Unreal_smoothtrue.png (861705 bytů)

Tak jsem se prohrabal tunou prachu (jsem se normálně musel jít osprchovat) a různých placek z minulosti a našel to! Rozmlácený obal, popis 980517_1247 (dá se zjistit kdy bylo CD vyrobeno? Protože ty soubory na něm opravdu mají jako datum vytvoření 17.5.1998 a některé ještě starší) no furt to funguje! Verze číslo 200 jak malovaná.

Unreal ma aj zakladne textury vo vyssom rozliseni.

To vůbec není pravda. Samotný engine zvládne textury až do rozlišení 1024x1024 (v SW, např. 3dfx módu zvládla ta grafika načítat textury maximiálně v 256x256 a mohly se tak jevit "blury") pixelů, ale původní herní textury mají rozlišení 128x128 a 256x256 a jsou 8-bitové! Zbytek je pouze výsledek dobrého enginu. Stačí vypnout TextureSmoothing a jsme tam kde jsme chtěli být. Akorát samozřejmě v polygonech místo BSP stromu na rozdíl od Doomu. Viz screenshoty.

Zdroj zde a ověřil jsem si to i v UnrealEditoru, fakt mají 256x256.

Unreal engine na to ma "detail textures". Ak si dostatocne blizko, tak cez povodnu texturu sa namapuje este druha s jemnym zrnitym povrchom.

Též si to pamatuju. Ale zaboha to nemůžu zapnout. Nebyla to fíčurka třeba jen v 3dfx Glide nebo PowerVR SGL módu? Jako v menu cosi je, i v Edu je nějaká kategorie s "Detail Textures" ale fakt nevím jak to zapnout.

Ale tu by to asi vyzeralo divne

Přesně naopak. Je až s údivem co všechno může SW render zvládnout.

[kvr]

Unreal je o něco novější a flexibilnější.

Doom byl v podstatě dost jednoduchý, renderování podlahy horizontálně a zdí vertikálně zcela eliminovalo nelineární nárust koordinátů v textuře vzhledem k pozici na obrazovce. Pokud se nemění vzdálenost textury od obrazovky, tak vzdálenost bodů na obrazovce odpovídá vzdáleností bodů na textuře.

Tohle pro pozdější enginy už neplatilo, ty všechno renderovaly po řádkách, takže se přepočítaval nárůst koordinátotů každých osm či šestnáct bodů (bylo tam navíc drahé dělení na FPU) paralelně s renderingem apod. Výhoda textur 64x64 byla, že se daly přičítat x a y zároveň a jednoduše useknout horní dva bity, které mohly přetéct. Což spíš eliminovalo nedostatek registrů na x86 než že by se ušetřily dvě aritmetické operace Quake měl myslím cenu 7 taktů tehdejšího procesoru na bod.

Nedivil bych se, kdyby to překrývání (nebyly to spíš lightmaps?) byly už primárně na grafikách, s omezením x86 už tyhle pokročilé operace byly dost drahé...

[Grunt]

Přílohy:

• multitexture.jpg (102756 bytů)
• unrealed_det.png (156209 bytů)

Unreal je o něco novější a flexibilnější.

Nicméně se musím omluvit, protože stále pro vykreslování mapy využívá staré dobré BSP + vertexovou geometrii pro modely.

Nedivil bych se, kdyby to překrývání (nebyly to spíš lightmaps?) byly už primárně na grafikách, s omezením x86 už tyhle pokročilé operace byly dost drahé...

Je tomu skutečně tak. Stáhnul jsem si nejnovější patche které přidají možnost vykreslovat v Direct3D a OpenGL a v jejich menu se dají tyhle "Detail Textures" zapnout a skutečně fungují. Přísahal bych že jsem to viděl v Softwarovém renderování, no ale asi ne (přitom si nepamatuju že bych kdy vlastnil nějakou Voodoo nebo S3, ale očividně jsem někdy v historii musel). Bohužel dle UnrealEdu je to jen pár opakujících se malých textur, které nejsou nijak s podkladovou texturou korelované (viz screenshot).

Škoda, protože tohle by bylo v Doomu naprosto perfektní. Nižší frekvence původní textury ze hry takže při pohledu z dálky by to nijak nekazilo dojem a paletu z původní hry a pro vyšší frekvence nějaký UltraHD Pack, takže by byly z blízky vidět detaily textur a přitom blendingu pro určitou plochu by to ani nebylo vůbec náročné na prostředky. To zas mám promyšlené, že? Teď to už jen implementovat

[R]

Detail textures sa zapinaju v nejakom tajnom advanced menu. Aspon v Unreal Tournament to tusim bolo, v povodnom Unreali tusim ani nie.

Inak v konfiguraku: [OpenGLDrv.OpenGLRenderDevice] DetailTextures=True

[Grunt]

No to je i pro SW render ale mám to ve výchozím nastavení zapnuté

[SoftDrv.SoftwareRenderDevice]
DetailBias=0.000000
FastTranslucency=False
LowResTextureSmooth=False
HighResTextureSmooth=True
DetailTextures=True
FullMeshRendering=False

a nikde nic, takže si nemyslím že to bude zrovna tahle volba.

[R]

Podla mna to SW renderer nepodporuje.

[Heron]

Wau. Tak takhle ty se bavíš

Textury samotné mají vcelku nízké rozlišení (64x64 pixelů jestli se dobře pamatuju)

Wall textury mají na výšku přesně 128px a není to tak jednoduché. Textura se může skládat z více "vrstev" (upřímně řečeno, nevěnoval jsem tomu zase tolik času, abych se vyznal ve všech těch lumpech a patches - naivně jsem čekal, že to bude, pro úsporu výkonu, uloženo prostě jako indexovaná bitmapa - ale zřejmě museli i značně šetřit místem), a každá z nich může mít jinou barvu. Po těch letech mě pořád nepřestává fascinovat, jak to na svou dobu bylo promakané a na jakých prostředcích to běželo.

Veškeré hranaté objekty jsou krásně rozmazané, z krásných ostnatých Impů jsou jakési nasrané rozmazané fleky a texty jsou absolutně nečitelné.

No pozor. To záleží na nastavení. GZDoom umí vypadat i ve vysokém rozlišení naprosto fantasticky, ale je potřeba si s tím pohrát (trilinear, 16x aniso, HQx4 scaler, 32x multisample). Jasně, potřebuje to asi tak miliardkrát víc prostředků, než původní doom, ale vypadá to skvěle a rozhodně to nemusí nutně působit rozmazaně.

Dokonce tak skvěle, že jsem se v létě bavil extrakcí textur z mapy Scythe2, protože jsem odmítal uvěřit, že to je wall textura v 128px rozlišení. A je.

Jako jistě, on je to trochu podfuk, protože z původního dooma tam už jsou jen ty textury a mapa. Na rámec toho tam jsou 32b barvy, bloom, ambient occlusion, dynamic light apod. podlé triky, které z toho vytahují zase něco mnohem navíc. Ale je fascinující, že z takhle starých zdrojů toho lze tolik vytěžit.

[Odin]

S prihlednutim k autorovi tohoto blogpostu je s podivem, ze jsem byl timto potesen. Doom jsem si za relativne mladych let obcas zahral, takze ma blogpost tento pro mne trochu nadech jiste nostalgie. Sice nevidim smyslu v modifikaci herniho engine a snaze vyhlazovat textury u takto stare hry, ale i tak dekuji za zajimave cteni.

[Grunt]

Sice nevidim smyslu v modifikaci herniho engine a snaze vyhlazovat textury u takto stare hry, ale i tak dekuji za zajimave cteni.

Sice starý engine, nicméně dokazuje stále jedno pravidlo: S mírnými modifikacemi (ať už jde o herní typu Brutal Doom, tak nějaké menší grafické vylepšení) stále válcuje po téměř třiceti letech všelijaké Áčkové tituly (Cokoliv od Ubisoftu, Call of Duty, apod.) a není rovnítko mezi vysokým rozpočtem a úspěšnou hrou. Spíš naopak. Původní Doom udělala hrstka lidí (jádro se skládalo ze čtyř) za zlomkový čas toho co se dnes pere do obrovský projektů a přesto se na něm po třiceti letech pracuje a stále se vylepšuje (byl tak prostě vymyšlen, kód byl uvolněn pod GPL). Já hry nehraju (občas mrknu na nějaký walkthrough, jinak nemám čas ani náladu), ale nainstaloval jsem si Brutal Wolfenstein a musel jsem to smazat, protože bych u toho zase zakysl na spoustu hodin. Proto ta snaha o vylepšení toho co mě na původním enginu štvalo.

[ehm]

Sice starý engine, nicméně dokazuje stále jedno pravidlo: S mírnými modifikacemi (ať už jde o herní typu Brutal Doom, tak nějaké menší grafické vylepšení) stále válcuje po téměř třiceti letech všelijaké Áčkové tituly (Cokoliv od Ubisoftu, Call of Duty, apod.) a není rovnítko mezi vysokým rozpočtem a úspěšnou hrou. Spíš naopak.

Mohl bys to válcování nějak upřesnit? Třeba v obchodní rovině staré enginy neválcují určitě vůbec nic. V počtu hráčů taky ne. Subjektivní žebříček hodnocení, kde by se DOOM I umístil nad moderním A titulem, samozřejmě může sestavit kdokoliv, ale lidí, kteří to tak vidí, je naprostá minorita. Ve starších věkových skupinách ten podíl může být vyšší, protože tam „do hry“ vstupuje nostalgie.

[Agent]

Mě třeba připadá, že současné AAA tituly jsou většinou vytvářeny pro 15leté napůl retardované deti. Obtížnost není moc vysoká, ani v průběhu hry se nezvyšuje, je to často repetitivní. Prostě pro co nejširší masy.

[ehm]

Tu nepříliš vysokou obtížnost vyvozuješ z čeho? Např. CS:GO je s odhadovanými 25 miliony prodaných kopií jednou z nejprodávanějších her vůbec a je ve všech ohledech těžká, vyžadující zkušenosti a trénink. Totéž platí o LoL, aktuálně frčícím PUBG a dalších.

[Fluttershy, yay!]

Meh, newfags.

1.6 or gtfo

[ehm]

stfu noob cука блять!

V 1.6 jsem jednou hrál přátelský zápas na Infernu proti lidem z eSuby. Dal jsem frag. :>

[Bedňa]

1.6 or gtfo

Kempovica a chýbajúci teamwork. Hrozne pomalé. V Enemy Territory bol top team work, v Urban Terrore zas najrýchlejšia akcia a zápas 5v5 skončil aj za pár sekúnd.

ET má aj po ja už neviem asi 15 rokoch stále aktívne ligové/pohárové zápasy, hoci to 2017 začalo upadať, prv nebol deň bez niekoľkých zápasov.

Na ET sa stále maká. Málo ktorý deň je bez nejakej opravy nového enginu a game play.

A toto si v CS nikdy nezažil, treba si pridať hlasitosť a vychutnať si

atmosféru. Challenge

[Fluttershy, yay!]

najrýchlejšia akcia

<doplň vtip o předčasné ejakulaci>

A toto si v CS nikdy nezažil, treba si pridať hlasitosť a vychutnať si

3mlg5me

[Bedňa]

Njn extra akcia.

To som si fat zrovnal Trabanta s Ferarri a fat mi to vyšlo na stejno.

[Bedňa]

Timinig

[Agent]

Tu nepříliš vysokou obtížnost vyvozuješ z čeho?

Třeba Alan Wake mi takový připadal. Podobně poslední GTA, jen jsem jej zkoušel asi 4 hoďky, mi přišlo jako vyhypované, naleštěné, pozlátko. Nějaké mise nejsou špatné, ale často je to na jedno brdo, někam vlezu, pokosim co se dá i nedá a jdu dál. Obtížnost střední.

Just Cause 3 z podobného soudku. Brzy začlo nudit.

Např. CS:GO je s odhadovanými 25 miliony prodaných kopií jednou z nejprodávanějších her vůbec a je ve všech ohledech těžká, vyžadující zkušenosti a trénink.

Tak to mě jedině těší. Snad to ještě neni s lidma tak špatný jak jsem si myslel.

[Grunt]

Můj názor je že se současná situace hodně blíží krachu z třiaosumdesátého. Nacpou se do toho obrovské prachy a pak se dějou všelijaké divy jenom aby se ty prachy (aspoň) vrátily. A pak vznikají divy jako Aliens: Colonial Marines apod. O nějaké kreativitě se dá mluvit tak maximálně na indie scéně.

[Heron]

A pak vznikají divy jako Aliens: Colonial Marines apod.

Tak ono je hlavně hodně poučné si najít něco o tom, proč se tak stalo. Prostě to byla zakázka jako mnoho jiných, spoléhalo se na to, že spojení Alien, Gearbox, Sega bude "prostě stačit" a všichni k tomu tak přistupovali (proč se snažit, máme dobrou značku). Nehledě teda na to, že to měli od počátku na druhé koleji a jako méně prioritní projekt. Jinak to v podstatě dopadnout nemohlo.

O to lepší půdu to potom připravilo pro Alien Isolation, které všem ukázalo, že taková hra se dá udělat i úplně jinak.

A v tom je podle mě odpověď. Občas někdo něco poměrně důkladně zvoře a tím připraví půdu pro něco mnohem lepšího. Stejně jako DOOM (2016) všem ukázal, že i po 30 letech stříleček, kde to bylo už v podstatě ustrnulé, lze udělat něco nového a, co člověka donutí hrát zase trochu jinak (viz třeba to, že mnoho her implementuje autohealth a hráče nutí se skrývat, dokud se nevyléčí - v doomu se s tím daleko nedostanete, tam je potřeba jít do boje agresivně a získávat tak zdraví z potvor).

Teď dostala přes držku EA (která si o to koledovala už hodně dlouho) a některé firmy se od tohoto jednání budou mít potřebu distancovat. Tak uvidíme, s čím přijdou. Pro hráče jedině dobře.

[Grunt]

Tak ono je hlavně hodně poučné si najít něco o tom, proč se tak stalo. Prostě to byla zakázka jako mnoho jiných, spoléhalo se na to, že spojení Alien, Gearbox, Sega bude "prostě stačit" a všichni k tomu tak přistupovali (proč se snažit, máme dobrou značku). Nehledě teda na to, že to měli od počátku na druhé koleji a jako méně prioritní projekt. Jinak to v podstatě dopadnout nemohlo.

20th Century Fox to přehodil na SEGu (v naději že když nemají už nic jiného tak aspoň jméno), SEGA to přehodila na Gearboxu, Gearbox to přehodil někam do indie nebo bůh ví na koho, ale ještě mimo to si dali práci s CGI demem pro E3. A Randy Pitschford k tomu přidal jakože herní komentář. To je celé. Všichni vyfakturovali, vydavatelé vydali, ztráta se vrátila a pak jim přistála na stole žaloba. Úplně stejně to dělá i Ubisoft (z hlavy mě napadá Watch Dogs, The Division nebo Rainbow Six Siege) a jen čekám kdy se začne s bojkotem toho.

Mimo jiné je to ukázka toho jak stupidní je systém s licencemi na dílo, protože i když se to moc neví při vývoji Dooma kontaktoval idSoft 20th Century Fox (bylo to těsně po úspěchu Wolfenstaina 3D) právě s tím že by chtěli udělat Vetřelce v jejich novém enginu. Romero je slušně odmítl, protože by nad dílem ztratili kreatviní práva a místo vetřelců implementovali démony.

Stejně jako DOOM (2016) všem ukázal, že i po 30 letech stříleček, kde to bylo už v podstatě ustrnulé, lze udělat něco nového a, co člověka donutí hrát zase trochu jinak

Doom (4) měl vypadat jak Call of Duty. Předpokládám že zásluhu na tom jak vypadá dnes má Brutal Doom.

Teď dostala přes držku EA

O čem je řeč? Zase mi něco uniklo?

[Fluttershy, yay!]

Teď dostala přes držku EA

O čem je řeč? Zase mi něco uniklo?

Předpokládám, že Battlefront 2.

Viz

The intent is to provide players with a sense of pride and accomplishment for unlocking different heroes.

Ale pochybuju, že „EA dostala přes držku.“ Jejich byznys model je krajně nepopulární už dlouho a nízkoinformační zákazníci to přesto žerou.

Nakonec, kam směřuje Konami? Vedle Treatment of [ex]employees viz především reference na pačinko a pačislot.

[Grunt]

pačinko a pačislot

Nejhorší je když to ani není v mém jazyce a přesto tomu rozumím. Chupopopo…

[Fluttershy, yay!]

weeb

[Grunt]

…se zrovna ozval, že?

[Heron]

O čem je řeč? Zase mi něco uniklo?

Asi ano. Viz třeba https://www.youtube.com/watch?v=h03EY02y2WE (a dalších mnoho videí na toto téma). Prostě EA "vylepšila" mikrotransakce do takové míry, že se z toho stalo nelegální sázení (nebo něco takového) a to do takové míry, že si toho všimly i vlády mnoha zemí a tak trochu to zakazují. Podobný takový problém, ale zatím v menším, má i Bungie (Activision) a nějak se toho nehodlají vzdát.

A Randy Pitschford k tomu přidal jakože herní komentář.

Ale zase to umí docela okecat. (Sorry za odkazy na stále stejný kanál, nějak jsem si jej loni oblíbil.)

Doom (4) měl vypadat jak Call of Duty.

Ano měl, ale z toho bych si mnoho nedělal, mnoho her mělo vypadat úplně jinak. (Třeba mimochodem jedna z mých nejoblíbenějších a nejvíce zapomínaných her jako je FEAR - už jen ta kombinace japonského hororu, asijských bojových umění, akčních filmů, paranormálna a scifi zní jako naprosto šílený guláš, ze kterého nemůže nic být, ale bylo to jedno z největších překvapení té doby). A Doom vypadá jinak taky proto, že nějaká COD střílečka docela dost propadla. Jinak teda musím popravdě říct, že mě se nový doom až tak úplně nelíbí a v některých místech mi to přišlo až moc asijské. Já přece jen mnohem víc rád tu démonickou mytologii, do měly ty první (ostatně, můj avatar, že).

[Heron]

No a to nejpodstatnější mi mezi těma dvěma rebooty abclinuxu (někdo updatoval jádro?), vypadlo.

Předpokládám že zásluhu na tom jak vypadá dnes má Brutal Doom.

Ano, podobnosti se nedají upřít. Brutal Doom jde mnohem dál a tady zase vidím negativní vliv různých "hodnotících komisí". Prostě brutal doom je mnohem brutálnější v tom nejlepším slova smyslu než doom 2016 (třeba tohle se vyloženě nabízelo). V Brutal Doomu je mi těch potvor občas i líto, protože tam autor zapracoval i to, že ta potvora něco cítí (teda přinejmenším bolest). Prostě mají o jakýsi rozměr navíc. V doom 2016 fakt ne.

[Kate]

Ono to možná chce přestat si vybírat AAA tituly pro děti :) Nemyslím si že třeba Deus Ex je nějaké ořezávátko a běžný hráč tehdejšího dooma by se nejspíš rozbrečel frustrací z tisící a první smrti v Dark Souls.

[Agent]

Tak Deus Ex je už skoro 20 let tomu nazad, to se ještě nedělali hry jen pro děti. Takže to se moc nepočítá, tedy počítá, ale ne jako argument proti mému názoru.

[Heron]

Poslední Deus Ex vyšel v roce 2016.

[Kate]

Přesně. A přestože mě do děje nevtáhl tolik jako předposlední, rozhodně bych neřekla že šel obtížností nějak dolů oproti prvním dvěma dílům. Hrála jsem je taky nedávno, tak snad srovnání mám :)

[Heron]

Ano. Já bych první DeusEX určitě neoznačil za těžkou hru. Poslední díl Mankind Divided podle mě herní mechanikou úspěšně na tu jedničku navazuje a ta obtížnost mi přijde dost podobná.

[Kate]

Jde i o styl hry… Já to celé procházím kompletně stealth a ač se tím dost sníží pravděpodobnost úmrtí, projít to celé bez zpozorování je docela výzva :)

[kvr]

Nestačilo by pro random použít něco mnohem jednoduššího - třeba pole osmi barev (rozdílů), které by se deterministicky aplikovaly při vykreslování? Výhody:

• Rychlejší než random.
• Konsistentní při statickém obraze, eliminace šumu.
• V MMX snad relativně jednoduchá aplikace (odečtení a přičtení barevných složek, navíc potenciálně na pole).

To pole rozdílů barev by se dalo případně měnit při změně úhlu, ale ani to by asi nebylo nutné...

[Grunt]

Příloha:

• flip_flop_2.png (116559 bytů)

Jenže to bude vždy stejné pro všechny sloupce, korigováno o pozorovací úhel. Popravdě mi to nedalo, vyhrabal sem zdrojáky a trošku předělal Flip Flop a to následovně:

 do
    {        
	// Re-map color indices from wall texture column
        //  using a lighting/special effects LUT.
 
	dc_ssrc = (frac >> FRACBITS) & 127;
	if(count&1)
	  dc_ssrc = ((frac >> FRACBITS)) & 127;
	else
  	  dc_ssrc = (((frac >> FRACBITS) + 1) & 127);

	*dest = dc_colormap[dc_source[dc_ssrc]];

        dest += vid.ybytes;
        frac += fracstep; 

    }

Už potřebuju jen nějak přehazovat pixely ze sousedních texelů i mezi sloupci. V tom je trošku problém, protože v samotné rendrovací smyčce (R_RenderSegLoop() v r_segs.c) je to implementované velmi jednoduše:

dc_source = R_GetColumn(midtexture,texturecolumn); kde proměnná texturecolumn se inkrementuje jak se renderovací smyčka projíždí a vždycky nastaví dc_source na první texel textury. Pak už to jen volá colfunc() a kreslí se sloupec a mezi sousedními texely se přehazuje velmi špatně. Ale předpokládám že by to asi nějak jít mělo.

Zdrojáky Legacy DOOMu jsou hrozný bordel. Vůbec se v tom nevyznám. Budu muset stáhnout Carmackovi zdrojáky a projít ty, abych to pochopil. Ty by měly být docela čitelné.

třeba pole osmi barev (rozdílů), které by se deterministicky aplikovaly při vykreslování?

Hodně štěstí. Některé barvy v paletě vůbec odstíny nemají. Přehodit barvu na další nebo předchozí textel je velmi jednoduché, když se ale přičte nebo odečte něco od barvy, klidně ji to kompletně přehodí (nejoblíbenější je zelená) a dělá to pak velmi zajímavé efekty.

[Grunt]

Příloha:

• paleta.png (127270 bytů)

Heh, jak říkám. Některé odstíny to docela podchytí, ale jiné barvy mají hned vedle sebe zelenou Ta je nejoblíbenější.

[kvr]

Hodně štěstí. Některé barvy v paletě vůbec odstíny nemají. Přehodit barvu na další nebo předchozí textel je velmi jednoduché, když se ale přičte nebo odečte něco od barvy, klidně ji to kompletně přehodí (nejoblíbenější je zelená) a dělá to pak velmi zajímavé efekty. Heh, jak říkám. Některé odstíny to docela podchytí, ale jiné barvy mají hned vedle sebe zelenou Ta je nejoblíbenější.

A jo, zapomněl jsem, že Doom je osmibit. MMX/SSE má na tohle funkce (přičtení/odečtení barvy po složkách s eliminací přetečení). Barva by se musela nejdřív zkonvertovat, upravit a zase zpátky. A nebo jednodušeji celé převést na 24-bit RGB

PS: Řekl bych, že je spíš zelená nejvíc vidět