Ball, Missile copy/flicker limit questions.

[BladeJunker]

I do know that both missiles can copy 3 times by default and the Ball has no native copy ability but if you race the beam how far can you push these 3 objects in terms of copies.

 

To add some context to my question I'm just looking into larger full screen and more heavy multicolor use on the 2600 for title screens and or art slides in the same vein of the C64 pixel art scene. The hope is a 2600 Paint type program to give pixel artists something to screw around with so here's a run down on how each object is used and object options.

 

Background: Canvas

 

Playfield: Bulk Fill tool.

 

Player0: Tile bitmap.

 

Missile0: Line tool

 

Player1: Tile bitmap

 

Missile1: Line tool

 

Ball: Line tool

 

 

Object Options=

 

Background: Color set.

 

Playfield: Color Change per scanline, Pixel thickness per scanline(1 Line, 2 Line).

 

Player0/Player1: Tile Repeat, Tile Multiplex(2-3 Max), Color Change per scanline, Pixel thickness per scanline(1 Line, 2 Line).

 

Missile0/Missile1/Ball: Odd to Even scanline stagger, Odd to Even scanline flicker, Width Adjust, Color Change per scanline, Pixel thickness per scanline(1 Line, 2 Line).

 

 

I know that stretching either Player object cancels its corresponding Missile from use but is that effect global or just per scanline, can you stretch one Player object differently per scanline? If not dedicating one Player object to stretch use can be used in conjunction with a multiplexed non stretched Player object.

 

If any of this works I have doubts of it being practical for real-time use on actual hardware but perhaps an external program with a trimmer more compressed format it would export for actual display purposes.

 

Because of the technical limits I'd imagine a trial & error process in use such as composing an image, running it on a 2600 or Stella to see how much flicker occurs, and going back to revise or try it a different way.

 

I'm including an example image of quality standards which is primarily made with 4 times wide pixels to maximize horizontal screen coverage. Its just a mockup since I'm pretty sure only one image could be displayed at a time but I wanted to show some variety.

 

So any insight or collaboration on this venture would be appreciated.

[Thomas Jentzsch]

If you have enough CPU cycles, you can change everything line by line (even mid line). But especially when you want to display a 48-pixel "hires" graphics, you have only 10 to 20 CPU cycles per line left. This allows for changing ~2 to 4 registers (e.g. colors or number/size of player/missile copies). And those changes are only possible outside the 48 pixel display.

 

Everything above that limit requires flicker, where 30Hz is acceptable. 20 or 15Hz are pretty annoying.

[BladeJunker]

If you have enough CPU cycles, you can change everything line by line (even mid line). But especially when you want to display a 48-pixel "hires" graphics, you have only 10 to 20 CPU cycles per line left. This allows for changing ~2 to 4 registers (e.g. colors or number/size of player/missile copies). And those changes are only possible outside the 48 pixel display.

 

Everything above that limit requires flicker, where 30Hz is acceptable. 20 or 15Hz are pretty annoying.

Has anyone tried less than 48 pixel display as my intention is more strategic use of Player bitmaps instead of always using the maximum of 6 Player blocks multiplexed, that is bound to save some cycles for other uses such as color changes etc. I understand that the 48 pixel rendering is demanding on rendering speed so I'm trying to lessen its use to 16,24,32 or even 40 pixels per scanline.

 

30Hz acceptable, is that tolerable or barely visible? ^_^

 

You mention being able to change everything per line with enough cycles, does that include stretching the Player object. Also does the nullified Missile tradeoff from stretching the Player object apply regardless of scanline or can its effect be contained within a set amount of vertical screen resolution?

 

Thank you for your info, its most helpful.

[LS_Dracon]

I did some images years ago I call hyper sprite, check the result here

[BladeJunker]

I did some images years ago I call hyper sprite, check the result here

Yeah I came across your post in my research some months ago, I liked your approach very good and catchy name Hyper Sprite. I've tried reading up on Batari etc. but I'm afraid I only understand maybe of 10-15% of your code example. I have a friend whose programming savy to try out some of my mockups but I just sent him 1 concept for now as he doesn't have much time for my projects these days.

