|
|
|
|
 Diskusn boardy |
|
|
|
|
|
Najnovie lnky |
|
Automatická textová správa
Vocko  Tutoril 
07.06.2009 : 11:02:12
|
 V tomto tutoriále si spravíme automatickú textovú správu, ktorá sa prehraje vždy s nejakým zvukom. |
|
|
|
|
|
Env_mirror alebo zrkadlenie modelov
Vocko Tutoril 
24.04.2009 : 18:49:30
|
 Tutoriál na zrkadlenie tu už je, ale èo ak chceme odráža i modely? Na tom nám poslúži entita env_mirror, ktorá sa nachádza iba v Spirite 1.4 alebo novšej verzii. |
|
|
HL2 : Obloukový prùchod
R4z0r Tutoril
01.05.2008 : 05:48:46
|
 Dnes si ukážeme zpùsob, jak vytvoøit elegantní obloukový prùchod, bez nutnosti používat øezání geometrie brushem... |
|
|
|
|
|
Pridanie mp3 do spiritu
NICKSss Tutoril
02.03.2008 : 20:55:09
|
Návod na pridanie mp3 do Half-Life 1 alebo Spirt 1.2,otestované na verzii 1.2.
Asi už mate zbrane add-ons vo Spirite 1.2 a nechcete prejst na ver.1.4 lebo všetko stratite
pre Mp3... Na internete som našiel návody pre HL1 a po anglicky ktoré po skompilovani
fungovali asi takto : Aplikácia HL.EXE Neodpovedá...  |
|
|
*locus
Deli Tutoril
22.02.2008 : 20:13:47
|
 Pre niektorých mapperov neznámy pojem, ale pre niektorých ve¾mi úèinná pomôcka.
Vïaka tomuto príspevku sa vám posnažím priblíži tajomstvá jednej z najväèších zbraní spiritu.
|
|
|
Spirit of Half-Life - Predstavenie
Wizz Tutoril
27.10.2007 : 08:52:04
|
 Predtým než sa pustíte do èítania, chcel by som Vás upozorni že èlánok už nemusí by 100% aktualny. Èlánok som totiž napísal ešte za svojich mladých èias - 13. júna 2004, èo je viac ako tri roky. Zverejni som sa ho rozhodol po nátlaku a výhražkach ostatných redaktorov  |
