Mid-Scanline Color Changes

[glurk]

I was playing around with a mockup I made of the game by @8bitPoet and trying to clarify for myself on color changes of the background and playfield.  So let's say we have 160 pixels across numbered from 0, so 0-159.

 

The playfield pixels are 4-wide, so the leftmost pixel of each one is:

0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100 104 108 112 116 120 124 128 132 136 140 144 148 152 156

 

Mid-scanline color changes of either COLUBK or COLUPF can only hit every 3rd pixel because of TIA vs CPU timing, so changes can only happen at:

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100 103 106 109 112 115 118 121 124 127 130 133 136 139 142 145 148 151 154 157

 

So, the only places where they line up are those that are (certain?) factors of 4

4 16 28 40 52 64 76 88 100 112 124 136 148

 

Since there is no HMOVE or such for color changes, I believe these 13 places are the only locations where you can CLEANLY change the PF color precisely on a "PF pixel" boundary.

 

Now, do I have this correct?

Edited January 10 by glurk

[Thomas Jentzsch]

Your COLUBK/COLUPF timings are off by 1 pixel. Correct are 2, 5, 8...

[glurk]

But I'm using Stella 6.7, and in the debug windows, those are the X positions where the color changes occur...  I'm confused.

 

(I'm looking at the pixel where the new color starts...)

 

Edited January 10 by glurk

[Thomas Jentzsch]

Sorry, my bad. Your numbers are correct.

[lucienEn]

Not sure what is meant with cleanly but if I do STA COLUPF at pixel pos = 52 then color changes at pixel 61 (3 cpu cycles * 3 color clocks). Which in this case is 1 pixel wide color (last pixel of the 4 pixel PF2 bit). Still very limited since it can only change color every 9 pixels minimum.

 

PS I think it can be on any starting pixel position if you don't use WSYNC.

Edited January 10 by lucienEn

[glurk]

When I said 'cleanly' I meant the places where the color change happens EXACTLY at the edge of a PF "pixel."   And it can only be done for 13 of the 40 PF pixels.

 

Otherwise, you get a PF pixel that is half one color and half another.  Or 1/4 and 3/4.  And it happens because the PF pixels are 4 wide, but color changes are 3 wide.

 

I should probably try to code up a demo or something.  I'm actually learning this as I go, but also hoping it is helpful for others.  And I searched, and did not find a great deal of info on precisely timed / clocked mid-line color changes.  It seems to be used somewhat rarely, but I think it's a cool technique...

 

EDIT TO ADD:  It's true that if you have STA COLUPF, STX COLUPF, STY COLUPF right in a row, it can only change every 9th pixel.  But you can still vary the starting cycle of the first STA COLUPF and set that position with 3-pixel resolution.

 

I wasn't think in terms of a color grid, but more like some mid-line changes to make a more colorful PF "drawing" of "scene."

Edited January 10 by glurk

[+splendidnut]

13 minutes ago, glurk said:

I wasn't think in terms of a color grid, but more like some mid-line changes to make a more colorful PF "drawing" of "scene."

Take a look at the first level of the original Congo Bongo.  There's a variety mid-line color changes spread amongst the drawing kernels.  Maybe there's some potential tricks that you could use.

[glurk]

I'm aware of Congo Bongo, although that game is a bit of a mess.  Another game that uses the technique (very well) is Quick Step! by Imagic.  Even though it makes it's changes against a black background, it's used to great effect.

 

And those are the only ones I can think of...  Surely there are other games that use mid-line PF color changes, but I don't know of them...

[Sohl]

5 hours ago, glurk said:

When I said 'cleanly' I meant the places where the color change happens EXACTLY at the edge of a PF "pixel."   And it can only be done for 13 of the 40 PF pixels.

 

Otherwise, you get a PF pixel that is half one color and half another.  Or 1/4 and 3/4.  And it happens because the PF pixels are 4 wide, but color changes are 3 wide.

If the color change needs to happen cleanly at only one or a few locations, why can't you waste a few cycles with NOPs or 4cycle writes, etc. so that the real STA that you want to do hits when you want? Am I missing something special about your situation? 

Nevermind, I think you are talking about the 3 color clocks per CPU cycle.

Edited January 10 by Sohl

[glurk]

30 minutes ago, Sohl said:

Nevermind, I think you are talking about the 3 color clocks per CPU cycle.

Right.  I try to explain myself clearly, and yet I still get misunderstood, sigh...  I just had never seen it 'explained' that since PF pixels are 4 color clocks wide, and CPU cycles take 3 color clocks, it's impossible to match them in some locations.  Only in intervals of 3. 

 

Had to explore it for myself, because I found very little written up about the topic. 

[lucienEn]

21 hours ago, glurk said:

Right.  I try to explain myself clearly, and yet I still get misunderstood, sigh...  I just had never seen it 'explained' that since PF pixels are 4 color clocks wide, and CPU cycles take 3 color clocks, it's impossible to match them in some locations.  Only in intervals of 3. 

 

Had to explore it for myself, because I found very little written up about the topic. 

Typically easier just to use ball with size = 4. Then you can position it anywhere incl. at the end unless you need the ball as well. But this scanline can't be used anyway for anything else anymore and you really can only do 1 4 pixel aligned block. Another common option is P1 which you can replicate 3x. In winter games you can see trick to put 2 sprites on both outsides of the screen by setting position towards the end (which gets wrapped around).

Edited January 11 by lucienEn

[glurk]

I don't think you understand what I was trying to do.  The 'ball' is absolutely no help, because when I change COLUPF, it instantly changes the color of the 'ball' also.

 

At one time, I thought that it was possible to change COLUBK or COLUPF at any arbitrary pixel position, if the STA was timed correctly.  But it's NOT possible.  Color changes can only happen at every 3rd pixel position, such as 1, 4, 7, 10, 13, etc...  The in-between positions are IMPOSSIBLE.  And the is no HMOVE equivalent for color changes, so they cannot be "nudged" either.

 

I posted this thread to clarify this info for myself, see if I was mistaken about any of it, and possibly help others as well, since I've never seen it explained very well...

 

In this image, I was trying to have the background color change (at the white arrows) from DkBrown to LtGreen and back to DkBrown on each scanline.  The DkGreen is PF.  But it's not possible to make the change line up exactly with the PF "pixel" edges....

Edited January 11 by glurk

[+Dave C]

If you had the cycles to use an asymmetric playfield - you could make the change at points where the transition is clean but you'd need to do something about the whole image being off center  (like put a black missile down one edge)..?


In some work I've been doing I've been playing around with making background color transitions at CPU cycle 28 (16) and cycle 71 (145). I'm using graphics in PF0 to at least partially cover over the transition area.

As things look whole screen.


Here is cycle 71, the overlap is definitely visible (although some color combinations make it less obvious).

[JetSetIlly]

12 hours ago, glurk said:

I don't think you understand what I was trying to do.  The 'ball' is absolutely no help, because when I change COLUPF, it instantly changes the color of the 'ball' also.

Have you looked at scoremode? It's probably of no help but it's worth thinking about.

[lucienEn]

16 hours ago, glurk said:

I don't think you understand what I was trying to do.  The 'ball' is absolutely no help, because when I change COLUPF, it instantly changes the color of the 'ball' also.

 

At one time, I thought that it was possible to change COLUBK or COLUPF at any arbitrary pixel position, if the STA was timed correctly.  But it's NOT possible.  Color changes can only happen at every 3rd pixel position, such as 1, 4, 7, 10, 13, etc...  The in-between positions are IMPOSSIBLE.  And the is no HMOVE equivalent for color changes, so they cannot be "nudged" either.

 

I posted this thread to clarify this info for myself, see if I was mistaken about any of it, and possibly help others as well, since I've never seen it explained very well...

 

In this image, I was trying to have the background color change (at the white arrows) from DkBrown to LtGreen and back to DkBrown on each scanline.  The DkGreen is PF.  But it's not possible to make the change line up exactly with the PF "pixel" edges....

Edit: ball color is shared with playfield but that would help you to mask extra pixels to get to 4 pixel alignment. But I mentioned player sprites / missiles which is very common to use for that scenario. Do you have both in use? What do you need to happen at those scanlines besides playfield color changes? It would help to see the 2nd desired image and which draw actions need to happen in that kernel band. If there is no wave at those scanlines then maybe you can swap background/playfield and use the playfield as borders.

Edited January 12 by lucienEn

[SvOlli]

@glurk: what you can do in this specific example is to have the "leftmost green" as playfield color. That way it will always be drawn at a starting pixel. Then use background color for the "leftover" green. This will get you a chance to put anything in "character boundary".

 

Alternatively, you still can use sprites to "smooth the edges".

 

For planning things like this, I've hacked up a tool called "fridgegrid", which helps to make up your mind (but doesn't generate code). In my example, I'm using it to draw 8 vertical bars, each 32 pixels and each with it's own color, only using COLUPF and COLUBG. Might help, might not.

[lucienEn]

I'm working on a tool to allow you to draw all object types and possibly it might cover the scenario here (but don't know if this is asymmetric PF). See post below. But right now it only supports background and playfield. Should be easy to add ball & missiles when I have time again to continue this. I'm not planning to allow color changes within scanline but that still should cover most scenarios. So far this supports max. 4 register changes in 1 scanline (COLUBK, PF0/PF1/PF2). I think 5 could be the max possible without mid-scanline changes. But with asymmetric playfields it might be less (not supported either yet).

 

 

Edited January 12 by lucienEn