Calling all Harmony Cart users, for science!

[Thomas Jentzsch]

Please stop quoting me wrong. Or at least try to understand what I write. I 100% agree with RevEng!

 

And just in case: StarBlitz uses method A.

[Mr SQL]

Please stop quoting me wrong. Or at least try to understand what I write. I 100% agree with RevEng!

 

And just in case: StarBlitz uses method A.

Tom,

your examples were excellent but I disagree with this observation as RevEng correctly observed:

A signal updated at 30Hz (method C, simply doubled frames) also uses 50% bandwidth and flickers even less than the interlaced signal. So that's the way to go for minimizing flicker.

 

You're using 100% of the available bandwidth to update the entire screen every 60 hz period. You're just wasting half of it by doubling the frames, there's a difference:

 

In contrast, splitting the screen update across two 60 hz periods for interlace genuinely halves the bandwidth required for the update (only enough for half the image) and thus makes the signal have far more flicker than the Atari's progressive scan output illustrates ©. Just as you observed.

 

And StarBlitz uses A & C; Spice and I were working on roll theory. It also has to do with the red shift you observed in Joe's video if you want to discuss; it's pretty cool

 

RevEng,

it wasn't software rendering mode in the vid of StarBlitz breaking Stella on Windows, it was Direct3D. Software rendering mode was only important in 3.x because it was the default.

[Thomas Jentzsch]

I am ignoring discussing that bandwidth issue, since it doesn't matter here.

 

And StarBlitz uses A & C

Where does it use C? The screen is completely blank ever other frame.

 

That clearly is A and causes unnecessary flicker.

[Mr SQL]

I am ignoring discussing that bandwidth issue, since it doesn't matter here.

 

Where does it use C? The screen is completely blank ever other frame.

 

That clearly is A and causes unnecessary flicker.

 

Yes it does A&C the last time I checked

 

That actually has to do with the retrograde experiments Spiceware and I conducted and the red shift you observed in the spectral video Joe posted.

 

Spiceware has the video footage chronicling our interesting laboratory analysis. The red shift is real, but there could be different explanations for the observed phenomena. I can tell you a little bit about it but you really have to see the video:

 

In our retrograde study ROM's were exchanged and Arcane rituals performed. Incantations, gestures and a unique antique talisman was used to study the nature of the red shift. Phosphor was heavy in the air and the atmosphere was quiet with the steady focus of men of science on the brink of discovery.

[RevEng]

Getting back on track, I want to say thanks to everybody that took time to run the ROM and report the results back!

 

As was revealed earlier in the thread, the left rectangle was solid 60Hz, and the right one was flickered every other frame. (i.e. 30Hz.) Looking at the poll numbers generated...

• 10 people ran through the test on either CRT and LCD. One of the participants tested both.
• There were 9 reports of having negative feeling towards detected flicker.
• There were 2 reports of having detected both the 60Hz flicker and the 30Hz flicker.
• There were 10 reports of having detected 30Hz flicker or 60Hz+30Hz flicker
• There was 1 report of LCD not flickering at all. 2 people outside of the poll reported that their LCD display provided a non-flickering image.

From the results I think it's pretty clear that as developers, we should be wary of playfield flicker - avoiding large flickering areas when possible, and taking steps to minimize it when it's not. A quick recap of "how" for devs who aren't familiar with the historic approaches:

• reduce the luminance difference between the flickered object and it's background.
• interlace the flickered object using the flickerblinds technique. i.e. display the object on even lines on one frame, and odd lines the next.

There's probably more state-of-the-art to be discovered here. I suspect that many LCD TVs can be forced to draw 30Hz flickering as non-flickering lines by sending them a 480i-like signal from the 2600 - We already saw some doing this without a 480i signal, in this thread. It's also been suggested that blue cone cells have a much lower flicker fusion threshold than their green or red counterparts, so pure-blue is probably a good color for a flickering element - worth some experiments of your own anyway, if you're going to be dabbling in flicker.

 

I'm sure people will have more ideas, or will point out things I may have missed. Feel free to carry on with the flicker-tech discussion.

[Andromeda Stardust]

Getting back on track, I want to say thanks to everybody that took time to run the ROM and report the results back!

 

