Atari 2600 motion blur research and experiments

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers & Advanced Display Articles on Blur Busters. The masters on Blur Busters.
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Atari 2600 motion blur research and experiments

Post by Chief Blur Buster » 18 May 2018, 14:18

Mr SQL wrote:This is awesome stuff! I'm continuing to read through your research articles and I will share this thread with the research scientists that were trying to understand the related effects in STARBLITZ and debunking them with contrived explanations.
Great!

You've probably seen many of the TestUFO motion tests by now, including the custom-configured links too (like the 5-UFO black-frame-insertion links).

I am always creating new tests (several per year) that piggybacks of several kinds of display behaviours.

You can show your researcher friends some of my favourite TestUFO animations.

- www.testufo.com/persistence
- www.testufo.com/eyetracking
- www.testufo.com/blackframes#count=4&bonusufo=1
- www.testufo.com/vrr
- www.testufo.com/ghosting

Sometimes a globally-viewable animation is better than a scientific paper.
(Papers are important too)

That's why I invented TestUFO -- it works in most web browsers worldwide.

Sometimes people don't want to believe in things until they see these custom-crafted motion tests similar to the above. Accompanied with quite simple experimentally-proven explanations with wide industry support.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
Mr SQL
Posts: 11
Joined: 12 May 2018, 08:24

Re: Atari 2600 motion blur research and experiments

Post by Mr SQL » 26 Feb 2021, 03:29

Chief Blur Buster wrote:
18 May 2018, 14:18
Mr SQL wrote:This is awesome stuff! I'm continuing to read through your research articles and I will share this thread with the research scientists that were trying to understand the related effects in STARBLITZ and debunking them with contrived explanations.
Great!

You've probably seen many of the TestUFO motion tests by now, including the custom-configured links too (like the 5-UFO black-frame-insertion links).

I am always creating new tests (several per year) that piggybacks of several kinds of display behaviours.

You can show your researcher friends some of my favourite TestUFO animations.

- www.testufo.com/persistence
- www.testufo.com/eyetracking
- www.testufo.com/blackframes#count=4&bonusufo=1
- www.testufo.com/vrr
- www.testufo.com/ghosting

Sometimes a globally-viewable animation is better than a scientific paper.
(Papers are important too)

That's why I invented TestUFO -- it works in most web browsers worldwide.

Sometimes people don't want to believe in things until they see these custom-crafted motion tests similar to the above. Accompanied with quite simple experimentally-proven explanations with wide industry support.
1001ThingsToDoWithYourPersonalComputer.jpg
1001ThingsToDoWithYourPersonalComputer.jpg (27.38 KiB) Viewed 6692 times
Hi Chief Blur Buster! :) It's been a while since we talked about these experiments - I added a throttle feature to these two demos below to let the user control the motion blur to experience the difference and to use it as a game effect; while motion blur is horrible when unexpected and in movies motion blur can be cool when intentionally controlled in a game :)

They are discernable in the browser but work much better on classic CRT they were designed for.

I think part of the difficulty people have understanding may come from getting used to motion blur and I wonder perhaps from some people simply never experiencing crisp CRT or film based movies as a reference point?

Code: Select all

rem ----------------------------------------------------------------------------
 rem --- SUPERBLITZ Throttle Control 3/2021
 rem --- basic10liner.com competition version
 rem --- Waves and Missions                 
 rem ----------------------------------------------------------------------------
 rem --- Insignia on Plane revealed after Night Mission is completed!
 rem --- Multiple Waves over differently colored Sky's and Cities
 rem --- More optical illusions: Some color combinations create unreal artifacting such as textured bricks -
 rem --- complete several rounds and describe what you encounter!
 rem --- note: Classic hardware and a CRT required to experience artifacting textures and additional illusions
 rem --- unique features - you control your speed and difficulty increases as you play
 rem --- BW switch pegs the throttle (Advanced)
 rem --- Each wave achieved keeps it's colors in Attract mode!
 rem --- Unlimited continues until powering off the console!

