Első ránézésre kevés a hasonlóság a nagyító, meg a textúrázott gömb között, de csak egy kis fantázia kell hozzá.
Gyakorlatilag: Ha mondjuk egy újságon végighúzunk egy eléggé torzító nagyítót az írás irányába, olyan, mintha a betűk egy gömbön fordulnának elénk. Ha egymásután csak ugyanolyan betűk lennének, mindig ugyanaz a minta forogna. Tehát, textúra a gömbön.

Elméletileg: Ráeresztünk egy végtelenített textúrára egy nagyítóeffektet. Úgy, hogy mindig egy irányba mozgatjuk. Ezzel aztán már forgatjuk a gömböt egy irányba.

Egy kis emlékeztető a nagyító effektről. Egy mátrix segítségével történik, a mátrix minden pontja az odatartozó textúrapont koordinátáit tartalmazza. Akinek nem tiszta, az előző számban megtalálja.

Persze a dolog nem ilyen egyszerű. Attól függően, hogy milyen messze van a gömb, egyre kisebb. Tehát magát a nagyítómátrixot is nagyítani, kicsinyíteni kell. Ezt nagyon egyszerűen, egy texture mappinghez hasonló eljárással el lehet érni, csak itt a mátrix lesz a torzítandó textúra.

A mátrix végtelenített textúrán való csúsztatása, pedig a forgást eredményezi.

A dolog akkor működik igazán, ha ugyanakkora a textúra, mint a nagyítómátrtix. Érthető okok miatt legyen 256X256.

progi:

void txtr(int cx, int cy, int cz, unsigned char a, unsigned char b){   int d,x,y,n,m,v,z,o,p,l,c;   char j,k;   d=cz;   cx-=256*RAD/d;   cy-=256*RAD/d;   cx<<=8;   cy<<=8;   for(y=0,m=0;y<256*2*RAD;y+=d,m++)   for(x=0,n=0;x<256*2*RAD;x+=d,n++)   {     v=x>>8;     z=y>>8;     o=(cx>>8)+n;     p=(cy>>8)+m;     if(transtab[v][z].x!=0 && transtab[v][z].y!=0)     {       if(o>0 && o<640 && p>0 && p<480)       {         j=transtab[v][z].x+a;         k=transtab[v][z].y+b;         c=(k<<8)+j;         screen[o+p*640]=texture[c];       }     }   } }

Ez a kis függvény csinálja azt, amiről eddig irkáltam. Meg kell adni a gömb középpontját 3D-ben, és a nagyítómátrix eltolását a textúrán. Az eltolás egyik koordinátáját folyamatosan növelve a forgás illúzióját lehet kelteni. Tulajdonképpen ilyen egyszerű lenne. Ezzel a módszerrel csak 2 irányba lehet forgatni a textúrázott gömbünket. Akinek ez nem elég, magát a mátrixot is megforgathatja, így megvan a harmadik is. Ehhez egy kis wallpaper texture mappinget kell belekeverni.

Tulajdonképpen ilyen egyszerű lenne. A megvalósítás Watcom C-ben sikerült. 640X480-ban fut a program, és nem is olyan lassú. Annak köszönhetően, hogy élesben nem a fenti kis rutin működik, hanem annak assembly változata. Erről ennyit.

A program futtatásához sima DOS ajánlot, a VESA mód nálam (Windows NT) nem volt az igazi.

forrkod1.zip

Legyen még valami.
Linear Frame Buffering.

Aki nincs tisztában a real mode, meg a protected mode közti különbségekkel, nézzen utána, mielőtt továbbmegy. (A PC-X User-ben a Rendszerprogramozás rovatban már bőven volt szó róla. De lassan indul ezt is említő rovatunk. Szerk.)

A hangzatos elnevezés azt takarja, hogy míg normális esetben az 1 szegmenset meghaladó képernyő-memóriát bankokként kell kezelnünk(be kell lapoznunk), ezzel egybefüggő memóriaként írhatjuk, olvashatjuk, a képet. Ehhez persze a valós módú címzés nem igen stimmel, mert hiába van megengedve az egyben való kezelés, ha még mindig 64k a szegmenshatár.

Ezért kell protected módban kavarni. Megéri, mert gyorsabb. A dolognak annyi szépséghibája van, hogy általában csak sima DOS alól működik. A 32 bites oprendszerek nemigen rajonganak azért, mikor mindenféle memóriafoglalás nélkül elkezdünk írogatni valahova. Még akkor is, ha történetesen az a linear frame buffer. Ez van.

Tehát a linear frame buffering a VESA 2.0 óta van. Ezt még nem sok kártya tudja, ezért kell általában valami meghajtót (univbe, stb...) betölteni. Ha ez megvan, elvileg már kezelhető a cucc. Ahhoz, hogy kezeljük, kéne tudni azt is, hogy hol van egyáltalán. Ezt a VESA get vesa mode information nevű funkciójával lehet megtudni. (Erről és a VESA-ról már volt szó)

Elvileg nem biztos, hogy minden módnak ugyanott van a buffere, de gyakorlatilag így van. Szóval mindegy melyik módnak az informácóját kérdezzük le, másik módban is ott lesz a buffer. Ami elvileg nem biztos, hogy a 0 báziscímnél és 0e0000000H offsetnél lesz, de gyakorlatilag 99.999%. Szép dolog ez a számítógép ...

Tehát mivel nem vagyunk favágók, mi lekérdezzük, maximum meglepve megállapítjuk utána, hogy jé, megint ott van.

Ez a lekérdezés bizony elég macerás dolog. Meg kell hívni védett módból egy 16 bites, real címzést használó megszakítást, aminek azt a memóriacímet kell megadni (szegmens:offset alakban) , ahova azt a pár száz byte adatot beírja.

Ez elég gázos. Egy 32 bites lineáris címből kell csinálni egy 16 bit szegmens:16 bit offset alakú címet. Ez csak akkor oldható meg, ha a 32 bites cím 1 Mbyte alá mutat. Meg a megszakításnak nincs is joga a mi területünkre írni. stb, stb...

Vissza kell nyúlni a DOS-hoz, megkérni, ugyan már foglaljon le nekünk egy memóriablokkot. Ez már biztos olyan helyen lesz amit a megszakítás tud írni. De nekünk is tudnunk kell azt a helyet. A DPMI egy szolgáltatását kell használnunk, ami visszaadja a szegmenst is, meg a deszkriptort is. Innen már megy a dolog.

A DPMI szolgáltatásait nem írom le, meghaladná ezen iromány kereteit. 
Meg én is nálam okosabb emberek programjaiból bányásztam ki. A példaprogramban meg van minden pontosan, és még működik is.

Szóval miután megbizonyosodtunk róla, hogy tényleg ott van a buffer ahol gondoltuk, már írhatjuk is.

pl.: egy 640X480-as képernyő letörlése
 

mov eax,0 mov ecx,640*480/4 mov edi,linearbuffer rep stosd

Ilyen gyorsan és fájdalommentesen megy ez. Mintha csak 320*200-ban lennénk.

A progam sikeres futtatásához sima DOS-ban kell lenni, és ha a kártya nem tudja a VESA 2.0-t, akkor be kell tölteni egy univbe-t.
forrkod2.zip

Na ennyi.