Video Ram-obsluha paměti,kreslení polygonů,otáčení obrázku

[milikiller]

Dobrý den. Již delší dobu vyvíjím vlastní vývojovou desku pro průmyslovou atomatizaci je to vlastně spíš dotekový ovládací panel. Již mám k dispozici funkční hardware a píši software. Jde o ARM7 mcu s 64Kb Ram a 512Kb flash tak že žádná výkonová bomba ale na vizualizace grafů a průběhů to dostačuje.

Mám na vás 3 dotazy.

Jak nejlépe obsluhovat video paměť? používám pro adresaci celého LCD dvourozměrné 16ti bitové datové pole o rozměrech rovnajících se rozlišení LCD , ale nejsem si uplně jistý jestli to je nejlepší metoda. Pokud chci kreslit bod o určité barvě tak jen nastavím

[Mem]

milikiller: 2D grafikou jsem se už dlouho nezabýval, ale mrkni na algoritmy kreslení čar DDA (tak předpokládám kreslíš i teď?), Bresenhamův atd. Pro konvexní polygony se myslím používá právě ten bresenhamův, pro nekonvexní to musíš větvit. Další varianta je použít nějaký vyplňovací algoritmus (flood fill, seed fill), samozřejmě si na tom ARMu asi nemůžeš dovolit rekurzivní verze, ale přepsat je na iterativní.

S tou konverzí bitové hloubky za chodu by to neměl být takový problém, ve svém starém adventure enginu, který podporoval 15/16/24bit barvy jsem přepočítával framebuffer při loadingu obrázků a s bitovým posunem to bylo rychlé:

[milikiller]

tak jsem koukal na ty algoritmy a našel jsem docela pěkné pdf
http://www.cse.unsw.edu.au/~cs3421/slides/COMP3421-pixels.pdf

A s tím přepočítávání barev to řeším uplně stejně. bitovým posunem. ale spíš jsem myslel jestli není nějaký algoritmus který umí počítat alpha kanál přímo z těch 16bpp ale to je asi uplný sci-fi. ono totiž na 60Mhz MCU si té matematiky moc dovolit nemůžeš... Ono bohatě stačí mazat-vykreslit a přeposlat do LCD 132x176 pixelů *16bit sice to stihnu zhruba při 30 fps ale stačí když dam pozadí přez celej LCD a rychlost letí někam k 10 fps. hold je to pakárna. Dneska zkusim nějak sesmolit ten Fill na ty polygony ,ale bojim se že se to všechno totálně zasekne. Uvidíme. Díky za odpověď. O tom otáčení obrázků náhodou někdo něco nevíte?

[Tringi]

Zdar, s podobnou ARM deskou zrovna taky pracuju, i když bez displeje.

Jak máš řešenu paměť toho displeje? Je zrcadlena v RAM nebo její čtení způsobí přístup k displeji? Pokud bys měl paměti víc, mohl bys mít jeden back-buffer s 24b barvami, a při blendingu (zápisu s průhledností) by ti tak odpadlo čtení a konverze. Jak široká je sběrnice k tomu displeji? Pokud je třeba 32 bitová, pak by se vše mohlo urychlit zápisem vždy dvou pixelů současně.

Nějaký chytrý a rychlý algoritmus na 16 bitovou průhlednost určitě existovat bude, zkusil bych googlit. Z hlavy ho takhle nevymyslím, ale pokud si danou grafiku přednásobíš alfa kanálem (viz google: premultiplied alpha) odpadne ti dalších pár instrukcí. Pak uděláš opačnou operaci nad pixelem v bufferu displeje, a tyto jednoduše sečteš. Tento součet pak klidně provedeš v 16 bitech, a pokud vymyslíš způsob přednásobení v 16 bitových barvách (což definitivně půjde), pak ti konverze úplně odpadně. Znáš-li OpenGL, pak se inspiruj: glBlend (GL_ONE, GL_ONE_MINUS_SRC_ALPHA).

Výplň se počítá tak, že objekt rozdělíš na trojúhelníky. Pro každý řádek si pak spočítáš, kde se s ním protínají jeho jednotlivé strany, a nastavuješ pixely od prvního průniku do druhého.

Finta v plynulém otáčení je, pro každý pixel výsledné bitmapy hledat vhodný pixel ze zdrojové bitmapy, pro vyhlazení pak váhově zprůměrovat čtyři nejbližší.

EDIT: Koukám na fotky a vidím že ten zápis na displej asi nijak nezrychlíš. Každopádně doporučuji nastudovat si instrukční sadu ARM a zkusit kritické části nabouchat v assembleru, protože ARM má mnoho instrukcí, které typický port GCC nedokáže ani použít.
S tím že to bude pomalé se budeš muset smířit a spíš vymýšlet optimalizace změn zobrazení. Tedy překreslovat jen ty části, které se opravdu změnily. Taky lze zneužít pomalou reakci displeje na zmenšení počtu kroků v plynulých přechodech a podobně.
_________________
WWW | GitHub | TW

[Hardwire]

Plnění polygonu:
http://cgg.ms.mff.cuni.cz/~pepca/lectures/pdf/fillpolygon.pdf

K otáčení obrázku bych přistupoval jako k renderování rotovaného quadu s texturou. Nejdřív bych otočil vrcholy obdélníka, ve kterém je obrázek, a postupně bych prošel oblast mezi nima, kterou mám vyplnit - např. algoritmem pro plnění polygonu viz. výše, můžeš ho optimalizovat jen na tuhle konkrétní situaci. Pro každý vyplňovaný pixel bych pak spočítal barvu z jeho pozice. Pro jednoduchost bych ze začátku jen spočítal souřadnice v textuře, zaokrouhlil je na nejbližší pixel a ten přímo vykreslil. Pak to můžeš zlepšit nějakým filtrováním (např. http://en.wikipedia.org/wiki/Bilinear_filtering).

[milikiller]

Tak zkusím nějak zodpovědět dotazy. Tak k HW který používám, jedná se o procesor LPC2106 čili arm7 s 64Kb ram a 128Kb flash. Display je moje specialitka jedná se o display z mobilního telefonu Siemens M65. Cena cca 250,- což je na tom to nejkrásnější. Ovládání LCD probíhá přez SPI cca 15MHz, ale přez SPI se dají data jen psát,tzn že celou RAM musím ukládat přímo na chipu, zabere to cca 47Kb. Potom se to celé přenáší do LCD.
Jako vstup mám k dispozici 2x Uart,1x I2C, Joystick,touchscreen, a ještě pár gpio navíc.

Co se softwaru týče tak mám zdrojáky portované pro devcpp a Keil for arm.
Nejsou žádné tajemství tak že už se tu asi 4 hodiny válí

[Hardwire]