15 replies to this topic

[yuppicide]

I'm using 8kSC and the following:

set kernel_options no_blank_lines background

-- I can never seem to get background working. It always gives me an error on compiling and highlights that line as the error.

[Primordial Ooze]

Quote

The order of the options doesn't matter, but there are limitations as to which options can be used alone and/or together:



Acceptable singles:
player1colors
no_blank_lines
pfcolors
pfheights

Invalid singles:
playercolors
readpaddle
background

Acceptable combinations:
pfcolors pfheights
pfcolors pfheights background
pfcolors no_blank_lines
pfcolors no_blank_lines background
player1colors no_blank_lines
player1colors pfcolors
player1colors pfheights
player1colors pfcolors pfheights
player1colors pfcolors background
player1colors pfheights background
player1colors pfcolors pfheights background
player1colors no_blank_lines readpaddle
player1colors no_blank_lines pfcolors
player1colors no_blank_lines pfcolors background
playercolors player1colors pfcolors
playercolors player1colors pfheights
playercolors player1colors pfcolors pfheights
playercolors player1colors pfcolors background
playercolors player1colors pfheights background
playercolors player1colors pfcolors pfheights background
no_blank_lines readpaddle

Yes it should.

[jrok]

yuppicide, on Mon Oct 20, 2008 11:11 AM, said:

-- I can never seem to get background working. It always gives me an error on compiling and highlights that line as the error.

Same here. I'm not really sure what is meant by "Change background color instead of playfield color." How do you define background lines? And since it says "instead of playfield color", how is it possible to that some valid kernel options contain both pfcolors and background?

[yuppicide]

jrok, on Mon Oct 20, 2008 12:56 PM, said:

Same here. I'm not really sure what is meant by "Change background color instead of playfield color." How do you define background lines? And since it says "instead of playfield color", how is it possible to that some valid kernel options contain both pfcolors and background?

Well, you don't define background lines it's just one color. But, you are right.. how is it possible you can do PFCOLORS and BACKGROUND as valid options, but yet it says I can only do one or the other.

Either way I can't get it to compile using background and when I try to change background color it's all screwed up. Blue comes out as a bright sea green color for me if I try to change background color without the kernel background option.

I have a game where you control a little fish, so I needed the water blue, but wanted my playfield a "coral" like color.. purple, green, light brown, something other than black.

Edited by yuppicide, Mon Oct 20, 2008 12:05 PM.

[Random Terrain]

I never understood what the purpose of background is. Maybe I'm confused, but I thought COLUBK did the same thing? Does COLUBK not work with Superchip RAM?

[Robert M]

yuppicide, on Mon Oct 20, 2008 11:11 AM, said:

I'm using 8kSC and the following:

set kernel_options no_blank_lines background

-- I can never seem to get background working. It always gives me an error on compiling and highlights that line as the error.

You must include the pfcolors kernel option with the background kernel option. Then you must use the pfcolors: construct to make a table of 11 colors (assuming you are using the standard 11 high resolution. Like this:

  pfcolors:
  $f5
  $f5
  $f5
  $43
  $f5
  $f5
  $f5
  $f5
  $f5
  $f5
  $f5
end

Normally with the pfcolors kernel option set, the table of pfcolors would be applied to the COLUPF register on each row change. With the additional background option set, however, the kernel writes to the COLUBK register instead of COLUPF.

So with pfcolors you can have a new PF pixel color each row with a solid background. If you throw in the background option, then you get rows of color in the background PF, and the PF pixels are all the same color.

Cheers!

[Robert M]

double post

Edited by Robert M, Tue Oct 21, 2008 6:21 AM.

[Random Terrain]

OK, now I get it. It forces the pfcolors data into the background:

http://www.atariage....s...t&p=1356367

[yuppicide]

On the bB page, when it says "INSIDE GAME LOOP" that means it must be inside the game loop, but for example COLUBK doesn't say anything, so can that be outside the loop OR inside as well?

[Random Terrain]

yuppicide, on Tue Oct 21, 2008 7:57 AM, said:

On the bB page, when it says "INSIDE GAME LOOP" that means it must be inside the game loop, but for example COLUBK doesn't say anything, so can that be outside the loop OR inside as well?

This should answer your question:

http://www.randomter....html#ephvarreg

[SeaGtGruff]

The ability to change both playfield *AND* background colors isn't part of the standard options-- it's something somebody added with a customized include file IIRC. There's a thread about it somewhere.

Michael

[yuppicide]

I figured out why my colors were screwed up.. well I shouldn't say I figured it out, though.

In my one game I'm doing COLUBK = 132 (blue) but it comes out as PAL purple. When I set it to 212, PAL blue, it looks like I wanted.

So somehow even though I specify set tv ntsc it's still doing PAL. Maybe something in my code is taking too long and making the emulator think PAL?

[Random Terrain]

yuppicide, on Tue Oct 21, 2008 11:45 AM, said:

Maybe something in my code is taking too long and making the emulator think PAL?

Using Stella, did you hit the button above Tab (`) for the debugger, stare at Scanline:, then hold down Alt + f to see if Scanline: changes from frame to frame. If it stays at 262, everything is great:

http://www.atariage....s...t&p=1600284

[yuppicide]

Everything looks okay. It's always at 262 unless you die, in that case the program looks for a collision between you and the playfield and does REBOOT. When that happens it shoots up to 800 something.

I am just looking at my code for the skulltitle and when the screen changes yellow and the lightning sound occurs the scanline changes.

EDIT: I originally asked what ALT-F did.. I figured it out. Sweet.

Random Terrain, on Tue Oct 21, 2008 4:26 PM, said:

Using Stella, did you hit the button above Tab (`) for the debugger, stare at Scanline:, then hold down Alt + f to see if Scanline: changes from frame to frame. If it stays at 262, everything is great:

http://www.atariage....s...t&p=1600284

Edited by yuppicide, Wed Oct 22, 2008 12:28 PM.

[Random Terrain]

In case anyone wants to know, I added that info to my version of the bB page under Timing:

http://www.randomter...nds.html#timing

[yuppicide]

Great! How about adding the updated bAtari Basic files to your page as well?

Random Terrain, on Wed Oct 22, 2008 6:42 PM, said:

In case anyone wants to know, I added that info to my version of the bB page under Timing:

http://www.randomter...nds.html#timing