 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : CMM2: PNGs, BLITs and transparency in 12-bit mode
| Author | Message | ||||
| electrotrains Newbie  Joined: 29/07/2020 Location: United KingdomPosts: 13 |
Hi, I'm slightly confused by how we populate the alpha channels in 12 bit mode. As far as I understand it- we've got 2 (stacked) layers, each layer has 16 bits per pixel, with 4 bits each of R,G,B & A per pixel. If I have a PNG file with alpha channel, I was expecting LOAD PNG to set the alpha bits correctly in the PAGE I load it into. However, the documentation for LOAD PNG which talks about a transparency_cut_off value makes me think otherwise. Is the end result of LOAD PNG always going to be pixels with alpha values of 0xF or 0x0? Is there any other way to load assets (e.g. sprites and tiles) into a PAGE that would properly populate the alpha channel? I guess I could write C command line utility that converts the PNG to a simple binary dump of 16-bits of RGBA per pixel, then load that file into the CMM2? Second question  ... what happens with BLITs in 12-bit mode? Does it always simply copy RGBA per pixel? Does the 'orientation' option &B100 - don't copy transparent pixels - have any effect in 12-bit mode?Robin https://github.com/robinhedwards |
||||
| electrotrains Newbie Joined: 29/07/2020 Location: United KingdomPosts: 13 |
Actually I've just found this post, confirming that transparency is currently all or nothing per pixel when loading a PNG. Fingers crossed we can get a better solution in the future. Still curious about the behaviour of BLIT, when I do get my alpha channel set correctly. https://github.com/robinhedwards |
||||
| electrotrains Newbie Joined: 29/07/2020 Location: United KingdomPosts: 13 |
Doing some experiments with BLIT in 12-bit mode it seems that: if BLIT orientation = &B000, dst RGBA = src RGBA if BLIT orientation = &B100, dst RGBA = unchanged, if src A = 0 = src RGBA, if src A = F (src = source pixel, dst = destination pixel) So it looks like &B100 does what I would hope and uses the alpha channel, though I haven't tried intermediate alpha values yet. Robin https://github.com/robinhedwards |
||||
| at67 Newbie Joined: 02/07/2020 Location: AustraliaPosts: 6 |
From the manual: &B100 = don't copy transparent pixels. This reads to me as a standard alpha test/rejection, i.e. if the alpha component of your source pixel < max(component), (probably 15 in 12 bit mode), then reject the pixel. If this is the case, then intermediate values of alpha, (i.e. 0 <-> 14) will be treated as if they were 0. I've read somewhere that the hardware supports true read-write-modify blending in these alpha supported modes, (known as 12bit mode in the CMM2 SW eco system), but that would imply that there is some sort of inherent hardware blending going on. If there is true hardware blending available, then there should be some sort of blending equation that defines the amount of blending that occurs between source and destination, typically: DST = SRC*a + DST*(1-a) Edited 2020-08-05 00:13 by at67 |
||||
| electrotrains Newbie Joined: 29/07/2020 Location: United KingdomPosts: 13 |
Hoping your interpretation of the manual is wrong . Otherwise the alpha channel in 12-bit mode is somewhat crippled. While I can write my own sprite/tile loader in BASIC, I can't really write my own BLIT!https://github.com/robinhedwards |
||||
| at67 Newbie Joined: 02/07/2020 Location: AustraliaPosts: 6 |
I've just done some quick RTFM and research on the STM32 LTDC: Peruse Peter's thread here for a great explanation of the basics, (scroll down to the 12bit-modes message): https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=12125 It seems the hardware supports 2 distinct layers and a background that are composited together into a final output image using blending, the hardware also supports true read-modify-write DMA accesses between the layers and background, (i.e. hardware blending operations at the pixel level), and seems to be extremely configurable in terms of the blending equations, input, outputs, etc. I would guess that Peter has setup default blending equations, (similar to what I posted earlier), between the layers and the background, so that if you want to perform true alpha blending, (not alpha-reject or colour-key), then you need to use the layers system. Feel free to correct, or add missing information, etc. P.S. If my interpretation is correct, then you would want to setup your background and 2 layers according to the priority of your scene and then just blit to one of the 2 layers using a DST = SRC blit, (i.e. a raw copy), and let the hardware auto-magically do the blending for you based on the values contained within each of the layer's pixels. P.P.S. You're probably going to have to generate the alpha values within each source pixel/image yourself, (in code), as the inbuilt image loaders seem to always assume a colour-key/alpha-reject paradigm with the alpha component. What I will probably do tomorrow is code up a CSUB TGA loader that doesn't interfere with the alpha component of loaded images. I always find TGA to be much simpler, efficient and less intrusive in terms of crapping over your image when writing graphics code. Edited 2020-08-05 00:50 by at67 |
||||
| electrotrains Newbie Joined: 29/07/2020 Location: United KingdomPosts: 13 |
Hi at67, Thanks for reply - yes I'd read that post (and the PDF version included with the latest firmware). But sadly it doesn't talk about BLITting between pages in a 12-bit mode context. So while I can get graphics on each layer with the alpha set correctly using COLOUR RGB(....), BOX and other graphics primitives, I really want to do it by BLITting assets from another PAGE (originally loaded from a file). I guess I can do some experiments later tonight to try to see what's happening. Robin https://github.com/robinhedwards |
||||
| at67 Newbie Joined: 02/07/2020 Location: AustraliaPosts: 6 |
I think your problem is here "originally loaded from a file", if I am interpreting the situation correctly we need a loader that doesn't colour-key/alpha-reject the alpha components of the source image pixels as they are loaded into memory. I assume there is a raw copy mode when Blitting. |
||||
| electrotrains Newbie Joined: 29/07/2020 Location: United KingdomPosts: 13 |
Sorry, missed your PSes! I'm not too concerned about the blending between the 2 layers - I think I'm clear from the documentation how this works. I'm more worried about building up the pixels for a layer in the first place (which I do to an offscreen page, then PAGE COPY it to PAGE 0 or 1). This will involve lots of BLITs, and sprites that will overlap - hence my worries about the alpha channel. Your CSUB TGA loader idea sounds good. I'd got as far as finding a C library to load PNGs, with the aim of making a command line utility that would convert a PNG into simple file with 2-bytes per pixel RBGA values. https://github.com/robinhedwards |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
