12 replies to this topic

[PacManPlus]

Hi:

I was hoping someone could answer this for me.

If I only wanted to rotate left (or right) one row of the playfield, how would I do it? I see there's a command to do the whole playfield screen, but I only want one row. I also see that it doesn't work with the multisprite kernel (which I am using)

Also, if I wanted to scroll the playfield down, and I'm using the multisprite kernel, is there a way as well?

Thanks in advance
Bob

[Wickeycolumbus]

I am not sure how to do it in bB, but here is how I think you would do it in Assembly:

;code.....

	 lda PFDATA,X
	 ror				   ; or rol for left movement
	 sta PF1			 ; or PF0 or PF2

;code.....

of course, this would not be executed every frame.

[batari]

PacManPlus, on Wed Apr 9, 2008 3:41 PM, said:

Hi:

I was hoping someone could answer this for me.

If I only wanted to rotate left (or right) one row of the playfield, how would I do it? I see there's a command to do the whole playfield screen, but I only want one row. I also see that it doesn't work with the multisprite kernel (which I am using)

Also, if I wanted to scroll the playfield down, and I'm using the multisprite kernel, is there a way as well?

Thanks in advance
Bob

The playfield in the multisprite kernel is stored in ROM and is reflected so you can't scroll it. With some limitations, however, you might be able to do something by defining several copies using the playfield: command, and calling them on alternate frames, with each having a small change, so you can at least have a sort of dynamic playfield.

Scrolling up and down is not possible right now, but this ability will be added in the future. I have already made the changes to a WIP kernel but they need some compiler support before I release them.

[Impaler_26]

The Playfield in the bB-Game Because It's There is moved down with this inline-asm code:

 rem We move the playfield down one level.
 for x=2 to 0 step 255
 for y=0 to 3
 asm
; Load from x*12+y
; Store to (x+1)*12+y
 lda x
 asl	; A=x*2
 clc
 adc x; A=x*3
 asl	; A=x*6
 asl	; A=x*12
 clc
 adc y; A=x*12+y
 tax	; X=x*12+y
 clc
 adc #12; A=x*12+y+12=x*12+12+y=(x+1)*12+y
 tay	; Y=(x+1)*12+y
 lda playfield,x
 sta playfield,y
end
 next
 next

Hope this helps...

[batari]

Impaler_26, on Wed Apr 9, 2008 4:23 PM, said:

The Playfield in the bB-Game Because It's There is moved down with this inline-asm code:

This code is for the standard kernel, but interesting nonetheless.

I suppose it would be worth mentioning that you can do some limited vertical scrolling with the multisprite kernel right now. My improvements were for fine scrolling, but if you want to scroll coarsely (i.e. one playfield block at a time) then all you need to do is define a playfield larger than you need it using playfield: and change the pointer into the ROM where the playfield data is stored when you need to scroll.

PF1pointer=PF1pointer+1:PF2pointer=PF2pointer+1 will scroll down, and:
PF1pointer=PF1pointer-1:PF2pointer=PF2pointer-1 will scroll up (Or I might be backward on that.)

Just don't go beyond the bounds of your playfield and it should work fine.

[PacManPlus]

Thank you for the answers, everyone.

I actually know how to do it in asm, but I wanted to keep this as much bB as possible.

