http://nintendoage.com/forum/ -Sqooner http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-10-07T15:08:43 -05.00 KHAN Games 1071
I like the buffer idea, I've seen that with drawing logic and it definitely becomes necessary when doing music (per MetalSlime's tutorials) so I'mma sharpen my skills with buffers and give that a go. And I'll definitely hunt down MRN's stuff and start working thru that.

Thanks again, everyone! ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-10-07T14:37:01 -05.00 KHAN Games 1071
These days I also split things like scroll writes, sprite 0 hits, and delay loops off from normal and gamestate NMI, which having NMI already in a separate area helped a lot with. Any time that you have to sit there and find a bunch of different ways to work around your own code it is probably time to start splitting things off. ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-10-07T14:17:55 -05.00 KHAN Games 1071
The "proper" way to do it is to create some sort of routine that writes to RAM all the background graphics/palette updates you need to do, and then when NMI hits it looks to see if there are values in that buffer and draws them. So you're always constantly putting the "next frame's updates" in RAM and then when NMI comes it draws them all at once in one fell swoop. ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-10-07T11:48:52 -05.00 KHAN Games 1071
Also, thanks for the reply! ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-10-07T10:57:40 -05.00 KHAN Games 1071
Don't worry with doing it one way or the other depending on complexity, do it right. IIRC, NN and my tutorials all do it "correctly". It's been a while though. ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-10-06T12:45:42 -05.00 KHAN Games 1071
I've seen lots of different forums, articles on NesDev, answers here at NA, and other places talk about where to put the bulk of your code and mention something to the effect of "if your game is small enough" or "if your game isn't very complex", etc.

My question is (since no real context was provided in any of those places), what makes a game "small" or "complex" or "big"? Would small be something like Pong from Nerdy Nights or something smaller? Would complex be like SMB or Zelda II? I'm trying to have some examples so I know how exactly I would classify the game I'm working on so I don't have to do some massive overhaul later on and can do it more properly from the start. (Namely, deciding what functionality the NMI will do. Whether that's incrementing a counter like some people do, putting all the code in NMI which apparently SMB does, or making my code interrupt aware and going from there).

Thanks for the help whenever someone sees this,
LambBrainz ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-08-04T05:40:41 -05.00 KHAN Games 1071 Originally posted by: KHAN Games

Well, looking at the code, in order for the code to work inside NMI after pasting it back in there, you'd have to take out more than a single RTS. The NMI needs to get all the way down to RTI no matter what, so your code needs to be modified a little bit. Basically in every spot there is a RTS in MoveShip1, you'll need to delete the RTS and instead JMP to MoveShip2, so the second ship's routine is read. Then every place there is a RTS in MoveShip2, you'll need to delete the RTS and instead JMP to the end of MoveShip2 (after the RTS after .Reset2) so that it arrives at RTI.

Writing it the way you have it currently written (moving the routines out of NMI and just JSR'ing to them) is way cleaner/easier due to the ability to use the RTS in the individual subroutines. Jumping back to the main NMI this way allows you to not have to keep track of all the weird flow of things.

Right now, if it hits an RTS inside of NMI without having to go through a JSR to get there, it is returning to god knows where and it will behave erratically. I'm surprised it worked at all, honestly.   I never got to say thanks bud! Yeah, all good now. 
Anyway, I thought it'd be cool if you had to hit refresh one more time  

But seriously, much thanks for the help, you guys rock!

  ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-08-01T12:26:32 -05.00 KHAN Games 1071
Writing it the way you have it currently written (moving the routines out of NMI and just JSR'ing to them) is way cleaner/easier due to the ability to use the RTS in the individual subroutines. Jumping back to the main NMI this way allows you to not have to keep track of all the weird flow of things.

Right now, if it hits an RTS inside of NMI without having to go through a JSR to get there, it is returning to god knows where and it will behave erratically. I'm surprised it worked at all, honestly.   ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-08-01T03:57:14 -05.00 KHAN Games 1071
In its current version, both player 1 and 2 controllers can rotate their respective sprites. So to revert to the "non working" version you take lines 210 - 332  and cut them.
Then paste it over / replace the 2 "JSR MoveShip[1|2]" lines at the end of the NMI. I think you have to remove the last RTS as well since its no longer a subroutine being referenced, but that should be all.  
Player 1 controller will be able to spin the player 1 sprite, but Player 2 controller won't be able to spin player 2 sprite. 

Other than taking it out of the NMI and calling the MoveShip as a subroutine there's no changes to the code really.  ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=103138 2019-07-31T09:07:14 -05.00 KHAN Games 1071