Thanks for the opinions guys. For my learning I went with gravity but that may change. I have my character doing what I want for now. The next thing I want to learn is character interaction with obstacles. In my demo I am using to learn the type is a platformer but I guess it doesn't really matter. I am trying to learn how to make the player land on platforms and be impeded by obstacles. Im going to start with random platforms that the character can jump to. My first thought is that we put some sprites on the screen to create the platforms. Now when this is finished how do I check to see if the player is standing on them? I mean my first thought would be when the player is moving down, to chek to see if the players Y value is greater than or equal to the 'platforms'. I currently do this in my demo but the y value is uniform forming an invisible floor that the player could move along while I tested everything else. With many sprites at different heights it seems like that would be a lot of tests each frame. Is there an easier way? Like a general sprite collision routine and then figure out what it is interacting with (enemy, wall, floor etc.)

You could set up a routine to check the player sprite against every other sprite, or a certain range of them, and then go to a routine that determines what has been contacted, and what to do about it. That is kind of what I did with Spook-o'-tron since it is all sprite based, in an earlier build (in the end they all became the same points-wise and in terms of contact).

The issue is that it eats up a lot of CPU due to all of the checks, and you can only have 64 sprites total. The other problem with sprite-based platforms is the 8 sprites per scan line limit. Since backgrounds and sprites work different enough, if you want to expand your idea down the road it might be a good idea to start looking into doing platforms with backgrounds sooner than later (that would also allow your gravity engine to carry over), otherwise you could end up doing the work twice, and in two different ways (very little of my sprite based collision code seems to carry over to background use). MRN has a great tutorial on this, his Week 7 lesson (probably need to begin at week 5 for it to make sense; I skipped his ones deling with sprites when I started out). That is set up for treating all BG tiles the same, but with a small modification you can give the background tiles a "type" like structure and then pass through some one way, destroy others, fall through some, etc. His way also ties all of that to the metatile data so you do not have to have separate tables for any of that info. What you see on screen is what you get.

Awesome.  I will check that out.  That helps alot and thats exactly why I asked lol.  Much appreciated.  Its early so maybe this is a stupid question, what is MRN?
 

A forum user named "Mario's Right Nut" -- he has this tutorial.

  The other thing I would recommend is, as much as possible, do your collision logic based on your logical game actors and not based on sprites or tiles themselves. (ie have a logical bounding box for your main character, and do collision tests based on that bounding box, and not based on the sprites that make up the character. ) This gives you more flexibility if you change how the character is represented in terms of sprites. Similarly with backgrounds -- check against whatever level of background element/metatile your game would find appropriate (ie often 16x16 pixel blocks like Mario), and don't actually check against each individual hardware-level tile.

On that guide to platformers page I linked to previously, there's a section about collisions with platforms that's worth reading.

This was a very valuable lesson that I leanred during Spook-o'-tron. Bunnyboy kept saying, years ago, not to directly check against sprite things, but rather to create variables for them. I chalked it up to a waste of variables in Pong and went my own way. Why have an EnemyStatus variable, or 32 of them for that matter, when a "dead" enemy could just have a Y value of 01 for instance. Out of sight, out of mind. Well, let's just say that it led to a world of problems and that I ended up having to redo all of the sprite handling code at some point  . Off-screen enemy collision code started interferring with off-screen projectile and civilian code and I suddenly realized that variables would have solved everything.

MRN's background collision system checks against metatiles. It seems to work rather well, at least for 16x16 worlds.

Beau and his abbreviations...
 

Well it has taken about a month but I finally have my code working in line with MRN's tutorials.  I cant believe how much easier my code is to read and go through.  Much appreciated to everyone for the help.  I have made my way up to bounding boxes which is going to take some time.  The concept seems easy enough but putting it into action and actually understanding what it is doing is taking some time.  I am really trying to understand everything rather than just copy and paste and hope it works lol.  Debugging is getting easier for me as well.  I am so used to being able to step through the code with all my other development stuff. Had to think back to how I used to do things before that.  So by using the hex editor and some debug hex variables I am getting the hang of it.  Thanks again!

 

Awesome to hear man. I don't know if you realize quite how fast you're moving in comparison to some of us  .

