[elektro] Vonal rajzolás

[Horvath Janos]

>> ELeve van ugye a 8-ad, de nagyon kicsi korokkel kulonben sem lehet sokat 
>> kezdeni,
>> vagy a pixelkirako kerekit, vagy az aritmetika, mar ha sin/cos-os a 
>> rutin. Inkabb nekem az volt a gondom, hogy hogyan lehet paros 
>> pixelmeretu atmeroju kort rajzolni, de aztan mas dolog akadt...
> 
> Most arra gondolok, hogy valamelyik algoritmus, nem tudom mi a neve, igen 
> jol lathatoan sokszog alaku kort rajzol, mondjuk olyan 8-12 pixel atmero 
> alatt, meg a sin/cos azert sokkal jobb.

Jaaa, azt asszem nem ismerem, amit en hasznaltam az gyors, olyasmi mint
a vonalhuzas, de csak 1/8-adot tud. Onnantol tukrozessel meg van a 
tobbi,ami LCD-nel jo, de ha mechanikat kell mozgatni, akkor
8x neki kell esni. Mondjuk akkor is gyorsabb mint a sin/cos. Sajnalatos,
hogy nem lehet vele emiatt ellipszist meg tetszoleges szogtartomanyu 
korivet rajzolni, de asszem nekem nem is kellett. Viszont nagyon gyorsan 
lehet fillezni a kort.

>> Ja, hat ha van. Altalaban nincs, legalabb is nalam.
>> Sajnos az olyan kijelzoket, amelyekbol nem lehet visszaolvasni, 
>> mindenkepp RAM pufferelni kell, ha grafikat akarok hasznalni :(
>> Olcso, kicsi kontrollerekben meg ritka a felesleges 1-2-4k RAM.
>> A megrendelo meg vonyiiiiit, ha 500Ft-al dragabb/nagyobb uC-t akarok 
>> hasznalni.
> 
> A tenyek sajnos komoly dolgok, a megrendelo ket lehetoseg kozul tud valasztani:
> - dragabb uC, es gyors lesz
> - lassabb lesz a grafika
Az en megrendeloim 500Ft alatti uC-vel kernek real-time 3D grafikat :)

> Ha az LCD-bol kiolvasas ciklusideje x ns vagy us, akkor annyi, ezt nem lehet 
> megkerulni.
> 
>>> legkevesbe hatekony. Ha tobb egymast koveto putpixel ugyanarra a byte-ra ir, 
>>> akkor ki lehet irni egy lepesben is. Ennek viszont az a hatranya, hogy 
>>> egyaltalan nem portabilis, ha mas szervezesu kijelzore kell a kod, teljesen 
>>> at kell irni.
>> Igazad van, de amikor en agyaltam ilyen optimalizacion, arra jutottam,
>> hogy az allandoan vegrehajtott feltetelvizsgalatok annyit lassitanak
>> a dolgon, mint amit talan nyernek 6-8 pixel egyszeri kirakasaval.
>> Persze ha csak vizszintes vonalakat rajzolok, akkor gyors...
> 
> Hat azert nem eppen. Meg ha a kijelzo olyan gyors is, hogy varakozas nelkul 
> lehet visszaolvasni belole, akkor mondjuk egy 8 pixel magas fuggoleges vonal 
> kiirasa az egyik esetben 8 olvasas + 8db OR + 8 iras, meg 1 lepesben 
> mindegyikbol 1db. Ha ablakkezelo rendszert irsz, akkor pedig a fuggoleges 
> vonal nem is annyira ritka. Es akkor meg nem beszeltunk a betutipusokrol, 
> ami sokkal tobb pixel.
> 
> Nem kell ebbe rengeteg feltetel vizsgalat. Fugg./vizsz. vonal, betu kiiras, 
> terulet feltoles (fill), igen jol optimalizalhato. A kulonfele alakzatok, 
> kor, egyeb vonal, persze mar nehezebb, de ezek talan nem is fontos hogy 
> optimalizalt legyen, ha csak egy sima GUI-t akarsz irni nem pedig 
> vektorgrafikus programot.
Jaaa, persze, nem is ugy gondoltam en sem, hogy egy karakter pontonkent 
megy ki.
Ha ilyen van, akkor termeszetesen byte-os irasok mennek, nekem most a 
grafikarol az ossze-vissza egyenesek jutottak eloszor eszembe.
Most mar ertem, mit probalsz a buta fejembe verni :)

JAni
14:38