Since the topic of the week has been cleaning up/optimizing code, I had a question or two. For the most part my game engine has followed that of the Nerdy Nights, except that since Pong only had one screen for the playing state I did not know how to do individual rooms. At the moment, I have each room as a separate game state, which leads to a LOT of duplicated code since all of the playing state material is re-written for each room. Is this the correct way to do things? I am guessing not , and from beginning to understand MRN's room indexing lesson I can see what appears to be another way (though I have not figured out how non-player character sprites are updated in new rooms), but could use whatever advice folks have to offer. Thanks!

No, a game state would be like Pause, Cut Screens, Main Game, Death, etc. where there are different types of game functions. I'm pretty sure #6 (or there abouts) discusses this. An "engine" would work with whatever you put into it. It sounds like you're "hard coding" rooms if you have to make a different GS for each one.

Here's a question:
What are the scanlines in NES's PPU? Why and where are they used? Why are they required for the PPU? I don't really understand them so I need explaining. Also, an example picture showing where the scanlines go would be helpful.

One horizontal row of pixels displayed on the TV screen is the scanline.

OK, I'm stuck on the easiest way to do do player + bg collision detection. I've got it working with hard coded bounding boxes - basically, there are currently 6 variably sized blocks on a screen that should be impassible, so I coded the coords in for them, then compare them to the player sprite's box to see whether the movement should be allowed. Works great, but I can't be bothered changing the coords every time I alter the level structure.

With the following limitations in mind, what's the easiest way of doing this?

1.) No scrolling. Each screen is static.
2.) I'm not using metatiles, or even nametable compression at the moment.

I thought of maybe just checking directions eg: sprite wants to move up, so check the tile one row up in the nametable, if it's solid, don't allow movement. This would then cause issues where it's fixed to tile boundaries, so the sprite could potentially be stopped almost a full 8 pixels before the actual obstruction... "Pixel exact" would be good.

I'm missing something really obvious, I'm sure, but I can't figure it out

Thanks for any help.

You should not use bounding box intersection for BG-to-object collision. You need to have a walkmap instead, an array with flags for each tile that specified either it is passable or not.

I just had a moment of inispriation with this post.  I need to make some notes!

Hmm, I'm messing something up with my sprite->nametable coordinate mapping or something. My impassible blocks have now become impassible buildings of various sizes due to my awesome graphical abilities (it's a top down rpg-ish/shooter). It just seems easier to keep 4 bytes of collision data for each building (x1, y1, x2, y2) and looping through to check for collisions in each direction, but directly indexing the nametable data would make more sense I guess. And also be even simpler if I knew what the hell I was doing

The bounding box based BG collision would work fine on modern platforms with a lot of RAM and CPU power, but on the NES it'll quickly become impractical as number of the BG elements grows up. Also, if you need a more complex walkmap shapes than a set of simple rectangles, like, diagonal slopes as in SMB3, you'll simply have to switch to array of tile flags instead of bounding boxes, because non-axis aligned rectangle collisions will take way much more CPU time.

A complex case of BG-to-object collisions from an actual NES game is explained here.

That was an interesting read, thanks Shiru. Way beyond my own talents at the moment, just baby steps for me at the moment.

I have a single screen (created with your excellent Screen Tool btw, thank you for that!) just defined as a series of bytes - no compression. Sprites are 8x8, I've been trying to translate the player's X/Y coordinates to a nametable index by dividing by 8, then using tile_x * 32 + tile_y, but it doesn't seem to be working properly.

I can't post the code now, I'll try again later and include code to see if anyone can lend a hand.

It should be tile_y*32 + tile_x. Also you have to use 16-bit arithmetic because the result doesn't always fit in 8 bits.

I'm looking at MRN's Metasprite tutorial right now, and I came up with this little program. However, I made my own random sprite movement routine, and it seems to crash on NEStopia (Mac version), even though it runs fine on Windows XP's FCEUX
Anyone knows what's wrong?
http://pastebin.com/ZiuSVTj3...

D'oh!  Of course the result needs to be 16-bit   The other tile_x/tile_y part was a typo on my part.  Thanks for the pointer thefox, it's much appreciated.  That'll teach me for late night coding.  And being a dumbass

Anyone?

You commented all the parts of the code that I don't need to understand. I have no idea what you're trying to do after MoveRightDone.

Without studying your code in great detail, it would appear the program is based entirely on nmi interrupts rather than main thread + interrupts (which is fine for something small). However, you still need an infinite loop to prevent your nmi handler from running outside of nmi. Right above your nmi routine, put something like:

GameLoop:
jmp GameLoop

For an nmi based game that doesn't need much processing, you can just leave it blank.

Can't believe I'm so stupid for having forgotten this! Of course it won't work that way

Originally posted by: KHAN Games