I live and die by the Hex Editor. I even catch bugs that I don't know about by watching the Hex Editor.

I'm glad to hear that it is all working out!

I am not THAT accomplished with the hex editor lol.  But I can atleast check variables from it and see where maybe a bug is appearing by looking for changes or non changes where they should be.

Could someone explain how to structure PRG banks for MMC1 using asm6? I can switch CHR banks fine but PRG is a no go. I'm getting a lot of gray screens. Thanks.

Are you swapping $8000-BFFF or $C000-FFFF? What I am posting below is assuming $8000-BFFF is swappable and $C000-$FFFF are fixed.

I'm not familiar with MMC1 or ASM6, but maybe my UNROM code using NESASM3 can help point you in the right direction.  NESASM3 breaks banks out in the code in 8KB chunks (the .bank 0, .bank 1, etc), however, when you bankswitch, the entire 16KBs is swapped (so for bankSource=00, .bank 0 and .bank 1 are called). I have to note this because I think ASM6 does this differently. I think that banks are stored and called in 16kb chunks. Anyways, as you can see, all my swappable banks start at $8000. When I need to swap, I just call which 16kb bank I need with my bankswitching code. With UNROM, its as simple as writing the bank value to the bankswitching register. With MMC1, I do believe you have to use a shift register as per bunnyboy's Nerdy Nights tutorials. Take a look at the code below. As I said, I'm sort of combining my UNROM code with the MMC1 code provided by bunnyboy. It's also all in NESASM3, so there are probably some differences in the code. This is more for a basis to check your code to see if you can see any simple errors. Take all of it with a grain of salt. Here is also the NESdev page on MMC1 banking. http://wiki.nesdev.com/w/index.ph...


My Bank Code
;;;;;;;;;;;;;;;;;bankSource=00;;;;;;;;;;;;;;;;;;;;SWAPPABLE BANK
  .bank 0        
  .org $8000  
  ;CODE HERE
    
  .bank 1
  .org $A000
  ;CODE HERE   

;;;;;;;;;;;;;;;;;bankSource=01;;;;;;;;;;;;;;;;;;;;SWAPPABLE BANK
  .bank 2 
  .org $8000
  ;CODE HERE
    
  .bank 3
  .org $A000
  ;CODE HERE
;;;;;;;;;;;;;;;;;bankSource=02;;;;;;;;;;;;;;;;;;;;  SWAPPABLE BANK
  .bank 4                                                
  .org $8000
  ;CODE HERE

  .bank 5
  .org $A000
  ;CODE HERE

.  MORE SWAPPABLE BANKS UNTIL MY FIXED BANK
.
.
.
.
.

;;;;;;;;;;;;;;;;;bankSource=0F;;;;;;;;;;;;;;;;;;;;FIXED BANK
  .bank 30
  .org $C000
  ;CODE HERE

   .bank 31
  .org $E000
  ;CODE HERE


bunnyboy's MMC1 PRG Banking Routine
http://nintendoage.com/forum/mess...

PRGBankWrite:       ; make sure this is in a fixed bank so it doesnt get swapped away
  LDA bankSource    ; get bank number into A
  STA $E000         ; first data bit
  LSR A             ; shift to next bit
  STA $E000
  LSR A
  STA $E000
  LSR A
  STA $E000
  LSR A
  STA $E000         ; bank switch happens immediately here
  RTS


Routine to call Banking routine
LDA #$03
STA bankSource   ;Call bank 3
JSR PRGBankWrite ;Jump to banking code


I hope this helps.

 

That did help. I didn't make the connection that MMC1 is similar to UNROM and asm6 doesn't have a .bank directive. Those two and PRG_COUNT in the iNES header were throwing me off. Thanks for the help Mega Mario Man.

Yeah, I did some digging. It seems that ASM6 uses .base to start the bank and .pad to end the bank. I'm glad that helped you out, I was shooting from the hip just a bit on that one.

So I could use a little help, I was told that my code was doing most of it's logic in the NMI which is generally frowned upon, I'm trying to rearrange the code as so that is not so, I managed to get the file to compile, but now lost my ability to move sprites, if anyone would be willing to help me grokk this out I would really appreciate it, Assembly is hard lol https://hastebin.com/wahulohivi.p...