|
|
|
|
Veľký sprievodca enginom HalfLifu
Jackar [10.03.2004 : 20:23:58] 96 Tutoril
tan : 5834
Priemern znmka : 1.73 |
Najprv by som rád povedal pár viet na začiatok. Tento článok vychádza z mojich dlhoročných skúsností, pobytoch na rôznych fórach a tonami prečítaného materiálu. Nie je to žiaden preklad niečoho čo už existuje, ale môže sa stať že určité princípy tu popisujem veľmi podobne ako niekto iný niekde inde. To viete, podvedomie sa nezaprie ...
r_speeds
Takže najrpv by som vám mohol vysvetliť čo to vlastne tie "r_speeds" sú.
Samo o sebe je r_speeds príkaz v HalfLife, ktorý vám počas hrania ukazuje rôzne údaje ako fps, počty polygónov atp... Najhlavnejší údaj pre mappera je wpoly - počet polygónov solid objektov, tj. všetky steny a brush_entity. Druhý dôležitý údaj sú epoly - počet polygónov všetkých bodových entít, teda hlavne modely, ale aj sprity, beamy atd... A to wpoly sa "ľudovo" označuje za r_speeds, takže ak vám niekto povie že mapa má vysoké r_speeds, tak to znamená že má veľa wpoly = slabší výkon enginu.
Popíšme si teda ešte raz a presnejšie kolonku r_speeds (viz. obrázok):
Počet framov - fps, počet snímkov za sekundu. Čím väčšie číslo, tým je hra plynulejšia.
Čas herného cyklu - Engine má svoj vlastný "takt" teda vykoná jednu hernú operáciu za jednu časovú jednotku. Tento údaj zobrazuje danú časovú jednotku v ms.
Teda napr. ak chcete otvoriť dvere, tak po cykloch sa koná - button_pressed - door_targeted - button_sound - door_open - door_sound - door_countdown - door_close - door_sound - door_triggerbutton ...
WPoly - Počet renderovaných poligónov World objektov, tj. všetky steny a brush_entity (napr. func_wall, func_door atd...)
EPoly - Počet renderovaných polygónov Entity objektov, tj všetky modely, grafické efekty apod.
Doporučené hodnoty r_speeds
Ako som už spomenul, HalfLife je staršieho dáta a keď ho zahltíte brutálnym množstvom polygónov, tak mu nepomôže ani Radeon 9800pro a trojgigový procák... Proste si musíme pripustiť že HL1 neni HL2 aj keď sa to už viacerý pokúšali vyvrátiť (napr. aj ja s mojou mapou INTAKE :D )
Takže ak chcete zachovať vašu mapu v rámci hrateľnosti aj pre ľudí zo slabšími kompami ale hlavne ak robíte Multiplayerový level, je dobré držať sa týchto dlhodobým používaním zaužívaných r_speeds:
WPoly 600 / EPoly do 5000
SP - staré šunky
MP - mapa pre 10-x hráčov, frekventované miesto s mnoha bojmi
WPoly 800 / Epoly do 3500
SP - horná hranica pre pomalšie počítače (700Mhz-)
SP - maximálny limit vykreslených polygónov v softwarovom mode
MP - najviac používaná hranica pre MP mapy
MP - mapa do 10 hráčov, frekventované miesto s mnoha bojmi
WPoly 1200 / EPoly do 3500
SP - Mapa pre lepšie mašiny (1600Mhz+)
MP - mapa do 4 hráčov, málo frekventované miesta
WPoly 2400 / EPoly do 1500
SP - Mapy pre veľmi dobré mašiny (2600Mhz+)
MP - Nevhodné
Wpoly 3200 + / Epoly 5000 +
SP - Sekaná jak HL2 na 486...
MP - Lagy na LAN horšie ako na modeme...
Ako ste si iste všimli, engine potrebuje hlavne veľa výpočetného výkonu, pretože grafiky v tej dobe veľký výkon nebrali. Preto vám pri detailnom leveli viac pomôže lepší procesor ako grafika.
)
Snažte sa držať pravidla do 800, to je najpoužívanejšie. U EPoly si uvedomte, že ich kreslenie je omnoho rýchlejšie ako WPoly, ale zase všetky údaje sa musia posielať na server, preto keď je veľa modelov a efektov na scéne tak to dosť laguje. Tiež si uvedomte, že čím viac polygónov, tým väčšie časy vnútorného cyklu hry = daľšie lagy a menšie fps (engine čaká s vykreslením snímku na ukončenie herného cyklu) ...
Pozn. Krásny prípad ako sa to nemá robiť je moja prvá mapa Warehouse . Veľká miestnoť je to najhoršie čo môžte pre váš level urobiť. Halfik nemá rád exteriéry, on radšej menšie interiéry.
Niečo o engine, jeho stavbe a kompilácii
Engine HalfLifu bol v čase vydania jeden z najlepších. Dnes je tomu už "trochu" inak a preto má už nejaké tie obmedzenia. Bol projektovaný prevažne na grafické karty vtedajšej súčasnosti, teda Vodoo3, TNT2 atp. a bol optimilizovaný na možnosti vtedajších počítačov.
Ale hlavne si musíme pripustiť, že je postavený na engine hry QUAKE 1 a doplnený mnohými kódmi z QUAKE 2 (viem, mnohým z vás teraz zrejme spadla sánka, ale je to potvrdený fakt od Valve, bola o tom dosť živá diskusia na VERC a napokon najprv zistili určitý maniaci že sa vnútorne akosi "priveľmi" podobá na Quake1 a potom to aj potvrdil jeden programátor od Valve...)
Takže, čo to z histórie máme za sebou, poďme na teóriu.
Ak by mal engine vykresľovat celý level naraz (teda aj časti ktoré nevidíme), bolo by to zbytočné plýtvanie výpočetným výkonom. Preto má každý engine vlastnú technológiu na zisťovanie toho čo má a čo nemá vykresľovať. Keďže Halfik je postaveny na Quake generácii, používa teda na výpočty BSP Tree a Visibility Information Set (VIS). Poďme si ich bližšie priblížiť:
BSP Tree
Počas kompilácie prekonvertuje HLCSG planárny formát .rmf (objekty nie sú definované polygónmi ale rovinami) do vektorového polygónového formátu .map a HLBSP usporiada tieto vektorové informácie do prehľadného BSP Stromu. Je to niečo podobné ako adresárový strom v DOSe alebo WindowsComanderi. Herný svet sa rozdelí na hlavné vektory a polygóny, potom od tých vektorov na ďaľšie menšie atd. až kým sa neusporiada celý level. Tak vznike stromovitá štruktúra polygónov celej mapy, ktorá udáva v akom poradí sa majú polygóny renderovať.
VIS
Starý známy VIS. Mnohý nevedia na čo je dobrý, len že spomaľuje kompiláciu a preto ho vypínajú, mnohý vedia približne čo robí, ale aj tak ho z vyššie uvedeného dôvodu vypínajú a máloktorý vedia presne čo robí a vážia si ho a uctievajú ho . Takže si vysvetlime načo je ten VIS taký dobrý.
Keď je .bsp skompilované, je síce pekne usporiadané do stromovej štruktúry, ale nemá absolútne žiadnu usporiadanosť čo sa týka viditeľnosti. Z akéhokoľvek miesta vidíte všetky poligóny na mape vo našom FOV (výhľade). Avšak HLBSP pri kompilácii uloží aj špeciálny súbor s geometrickými dátami mapy. VIS ich spracuje a na ich základe "inteligentne" rozloží mapu na BSP Leafs (viď ďaľší pojem). Prečo som dal inteligentne do zátvorky sa dozvite neskôr (ale niektorý už tušia ;) ). Tieto Leafy sú v podstate územia, ktoré rozkladajú mapu na akési sektory resp. oblati, na základe ktorých sa potom neskôr určuje ktoré ďaľšie oblasti sú práve viditeľné - renderujú sa.
Ako jednu z ďaľších dosť dôležitých vecí upraví BSP Tree tak, aby sa pri renderovaní nezobrazovali inverzné plochy, - plochy ktoré vidíme tzv. "od chrbta" - tzv. BackFacing. Teda napríklad máme pred sebou bedňu a zadnú stranu nemôžete bez pohnutia vidieť, aj keby ste sa poskladali... Ako to ale robí vám už bohužiaľ nepoviem, ešte nikde na internete som to nenašiel (a to som už dosť dlho na celonárodných mapping fórach). Ale mám taký pocit, že kým nebudeme mať zdrojáky enginu, tak to ani nezistíme, lebo technické finesy sú veci ktorá sa zásadne neprezrádzajú
Nakoniec, na základe týchto geometrických údajov vypočíta Radiálnu mapu levelu, ktorú použije HLRAD na výpočet Radiosity, teda odrazu svetla.
Ukážka ako VIS rozdelil mapu na Leafy ako ich teraz zobrazuje. (pozn. o pužitom zobrazovacom mode si povieme neskôr)
BSP-Leaf
Ako som už spomenul, VIS rozloží mapu na akési oblasti. Tie sa nazývajú BSP-Leafs. Na nich sa zakladá a padá základný princíp určovania viditeľnosti, tzv. Potentialy Visible Set (PVS). Funguje na tom princípe, že VIS na základe týchto Leafov prepočíta vzájomnú viditeľnosť Leafov, ktorá je potom pri každom spustení mapy načítaná a engine na základe týchto údajov renderuje len VISom označené Leafy - teda polygóny v nich obsiahnuté (viď obrázok).
V skratke, VIS urobí "mapu" Leafov a určí ich vzájomnú viditeľnosť, ktorú potom používa engine, aby vedel čo má renderovať.
Leafy VŽDY existujú len ako trojuholníky. Hrany Leafov zalomia tiež polygóny na zemi, stenách a strope ak už leaf nie je vytvorený na hranách polygónov (predstavte si to akoby ste miestnosť prepálili laserom).
VIS ale nemá inteligenciu človeka a preto nie sú Leafy nikdy usporiadané ideálne. Preto tá inteligencia v zátvorke... V podstate dáva buď okraje na väčšie znemy v architektúre (prechod z chodby do miestnosti) alebo ich rozmiestňuje viac-menej pravidelne po mape. Ale zase je pravda že taký "vymakaný" VIS by bral asi desaťkrát viac času než doteraz, takže buďme radi :D. Leafy sa dajú umiestňovať aj "ručne" pomocou HINT blokov, ale o tom si povieme v nejakom ďaľšom tutoriale...
Pravidlá pri určovaní viditeľnosti
Ako som už spomenul, VIS prepočítava viditeľnosť leafov. Ale má na to svoje pravidlá, nie je to len tak že si tipne .
Pri výpočtoch vyšle VIS mnoho myslených lúčov do priestoru (pracujeme v 3D). Lúče ktoré sa ocitnú v ďaľšom leafe podajú informáciu o viditeľnosti tohoto leafu a pokračujú ďaľej. Ak narazia na stenu, zanikajú a podajú informáciu že zanikli. Po zaniknutí všetkých lúčov spracuje všetky podané informácie o viditeľnosti, uloží ich a pokračuje na ďaľší leaf v rade (rada sa určuje cez BSP-Tree). Takto spracuje všetky leafy a napokon uloží PVS do BSP stromu.
VIS považuje za "steny" všetky solid objekty ktoré nie sú entitami. Ak je objekt entita (napr. func_wall), lúč pokračuje ďalej. Toto je dosť dôležitý fakt ktorý mňa osobne dosť ser... ehm. Asi sa predpokladá, že entita môže kedykoľvek meniť svoje vlastnosti, teda aj vizuálne a tým pádom sa môže zneviditeľniť => oblasť za stenou by sa stala viditeľnou a PVS sa nedá upravovať, takže by vznikol konflikt.
To by bolo asi tak všetko o engine, snáď ešte len taká poznámka, že všetky polygóny v rámci viditeľného leafu sa ukladajú do pamäte, aj tie ktoré sú vám za chrbtom, ale renderujú sa len tie ktoré sú vo vašom FOV (field of view, v preklade čo sa zmestí na monitor ). Takže ak designujete mapu, tak to majte na pamäti. Nie je všetko výkon čo sa renderuje... (btw: možno neskôr napíšem aj teoretický článok o renderingu...)
VIS-Bloky
Mnohokrát som už spomenul tento termín, ale ešte som ho neozrejmil. Sú to objekty, ktoré bránia VIS-u, aby "videl priveľa". Vysvetlíme si to na mojej mape Enigma7.
Ak neberieme v úvahu, že Vis-bloky sú v podstate neodeliteľná časť levelu, tak si uvedomíte ich dobré usporiadanie. Taktiež ale neberme v úvahu presné rozdelenie Leafov, o to tu nejde, tu ide o princíp . A síce že VIS-Bloky zabraňujú prílišnému "rozhľadu" enginu. Preto už od začiatku projektujte svoju mapu tak aby v nej bolo čo najviac prirodzených VIS-blokov.
Kompilačné kiksy, alebo aj stroj je len človek
Už mnohí ste sa stretli s rôznymi podivnosťami po skompilovaní mapy bez erroru, vyzeralo to skôr ako práca Microsoftu, ale na to to bolo až príliž čudné. Napríklad ste mali zalomený tieň na svetle alebo krabici, mizli vám steny spred očí alebo ste videli všetko na zeleno (to posledné neplatí, to bol len problém v kábli ;) pozn. Wizz ).
Ale tu nejde o problémy s istým operačným softwarom, ale o kompilačné nástroje, pretože tie makajú len na matematickej úrovni a zdravý úsudok nepoznajú. Preto aj ak dostanú nejakú nesprávnu hodnotu, prepočítajú ju a o výsledok sa nestarajú. Proste idú ďalej kým neni error (to mi pripomína WIN, nešahať kým to ide , ale dosť už srandičiek s Billa...). Ale prečo sa takéto hodnoty vyskytujú ? Jednoduchá opdoveď: Presnosť výpočtov.
Počet bitov v počítači je obmedzený a čím viac ich je zaplnených, tým viac treba počítať. Preto ak máme vektor dajme tomu na adrese XYZ 25,46448679 / 668,4646 / 353,6666666 periody, tak si to počítač proste zaokrúhli na šiestu desatinu (počítame s tympom Integer, toto je už vysvetlenie viacej programátorského typu) teda dostane adresu XYZ / 25,464487 / 668,464600 / 353,666667. HA! zaokrúhlil to. A keď si vezmeme že takýchto vektorov je čosi cez milión a väčšinou má aspoň každý tretí periodickú hodnotu a nezanedbáme že čím viac ide výpočet ďalej, tým sa presnosť znižuje (stále výsledky zaokrúhľuje na menej desatiných miest aby dostal non-float číslo, ktoré je engine schopný prijať) tak dostaneme štatistickú chybu okolo 10% (hodnota od oka ) čo je setsakra veľa, takže sa len divím že level nemá tak veľa chýb.
Huh, keď tomuto odstavcu pochopí aj niekto iný ako ja a Majacik tak budem rad. A keď to ani Majacik nepochopí, tak sa asi vážne zamyslím nad písaním ďaľších podobných blábolov :D...
Okej, poďme si teda ľudsky povedať, čo tieto chyby spôsobuje naozaj a ako sa im vyhnúť...
Zlé nasvetlenie, "polámaný tieň"
Tento klasický efekt je spôsobený prechodom medzi tieňovaním. RAD používa Phongove tieňovanie ale po prekročení určitého uhlu od svetla sa daná face (polygón) netieňuje daným svetlom. A to je presne tento prípad. Napríklad žiarivka ktorá je brush, "rozsekne" polygóny na stene a väčšinou je to tá smola, že je tam akurát ten blbý uhol od light-u, od ktorého sa netieňuje... Viď nižšie o práci HLCSG.
Riešenie:
1.) Nastaviť hodnotu HLRAD -smooth na väčšie číslo, prípadne menšie. Dobrá je hodnota okolo 80°.
2.) Dať svetlo ako entitu. Odporúčam func_wall, prípadne func_illusionary a nastavte parameter ZHLT Lightflags na Opaque čo spôsobí že entita bude vrhať tiene. Ale pozor ak je daný objekt "čo láme tieň" vis-blok. Vtedy si týmto moc nepomôžete...
3.) Dajte svetlo ako entitu (viz. hore) ale do ZHLT Lightflags dajte Opaque + Embedeed Fix.
Miznúce modely, prípadne steny
Toto je spôsobené ak je presiahnuté množstvo entít, teda limit enginu. Hore vľavo by vám malo písať hlášku že "Too many entities in visible packet list". Tu sa to nedá inak riešiť ako zmenšiť počet entít na scéne. Často sa to ale stáva ak je blbý VIS a engine vidí kopu entít ktoré by v skutočnosti nemal vidieť. Pokúste sa urobiť nejaké Vis-bloky prípadne zmeňte trochu architektúru levelu.
Mapa mizne v diaľke do oblohy
Toto je častý jav pri softwarovom mode, ktorý má limit 800 wpoly. Ostatné už proste nevykreslí...
Ďaľšia možnosť je, že váš level je "trošku dlhší" než bol nastavený BSP strom. Toto sa dá ľahko napraviť v Hammeri: Ideme cez hornú lištu Map > Map Properties > Max Viewable Distance. Toto číslo je deafultne 4096 unitov, nahraďte ho takým čo vám bude vyhovovať. Ale pozor ! Nepreháňajte, lebo tento limit vlastne určuje čo sa má natiahnuť do pamäte a čo nie, preto pri MP leveli môže veľké číslo spôsobiť nemalé problémy. Podľa mňa je aj 4096 na MP level veľa...
V podlahe a stenách sa objavuú "praskliny"
Tento "efekt" je vídať hlavne na objektoch upravených Vertex-editingom. Engine dokáže pracovať len s koorodinátmi typu celých čísel, a všetky vertexy, ktoré majú polohu s desatinou čiarkou sú umiestnené na najbližšiu celú kótu. A takto vzniknú tieto "praskliny", teda tým že dve polygóny nedoliehajú a vytvorí sa medzera. Opraviť sa dá jedine tak, že daný objekt zmažeme a spravíme ho odznova. Často je chyba detekovaná už v Hammeri. Dajte si Check for Problems (Alt+P) a ak tam budete mať error Invalid Solid Structure tak ste jasný... Treba to prerobiť alebo dajte FIX, ale práve ten často spôsobí tieto praskliny.
Občas sa objaví aj na miestach, kde jeden objekt "rozsekol" polygóny druhému (viz nižšie). To sa dá opraviť tým že objekt ktorý to spôsobil dáme ako entitu.
Tak, to by boli asi tie najzákladnejšie problémy okolo enginu, ak budete mať nejaký iný vážny, ozvite sa a ja vám odpoviem .
Detaily versus výkon...
Detaily sú to čo dávajú levelu charakter, detaily sú to čo vášmu levelu vdýchnu dušu. Ale keď je týchto detailov priveľa, začína nám to nepríjemne sekať. Ale nenecháme našu dlhodobú snahu marnú a dáme našim detailom šancu aj v takom nehostinnom prostredí, akým je v dnešnej dobe HL1... Preto teraz pozorne čítajte, lebo vám prezradím tajomstvá, ktoré sa neprezrázdajú, ale keďže sme jeden kolektív, budú to naše "Teamové finty" .
Takže, poďme si povedať základy, ako spraviť namakaný level ktorý má neuveriteľne nízke WPoly. Najprv si ale povedzme, čomu sa vyhnúť a prečo.
HLCSG a HLVIS a ich práca
 Ako sme si už povedali, HLCSG prekompiluje všetky planárne objekty na polygóny. Zdá sa to jednoduché, ale nie je. A to hlavne kvôli tomu, že polygónová sieť nemôže mať žiadne "diery" alebo prerušenia. Preto ak sa napríklad stretáva stĺp s podlahou, tak ten stĺp ju "rozseká" na polygóny tak, aby podlaha naväzovala na ten stĺp (viz. obrázok). Blbo sa to vysvetľuje, pozrite si obrázok vľavo a hneď pochopíte.