As was revealed earlier in the thread, the left rectangle was solid 60Hz, and the right one was flickered every other frame. (i.e. 30Hz.) Looking at the poll numbers generated...

• 10 people ran through the test on either CRT and LCD. One of the participants tested both.

I ran the test on both. A Symphoic 19" CRT and a 2006 26" Sanyo LCD. Both 4-switch Atari with RF out channel 2.

[Omegamatrix]

I haven't tried the 2nd demo yet, Thomas. Might have to wait until this weekend.

 

 

I'm going to post my old flicker utility, because it seems relevant. Use the joystick to select a color. The color you are on becomes the background color, which every other color flickers against.

 

 

It quickly helps you gauge two color combinations, and demonstrates that flickering of similar luminosity works well.

 

 

 

FlickerTest_rev2.zip

[Thomas Jentzsch]

Yes it does A&C the last time I checked

You cannot do both. You can either flicker (A) or not ( C).

 

So where does it do C? C would mean absolutely no flicker. Please explain.

Edited February 16, 2016 by Thomas Jentzsch

[RevEng]

You cannot do both. You can either flicker (A) or not ( C).

 

So where does it do C? C would mean absolutely no flicker. Please explain.

He's trolling, though I'm sure he will say he's joking. A and C are mutually exclusive, of course. Outside of word games, an object doesnt simultaneously flicker and not flicker.

 

Put him on ignore, as I have. First time I've had to do that since I've been on AA.

[Mr SQL]

You cannot do both. You can either flicker (A) or not ( C).

 

So where does it do C? C would mean absolutely no flicker. Please explain.

 

Tom, everything is at 30 hz during play most of the time but when the game ends and you find yourself playing on a blue background (A&C).

 

On CRT black cannot oscillate so there is no 60 hz flicker on top of the 30 hz flicker. Keatah made an excellent observation about the effects of seeing multiple flicker rates; I favor A over the combination A&C because when most of the screen is black, most of the screen has no flicker at all.

 

I can't post the video Spice made to test the red shift (his lab) and would suggest that he doesn't post it either to avoid getting anyone upset; pm me and Spice if you want to discuss. Thicker bands covering more bandwidth is also open to discussion.

 

RevEng, I'm only interested in discussing programming theory; ignore is fine but if you then can't stop calling names and throwing insults, it's allegory of the den. Tune into a higher frequency and just ignore me, or tune into a higher frequency still and join us in the cerebral stratosphere; then you can discuss the ideas that challenge your beliefs like Tom is doing.

 

Sometimes engineers just understand things differently and technology is so vast we're able to do amazing things with just a partial understanding - it's been that way since the Maxwell Heaviside experiments. We all have gaps in our knowedge base.

[Thomas Jentzsch]

Tom, everything is at 30 hz during play most of the time but when the game ends and you find yourself playing on a blue background (A&C).

I never risked playing to an end, because the hefty flicker before hurts too much. I saw a blue background, but it still flickers using method A. And what happens at the end is irrelevant anyway.

 

On CRT black cannot oscillate so there is no 60 hz flicker on top of the 30 hz flicker.

These words make no sense. Black cannot oscillate at all.

 

I favor A over the combination A&C because when most of the screen is black, most of the screen has no flicker at all.

That again makes no sense. There never is a combination of A&C. The whole game does A, if at the end the flicker may go away (C ) does not matter if you get a headache long before.

 

Also, everything that really counts in your game is not black. The eye focuses and the human brain concentrates on that. And that flickers like mad. Terrible!

 

I still don't get what you are trying to achieve with that flicker. To me you come over, like you cannot program any better and need the CPU time of those black frames. And then you come up with crazy stupid arguments and theories, which have all been torn apart multiple times. Yet, you still repeat that nonsense and thus making a clown out of you.

 

Normally people on AtariAge are a friendly and supportive bunch. But now you achieved that you are that close to be put on my ignore list too!

 

Last chance...

Edited February 16, 2016 by Thomas Jentzsch

[Thomas Jentzsch]

Put him on ignore, as I have. First time I've had to do that since I've been on AA.

Done.

[+SpiceWare]

Done.

 

Same here. Apparently composite mods (S-Video actually) make flicker worse due to artifact colors

 