Doesn't look like you're calling your subroutines to check for button presses in your forever loop. Anything you want done outside of NMI has to be called between FOREVER and JMP FOREVER.

Also, in your NMI you'll want to push your A, X, and Y registers to the stack before doing anything else, then restore them all just before your RTI.


NMI:

    PHA
    TXA
    PHA
    TYA
    PHA

    ; do NMI stuff

    DEC sleeping ; set sleeping variable to #$00 so your main loop will run once

    PLA
    TAY
    PLA
    TAX
    PLA

    RTI


Then in your FOREVER loop do:


FOREVER:

    INC sleeping
.loop                  ; NMI will return in the loop with sleeping set to #$00
    LDA sleeping
    BNE .loop

    ; Call game logic subroutines here

    JMP FOREVER


 

Ok, so there are some issues in that code.

First off, you need your RTI to go right after your NMI is complete. It is how the system know that you are finished with the NMI. Right now you have it after GameEngineDone:. It needs to be after ';;;all graphics updates done by here, run game engine'.

Second, you really should Push and Pull your registers as ubuntuyou shows above. This preserves any values that are in them before your forever loop runs.

Third, you have this twice, you only need it once:

  .org $FFFA     ;first of the three vectors starts here
  .dw NMI        ;when an NMI happens (once per frame if enabled) the 
                   ;processor will jump to the label NMI:
  .dw RESET      ;when the processor first turns on or is reset, it will jump
                   ;to the label RESET:
  .dw 0          ;external interrupt IRQ is not used in this tutorial

It's best to keep this code in the bank with $E000 (in your case, bank 3).

Forth, All of your game engine code needs to happen between Forever: and JMP Forever. Here is my exact Forever Loop and NMI. This is the backbone that runs the entire game. All my setup code happens before the Forever loop, such as the RESET:, clrmem, turn on the NMI and PPU, etc.

;Game Setup Code Goes Here.
;----------------------------------------------------------------------
;-----------------------START MAIN PROGRAM-----------------------------
;---------------------------------------------------------------------- 
Forever:
  INC sleeping                     ;wait for NMI

.loop
  LDA sleeping
  BNE .loop                        ;wait for NMI to clear out the sleeping flag

  LDA #$01
  STA updating_background          ;this is for when you are changing rooms or something, not really needed here
                                   ;it will skip the NMI updates so as not to mess with your room loading routines

  JSR ReadController1  ;;get the current button data
  JSR ReadController2  ;I like to read my controllers right after the NMI so save PPU time.

  JSR GameStateIndirect     ;THIS IS MY GAME ENGINE. Everything happens here, sprite movement, enemy movement, etc.

  LDA GameState
  CMP GameStateOld
  BEQ .next
     JSR GameStateUpdate        ;These last 4 lines update my game states. This code is from Mario' Right Nut's Tutorials.
.next

  LDA #$00
  STA updating_background

  JMP Forever     ;jump back to Forever, and go back to sleep


;--------------------------------------------------------------
;-----------------------NMI ROUTINE----------------------------
;--------------------------------------------------------------
NMI:
  PHA                              ;protect the registers by moving values to the stack
  TXA
  PHA
  TYA
  PHA

nmi_start:                          ;write Sprite RAM
  LDA #$00
  STA $2003                        ; set the low byte (00) of the RAM address
  LDA #$02
  STA $4014                            ;Set High byte of sprite RAM

  LDA updating_background          ;check to be sure that the main program isn't busy
  BNE skip_graphics_updates

  JSR GameStateNMIIndirect       ;This runs NMI Specific code based on what game state I am in, Title, Playing, Credits, etc

  LDA #$00                            ;tell the ppu there is no background scrolling
  STA $2005
  STA $2005

  LDA #%10010000                    ; enable NMI, sprites from Pattern Table 0, background from Pattern Table 1
  ORA NameTableFlag                   
  STA $2000

  LDA EnablePPUFlag
  BEQ .SKIP
    LDA #%00011110                   ;enable sprites, enable background, no clipping on left side
    STA $2001   
    DEC EnablePPUFlag
  .SKIP:

  LDA MusicBank
  JSR Bankswitch
    jsr FamiToneUpdate                ;*MUSIC
  LDA #$00            ;start in bank 0
  JSR Bankswitch

  LDA #$00
  STA sleeping                     ;wake up the main program  (start forever loop)

