Homebrew Project Questions

[Izhido]

Just my 2 cents in this...

Isn't a "combined" project a little overkill for a simple word game? The combined ARM9 / ARM7 project template was, initially, required for some tasks (sound, microphone, WiFi), but that's over now. The ARM9-only projects can do all that now, and are 1000% simpler to work on. Nowadays, combined-type projects are intended for very advanced needs and extremely fine control of what you need to do in your application. Wouldn't it be easier for you to start with *any* of the projects in /examples/nds (except for the combined template), then do your work starting from them?

[Tron]

Don't you need the ARM7 code for retrieving the other key input (touch, x / y, lid)? What makes combined projects so much more difficult? Also, if it's no longer used for those things, what is the ARM7 used for now?

As to whether it would be easier to start with any of the other examples, I cannot say. However, I figured I would read through and run any that contain a functionality I need to learn.

[vuurrobin]

the 'arm9-only' template does use arm7 for music, input, wifi ect, but it uses a default arm7 so you don't have to worry about the arm7 code or the communication between the 2 arm processors. which makes things a whole lot easier and is good enough for most projects.

the combined template is mostly for people who needs to do anything arm7 specific.

[Tron]

Alright, thanks for the clarification. I've now successfully compiled and run my demo, which is operating as intended on both DeSmuME and the hardware itself. By the way, vuurrobin, according to the libnds src, touchReadXY updates the pressure and raw values too, it just returns them in a touchPosition struct as opposed to having you pass a pointer to one.

[Tron]

6. Why must tile data be written to video memory using a bios call (swiCopy) instead of writing to the space directly?

[vuurrobin]

it doesn't need to be, but you need to write to vram at least 2 bytes at a time (1 byte wont work) and using one of the existing functions will most likely be faster than doing it yourself.

[StevenH]

6. Why must tile data be written to video memory using a bios call (swiCopy) instead of writing to the space directly?

It does not need to be done that way, but if your copying a large amount of data that's in a pre-existing block of memory then an swCopy is the fastest way to copy the data over, you also have dmacopy, memcpy or even a for() loop as options to access the data for the tiles, but the fastest way IIRC is swiCopy due to a bug in the dmaCopy implementation (I read about this somewhere, if I can find the link I'll paste it here).

[Tron]

it doesn't need to be, but you need to write to vram at least 2 bytes at a time (1 byte wont work) and using one of the existing functions will most likely be faster than doing it yourself.

How come 1 byte doesn't work?

7. In dovoto's 4th day tutorial, he says that the 11th and 12th bits in a 16-bit tilemap header are control bits for horizontal and vertical flipping, respectively. I assumed this meant over an imaginary y and x axis so that one tile could be used both for one side of an image, and the opposing, symmetric, side. However, I tried to do this in a demo and the locations in the map which were to be flipped tiles did not appear. Below is a snippet showing the code where I assign the flipped tiles in the map (using & BIT(11)):

Code: Select all

	/* create tilemap */
	int i;
	for (i = 0; i < 21*32; ++i)
		mapMemory[i] = 0;
	for (; i < 21*32+29; ++i)
		mapMemory[i] = 0;
	mapMemory[i++] = 1;
	mapMemory[i++] = 2;
	mapMemory[i++] = 1 & BIT(11);
	for (; i < 22*32+29; ++i)
		mapMemory[i] = 0;
	mapMemory[i++] = 3;
	mapMemory[i++] = 6;
	mapMemory[i++] = 3 & BIT(11);
	for (; i < 23*32+29; ++i)
		mapMemory[i] = 0;
	mapMemory[i++] = 4;
	mapMemory[i++] = 5;
	mapMemory[i] = 4 & BIT(11);

[WinterMute]

6. Why must tile data be written to video memory using a bios call (swiCopy) instead of writing to the space directly?

It does not need to be done that way, but if your copying a large amount of data that's in a pre-existing block of memory then an swCopy is the fastest way to copy the data over, you also have dmacopy, memcpy or even a for() loop as options to access the data for the tiles, but the fastest way IIRC is swiCopy due to a bug in the dmaCopy implementation (I read about this somewhere, if I can find the link I'll paste it here).

The bug is in the swiCopy implementation.

The VRAM bus is 16bit only, any 8bit write to VRAM will change both 8bit halves of the 16bit value at the 16bit aligned address.

[Tron]

8. How are pixel transparencies handled using 256 paletted color (since there is no transparency bit as in 16-bit color mode)?