Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: Jeded Vojka 27. 03. 2018, 01:00:09
-
Zdar!
Mám takovouhle strukturu:
// A 4x4 pixels sprite block
unsigned char filled_block[2]={0xFF,0xFF};
a tu potřebuju na souřadnicích x,y nějak zobrazit. Měl by to být černý čtvereček 4x4 pixely.
Zkoušel jsem TextOut(hdc, x,y, filled_block,1); ale nevezme mi to při překladu parametr 4.
A taky to nechci volat jen ve WM_PAINTu, ale někde jinde v kódu.
Jak mám tu strukturu zobrazit v okně pomocí Win32Api?
-
Winprog.org/tutorial/bitmaps.html
-
jak zobrazit číslo? filled_block[2]? černý čtvereček 4x4 pixely? TextOut(hdc, x,y, filled_block,1)?
nevezme mi to při překladu parametr 4? nechci to volat jen ve WM_PAINT??
To je blbý vtip, nebo blbý trolling?
-
jak zobrazit číslo? filled_block[2]? černý čtvereček 4x4 pixely? TextOut(hdc, x,y, filled_block,1)?
nevezme mi to při překladu parametr 4? nechci to volat jen ve WM_PAINT??
To je blbý vtip, nebo blbý trolling?
mozna ze do toho autor zamichal dva ruzne ukoly.
-
mozna ze do toho autor zamichal dva ruzne ukoly.
a trochu LSD
-
Na daný problém by mohlo fungovat FillRect se štětcem typu pattern brlush (viz CreatePatternBrush), ale nejsem si zrovna jistý, zda takový postup v případě čtyř pixelů bude rychlejší než prostě čtyřikrát zavolat SetPixel.
-
Na daný problém by mohlo fungovat FillRect se štětcem typu pattern brlush (viz CreatePatternBrush), ale nejsem si zrovna jistý, zda takový postup v případě čtyř pixelů bude rychlejší než prostě čtyřikrát zavolat SetPixel.
Jo, asi to udělám nějakým "Rectanglem", ale šlo mi o to, jestli třeba nějak nejde tahle číselná interpretace přímo zobrazit. Jinak těch pixelů je 16. Takže SetPixel by se musel volat 16x pokaždé a bylo by to hrozně pomalé.
Ale jo, dík za odpověď.
-
Přímo jde zobrazit jako bitmapa monochromatická, akorát je potřeba ji z vždy vytvořit, což vzhledem k tomu, že zobrazujete 16 stavů pomocí 16 bitů, je lepší řešit nakešováním těch bitmap.
-
Přímo jde zobrazit jako bitmapa monochromatická, akorát je potřeba ji z vždy vytvořit, což vzhledem k tomu, že zobrazujete 16 stavů pomocí 16 bitů, je lepší řešit nakešováním těch bitmap.
Grr, píšu rychleji než myslím. Stavů je víc než 16, samo :-)
Zkuste to pole vrazit jako parametr lpbInit funkci CreateDIBitmap, bV5BitCount bude 1, tedy každý bit bitmapy představuje pixel.
-
... Jinak těch pixelů je 16. Takže SetPixel by se musel volat 16x pokaždé a bylo by to hrozně pomalé. ...
Mnoo.
Čistá možnost je, udělat to přes bitmapu. Ale to při každém vykreslení stejně znamená udělat memory DC (CreateCompatibleDC), selectovat do něj tu bitmapu a pak bitblt na reálné DC. Což je také zatraceně pomalé. Cacheovat by se možná dalo, ale pozor - jakmile by došlo k přesunu na jiný monitor (s jiným nastavením barev), či si uživatel změnil nastavení třeba hloubky barev (jde bez restartu), změnil použité graf. karty (u NB lze často vybrat interní kontra externí) a 100+1 podobně, tak by starý cache IMHO byl problém a potřeboval nové compatibleDC. Takže zase opruz s tím to hlídat.
V takovém světle by 16x SetPixel by možná mohl být nejen univerzální, ale možná i rychlejší. Pokud to vždy bude do těch cca 16 a ne řádově více.
P.S.: Vykreslovat kdykoli "někde jinde v kódu" lze přímo do DC (GetDC), ale ... na WM_PAINT to stejně musí umět reagovat (pro případ požadavku překreslení zvenku - odkrytí okna jiným, a podobně) .... takže častokrát bývá jednodušší, namísto dalšího vykreslování zavolat InvalidateRect (pro odpovídající čtverec) + případně UpdateWindow, pokud potřebuješ překreslit ihned.
-
Na daný problém by mohlo fungovat FillRect se štětcem typu pattern brush (viz CreatePatternBrush) ...
To už bývá jednodušší (spolehlivější) udělat to přes compatibleDC a bitblt.
Protože CreatePatternBrush potřebuje bitmap stejně jako memory DC. I pokud použiješ monochrome bitmap, stejně si pokaždé dělá konverzi, jako při SelectObject do memDC. Tu konverzi prostě vždy někdy udělat musí, z obecné bitmapy na konkrétní vlastnosti /hloubky barev, .../ DC.
Navíc mám pocit, že při použití jiného než solid brush mívalo (hodně historicky) problémy s kompatibilitou, protože obecný brush (interně asi) fungoval obdobně jako bitblt PATCOPY či MERGECOPY z prázdného zdroje, což někdy nebývalo v DC podporováno (či blbě). Kdežto klasické bitblt SRCCOPY (ruční kopie z předpřipraveného memDC) neselhalo snad nikdy (nad rasterovým DC). Ale teď už je to snad jedno.