[asembler] - koprocesor

cau, mam problem
zkosuim pocitat neco v koprocesoru a nejak to nechodi. napr zkusim tot a to to pocita spatne

Kód:

---

        finit
        fild        y
        fild        f320
        fmul
        fild        x
        fadd
        fistp        di_n
        fwait

---

a pritom by to melo byt podle me stejne jako tohle a to pocita jak ma jen bez kopru

Kód:

---

mov        ax,y
        mov        dx,y
        shl        ax,8
        shl        dx,6
        add        ax,dx
        add        ax,x
        add        ax,cx
        mov        di_n,ax

---

promene jsou takto definovane

Kód:

---

        X        Dw        0h
        Y        dw        0h
        DI_n        dw        0h
        F320        DW        320

---

nevite nekdo? neni u kopru nejaka bota? sakra to musi fungovat :( potrebuju v nem siny a cosiny a kdyz nespocitam ani tole sme nahranej :(

Na chybu kopru bych to hnbed nehazel (pokud nemas nahodou stare P60 :)
Bohuzel s koprem sem si nikdy nehral, tak neporadim, ale docela by me to i zajimalo. BTW jakej pouzivas ASM prekladac?

uz to mam vyresene, sice ne k plne dokonalosti ale mam.

pouzivam tasm. turbo assembler, ze

k te chybe. bylo to rukama, jak jinak. potreboval sme arctan jenze arctan jakozto FPATAN nedela jen ten arctan ale dela i deleni, takze to ma dva argemnty. ty to podeli a udela arctan.
ten ukazkovej kond jak sem zjistil nefunguje jen v tom jednom mem programu. nevim proc ale pocita to jen pro 32000 pixelu co tam davam souradnice, nechapu, ale to je fuk, to ponasibim v v normal cpu. asi nejak blbe nastavene ds nebo es nebo cokoliv :/ kazdopadne z toho vznikl nejpomalejsi rotozoomer :))))

Citace:

---

Původně odeslal Glottis

ten ukazkovej kond jak sem zjistil nefunguje jen v tom jednom mem programu. nevim proc ale pocita to jen pro 32000 pixelu co tam davam souradnice, nechapu, ale to je fuk, to ponasibim v v normal cpu.

---

Ty dva uryvky kodu nejsou ekvivalentni. Koproc, pokud vim, ocekava cislo se znamenkem takze ti tam muze dojit po prekroceni 32767 k rozsireni vysledku na dvojite slovo (nesouvisi to s tim problemem, ze ti to funguje jen do 32000?). Oproti tomu v te prvni verzi pocitas jako bys mel neznamenkove cislo.

Chtel jsem se zeptat zda jsi delal testy rychlosti obou verzi? Mne prijde ten dvojity posuv a secteni jako rychlejsi nez to pasirovat pres koprocesor...

Glottis> Muzes prozradit na cem to robis, ze delas nakou grafiku pres FP funkce? Se mi zda, ze to asi pak nebude nejrychlejsi. Ja bych nejake ty vyssi operace sveril radeli GCC kompilatoru at dela co umi, pokud teda netrvas na pure ASM (asi kuli male velikosti).

Ja sem jednou zkousel delat takovy malicky programek v ASM, ktery nakresli Svejcarskou vlajku (byla to soutez Vyhen coding compo) a docela mi to stacilo. Muj kod mel asi 78 Bajtu, zatimco nejlepsi borci to meli asi na 40 ;D
Takze po te, co sem narazil na limity Pascalu sem se donutil do Cecka...

miho: to me nenapadlo ze by mi to mohlo pretect! na tom neco je. zkusim. kdyz to pujde zkusim posoudit rychlost ale ty posuvy budou asi rychlejsi. asi jak na jakem procesoru. p4 a tak maj kopr uz vymaklej, nejspis :) apson co sem slysel

