New code making Stella 4.7 display inconsistant

[Thomas Jentzsch]

That's the code I am talking about.

 

Worst case, if VSYNC is enabled at cycle 73, the following WSYNC delays by just 3 cycles. And then VSYNC is disabled after just 157 cycles again.

[Mr SQL]

You meant VSYNC is delayed by 3 cycles not 3 full scanlines? I thought you were seeing the startup init.

 

There are more than 3 cycles if the animation kernel is engaged - looks like the number of cycles before VSYNC is not equal

on the frames though they both total 262. I will try equalizing them and eliminating the delay (0 cycles before VSYNC) to see if it makes a difference.

[Thomas Jentzsch]

You meant VSYNC is delayed by 3 cycles not 3 full scanlines?

No.

 

The first VSYNC comes without any preceding WSYNC. So it can be trigger any time on a scan line (worst case cycle 73). The following WSYNC only completes the current scan line (so no full scan line). So depending on when the first VSYNC was triggered it is enable between 2.x and 3.x scan lines.

[+SpiceWare]

That's similar to the problem Warlords had, the VSYNC occurring late in the scan line would throw off an XRGB-mini used to show the Atari on a modern display.

[Keatah]

I wonder if all this isn't a trick of the eye and minor variances of the render system aggravating it. OR pushing it to the limit where you can see flickering.

 

I talked about this a long time ago. Let me try simplifying it.

 

Say you have 192 horizontal dots, and you wish to scroll perfectly smooth. Perfectly. That means you have to update the display when the dot is moved 1 position at a time. 1 dot = 1 frame. 192 plots. That means 192 FPS if you wish your dot to make it across the screen in 1 second, without distortion, fading, flickering or any other artifact.

 

To test this you can make it where you have two dots. One that moves across the 192-wide field in one second on a 60hz screen. You'll either see some dropouts, or flickering, or stretching and blending of the dot into a dash, depending on your display technology.

 

To see this "phenomenon" in starblitz game however. When you pay attention to the background city, you see a slight 30hz flicker. And you can track it smoothly with your eye. And doesn't flicker much.

 

Now focus on the ship and its movements. All of a sudden, like magic, the background cityscape is flickering like crazy. Maybe tearing and jittery too - depends on your definition of tear & jitter.

 

Note: Just because something says 60hz doesn't automatically mean smooth. Your render pipeline has to deliver a screen update every single pixel movement or your object blurs. If it moves more than 1 "object's width" during an update you sure as hell will notice the discrete jumps.

 

It's like a visual quantization, and flicker or blur is the noise. Real life vision doesn't encounter this because a car flying past you at a hundred clicks is doing so with billions upon billions of FPS. The care does jump in discrete steps, however, they are on Planck timescale though.

 

So yes, playing Doom or Quake at 30hz, 60hz, 100hz, and 240hz result in progressively smoother scrolling and animation. the improvements continue to increase till you are updating at the dot-resolution (in fps). For 1024x768 that could mean 1024 fps or 768 fps, depending on your direction of movement.

 

A seemingly instant and fast 60hz update rate guarantees nothing when your onscreen object has to move 180 pixels in that one second. You're going to see smearing if your eye is tracking it. Or flickering if your eye is paying attention to something else.

 

A game that has different update rates in the same play area and requires you to swap your attention between those rates is going to cause discomfort.

 

And that's what's happening here.

Edited February 10, 2016 by Keatah

[Mr SQL]

That's similar to the problem Warlords had, the VSYNC occurring late in the scan line would throw off an XRGB-mini used to show the Atari on a modern display.

 

Spice you put a WSYNC after VBLANK before setting VSYNC, I get that it was occuring too late in the scanline but why can't the WSYNC go before the VBLANK so that VBLANK starts earlier, does it make a difference?

 