My time's better spent finishing the demo for cd-w's 128 pixel kernel

[RevEng]

[...]It quickly helps you gauge two color combinations, and demonstrates that flickering of similar luminosity works well.[...]

I'm clearly stepping into this with a bias, but looking at your utility it really does seem that pure-blue flickers less perceptibly than other colors with more green or red in them.

[Omegamatrix]

I'm clearly stepping into this with a bias, but looking at your utility it really does seem that pure-blue flickers less perceptibly than other colors with more green or red in them.

It does to my eyes too.

 

The middle row $8x (blue) seems to flicker the least all of the time. Whatever column you are on also flickers less than other columns because the colors are all at the same luminosity.

[Andromeda Stardust]

I recall people discussing A, B, and C flickering. just for clarity's sake, what do A, B, and C represent?

 

So far in the demos that have been presented, we have no flicker (60Hz solid object) one frame on, one frame off flicker (simulated 30Hz), and finally, odd scanlines in odd frames, even scanlines in even frames (simulated "240i" interlace).

 

Or am I missing something? To me, when viewing on CRT display, the interlacing "240i" is less objectionable than the 30Hz flicker. But this method increases the the size of "venetian blind" artifacts on LCD panels.

 

I have not yet tried the "480i" 262/263 demo. Will load that on my harmony shortly.

[Andromeda Stardust]

 

There's probably more state-of-the-art to be discovered here. I suspect that many LCD TVs can be forced to draw 30Hz flickering as non-flickering lines by sending them a 480i-like signal from the 2600 -

 

I'm sure people will have more ideas, or will point out things I may have missed. Feel free to carry on with the flicker-tech discussion.

 

Hey, FYI, I downloaded the 480i demo linked on this page. I'm not necrobumping a 14-year old forum discussion topic from 2002 to bring this up, but the ROM does not work on my Harmony at all. I just get a blanked display with a thin blue line on the far left. Perhaps it was never tested on real hardware? I don't imagine people in 2002 had that option of just loading it on hardware without first burning an EPROM.

 

As for the recently discussed 480i interlacing flicker test ROM posted in this post, it loads fine on my CRT. Untested on my LCD but I assume it would work fine considering the fact that my LCD also supports progressive signal over composite/RF (but like most modern progressive displays, treats it as interlaced material by applying a deinterlace filter to the image).

[Omegamatrix]

A few years ago we were testing RSYNC for Stella development. If you go down a few posts in that thread you'll see where we discuss the screen starting to interlace. I think I'll try that rom on my new TV this weekend.

[JamesD]

NTSC is 60Hz but it only updates alternate scan lines with each pass of the electron beam.
60Hz is each individual pass of the electron beam across the screen.
To update all scan lines, NTSC is effectively updating the entire display at only 30Hz but the electron beam is passing across the screen twice in that time.
There's no flicker because you are always seeing neighboring lines of the image at 60Hz and the phosphor is designed to fade out slowly between passes of the electron beam.

In order to update all scan lines at 60Hz you'd have to make each pass at 120Hz.

*edit*
At least that's what my understanding was.

Edited February 17, 2016 by JamesD

[JamesD]

From the NTSC standard specification:

 

The horizontal scanning frequency shall be 2/455 times the color subcarrier frequency; this corresponds nominally to 15,750 cycles per second (with an actual value of 15,734.264+-0.047 cycles per second). The vertical scanning frequency is 2/525 times the horizontal scanning frequency: this corresponds nominally to 60 cycles per second (the actual value is 59.94 cycles per second).

*edit*

That seems to indicate both scans take place within 60 cycles per second.

 

Now that I think about it, that's what I remember. Hearing the comment about 30Hz made me over think it.

Edited February 17, 2016 by JamesD

[RevEng]

I recall people discussing A, B, and C flickering. just for clarity's sake, what do A, B, and C represent?

Here's the breakdown that Thomas set out:

 

