It is currently Sun Nov 19, 2017 12:05 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Thu Oct 12, 2017 8:56 am 
Offline

Joined: Sun Jan 31, 2016 9:55 pm
Posts: 36
I wouldn't worry too much yet about using up everything the MMC3 has available. The MMC3 can handle games like Super Mario Bros 3 and Kirby's Adventure, which have lots of enemies, graphics, and moves.


Top
 Profile  
 
PostPosted: Thu Oct 12, 2017 10:05 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
IMAGICA wrote:
[color=#FF0000]

Before I fix. Is there another way to manage jumping? Look at from Jump to Animation


I think you would benefit from testing out 6502 code and stepping through it, to see how it all works.

https://skilldrick.github.io/easy6502/

This is a nice online 6502 emulator. Try writing some small test code.


To answer your question, seems to be about program flow control. Right? When to JMP and when to JSR and when to branch? I'm not sure I understand your question.

EDIT - or do mean having a character jump? Like handling the animation and collision detection of a jump?

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Last edited by dougeff on Thu Oct 12, 2017 1:49 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Oct 12, 2017 11:38 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 862
Location: Sweden
IMAGICA wrote:
May need another Thread: Ok, Doing that in mind, and I know it's way off topic. For This game play, Should the sprites be bigger because you'll be flying via mid air dashing, shooting projectiles and wall jumping? I may need more ram than MMC3 chip for ai and other stuff. Maybe I need to understand how to compress code and to do this NMI Stuff before this challenge.


Before I fix. Is there another way to manage jumping? Look at from Jump to Animation
I think you should focus on getting your core working if it isn't already. And by core I mean your main loop and NMI. If you start adding lots of extra stuff before everything works as intended it will just complicate things even further.

I doubt you will need to compress any code. Get something smaller working first, and do things one step at a time. That's how I do it anyway.


Top
 Profile  
 
PostPosted: Thu Oct 12, 2017 3:55 pm 
Offline
User avatar

Joined: Thu Jul 13, 2017 5:17 pm
Posts: 34
dougeff wrote:

EDIT - or do mean having a character jump? Like handling the animation and collision detection of a jump?

Character.


Top
 Profile  
 
PostPosted: Thu Oct 12, 2017 5:13 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
The basics behind platformer physics is to have horizontal and vertical speeds for each object, that you add to their coordinates every frame. When characters are stationary, both speeds are 0. Pressing left/right gradually decreases/increases the horizontal speed by the acceleration value. The vertical speed can be affected by gravity (when there's no ground below a character, increase its vertical speed by the gravity value), or by jumping. Jumping can be implemented by setting the vertical speed to a high negative number, which will cause the character to move up pretty fast, and then gravity will kick in and gradually modify the vertical speed back into a positive value, eventually causing it to fall back down.


Top
 Profile  
 
PostPosted: Thu Oct 12, 2017 5:16 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1035
You can comment your code to describe what it's doing. What does a 1 in JumpState+2 mean? Why are you comparing JumpState+1 to #$14? What does #$14 represent?

Is player+1 the Y position?

I don't really follow what it's doing, it needs more context.

It requires understanding of 16 bit math, but here's fixed jump height code:

Code:
;playerY is the player's Y pixel position
;playerYSub is the player's Y position in between pixels (fractional position. 1/256th of a pixel)

;playerYSpd is the player's pixel speed (pixels per frame)
;playerYSpdSub is the player's fractional pixel speed (1/256th of a pixel per frame)

;grounded: If the player is on the ground, this is non zero
   
GRAVITY = 8
JUMPSTRENGTH = -512
GROUNDPOSITION = 200

   lda grounded;If the player is in the air, we need to
   beq addgravity;add gravity
   
   ;If here, the player is grounded and can jump if they press A
   
   lda buttons;if the player did not press A
   bpl nojump;no jump happened
   
   ;If here, the player pressed A, and we should jump
   
   lda #low(JUMPSTRENGTH);Set the player's speed
   sta playerYSpdSub;to the jump strength
   
   lda #high(JUMPSTRENGTH)
   sta playerYSpd
   
   ;and make the player not grounded
   lda #0
   sta grounded
   
   
   jmp updateyposition
addgravity:
   lda #low(GRAVITY);add gravity to the player's speed
   clc
   adc playerYSpdSub
   sta playerYSpdSub
   
   lda #high(GRAVITY)
   adc playerYSpd
   sta playerYSpd
   
updateyposition:
   ;Add speed to position to update the position
   lda playerYSpdSub
   clc
   adc playerYSub
   sta playerYSub
   
   lda playerYSpd
   adc playerY
   sta playerY
   
   ;If the player is not below the ground
   cmp #GROUNDPOSITION
   bcc jumpdone;We're done
   ;Otherwise, we ground them
   lda #$FF
   sta grounded
   
   ;set their falling speed to zero
   lda #0
   sta playerYSpdSub
   sta playerYSpd
   
   ;Set their position to the ground
   lda #GROUNDPOSITION
   sta playerY
   
   lda #0;The ground is a pixel position
   sta playerYSub;so the fractional part is just zero

jumpdone:
nojump:


Here's what it looks like:
Image
Edit: Actually that's probably not quite what it should look like. What I hacked it into probably ran it twice per frame instead of once. Changing GRAVITY to 24 would probably get a similar enough result to the animation.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 5:27 pm 
Offline
User avatar

Joined: Thu Jul 13, 2017 5:17 pm
Posts: 34
The background changed to it's 8x16 counterpart for some reason, looks freaky.
character's changed againmeaningless
reverted the pla and pha to the basicsno more STA/LDA temp for now
and now the second part of the jsr problems that Kasumi mentioned is beinfg worked on


Attachments:
File comment: hjk,
KitsuneTales.nes [40.02 KiB]
Downloaded 9 times
File comment: tyui
Kitsunetales.asm [24 KiB]
Downloaded 8 times
Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 8:33 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
I apologize, sincerely. Please don't take offense. This code is not good. It crashed almost immediately. Start over. Really. Blank slate. Start over. You need a stable loop before you add anything to it.

Fr .rs 1
Timer1 .rs 12
ANT .rs 4
T .rs 1
Srt .rs 6

What are these? I don't know. There's no comments, and the variable names are impossible to figure out.

NMI:

PHA
STA temp
TXA
PHA
TYA
pha

Why are you STA temp here? There's no other reference to temp.

...



RTS ?

no. The NMI routine ends in RTI. AFTER you do this stuff...

PLA
TAY
PLA
TAX
PLA
RTI




...

jsr Updating

but you have this subroutine end in...

PLA
TAY
PLA
TAX
PLA
rti

Where it should end in

RTS

This is almost certainly where it is crashing. Here or after the first NMI tries to RTS and it finds X and Y values rather than a return address.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 9:01 pm 
Offline
User avatar

Joined: Thu Jul 13, 2017 5:17 pm
Posts: 34
Removed Updating until scrollCheck
there is only RTS in between
edit
Code:
Forever:
  INC NMIB+2
 
  lda #$01
  sta NMIB ;allow NMI to draw, prevents incomplete buffering
nmi_wait:
 
 
  lda NMIB+2
  BEQ nmi_wait
 
  lda #$00
  sta NMIB
 
  ;wait for NMI to finish, this limits logic to a fixed frame rate
main:
 
  jsr ReadController1 ;read controllers
  [ Read conrtollers1:
....
  RtS]  jsr Updating ;state machine with all game logic, like: input handlers, moving objects, collisions gravity etc
[updating:
...
Rts]
 

 
 
 
  jmp Forever

 
 
 
 
 
  JMP Forever     ;jump back to Forever, infinite loop
 


Last edited by IMAGICA on Sun Oct 22, 2017 9:07 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 9:07 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
Just as a practice exercise, I recommend when you rewrite your code. Follow this constraint. No subroutine shall exceed 50 lines.

Then, your main routines will be just a series of subroutine calls.

JSR Read_Controllers
JSR Move_Hero
JSR Scrolling
JSR Move_Enemies
JSR Handle_Collisions

Etc.

Then, just before each subroutine, a detailed comment on what the subroutine does. If it passes any values, list what kind of value(s) it passes.

If a subroutine is longer than 50 lines, try to break it into smaller subroutines.

Every non-trivial variable should tell you what it does, just by its name.

y_scroll
x_scroll
hero_size
jump_height

And so forth.

In 6-12 months, when your code is 10,000 lines long, you will thank me.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 9:09 pm 
Offline
User avatar

Joined: Thu Jul 13, 2017 5:17 pm
Posts: 34
Challenge....Subverted
loop isn't working at all


Top
 Profile  
 
PostPosted: Mon Oct 23, 2017 12:18 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1035
Listen to me 11 days ago, listen to dougeff. Please restart, write smaller pieces of code, don't only come to us when your code visibly doesn't work. You're clearly not understanding some of the things you're trying, and by the time it gets broken in a way you can see there is way too uncommented code for us to comb through in a reasonable amount of time.

Anytime you're not sure about something, you can just ask. Because anytime something appears to work, but you don't really understand why is a problem waiting to happen.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Mon Oct 30, 2017 6:16 am 
Offline
User avatar

Joined: Thu Jul 13, 2017 5:17 pm
Posts: 34
Where would the rti be?
Would it be after evey 50 lines or after all code before JMP Forever?


Top
 Profile  
 
PostPosted: Mon Oct 30, 2017 9:04 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
IMAGICA wrote:
Where would the rti be?
Would it be after evey 50 lines or after all code before JMP Forever?


In most of the games I programmed, there is 1 rti in the entire game code...

NMI:
inc nmi_flag
inc frame_count
IRQ:
rti

The IRQ handler being an empty routine that just returns.

My Ninja game has 2 RTIs in the entire game. One for NMI code (at the end of it) and one for the IRQ code (at the very end of it). It uses a MMC3 mapper generated IRQ (scanline counter) to do a mid-screen split scroll.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Mon Oct 30, 2017 1:42 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
Double post... just making sure you understand.

As the 6502 executes code, it keeps track of the current address of code being executed, called program counter (PC).

JSR - "jump to subroutine", takes pushes the address-1 (2 bytes) of the next operation on to the stack, and replaces the PC with then JSR address, at which point it starts executing from the subroutine.

RTS "return from subroutine", it pops 2 bytes off the stack, and puts them into the PC, at which point it starts executing from the next line after the last JSR.

An interrupt (NMI or IRQ), will pushes three bytes onto the stack. First is the high byte of the return address, followed by the low byte, and finally the status byte from the P processor status register. Then it replaces the PC from the NMI (or IRQ) vector table at the end of the ROM, at which point it starts executing from the NMI (or IRQ) routines.

RTI -"return from interrupt" pops 3 bytes from the stack, first the processor status flags, then the return addresses, replacing the PC, at which point it will continue executing from wherever (could be anywhere) it was prior to the interrupt.

If you try to RTI before an interrupt happens, it will try to pop 3 bytes off, but not get a usable address, which would crash the game.

If you JSR, then RTI, it will push 2 bytes, but try to pop 3 bytes. It won't get the right address, since the first byte is the processor flags, and it will crash the game. (It's not even the same address pushed. JSR pushes the next line minus 1, and an interrupt pushes the next line exactly. I don't know why they engineered it that way, but it makes it doubly incompatibe).

Clear?

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 77 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group