RayeR: aaaale delam semestralku na strojove orientovane jazyky. sem si vybral ze udelam rotozoomer tak ho pisu. musi to byt v asm. a nebo vkladany asm ale rotozoomer je tak jednoduchej ze to je lepsi napsat pure asm. jiank mas pravdu, neni to nejrychlejsi :/ naopak, je to nejpomaljis :))) na p3 mi to bezi tak nejak OK ale na p200 uz to je slideshow

tady se mzuete mrknout :) http://michal.inorg.net/asm/sem/

mno tak je to opravdu tim intem ze ho bere zapornej a jen do 32000. takova blbost a ja na to zapomenu.

jinak subektivne se mi zda ze ty posuvy jsou rychlejsi, toci se to o kapaaanek rychleji ale porad nic moc. tam je pruser pocitani te rotace. je tam arctg a sin a cos a to fakt trva :( lepsi by byli tabulky predpocitanych hodnot ale zase kolik by tech hodnot muselo byt, ze, prece jen dva pixeli od sebe to je minimalni zmena uhlu.
tady je kod jak to rotuju :) je to osklive :) ale kdyz nekoho napadne jak to zrychlit muzu to zkusit. kdyz nenapadne tak je to fuk. to by bylo uz jen pro me aby ztoho nebyl nejpomalejsi rotozoomer :)

Kód:

---

        PUSHA
        MOV    AX, @DATA        ; NASTAVÍ SPRÁVNÝ DATA SEGMENT
        MOV    DS, AX
        FINIT
        FILD        F160                ;POSUN NULOVEHO BODU
        FILD        XI1
        FSUB
        FIST    XI1
        FILD        F100
        FILD        YI1
        FSUB
        FIST    YI1
        FPATAN                        ;VYPOCET UHLU BODU ALFA = ATAN(X/Y)
        FLD        INCANGLE
        FADD
        FSTP        ALFA
        FILD        XI1                ;VYPOCET VZDALENOSTI OD STREDU
        FILD        XI1                ;SQRT(XI1*XI1 + XI2*XI2)
        FMUL
        FILD        YI1
        FILD        YI1
        FMUL
        FADD
        FSQRT
        FLD        SCALE                ;PRIPADNE ZVETSENI ZMENSENI
        FLD        INCSCALE
        FADD
        FMUL
        FISTP        R
        FILD        F160                ;POSUN NULOVEHO BODU ZPET
        FLD        ALFA                ;VYPOCET NOVYCH SOURADNIC
        FSIN                        ;R*SIN ALFA
        FILD        R
        FMUL
        FSUB
        FISTP        X1
        FILD        F100
        FLD        ALFA
        FCOS                        ;R*COS ALFA
        FILD        R
        FMUL
        FSUB
        FISTP        Y1
        FWAIT
        MOV        AX,Y1                ;320*Y+X
        MOV        DX,Y1
        SHL        AX,8
        SHL        DX,6
        ADD        AX,DX
        ADD        AX,X1
        MOV        DI_N,AX
       
        POPA

---

Mas to hezke. Pripomnelo mi to demicka na amize :-)

Kreslis predpokladam primo zapisem do segmentu $a000?

Ty predpocitane fce to neni spatny napad. atan pocitas pro hodnoty x a y obe promenne v rozsahu velikosti obrazu. Cela tabulka se ti vejde do segmentu tak proc jeste vahas? ;-) Usetris deleni a arkustangentu to je oproti vypoctu offsetu do tabulky (v podstate ty stejne posuny jako na konci) cela vecnost.
To stejne pro pocitani vzdalenosti (2xnasobeni, scitani a odmocnina).
Od ceho ty procesory ty dodatecne segmentove registry maji :-)
Sinus takto nezoptimalizujes ale staci ti zase jen ctvrt periody, zbytek jsou symetrie. Cos je posunuty sinus.
Bez do toho, drzim ti palce :!:

jeste je jedna rotace :) brutalne rychla

