Scrolling - NESdev BBS

Scrolling
by lynxsolaris on 2006-01-26 (#8651)

I've finally have my background to scroll left to right or right to left depending
on which direction the player has pressed the directional pad.
However, it scrolls way to fast for my liking. What are your ideas for
slowing the scroll speed down? Thanks in advance.

by tepples on 2006-01-26 (#8656)

How fast is it scrolling right now? Is it going about one screenwidth every 4 seconds, or is it going faster?

by baisoku on 2006-01-27 (#8667)

Scroll rate is completely dependent on the game type, main character/sprite size, playfield layout, etc. Generally, with a console locked to ~60Hz, allowing for only 1 pixel or 2 pixel per frame velocity will be far too restrictive. I encourage you to research fixed point math operations. Using simple fixed point schemes, you can represent fractional velocities, distances, accelerations, etc. using the 8- and 16- bit values the 2a03 is comfortable with. In fact, many modern applications can benefit from fixed-point as opposed to floating-point operations, due to the fact that the resolution of the fractional components are always constant, unlike float/double math.

if you're not familiar with the concept: http://www.google.com/url?sa=t&ct=res&cd=9&url=http%3A//www.essentialmath.com/FixedFloat.pps&ei=1dTZQ5bYFZT-qAKywpXECA&sig2=fvf1mZaVwGxCayvYpOVsig

if you are, please forgive my misinterpretation of your aptitude.

by lynxsolaris on 2006-01-27 (#8672)

tepples wrote:
How fast is it scrolling right now? Is it going about one screenwidth every 4 seconds, or is it going faster?

Tepples, it seems to be faster than that.

by lynxsolaris on 2006-01-27 (#8673)

baisoku wrote:
if you are, please forgive my misinterpretation of your aptitude.

No problem but I am familiar with fixed point math. However, I'm still
learning how to implement fpm in 6502 asm.

Thanks.

by tepples on 2006-01-27 (#8705)

lynxsolaris wrote:
tepples wrote:
How fast is it scrolling right now? Is it going about one screenwidth every 4 seconds, or is it going faster?

Tepples, it seems to be faster than that.

How fast is it going? One screenwidth per 4 seconds is one pixel per vblank. One screenwidth per half second is one tile per vblank. Could you paste the parts of your program that write to $2000, $2005, and $2006?

by lynxsolaris on 2006-01-27 (#8708)

tepples wrote:

How fast is it going? One screenwidth per 4 seconds is one pixel per vblank. One screenwidth per half second is one tile per vblank. Could you paste the parts of your program that write to $2000, $2005, and $2006?

sure thing ... all I'm doing is reading the controller and if the user presses
left or right then I either increment / deincrement scrollPos (inside NMI)

Code:

.zp
scrollPos = $00

......

main:
sei
cld
lda #$00
sta <scrollPos

.......

nmi:
jsr controlStrobe ; read controller
jsr dmatrans ; where I do my spr dma stuff
lda #$0
sta $2000
lda #%10001000
sta $2000
lda scrollPos
ldx #$00
sta $2005
stx $2005
int:
rti

controlStrobe:
lda #$01
sta $4016
lda #$00
sta $4016

lda $4016 ; A button .. nothing for now
lda $4016 ; B button ...
lda $4016 ; Select
lda $4016 ; Start
lda $4016 ; Up
lda $4016 ; down
lda $4016 ; Left
and #1
beq Right_Press
dec scrollPos
Right_Press:
lda $4016 ; Right
and #1
beq stop_rts
inc scrollPos
stop_rts:
rts

.....

"..." is, of course, removed code to save space. I'm sure what I did
is really basic but is my first attempt at scrolling. Thanks Tepples.

by tepples on 2006-01-27 (#8709)

I notice that you're not saving and restoring registers A and X around your NMI handler. Is your main thread doing anything other than 'loop: jmp loop'?

And you should be reading the controller after you update the screen, not before; otherwise you stand a greater chance of overflowing vblank time as your engine grows more complex.

by lynxsolaris on 2006-01-27 (#8710)

tepples wrote:
I notice that you're not saving and restoring registers A and X around your NMI handler. Is your main thread doing anything other than 'loop: jmp loop'?

just the basic loop: jmp loop right now.

tepples wrote:
And you should be reading the controller after you update the screen, not before; otherwise you stand a greater chance of overflowing vblank time as your engine grows more complex.

so like this?
Code:
nmi:

jsr dmatrans ; where I do my spr dma stuff
lda #$0
sta $2000
lda #%10001000
sta $2000
lda scrollPos
ldx #$00
sta $2005
stx $2005
jsr controlStrobe ; read controller after

tnx.[/code]

by tepples on 2006-01-27 (#8711)

Another thing that might be happening is that you don't need to write to $2000 twice.

by lynxsolaris on 2006-01-27 (#8712)

tepples wrote:
Another thing that might be happening is that you don't need to write to $2000 twice.

Good call. Taking out that 1st write to $2000 did slow it down. Also, was
moving the jsr controller stuff under the $2005 stuff in my NMI routine
correct?

by tepples on 2006-01-27 (#8713)

lynxsolaris wrote:
Good call. Taking out that 1st write to $2000 did slow it down.

Because you're no longer repeatedly triggering an NMI.

Quote:
Also, was
moving the jsr controller stuff under the $2005 stuff in my NMI routine
correct?

Yes. If you're using a structure similar to that of SMB1 (whole game runs as an NMI handler), put all game logic after all display logic.

by lynxsolaris on 2006-01-27 (#8714)

tepples wrote:
lynxsolaris wrote:
Good call. Taking out that 1st write to $2000 did slow it down.

Because you're no longer repeatedly triggering an NMI.

Quote:
Also, was
moving the jsr controller stuff under the $2005 stuff in my NMI routine
correct?

Yes. If you're using a structure similar to that of SMB1 (whole game runs as an NMI handler), put all game logic after all display logic.

Thanks for the explaination. I understand now.