Change playfield colors using variables?

[bjbest60]

Hello all,

 

I'm wondering if it's possible to change pfcolors (using that kernel option) via variables. I know it's been alluded to / discussed in various other posts, always with the claim that pfcolors needs to be defined with constants.

 

Attached is an example that borrows / steals most of its code from others. Press fire to scroll and randomly create a sprite, using bogax's code in this thread. Each line of the sprite can change colors randomly, using SeaGtGruff's code here. Press Reset to cycle through random colors.

 

I added a feature that takes the random sprite and translates it to playfield pixels. Press Select to render the sprite in the third "column" of pfpixels.

 

Since I already have the variables set aside for the random colors of the sprite, I'd like to use those same variables to make the pfcolors the same as the sprite's colors. I see on the memory map that the pfcolortable pointer is at $F0, but I don't know how to manage that meaningfully, and the assembly code mentions a pfcolorlabel13, and I don't know what that is or what to do with it.

 

My code and binary are attached. Are there any possibilities here?

 

Thanks!

world4.bas

world4.bas.bin

[Lillapojkenpåön]

I don't know if I'm missing some code or just pointing to the wrong ram adress but seems doable without modifying the kernel slightly

 

world4_PFCOLORS_IN_RAM.bas

 

 

 

 

[bjbest60]

I don't know if I'm missing some code or just pointing to the wrong ram adress but seems doable without modifying the kernel slightly

 

world4_PFCOLORS_IN_RAM.bas

 

 

 

 

 

Unfortunately, that code doesn't work when I run it. I don't get a playfield at all. I tried something similar in asm last night and couldn't get it to work out.

 

I tried again this morning with a minimal test. I started the colors with variable a for ease of use. I discovered a few things:

 

set kernel_options pfcolors is necessary.

 

The constant to subtract in the lda's should be 83, not 84. I have no idea why, other than I saw it in some variations of the assembly output. (In some it's 84, in others it's 83.)

 

It is possible to control several lines of playfield colors independently. The pattern is:

• Line 1 of the playfield is a.
• Line 2 is b.
• Thereafter, each line is four letters after the previous one. So line 3 is f, line 4 is j, line 5 is n, etc.
• Line 9, which should be aux2 according to the memory map, doesn't work. I think this is due to using the pfcolors kernel option.
• But line 10 as aux6 does.

I have no idea why the colors would be every four variables. Maybe it's related to the fact that each playfield line is four bytes long?

 

I'd have no qualms about using the weird use-every-fourth-letter pattern, except you run out of letters before you can control each line. I can't work with line 9 and don't know where to try to control line 11.

 

Code and binary are attached, and they show independently cycling lines. Is there some additional assembly code that could somehow load / redirect each pfcolor variable to something more sequential?

 

Thanks!

minimal_pfcolors_in_ram_test.bas.bin

minimal_pfcolors_in_ram_test.bas

Edited May 22, 2019 by bjbest60

[Lillapojkenpåön]

Aha, well the pfcolortable looks like this

pfcolorlabel13

.byte $86,0,0,0

.byte $88,0,0,0

.byte $86,0,0,0

.byte $88,0,0,0

.byte $86,0,0,0

.byte $88,0,0,0

.byte $86,0,0,0

.byte $88,0,0,0

.byte $86,0,0,0

.byte $88,0,0,0

.byte $86,0,0,0

So it stores zero into the other three bytes, maybe it's possible to do that in ram to to get the variables sequential?

[bjbest60]

So it stores zero into the other three bytes, maybe it's possible to do that in ram to to get the variables sequential?

 

 

Thanks for the info about how the table is set up. Yes, realigning / reconfiguring the storage and/or pointers would be ideal. But something like that is well beyond my asm / bB knowledge, though. I'd welcome anyone's advice / code!

 

That being said, here's an updated example that can change ten lines (with no skipped lines) independently. It basically maximizes the span of the accessible memory map, starting with the 12th row of the playfield (so pf scrolling wouldn't work / make sense), and ending with temp7 and aux3.

 

Can monkeying with temp7 have unintended consequences elsewhere? I'm not sure if it's used by bB somehow behind the scenes. I feel aux3 is fairly safe if you don't need to do anything beyond displaying a basic score, but I'm willing to be corrected there, too.

 

The eleventh line points to stack1 in the memory map. I've tried to directly alter that variable, and no matter what I change it to, that final playfield line is always gray. I imagine it's unwise to try to change it at all, so I'm not sure there's anything that can be done there. Were I to use this code, I'd probably probably just zero out var40-var43 and not have an eleventh line.

 

Code and binary are attached. It's kind of mesmerizing to look at.

minimal_pfcolors_in_ram_test_2.bas

minimal_pfcolors_in_ram_test_2.bas.bin