a to tato

x=x´-y´*incalfa
y=y´+x´*incalfa

sice to neni az tak presne ale co :) bohuzel se mi to nari nejak rozume rozjet. jen to tim otocim asi o 90stupnu ale je to rychlejsi asi 100 000 :))) jako opravdu. stim predpocitanim to prad nevidim tak dobre. do segmentu se mi to asi nevejde. protoze obyc float ma 4byty, leda ulozit jen ctvrtinu a uhly jsou pak symetricke. uvidimjak bude cas a chut, odevzdavam uz v patek takze moc casu neni :)
jj kreslim primo kopii do a000h

Glottis>
Pekny, na nasem skolnim P4 to bezi asi 5fps ;D
Za ty tabulky bych se docela premlouval, jednou sem dal takovy mikro demo, ktery melo bezet na XT (bez kopru), byla tam rotace 3D krychle, tak sem si udal tabulku sinu pro kazdej stupen a jak to panecku frcelo. Tady byde asi potreba vic hodnot, ale myslim ze by se to do 64k veslo.

Schvalne to zkusim napsat v C a uvidime kolikrat to bude rychlejsi. Akorat to nebude mit 1,5kB...

Ale nenech se odradit, ja ASMisty docela obdivuju, uz bych na to nemel nervy... (max tak na nakym mikropocitaci, ale to je zas vo necem jinym)

Jinak muj oblibenej prekladac na assembler je NASM.

nasm me nejak moc neuchvatil

btw na p4 5FPS :)) to to na me p3 jede mnohem rychleji :)

Tady sou "jen" 1,5GHz P4, schvalne to zkusim este pustit doma. Jinak NASM se hodi kdyz delas naky programky do BIOSu, nebo MBR, kde chces primo flat binary a ne com/exe.

Na Cyrixe mi to ide asi 4 FPS, takze ta P4ka by sa mala hanbit ;D

je to podivne :) na p100 mi to beha asi 2FPS (odhadem), na 486 33 tak neco pod 1FPS. na mojim uz se to toci hezky, ve skole na p4 1,5 neco mezi tou p100 a mojim hodn edobre to beha v jedne ucebne kde jsou nejake 500ky snad a bratrovy s p4 1,7 to beha hur nez me. zajimalo by me co to brzdi :) jestli pamet grafiky take? mno je to zajimave :)

Tento programek bude na P4 urcite pomerne pomaly protoze pouziva FPU. P4 ma bohuzel jen jednu plnohodnotnou FPU jednotku (P III a Athlony maji dve) a spoleha na SIMD instrukce.

Kdysi jsem napsal clanecek na toto tema
http://www.zive.cz/h/Testcentrum/Ar....AI=2073&CHID=3
(psano pro prumerneho ctenare zive.cz, pocitejte s tim :-) )

Me se zda ze to nebude jen v CPU ale prave asi i dost v prenosu do VRAM. Tady je naka integrovana nvidia Vanta=sacka, a ma to zrejmne sdilenou pamet, tazke proto asi.

P4ka je na normalne veci slaba...

peknej clanek
udivuje me ze by p4 nemela na posuvy barell shifter chmmm

a nenni nekde nejakej tutorialek jak na sse a mmx instrukce v asm?

Tak sem to poustel na mym stroji a bezi to jakstaks plynule, rozhodne lip jak na tom skolnim stroji. Ale videl bych to fak v ty gfx, ne v P4. Jinak clanek byl dobrej...

IMHO to musi bezat nezavisle od grafiky bez problemov - to by malo aj na standardnej IBM VGA alebo Trident 9000 behat priblizne rovnako. Ked si spomeniem, co dokaze na 486ke s ISA grafikou robit demo Second Reality :-)