0 data city 5,9,6,9,7,6,7,5,9,5,5,5,5,6,6,7,5,8,5,8,7,5,8,8,5,5,6,6,7,5,7,8,9,8,8,7,8,9,5,6,8,5,9,6,6,7,5,7,5,5,8,5
1 if g=0 or CXP0FB>126 then CXCLR=0:for j=0 to 9:player1(j)=189:player0(j)=pl(j):rowcolors(j)=178+w:next j else goto 3
2 for j=20 to 71:k=j-20:k=city(k):for i=k to 9:vwpixel(j,i,on):next i,j:player0y=96:player0x=84:y=11:g=1:w=16*z
3 if f<player0y/52 and joy0right=0 and SWCHB|247=255 then f=f+1:goto 9 else AUDC1=7:AUDF1=BITIndex/5:AUDV1=BITIndex:f=0
4 AUDV0=f:scrollvirtualworldtoggle=1:BITIndex=BITIndex+1:missile0x=missile0x+2:data pl 0,224,127,231,252,192,128,0
5 if joy0fire=1 and y>8 then AUDF0=12:AUDC0=9:SUSTAINFORFRAMES=7:x=BITIndex+9:i=96-player0y:i=i/10:y=1+i:remPlayahTune
6 if y<10 then vwpixel(x,y,bindplayer1):COLUP1=M(y):y=y+1:data M 122,138,12,170,154,250,234,218,202,186,42,58,74,28   
7 if y<10 and vwpixel(x,y,poll)>0 then vwpixel(x,y,flip):player1x=0:player1y=0:AUDC0=y:y=21:AUDF0=4:AUDV0=15:rem Hit!
8 if BITIndex>71 then BITIndex=0:player0y=player0y-2 else missile1x=missile1x+1:missile1y=missile1y+3:rem SUPERBLITZ 86
9 if player0y=0 then g=0:player0colors(3)=14:player0colors(4)=112+z:COLUBK=M(z)-10:z=z+1 else missile0y=missile0y+2
Links to play the game online at different Hz rates, MBR Fx should be discernable when playing on an LCD monitor if you maximize the display to full screen after start up:

SUPERBLITZ running at 30 Hz and variable FPS:
https://javatari.org/?ROM=http://relati ... EN_MODE=1
FLUID CITY running at 60 Hz and variable FPS:
https://javatari.org/?ROM=http://relati ... EN_MODE=1

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Atari 2600 motion blur research and experiments

Post by Chief Blur Buster » 27 Feb 2021, 22:10

Thanks for following up with these experiments!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
Mr SQL
Posts: 11
Joined: 12 May 2018, 08:24

Re: Properly Designing A Blind Test That >90% Of Humans Can See 240Hz-vs-1000Hz (non-Game Use Cases Too!)

Post by Mr SQL » 23 May 2022, 22:31

From thread Properly Designing A Blind Test That >90% Of Humans Can See 240Hz-vs-1000Hz (non-Game Use Cases Too!):
Chief Blur Buster wrote:
23 May 2022, 20:26
Discorz wrote:
23 May 2022, 03:53
This also holds true for perfectly flat frametimes. Wouldn't this mean we need to test e.g 120 vs 480 fps or 60 vs 1000 fps at same gpu utilization? I'm not even sure if there is a way to go around this if we want to keep the same resolution scale. We could exclude interactive device out of the equation, but we don't want that. On top of this, nature of fluctuating gpu usage (even with flat frame pacing and times) may still affect it. Or I might be turning wrong direction here.
I forgot to mention...

GPU rendering times don't affect VSYNC ON because gametimes are keyed to the VBI's of VSYNC ON.

