Page 4 of 7
Re: Pallete affects scroll value
Posted: Thu Oct 12, 2017 8:56 am
by russellsprouts
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.
Re: NMI Is frozen / Not fully working
Posted: Thu Oct 12, 2017 10:05 am
by dougeff
IMAGICA wrote:
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?
Re: Pallete affects scroll value
Posted: Thu Oct 12, 2017 11:38 am
by Pokun
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.
Re: Pallete affects scroll value
Posted: Thu Oct 12, 2017 3:55 pm
by IMAGICA
dougeff wrote:
EDIT - or do mean having a character jump? Like handling the animation and collision detection of a jump?
Character.
Re: Pallete affects scroll value
Posted: Thu Oct 12, 2017 5:13 pm
by tokumaru
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.
Re: Pallete affects scroll value
Posted: Thu Oct 12, 2017 5:16 pm
by Kasumi
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: Select all
;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:
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.
Re: Pallete affects scroll value
Posted: Sun Oct 22, 2017 5:27 pm
by IMAGICA
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
Re: Pallete affects scroll value
Posted: Sun Oct 22, 2017 8:33 pm
by dougeff
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.
Re: Pallete affects scroll value
Posted: Sun Oct 22, 2017 9:01 pm
by IMAGICA
Removed Updating until scrollCheck
there is only RTS in between
edit
Code: Select all
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
Re: Pallete affects scroll value
Posted: Sun Oct 22, 2017 9:07 pm
by dougeff
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.
Re: Pallete affects scroll value
Posted: Sun Oct 22, 2017 9:09 pm
by IMAGICA
Challenge....Subverted
loop isn't working at all
Re: Pallete affects scroll value
Posted: Mon Oct 23, 2017 12:18 am
by Kasumi
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.
Re: Pallete affects scroll value
Posted: Mon Oct 30, 2017 6:16 am
by IMAGICA
Where would the rti be?
Would it be after evey 50 lines or after all code before JMP Forever?
Re: Pallete affects scroll value
Posted: Mon Oct 30, 2017 9:04 am
by dougeff
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.
Re: Pallete affects scroll value
Posted: Mon Oct 30, 2017 1:42 pm
by dougeff
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?