Sprite Id Number

[Sylus101]

Hello Again,

I'm feeling a bit like a pest, but I'm hoping that some of my questions will end up helping others trying to make a similar transition.

I can't find a way to define the sprite id number (second parameter of oamSet). Running a quick test, it seems to just increment itself (separately per engine) as oamAllocateGfx is called.
Is this intentional? I'm thinking that I could come up with a pretty good tracking system keeping this in mind, but is there a way to specify this? I'm also curious about the lack of use of the SpriteEntry union from examples that is noted in a few tutorials. Is this being moved away from, or just happening behind the scenes with the new sprite API?
(EDIT) I think I'm getting caught in the middle of trying to understand the new API and figuring out how some of the more advanced points work. What I have to assume is happening somewhere behind the scenes is in the new API, an OAMTable has already been created and is being updated with oamSet... and then applied to OAM memory with updateOAM for each engine... it would still be good to know what the OAMTable(s) was called... that is if I'm on the right track...

(EDIT 2) Okay I think I've got it... if I'm correct, oamMemory is the member of oamMain and oamSub that I am looking for. I was able to output a sprite's x location using oamSub.oamMemory[0].x in the SimpleSprite example (turned top screen in to console...). Still the question remains... can I retain the abstraction, but be able to manage gfx allocation and sprite id's safely?

Thanks again,
Sylus

[dovoto]

By sprite ID i assume you mean which position it is occupying in the OAM table?

Currently the api provides no allocation for that which is a bit unclear. I normally keep my "sprites" and my oam entries completely separate until display time.

After some usage of the sprite api and some other feedback you can expect some changes to the sprite api with the next release to clarify things.

I may simply forgo oamSet in favor of setting oamMain.oamMemory[id].blah directly (although this is not really much better at a glance it does expose all the sprite attributes where as oamSet is missing a few (like v and h flip)).

Keep the feedback coming though, your confusion is actually very helpful to me even though i know its probably equally as frustrating for you

[Sylus101]

No sweat. I try not to, but I have a bad habit of asking questions and then diving in and researching anything an everything anyway, hence all the edits...

I'll surely keep them coming, and I do have another.

By sprite id I'm talking about the 2nd parameter of the oamSet function. I've basically just been playing around with the SimpleSprite example, adding things, taking things away, etc... At the moment. I've loaded 2 of the same sprite on the bottom screen and changed the top to a print console to output some things as I test. It feels unusual calling the oamAllocateGfx function to get a memory address, fill that pointer will some gfx values, and yet never telling which sprite obj you're using. Since I loaded 2 sprites on the same screen, I just tested 2 calls of oamSet with id being 0 and 1 and it worked fine.

So it's a little difficult working with the unseen counter... I'm thinking that adding a id parameter to oamAllocateGfx so you can just specify the position in the OAM table would be good, as long as that's feasible.

[dovoto]

As a quick (and somewhat drunk) reply:

the second parameter is nothing more than an index into the sprite oam table. The api currently provides no "counter" or allocation scheme for this. There are 128 of these sprite "id"s you may use but they are entirely at your own discretion. I will take a look at this post when i am slightly less drunk tomorrow and see if it makes any sense and hopefully clarify things a bit.

[Sylus101]

To hopefully clarify my confusion a little, here's what I'm getting at.

In the SimpleSprite example, I commented out the top screen sprite and created two on bottom:

Code: Select all

	//u16* gfx = oamAllocateGfx(&oamMain, SpriteSize_16x16, SpriteColorFormat_256Color);
	u16* gfxSub = oamAllocateGfx(&oamSub, SpriteSize_16x16, SpriteColorFormat_256Color);
	
	u16* gfxSub2 = oamAllocateGfx(&oamSub, SpriteSize_16x16, SpriteColorFormat_256Color);

Inside the loop, I'm calling oamSet twice, one for each sprite. Here's the whole new loop:

Code: Select all

	while(1) {

		scanKeys();

		if(keysHeld() & KEY_TOUCH)
			touchRead(&touch);
		
		if(keysHeld() & KEY_RIGHT)
			sp2x++;
		if(keysHeld() & KEY_LEFT)
			sp2x--;
		if(keysHeld() & KEY_UP)
			sp2y--;
		if(keysHeld() & KEY_DOWN)
			sp2y++;
		
		oamSet(&oamSub, 
			0, 
			touch.px, 
			touch.py, 
			0, 
			0,
			SpriteSize_16x16, 
			SpriteColorFormat_256Color, 
			gfxSub, 
			-1, 
			false, 
			false);
			
		oamSet(&oamSub, 
			1, 
			sp2x, 
			sp2y, 
			0, 
			0,
			SpriteSize_16x16, 
			SpriteColorFormat_256Color, 
			gfxSub2, 
			-1, 
			false, 
			false);

		swiWaitForVBlank();

		
		oamUpdate(&oamMain);
		oamUpdate(&oamSub);
	}

The stylus moves one sprite and the D-Pad moves the other. I guess where my confusion lies, is that I never specified those id numbers myself. They just seemed to increment from 0 to 1 as oamAllocateGfx was called.

EDIT - Okay... now I'm really confused. On a hunch I modified the id numbers just for kicks and it ends up just behaving the same way.

->LIGHT BULB GOES OFF ABOVE HEAD<-
OOOOohhh okay okay... wow. I get it totally now. oamSet is really a catch all so that you can pretty much define information for any of the oam Table entries totally on the fly. I just had to separate where the graphics are from the individual oam entries in my head. Okay, this makes perfect sense now.

I'm trying to think what would have helped me get here sooner... I'll let you know if I come up with anything.

[dovoto]

I'm trying to think what would have helped me get here sooner... I'll let you know if I come up with anything.

maybe something as simple as renaming oamSet to oamEntrySet ?

[Sylus101]

Well, I had the perfect thing typed up, and then I closed my browser before leaving work... I'll try to hopefully recreate what I'd said.

I don't think a different name for oamSet is really necessary. Where I believe I became most confused was as I went out to find help in places other than here and the online docs, the tutorials that are out there (and Patater's is likely the most complete, at least in terms of Sprites) guide you without the API in mind. I saw the oamUpdate function so I could guess what was happening there, but I didn't know how things were working without the a SpriteEntry struct to update the hardware OAM with... that is until I realized that it had been there all along.

I think something like this could be added somewhere near the top of the sprite section of the docs:

" In general, an individual Sprite is made up of it's graphics (stored in VRAM) and an oam entry (stored in it's own memory banks). Libnds 1.3.1 brings a new API for handling both graphics and OAM.
2 OAMState structures have alreay been declared, oamMain and oamSub. Once oamInit() has been called, you will still be able to access your "mirror" to OAM memory via the (not going to say this part right) the members of oamMain and oamSub which include SpriteEntry *oamMemory and SpriteRotation *oamRotationMemory. For example you could set the x coordinate for oam (sprite) entry 3 on the Main screen to 10 with oamMain.oamMemory[3].x = 10; To keep things easy, oamSet() is the API function that can be used to set all of an oam entry's attributes quite easily."

This may be a bit verbose... I think at least the part about the 2 OAMState structures would be very helpful.

In the description to oamSet, I would change it to (changing variable name from id to oamId):
"Sets several attributes for the oam entry given by 'oamId'"

EDIT - Oh, and... Happy New Year!