Using the STANDARD kernel, NO SUPERCHIP, what is the highest PF resolution possible?

[freshbrood]

Also I'm cornfused; It seems that "Graphic memory" is fixed at a maximum regardless of rom size, and only "Action memory" (i.e. ways to manipulate graphics and color tables) increases with rom size, but not the amount of color or graphic assets themselves. Am I understanding this correctly?

 

Does using more data to make snazzier, finer backgrounds with more colors eat in to the available amount of data I can use for sprite colors and graphics?

[+Andrew Davie]

The horizontal resolution of playfield is 40 pixels. Immutable; no more, no less.

The vertical resolution; you can change the playfield registers every scanline if you wish, so the limit is the # visible lines you have on your screen.

Usually around 192 actually visible lines for NTSC.

 

There is no "graphic memory".  There are just a few graphics registers.  The playfield uses 3;  PF0, PF1, PF2 (with only half of the bits in PF0 used), giving 20 bits total. These 20 are displayed on the left half of a scanline, and repeated or mirrored on the right half of the scanline. PF pixels are 4 colour clocks wide.

Then there are registers for the players (0,1) each 8 pixels wide. Each pixel here is 1 colour clock wide, but can be stretched to double/quad width.

Then missiles (0,1) just one bit (i.e, one pixel) wide. Also one colour clock, so same resolution (160 pixels/line) as the players.  Also stretchable.

Finally, the ball. Again, one bit wide, one colour clock. Also stretchable to a maximum of 8 pixels wide.

More ROM gives you space for more "assets" as you put it. These would be data for players, playfield, etc. ROM is immutable; you cannot change the content.  Depending on your bankswitching scheme, you may or may not get extra RAM, which allows you to do some dynamic stuff.

Your last question doesn't really make a lot of sense; other than you have a set amount of ROM. If you use more of it for finer backgrounds then yes, of course you have less of it for sprite graphics, colour tables, etc.  Everything in the '2600 is a balancing/juggling act.

 

[+Andrew Davie]

I'll qualify my answer above, as I didn't realise I was answering a question specifically directed at a bBasic kernel;

I don't know the vertical limitations of the kernel you have asked about, sorry. The horizontal limit still applies.

 

[bogax]

The standard kernel keeps the playfield data in RAM and there isn't much of that.

Each row in the playfield need 4 bytes of RAM

You can jimmy the standard kernel to display more rows but you'll give up 4 variables for each extra row

I don't know what the actual limit would be but if nothing else you'd be limited by the amount of RAM you could make available for the playfield

Edited March 12, 2021 by bogax

[+Karl G]

11 hours ago, freshbrood said:

Does using more data to make snazzier, finer backgrounds with more colors eat in to the available amount of data I can use for sprite colors and graphics?

Bogax has already answered about the reason for the 11 row resolution, since the standard kernel keeps the playfield pixels in RAM. If you could add rows, then yes, these would take up more data space in your graphics bank, both for the playfield data and the color data for the playfield (if any). Additionally, if you did go with SuperChip, this would reduce the amount of space available in each bank by 256 bytes, including the graphics bank.

 

If this is for the game you have been working on, I'd say you've done really well with the 11-row backgrounds, and should just stick with that.  ? 

[+Gemintronic]

The compromise is to use the pfheights kernel option to shrink and grow playfield row heights.  So, you can use smaller rows for text and larger rows for areas that don't need detail like buildings or the sky.

 

[freshbrood]

Thanks for the very great explanations as always! 

 

11 rows it is. A full set of gruesome fatalies is more important!