A keď si vezmeme že máme dva 8-hranové stĺpy ktoré idú od podlahy po strop, tak nám vyjde, že nám toto "rozsekanie" pridalo 32 polygónov. Platí to u všetkých objektov, ktoré sa dotýkajú iných, teda aj napríklad krabice na zemi atd. Ak ale dané objekty dáme ako entity, rozsekanie sa nekoná, lebo CSG konvertuje 1 polygónovú sieť pre World objekty a pre každú brush entitu kompiluje vlastnú sieť, takže nenarušuje ostatné.
Teraz sa vám možno zdá, že by bolo najlepšie všetky objekty okrem stien dať ako entity. Ale ako to už v svete chodí, všetko má svoje pro a proti. Ak ste pozorne čítali, viete už o čo ide. O dve veci: Za prvé, čím viac entít na scéne, tým sú väčšie nároky na pripojenie k serveru, lebo všetky entity udávajú v každom cykle svoju polohu a to druhé je VIS. Poďme si ten druhý dôvod ale viac ozrejmiť:
VIS používa na zostrojenie PVS myslené lúče ktoré sú rozpustené po celej časti levelu (viz. vysvetlenie v časti "Pravidlá pri určovaní viditeľnosti"). A tieto lúče zanikajú iba ak dopadnú na World objekt, ale cez entitu prejdú. Preto nemôžu tým pádom pracovať ako Vis-bloky. A ak ich necháme ako normálny world objekt, tak budú pracovať ako prirodzené VIS-bloky tým že budú zabraňovať prílišnej viditeľnosti. Samozrejme sa ale malým objektom ako krabice 32x32 alebo svetlá nedá hovoriť Vis-bloky...
Ukážka, čo všetko engine renderuje
Riešenie
Ak máme zložitejší objekt ktorý sa má dotýkať inej väčšej plochy ako stena apod. tak je najvhodnejšie nechať buď medzeru 1 unit, alebo pridať medzi tieto dva objekty nejakú entitu. Napríklad máme rúru ktorá sa dotýka steny, tak na stenu dáme štvorcovú podstavu pre rúru a bude to plniť svoj účel a k tomu to bude ešte dobre vyzerať.
Druhé riešenie je dať daný objekt ako entitu, ale ako som už spomenul, má to svoje nevýhody.
Diagnostické nástroje
Na to, aby sme presne povedali čo spôsobuje vysoké r_speeds, musíme vedieť príčinu. "Je to zlé rozdelenie Leafov ? Príliš rozsekané polygóny ? Na scéne je veľa entít ?" Atd... Na zistenie a kontrolu nášho levelu z hľadiska výkonosti a optimilizácie má HalfLife vstavané rôzne nástroje. Poďme sa na nich pozrieť bližšie.
Na obrázku vidíme jednu scénu vo viacerých zobrazeniach. Text v každom okne hovorí o konzolovom príkaze. Poďme si ich vysvetliť.
Príkazy funkčné len v Softwarovom zobrazovacom mode.
r_drawflat 1 - Zobrazí celý level flatshaded pričom každý polygón má inú farbu
r_draworder 1 - Zobrazí čo všetko engine renderuje
Príkazy funkčné len v OpenGL zobrazovacom mode
gl_wireframe 1 - Zobrazí polygónovú sieť levelu na textúrach. Zobrazuje sa len skutočne videná oblasť
gl_wireframe 2 - Zobrazí polygónovú sieť levelu na textúrach ale zobrazí všetko čo engine renderuje (podobné ako r_draworder)
Vďaka týmto zobrazovacím modom si ľahko spravíte prehľad, ktoré oblasti sú najviac problémové a kde by sa hodily VIS-Bloky.
Záverečná...
Ak ste sa prelúskali až sem tak vám gratulujem ! Mali by ste už totiž vedieť ako pracuje CSG a VIS, základnú stavbu enginu a dostali ste odpovede na najčastejšie otázky ohľadom chybného skompilovania. Taktiež by ste už mali ovládať základné techniky na znižovanie r_speeds.
Takže nateraz je to odomňa všetko, lúčim sa s vami s krátkou štatistikou tohoto článku a vy sa môžete tešiť na ďaľší článok, ktorý bude pojednávať ďaľšie techniky na znižovanie r_speeds a na lepšie a rýchlejšie kompilovanie.
Mappovaniu zdar želá
JACKAR
Menšia štatistika tohoto článku...
- bol písaný cca 15 hodín
- padlo pri ňom asi 7 silných káv
- odohrali sa všetky albumy Horkýže Slíže na viackrát
- samozrejme aj iné ...
- chladnička bola vyrabovaná 5-krát
- a perlička na záver: Bol písaný na 3 rôznych monitoroch: 17'' LCD, 15'' CRT, 19'' CRT. Práve vlastním posledný
|
 BODOVANIE LNKU
