How do I get the icing off my cake? (no_blank_lines and pfcolors)

[+Random Terrain]

If I get rid of the blank lines and use pfcolors, each playfield pixel has a thin layer of color from the row above it. Here's an example:

 

 

I assume that each former blank line is filled with the row color above it. I can see how that might be useful to have as an effect in some games, but is it possible for that thin coating of 'icing' to be the color below it instead of the color above it?

Edited May 3, 2008 by Random Terrain

[jbs30000]

This is just a wild guess, but, since with no_blank_lines you can't use missile0, I'm wondering if it isn't used to fill in the gaps. If so, then it might be hard to set it to an in-between color if two vertical pixels are different colors. But of course I could be totally wrong about that.

[CurtisP]

BB uses a two line kernel. The pixels are drawn each line. It appears that the playfield color is drawn after the first line is drawn and before the second line is drawn.

 

There is a limited amount of cycles available during the drawing phase. The reason that there is no missile when using no_blank_lines is because the instructions used to draw the missile are replaced with the instructions to increment the pointer to the playfield data (which would normally be executed during the blank line).

[jbs30000]

Thanks for the explanation. I enjoy learning the inner workings of the bB kernel.

Unfortunately this probably doesn't help Random Terrain though.

[+Random Terrain]

BB uses a two line kernel. The pixels are drawn each line. It appears that the playfield color is drawn after the first line is drawn and before the second line is drawn.

 

There is a limited amount of cycles available during the drawing phase. The reason that there is no missile when using no_blank_lines is because the instructions used to draw the missile are replaced with the instructions to increment the pointer to the playfield data (which would normally be executed during the blank line).

Thanks for the info. So that's why the missile is gone. I thought the missile was being used to fill in those lines.

[MausGames]

Just so you know, when the missile instructions are replaced with other kernel options, you can still access the missiles as full height bars using "ENAM0 = 2" and "ENAM1 = 2". They are still changed by NUSIZ in the same ways.

Edited May 17, 2008 by MausGames

[+Random Terrain]

Just so you know, when the missile instructions are replaced with other kernel options, you can still access the missiles as full height bars using "ENAM0 = 2" and "ENAM1 = 2". They are still changed by NUSIZ in the same ways.

Thanks. That's a good thing to know. I'll see what I can do with that.

[MausGames]

Sorry, also - I'm pretty sure if you are using kernel options that disable either missile, and don't use ENAM, you can use it's missilex,missiley, and missileheight as extra variables! Even one of those is great, but three is fantastic. If you DO use ENAM, you can still use missileheight as an extra variable, so either way keep that in mind if you use kernel options that take away missiles.

 

As far as your original question, I have no idea if it can be fixed or changed. It's been brought up before, and I don't think Batari has ever answered if it could be changed or if so why it hasn't been.

 

I like it, but I wish was there was a "pfcolorspos" just like there is a "playfieldpos"

Edited May 17, 2008 by MausGames

[+Random Terrain]

Sorry, also - I'm pretty sure if you are using kernel options that disable either missile, and don't use ENAM, you can use it's missilex,missiley, and missileheight as extra variables! Even one of those is great, but three is fantastic. If you DO use ENAM, you can still use missileheight as an extra variable, so either way keep that in mind if you use kernel options that take away missiles.

That's a great idea. I'm sure I'll need all of the extra variables that I can get. Thanks.

 

 

As far as your original question, I'm hoping that Batari's consistent lack of response regarding this issue means he thinks/knows it's possible to address but hasn't gotten to it. That's just a guess.

He's probably just busy or temporarily burned out on bB or both. He'll be back sooner or later.

[MausGames]

I'm really burnt out on not having finished games to show for my time.

 

I wish there were some bB contests going or something. There isn't a lot of code being posted, it seems like there should be a lot more going on here than there is. Has the response to bB been about what was expected? It would be nice to see great code and demos being posted frequently.

[+Random Terrain]

I'm really burnt out on not having finished games to show for my time.

Now that I have Visual batari Basic with the various helpful tools and features, I'm pretty confident that I'll get at least a few games finished. I can't promise that they'll be any good, but at least I'll have fun making them.

 

 

I wish there were some bB contests going or something. There isn't a lot of code being posted, it seems like there should be a lot more going on here than there is. Has the response to bB been about what was expected? It would be nice to see great code and demos being posted frequently.

Yeah, contests might get more people interested and current users pumped up. I thought more people would start pouring in once VbB was released, but I guess we'll need a manual/help page and some YouTube videos showing how much easier it is to make bB games with VbB. If I ever win some big money or start making a ton of money from the Internet, it would be cool to give the winner of each contest a thousand dollars, five-hundred dollars for second place, and one-hundred dollars for third place. That should get more people making bB games.

 

The limitations of bB might scare off a lot of people, even those who always wanted to make their own Atari 2600 games since they were kids. You can have two multicolored sprites, but you lose the missiles. Unless you're willing to strain your brain a little, you might think there's not much you can do with that. And you can have 6 single-color sprites, but they can flicker if not handled properly, the playfield is mirrored, and there are no kernel options yet. That's not something that would make the average person jump up and down about. For people used to all of the colorful and detailed graphics of games made by companies like Imagic and Activision that have stuff happening all over the screen with little or no flicker, bB might seem to be too limited for them and not worth the time. But batari Basic is always improving and things like the unfinished version of Space Invaders that batari did can show people that you can still do a lot with bB if you use your imagination. Potential users who think that bB has too many limitations to be of any use need to be reminded that it's still amazing that we can use a BASIC-like language to make Atari 2600 games, especially when some people said it couldn't be done or the language wouldn't be worth using. It might also help if the Atari 2600 BASIC forum was renamed to batari Basic so people can't miss it and won't confuse it with other forums.

 

I think things are going to get better. I bet we'll see more bB users. When the new version of bB is released, it will be on the main page of AtariAge, so that will give it another boost. And we'll keep more current users from leaving if we try to remember to keep our critiques of their games as positive as possible. Instead of "Your game just gave me cancer!" we could say something like "I like the vomiting pterodactyl with bleeding hemorrhoids, but can you try it with less blood in your next version? It's kind of hard for me to see the golden eggs of Norbonium."