changing playfield color on the fly

[+hloberg]

OK, here is another, you probably can't do that, question.

1st off, I am writing this program (Parsec 2600) in the standard 8k kernel because I want to flash the ROMS myself just to see if I can. never did that before so i thought i start off simple.

Now back to the question.

I have set up a multicolored playfield with pfcolors:

What I want to do is change the color of one line at a time without having to do another pfcolors: since I have no idea what the color change will be on the various lines. If i had to use pfcolors: every time I would have to have about a dozen different pfcolors and choose which one to use every game cycle.

my theory is i can POKE a value into the one line I want to change the color. but i don't know where to POKE or if batari will override the value.

any ideas or am i totally off base.

thx, HLO

[+Random Terrain]

You are probably looking for what batari did for me here:

 

atariage.com/forums/topic/122998-double-click-draw/#entry1487807

 

But it may not be compatible with the current version of bB since he did that a million years ago.

[+hloberg]

You are probably looking for what batari did for me here:

 

atariage.com/forums/topic/122998-double-click-draw/#entry1487807

 

But it may not be compatible with the current version of bB since he did that a million years ago.

Looks like what I need. I'll give it a try. thanks.

[+hloberg]

I had to modify the color change 2600basic.h and add some stuff from the current 2600basic.h to make it run but it looks good on the test file.

now to see if it runs in a real program with my modifications to the header file. if it does i will post the new color change 2600basic.h for inspection.

Edited April 10, 2017 by hloberg

[+hloberg]

2600basic.zip

Here is the NEW modified color change 2600basic.h that I created from merging parts of the old color change 2600basic.h with the new standard 2600basic.h

my test, so far, show only the known limitation that variables P-Z are not available. the new header compiles fine from the stuff i tested WITH the standard 8k kernel. no test been run beyond that.

See previous messages on how to use this. what it does is change a line of playfield color on the fly without having to do another PFCOLORS:

Edited April 11, 2017 by hloberg

[+hloberg]

UPDATE:

I have just found that if you add PFHEIGHTS to the kernel options it doesn't work. It looks like what it does is move the color table but I can't figure out where.

when you use pfcolor and pfheights together in the kernel options he seems to create a new table of the combined tables. I looked at the dump but still can't figure it out.

anyone have an idea?

[+Random Terrain]

I wonder if this would help at all:

 

atariage.com/forums/topic/112423-pfcolors-and-pfheights-together-in-ram/

[+hloberg]

I wonder if this would help at all:

 

atariage.com/forums/topic/112423-pfcolors-and-pfheights-together-in-ram/

actually it does, sorta. it explains what i was starting to figure out. combined tables are the problem. to work around uses the SC cart. I'm going to have to think about this.

thanks for the info.

[+hloberg]

Problem solved.

I am going to re-design the section to not need the color change. I need the PFHEIGHTS much more. won't be a fancy but it'll work.

Note: I learned a lot about bAtari and the 2600 researching the problem so this has been time well used. thanks.

Edited April 13, 2017 by hloberg