Tom, I don't get why VSYNC is not showing as enabled for 3 scanlines; I followed Andrew's example setting VSYNC when I wrote the kernels (from RT's page):

 

lda #0

sta VBLANK

lda #2

sta VSYNC

 

; 3 scanlines of VSYNCH signal...

 

sta WSYNC

sta WSYNC

sta WSYNC

 

lda #0

 

sta VSYNC "

 

The #2 in VSYNC resets the electron beam to the upper left and the 3 WSYNC scanlines give it time, then a zero is put in VSYNC; this should be happening for both kernels frames.

[Mr SQL]

 

To see this "phenomenon" in starblitz game however. When you pay attention to the background city, you see a slight 30hz flicker. And you can track it smoothly with your eye. And doesn't flicker much.

 

Now focus on the ship and its movements. All of a sudden, like magic, the background cityscape is flickering like crazy. Maybe tearing and jittery too - depends on your definition of tear & jitter.

 

...

 

A game that has different update rates in the same play area and requires you to swap your attention between those rates is going to cause discomfort.

 

And that's what's happening here.

Excellent description Keatah, it does happen all of the sudden but I think it's something going on with the emulator since flicker can't be turning on and off, especially since all of the update rates for the objects match - the city and the sprites are all updated 30 times per second.

 

Try this with Stella - launch task manager (ctrl+shift+escape) and right click the stella app to go to the process. Then the detail view and then right click the stella process and set it to "real time". How does this affect StarBlitz gameplay for you?

[+SpiceWare]

Spice you put a WSYNC after VBLANK before setting VSYNC, I get that it was occuring too late in the scanline but why can't the WSYNC go before the VBLANK so that VBLANK starts earlier, does it make a difference?

That's the code from Warlords. Odds are you don't need to set VBLANK during the VerticalSync as you probably already turned off video output at the start of your Overscan code. From Collect:

 

VerticalSync:
        lda #2      ; LoaD Accumulator with 2 so D1=1
        sta WSYNC   ; Wait for SYNC (halts CPU until end of scanline)
        sta VSYNC   ; Accumulator D1=1, turns on Vertical Sync signal
        sta WSYNC   ; Wait for Sync - halts CPU until end of 1st scanline of VSYNC
        sta WSYNC   ; wait until end of 2nd scanline of VSYNC
        lda #0      ; LoaD Accumulator with 0 so D1=0
        sta WSYNC   ; wait until end of 3rd scanline of VSYNC
        sta VSYNC   ; Accumulator D1=0, turns off Vertical Sync signal
        rts         ; ReTurn from Subroutine
...

OverScan:
        sta WSYNC   ; Wait for SYNC (halts CPU until end of scanline)
        lda #2      ; LoaD Accumulator with 2 so D1=1
        sta VBLANK  ; STore Accumulator to VBLANK, D1=1 turns image output off

---

 

Tom, I don't get why VSYNC is not showing as enabled for 3 scanlines; I followed Andrew's example setting VSYNC when I wrote the kernels (from RT's page):

The problem is this:

 
            lda #0
            sta VBLANK
            lda #2
            sta VSYNC     <------- WHAT IS YOUR CYCLE TIME HERE?

               ; 3 scanlines of VSYNCH signal...

                sta WSYNC
                sta WSYNC
                sta WSYNC

            lda #0

            sta VSYNC

---

If you're at 73, you're only getting 2 scanlines for the sync signal

If you're at 38, you're only getting 2.5 scanlines of the sync signal

If you're at 3, you're getting 3 scanlines for the sync signal.

[Mr SQL]

That's the code from Warlords. Odds are you don't need to set VBLANK during the VerticalSync as you probably already turned off video output at the start of your Overscan code. From Collect:

 

VerticalSync:
        lda #2      ; LoaD Accumulator with 2 so D1=1
        sta WSYNC   ; Wait for SYNC (halts CPU until end of scanline)
        sta VSYNC   ; Accumulator D1=1, turns on Vertical Sync signal
        sta WSYNC   ; Wait for Sync - halts CPU until end of 1st scanline of VSYNC
        sta WSYNC   ; wait until end of 2nd scanline of VSYNC
        lda #0      ; LoaD Accumulator with 0 so D1=0
        sta WSYNC   ; wait until end of 3rd scanline of VSYNC
        sta VSYNC   ; Accumulator D1=0, turns off Vertical Sync signal
        rts         ; ReTurn from Subroutine
...

OverScan:
        sta WSYNC   ; Wait for SYNC (halts CPU until end of scanline)
        lda #2      ; LoaD Accumulator with 2 so D1=1
        sta VBLANK  ; STore Accumulator to VBLANK, D1=1 turns image output off

---

 

 

The problem is this:

 
            lda #0
            sta VBLANK
            lda #2
            sta VSYNC     <------- WHAT IS YOUR CYCLE TIME HERE?

               ; 3 scanlines of VSYNCH signal...

                sta WSYNC
                sta WSYNC
                sta WSYNC

            lda #0

            sta VSYNC

---

If you're at 73, you're only getting 2 scanlines for the sync signal

If you're at 38, you're only getting 2.5 scanlines of the sync signal

If you're at 3, you're getting 3 scanlines for the sync signal.

 

Ah, got it Appears to be at 7 cycles at that point for the normal frame, and a few more on the animation frame that seems to be causing the issue.

 

That's pretty close enough to 3 scanlines, I wonder if the extra cycles in the animation frame could cause it.

 

I will matching the cycles in both frames and getting it spot on 3 too to see if it has an impact.

[RevEng]

Excellent description Keatah, it does happen all of the sudden but I think it's something going on with the emulator since flicker can't be turning on and off, especially since all of the update rates for the objects match - the city and the sprites are all updated 30 times per second.

Sounds to me like he's saying the flickering is worse in peripheral vision, which is a well known phenomena. We have sluggish cone cells predominantly in the central part of our vision, and faster rod cells dominate our peripheral vision. It's also the reason why you sometimes see blinking out of the corner of your eye with some PWM light sources.

[Keatah]

No not peripheral vision. I thought about that and "conducted my observation" with the ship and cityscape in the same view area. Dead center of field of view.

[RevEng]

Ok. But it happens when you focus on the ship, rather than the background. Correct?

[Mr SQL]

Ok. But it happens when you focus on the ship, rather than the background. Correct?

RevEng,

Keatah was able to see a slight 30 hz flicker like you can but pointed out it was minimal; the tearing happens all of the sudden and causes discomfort as Keatah and the retroindienews reviewer described:

 

"All of a sudden, like magic, the background cityscape is flickering like crazy. Maybe tearing and jittery too - depends on your definition of tear & jitter"

 

but it's not necessary to focus on the ship; just likely that you will be if you are playing the game in which case it's jarring when it happens because the smooth gaming experience is interrupted.

 

This gives the feeling that the objects have different update rates but they don't; you can demonstrate the issue by turning on software rendering mode, then the whole screen tears apart but all other Atari games work fine.

 

Some users have systems that can render the game flawlessly in Stella like Tom and the German reviewer Trixter.

 

 

No not peripheral vision. I thought about that and "conducted my observation" with the ship and cityscape in the same view area. Dead center of field of view.

Keatah, I know you favor pure emulation over the real hardware so the StarBlitz gaming experience makes for an interesting discussion because the gameplay can be extremely polarized; take a look at the video of the StarBlitz on the real hardware and see if it looks pleasant or painful.

 

RevEng made an excellent point that it is more painful when the playfield breaks in your peripheral but I think this is linked to the phennomena of 30 hz augmenting that effect; 30 hz is at the border of perception, many can't see it and thus the effect can be subliminal but it affects the brain in an enjoyable way that makes gaming more fun and captivating and hypnotic/trance inducing:

 

Even the video of StarBlitz on an analog TV doesn't match the experience of actually playing it; all objects are synced at 30 hz which mostly shows in the vid despite occasional artifacts in the digital camera tearing the screen when it loses synch.

 

The phosphor augments the subliminal effect because you are far less likely to percieve even faint flicker at 30 fps - the same as broadcast NTSC; that's why Television was so captivating growing up, it really did hypnotize us

[Thomas Jentzsch]

I just tried my best to replicate the problem, by using software mode and disabling VSYNC. Then I think(!) I can see what you mean and the screen is massively tearing.

 

But, whenever I make a screen shot of this, the result looks perfect (no tearing at all). So Stella is rendering perfectly and this tearing is clearly not a Stella issue, but the result of missing VSYNC.

[RevEng]

RevEng,

Keatah was able to see a slight 30 hz flicker like you can but pointed out it was minimal; the tearing happens all of the sudden and causes discomfort as Keatah and the retroindienews reviewer described:

 

"All of a sudden, like magic, the background cityscape is flickering like crazy. Maybe tearing and jittery too - depends on your definition of tear & jitter"

You missed a bit: "Now focus on the ship and its movements. All of a sudden, like magic, the background cityscape is flickering like crazy. Maybe tearing and jittery too - depends on your definition of tear & jitter."

 

I think we probably have 2 competing effects here - one caused by not using the vsync stella setting (which results in the tearing and is the reason the vsync setting is there in the first place) and another caused by peripheral vision. The 2 effects likely play off each other when both are present.

 

We have slow cone cells exclusively in the central 2 degrees of our field of vision. These drop off sharply and are replaced mostly by rod cells by an 8 degree field of vision angle. Depending on who you're talking to, peripheral vision begins at the 8 degree mark, or some time prior, so unless you use a very tiny/far-away monitor, it's definitely a factor.

[Mr SQL]

I just tried my best to replicate the problem, by using software mode and disabling VSYNC. Then I think(!) I can see what you mean and the screen is massively tearing.

 

But, whenever I make a screen shot of this, the result looks perfect (no tearing at all). So Stella is rendering perfectly and this tearing is clearly not a Stella issue, but the result of missing VSYNC.

 

 

If it runs on the real hardware then it should work in the emulation, particularly if the same monitor is used. I will try to build an emu safe build if that solves it though:

 

It looked pretty close to 3 scanlines worth of VSYNC; how much was it off by? I will pm you the build where VSYNC has exactly 3 scanlines to double check if this is the issue. Perhaps the emulated electron gun has more travel (return to the top time) than it really should?

[Thomas Jentzsch]

I am referring to VSYNC in Stella: Tab/Video Settings/Vsync

[Thomas Jentzsch]

If it runs on the real hardware then it should work in the emulation, particularly if the same monitor is used.

It does. The problem is, that on read hardware, the console creates the vertical sync of the monitor. While in emulation the video driver of the OS does it (assuming a CRT). Enabling Stella's VSync setting, synchronizes the emulation frame rate to the OS frame rate.

 

It looked pretty close to 3 scanlines worth of VSYNC; how much was it off by?

That's undetermined. Anything between ~2 and ~3 scanlines.

 

I will pm you the build where VSYNC has exactly 3 scanlines to double check if this is the issue. Perhaps the emulated electron gun has more travel (return to the top time) than it really should?

It doesn't have to be exactly 3 scanlines, but at least 3 scanlines. And IIRC the length should be constant.

Edited February 11, 2016 by Thomas Jentzsch

[Mr SQL]

It does. The problem is, that on read hardware, the console creates the vertical sync of the monitor. While in emulation the video driver of the OS does it (assuming a CRT). Enabling Stella's VSync setting, synchronizes the emulation frame rate to the OS frame rate.

 

That's undetermined. Anything between ~2 and ~3 scanlines.

 

 

It doesn't have to be exactly 3 scanlines, but at least 3 scanlines. And IIRC the length should be constant.

 

Ah, now it makes more sense why Z26 was able to render the game once I tied the vsync setting to the monitor -

z26 had two settings, one to tie it to the monitor and the default to tie it to the clock plus another OS option; which of these three OS anchors does Stella use? I went into the menu and see it's on by default but I suspect it's not the monitor since that one cleared it up in Z26.

 

I want to make it work in Stella preferrably with the defaults. The build that you and Spice helped me tweak for a perfect VSYNC still seems to have the problem but perhaps less of it.

 

Here is the VSYNC build if anyone can see a difference:

StarBlitz_v5B_VSYNC_FOR_EMU.bin

[Thomas Jentzsch]

I want to make it work in Stella preferrably with the defaults.

Why?

 

And its impossible anyway, since there will always be slight differences of the frame rate of the emulator and the monitor. This is unavoidable, so that's why Stella offers the VSync settings.

 

You have to use it, a game like yours needs perfect sync between emulator and monitor.

[Mr SQL]

Why?

 

And its impossible anyway, since there will always be slight differences of the frame rate of the emulator and the monitor. This is unavoidable, so that's why Stella offers the VSync settings.

 

You have to use it, a game like yours needs perfect sync between emulator and monitor.

 

 

Yes vSync is on by default. I'd like the game to be just as fun in emulation as it is on the real hardware.

 

The technique has interesting application for gaming, no other vintage console can achieve 30 FPS of full screen animation besides the VCS

 

And vwBASIC games also use this display engine.

 

Why don't you think it's possible for Stella to push 30 FPS of full screen animation encoded in 60??

 

I think the potential is there as long as the target display has enough overhead to accomodate.

 

If the display is 60 hz or 120 hz the OS might get a better match... I had to change display settings in Z26 in addition to tying sync to the monitor.

 

What happens if the display is some othe hz though, you get encoding that oscillates because it doesn't fit evenly. It would lose the 30 hz effect but still shouldn't break the display unless one of the layers is making slow calls.

 

I think this is happening because the sprites can be displayed at 30 hz no problem and everything sync's so it looks like a matter of too much screen data for the calling code to pass quickly enough that is breaking the sync. Perhaps the calling code is attempting to pass a full screen 1024x768 color bitmap (or whatever res) of the playfield and building it slowly. I think this is what software rendering does; maybe the calling code is still running a bit slow passing data to Direct3D.

[Thomas Jentzsch]

Why don't you think it's possible for Stella to push 30 FPS of full screen animation encoded in 60??

What? Where did I say so???

 

I said that multiple games have done this before. And Stella can handle them all. Which is the exact opposite.

 

I think this is happening because the sprites can be displayed at 30 hz no problem and everything sync's so it looks like a matter of too much screen data for the calling code to pass quickly enough that is breaking the sync.

Sorry, but nothing is breaking the sync here. And definitely any 2600 code can NOT do so. Not on modern hardware. NOOO way!

 

I am not sure what you are trying to prove with constantly repeating that your code is breaking or over stressing emulation. Stella can even easily handle ARM accelerated code, running at 70 MHz, pure 6507 at 1 MHz code is slower by at least a margin.

 

I can let your ROM run in 10 instances without any problem. No slowdown, no tearing, 1-2% CPU load each.

Edited February 11, 2016 by Thomas Jentzsch

[Mr SQL]

What? Where did I say so???

 

I said that multiple games have done this before. And Stella can handle them all. Which is the exact opposite.

 

Sorry, but nothing is breaking the sync here. And definitely any 2600 code can NOT do so. Not on modern hardware. NOOO way!

 

I am not sure what you are trying to prove with constantly repeating that your code is breaking or over stressing emulation. Stella can even easily handle ARM accelerated code, running at 70 MHz, pure 6507 at 1 MHz code is slower by at least a margin.

 

I can let your ROM run in 10 instances without any problem. No slowdown, no tearing, 1-2% CPU load each.

 

Looks like miscommunication; you said it right here in response to my post that I wanted to make the game run in the emulator with the defaults:

 

And its impossible anyway, since there will always be slight differences of the frame rate of the emulator and the monitor.

 

What did you actually mean?

 

You also proved the game is tearing the emulator apart "massively" on your system while displaying fine on the real hardware. Is there another Atari game that does this?

 

And you keep repeating that I need to set vsync in Stella; I'm not sure why because I keep explaining to you that the setting is already on (by default) so I have to repeat myself too

 

Did providing 3 scanlines for VSYNC instead of 2.9 yield an appreciable difference on your emu setup?

 

Try using software mode without disabling VSYNC; the massive problem you identified is still there.

[Mr SQL]

Update - I tried Stella on two more systems:

 

1, A Windows 7 Home system with a faster processor and more memory - StarBlitz looked awesome, I couldn't even see minimal flicker and Stella synced the display perfectly. Stella=Farfegnugen! This is 30 hz emulation the way I want users to experience the game effects.

(3 GHZ powerful 64-bit CPU, 6 GB RAM)

 

2. A Windows XP Pro system with a slower processor and less memory - Stella completely shut the system down with an ever expanding swap file (memory) and I had to reboot.

(1.1 GHZ, 32-bit, 512 MB RAM)

 

There is clearly a performance curve; you and the German reviewer Trixter have newer systems maybe both running Windows 7 while Keatah, the indieretronews reviewer and RevEng all have slower systems with less memory, perhaps running Windows 10 because

on these systems we all see "flicker" that starts and stops suddenly and tearing and hesitation break the 30 hz effect. It's jarring and painful to play the game as described.

 

The specs on my Windows 10 Pro system were still relatively powerful: 2 GHZ celeron 64-bit CPU, 4 GB RAM.

(Keatah and RevEng, what are the specs on your systems?)

 

[Thomas Jentzsch]

Looks like miscommunication; you said it right here in response to my post that I wanted to make the game run in the emulator with the defaults:

 

And its impossible anyway, since there will always be slight differences of the frame rate of the emulator and the monitor.

 

What did you actually mean?

I mean that the monitor will e.g. run at 60.001 Hz and the emulator at 59.999 Hz. Or vice versa, or some other fractions.

 

You also proved the game is tearing the emulator apart "massively" on your system while displaying fine on the real hardware. Is there another Atari game that does this?

All games do this. It is just less obvious while there is less movement on the screen.

 

And you keep repeating that I need to set vsync in Stella; I'm not sure why because I keep explaining to you that the setting is already on (by default) so I have to repeat myself too

I didn't get you there then.

 

Did providing 3 scanlines for VSYNC instead of 2.9 yield an appreciable difference on your emu setup?

Nope. Stella is less sensitive than some real hardware

 

Try using software mode without disabling VSYNC; the massive problem you identified is still there.

Yes. And it makes no difference if I enable VSync in Stella. So it seems that software more does not use VSync.

 

BTW: Have had a look at the Stella documentation. There is a "timing" setting, which may help reducing the tearing on slower systems.

Edited February 12, 2016 by Thomas Jentzsch