Názory k článku Překladače na platformě IBM PC: od assembleru k C (32bitový kód a FPU)
-
Hodilo by se dodat, ze sice DJGPP (tedy GCC) asi mel nejlepsi vysledny kod, ale preklad trval VEKY. Na 486 Borland C prekladal prakticky okamzite, Watcom C nas kod rekneme do 2-3 sekund, ale DJGPP na tom sedel klidne pul minuty. A to bez vypnutych optimalizaci, jen zakladni preklad.
(navic, jestli si pamatuju, umel Borland C nejak cachovat include soubory do nejake predpripravene binarky)
-
Nee, myslel jsem fakt cast prekladu DJGPP, ne porovnani s BC, kterej nepreklada obj v pripade, ze se zdrojaky nezmenily. To se resilio i kdekoli jinde pres Make a RHIDE presne takto vytvorilo projekt - byl tam Makefile a prekladal se (dloooouho) vzdycky jen ten jeden malej zdrojak, ktery se menil. Ostatni se jen slinkovalo.
-
RHIDE bylo hezký, ale co pamatuju docela padavý.
Kromě DJGPP existoval i další port GCC Eberharda Matthese EMX, který podporoval kromě DOSu i OS/2, kde se možná nakonec používal víc než v DOSu, kde převážilo DJGPP.
DJGPP hodně proslavil Quake, který ho v původní verzi používal, byť to už je v roce 1996 taková labutí píseň DOSu...
Hodně se mi líbila a líbí knihovna Allegro, původně jen pro DOS, dneska kompletně překopaná a podporující všechny možné platformy. Za mě v dnešní verzi Allegro 5 jedna z čistě céčkovských knihoven s nejpromyšlenějším a nejpříjemnějším API. Škoda že vedle SDL nemá šanci :) Ale to už jsem od DOSu utekl hodně daleko... -
Pavel TišnovskýZlatý podporovatelJen technická poznámka: Allegro (psal jsem v tom bakalářku) původně vzniklo pro Atari ST. Myslím, že se dá používat dodnes, i když máš pravdu - dneska je všude SDL (2), tak těžko říct, co používat (asi SDL).
-
U SDL-1 na SDL-2 nebylo na výběr (taky jsem přepisoval). SDL-1 spoléhal na přímý přístup do grafické paměti, což v případě GPU prostě nefunguje. Myslím, že TTF zůstal tak na půl cesty - text se renderoval softwarově a pak přenesl do textury.
SDL-3 dělá další krok, mimo jiné opět kvůli změně přístupu k GPU - Vulkan apod.
-
Pavel TišnovskýZlatý podporovatel
to jo, ale IMHO klidně mohli nechat bliting SDL_Surface tak jak byl, jen by se na pozadí udělal update SDL_Texture a potom vykreslení (teď to tahám z hlavy, možná se ty struktury jmenují trochu jinak). Jako nakonec s tím nebylo takové drbání, jen si človek musel ujasnit, jestli ta původní SDL_Surface má být editovatelná (potom je to surface) nebo se tam jen natáhne statický obrázek (potom textura).
-
Jasně, ono to technicky jde, ale z hlediska GPU je strašně neefektivní tahat data tam a zpátky, takže se snaží lidi odradit. Programátor si stále může zvolit render do surface, ale musí si to poprávu napsat sám :-)
Ta editace SDL_Surface se ve vyšším kódu stejně nepoužívá, spíš jen některé nízkoúrovňové knihovny jako třeba TTF. Ale těm stačí jednosměrná cesta - create surface -> software render -> create texture -> render texture.
Takže se spíš musely přejmenovat věci, než že by to mělo nějak dramatický vliv u programů, které už renderovaly velké objekty.
-
Pavel TišnovskýZlatý podporovatel
jj tahat data zpátky (pokud to není nějakej screenshot tool) asi moc není potřeba, ale blitovat z pole pixelů do surface nebo na obrazovku, to je někdy běžné. Emulátory, hry typu Duke 3D (SW rendering), vlastně jakýkoli rendering, který jde mimo 3D pipelinu, simulace kdovíčeho atd. Nakonec když o tom přemýšlím, těch změn bylo jen pár a jak říkáš - na nějakém rozhraní low/high level, takže to na vyšší úrovni fakt jen znamenalo rozmyslet se, kdo a kdy mění pixely.