(Even as simple as just merely grabbing a timestamp immediately upon return from a blocking Present() on VSYNC ON -- which returns from a blocking API call when it hits the display's own VSYNC in the signal -- that's why it's called VSYNC ON).

VSYNC stands for Vertical SYNChronization, a component of a display signal that is a defacto comma-separator between refresh cycles (in digital POV). But back then in the analog days, it was an analog signal to vertically move the electron beam back to the top edge of the screen, to begin scanning a new refresh cycle.

Today it's still in the signal, but functioning more like a comma-separator signal and a time-delay (to allow display motherboard processing more time to begin to prepare a new refresh cycle -- but many display processors are so fast, you only need a tiny 1-scanline VSYNC).

Image

That's why it's called "VSYNC ON" in graphics drivers, it's named after the video signal's VSYNC, something that has existed for about 100 years since analog TV broadcasts has a VSYNC in it too.

(...Another name is "blanking interval" or "vertical blanking interval", but that's (porches/overscan + vsync) totalled. (porches were used as overscan area on a CRT tube, because tubes weren't perfectly shaped like digital monitors, and you needed to overscan a rectangular broadcast onto an odd-shaped tube, and extra overscan was also added to prevent the electron beam from going too far beyond the edges of the tube...)

Image

So this is very old technology. VSYNC existed in the 1920s Baird and Farnsworth TV broadcast experiments! They didn't call it VSYNC yet, but it's exactly the same signal still used on 2020s HDMI and DisplayPort cables. During the analog to digital transition we kept a 1:1 pixel clock.

A 1080p analog signal and a 1080p digital signal can be flawlessly adaptored to each other via an unbuffered realtime HDMI-to-VGA or VGA-to-HDMI adaptor. Yyou can even mirror the same 1080p HDMI output to both a 1080p digital monitor and a Sony FW900 CRT tube concurrently -- from the same digital GPU output (on cards that don't have VGA -- even a current RTX 3080 card. As long as both displays support the resolution and refresh rate and the timings (ATSC HDTV standard vertical total of 1125, which is used for both 1080i and 1080p), it works fine.

Digital signals are simply digital versions of the analog signal in a 1:1 pixel symmetry. Everything was preserved during the analog to digital transition, including the VSYNC signal embedded.

Now you understand the history of what "VSYNC" really means.

______________

Now back to modern nomenclature of GPU-based "VSYNC ON" which tells the drivers to synchronize frames to the signal, from a programmer perspective:

Windows waits for the GPU output to be aligned to a new refresh cycle, before returning from the Present() API.

Even with NULL (avoid buffering up), these waits are one big reason why VSYNC ON still has more latency than VSYNC OFF, but it does solve a big stutter weak link.

The magical thing is that at 1000Hz, VSYNC ON latency can become negligible (1ms). The higher the Hz, the less difference in latency between VSYNC ON and VSYNC OFF! So even if this visual test also became a latency test, the problem automagically solves itself because you're forced to ultrabrief frametimes with ultratiny differences between sync technologies (in latency).

For an experimental test, perfect framerate=Hz (ala VSYNC ON) is used to avoid a microstutter weak link that diminishes the difference between refresh rates. It's easier to tell apart 144Hz versus 180Hz if the content isn't microstuttering. 144fps@144Hz and 180fps@180Hz is generally easier to tell apart than unsynchronized-fps@144Hz vs unsynchronized-fps@180Hz, so we're removing various weak links that may lower the "retina refresh rate" measured in an experiment.

Because it's in exactly the same location of a refresh cycle, this keeps gametimes synchronous with refresh cycles.

1. Gametime clocks increases monolithically during VSYNC ON, keeping gametime:refreshtime in sync.
2. Object positions moving at constant speed always move at exact steps, despite varying GPU render times.
3. So gametime gets internally jittered by the varying GPU rendertime
4. But the VSYNC ON does the equivalent of 1-dimensional snap-to-grid, putting refreshtime back in sync with gametime.
5. Gametimes and refreshtimes are in perfect sync

Problem & weak link solved.

Thanks to VSYNC ON, increasing the threshold of retina refresh rate. VSYNC ON isn't perfect (lag, lag) but it's important for a researcher to measure a retina refresh rate threshold from a vision perspective. The sheer nature of retina refresh rates, also diminishes latency, since VSYNC ON latency can be optimized to refreshtime instead frametime, causing major latency drops as you increase refresh rates trying to test a humankind's retina refresh rate.

So multiple birds are hit concurrently. The intent was visual smoothness / blur / stroboscopic testing like The Stroboscopic Effect of Finite Frame Rates as well as 1000Hz Journey.

Thus, varying GPU rendertimes has no effect on this test, as long as gametime:refreshtime stays in sync (thanks to rendertimes staying less than refreshtime).
Hi Chief Blur Buster,
Awesome thread and science theory! :)

I've been conducting more experiments in the lower Hz ranges and found an unexpected side effect to help people perceive MBR who previously could not see it.

I used classic Television which also is CRT so we have the phosphor glow and persistence both affecting retina retention for considerable duration as part of the equation in these lower Hz experiments. here's a link to my previous MBR experiments using the Atari 2600 and a simple animated video game BLITZ with Throttle Control so the player can push forward on the stick and see the MBR difference.

Atari 2600 MBR Experiments Area 51 Thread:
viewtopic.php?f=7&t=4135

BLITZ with Throttle Control online (in Javatari Atari emulator):
https://javatari.org/?ROM=http://relati ... EEN_MODE=1

MBR Perception problem:
-------------------------------
I thought it was easy to see and you can see it too, but we've got a considerable percentage of folks who simply cannot perceive the difference with MBR, possibly in part from never having been exposed to CRT and always having seen a degree of MBR they are more tolerant of it; the root cause of MBR challenged perception is interesting it itself.

MBR Perception boost noticed building Commodore 64 Atari 2600 Emulator
----------------------------------------------------------------------------------------------
I found an unexpected way to boost MBR perception considerably creating an Atari 2600 Emulator for the Commodore 64 that could put fantastic Commodore Graphics on the Atari games.

How it works:
------------------
If you play the Blitz Throttle Control game in the link above you'll see phantom half size pixels emerge surrounding the phat tile pixels unless you go fast to eliminate the MBR.

Well the C64 paints PETSCII graphics on the phat tile pixels with 4 PETSCII characters per tile pixel allowing a wide range of shapes to be programmed (or even animated).

I drew detailed designs with PETSCII graphics on the buildings and it underscored the MBR, folks who found MBR too subtle on the Atari 2600 suddenly saw it on the Commodore 64.

This is pretty cool, it even shows up well in the VICE emulator but it really stands out on CRT! Here is a Benchmarking page with my unrelated C64 Atari 2600 emulator experiments showing the effect very prominently in the Silly Venture Fluid City clip in the lower right (my camera couldn't capture it properly):

http://relationalframework.com/C64ATARI ... lator.htm

More details are here on the Commodore forum on AtariAge:
https://atariage.com/forums/topic/33500 ... compiler/
C64_all_day_Easy_Calc_is_the_best.JPG
C64_all_day_Easy_Calc_is_the_best.JPG (118.21 KiB) Viewed 4909 times

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Properly Designing A Blind Test That >90% Of Humans Can See 240Hz-vs-1000Hz (non-Game Use Cases Too!)

Post by Chief Blur Buster » 24 May 2022, 16:16

Mr SQL wrote:
23 May 2022, 22:31
This is pretty cool, it even shows up well in the VICE emulator but it really stands out on CRT! Here is a Benchmarking page with my unrelated C64 Atari 2600 emulator experiments showing the effect very prominently in the Silly Venture Fluid City clip in the lower right (my camera couldn't capture it properly):
Very interesting!

Thank you for posting this.

I enjoy reading about your Area51-worthy continued display-visuals experiments, even if it's a little left-field from some of the other threads!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
Mr SQL
Posts: 11
Joined: 12 May 2018, 08:24

Re: Properly Designing A Blind Test That >90% Of Humans Can See 240Hz-vs-1000Hz (non-Game Use Cases Too!)

Post by Mr SQL » 28 May 2022, 01:05

Chief Blur Buster wrote:
24 May 2022, 16:16
Mr SQL wrote:
23 May 2022, 22:31
This is pretty cool, it even shows up well in the VICE emulator but it really stands out on CRT! Here is a Benchmarking page with my unrelated C64 Atari 2600 emulator experiments showing the effect very prominently in the Silly Venture Fluid City clip in the lower right (my camera couldn't capture it properly):
Very interesting!

Thank you for posting this.

I enjoy reading about your Area51-worthy continued display-visuals experiments, even if it's a little left-field from some of the other threads!
Thanks! I just added a clip of STARBLITZ without the MBR filter, it really sparkles. I never want to see it in a movie, but controlled motion blur can be an enhancement in large pixel retro games depending on how and when it is used check out the Fx here:
phpBB [video]

The Atari version with the MBR filter activated is in the description. There is an option to turn off the MBR in the Javatari link I posted earlier, but the blur Fx is more interesting on the C64, possibly also because of the hieroglyph PETSCII drawing/activating our eyes like the text in a book and making both MB and MBR more apparent.

My experiments are all in the low Hz ranges, but the addition of symbols might similarly aide perception of MBR in the higher realms.

User avatar
Mr SQL
Posts: 11
Joined: 12 May 2018, 08:24

Re: Atari 2600 motion blur research and experiments

Post by Mr SQL » 19 Jun 2022, 22:41

Here are some exact benchmark comparisons of the C64 Atari 2600 Emulator with the real Atari 2600 hardware videos right below them to see the difference. Motion Blur Reduction may be easier to see with PETSCII symbols.

http://relationalframework.com/C64ATARI ... ator2.htm

User avatar
Mr SQL
Posts: 11
Joined: 12 May 2018, 08:24

Re: Atari 2600 motion blur research and experiments

Post by Mr SQL » 24 Mar 2024, 15:46

I've added the Motion Blur Reduction filters to the Commodore 64 Atari 2600 emulator!

Here is STARBLITZ NEON SOUND with additional optical illusion Fx experiments in the LP video:

Difficult to film but looks great in person.

phpBB [video]

Post Reply