You commented all the parts of the code that I don't need to understand. I have no idea what you're trying to do after MoveRightDone.

Did that fix your problem?

Cracked it, finally.  This thread is very useful for anyone else struggling with bg/player collision:

http://forums.nesdev.com/viewtopi...

Thinking about it, it might be easier to just use a 120 byte array for bg collision (1 bit per 8x8 tile would suffice for my needs), thus saving oodles of space, but this works for now

Yep it did

I cannot for the life of me figure out sprites. I can write the code to load the initial sprites, that's easy. What I can't figure out is how to get more to load during game play (Push a button and sprite appears) or make them go away during game play (Push a button and the sprite is gone).  Essentially, my sprites don't move, they are just replaced by other sprites. So, here is an example below (not my actual code, but I want to make my code do this):

Here is what I want my code to do:
-Initially Load sprite1 and sprite4 (I can do this)
-Press and hold Button A - sprite1 changes to sprite2 (and sprite2 changes to another and this continues until you get to the last sprite or release A, to keep it simple, I am just stopping at sprite2) AND
sprite3 changes to sprite4


-Release Button A - first set of sprites (sprite1 and sprite2) stop changing AND sprite4 changes back to sprite3
-Press Button B - sprite2 changes back to sprite1

So, basically, I want to push a button and make a sprite leave the screen and make a different sprite load on the screen in the exact same location. Sprites 1 and 2 are beer mugs and sprites 3 and 4 are the tap handle. Press Button A, fill mug (series of 7 sprites) and tap the handle. Let go of A, mug stops filling and handle go back to the up position. Press B, a new empty mug loads.

Example Code:
;;Initial Sprite Load
LoadSprite1:
  LDX #$00              ; start at 0
.Loop:
  LDA sprites1, x        ; load data from address (sprites +  x)
  STA $0200, x          ; store into RAM address ($0200 + x)
  INX                   ; X = X + 1
  CPX #$10              ; Compare X to hex $10
  BNE .Loop   ; Branch to LoadSpritesLoop if compare was Not Equal to zero
                      

LoadSprite3:
  LDX #$00              ; start at 0
.Loop:
  LDA sprites2, x        ; load data from address (sprites +  x)
  STA $0220, x          ; store into RAM address ($0220 + x)
  INX                   ; X = X + 1
  CPX #$08              ; Compare X to hex $08
  BNE .Loop   ; Branch to LoadSpritesLoop if compare was Not Equal to zero
                    


sprite1: ;empty mug
     ;vert tile attr horiz
  .db $80, $00, $00, $90   ;tile 0
  .db $80, $01, $00, $98   ;tile 1
  .db $88, $02, $00, $90   ;tile 2
  .db $88, $03, $00, $98   ;tile 3

sprite2: ;start to fill mug
     ;vert tile attr horiz
  .db $80, $04, $00, $90   ;tile 4
  .db $80, $05, $00, $98   ;tile 5
  .db $88, $06, $00, $90   ;tile 6
  .db $88, $07, $00, $98   ;tile 7

sprite3: ;handle not tapped
     ;vert tile attr horiz
  .db $60, $08, $00, $90   ;tile 8
  .db $68, $09, $00, $90   ;tile 9


sprite4: ;tapped handle
     ;vert tile attr horiz
  .db $60, $0A, $00, $90   ;tile 10
  .db $68, $0B, $00, $90   ;tile 11
  .db $60, $0C, $00, $88   ;tile 12
  .db $68, $0D, $00, $88   ;tile 13


***NOTE*** The code I listed is just an example, so it proably has errors in the logic. I can fix that. I am just confused on process.

Sorry if my question isn't clear, I'm just so confused, I really don't even know how to ask what I'm trying to do.

You only need to load the sprites when you're loading the screen for the first time. After that's it's just changing what tile each sprite is using, if you want it to appear in the same exact spot. Can you post your full code on pastebin and send me a PM?  (I'll also need to see your CHR file)

Done. Do you need my CHR file?

EDIT: Reread your message. Sending.

Issue resolved thanks to KHAN Games.

OK, my collision code still doesn't work right. Anyone know of any decent tutorials that don't assume you're using metatiles?

[code]
; create index into nametable from player x,y
; return non-zero for a collision between player and bg tile
check_collisions:
lda #$00
sta index + 1
lda player_y
and #%11111000
asl
rol index + 1
asl
rol index + 1
adc #game_bg
sta index + 1
lda player_x
lsr
lsr
lsr
tay
lda (index),y
rts
[/code]

game_bg points to the (uncompressed) nametable data. It sort of works, but characters get stuck sometimes (guess I have to move them, then "eject" them the opposite direction if a collision occurred?), and other times it just doesn't seem to detect collisions right. Basically I'm just classing anything non-zero in the nametable as solid at the moment. Any pointers at all?

Thanks!