Boduje sa ako v kole (1- vborn, 5-zl)
Priemern znmka : 1.73
Hlasovalo : 26
|
KOMENTRE KU LNKU
Poet komentrov ku lnku : 16
1. qery 
[11.03.2004-09:40]  168 | pekny clanok (a pekne dlhy ;D)
konecne su mi niektore veci jasne[rmb]qery
-=HL4ever=-
qery.no-ip.com |
3. qery
[11.03.2004-12:08] 171 | jj cim viac tym lepsie. aspon je co citat ;))[rmb]qery
-=HL4ever=-
qery.no-ip.com |
4. Nemesis
[11.03.2004-13:09] 172 | | Uff mam co citat |
7. qery
[11.03.2004-17:57] 175 | 2shep: ani mne to doma nejde ale desik na servery som to uz vydel aj otvorene a zakempene... ;))[rmb]qery
-=HL4ever=-
qery.no-ip.com |
8. Choosen
[29.07.2004-12:33] 329 | Celkem dobrá èlánek. Pùvodnì jsem mìl asi 1000 dotazù, ale jelikož by to bylo hrooznì dlouhé a taky protože mì celkem ani moc nezajímá, jak HL engine pracuje , tak bych napsal jen pár nejasností èi pøipomínek.
-herní cyklusTo jako znamená, že pokud by byl herní cyklus tøeba 3ms, tak se za jednotku èasu (která je zøejmì stejnì velká u všech velikostí cyklù) provedou 3 "operace" a vypoète se FPS?
vis-blokypíšeš,že :"...Preto už od zaèiatku projektujte svoju mapu tak aby v nej bolo èo najviac prirodzených VIS-blokov..." no 1) o vlastní tvorbì vis-blokù nebylo v celém èlánku ani slovo 2) jak mám teda dìlat mapu, aby v ní bylo co nejvíce vis-blokù?
sekce od nadpisu KOMPILAÈNÍ KIKSY... až po obrázek:výtah z vìty:"...ak dostanú nejakú nesprávnu hodnotu, prepoèítajú ju a o výsledok sa nestarajú... "to jako že pokud jim vyjde pøi výpoètu špatná hodnota, tak ji pøepoèítají ještì jednou a pak až ji nechají být?
Další vìc. PROBOHA, JAK MÙŽEŠ NAPSAT A HALVNÌ SI TO MYSLET, ŽE HODNOTU 668,4646 ZAOKROUHLÍ NA 668,464600 ??? Hmmm, nechtìl bych to tady vysvìtlovat, ale vìz, že souøadnice 668,4646 je již zaokrouhlené èíslo. Správnì by to bylo, kdyby ta hodnota byla pøesnì tolik, ale pak bys to musel napsat ve tvaru 668,464600... (nula je periodická).
|
9. Choosen
[29.07.2004-12:34] 330 | | Myslím si, že tento tutoriál je dobrý a tak D9KY JACKARE. Dobrá práce |
10. Jackar
[29.07.2004-22:09] 331 | 2Choosen: Som rad ze mas otazky. Sem s nimi. Ale by som bol rad aby sa dakdo vyjadril aj o novom clanku 
Takze, herny cyklus je samostatny, proste ked mas sialene velky herny cyklus tak hra seka, aj ked mas 100fps... nemam cas na vysvetlenie, sorr
Dalej, vis-bloky sa umiestnuju tak aby zamedzovali enginu vidiet privela. NEviem ako sa to da inak xapat, ale chystam tutorial, prosim pockajte, vsetci xu tutorialy a ja xem cas
Daleeej, tie koordinaty som myslel ze ne zaokruhli, ale dopocita, som tym xel ukazat ze pracuje s takymi hodnotami, takze ostatne miesta si mozes domysliet nulky ;).
Dalsie otazky, anyone  |
11. Choosen
[29.07.2004-23:07] 332 | to Jackar: OK, ten herní cyklus stejnì nechápu, ale to je jedno, prostì tam je a hotovo
VIS BLOKY : pochopil jsem proè tam jsou, ale nepochopil jsem co jsi myslel tím, že máme vytváøet mapu tak, aby tam bylo co nejvíce visblokù ... nechápu JAK MÁ TEDY TA SPRÁVNÁ MAPA VYPADAT, ABY TAM BYLO VÍCE VISBLOKÙ... (apropo to, že když jich tam je více, tak že je to lepší je jasné. Srovnal bych to s jedním pøíkladem - chceme v Kladivu udìlat válec. Èím více stìn bude mít, tím bude pùdorys vypadat vìrohodnìji jako kruh  )
P.S. na tut o vis blocích se tìším
P.S.II Ohlednì toho zaokrouhlování - chtìl jsem tì jen trochu popíchnout 
P.S.III - Jak se spouští ve høe ten r_speeds?  Když to napíšu do konzole, se objeví na dalším øádku "r_speeds = 0" ??? |
13. Dukester
[06.03.2005-22:29] 998 | | Dobrej clanek na par principech fungoval muj opengl wallhack kdyz sem jeste driv delal cheaty DuK3st3r |
15. alien_hunter
[28.10.2005-23:44] 1590 | From Cradle To Enslave,From Enslave To Torment,From Torment To Death
Cradlove jsou fajn, ale jsou moc umely ...We cannot be understood as we are understanding...
...How can I be sure in a world that's constantly changing?... |
16. master
[16.02.2007-11:25] 2329 | | Velmi pekneeeeeeeeeeeeeeeeee... Steven Seagal is the BEST ... | Pre pridvanie komentrov muste by prihlsen
Pokia ete nieste zaregistrovan, mete tak urobi TU
|
|
|
|
|
|
Inak tak mimochodom nevite ako sa da otvorit ta tajna miestnost v crosfire?? Na niektorych servroch to ide a mne to na pc nejde.. Clanok by si zasluzil 1+++
