kernel don't panic: a chart to the valid kernel option combos

[kisrael]

I'm trying to get back into the bB groove a bit.

 

It occurred to me that the list of kernel options in RT's maintenance of the Command List is a bit opaque; if you have one option you know you need, it's not easy to see at a glance what other options it's compatible with, incompatible with, or dependent on. My solution is a chart:

 

http://alienbill.com/2600/kernel.cgi

 

The Perl script to generate that is hypergeeky, but I think the end result makes it much easier to quickly know if you're on solid ground when it comes to these options.

 

Random Terrain, would it make sense to include this chart (maybe prettified a bit) or at least a link into the command list? I hope the benefit of this kind of visualization is obvious.

Edited December 24, 2008 by kisrael

[yuppicide]

I am fine with what Random Terrain has. Your stuff is redundant.

 

For example on the left you have for example "player1colors pfcolors no_blank_lines" -- that tells me all I need to know there.. I don't need to look at any chart on the right.

[kisrael]

I disagree that there's no value here, that it's redundant:

say you know if you had full multicolor player options if you wanted to experiment w/ no_blank_lines. To figure out if they were A. mutually incompatible, B. one worked but not the other, or C all were fine together, you would have to look through every line of the list of ok combinations, find the ones that had no_blank_lines, and see which player color options are in those lines. I'd argue it's MUCH easier with this chart, because you just have to look in a column rather than reading each line.

 

If you already have a single line like "player1colors pfcolors no_blank_lines" you said, sure, the chart doesn't give you new information - you know what's there. But this chart makes it faster and easier to see that you won't be able to add in playercolors. So, not redundant.

[+Random Terrain]

That list is straight from batari and until some time in 2008, I didn't try any of them, so I was kind of afraid to mess with the list. Now that you've created a chart, I'll see if I can do my usual gaudy version. If my test chart ends up looking like poo, I'll just link to your chart. I'll see if I can get it done within the next few days.

 

Thanks.

[SeaGtGruff]

One addition that might be good is something to show you what you'll lose by using certain options-- like, you'll have to give up missile1, or missile0, etc.

 

Michael

[kisrael]

That's a very good point!

[MausGames]

One addition that might be good is something to show you what you'll lose by using certain options-- like, you'll have to give up missile1, or missile0, etc.

 

Michael

 

 

If you add that, don't forget to mention that you give up horizontal scrolling if you use no_blank_lines.

 

I've always wondered why "player1colors pfheights background" was a valid combination. You probably might as well leave that one out.

[kisrael]

I'll try to capture everything relevant about the combos that's listed in the document in the chart

[+Random Terrain]

I'll try to capture everything relevant about the combos that's listed in the document in the chart

I'm glad I had other things to do first. I'll wait until you update your chart before I make my version of it then.

[yuppicide]

I think maybe I was just used to using Random's page rather than yours. So maybe I was making a snap judgement and am sorry if I came across as harsh, although I still prefer the way I look at it on his page.

[+Random Terrain]

I think maybe I was just used to using Random's page rather than yours. So maybe I was making a snap judgement and am sorry if I came across as harsh, although I still prefer the way I look at it on his page.

I'll leave that stuff the way it is, but I'll also add a version of kisrael's updated chart when he's finished.

[+Random Terrain]

Any news on the updated chart yet?

[jrok]

Is "pfcolors & pfheights & background" really a legal kernel option set?

 

background

Change background color instead of playfield color using pfcolors data. Normally, pfcolors changes the color of the playfield pixels by row, but background forces the data into the background, so you can have rows of different colors in the background and the usual single color playfield pixels on top of it all.

 

It sounds to me like the normal pfcolors statement is substituted to color the background. If that's the case, then how would you define the color of the playfield rows?

[SeaGtGruff]

Is "pfcolors & pfheights & background" really a legal kernel option set?

 

background

Change background color instead of playfield color using pfcolors data. Normally, pfcolors changes the color of the playfield pixels by row, but background forces the data into the background, so you can have rows of different colors in the background and the usual single color playfield pixels on top of it all.

 

It sounds to me like the normal pfcolors statement is substituted to color the background. If that's the case, then how would you define the color of the playfield rows?

With COLUPF. In other words, you get one playfield color.

 

Michael

[jrok]

Is "pfcolors & pfheights & background" really a legal kernel option set?

 

background

Change background color instead of playfield color using pfcolors data. Normally, pfcolors changes the color of the playfield pixels by row, but background forces the data into the background, so you can have rows of different colors in the background and the usual single color playfield pixels on top of it all.

 

It sounds to me like the normal pfcolors statement is substituted to color the background. If that's the case, then how would you define the color of the playfield rows?

With COLUPF. In other words, you get one playfield color.

 

Michael

 

Ah, I see. Thanks!

 

Do you know if there any way to write some of the rows to the playfield's color table and the rest of the rows to the background?

 

Jarod

 

EDT: Or, failing that, could one limit the number of background rows, to make the size of the background smaller than the playfield?

Edited January 16, 2009 by jrok

[SeaGtGruff]

Do you know if there any way to write some of the rows to the playfield's color table and the rest of the rows to the background?

 

Jarod

 

EDT: Or, failing that, could one limit the number of background rows, to make the size of the background smaller than the playfield?

The only way to do the first would be to customize the kernel.

 

You can't change the number of rows, but if you're changing the background color instead of the playfield color, then you could always use the same color for two or more consecutive rows.

 

Michael

[MausGames]

SeaGtGruff, do you have any idea why ""player1colors pfheights background" is a valid combo?

[SeaGtGruff]

SeaGtGruff, do you have any idea why ""player1colors pfheights background" is a valid combo?

Well, batari would be the best person to ask, but I'm guessing it's simply a matter of no conflicts-- i.e., invalid combinations would be those where there's some kind of conflict. For example, you lose missile0 if you use playercolors, and you also lose missile0 if you use no_blank_lines, therefore you can't use playercolors and no_blank_lines at the same time. There's no conflicts with the player1colors pfheights background combination, although background has no effect without pfcolors.

 

Michael