Tak sem zkousel neco naprogramit v C, sice to rotuje rychle (rychles nez refresh monitoru), ale je to naky buggy, v tom obraze sou pri natocenim jinym nez 0,90,180,270... prazny pixely. Ja sem na to pouzil uz napsanou fci na kresleni obecny cary, takze rotuju jen pocatecni a koncovy body tech car, ktery se misto konstantni barvy krmi radkama z toho obrazku, jenze proste nak nesedou presne jedna vedle druhy. Asi uz bych se na to mel v tuhle hodinu vys.rat :idea:

:) nj kreslit carou to nejde. a kdyz po pixelech tak pro cilovej pixel pocitat zdrojeovej a ne naopak

Sakra, tak by me zajimalo, kde se bere ta chyba. Zistil sem, ze pri nepravym uhlu obcas dojde k tomu, ze se spocitana sourarnice, napr y posune o 1 driv nez by mela a na obrazovce pak zustane neprekresleny bod, tj prosvita pod nim pozadi. Dale pak zas dochazi k tomu, ze se nektery bod prekresli 2x, coz se v obraze okem nepozna, vysledkem je toto:

http://www.volny.cz/xfer/4all/bug.gif
(zvetseny vyrez)
Rozlozeni tech neprekreslenych bodu zavisi na uhlu, rek bych ze nejvic jich je tak pri 60 stupnich. Tohle bylo tusim pro 20 stupnu.

Stejnej problem samozrejme mam i pokud se pokousim nakreslit jen natocenej obdelnik.

Dalsi vec, co by se mela resit je pixel aspect ratio, pri ty rotaci totiz obraz nevypadal pravouhly.

Zistil sem, ze kdyz ten obraz trochu zmensim (staci tak na 80%) tak se diky vicenasobnymu prekreslovani zaceli ty prazny mista, ale neni to rozhodne cisty reseni.

Jinak ted pouzivat tuhle transformaci, po bodech (floaty):

Kód:

---

  for &#40;j=0; j<img.yres; j++&#41;
    for &#40;i=0; i<img.xres; i++&#41;
      &#123;
      x=mag*&#40;i*cos&#40;angle&#41;-j*sin&#40;angle&#41;&#41;;
      y=mag*&#40;i*sin&#40;angle&#41;+j*cos&#40;angle&#41;&#41;;
      vesa_putpixel&#40;x,y,img.p_imgbuf&#91;i+j*img.xres&#93;&#41;;
      &#125;

---

Tady je pak muj programek:
http://www.volny.cz/xfer/4all/rotate2.exe
a obrazek:
http://www.volny.cz/xfer/4all/a1.tga

Rotuje to po 1 stupni se zaplym vsync;

Jo este, u tebe sem koukal, ze ten obrazek taky nevyplnuje celou obrazovku, ac je 320x200 a zkousels co se stane kdyz pred kazdym snimkem smazes VRAM?

mazat vram sem nezkousel.

me prijde ze to prave delas obracene nez bys mel, proto ti tam vznikaj ty dirky. ten tvuj algoritmus pocita souradnice kam bude keslit, ne? zkus to obracene. pro souradnici kam kreslit pocitej souradnice co budes kreslit.

kdyby jsi necekal na retrace jak by se to tocilo rychle? 1° je asi 0,017 radianu coz sem tam mel krok take (priblizne, mel sme tam 0,01). tak jestli to je rychlejsi nebo ne.

Citace:

---

Původně odeslal Glottis

mazat vram sem nezkousel.

---

Notak si to schvalne zkus. Nejlip indexem 255. Pokud pozadi nemazu, tak
to vypada taky pekne, protoze pod tema dirkama prosvita puvodni obraz takze to nepoznas.

Citace:

---

Původně odeslal Glottis

me prijde ze to prave delas obracene nez bys mel, proto ti tam vznikaj ty dirky. ten tvuj algoritmus pocita souradnice kam bude keslit, ne? zkus to obracene. pro souradnici kam kreslit pocitej souradnice co budes kreslit.

