devkitPro

Posted: **Tue Oct 18, 2011 10:41 am**

I have a problem with my background on the Nintendo DS.

I've a BG which has a resolution of 952x192. The goal is to scroll this image so that you can read it on the Nintendo DS.
What the problem is, I can't get the BG image copied to the buffer. I also have an image that is 256x192 which I can load perfectly to the buffer, and I can scroll it. But with the bigger image I can't get it done.

I have 2 bitmaps, the COMICBMP which is the image that i want to have in my app. And the HSDRAWBMP, which is the 256x192 bitmap.

This is my main code:

Code: Select all

#include "comic.h"


void create_buffers()
{
	main_buffer = (Color*)calloc(SCREEN_PIXEL_COUNT, sizeof(Color));
	//sub_buffer = (Color*)calloc(SCREEN_PIXEL_COUNT, sizeof(Color));

}



void init_displays()
{
	// Enable both screens for 2D graphics
	powerOn(POWER_2D_A);
	powerOn(POWER_2D_B);

	// Enable VBLANK interrupt
	irqEnable(IRQ_VBLANK);

	// Set up main screen (mode 5 -> two bitmap layers)
	REG_DISPCNT = MODE_5_2D | DISPLAY_BG3_ACTIVE;

	// Map memory banks to the screens
	VRAM_A_CR = VRAM_ENABLE | VRAM_A_MAIN_BG;
	//VRAM_C_CR = VRAM_ENABLE | VRAM_C_SUB_BG;

	// Main screen on the bottem
	lcdMainOnBottom();

}
/*
void init_backgrounds()
{
	// Main screen background (16 bit bitmap -> 256x256 pixels)
	REG_BG3CNT = BG_BMP16_256x256 | BG_BMP_BASE(0) | BG_PRIORITY(1);

	// Set background: no scaling, rotation and offset
	REG_BG3PA = (1 << 8); // Scale X (1.0 = 0)
	REG_BG3PB = 0; // X rotation
	REG_BG3PC = 0; // Y rotation
	REG_BG3PD = (1 << 8); // Scale Y (1.0 = 0)
	REG_BG3X = 0; // X position
	REG_BG3Y = 0; // Y position

}
 */
void init_video()
{
	init_displays();
	//init_backgrounds();
	create_buffers();
}


void copy_comic_to_buffer(Comic* comic, Color* buffer)
{
	dmaCopy(comic->image, buffer, BACKGROUND_SIZE_COMIC);

}

void scroll_comic(Comic* comic, u8 speed)
{
	// Main screen background (16 bit bitmap -> 256x256 pixels)
	REG_BG3CNT = BG_BMP16_256x256 | BG_BMP_BASE(4) | BG_PRIORITY(1);

	// Set background: no scaling, rotation and offset
	REG_BG3PA = (1 << 8); // Scale X (1.0 = 0)
	REG_BG3PB = 0; // X rotation
	REG_BG3PC = 0; // Y rotation
	REG_BG3PD = (1 << 8); // Scale Y (1.0 = 0)
	REG_BG3X = comic->offset_x; // X position
	REG_BG3Y = 0; // Y position

	comic->offset_x = comic->offset_x + speed*2;
	int i = 0;
	for(i=0; i<3; i++)
	{
		swiWaitForVBlank();
	}

}


int main()
{
	consoleDemoInit();
	Comic comic1 = {COMICBMP, 952, 0};
	init_video();
	copy_comic_to_buffer(&comic1, MAIN_BACKGROUND);
	while(1)
	{
		//copy_comic_to_buffer(&comic1, MAIN_BACKGROUND);
		scroll_comic(&comic1, 128);
	}




	return 0;
}

If I run this code, i get this:

Can someone help me out?

Posted: **Wed Oct 19, 2011 7:02 pm**

you only have vrama mapped so that is not enough for your whole image. you also have you background set as 256x256.

in any case, I suggest that you check out gl2d - just search the forum.

edit: the reason I pointed out the 256x256 bit is that your source width does not match the destination width (952!=256) - which is why you get the wrapping.

Posted: **Wed Oct 19, 2011 11:08 pm**

The simplest way to go for this might be using the large bitmap mode which will allow a 1024x512 pixel image on engine A. That's 256 color so if you need 16bit color then you'll need to write a strip scroller & use a 512x256 bitmap instead.

I'm not really clear on how gl2d would help much for this.

Posted: **Thu Oct 20, 2011 10:15 am**

Thanks for the info.