I had actually wanted to start work on 'Super Circus Atari' (complete with dropping balloon levels and multiple acrobats a'la Super Breakout), but if the playfield really is in ROM, that makes this pretty much impossible.

Here's how far I got


BTW, that's supposed to be a trampoline at the bottom of the screen :-P

Edited by PacManPlus, Wed Apr 9, 2008 9:04 PM.

[SeaGtGruff]

PacManPlus, on Wed Apr 9, 2008 4:41 PM, said:

If I only wanted to rotate left (or right) one row of the playfield, how would I do it? I see there's a command to do the whole playfield screen, but I only want one row.

There isn't a built-in command to scroll just one row, but you can write an assembly routine to do it. I don't have time to try it right now, but it would be nice to have a routine to scroll a playfield row through a ROM table, so maybe I'll eventually get around to trying that and posting an example. For example, it would be cool to have different playfield rows scrolling at two or more different rates simultaneously.

PacManPlus, on Wed Apr 9, 2008 4:41 PM, said:

I also see that it doesn't work with the multisprite kernel (which I am using)

Also, if I wanted to scroll the playfield down, and I'm using the multisprite kernel, is there a way as well?

As batari pointed out, you can scroll vertically through a ROM table by defining a playfield that's taller than your displayed playfield area, and then changing the pointers that tell bB where the playfield data is.

Also, if you use the Superchip option with the multisprite kernel, then you can relocate the playfield to the Superchip RAM area, and use things like playfield drawing commands, and playfield scrolling-- but you have to write/use special versions of the include files, since the standard ones are designed for a 4-byte-wide asymmetrical playfield, whereas the multisprite kernel has only a 2-byte-wide reflected playfield. I've (re)written the routines for using playfield drawing commands in the multisprite kernel, but I haven't tackled scrolling yet, except for the vertical scrolling described in the previous paragraph.

Michael

[gambler172]

Hi Bob
Please show us a bin.It looks really nice.
greetings Walter

[Random Terrain]

batari, on Wed Apr 9, 2008 5:52 PM, said:

PF1pointer=PF1pointer+1:PF2pointer=PF2pointer+1 will scroll down, and:
PF1pointer=PF1pointer-1:PF2pointer=PF2pointer-1 will scroll up (Or I might be backward on that.)

I made a test program and tried both of those and the program will not compile. Is there something that needs to be included to make those work?

[batari]

Random Terrain, on Sat Apr 12, 2008 12:23 AM, said:

batari, on Wed Apr 9, 2008 5:52 PM, said:

PF1pointer=PF1pointer+1:PF2pointer=PF2pointer+1 will scroll down, and:
PF1pointer=PF1pointer-1:PF2pointer=PF2pointer-1 will scroll up (Or I might be backward on that.)

I made a test program and tried both of those and the program will not compile. Is there something that needs to be included to make those work?

It only works with the multisprite kernel, in case I wasn't clear on that.

[Random Terrain]

batari, on Sat Apr 12, 2008 1:28 AM, said:

Random Terrain, on Sat Apr 12, 2008 12:23 AM, said:

batari, on Wed Apr 9, 2008 5:52 PM, said:

PF1pointer=PF1pointer+1:PF2pointer=PF2pointer+1 will scroll down, and:
PF1pointer=PF1pointer-1:PF2pointer=PF2pointer-1 will scroll up (Or I might be backward on that.)

I made a test program and tried both of those and the program will not compile. Is there something that needs to be included to make those work?

It only works with the multisprite kernel, in case I wasn't clear on that.

Oh, I must have missed that. Thanks.

[SeaGtGruff]

Random Terrain, on Sat Apr 12, 2008 1:30 AM, said:

batari, on Sat Apr 12, 2008 1:28 AM, said:

Random Terrain, on Sat Apr 12, 2008 12:23 AM, said:

batari, on Wed Apr 9, 2008 5:52 PM, said:

PF1pointer=PF1pointer+1:PF2pointer=PF2pointer+1 will scroll down, and:
PF1pointer=PF1pointer-1:PF2pointer=PF2pointer-1 will scroll up (Or I might be backward on that.)

I made a test program and tried both of those and the program will not compile. Is there something that needs to be included to make those work?

It only works with the multisprite kernel, in case I wasn't clear on that.

Oh, I must have missed that. Thanks.

I think you should be able to do vertical playfield scrolling like that with the standard kernel, too, but the specifics of what you'd have to do would necessarily be different, since the playfield works differently in the two kernels.

Michael

[Random Terrain]

SeaGtGruff, on Sat Apr 12, 2008 1:04 PM, said:

I think you should be able to do vertical playfield scrolling like that with the standard kernel, too, but the specifics of what you'd have to do would necessarily be different, since the playfield works differently in the two kernels.

Thanks. I looked at the .lst file, but I don't know enough about what I am looking at to figure out what I should use instead.