---

Ano pocitam KAM budu kreslit. Nejak nechapu jak by to melo vypadat obracene. Kdyz ted zapomenu na rotaci obrazku, predstav si, ze bych stel nakreslit pouze natoceny obdelnik. Tak bych to udal stejne, akorat budu kreslit konstantni barvou. Pritom tam budu mit "dirky" ale taky.

Napred sem myslel, ze ty svine vznikaj pri zaokrouhlovani float->int
http://www.volny.cz/xfer/4all/zaokr.jpg
, ze se to tam vlivem naky chyby jako zateteli a padne spatna hodnota. Jak sem ale zistil, tak naky pixely se zas prekryvaji. Ty muzu aspon detekovat (podle toho, ze pred zapisem zkontroluju framebuffer jesi uz tam neni neco zapsano) a tak sem si vypsal jejich souradnice a zistil, ze se zdaleka ne vzdy jedna o cisla s desetinou casti kolem rozhodovaci urovne. Spis me napada, jesi to neni naka nepresnot ty samotny funkce sin a cos.
Kontorloval sem taky jesi mi da x^2+y^2=i^2 to je celkem OK, semtam odchylka asi na 5 des. miste.

Citace:

---

Původně odeslal Glottis

kdyby jsi necekal na retrace jak by se to tocilo rychle? 1° je asi 0,017 radianu coz sem tam mel krok take (priblizne, mel sme tam 0,01). tak jestli to je rychlejsi nebo ne.

---

Bez vsync asi 2x rychlejs, zatim tu rychlost moc neresim, neni to vubec optimalizovany. Do toho se pustim az to bude kreslit korektne.

Jinak tady je este druhej programek, kde to neni nijak vosetreny ty "dirky" http://www.volny.cz/xfer/4all/rotate1.exe

Co je taky zajimavy, ze se to nemeni at pouzivam float nebo long double.

tak ja se to zkusim popsat nejak lip ten obraceny postup.

zdrojove veci budu indexovat 1 a cilove 2.

postupne budes prochaze obrazek2 a kazdou jeho souradnici x2,y2 zpracujes tak ze si to nekam ulozis. ztrancformujes o tu rotaci a vypocitas x1,y1 coz jsou souradnice do obrazk1. z obrazek1 na souradnicich x1,y1 vemes pixel a prekopirujes do obrazek2 na x2,y2 ktere se nemenili. jeste ti to muzu napsat jako algoritmus v cecku :) ale ja myslim ze s timhl esi uz poradis. takhle to je odolne i na zvetseni coz to tve neni. to tve by pri zvetseni ty diry zvetsovalo ! zkus. tim mim pro kazdej! cilovej pixel pocitas pixel ze zdroje. pokud pro kazdej zdorojovej pocitas cil nemas zajistene ze tim pokrejes vsechny cilove.

Este sem udal takovy experiment, ze sem si nasel ten "spatny" bod a vypsal jeho souradnice. Pak sem je spocital podle tech transformacnich rovnic na kalkulacce (TI-89) a vysledek byl tentyz jak na PC => chyba neni v zaohrouhlovani nebo implementaci sin/cos ale primo v tom algoritmu. Ono pri te rotaci dochazi i ke zmene meritka a vubec takovym zajimavym pochodum, kdy proste regulerne dojde k preskoceni nejakyho bodu...

Pokud sem te dobre pochopil, tak bych mel projizdet po radkach celou obrazovku a zistovat, jesi se nahodou bodem z obrazovky netrefim do zdrojove bitmapy.

To je ale pro muj ucel trochu nevyhodny, kdyz budu kreslit jeden mrnavej rotovanej obrazek na velikou obrazovku, tak budu muset projit stejne veschny body na obrazovce. Pro tvuj ucel to nevadi, tam chces naopak zaplnit celou obrazovku. Kdyz ale ja bych chtel jen fci na vykresleni jednoho obecne natocenyho obrazku, kterej zdaleka nemusi pokryvat celou obrazovku.

