I'm not sure this will help, however, I'll try to help. All this is AFAIK.

You have two palettes of 16 values: one palette is for the sprites, the other is for the background.

Each palette is composed by 4 sub-palettes of 4 values each, the first value (of the four values) of each sub-palette is the same transparency color, which is common in all the (4 x 2 palettes) eight sub-palettes.



This is the sprite palette of Swords and Runes. As you can see, each sub-palette has the same black color in its first slot (I don't know what is the best word to use, I mean the first hex value of each sub-palette); then three other colors. Note that you cannot mix these colors: for instance, you can't have in your game a sprite with a yellow, a green and a blue color using this palette, since these colors are not in the same sub-palette.

So, a single 8x8 sprite, can only use three colors from a specific sub-palette, plus the transparency color.

I hope this helps a little, but I'm not too sure this is what you asked for.

Cheers!

- user

Edit: misspelling.

Yes, the CHR file is a binary file so you can't open it in a text editor and expect to make sense of it.  It is best opened in a program like TileLayerPro or Tile Molester, like you suggested.

And make sure you are changing the values in the correct .db table, since half of it is for background colors and half of it is for sprite colors.  Plus the first value of each set of four colors is the transparency color, like Jack mentioned.  Changing that value for sprites would make no difference since that color doesn't actually visually show up.

You and Khan helped a little. I was trying to change the colors in the directive .db. So, they have to have that first transparent color ? Why do they all have to have that ? I'm still not understanding what is meant by high byte and low byte. What is their signifigance and why do you have to set them to a pallete value ?  Looking forward to Swords and Ruins as I do every homebrew. Will it be released on here, Inifite NES lives or RetroUSB ?

So, they have to have that first transparent color ?
Yes.

Why do they all have to have that ?
It is the way the NES handles transparency. Someone more tech-oriented can be more precise about it.

I'm still not understanding what is meant by high byte and low byte. What is their signifigance and why do you have to set them to a pallete value ?

Each colors in the palette is a single byte. Hi/Lo is for addresses and pointers.
But you can just set a "dataline" of 16 hex values and load it up as your palette.
Just remember: #0,#4,#8,#12, i.e. the first byte (i.e. color) of each sub-palette, is transparent.

Will it be released on here, Inifite NES lives or RetroUSB ?
I don't handle the release, just the coding. Updates, when available, will be in the S&R thread.
I fear this is not the correct thread to discuss about it, and that discussing it further would be considered spam in here.
I posted that image just to (try to) explain a concept about sprites palettes.

You and Khan helped a little.
I hope this helped a little more!

This is a pretty good depiction about the transparent colors. I swear I wrote a great post explaining this but I can't find it for the life of me.

Basically when you play a Nintendo game, the player isn't a square is he? Mario has a shape, Link has a shape, etc, etc. Without a transparent color to tell the Nintendo which pixels to draw invisible, everything would be a square or rectangle.

ahhh, that makes sense now. There are only two paletes one for sprites and one for background ? All colors that are represented within a game exist within these two palettes ? Their adress in the PPU is brought up by the accumulator through operands in the PRG Rom. Does that make any sense ? Am I getting this at all ?

Not really.  You have 4 different palettes for sprites, and 4 different palettes for backgrounds.  Each of these palettes are made up of 3 colors, plus the background color.  In the sprite palette, the background color is actually transparent, so if a sprite is on top of the background, the background will show through.

It seems that there is a small mistake on the comments, which confused me at first.
First of all RAM is not a suitble word for  $2003, it is Sprite Memory
Then Sprites Memory can address from 00 ~ FF (8bit address range) so it doesn't have any low / high address bytes

Thanks for the great tutorial

It's setting the sprites to $0200, which is definitely in RAM.

The comments are referring to the LDA #$00 and the LDA #$02.  Low byte and high byte.

$2003 and $4014 are PPU registers.

See here:
http://wiki.nesdev.com/w/index.ph...

Writing #$00 to $2003 sets the OAM address (from $00 to $FF)
Writing #$02 to $4014 sets the CPU RAM address (from $XX00 to $XXFF) and then begins the transfer from CPU RAM to OAM automatically
00 and 02 are not High/low bytes of a single address, they are referring to different addresses

Edit :
fixed a typo : $2014 --> $4014

Whatever you say, friend.

This should say $4014 instead of $2014, and the DMA source address doesn't have to be RAM; it can be any address in the memory space (you can do OAM transfers from ROM if you want). Other than that it's correct.

How to set the sprite speed?

Eg. The character is at the speed x, ap the missile fired at a speed of 2x. Is it possible to set it somehow

Just have the sprite move more pixels per frame.

If your character is moving 1 pixel per frame, increment the missile to move 2 pixels per frame.

Example for:
Character
LDA $0200
CLC
ADC #$01
STA $0200

Missile:
LDA $0210
CLC
ADC #$02 ;Twice as fast
STA $0210

To build on this, you can use a variable and change the speed of the missile before moving it x or y pixels per frame.

;In Variables Area
MissileSpeed    .rs 1

;Changing Missile speed in code for whatever reason
LDA #$02          ;You can load this with whatever number you want based on things
STA MissileSpeed

;Adjusting the speed of the missile (assuming $0210 is the direction the missile is moving)
LDA $0210
CLC
ADC MissileSpeed                 ;Move sprite this many pixels
STA $0210


2x Character Speed
If you want the missile to be twice as fast as the character, you can do this.

;In Variables Area
CharacterSpeed    .rs 1
MissileSpeed    .rs 1

;Changing Missile speed in code for whatever reason
LDA CharacterSpeed             ;Current number of pixel per frame the character is moving
CLC
ADC CharacterSpeed 
STA MissileSpeed                 ;CharacterSpeed + CharacterSpeed = MissileSpeed

;Adjusting the speed of the missile (assuming $0210 is the direction the missile is moving)
LDA $0210
CLC
ADC MissileSpeed                 ;Move sprite this many pixels
STA $0210

It's slower than ADC #$01?

With what I posted, the Missile is 2x faster than the character. I hope that is what you are asking, I'm not sure what "It" is.

 

I will ask another question, can you determine the sprite rate of less than 1?

Yes, using a further byte of RAM.
Example: you store somewhere (e.g. variable FOO) the value HEX00.
then each NMI you add HEX40 to that variable.
each four MNIs the variable will reach "HEX100" (which is HEX FF+1 ) reset to zero and trigger the carry flag.
When the carry flag is triggered, you advance by 1 pixel.
So, you advance by 1/4 of pixel each NMI.
tell me if this helps.  

Yes. Instead of moving 1 pixel per frame, you move 1 pixel every other frame, every third frame, etc. However slow you want it to go.

The way I would tackle this by using a counter variable to skip frames.

;Variables
MissileSpeedCounter   .rs 1

;Code to Move Missile
INC MissileSpeedCounter      
LDA MissileSpeedCounter
CMP #$02                           ;Adjust this value depending on how many frames you want to skip, here I'm going every other frame. You can use a variable here if you want different speeds
BNE .SkipMoveMissile         ;Skip moving the missile this frame if not equal to #$02
     LDA $0210
     CLC
     ADC #$01
     STA $0210        ;Move Missile 1 pixel
    
     LDA #$00
     STA MissileSpeedCounter         ; Reset counter back to #$00
.SkipMoveMissile :



 

I think this may be better touched in the 16-bit math section further a long in the tutorials. This is only lesson #4.   

But yes, that is a shorter way to do this than what I posted if you are wanting to save cycles and RAM space.

 

Indeed.  
What you say makes perfect sense. And nice from you to write a full routine, I was too lazy.  

In the end, I think that providing Piputkin3 two different solutions, won't hurt!