I already found out that the destination was clearly not good, I used 512x256, 1024x512 (that gave me nothing on screen, because it wasn't 16 bit) and I think that 512x256 is indeed a good call.

But then I'm stuck at somehow the same point, because my image is 952x192 and I only have 512x256, so I'm clearly missing a few extra px.

WinterMute wrote:The simplest way to go for this might be using the large bitmap mode which will allow a 1024x512 pixel image on engine A. That's 256 color so if you need 16bit color then you'll need to write a strip scroller & use a 512x256 bitmap instead.

I'm not really clear on how gl2d would help much for this.

What do you mean by a strip scroller?

I know that the image is 952 width, that's why I get an image who is clearly disrupted, the image itself is on screen only the order of the pixels is not right. I can't get much further...

Posted: **Thu Oct 20, 2011 12:32 pm**

For a strip scroller you set up your background to wrap then when the user scrolls the image you draw strips of the image in the offscreen parts of the bitmap at the location that's about to become visible. When the place you need to draw the strip is outside the bitmap area you wrap it round and draw it on the opposite edge. You may need to limit the scroll speed a bit to avoid jerkiness if the strip is too wide to be drawn in a single frame and also make sure that you split the strip if it 's intersected by the edge of the bitmap.

Posted: **Thu Oct 20, 2011 1:18 pm**

WinterMute wrote:The simplest way to go for this might be using the large bitmap mode which will allow a 1024x512 pixel image on engine A. That's 256 color so if you need 16bit color then you'll need to write a strip scroller & use a 512x256 bitmap instead.

I'm not really clear on how gl2d would help much for this.

personally, I think it would be easier to break the original image into 256x256 textures, then it is just a matter of determining which texture(s) to show at which horizontial offset. gl2d makes it easy to use screen coordinates. personal preference really.

this is a matter of displaying a 2d image, so I am not sure why you do not think gl2d could be used.

Posted: **Thu Oct 20, 2011 1:39 pm**

WinterMute wrote:For a strip scroller you set up your background to wrap then when the user scrolls the image you draw strips of the image in the offscreen parts of the bitmap at the location that's about to become visible. When the place you need to draw the strip is outside the bitmap area you wrap it round and draw it on the opposite edge. You may need to limit the scroll speed a bit to avoid jerkiness if the strip is too wide to be drawn in a single frame and also make sure that you split the strip if it 's intersected by the edge of the bitmap.

Yes, I totally understand what you mean, and that was exactly what I had in mind when I encountered this problem and knew why the image was shown that particularly way. But I don't know how to cut the image in pieces, without actually cut it off course in Photoshop or something familiar. I want to do it in the code itself, but I don't have a single clue how to do that, I have almost everything thought out and nothing was the solution.

I am a beginner, so I haven't got much options because I don't know that much, but with all the knowledge I have I can't get it sort out.

Posted: **Thu Oct 20, 2011 7:39 pm**

You don't need to cut the image in pieces, you just need to be able to copy a strip from the source image to the destination buffer.

Start by copying a 256x192 section from the source image to the bitmap buffer, for that you can start by copying a 256 pixel row to your 512x256 bitmap layer.. Hint: each row of the source is 952 pixels wide, each row of the destination is 512pixels wide, after you copy 256 pixels how many pixels do you now need to move to get to the start of the next row?

elhobbs wrote:
WinterMute wrote: I'm not really clear on how gl2d would help much for this.
personally, I think it would be easier to break the original image into 256x256 textures, then it is just a matter of determining which texture(s) to show at which horizontial offset. gl2d makes it easy to use screen coordinates. personal preference really.

this is a matter of displaying a 2d image, so I am not sure why you do not think gl2d could be used.

Breaking the image into 256x256 tiles seems to me like it's adding needless complexity for no particularly good reason. gl2d for this is using a hammer to crack a nut.

Posted: **Thu Oct 20, 2011 9:54 pm**

WinterMute wrote:You don't need to cut the image in pieces, you just need to be able to copy a strip from the source image to the destination buffer.

Start by copying a 256x192 section from the source image to the bitmap buffer, for that you can start by copying a 256 pixel row to your 512x256 bitmap layer.. Hint: each row of the source is 952 pixels wide, each row of the destination is 512pixels wide, after you copy 256 pixels how many pixels do you now need to move to get to the start of the next row?

Ok, I get what you mean.

Maybe I don't get how to copy bitmaps in sections to the buffer.
The answer btw is: 952-256 = 696, so if I copy two times the bitmap to 512x256 it will do, I see that. I understand the logic that you mean, and I totally get it, only I don't have a clue how to "cut" the bitmap in half so I can copy it to the buffers.

Posted: **Fri Oct 21, 2011 2:18 am**

WinterMute wrote:Breaking the image into 256x256 tiles seems to me like it's adding needless complexity for no particularly good reason. gl2d for this is using a hammer to crack a nut.

that may be true, but it is an easy/convenient hammer.

devkitPro

Big background problem

Big background problem

Re: Big background problem

Re: Big background problem

Re: Big background problem

Re: Big background problem

Re: Big background problem

Re: Big background problem

Re: Big background problem

Re: Big background problem

Re: Big background problem