Samozrejme ze kdybych chtel pritom este zvetsovat nad 100% tak bych musel vznikajici prazny mista vyplnovat nakou interpolaci (coz u palety asi nee) nebo nejblizsim sousedem.

Mzna ze mas pravdu, ze to ani jinak delat nejde, ale me to furt vrta v hlave...

aby si kreslil jen kousek musel by si na to jit jinak. treba si brat jen cast obrazovky, ze a ne celou, kolik ji vemes je jedno. to jde uz jen o posuny v te bitmape. nebo si napocitat obrys tim tvym a vyplnit mim :/ jinak nevim

Tak neska mam po zkousce (sice ne zrovna z programovani), se na to konecne mrknu a zkusim to podle tebe. S tim obrysem by to slo, ze bych si pro zacatek stanovil okno na obrazovce a prochazel jen to.

Koukam, ze z toho rotozoomera se za chvili vyklube nova implementace softwaroveho OpenGL :wink:

No trosku se amatersky programovanim grafiky zabyvam... SW opengl z toho ale nebude, od toho tu je uz MESA ci Allegro a pod. knihovny. Ikdyz zas nejsou nejmensi a mozna ani ne nejrychlejsi.
Jinak si Glottis zaslouzi za sve dilo jisty obdiv, padz pure ASM coderu je uz jako safranu.

hehe :) neprehanej zase. to byla semestralka pro vsechny vypocetkare 5 semestru FELu. teda ne kazdej mel rotozoomer :) sem byl jedinej. ale na to ze sem v tom delal prvni semestr sm prekvapenej ze to jde zvladnout :)

a ze to je pure ASM vyplyva z me lenosti si shanet stare C a nebo pascal abych mohl udelat vkladanej asm :) programatori jsou liny prasata :))) jak rikal nas cvicici na asm :) radsi budou va dny psat prog na neco nez aby to udellai rucne :)

OK to sem trochu prehnal, inac bys asi nemel zapocet co? ;D
Jinak nevim v cem horsi/lepsi by mel bej vkladanej ASM z C, takle je to prave ono. Proste sem chtel jen naznacit ze je dobre, kdyz se lidi este uci a umi neco v ASM, padz se cimdal tim vic dela stylem: at to ma hezky wokynka, je to veliky a pomaly (od toho je prece upgrade PC) a hlavne je to HNED. Obdivuju dila jako vyse zminovane Second Reality, myslim ze uz by neco takoveho (aby to chodilo i na tehdejsich 386) svedl malokdo. Dneska se vecina dem pise pro D3D/Ogl a pak to taky podle toho vypada, jen par z nioch vycniva z sedeho prumeru libive akcelerovane grafiky. Proste oldskool rulez.

:) hlavne kdyz se ted zacina vsude ucit JAVA. sem na ni uz alergickej.

Mno ja se v tehlech modernich a hlavne visual jazykach nak moc necapu...

Tak neska sem to zkusil udelat, jax rikal, obracene a FUNGUJE to!
Ale nepouzil sem tam zadny arctan a pod, jen sin cos:

Kód:

---

  sincos(&cosa,&sina,PI*angle/180.0);  // preved uhel na radiany a spocni sin cos
  for &#40;j=y1; j<y2; j++&#41;                // pres vsechny radky v boundboxu
    for &#40;i=x1; i<x2; i++&#41;              // pres vsechny body radku boundboxu
      &#123;
      x=0.5+img_xmid+mag*&#40;&#40;i-image.xofs&#41;*cosa-&#40;j-image.yofs&#41;*sina&#41;;
      y=0.5+img_ymid+mag*&#40;&#40;i-image.xofs&#41;*sina+&#40;j-image.yofs&#41;*cosa&#41;;
      if &#40;&#40;x>0&#41;&&&#40;y>0&#41;&&&#40;x<image.xres&#41;&&&#40;y<image.yres&#41;&#41; // jsou-li x,y platne souradnice v obrazku
        vesa_putpixelu&#40;i,j,image.p_imgbuf&#91;x+y*image.xres&#93;&#41;; // vykresli je na aktualni pozici
