Calling all Harmony Cart users, for science!

[alex_79]

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.

The problem is that the rom doesn't initialize correctly ram and stack. Probably the dev system used at the time (I think either a 7800 with devOS + ramcart or a supercharger) already initialized those so the bug wasn't evident. Here is a fixed version:

cube_imp-fix.bin

 

It seems to work fine on my crt TV.

It doesn't use RSYNC, the interlaceing is enabled just by using different VSYNC timing for each field.

[Thomas Jentzsch]

Correct, every other frame VSYNC is enabled and disabled in the middle of a scan line.

 

I wonder if that kind of output is better accepted by LCD TVs. I think I will provide a test program.

Edited February 17, 2016 by Thomas Jentzsch

[Andromeda Stardust]

My Hauppauge USB capture is extremely picky and refuses to display my Best AV modded 7800 at all, though it works great with NES and SNES. Demodulated 2600 and Genesis is putrid grayscale. I could attempt running it through the 7800 to see if it likes this "proper" interlaced signal.

 

FYI, I don't believe it is 240p that breaks the Happauge, otherwise NES/SNES wouldn't work, but it may be the fact scanlines on the Atari is 228 clocks instead of 227.5 or something. Grayscale might have to do with colorburst. I really don't know but I can try it.

 

If the Atari can pass a properly formatted NTSC signal, whether my Hauppauge capture will like it or not.

[+RevEng]

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.

LCD (really any modern non-CRT) is indeed a monkey wrench. "looks like ass" may be a bit harsh, since we're talking about non-flickering thick lines.

 

Omegamatrix had the idea to insert an extra scanline into odd frames, to try and break apart those thick lines. If that works out, then it would be relatively easy to add an "LCD friendly" option in any new game that uses flickerblinds.

 

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.

Just to be pedantic, it's rods (that dominate the central vision) that are slower and have a flicker fusion threshold around 15Hz. The cones are faster, though the blue cones probably aren't very much so. Red and green cones have a flicker fusion threshold of around 60Hz.

 

Since white is equal parts RGB, it trips the more sensitive red and green cones. Any colors containing significant amounts of red or green would be problematic.

 

My own thinking is flicker is on a spectrum of "annoying" to "acceptable". Large areas with red and/or green components are the worst. Anything you do to mitigate the effect of the flicker in your design shifts it more away from "annoying". How much you've shifted along the spectrum depends on how sensitive the viewer is.

 

Activision had a no-flicker policy for a reason. I'm nowhere near that absolute - my first 2600 game featured a large swath of flickerblinds graphics - but I don't think its ever possible to use flicker and move past flicker being just "acceptable", except maybe on LCD TVs that remove the flicker.

[Thomas Jentzsch]

Omegamatrix had the idea to insert an extra scanline into odd frames, to try and break apart those thick lines. If that works out, then it would be relatively easy to add an "LCD friendly" option in any new game that uses flickerblinds.

This may work for NTSC, but I doubt it will work for PAL which requires an even amount of scan lines.

[+RevEng]

Good call. Since its line offset we care about I guess we could pad overscan in both fields to make it overall an even 264 each frame.

[Thomas Jentzsch]

Chances still only 50:50, or do we know which line pairs are combined (even+odd or odd+even)?

 

Also interleaved texts like Harmony menu will still look 50% odd.

[+RevEng]

If we throw a pseudo 480i vsync at it, it may sort that out.

 

Definitely needs more testing. I'm not clear that harmony-like text will get messed up, if it's a manual option. Wouldn't it just deinterlace?

 

[edited for clarity]

[Andromeda Stardust]

This may work for NTSC, but I doubt it will work for PAL which requires an even amount of scan lines.

Every other PAL frame has an odd scanline count, just like NTSC.

 

NTSC: 262 + 263

PAL: 312 + 313

 

So long as every other frame is even, it won't matter.

[Andromeda Stardust]

Chances still only 50:50, or do we know which line pairs are combined (even+odd or odd+even)?

 

Also interleaved texts like Harmony menu will still look 50% odd.

Harmony is borderline unreadable on LCD. Perfect on CRT though.

[+RevEng]

The color phase alternates every other line with PAL. The 2600 itself doesn't know that an odd number of lines was drawn, and we have no way of altering the color phase it starts with at the top of the frame.

 

So on the 2600 a frame with an odd scanline count messes up the color badly under PAL.

[+RevEng]

Harmony is borderline unreadable on LCD. Perfect on CRT though.

I'm assuming that's due to the thick lines. Not sure. If we can break these apart correctly it may fix that.

[Andromeda Stardust]

I'm assuming that's due to the thick lines. Not sure. If we can break these apart correctly it may fix that.

