Problem using pfcolors and pfscroll

[+Atarius Maximus]

I'm not sure if this is a bug in batariBasic, or if I'm just trying to use this function in a way that was not intended. Is it possible to define pfcolors multiple times in separate subroutines and then call them when you want to change the playfield colors? I've been experimenting with this in my primate plunge game, as I'd like to figure out a way to scroll the colors up with the playfield. When I attempt to call a subroutine that will change the colors, it changes the color of the background to some strange color combination that I didn't define in the subroutine (I defined all shades of green and got reds & blues).

 

My goal is to figure out how to scroll the colors up with the playfield when you use pfscroll up. Right now the strips of color on the playfield move up one and then back down, they don't scroll all the way to the top of the screen when you use pfscroll up. My intial idea was to use a variable to time color changes, and call subroutines to change the color at specific times to make it look like they're scrolling up, which is when I ran into the problem described above. Does anyone have any idea how I might accomplish this? Nothing I've tried so far works.

 

Thanks!

 

Steve

[CurtisP]

It seems to me that redefining the playfield colors could eat up a lot of ROM fast.

 

Howvever, by increasing the number of playfield colors defined and directly manipulating the playfieldcolors variable, you can achieve a color scroll.

 

Please note that this will NOT work if you are using both pfcolors and pfheights, since that uses a different indexing method.

pfcolorscroll.bas

pfcolorscroll.bas.bin

[+Atarius Maximus]

It seems to me that redefining the playfield colors could eat up a lot of ROM fast.

 

Howvever, by increasing the number of playfield colors defined and directly manipulating the playfieldcolors variable, you can achieve a color scroll.

 

Please note that this will NOT work if you are using both pfcolors and pfheights, since that uses a different indexing method.

 

Thanks for your help Curtis! That's exactly the effect I was trying to acheive.

 

Steve

[MausBoy]

The demo posted Uses a 32x12 playfield, but the playfield scrolls at a much higher resolution; so a single horizontal playfield line requires multiple calls to pfscroll to scroll up or down the height of one horizontal playfield line. Is it possible to scroll the pfcolors as smoothly as the playfield?

[CurtisP]

The demo posted Uses a 32x12 playfield, but the playfield scrolls at a much higher resolution; so a single horizontal playfield line requires multiple calls to pfscroll to scroll up or down the height of one horizontal playfield line. Is it possible to scroll the pfcolors as smoothly as the playfield?

I'm pretty sure that the playfield scrolls at low resolution (whatever pfheight is set to). If you are seeing something different, I would like to see the code.

[MausBoy]

You aren't the first person to think that, but if you add a "pfscroll up" to a program with a playfield you'll see that you are wrong. Read up on the Playfieldpos variable and Shakescreen to learn more about how vertical scrolling works in bB.

[CurtisP]

You aren't the first person to think that, but if you add a "pfscroll up" to a program with a playfield you'll see that you are wrong. Read up on the Playfieldpos variable and Shakescreen to learn more about how vertical scrolling works in bB.

 

I see now. Unfortunately PFCOLORS are tied directly to the PLAYFIELD lines, although a Kernel mod might get you what you want. I'll have to take a look.

[CurtisP]

Nope, the way the kernel is structured, lines of color always go with lines of playfield. Sorry about that (on the plus side, I now understand the Kernel a little better).

[lord_mike]

It seems to me that redefining the playfield colors could eat up a lot of ROM fast.

 

Howvever, by increasing the number of playfield colors defined and directly manipulating the playfieldcolors variable, you can achieve a color scroll.

 

Please note that this will NOT work if you are using both pfcolors and pfheights, since that uses a different indexing method.

 

So... since you brought it up... what needs to be change to make your example work with both pfcolors and pfheights? I've been looking at the assembly, and I've tried altering the variable with no luck.... the BBasic compiler doesn't seem to want to write the extra pfcolor data into memory, making it impossible to move the pointer to a new location... I think

 

Any thoughts how to make it work? Any help is greatly appreciated!

 

Thanks,

 

Mike

[CurtisP]

It seems to me that redefining the playfield colors could eat up a lot of ROM fast.

 

Howvever, by increasing the number of playfield colors defined and directly manipulating the playfieldcolors variable, you can achieve a color scroll.

 

Please note that this will NOT work if you are using both pfcolors and pfheights, since that uses a different indexing method.

 

So... since you brought it up... what needs to be change to make your example work with both pfcolors and pfheights? I've been looking at the assembly, and I've tried altering the variable with no luck.... the BBasic compiler doesn't seem to want to write the extra pfcolor data into memory, making it impossible to move the pointer to a new location... I think

 

Any thoughts how to make it work? Any help is greatly appreciated!

 

Thanks,

 

Mike

 

IIRC, you can't do it at all with pfcolors and pfheights. The reason is that each pfheight and pfcolor is stored side by side, and a single pointer is used to point to both. I'm not even sure if you can change the pointer safely, but if you could, then the height of each pf row would change along with the color.

 

Unfortunately, a number of thingds are hardcoded into the kernel and while some things can be tricked into working without modifying the kernal, others can not