//      else
//        vesa_putpixelu&#40;i,j,255&#41;;        // vykresli boundbox-pro kontrolu
      &#125;

---

Abych zbytecne neprejizdel celou obrazovku, tak si napred spocitam hranice, pres ktery mi to nepreleze a pak jedu uvnitr. Taky pocitam sin a cos pomoci jedny funkce, ktera by mea bejt rychlejsi. Samozrejme vne cyklu, ikdyz to by kompajler za me stejne zoptimalizoval.
V tomle programu sem nechal bile vykreslovat ten boundbox:
http://www.volny.cz/xfer/4all/rotate3.exe

Docela me to zaujalo a tak sem to dotah do konce, a udal z toho taky poradnej rotozoomer + benchmark.
http://www.volny.cz/xfer/4all/rotozoom.exe
Bez parametru vypise napovedu k ovladani, umi nacitat TGA a GIFy.
Este sem zkompilil jednu verzi pro Pentium 4:
http://www.volny.cz/xfer/4all/rotozoom-p4.exe

Aby ten benchmark mel smysl, tak se samozrejme musi vypnout synchronizace a zvetsit obrazek tak, aby se kreslilo po cely obrazovce.
FPS se pocitaj mezi jednotlivejma volanima statusu, po par merenich by to melo bejt ustaleny. Me to dela asi 118FPS. S optimalizaci -funroll-all-loops -mpentium3 -mmmx -msse to bylo 122FPS.

Sem docela zvedavej jak to pojede na P4 a hlavne jakej bude rozdil mezi tou normalni a P4 verzi, ale ten zrovna zadny po ruce nemam, tak to nekdo zkuste.

poc pekneee :)) mno jo to se to pise v cecku :) me to dava na p3 866 asi 84 fps :) p4 tu nemam tak nereknu :/ mozna az prijde bratr tak to zkusim u nej

Mne to hodilo 157FPS na Tualatine, na Cyrixe je to slabe - 18FPS...

Taks to mel napsat taky v C a pak to profesorovi disassemblovat ;D

Este sem to zkousel na P133 - 16,5 FPS

kdyz sem zkusil pustit tu p4 verzi tak me to hodilo invalid opcode, takze by to melo nove instrukce opravdu vyuzivat.

Este premejsim jak to udelat v truecolor modu s bilinearnim filtrovanim pri zvetsovani. Interpolovat po radkach neni problem, ale neni to ono. Myusi se to delat i svisle. Ale uz by to bylo asi dost pomaly...

ja nekde vydel nejaek filtrovani a bylo to dost rychle, bohuzel nevim kde :(

Tak muzeme pokracovat tady:
http://www.overclocking.cz/4um/viewt...=530252#530252

Jak sem zistil, tak na tom airwolfove P4-Celeron to nebeha vubec spatne!

Kdyz vemu ze pomer frekvenci mojeho a airwolfova P4 celeronu je 2.057 (ted bezim na 1055) a pomer FPS je 1.926 a vzhledem k tomu ze to je JEN celeron (ikdyz to moje taky) tak je to vcelu odpovidajici, nemyslite?

U neoptimalizopvaneho kodu byl vysledek mnohem horsi. A v tom to asi bude. Lidi pouzivaji programy prelozeny a optimalizovany pro P2+MMX ci pentium a pod a pak nadavaji na P4, jak to na nem bezi pomalu oproti AMD.

Zde sem udal nekolik verzi rotozoomeru opt. pro ruzny CPU, takze sem zvedavej, jak se AMD ukazkou. No flame ;D