skip_graphics_updates:

  PLA                              ;restore the registers
  TAY
  PLA
  TAX
  PLA

  RTI                              ;return from interrupt

You have it all there, you just need to reorder some of it. Hopefully, this points you in the right direction. This was a pretty big hurdle for me to clear when I was learning. I still remember the day it all clicked.
 

Thank you guys for the help, before I put the engine into the forever loop, just want to double check I've done everything else correctly, also trying to single out what of my engine I need to put inside the forever loop, basically everything from 182 to 293? or would I include all the sub routines? It's just I suppose still hard for me to contextualize how the hardware is working. https://hastebin.com/anonolavoc.p...

Also, here's what I got when I tried the above code w/ sleeping, did I need to define this somewhere else? feel like im missing something obvious lol, attached is my error log 

Everything except variables, constants, and game startup code.

Here is my layout.

Header
Variables
Constants
Startup Code (Rest, clrmem, music init, sfx init, save data load, game state init, Enable PPU and NMI)
Forever Loop (with it waiting for the NMI right at the start)
     - Wait for NMI to start and finish
     - Read Controllers
     - Game Engine
     - Check if game state changed during engine
     - Loop back to forever and wait for NMI


The forever loop is exactly what it sounds like, one big loop that runs all of your data from 1 frame. You update everything in this loop and when you are finished, you put in a wait for the NMI to hit. As long as it is enabled, the NMI interrupts once a frame. This code ensures that we wait for the NMI to run before proceeding with the rest of our code.

Forever:
  INC sleeping                     ;wait for NMI

.loop
  LDA sleeping
  BNE .loop

This code at the end of NMI tells the Forever loop that is done and you can update the game code for the next frame:

  LDA #$00
  STA sleeping                     ;wake up the main program  
 
  PLA                              ;restore the registers
  TAY
  PLA
  TAX
  PLA

  RTI           ;Return from the Interrupt back to the Forever loop

This is how we "time" hitting the NMI. Otherwise, we could be running our game code and the NMI would Interrupt and mess up everthing. The only think that should happen during the NMI is writing to the PPU and APU. All other code goes in your game engine. So, if you have a background tile that needs to change (think Score or Time), you could update that data in your game code and then write it during the NMI. You will advance your sprites once per frame in your game code (updating the $0200 page in RAM), then the first part of the NMI writes the $0200 page to the PPU every frame. Even if you don't understand why at this point, that is what is happening here.

  LDA #$00
  STA $2003                        ; set the low byte (00) of the RAM address
  LDA #$02
  STA $4014                            ;Set High byte of sprite RAM

Does that clear it up some more?

I think I understand? Though what I'm still confused about is why I would be getting the same error about sleeping being an unkown operand, here's my current code where I attempt to place the engine inside the loop  (wait sent the wrong one) 

https://hastebin.com/goqexagoyo.p...

update: yeah no matter what I try, I keep gettin an error saying that sleeping is an undefined symbol in operand field  

put sleeping in your variables.

sleeping    .rs 1
 

Also, move lines 198 - 539 to after RTI or you can put that in bank 0 or bank 1. Where it is at now, all of that will try to run before the forever loop. These are your subroutines that are called from within your Game Engine inside of your Forever loop.
 
 

like so? (thank you for bearing with me) This got the sprite up on the screen again but i lost controller input it seems https://hastebin.com/okukuzelok.p...

We got this running through pms for those that were following along.

Another question, trying to follow Nerdy Nights 7 and implement collision with the paddles, I got the walls working, but what am I doing wrong here? If someone could breakdown the logic bunny boy is using for this I would really appreciate it,

CheckPaddleCollision:
LDA $0300
STA paddle1ytop
LDA $031C
STA paddle2ybot

LDA ballx
CMP #PADDLE1X
BCS .End
LDA bally
CMP #paddle1ytop
BCC .End
LDA bally
CMP #paddle2ybot
BCS .End

LDA ballx
CMP #RIGHTWALL
BCC .End
LDA #$00
STA ballright
LDA #$01
STA ballleft ;bounce, ball moving left, below here give point to p1, reset ball
.End:
RTS