[LS_Dracon]

Tnx.

Your mock-ups are possible, with few adjusts (mario skin color and the red (hat) color in the same scan line is not possible, also the eyes must be brown, it's a good idea to paint the hair as black).

Also using 1 scanline resolution require much rom. My example uses something like 128 bytes on each image, (8 scanline resolution) so you can store 9 images in 1 kb.

 

Atari 2600 hardware is really limited to the graphics, sadly.

[BladeJunker]

Tnx.

Your mock-ups are possible, with few adjusts (mario skin color and the red (hat) color in the same scan line is not possible, also the eyes must be brown, it's a good idea to paint the hair as black).

Also using 1 scanline resolution require much rom. My example uses something like 128 bytes on each image, (8 scanline resolution) so you can store 9 images in 1 kb.

 

Atari 2600 hardware is really limited to the graphics, sadly.

I see what you mean about the colors, I kind of figured painting to my whims would exceed color capacity in certain image zones. So if I change the hair color to black could I keep the eyes black? Also are we talking absolutely not or could I keep brown if I'm willing to endure some flicker?

 

On the issue of ROM size I'm not that concerned about it, I respect the amount of rendering capacity afforded by the 2600 pipeline(4K Max) since it can't be enhanced without adding additional hardware into the cartridge like Pitfall2 did. Given modern chip capacities I think we can afford to grow as large as we need in overall program footprint size compared to the original 2600 titles, after all David Crane has said on the record that he kept begging for larger ROMs back in the day(not that he got any) and 7800 developers had the same problem. Might as well relieve one limitation if we can.

 

Believe me the lack of graphics power from the 2600 goes with saying but it is the most popular unit globally compared to the 5200, 7800, or Jaguar which have a lot more power. I would say games should be the primary focus of 2600 programs but art and music should be a close second.

 

I see your from Brazil, how is the weather down there?

[LS_Dracon]

The flicker don't looks good in large images (playfield and 4x sized players) in a "not black" background, I already did tests, trust me.

Yes, I mean the hair black for the eyes be black too. Actually you can change the background color in that area to paint the eyes as black, but it's require a special timming wich is very difficult to do.

The problem you need to change the playfield pixels at exactly 48 cicles (half of the screen) you can't miss this time, another thing that makes it difficult.

...

I think you can change the playfield color, as there aren't others playfield pixels after the eye. I'll try to convert this image for you.

BTW there are others ways to display a multi colored image, using Andrew Davie Chrono Color technique, wich flicker but looks good because the black background.

 

Teorically, with Melody Board both ROM and RAM is no more a problem, but it's not a goo way to start to code, I think learn to code for the 2600 with all limitations makes the wole thing fun.

Is possible to extract art from 2600, don't give up

 

I see your from Brazil, how is the weather down there?

 

The spring is ending, the summer aproaches. Yep, Xmas in the hell hehehe. Actually I live in south of Brazil wich is cold, but no snow in dezember. You don't miss what you don't know

[LS_Dracon]

Dude, here's all I did, in last 2 hours (yes, really).

It's terrible to keep everthing working, lot of problems, page crossing, timming etc...

I haven't find cicles enought to finish the right - down part (the pixels must to be pushed to the left).

mariohyper.bin

[Thomas Jentzsch]

I haven't find cicles enought to finish the right - down part (the pixels must to be pushed to the left).

You could remove the WSYNC and gain enough cycles for sta HMP1.

[BladeJunker]

Dude, here's all I did, in last 2 hours (yes, really).

It's terrible to keep everthing working, lot of problems, page crossing, timming etc...

I haven't find cicles enought to finish the right - down part (the pixels must to be pushed to the left).

First thing thanks for converting it, nice of you to spend the time.

 

I have seen Andrew Davie's Chrono Color technique, I think it is good for photographs but not optimal enough for stylized art or full screen imagery.

 

I agree about keeping things as trim as possible but those very first 2600 carts were too small and tied the hands of the programmers back then.

 

I've included 2 variations on the Mario, the first is Hyper Sprite based with a height adjustment for the Playfield wide pixels and the second is closer to my concept of Playfield color fill and 4 pixel wide edging pixels and tile blocks.

 

Thanks again for your efforts.

Edited November 12, 2011 by BladeJunker

[LS_Dracon]

You could remove the WSYNC and gain enough cycles for sta HMP1.

 

Tried but I need to make the loop with exactly 76 cicles or it mess with HMOVE.

Also there's the problem to set HMxx values 24 cicles before HMOVE, here'sthe scanline loop :

 

;------------------------------------------
Scanloop
sta WSYNC
sta HMOVE
lda MarioPF2,x
sta PF2
;-----
lda MarioPlayer1,x
sta GRP0
lda MarioColor1,x
sta COLUP0
lda MarioPlayer2,x
sta GRP1
lda MarioColor2,x
sta COLUP1
ldy #0
lda MarioPF3,X
sta PF2
sty PF1
lda MovePlayer1,x
sta HMP0
lda MovePlayer2,x
; sta HMP1
lda MarioPF1,x
sta PF1
;------
FinishLoop
dex
bne Scanloop

 

I'm not good with optimizations

 

The PF1 is load after PF3, to be displayed in next line, added 1 extra line in the graphic table to fix it.

 

I've included 2 variations on the Mario, the first is Hyper Sprite based with a height adjustment for the Playfield wide pixels and the second is closer to my concept of Playfield color fill and 4 pixel wide edging pixels and tile blocks.

 

You can use only 1 color per line, combinations like skin-red and red-blue or blue-brown aren't possible. Only if you set both players at same place, like layers, reducing the color area to 8 pixels wide.

Edited November 13, 2011 by LS_Dracon

[BladeJunker]

You can use only 1 color per line, combinations like skin-red and red-blue or blue-brown aren't possible. Only if you set both players at same place, like layers, reducing the color area to 8 pixels wide.

 

 

Okay I'm not understanding yet. By default don't we have 3 colors possible per scanline not including the Background, as in the Playfield+Ball, Player0+Missile0, and Player1+Missile1 which can be set independently per scanline. Also are we talking about stretched Player objects since I was planning on using the default 8 pixels of width but drawn to an appear like 4 pixel wide bitmaps so they match the Missile and Ball bits which are set to 4 pixels of screen width? So is this about cycle costs or are we both talking about different objects?

[Thomas Jentzsch]

Tried but I need to make the loop with exactly 76 cicles or it mess with HMOVE.

True, but as soon as you start cycle counting, this will be very easy, since there are no special branches in your code. Just make sure that your tables and kernel code don't cross a page.

 

Also there's the problem to set HMxx values 24 cicles before HMOVE,...

HMxx has to be (at least) 24 cycles after HMOVE, not vice versa.

 

...here'sthe scanline loop :

 

...
lda MovePlayer1,x
sta HMP0
lda MovePlayer2,x
; sta HMP1
...

Do you really need two different vales for HMP0 and HMP1? If you can get away with just one value, your code would run withing 76 cycles.

 

I'm not good with optimizations

Just a matter of practice.

[LS_Dracon]

Tnx for the tips Thomas, it's working great.

I'm using align 256, the kernal ended with exactly @76

 

The wrong pixels is not problem in the code, my source image require better work.

 

Just a matter of practice.

 

 

Edited November 13, 2011 by LS_Dracon

[BladeJunker]

Just thought I'd add a different style image without outlines sort of a South Park look that might work also under this rendering setup. I broke it down into width segments just to give options as I'm not sure which object renders what.

[BladeJunker]

Thought I'd throw another style that will likely work with this type of rendering. This one is ANSI based, I included a few pattern swatches at 3 resolutions at the bottom but went with Playfield based blocks for the main image simply based on a trim image format. It should be said this is not my piece, I just found it with Google Images. ^_^

Edited January 26, 2012 by BladeJunker

[BladeJunker]

Thought I'd try breaking down a large circle into a visual description of its raw construction using Playfield plus Missile 0, Missile1, and the Ball. Looking for critiques on cycle costs and or possibilities for kernel optimization for primitive shapes like circles. More than willing to drop resolution if that will help make the overall setup cheaper in cycles.

 

The foundation or bulk is a Playfield render using a 3-line kernel at 61 lines top to bottom.

 

The edge bits pretty much switch between 1-line and 2-line kernels per scan line. There are 3 width options but only 2 possible widths per scan line per 2 objects with whatever bit that will line up correctly given the horizontal position needed.

 

 

I've highlighted the bits for visibility sake but all objects would be set to yellow in an actual render. I'm still trying to grasp cycle cost overall but I thought it couldn't hurt to ask if this example would work and how costly would it be in ROM space and CPU time.

[SeaGtGruff]

Thought I'd try breaking down a large circle into a visual description of its raw construction using Playfield plus Missile 0, Missile1, and the Ball.

The simplest way to do that is to use the ball and a missile, set their widths to 4 color clocks, set their positions at the top of the circle, and then use horizontal motion to shift them left or right as you go down the screen. Since their widths will always be the same, all you need to do during the circle-drawing portion of the kernel is load their horizontal motions from a table, write the values to the motion registers, and strobe HMOVE-- plus loading and writing the playfield, of course. Assuming the circle is in the center of the screen, you can use a mirrored playfield, and you should not have to load and store PF0-- just PF1 and PF2.

Edited February 24, 2012 by SeaGtGruff

[BladeJunker]

The simplest way to do that is to use the ball and a missile, set their widths to 4 color clocks, set their positions at the top of the circle, and then use horizontal motion to shift them left or right as you go down the screen. Since their widths will always be the same, all you need to do during the circle-drawing portion of the kernel is load their horizontal motions from a table, write the values to the motion registers, and strobe HMOVE-- plus loading and writing the playfield, of course. Assuming the circle is in the center of the screen, you can use a mirrored playfield, and you should not have to load and store PF0-- just PF1 and PF2.

 

So if I use only one bit width that would work better overall to the efficiency of the kernel. Ah a table that was the term I was looking for sections of predefined data.

 

I lowered the resolution based on 4 CCs but I think all 3 bits are needed for the bottom and peak of the circle if Playfield and Bits differ in line thickness.

Most of the exceptions to a circle kernel are found at the north and south end of the circle are related to the needs of a "perfect circle" primarily line kernel thickness versus the mostly vertical aspect ratio stretch. I test things for 4:3 in paint programs then measure and eyeball it to get equally wide and tall shapes but I did do the math once and it wasn't exactly a pixel divisible value lol, so I had to approximate.

In an actual game I'd most likely oval the circle for a faster cheaper overall circle kernel but under this context I'm interested in differing kernels per vertical zone when needed to get an exact final result. I think also in practice under the original context of this posting being a paint program a circle tool would definitely bend towards efficiency for multiple circles instead of exacting dimensional sizes.

 

Yes in this example the circle is centered, mostly sticking to symmetry to gauge kernel costs for shapes in general. And yes PL0 is not used in this example.

 

Okay here's something I forgot to ask, can you set different objects to different line kernel thicknesses or is it a global setting for all objects when rendering occurs?

 

Also in your opinion do you think 4 CCs would be the best standard width for bits being used for Playfield smoothing on the 2600, by that I mean would my original circle of maximum crispness or resolution be more appropriate on the 5200 or 7800?

 

Thanks for your response, you're my savior,

 

Logan:)

[SeaGtGruff]

So if I use only one bit width that would work better overall to the efficiency of the kernel.

A playfield pixel is 4 color clocks wide, so if you draw the bulk of the circle with the playfield, the only reason to use the ball and a missile is to be able to shift the left and right edges of the circle by *less* than 4 color clocks-- 1, 2, or 3 color clocks. If you let the ball and missile overlap the playfield pixels, you can leave them set to a width of 4 color clocks-- so you don't need to worry about changing their widths while drawing the circle-- and then shift them left or right as needed to get the finer horizontal resolution for the edges. On some lines the ball and missile will completely overlap a playfield pixel. On other lines they'll overlap the playfield for 3 color clocks but will jut out beyond the playfield for 1 color clock. On other lines they'll overlap for 2 color clocks and jut out for 2 color clocks. On other lines they'll overlap for 1 color clock and jut out for 3 color clocks. Then when you reach the point where the ball and missile would jut out for 4 color clocks, you just extend the playfield another pixel so they're back to overlapping for all 4 color clocks. I'm assuming the topmost and bottommost lines of the circle will be at least 4 color clocks wide.

 

I lowered the resolution based on 4 CCs but I think all 3 bits are needed for the bottom and peak of the circle if Playfield and Bits differ in line thickness.

The kernel would be easier to draw if the playfield's vertical resolution is the same as the ball's and missile's.

 

Most of the exceptions to a circle kernel are found at the north and south end of the circle are related to the needs of a "perfect circle" primarily line kernel thickness versus the mostly vertical aspect ratio stretch. I test things for 4:3 in paint programs then measure and eyeball it to get equally wide and tall shapes but I did do the math once and it wasn't exactly a pixel divisible value lol, so I had to approximate.

The aspect ratio of a color clock (often referred to as a "pixel") on the 2600 is roughly 5:3. Assuming that Paint's pixels are square or have an aspect ratio of 1:1 (which really depends on the screen resolution of the desktop), then if you draw an oval with an aspect ratio of 3:5 in Paint-- say, 300 pixels wide and 500 pixels tall-- you can convert the drawing to pixel data. When you draw that same oval on the 2600, it should come out very close to a circle due to the pixels being wider than in Paint. Of course, the 2600's drawing area is usually only 192 scan lines or so. Just multiply the desired height in scan lines by 3 and divide by 5 to get the width:

 

192 lines tall x 3 = 576, 576 / 5 = 115.2 color clocks wide

191 lines tall x 3 = 573, 573 / 5 = 114.6 color clocks wide

190 lines tall x 3 = 570, 570 / 5 = 114.0 color clocks wide *

etc.

 

The best choices would be where the height is a perfect multiple of 5 lines, so the ideal width is a whole number of color clocks:

 

190 lines x 3 = 570, 570 / 5 = 114 color clocks

185 lines x 3 = 555, 555 / 5 = 111 color clocks

180 lines x 3 = 540, 540 / 5 = 108 color clocks

etc.

 

Okay here's something I forgot to ask, can you set different objects to different line kernel thicknesses or is it a global setting for all objects when rendering occurs?

If I understand your question correctly, there is nothing in the hardware that says the lines must all be the same thickness (vertical resolution). This really depends on how you construct your kernel as required for your game. Let's suppose you're using a 1-line kernel, to get a maximum vertical resolution of 192 lines. You don't need to store the data for each line, but again it depends on how you want to construct your kernel.

 

Also in your opinion do you think 4 CCs would be the best standard width for bits being used for Playfield smoothing on the 2600, by that I mean would my original circle of maximum crispness or resolution be more appropriate on the 5200 or 7800?

A width of 4 color clocks would be standard if you're letting the ball or missile overlap the playfield, since that will let you get the interim positions. That is, the playfield pixels are 4 color clocks wide, so you can get positions every 4 color clocks using just the playfield, and the ball and missile would let you get the interim positions, as described above by how many color clocks are overlapping with a playfield pixel.

[BladeJunker]

So if I use only one bit width that would work better overall to the efficiency of the kernel.

 

Okay poor choice of phrasing. I should have asked is one width for all Bit Objects used an efficient choice when making a kernel which it is according to what you've described.

 

A playfield pixel is 4 color clocks wide, so if you draw the bulk of the circle with the playfield, the only reason to use the ball and a missile is to be able to shift the left and right edges of the circle by *less* than 4 color clocks-- 1, 2, or 3 color clocks. If you let the ball and missile overlap the playfield pixels, you can leave them set to a width of 4 color clocks-- so you don't need to worry about changing their widths while drawing the circle-- and then shift them left or right as needed to get the finer horizontal resolution for the edges. On some lines the ball and missile will completely overlap a playfield pixel. On other lines they'll overlap the playfield for 3 color clocks but will jut out beyond the playfield for 1 color clock. On other lines they'll overlap for 2 color clocks and jut out for 2 color clocks. On other lines they'll overlap for 1 color clock and jut out for 3 color clocks. Then when you reach the point where the ball and missile would jut out for 4 color clocks, you just extend the playfield another pixel so they're back to overlapping for all 4 color clocks. I'm assuming the topmost and bottommost lines of the circle will be at least 4 color clocks wide.

 

Sorry, sorry, sorry I messed up, I meant 2 color clocks. You are absolutely right that there would be little point in making the Bit Objects the exact width of a Playfield pixel. Right here is proof how confused us doodlers get, this is why an abridged translation description is needed for pixel art forums.

 

Still what you describe about jutting pixels out sounds most useful and more efficient to producing maximum image crispness than using multiple width options. 3 color clocks, I keep forgetting that is an option, powers of 2 are ingrained in my brain.

 

The top and bottom of the circle are 4 color clocks wide if we're just talking about half the circle before mirroring occurs?

 

The kernel would be easier to draw if the playfield's vertical resolution is the same as the ball's and missile's.

 

Darn I thought you might say that. No big loss, I'll just have to rethink this matter.

 

The aspect ratio of a color clock (often referred to as a "pixel") on the 2600 is roughly 5:3. Assuming that Paint's pixels are square or have an aspect ratio of 1:1 (which really depends on the screen resolution of the desktop), then if you draw an oval with an aspect ratio of 3:5 in Paint-- say, 300 pixels wide and 500 pixels tall-- you can convert the drawing to pixel data. When you draw that same oval on the 2600, it should come out very close to a circle due to the pixels being wider than in Paint. Of course, the 2600's drawing area is usually only 192 scan lines or so. Just multiply the desired height in scan lines by 3 and divide by 5 to get the width:

 

192 lines tall x 3 = 576, 576 / 5 = 115.2 color clocks wide

191 lines tall x 3 = 573, 573 / 5 = 114.6 color clocks wide

190 lines tall x 3 = 570, 570 / 5 = 114.0 color clocks wide *

etc.

 

The best choices would be where the height is a perfect multiple of 5 lines, so the ideal width is a whole number of color clocks:

 

190 lines x 3 = 570, 570 / 5 = 114 color clocks

185 lines x 3 = 555, 555 / 5 = 111 color clocks

180 lines x 3 = 540, 540 / 5 = 108 color clocks

etc.

 

Boy my math sucks lol, must be my painterly ways. I tend to just draw to draw pixels double wide as its hard to visualize at its native 50% width. I see now my choice to favor the width of the circle was wrong on account of the way an efficient kernel works per scan line, better to pad the width to achieve a "perfect circle".

Still I saved off you formula and I'm going to go try it out.

 

If I understand your question correctly, there is nothing in the hardware that says the lines must all be the same thickness (vertical resolution). This really depends on how you construct your kernel as required for your game. Let's suppose you're using a 1-line kernel, to get a maximum vertical resolution of 192 lines. You don't need to store the data for each line, but again it depends on how you want to construct your kernel.

 

Well you actually answered most of my question higher up in this post, you can differ the line thickness per object but it makes the kernel less efficient overall. Good to see more options nonetheless.

 

A width of 4 color clocks would be standard if you're letting the ball or missile overlap the playfield, since that will let you get the interim positions. That is, the playfield pixels are 4 color clocks wide, so you can get positions every 4 color clocks using just the playfield, and the ball and missile would let you get the interim positions, as described above by how many color clocks are overlapping with a playfield pixel.

 

Again sorry as I meant 2 color clocks. However the 4 color clock option of jutting pixels has caused me to rethink things quite a bit.

[SeaGtGruff]

Sorry, sorry, sorry I messed up, I meant 2 color clocks. You are absolutely right that there would be little point in making the Bit Objects the exact width of a Playfield pixel.

I don't understand the last sentence. I'm saying that if you want to use the ball and a missile to increase the horizontal resolution of a circle, then setting their widths to the same width as a playfield pixel-- 4 color clocks-- and leaving them at that width, will allow you to get all three of the interim positions based on how much of the the ball or missile overlaps a playfield pixel and how much it extends beyond the playfield pixel.

 

3 color clocks, I keep forgetting that is an option, powers of 2 are ingrained in my brain.

No, you can't set the ball and missiles to a width of 3 color clocks, only to powers of 2-- 1, 2, 4, or 8 color clocks.

 

The top and bottom of the circle are 4 color clocks wide if we're just talking about half the circle before mirroring occurs?

I'm talking about the whole circle, not just the left half or right half. If the top line of the circle is at least 4 color clocks wide, then you can set the ball and missile widths to 4 color clocks for that line. If the top line is less than 3 color clocks wide, then you won't be able to set their widths to 4 color clocks on that line. But for a circle as large as you've drawn in your example, I imagine that the top line is well over 4 color clocks wide.

[BladeJunker]

Sorry, sorry, sorry I messed up, I meant 2 color clocks. You are absolutely right that there would be little point in making the Bit Objects the exact width of a Playfield pixel.

 

I don't understand the last sentence. I'm saying that if you want to use the ball and a missile to increase the horizontal resolution of a circle, then setting their widths to the same width as a playfield pixel-- 4 color clocks-- and leaving them at that width, will allow you to get all three of the interim positions based on how much of the the ball or missile overlaps a playfield pixel and how much it extends beyond the playfield pixel.

 

This was just a correction of my past statement on the visual measurement without jutting considered so best to ignore this in favor of me agreeing with your setup of 4 color clocks and achieving the interim position much more cheaply in cycles than my original poorer setup.

 

No, you can't set the ball and missiles to a width of 3 color clocks, only to powers of 2-- 1, 2, 4, or 8 color clocks.

 

Got yah, 3 color clocks was mentioned as a unit of measurement not as a width setting for any object.

 

I'm talking about the whole circle, not just the left half or right half. If the top line of the circle is at least 4 color clocks wide, then you can set the ball and missile widths to 4 color clocks for that line. If the top line is less than 3 color clocks wide, then you won't be able to set their widths to 4 color clocks on that line. But for a circle as large as you've drawn in your example, I imagine that the top line is well over 4 color clocks wide.

 

Both circle picture examples use a top line width of 12 color clocks, 8 of those color clocks are filled by the 2 Playfield pixels with one on the left and right of the Playfields center, the remaining 4 color clocks are filled with the Missile and Ball set to 4 color clocks of width which jut out past the Playfield 2 color clocks of distance on the left and right side of the Playfield pixels.

 

Thank you for your patience on this, my friend is a programmer and we spent many a conversation based on misunderstanding each other. Despite my best efforts at proofreading my responses I'm going to misquote terms and it will be most confusing at times but I'll do my best to correct this over time.

[BladeJunker]

Can't get it out of my head so might as well post an inquiry into mid-line color changes in the Playfield.

 

-Can you use it in combination with color changes per scan line, if so is this a common technique in games or is what I'm seeing achieved in some other way(2 colors per line where the other color isn't the Background color showing through. EG. Checkerboard pattern.)?

-In the game Party Mix the buildings look like mid-line color changes combined with a per scan line gradient using skipped scan lines at odd and even alignment, is that an effective means of optimization for this technique?

-How expensive are mid-line color changes to rendering as a whole?

-What would be a reasonable limit for mid-line color changes, 2,3,4, etc?

-Does it matter where you put a mid-line color change within each Playfield column?

 

Was mostly thinking it might be a good function to exploit in an Atari based paint program.