#130092 - AdolescentFred - Wed May 30, 2007 9:57 pm
I'm new to DS programming and I'm having trouble using extended backgrounds. I can't see the problem with the code, especially because most of it is copied from examples.
| Code: |
int main(){
videoSetMode(MODE_5_2D | DISPLAY_BG2_ACTIVE);
vramSetBankA(VRAM_A_MAIN_BG_0x06000000);
BG2_CR = BG_BMP16_256x256 | BG_BMP_BASE(0) | BG_PRIORITY(3);
BG2_XDX = 1 << 8;
BG2_XDY = 0;
BG2_YDY = 1 << 8;
BG2_YDX = 0;
BG2_CY = 0;
BG2_CX = 0;
u16 *BG_BUFFER = (u16*)BG_BMP_RAM(0);
int x,y;
for(y=0;y<192;y++){
for(x=0;x<256;x++){
BG_BUFFER[y*256 + x] = page_bin[y*256 + x];
}
}
} |
I have a feeling the problem lies in the copying of the pixmap into VRAM, because I wasn't really sure what to use to copy it. dmaCopy() didn't work either. I just get a black top screen and a white bottom one.
thanks for any help anyone can give.
~Fred
#130098 - GPFerror - Wed May 30, 2007 11:26 pm
| AdolescentFred wrote: |
I'm new to DS programming and I'm having trouble using extended backgrounds. I can't see the problem with the code, especially because most of it is copied from examples.
| Code: | int main(){
videoSetMode(MODE_5_2D | DISPLAY_BG2_ACTIVE);
vramSetBankA(VRAM_A_MAIN_BG_0x06000000);
BG2_CR = BG_BMP16_256x256 | BG_BMP_BASE(0) | BG_PRIORITY(3);
BG2_XDX = 1 << 8;
BG2_XDY = 0;
BG2_YDY = 1 << 8;
BG2_YDX = 0;
BG2_CY = 0;
BG2_CX = 0;
u16 *BG_BUFFER = (u16*)BG_BMP_RAM(0);
int x,y;
for(y=0;y<192;y++){
for(x=0;x<256;x++){
BG_BUFFER[y*256 + x] = page_bin[y*256 + x];
}
}
} |
I have a feeling the problem lies in the copying of the pixmap into VRAM, because I wasn't really sure what to use to copy it. dmaCopy() didn't work either. I just get a black top screen and a white bottom one.
thanks for any help anyone can give.
~Fred |
change to this
| Code: |
| BG_BUFFER[y*256 + x] = page_bin[y*256 + x] | BIT(15); |
Have to set this bit in 16bit mode.
Troy(GPF)
#130157 - AdolescentFred - Thu May 31, 2007 10:53 am
thanks it's displaying now but not correctly. I knew that I had to set the alpha bit, but i thought that it was done already because I used
"bmp2bin -d"
to generate the bin file and option d says:
"16 bits output, x1b5g5r5, DS, x bit set"
The colours are all wrong and there are horizontal and vertical lines and I don't know what the problem is.
#130162 - mml - Thu May 31, 2007 11:25 am
Try making a test-pattern image (ie, an image with some repeating pattern) and use that, then run it in emulation and use the magnifying glass app to zoom in and look at how its distorted. Since you know from the pattern where the pixels are supposed to be, you can work out where they're being relocated to, which might provide you some hint as to what's going wrong.
#130163 - AdolescentFred - Thu May 31, 2007 11:53 am
I've never managed to get an emulator to run under linux, but i tried a pattern on the hardware and i've solved the problem.
page_bin is from page_bin.h which was generated by the Makefile (I used the defualt one) and it was defined as u8 where it should be u16. It was displaying wrong because it was doing 8bit reads and 16bit writes. I changed it to u16 and it displays perfectly now.
Thanks for your help GPFerror and mml
#130168 - mml - Thu May 31, 2007 12:40 pm
Are you using git/grit to convert your image data to .s/.h files? It has an option for specifying the output data type. It defaults to u32 according to grit --help, so if you are using git/grit, it could be your foo.git is overriding that to output u8's instead. The "correct" fix would then be to change this to output u16's, so if you modify the source image later you don't have to hack the .h by hand again.
You might not be using it though -- I don't remember what the default Makefile used for converting graphics, but I do remember needing to change it in a few places to get it working for me (and get an endianness fix for git from Cearn, since I'm dev'ing on PPC hardware) -- but maybe that's just because I was a noob and doing something wrong.
#130169 - Dark Knight ez - Thu May 31, 2007 12:51 pm
What's all the fuss about? There's no need to "hack" .h files by hand or whatever.
| Code: |
| ((uint16*)page_bin)[y*256 + x]; |
Voila. No hacking .h files. No worrying about whether they are u8s, u32s, whatever.
_________________
AmplituDS website
#130180 - AdolescentFred - Thu May 31, 2007 3:45 pm
| Dark Knight ez wrote: |
What's all the fuss about? There's no need to "hack" .h files by hand or whatever.
| Code: | | ((uint16*)page_bin)[y*256 + x]; |
Voila. No hacking .h files. No worrying about whether they are u8s, u32s, whatever. |
Thats exactly what i've done
@mml: i've used gfx2gba for converting tile gfx to .bin, and for this I used bmp2bin, both of which come with devkitarm. The makefile builds them in using some bin2s magic or something, and generated the headers in the build dir.