A=plain 30Hz flicker (right of Thomas' program)

B=interlaced 30Hz flicker (left of Thomas' program)

C=no flicker, but moved/animated at 30Hz (not demonstrated, but discussed)

 

 

I have not yet tried the "480i" 262/263 demo. Will load that on my harmony shortly.

That one is actually 240p binary. The interlace is done via the 2600 manipulation, aka flickerblinds.

 

 

Hey, FYI, I downloaded the 480i demo linked on this page. I'm not necrobumping a 14-year old forum discussion topic from 2002 to bring this up, but the ROM does not work on my Harmony at all. I just get a blanked display with a thin blue line on the far left. Perhaps it was never tested on real hardware? I don't imagine people in 2002 had that option of just loading it on hardware without first burning an EPROM.

Pretty sure I ran Glenn Saunders' updated version on Harmony when I played with the technique myself. Not sure about the original, but it's not handy for me to run it tonight.

[Andromeda Stardust]

Here's the breakdown that Thomas set out:

 

A=plain 30Hz flicker (right of Thomas' program)

B=interlaced 30Hz flicker (left of Thomas' program)

C=no flicker, but moved/animated at 30Hz (not demonstrated, but discussed)

 

Option C: No flicker, but moved/animated at 30Hz...

 

I am aware of games employing multicolor sprites using flicker. But if the flicker effect is the result of the display kernel reaching the hardware limits of available sprite data, how does one display multiple objects without flicker, short of updating the TIA registers mid-scanline (and extremely finite amount of cycles available for this). I get it if the character position or movement is updated every other frame (Princess Rescue's kernel for instance ran at 20Hz frame rate for updating the sprites and playfield objects, 15 Hz when kicked shells were in motion, due to the limited amount of available CPU time for physics calculations during overscan), but if we are discussing non-flickering sprites, since there is no frame buffer or video RAM to store objects, the TIA must be updated every scanline rather than every frame, effectively requiring continuous CPU cycles even to display a static picture.

[RevEng]

C was raised only as a contrast to A and B, when someone wrongly suggested A was flickerless under 240p. It's not a general alternative to flicker.

[Thomas Jentzsch]

I am aware of games employing multicolor sprites using flicker. But if the flicker effect is the result of the display kernel reaching the hardware limits of available sprite data, how does one display multiple objects without flicker, short of updating the TIA registers mid-scanline (and extremely finite amount of cycles available for this).

Those are reasons when flicker becomes unavoidable. However the developer should always try to minimize it (e.g. intelligent flicker). Edited February 17, 2016 by Thomas Jentzsch

[Andromeda Stardust]

C was raised only as a contrast to A and B, when someone wrongly suggested A was flickerless under 240p. It's not a general alternative to flicker.

Okay so C option is just the placebo of a static block at 60Hz.

 

Leaving A option with 30Hz flicker

: : : : : : : : 
---> time

 

Or B option with simulated 240i

'.'.'.'.'.'.'.'.
---> time

I think B option is the best for CRT screen, but looks like ass with it's fatter than fat scan lines on an LCD.

 

And since integral changes to the engine would be required to switch formats, it is not as simple as flipping the B/W or difficulty switch. You would need two separate ROMs which would be a pain.

 

And yes, intelligent flicker is always best but I understand it is difficult to program. If your kernel is at it's limites with RAM, ROM, or CPU cycles, adding an intelligent flicker algorithm might not be possible. I imagine intelligent flicker looking something like

:':.:':.:':

or equivalent as holes within the flicker algorithm get filled whenever possible. On the whole, however, flicker isn't really that bothersome when only sprites or small areas of the screen are affected.

 

Look at Pacman 4k homebrew. Pacman, fruit, and four ghosts to share the same two sprite objects, and no intelligent flicker routine is present. So each sprite flickers at 20Hz. By using bright colors, the sprites remain visible onscreen even illuminating every third frame, yet the playfield graphics which make up over 90% of the image remains static the entire time. End result is flicker exists, even worse at 20Hz than at 30Hz, but taking up low real estate means it doesn't cause fatigue, and the black background ensures each sprite remains visible.

 

So flicker is really just nuisance when occupying large swaths of real estate, bright white (no color) and large areas. And overall it seems the cones (color neurons) in our eyes are less sensitive to flicker than the rods (contrast / night vision), so saturated colors for the flicker areas are perceived annoyingly so than white. I tried the blue flicker test with the difficulty switch, and while I could still detect the flicker, it was not painful as with the white.