libnds examples 3D_Both_Screens graphical glitch

[coreyh2]

Bottom screen has a normal looking pyramid, top screen has a flickering interlaced box and a glitched series of 8 rotating triangles. I compiled it with the latest version of devkitARM.

I don't know enough about the 3d code to understand what is going on.

[StevenH]

Is this on hardware or an emulator?

If it's hardware what flashcart are you using, how are you launching your NDS file (hbmenu or flash cart launcher).
If it's on an emulator, which one, version, OS, etc..

Without basic background the forground just vanishes into grey...

[coreyh2]

cycloDS launcher, NO$GBA 2.6, and DeSmuME 0.9.5 both had the same problem. Interlacing part looks different on DeSmuME. The emulators are running on XP.

Its the latest version of 3D_Both_Screens compiled after the new version of devkitARM came out.

[StevenH]

I've had a quick play around and I "fixed" the issue as far as my quick tests go:

change the two lines that deal with the REG_DISPCAPCNT to read as follows:

Code: Select all

REG_DISPCAPCNT = DCAP_BANK(0) | DCAP_ENABLE | DCAP_SIZE(3);

This sortof worked on my EzFlash Vi card (there's some issues with the memory not being cleared correctly from the boot process), but there's no issues with the tearing / interlacing artifacts I was getting when I first compiled the examples

[coreyh2]

When I tried your changes both screens were interlaced and flickery but the glitchy triangles were gone.

I first looked at this example because I wanted to compare it to the µLibrary example that does the same thing with a bunch of 2d ball textures. So I went into the actual library code of µLibrary and compared it to 3D_Both_Screens and libnds code. I got 3D_Both_Screens working by changing this code. The original REG_DISPCAPCNT code was the same in the uLibrary example so I changed that back.

Code: Select all

void initSubSprites(void){
//-------------------------------------------------------
 
	oamInit(&oamSub, SpriteMapping_Bmp_2D_256, false);
 
	int x = 0;
	int y = 0;
	int id = 0;
 
	//set up a 4x3 grid of 64x64 sprites to cover the screen
	for(y = 0; y < 3; y++)
	for(x = 0; x < 4; x++)
	{
		/* Doesn't set the same attribute variables *//*
		u16 *offset = &SPRITE_GFX_SUB[(x * 64) + (y * 64 * 256)];
 
		oamSet(&oamSub, x + y * 4, x * 64, y * 64, 0, 15, SpriteSize_64x64, 
			SpriteColorFormat_Bmp, offset, -1, false,false,false,false,false);
		*/
		
		/* adapted from µLibrary code */
		oamSub.oamMemory[id].attribute[0] = ATTR0_BMP | ATTR0_SQUARE | (64 * y);
		oamSub.oamMemory[id].attribute[1] = ATTR1_SIZE_64 | (64 * x);
		oamSub.oamMemory[id].attribute[2] = ATTR2_ALPHA(1) | (8 * 32 * y) | (8 * x);
		id++;
		/* adapted from µLibrary code */
	}
 
	swiWaitForVBlank();
 
	oamUpdate(&oamSub);
}

I don't understand sprite.c enough to understand what is going on here either. oamSet wasn't setting the same attribute variables. SpriteEntry structure in sprite.h is impenetrable. I see some of the same data but its doesn't seem like its being put in the same place.

µLibrary code is from drawing.c . The actual ball example is high level code that doesn't really help any with this problem.

[coreyh2]

Code: Select all

void initSubSprites(void){
//-------------------------------------------------------
 
	oamInit(&oamSub, SpriteMapping_Bmp_2D_256, false);
 
	int x = 0;
	int y = 0;
	int id = 0;
 
	//set up a 4x3 grid of 64x64 sprites to cover the screen
	for(y = 0; y < 3; y++)
	for(x = 0; x < 4; x++)
	{
		u16 *offset = NULL;
		
		oamSet(&oamSub, id, x * 64, y * 64, 0, 15, SpriteSize_64x64, 
			   SpriteColorFormat_Bmp, offset, -1, false,false,false,false,false);
		
		oamSub.oamMemory[id].attribute[2] = ATTR2_ALPHA(1) | (8 * 32 * y) | (8 * x);			
				
		id++;		
	}
 
	swiWaitForVBlank();
 
	oamUpdate(&oamSub);
}

Works.

*edit*
oamAllocateGfx doesn't work with 2d modes like SpriteMapping_Bmp_2D_256. So my test code was wrong.


offset is the thing that need to be corrected somehow.

Does the libnds 1.4.1 update "correct offsets for bmp sprites" have anything to do with this problem?