Pallate change through attribute byte

[Vivek_Kakashi]

I am designing a game in which when I type a letter displayed on the screen its color should change but instead of sprites I have loaded the alphabets from background, as my sprite space is already in use. But now by changing the pallate using attribute byte the color of adjacent letter also gets changed....means for eg if on screen ROCK is return then If I only want to change the color of R then to color of O gets changed is there any different way......[Space can't be given between the letters because at later stage I also wand to load sentences]

[tokumaru]

Use a sprite with the new color on top of the first letter of each pair, and when the second letter changes you get rid of the sprite and modify the attributes, coloring both letters.

The downside is that you are gonna need all the letters in both sides of the pattern table (unless you use 8x16 sprites, but then you'd need an empty tile for each letter, which would waste just as many tiles). So yeah, the downside is that you're gonna be wasting some tiles.

[Vivek_Kakashi]

This is nice idea but but in our sprite page there is no space left but i think so i can use background page to load the same alphabate with different layer but it will also be waste of 26 tiles........is there any better method....thanks for replying

[tokumaru]

The only thing I can think of is using CHR-RAM instead of CHR-ROM... Then instead of having the whole alphabet in your pattern tables you'd have the exact word/phrase the person is supposed to type, and since it's CHR-RAM you can overwrite the tiles with the same letters, but using the new color.

What I mean is that right now you probably have the whole alphabet in your background pattern table (ABCDEFGHIJKLMNOPRSTUVWXYZ) and you combine those words as necessary for making up each word/phrase. My suggestion is that instead of having the whole alphabet you just hold the exact word/phrase you are using (ROCK, for example), and every time a letter is typed you redraw that letter using the new color. The name tables and attribute tables don't need to change.

For this you need to have a palette that contains the two colors you want to use for the letters (before typing and after typing).

If using CHR-RAM is not an option, then I'm out of ideas...

[tepples]

Can you use a single sprite to underline the selected character?

[tokumaru]

Yeah, that's an option... instead of changing the character's color you just indicate the current letter some other way, using sprites.

[Dwedit]

You can always use scrolling tricks to effectively get 16x8 attribute squares. Just look at Klax.

[tokumaru]

You can always use scrolling tricks to effectively get 16x8 attribute tables. Just look at Klax.

That doesn't help if the text is written horizontally, which I'm guessing it is.

[blargg]

Use 16x8 or 16x16 text, or an 8x8 font with spaces between each letter.

[tokumaru]

Use 16x8 or 16x16 text, or an 8x8 font with spaces between each letter.

[Space can't be given between the letters because at later stage I also wand to load sentences]

Yeah. Unless he reconsiders, and decides to split the sentences across multiple lines.

[Vivek_Kakashi]

tokumaru can u plz tell me what exactly is the difference between CHR ROM and CHR RAM or some tutorial on this topic.....

[tepples]

http://wiki.nesdev.com/w/index.php/CHR-ROM_vs_CHR-RAM

What mapper are you using?

We can get a better idea of what you're trying to do if you make a mock-up of your screen layout in an image editor such as MS Paint, GIMP, or Photoshop.

[tokumaru]

tokumaru can u plz tell me what exactly is the difference between CHR ROM and CHR RAM or some tutorial on this topic.....

You probably know that NES carts have two different chips: one for the program and one for the graphics. So far you have probably used CHR-ROM, which means that the graphics chip is ROM (Read Only Memory): it contains all the tiles that are going to be used in the game, and those tiles can't be changed.

But in some carts, the graphics chip is RAM, which can be written. This means that your program is free to manipulate the tile data, you can overwrite and modify tiles at will as the program runs.

At first, the big difference is that when you use CHR-ROM the tiles are always there, ready for you to use. But with CHR-RAM, when the console is turned on there is nothing there, because RAM loses its contents when there is no power. So you have to put your graphics there before you can use them.


QUICK GUIDE TO CONVERTING YOUR 8KB CHR-ROM PROJECT TO USE CHR-RAM:

Step 1: Modify the iNES header to indicate that there are no CHR pages (set the number of CHR pages to 0).

Step 2: Remove the CHR data from the end of the file. If you have an "incbin" command after the interrupt vectors, remove it. I you are joining the PRG and CHR with a "copy /b" command after assembling, don't.

Step 3: Put the CHR data in the middle of the code, along with other data you might have. It's supposed to be data inside your program now, so that you can read it. It is important that you still have 8KB of PRG-ROM free (if you don't you might want to use a mapper like UNROM, for more PRG-ROM space). Do something like this:

Code: Select all

TileData:
	.incbin "tiles.chr"

Step 4: Copy the data from PRG-ROM to CHR-RAM during the initialization of your program. The following code copies the whole 8KB:

Code: Select all

	lda #<TileData
	sta Pointer+0
	lda #>TileData
	sta Pointer+1

	lda #$00
	sta $2006
	sta $2006

	ldy #$00
	ldx #$20

-CopyByte:

	lda (Pointer), y
	sta $2007
	iny
	bne -CopyByte
	inc Pointer+1
	dex
	bne -CopyByte

Note that this is a PPU operation, it suffers from the same limitations as as writing to palette RAM or to the name tables: it can only be done during VBlank or with rendering turned off. Also note that tiles take a lot of space (16 bytes each), so there is a limit to how much you can change during VBlank depending on what else is being done during that time.

[cpow]

tokumaru can u plz tell me what exactly is the difference between CHR ROM and CHR RAM or some tutorial on this topic.....

Create three separate alphabet-tile regions in your CHR-ROM/RAM (it doesn't matter which). In the first, use the plane-0 bit for the letter image. In the second use the plane-1 bit for the letter image. In the third, use the plane-0 and plane-1 bits. This gives you three possible "A" tiles, three "B" tiles, etc.

If you placed an "A" from each tile set in adjacent squares of the same attribute table they will be different colors if the attribute-table selected palette contains different colors.

So you start out with the word ROCK drawn with the first alphabet-tile variant. Attribute tables set up so that the entire word is using the same selected palette of three different colors and a background color.

Then when the letter "R" is to be highlighted, you simply change the tile index of the "R" from the original-color alphabet set's "R" to the new-color alphabet set's "R".

No attribute update necessary...just a NameTable update.

[tokumaru]

Create three separate alphabet-tile regions in your CHR-ROM/RAM (it doesn't matter which). In the first, use the plane-0 bit for the letter image. In the second use the plane-1 bit for the letter image.

i can use background page to load the same alphabate with different layer but it will also be waste of 26 tiles