Pallete affects scroll value

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

russellsprouts
Posts: 53
Joined: Sun Jan 31, 2016 9:55 pm

Re: Pallete affects scroll value

Post 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.
User avatar
dougeff
Posts: 3078
Joined: Fri May 08, 2015 7:17 pm

Re: NMI Is frozen / Not fully working

Post 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?
Last edited by dougeff on Thu Oct 12, 2017 1:49 pm, edited 1 time in total.
nesdoug.com -- blog/tutorial on programming for the NES
Pokun
Posts: 2675
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Pallete affects scroll value

Post 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.
User avatar
IMAGICA
Posts: 61
Joined: Thu Jul 13, 2017 5:17 pm
Contact:

Re: Pallete affects scroll value

Post by IMAGICA »

dougeff wrote:
EDIT - or do mean having a character jump? Like handling the animation and collision detection of a jump?
Character.
In Progress:
Tengu Tales (MMC3 Test first)[360 degress bullet direction math]
Baseball Brawlers (MMC5 full features, "Yoshi's Island")[Square root table, SPG ]
Smash ("port",MMC5 )[Character Movement]
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Pallete affects scroll value

Post 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.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: Pallete affects scroll value

Post 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:
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.
User avatar
IMAGICA
Posts: 61
Joined: Thu Jul 13, 2017 5:17 pm
Contact:

Re: Pallete affects scroll value

Post 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
Attachments
KitsuneTales.nes
hjk,
(40.02 KiB) Downloaded 85 times
Kitsunetales.asm
tyui
(24 KiB) Downloaded 74 times
In Progress:
Tengu Tales (MMC3 Test first)[360 degress bullet direction math]
Baseball Brawlers (MMC5 full features, "Yoshi's Island")[Square root table, SPG ]
Smash ("port",MMC5 )[Character Movement]
User avatar
dougeff
Posts: 3078
Joined: Fri May 08, 2015 7:17 pm

Re: Pallete affects scroll value

Post 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.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
IMAGICA
Posts: 61
Joined: Thu Jul 13, 2017 5:17 pm
Contact:

Re: Pallete affects scroll value

Post 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
  
Last edited by IMAGICA on Sun Oct 22, 2017 9:07 pm, edited 1 time in total.
In Progress:
Tengu Tales (MMC3 Test first)[360 degress bullet direction math]
Baseball Brawlers (MMC5 full features, "Yoshi's Island")[Square root table, SPG ]
Smash ("port",MMC5 )[Character Movement]
User avatar
dougeff
Posts: 3078
Joined: Fri May 08, 2015 7:17 pm

Re: Pallete affects scroll value

Post 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.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
IMAGICA
Posts: 61
Joined: Thu Jul 13, 2017 5:17 pm
Contact:

Re: Pallete affects scroll value

Post by IMAGICA »

Challenge....Subverted
loop isn't working at all
In Progress:
Tengu Tales (MMC3 Test first)[360 degress bullet direction math]
Baseball Brawlers (MMC5 full features, "Yoshi's Island")[Square root table, SPG ]
Smash ("port",MMC5 )[Character Movement]
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: Pallete affects scroll value

Post 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.
User avatar
IMAGICA
Posts: 61
Joined: Thu Jul 13, 2017 5:17 pm
Contact:

Re: Pallete affects scroll value

Post by IMAGICA »

Where would the rti be?
Would it be after evey 50 lines or after all code before JMP Forever?
In Progress:
Tengu Tales (MMC3 Test first)[360 degress bullet direction math]
Baseball Brawlers (MMC5 full features, "Yoshi's Island")[Square root table, SPG ]
Smash ("port",MMC5 )[Character Movement]
User avatar
dougeff
Posts: 3078
Joined: Fri May 08, 2015 7:17 pm

Re: Pallete affects scroll value

Post 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.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
dougeff
Posts: 3078
Joined: Fri May 08, 2015 7:17 pm

Re: Pallete affects scroll value

Post 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?
nesdoug.com -- blog/tutorial on programming for the NES
Post Reply