nesdev.com
https://forums.nesdev.com/

8x16 and whatever else unreg wants to know
https://forums.nesdev.com/viewtopic.php?f=10&t=7451
Page 61 of 95

Author:  tepples [ Mon Jan 21, 2013 2:50 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Kasumi wrote:
You could even write half a row, half a column, then the other half of the row, the other half of the column. It's not a good idea, just saying it because things aren't so rigid as you seem to be imagining.

One of my programs does exactly that to draw a box:
  1. Set the address to the top left and set the increment to +1.
  2. Draw the top left corner and the top border.
  3. Set the increment to +32.
  4. Draw the top right corner and the right side.
  5. Set the address to just below the top left.
  6. Draw the left side.
  7. Set the increment to +1.
  8. Draw the bottom left, bottom, and bottom right.

Author:  unregistered [ Tue Jan 22, 2013 9:21 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

:D That's so cool tepples! 8-) I can't wait to play with the non-rigid NES PPU!

edit: Ok, I think I understand why yall used a variable to keep track of what you've written to $2000 PPUCTRL; it is a write-only register, right? And so instead of reading it you keep a copy of the last byte you've written to it... I think! :)

Author:  Kasumi [ Tue Jan 22, 2013 1:48 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Yep, you got it.

Author:  unregistered [ Tue Jan 22, 2013 2:34 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Kasumi wrote:
Yep, you got it.
Thank you Kasumi,; I'm so happy for the your reply! :D

added.

Author:  unregistered [ Tue Jan 29, 2013 4:14 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

So, when my PPU is incrementing by 32 after each write does it always do that forever... like can it automaticly start at the top of the next row? Or do I need to first set the address to zero?

Author:  Kasumi [ Tue Jan 29, 2013 5:05 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

You have to write a new address to $2006. It's especially annoying in whatever directions you're scrolling in. In 29 cases out of 30, you have to set the address again to write a whole column. In 31 cases out of 32, you have to set the address again to write a whole row.

Author:  unregistered [ Tue Jan 29, 2013 5:36 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Kasumi wrote:
You have to write a new address to $2006. It's especially annoying in whatever directions you're scrolling in. In 29 cases out of 30, you have to set the address again to write a whole column. In 31 cases out of 32, you have to set the address again to write a whole row.
Ahhh noooooooooo. :(

Author:  Kasumi [ Tue Jan 29, 2013 5:49 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Hmm... what I said was misleading. If you only scroll horizontally, you'll only need to write the starting address for each column. You'll never need to write two for one column.

Same if you only scroll vertically, except replace column with row.

It's only an issue if you do both, which you are not. You still do need to write a new address for each NEW column, but there's much less math involved there. I apologize, not quite sure what I thinking in the last post.

Author:  unregistered [ Tue Jan 29, 2013 7:23 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Kasumi wrote:
Hmm... what I said was misleading. If you only scroll horizontally, you'll only need to write the starting address for each column. You'll never need to write two for one column.

Same if you only scroll vertically, except replace column with row.

It's only an issue if you do both, which you are not. You still do need to write a new address for each NEW column, but there's much less math involved there. I apologize, not quite sure what I thinking in the last post.


Thank you Kasumi! :D : ) I was dissappointed in having to write the address for each new column... but it is really ok now... :) it is should be possible for me to do! I'm looking forward to making this work for two columns. And then there will be a point where I should not make a column until it is needed... :D or, hey, I can create the column in my buffer and then wait to draw it on the screen.

edit.

Author:  unregistered [ Wed Feb 06, 2013 10:37 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

sigh... why would my rom be built with the wrong chr screen?? In FCEUX 2.1.5's PPU viewer it shows that I've loaded the same pattern table for both screens... in my code there is:
Code:
.incbin "lvl1\lvl1.chr"
; Fill the rest of the first CHR-ROM block with zeroes.
.align $1000

; Here begins the second 4K block.  The sprites (all one of them) get their data
; from this page.
.incbin "Character3.chr"

; Fill the rest of the CHR-ROM block with zeroes, giving us exactly 8K of data, which
; was what we want and need.
.align $1000
; now we have 16 banks of 8K CHR-ROM. (actually 32 banks cause we are using 4K files)


Why isn't Character3.chr present in FCEUX 2.1.5's "PPU Viewer..."? It looks like lvl1.chr is there twice! :x :?

Author:  tokumaru [ Wed Feb 06, 2013 11:11 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Are you using a mapper? Have you selected the appropriate CHR-ROM banks? If you're using the MMC1 in 4KB CHR mode you might get the same 4KB mapped twice if you didn't explicitly switch the 2 4KB pages you want to use.

Author:  lidnariq [ Wed Feb 06, 2013 11:21 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

tokumaru wrote:
Are you using a mapper? Have you selected the appropriate CHR-ROM banks? If you're using the MMC1 in 4KB CHR mode you might get the same 4KB mapped twice if you didn't explicitly switch the 2 4KB pages you want to use.
And/or have you written the right value to $2000 so that the sprites and background come from different parts of CHR?

Author:  3gengames [ Wed Feb 06, 2013 11:44 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

Why not make one big 8/16/32/64/128KB file and just INCBIN that instead of messing with tiny 2KB char files and such?

Author:  tokumaru [ Wed Feb 06, 2013 12:28 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

lidnariq wrote:
have you written the right value to $2000 so that the sprites and background come from different parts of CHR?

I think this wouldn't change what's displayed on FCEUX's debugger, though.

3gengames wrote:
Why not make one big 8/16/32/64/128KB file and just INCBIN that instead of messing with tiny 2KB char files and such?

If you have different tilesets for different levels for example, it makes sense to use smaller CHR files. I even have individual CHR files for each enemy/object, for example. This way I can easily rearrange them without the aid of graphical editors, or even calculate banks numbers or tile indexes using labels, instead of using hardcoded values. It's more organized (which is the same reason most people don't use a single huge ASM file for the whole game).

Author:  3gengames [ Wed Feb 06, 2013 1:03 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

He's using MMC1 so the highest resolution is 4KB, and is using CHR-ROM, it's much easier to do a LUT to pick the right graphics bank per level unless he uses CHR-RAM or a mapper like MMC3, especially since he's having troubles. But still, besides the point. FCEUX does not change what it displays based on $2000 value...just tested. So be sure you are picking both chunks in 4KB mode. :P

Page 61 of 95 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/