Yes, I am well aware of the Harmony "simulated" 240i menu. It's still pretty easy to navigate the ROMs on an LCD, just takes a bit of extra effort to decipher the letters.

[Mr SQL]

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.

 

These words make no sense. Black cannot oscillate 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...

 

Programmers on this thread:

 

Try the 60 HZ 30 FPS version of StarBlitz, and compare it to the 30 HZ 30 FPS version of StarBlitz, judge for yourself if a real CRT looks better at 30 HZ or 60 HZ with 30 FPS of animation; that's different than a still image demo illustrating still image effects.

 

The poll is here with videos if you don't have the real hardware to try it on:

http://atariage.com/forums/topic/250243-30-fps-at-60-hz-vs-30-fps-at-30-hz/

 

The 60 HZ StarBlitz download is here:

http://atariage.com/forums/topic/249950-manual-flicker-optimization/?p=3465984

Turned out Empire Strikes Back from bitd has super smooth scrolling and also makes Stella jitter and shake apart, and Spice popped onto the thread to revise his claim that StarBlitz looked too good on his tiny video, to include looking too good on his larger video, clarifying that the badness can now only be seen directly in front of his modified Atari:

StarBlitz on SpiceWare's monitor.

 

I encourage more StarBlitz reviewers - awesome if Tom could review the 60 HZ version!

[Andromeda Stardust]

^^If I had the choice between 30fps with each 60Hz frame doubled, or 30fps with every other 60Hz frame blacked out, I would choose the former. 24Hz Movies look fine with 3:2 telecine after all...

[+RevEng]

I was listening to a favorite science podcast yesterday, and some info came up that seemed relevant to share here. I'll quote from the summary page. (The full 8-minute audio segment is at that same link)

 

If you have trouble reading the fine print on a restaurant menu, a team of scientists - including Dr. Melvyn Goodale, Canada Research Chair in Visual Neuroscience at Western University - have come up with a simple solution. By staring at a flickering image for several seconds, then looking at the fine print again, the text will be less blurry for a period of time. This is based on the knowledge that there are two major pathways that carry information from the eyes to the brain. One pathway is fast and carries more coarse information, including movement; the other is slow and carries finer detail such as text. By looking at the flickering image, the fast, coarse pathway becomes tired and allows the slow, fine detail pathway to take over, therefore improving acuity for reading words on a page.

Amazing how we're still learning about the finer details of our patchwork visual systems, but here's the bit that's relevant to game design - the scientists used flickering to over-stimulate and fatigue the visual neural pathways meant for detecting fast motion, temporarily reducing the ability of those same pathways to contribute.

 

Given that effect, if a game uses a large amount of flicker I'd expect the same fatigue to set in and impair the player's ability to detect fast moving objects. Something to keep in mind!

[Andromeda Stardust]

I was listening to a favorite science podcast yesterday, and some info came up that seemed relevant to share here. I'll quote from the summary page. (The full 8-minute audio segment is at that same link)

 

 

Amazing how we're still learning about the finer details of our patchwork visual systems, but here's the bit that's relevant to game design - the scientists used flickering to over-stimulate and fatigue the visual neural pathways meant for detecting fast motion, temporarily reducing the ability of those same pathways to contribute.

 

Given that effect, if a game uses a large amount of flicker I'd expect the same fatigue to set in and impair the player's ability to detect fast moving objects. Something to keep in mind!

Also the amount of real estate that flickers has a huge impact on enjoyment. 30Hz or even 20Hz flicker on a handful of sprites isn't bad, but if the entire playfield does it, the experience can get down right nauseating after a while. Playing in a darkened room as many of us do will only intensify the effect.

[Mr SQL]

Here is cutting edge parallel research that mirrors my research experiments with STARBLITZ and explains the other type of flicker that motion blur causes:

 

https://forums.blurbusters.com/viewtopic.php?f=7&p=33161#p33042

 

These same techniques are applied to enhance emulators that render at 60FPS on 120Hz LCD's by inserting a black frame, and to create super smooth 60fps animation using 480 Hz by inserting several black frames.

 

The researchers explanations are really clear with modern terminology and peer review research papers.

 

Sometimes new science discoveries are accidental; the phennomena was discovered working on advanced 3D displays, likewise I was working on a soft blitter chip and initially needed a frame to do the calculations and made the initial observations on the STARBLITZ thread; all of the related effects that were observed in STARBLITZ and discussed here and on the STARBLITZ thread are reiterated with additional demo examples you can try online.

 

The Atari's open ended architecture is so flexible new discoveries are still possible - hope this helps anyone who truly wishes to explore new science ideas and application of new display technologies