Torches, Darkness, and Backgrounds?

[SoleGooseProductions]

I have done a few things beyond the tutorials (no scrolling projects, though my current one is up and, uh, running), and am learning as I go. This task may be a bit beyond me, however, we will see. Someone was nice enough to share his collision code with me a while back, and from this I have the X and Y locations, following the procedure that you mentioned. However, I am having trouble figuring out the following, since I have not had to do too much multiplication and combining of values:

Then, once you have the X and Y coordinates of the player converted to tile units, you have to combine them using the following formula: NTADDRESS = BASE + Y * 32 + X. BASE is the base address of the name table... for example, $2000 is the first name table. You multiply Y by 32 because each row has 32 tiles, and you add X because that's how far into the row the tile is.

I have gotten the X coordinate to work, doing two writes to $2006, but I cannot figure out the Y cordinate/base address part. I have looked around online regarding how to do this, but no luck since most of it is not 6502 specific. So far my routine looks like this:

Code: Select all

Illuminate:
;
; I have tried putting various things here, which affects the location of the Y coordinate, but not based off of player position.
; Instead, it seems to be based off of the first two digits, with the options being at 20, 21, 22, and 23, which is consistent
; with the previous way that I was writing to the background by writing two hex numbers and storing them each at $2006.
;
  STA $2006

  LDA SpriteXPos
  CLC
  ADC #$03              ; Changing this, as you said, changes the relationship of the tile to the player
  STA $2006

  LDA Tile                 ; A light tile
  STA $2007
IlluminateDone:
  RTS

This may not be at all the correct way to do things, but it is partially working which gives me hope. Thanks again for any help!

[tokumaru]

You have to use the full formula I gave you:

A: TileX = SpriteX / 8;
B: TileY = SpriteY / 8;
C: Address = Base + (TileY * 32) + TileX;

The 6502 code would be something similar to this:

Code: Select all

	;TileX = SpriteX / 8
	lda spriteX
	lsr
	lsr
	lsr
	sta TileX

	;TileY = SpriteY / 8
	lda SpriteY
	lsr
	lsr
	lsr
	sta TileY

	;Address = $2000 + (TileY * 32) + TileX
	lda #$00
	sta Address+1
	lda TileY
	asl
	rol Address+1
	asl
	rol Address+1
	asl
	rol Address+1
	asl
	rol Address+1
	asl
	rol Address+1
	adc TileX
	sta Address+0
	lda Address+1
	adc #$20
	sta Address+1

	;use the address
	lda Address+1
	sta $2006
	lda Address+0
	sta $2006
	lda Tile
	sta $2007

There are obvious optimizations you can do (for example, instead of shifting TileY right 3 times and left 5 times, you can take a shortcut and shift it left twice if you clear the lower 3 bits), but I wanted the code to be easy to understand.

Also, you don't need to perform this conversion several times for several tiles, you can easily generate other addresses from the first one: to move left, subtract 1, to move right, add 1, to move up, subtract 32, to move down, add 32. You should perform some some boundary checks when doing this, to make sure you don't go out of the name table you're in.

Another important point is that you shouldn't be doing these slow calculations during VBlank. The correct thing to do would be to compute all this stuff beforehand and buffer the addresses and data you'll be using, so that during VBlank you can just perform the actual PPU writes, instead of wasting precious VBlank time with operations that could have been performed before.

[SoleGooseProductions]

Thanks! There is still a long way to go, but I already have it up and running with a little spotlight (4x4 tiles). I'll play around with it for a while and see what I can figure out on my own, but thanks again. I would guess that next up is adjusting it to player movement, buffering, loading real data instead of blank tiles, and who knows what else. If anyone has any advice regarding those different things, or helpful links, feel free to post in the meantime.