nesdev.org

No problem - here is some code. Hopefully it's enough context? I have added a acceleration and deceleration method to my movement (works fine). Now I have to update my collision detection. This is where the problem is coming in. Here is the code that works in line. For example, this reads the point ...

Hey guys - thanks. I push all my stack values at the top of the NMI and pull them at the end. So that's not it... But more importantly, nothing is being pushed or pulled during this routine. I'm mostly perplexed that it works perfectly in line, but not as a routine. Thanks for the suggestions though...

So this is the first time I've experienced this. It's sorta wacky. I have a routine that I'd like to use in a few instances, so I set up a JSR->Routine->RTS scenario. It does not work. I mean, there are no errors returned, however its effect does not work... Now, if I take the meat of the routine (a...

Lidnariq - do you happen to have any past NES homebrews of note? Thanks for responding!

Hey all - looking to profile some homebrewers and their projects. Will be traveling to Portland and Seattle this month and was wondering if there are any active NES homebrewers in that area not afraid to be on camera? Or perhaps some of you may know someone?

Let me know! Thanks.

Hey friend - yeah, this I figured out. It's more using 16bit math for the acceleration routine that's tripping me up. I elaborated much more in a response PM. Thanks for the constant and quick feedback everyone

Right - I'm still confused though, about drawing the 'sub pixel'. For instance, prior to starting to work with sub-pixel movement, I had a simple variable called playerX. L and R inc or dec playerX, and then it was written to spriteRam+whatever to determine the tiles x position in the screen. Easy. ...

Alright - so here's a follow up question on this... I have understood the very easy method of implementing 16bit math to handle 'sub pixel movement'/acceleration...however I'm sort of confused how to translate that to screen position. For acceleration, for instance...it was very simple to add a low ...

Tepples - that is an awesome resource! Thanks! And Kasumi...you're right. That was brain-dead-simple! *palm to forehead*. Very easily integrated.

Hey all - thanks for the responses. Yes, X is set to 8 before jumping to the routine. I tried adding it just before the controller bytes loop just in case to the same ends. It's a gremlin, for sure. Yes, RAM is cleared at reset prior to turning the NMI on, yet when this routine is called inside the ...

Been seeing a few posts on this and have been experimenting with a few things. I'm trying to get a good handle on the best method for sub pixel movement (seems imperative to implement, lest everything always move by multiples of 'one pixel'). Things like acceleration are impossible without this. Jus...

This is something that went unnoticed until now. I have a controller reading routine that seems to work just fine. It's this: GamePadCheck: LDA #$01 STA $4016 LDA #$00 STA $4016 ReadControllerBytesLoop: PHA LDA $4016 AND #%00000011 CMP #%00000001 PLA ROR DEX BNE ReadControllerBytesLoop STA gamepad R...

I had written a lot about how to get left, right, up or down, but it boils down to exactly what you're thinking. absolute value of object X midpoint - enemy X midpoint. absolute value of object Y midpoint - enemy Y midpoint. If X distance was greater than Y, collision is horizontal, else collision ...

This might be more of a programming question than NES specific, however I can conceive of plenty of ways to do this with higher level functions or if cycles weren't a concern...so I guess I'm looking for a suggested method for something much more efficient - I'm looking to essentially detect whether...

So I've worked through and, with the help of posts I've found on the subject, developed a PRNG that works for me pretty well...however, I'd love to develop something that gives me a random seed value for it prior to, say, player input. Does anyone have any methods for this? Having a random seed valu...