[yugisokubodai]

Hello

I'm writing some simple NES program. My first one is to display a sprite to the screen like this



Here is a part of my code

   

Code: [Select]

.inesprg 1 ;   - chọn bank nào trong program. Giờ chọn 1
.ineschr 1 ;   - chọn bank nào trong dữ liệu đồ họa. Giờ chọn 1
.inesmir 0 ;   - Đối xứng gương theo chiều ngang
.inesmap 0 ;   -Mapper 0

.bank 1      ; bank 1
.org $FFFA   ; bắt đầu từ $FFFA

.dw 0        ; ngắt VBlank
.dw Start    ; ngắt reset. Nhảy tới label Start khi khởi động và reset
.dw 0        ; phát sinh khi ngắt phần cứng và ngắt phần mềm

.bank 0 ; bank 0
.org $8000  ; $bắt đầu từ 8000

; Code chương trình bắt đầu từ đây

Start: 
lda $2002  ; Khi VBlank phát sinh, bit 7 của $2002 thành 1
bpl Start  ; trong khi bit 7 =0, nhảy tới Start

; Định dạng Register quản lý PPU
[b]lda #%00001000 [/b]
sta $2000
lda #%00000110 ; tắt hiển thị sprite và BG trong khi định dạng
sta $2001

ldx #$00    ; cho X Register về 0

; Chỉ định địa chỉ load palette $3F00 trong Register địa chỉ $2006 trong VRAM
lda #$3F
sta $2006
lda #$00
sta $2006

As I know, $2000 is the Register that controls PPU. Its bit 5 controls displaying 8x8 or 8x16 sprite.

   lda #%00001000  
Bit 5 now is 0, so it is 8x8 sprite and the result is as the screen shot above.
But when I change bit 5 to 1 (lda #%00101000   ), the result like this



Can anybody explain to my why the heck it happend like this? And how to properly display as 16x8 sprite?

Thanks for reading.

[Disch]

For 8x8 sprites:
- $2000.3 sets which pattern table the sprite graphics are taken from (0=$0xxx, 1=$1xxx)

For 8x16 sprites:
- $2000.3 is completely ignored
- the pattern table is determined by the low bit of the sprite tile in OAM


So if you have an 'odd' sprite tile, it will draw from $1xxx... but if you have an 'even' sprite tile, it will draw from $0xxx.

You probably have an even sprite tile, which means you are drawing from the wrong pattern table, which is why you are getting a blank space.

[Rappa]

Thank you for replying. I don't get it, what is odd or even sprite you mentioned about?

[M-Tee]

I wrote a small doc explaining it a while back for the coder of a homebrew project I'm working on. I will link it when I get home in an hour or so.

[Disch]

Thank you for replying. I don't get it, what is odd or even sprite you mentioned about?

You should be setting 4 bytes for your sprite in OAM:

byte 0 = Y position
byte 1 = tile
byte 2 = attributes
byte 3 = X position



For 8x16 sprites, the low bit of 'byte 1' determines which pattern table to use.

See this page:
http://wiki.nesdev.com/w/index.php/PPU_OAM#Byte_1

[Rappa]

Oh yeah, I made it. Thank you very much. Actually it display  sprite 0 over sprite 1.

[M-Tee]

I'm sure you've got it under control, but I went ahead and rounded out that document and uploaded it to my blog. It really only explains tile arrangement for using 8x16 sprites, but you may find it useful.

NES 8x16 Sprites Overview.

[yugisokubodai]

I'm sure you've got it under control, but I went ahead and rounded out that document and uploaded it to my blog. It really only explains tile arrangement for using 8x16 sprites, but you may find it useful.

NES 8x16 Sprites Overview.

Thanks for a great document.
NES game font has a tendancy to be 8x8, which is impossible to display accent such as Ŝ, Ğ... So by changing 8x8 to 16x8 sprite, may be I can come up with letters with accents above them.

[Disch]

Most games will split that up into 2 sprites/tiles.  So rather than drawing one 8x16 sprite, you'd draw 2 8x8 sprites.

That way, you don't have to waste pattern table space duplicating the 'overhead' symbols, or having 'S' repeated multiple times (one with overhead and one without).

[yugisokubodai]

By changing bit 5 in $2000 from 0 to 1, now I'm able to display 18x6 sprite, which sprite 0 overhead of sprite 1, sprite 2 overhead of sprite 3 and so on. Now I wonder how to display sprite 2 overhead of sprite 1 instead of sprite 3?

[Trax]

This explanation is weird to me, because in practice, it's never like that. When you visualize the two PPU sections $0000 and $1000 in an emulator like FCEU, you don't scan from left to right to assemble the 8x16 sprites. It's more like sprite index $24 will be composed of tiles $0024 and $0025, not $0024 and $1024. What am I missing, here?

[Disch]

By changing bit 5 in $2000 from 0 to 1, now I'm able to display 18x6 sprite, which sprite 0 overhead of sprite 1, sprite 2 overhead of sprite 3 and so on. Now I wonder how to display sprite 2 overhead of sprite 1 instead of sprite 3?

You can V-flip the entire sprite by setting that attribute bit.  That is the only way.  Otherwise tile 3 will always be below tile 2.

This explanation is weird to me, because in practice, it's never like that. When you visualize the two PPU sections $0000 and $1000 in an emulator like FCEU, you don't scan from left to right to assemble the 8x16 sprites. It's more like sprite index $24 will be composed of tiles $0024 and $0025, not $0024 and $1024. What am I missing, here?

sprite index $24 is composed of $024x and $025x
sprite index $25 is composed of $124x and $125x
sprite index $26 is composed of $026x and $027x
sprite index $27 is composed of $126x and $127x


The low bit of the sprite index determines which pattern table to take both tiles from.  And the 'even' tile is always drawn over the 'odd' tile.

[M-Tee]

Thanks for a great document.
NES game font has a tendancy to be 8x8, which is impossible to display accent such as Ŝ, Ğ... So by changing 8x8 to 16x8 sprite, may be I can come up with letters with accents above them.

That wouldn't really matter anyway, though. Text is 99% of the time background, not sprites. Sprites max out at 8 per scanline (hence flicker), so you couldn't have more than 8 characters on a line (or 64 on screen) if you used sprites for text.