#107474 - Dark Knight ez - Sun Oct 29, 2006 11:41 pm
Hey everybody.
I've been working on using an extended rotation background (in mode 3) to display an image (framebuffer style) of about 32x32, which is then stretched with hardware to be 2.5 times larger or so.
I used a 16-bit bitmap of 128x128 to do this so I can also do a lot of other things with other backgrounds (as it doesn't take up all of BG_GFX_SUB).
I came across a problem though, and after having searched this forums, I'm not sure if there's a solution at all.
I would like the not-filled up area of the bitmap (what is left by the 32x32 image) to be transparent.
Apparently, when I initialize the first 128*128 entries of BG_GFX_SUB before drawing the 32x32 image makes the entire background pink (which is palette entry 0).
If I set it all to BIT(15), it results in something else, can't exactly describe it, but also not transparent.
Is it possible at all to have stuff of the bitmap transparent?
I mean, isn't it also done with most "text on screen" functionality? I always though that was actually an extended rotation background and used as framebuffer. Please enlighten me.
Oh, I should mention that there are like 2 active background layers behind this one, so it's not like there's nothing to be displayed below it which causes the displaying of the first palette entry.
Greets,
Dark Knight ez.
#107479 - Lick - Mon Oct 30, 2006 12:30 am
Show us some code!
_________________
http://licklick.wordpress.com
#107505 - Dark Knight ez - Mon Oct 30, 2006 9:37 am
Why? I just told you precisely what I did.
But alright, if you insist. Here are the relevant snippets for background3:
| Code: |
SUB_DISPLAY_CR = (MODE_3_2D |
DISPLAY_BG0_ACTIVE |
DISPLAY_BG3_ACTIVE |
DISPLAY_BG2_ACTIVE |
DISPLAY_SPR_ACTIVE |
DISPLAY_SPR_1D |
DISPLAY_SPR_1D_BMP
);
SUB_BG3_CR = BG_PRIORITY_1 | BG_BMP16_128x128;
SUB_BG3_XDX = 1<<8; // scaling of 1 (this is adjusted later on)
SUB_BG3_XDY = 0;
SUB_BG3_YDX = 0;
SUB_BG3_YDY = 1<<8; // scaling of 1 (this is adjusted later on)
SUB_BG3_CY = 0;
SUB_BG3_CX = 0;
vramSetBankC(VRAM_C_SUB_BG);
|
And I was trying to achieve transparency by doing either:
| Code: |
for (i=0; i<(128*128); i++) // (128*128) being the size of this BG
BG_GFX_SUB[i] = 0; |
And I also tried by doing:
| Code: |
for (i=0; i<(128*128); i++) // (128*128) being the size of this BG
BG_GFX_SUB[i] = BIT(15); |
Both methods failed.
The actual displaying of the 32x32 image in the 128*128 bitmap background works properly with statements such as:
| Code: |
| BG_GFX_SUB[j+i*128] = RGB15(26,18,11) | BIT(15); |
where j represents horizontal offset and i vertical offset.
#107597 - Dark Knight ez - Tue Oct 31, 2006 10:33 am
Does the lack of responses mean that it can't be done?
ERBs and transparency are a no go?
#107599 - DekuTree64 - Tue Oct 31, 2006 10:43 am
Clearing bit15 of a pixel SHOULD make it transparent... not sure why it wouldn't, since it looks like that's what you're doing in the loop setting everything to 0. What did it look like when you did that?
On a side note, another option which would save some VRAM would be to use a bitmap sprite. You can only scale them to 2x the original size, but you could use a 64x64 sprite with a 16 pixel border of transparent around the 32x32 image, to get enough room for 2.5x original size. Although then you'll have the exact same problem getting the pixels to be transparent, since bitmap sprites use bit15 as transparent/opaque too.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#107601 - Dark Knight ez - Tue Oct 31, 2006 11:03 am
About your side note:
The 32x32 image is dynamicly generated and each individual pixel of it can (and probably will) change. Thus I'd rather not use sprites as I'd have to use 32*32 sprites for this purpose.
| Quote: |
| What did it look like when you did that? |
Well, the entire screen went pink (except for that 32x32 image since that overwrites the set 0s), with the sprites still showing. The entire screen being affected is probably due to BG3 having high priority and the stretching out I did.
#107607 - gmiller - Tue Oct 31, 2006 1:30 pm
Since I only do this on the GBA side it might not apply in the DS mode. In GBA mode there is a global register that defines how the blending occurs and what layers blend. If those registers don't get set then the set/clear of the transparency bit does almost nothing. Of course this might not apply in DS mode.
#107618 - josath - Tue Oct 31, 2006 5:21 pm
| Dark Knight ez wrote: |
About your side note:
The 32x32 image is dynamicly generated and each individual pixel of it can (and probably will) change. Thus I'd rather not use sprites as I'd have to use 32*32 sprites for this purpose.
|
I'm not sure I understand your complaint here. You know you can dynamically change sprites just as easily as you can dynamically change a BG, right?
#107634 - Dark Knight ez - Tue Oct 31, 2006 7:22 pm
@Josath
It would require more than 128 sprites... copying during HBlanks.
I'm already going to do that for the bottom (main) screen, and I want to keep the top screen simple. It's just really unnecessary to make things more complicated than they are there, when I might be able to use this BG instead.
@gmiller
I'll have to check for such a register in libnds then... might be just what I need.
#107636 - josath - Tue Oct 31, 2006 7:29 pm
| Dark Knight ez wrote: |
@Josath
It would require more than 128 sprites... copying during HBlanks.
I'm already going to do that for the bottom (main) screen, and I want to keep the top screen simple. It's just really unnecessary to make things more complicated than they are there, when I might be able to use this BG instead.
. |
I'm confused, why would you need so many sprites? In your first post you said you only needed a single 32x32 image. Or are you saying you need many sprites for something else? Anyway, it should work with the BG, I would check to make sure all the priorites and things are set correctly.
#107637 - Dark Knight ez - Tue Oct 31, 2006 7:37 pm
A 32x32 image of which each individual pixel can change dynamicly. Really easy to implement a radar this way (each pixel representing a game-tile).
Plus, using the BG I can upsize this image to be bigger, without adjusting each pixel's size by hand.
Priorities are set correctly.
I'm trying fiddling with the blending register now. Doing the following
| Code: |
| SUB_BLEND_CR = BLEND_ALPHA | BLEND_SRC_BG3 | BLEND_DST_BACKDROP; |
makes the 32x32 image dissapear and leaves the pink (palette entry 0) all around it. What am I doing wrong? Or is this only used for entire BGs transparency instead of only palette entry 0?
#107644 - Lick - Tue Oct 31, 2006 8:23 pm
If it shows pink, then the layer does the transparency just fine! The problem is probably in the other layers.
Also, just to make sure: I assume you're running on hardware, right?
_________________
http://licklick.wordpress.com
#107645 - Dark Knight ez - Tue Oct 31, 2006 8:28 pm
Yes. Using hardware. Only hardware. Always. ;)
And how do you figure transparency is fine when pink shows? That's palette entry 0... the actual thing I want _not_ to show up. There are layers hidden beneath that pink. :\
#107646 - Lick - Tue Oct 31, 2006 8:33 pm
Well, that's the color when NOTHING is displayed right? So I'm thinking that it shows up like this:
| Code: |
Your eyes ----> DS ( bitmap | empty | empty | empty | pink )
|
That's just what I'm suspecting at the moment. You should really show us some code, since your description seems fine to me, so it's probably something nasty in your code (for all layers)?
And also, blending isn't necessary since this is DEFAULT behavior of the layers. If it isn't, then someone will have to bitchslap me.
- Lick
_________________
http://licklick.wordpress.com
#107648 - Dark Knight ez - Tue Oct 31, 2006 8:42 pm
No no no no...
The backgrounds 0 to 2 have some content and if I disable background 3 then stuff is displayed.
Setting background 3 to have every pixel as "0" makes it display the pink colour (even though backgrounds 0 to 2 are below that background!).
So transparency fails.
| Quote: |
| And also, blending isn't necessary since this is DEFAULT behavior of the layers. If it isn't, then someone will have to bitchslap me |
It's... not working for me.
#107653 - josath - Tue Oct 31, 2006 10:25 pm
| Dark Knight ez wrote: |
A 32x32 image of which each individual pixel can change dynamicly. Really easy to implement a radar this way (each pixel representing a game-tile).
Plus, using the BG I can upsize this image to be bigger, without adjusting each pixel's size by hand.
Priorities are set correctly.
I'm trying fiddling with the blending register now. Doing the following
| Code: | | SUB_BLEND_CR = BLEND_ALPHA | BLEND_SRC_BG3 | BLEND_DST_BACKDROP; |
makes the 32x32 image dissapear and leaves the pink (palette entry 0) all around it. What am I doing wrong? Or is this only used for entire BGs transparency instead of only palette entry 0? |
You can change every individual pixel in a single sprite dynamically. Just write to the correct location in VRAM.
#107654 - Dark Knight ez - Tue Oct 31, 2006 10:34 pm
Cool. I didn't know that. Still.... I'll quote myself.
| Quote: |
| Plus, using the BG I can upsize this image to be bigger, without adjusting each pixel's size by hand. |
Having it as a BG which I can then resize would be a lot nicer. Not having to calculate the amount of pixels I need to fill with a certain colour in order to make the 32x32 image stretched out.
(I said 32x32 as that's the current level game map's size. I'm resizing that to be displayed bigger.)
#107663 - Dark Knight ez - Wed Nov 01, 2006 12:07 am
Apparently, I'm overwriting my BG GFX used by the other (underlying) BGs with the radar.
Need to figure out why that happens...
Isn't using BG_TILE_BASE(1) for BG GFX for the other BGs good enough to avoid overwriting by the 128x128 sized BG3?
#107667 - DekuTree64 - Wed Nov 01, 2006 12:21 am
Ah, that would do it. A 128x128 16-bit bitmap is 32KB. One char base block is 16KB. So BG_TILE_BASE(1) refers to the middle of the bitmap, which is of course transparent if only the upper left 32x32 is used.
Try BG_TILE_BASE(2) instead. Also, make sure the screen blocks for other BGs don't overlap anything either. Screen blocks are 2KB each, so 0-15 overlap the bitmap, 16-23 overlap char base 2, and 24-31 overlap char base 3.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#107668 - Dark Knight ez - Wed Nov 01, 2006 12:24 am
I put the screenblocks all at the end (29 to 31).
I'll quickly try BG_TILE_BASE(2).
Make that not so quick... something's wrong. I'll continue tomorrow when I'm more awake.
edit:
Victory. Got it to display correctly now.
(Also had to change the graphics loading in to CHAR_BASE(2) of course.)
Thanks to everybody for giving advice on this. I really appreciate it.
#107725 - Lick - Wed Nov 01, 2006 4:22 pm
Yeah this is what I suspected, that's why I asked for your code.
Remember to use these defines in your BGx_CRs:
BG_TILE_BASE(n), BG_MAP_BASE(n) and BG_BMP_BASE(n).
And when accessing the data simply use:
((u16*)BG_TILE_RAM(n)), ((u16*)BG_MAP_RAM(n)) and ((u16*)BG_BMP_RAM(n)).
On the SubCore, append _SUB.
_________________
http://licklick.wordpress.com