... ..... ....... .........I feel really dumb now. :-)

edit: double post

I post a .zip file tonight with all the code in it. It's been over a year, so I can't really recall everything I done.

First off, I commented out anything that was related to drawing and animating the enemy sprites so I could concentrate on the playable character. I then made my own CHR file with a 2x4 metasprite character for the testing. I then studyied the code and found where to make the changes and got it all working.

Basically, you are going to have to compare the code to MRN's to see what I changed. Been a long time since I have sat down and wrote some code or read the tutorials. I will try to help where I can if you have questions.

 

Here is the code.

You should not.

Actually, my answer is correct, but it was the answer to another question.
In the X position of two metasprites 16x16px next to eachother, the offset is 16px, hance 10 in HEX.
In the Y position of two metasprites 16x16px adjacent vertically, the offset is 16px, hance 10 in HEX.

However, this was not the offset you were asking about.

Still, it is an offset of 16, which is 10 HEX.

Let say that, as the MRN article proposes, you use RAM page $0200 for sprites.

Each metasprite is made of four (4) 8x8px sprites: UpL UpR BottomL BottomR.

Each of these four (4) sprites has four (4) bytes of info:

1. (address +0) Y position
2. (address +1) pattern
3. (address +2) attributes
4. (address +3) X position

Let say the metasprite "Foo" starts at address $0200, and is composed by the following four (4) 8x8px sprites: spriteUL, sprite UR, sprite BL, sprite BR.

$0200 = Y position spriteUL
$0201 = pattern spriteUL
$0202 = attributes spriteUL
$0203 = X position spriteUL

$0204 = Y position spriteUR
$0205 = pattern spriteUR
$0206 = attributes spriteUR
$0207 = X position spriteUR

$0208 = Y position spriteBL
$0209 = pattern spriteBL
$020a = attributes spriteBL
$020b = X position spriteBL

$020c = Y position spriteBR
$020d = pattern spriteBR
$020e = attributes spriteBR
$020f = X position spriteBR

As you can see, there are (4x4) 16 Bytes of info (from RAM address $0200 to $020f, both included) describing the 16x16px metasprite "Foo".

Where the next metasprite will start? At address $0210, with an offset of 16 Bytes, HEX 10, from address $0200.

I think now that this is the offset you were referring to in your question.

My apologies for giving a quick answer without understanding what the question was about, I hope this helps some more.

By the way, if you wonder:
 - There are 256 Bytes to store sprites data.
 - Which makes 64 total (8x8px) sprites (four (4) Bytes each sprite: Yposition, pattern, attributes, X position).
 - Which makes 16 total (16x16px) metasprites available, if your game uses only 16x16 pixel metasprites (four (4) 8x8px sprites are used for each metasprite, hence 64/4).

Also (and sorry for my lacks in English) I hope this answer is correct, makes sense and is understandable.

And if by now you had everything understood already, sorry for the redundancy of this further reply.

Edit: formatting.

Is the attachment for this still available? I'm not seeing a link anywhere. :/

Directly beneath the first post. But above the second post. The attachments are hard to see.  
 

I see it now. Thank you.  

@Mario's Right Nut nice work! thx

These are some great tutorials to check out once you finish the NN, that is for sure  .

I have to say that this tutorial is teaching me a ton. Before someone told me about this in another post, I had finished the awesome NN tutorials and had made a program with a player character and all of its animations and movements and controls. It worked but it was ALOT of code. I have been working on the code in this tutorial for 3 days now, trying to understand all of it. As I understand it more and work it into my own program the code is getting so much smaller and concise. Thank you! I look forward to the next one.

I feel this tutorial and tutorial #2 are a must after the NN tutorials. The others are great as well, but I feel these first 2 can point you in the proper direction. I use MRN's game engine in my games. I have not devled in the metasprites yet. Maybe someday, but it my next game, I will be loading my sprites in a way that metasprites aren't very helpful.

 

So I think I fully understand this first tutorial now. I have redesigned my previous program to use it and is so much easier to understand. The one thing I cant seem to figure out is where the striped background is set? I would like to set it to just black for now. Where would I find where he is setting the background?

Right now, there is no BG loading routine in that code.
You will first have to create and add a BG CHR file to the code (look at how Sprite_Data: section looks). Then load that chr file into the PPU (look at the LoadCompleteBank routine, right now it is just load the Sprite_Data). I would go back to the Nerdy Nights Background tutorials to see how he loads BG data into the PPU to get your new file up to speed.

In Nerdy Nights, all CHR files were 8kb since it held 256 sprite tiles and 256 background tiles. In this tutorial, the sprite CHR file is only 4kb because it only has the 256 sprite tiles. You will need a 4kb BG CHR file for BG tiles. Storing BG and Sprites in separate CHR files is very helpful down the road when you start bankswitching and needing more that 256 BG or Sprite tiles. Then you can swap out BG tiles but keep your sprite tiles or vice versa. You can create 4kb (or even othe sizes!) chr files in NES Screen Tool by going to the Patterns Menu and then selecting the Save CHR drop-down menu.

I hope this helps. This was a huge revalation for me when I finally figured out that you can split and load CHR data in chunks instead of 8kb at a time.

 

Yes! I took me a couple of days to figure out why my code wouldn't work when I put my chr in instead of his. He had only allocated 4 and mine was 8. I understand bg tiles and such just don't understand how he is accomplishing the black and grey stripes for the bg.

He didn't do that. Those are just the default values that are populating that area in the PPU and you are just seeing the result on the screen. Maybe someone more technical than I can tell you exactly why tile $00 is half black and half gray. But, nothing in the code suggests that he meant for it to do that from what I can tell.

That's why I skipped to Week 5, and got back to sprites years later  .

ok thanks, I thought I was just crazy lol. Thanks for the help. I wont mind them for now. I was just trying to understand everything I could.

Thanks again.

It is a deep lesson, that is for sure!