New code making Stella 4.7 display inconsistant

[Thomas Jentzsch]

Attached is a very simply test ROM, which simply scrolls the 2 PF pixel at 60Hz. And you can see massive tearing in Stella's software mode.

This is not because of stressful code, just because on how the rendered result is put on the screen.

 

BTW: If you happen to have two monitors both running at 60Hz, then try to put the Stella window so that it shows partially on both screens. Even with e.g. OpenGL and VSync enabled, on one screen you will notice (pretty static) tearing.

SB_Test.bin

SB_Test.asm

Edited February 12, 2016 by Thomas Jentzsch

[Keatah]

FWIW:

I found the flip/blit policy to have a great effect whether tearing occurs or not. I tested this on an older machine that tends to hover around 50% usage with a single core cpu. When I have the policy set to flip, I get stupid smooth scrolling in either opengl or software rendering. DirectX always seems to produce some tearing, 3 or 4 evenly spaced staticy breaks in each line.

[Thomas Jentzsch]

What do you mean with "flip/blit policy"?

[Keatah]

See this:

http://www.intel.com/content/www/us/en/support/graphics-drivers/000005575.html

https://en.wikipedia.org/wiki/Multiple_buffering#Page_flipping

 

Flip (default value) - In applications that run in full screen, enables flip multi-buffering. With flip operations, the render buffer is directly connected with screen and when it is rendered it is just swapped on to the screen with no copying occurring.

 

Blit - Enables blit multi-buffering which copies rendered buffer on to the screen. With blit operations, several bitmap patterns are combined into one using a raster operator. Applications running windowed (not full-screen) can only use blit operations.

 

---

 

The way I see it is that with flip, the image is rendered to graphics memory "page 1", and a toggle switch flips and displays the image instantly. Then the next frame is rendered to "page 2" and the switch flipped and the next image displayed. It bounces back and forth between them. Page flipping. A popular animation technique on the Apple II. Essentially double buffering I think.

 

The end result is like a camera or scanner sensor. Scanning the scene. Then displaying it to you while it scans the next scene. You never see the scanning action.

 

With Blitting there is a lot of memory moving while the screen is being drawn, and parts of the image aren't always updated at the same time; resulting in an image that can break apart or appeared chopped or out of sync. When you move windows around the screen, not every pixel is updated, just the window contents. This is a more compatible mode for some applications. But much slower.

 

Like a movie camera filming a stage production, only the actors are moving. The stage and the background scene & props are stationary.

 

It also explains cpu usage differences between windowed and full-screen applications.

 

Hope that helps.

Edited February 12, 2016 by Keatah

[Mr SQL]

Keatah that's really interesting; Direct3D OS configuration differing from OpenGL under Windows 10 may resolve the issue with configuration options on those systems which is great but only relevant from my perspective if it can be implemented programmatically as a default in Stella. You hit the nail on the head with your descriptive post of the gaming experience.

 

Tom,software rendering mode is no longer relevant because it is not a default, but it may help explain why I am interested only in the default behavior and specifically, not changing any settings at all (users shouldn't have to configure anything and usually they won't).

 

To help understand this perspective, suppose when you and Andrew released the BoulderDash demo it fell apart painfully scrolling in Stella but looked captivating on the real hardware?

That was the scenario when I released KC Munchkin because Stella couldn't render my game in software just like your demo here, but now the issue has changed to having a powerful enough system and/or a specific Windows OS.

 

Stella 4.7 can run StarBlitz perfectly on a very powerful OS setup like yours, but my games display breaks apart painfully (instead of being captivating) on Windows 10 with slightly less powerful setups.

 

[Thomas Jentzsch]

Tom,software rendering mode is no longer relevant because it is not a default...

Agreed. I only enable it to get the tearing you described.

 

To help understand this perspective, suppose when you and Andrew released the BoulderDash demo it fell apart painfully scrolling in Stella but looked captivating on the real hardware?

Nope, not for me. I have always used OpenGL or Direct3D with VSync enabled.

 

Stella 4.7 can run StarBlitz perfectly on a very powerful OS setup like yours, but my games display breaks apart painfully (instead of being captivating) on Windows 10 with slightly less powerful setups.

How about the simple demo I posted above?

 

My demo (~6% CPU load) and your game (~8% CPU load) both work flawless on my Win10 with a dead slow Atom Z3735F CPU.

[Mr SQL]

Nope, not for me. I have always used OpenGL or Direct3D with VSync enabled.

 

 

Well I care if users can play my games, I don't just write them for myself.

 

And I think you feel the same way judging from your posts so perhaps you imagine users are keen on drilling into menu's and configurations to change the defaults like you do and don't just click on the ROM's to play them. That's a common programmer misconception, people just want to use the emu like it was a VCS.

 

And all of your awesome games have always displayed fine in the emulator, I don't see you leveraging that demo technique in a game and then insisting people change the emu defaults to get it to play

 

It seems you are unable to reproduce the intermittenly jarring display issue breaking the gameplay with Direct3D that Keatah, myself, RevEng and the indie reviewer all experienced in Stella 4.7.

 

What are the specs on your Windows 10 system that worked flawlessly?

(cpu speed, 64/32 bit, RAM)

[Thomas Jentzsch]

I write my code for real hardware and if I find a bug in Stella I help to fix it and improve its emulation (this happened multiple times). If anyone has a problem running my games in emulation, I provide help there too. Stella's default will always require additional setup, e.g. you have to tell Stella if your game uses a different controller than a joystick, if it supports a SaveKey/AtariVox or if it looks better with Phosphor emulation enabled. Its no rocket science to change that, just a few clicks. And if someone still has a problem with that: asking a question and getting an answer in no time is normal on AtariAge.

 

My Specs: 1.3 GHz, 2 GB RAM, 32 Bit (it doesn't get much lower today, does it?).

 

 

It seems you are unable to reproduce the intermittenly jarring display issue breaking the gameplay with Direct3D that Keatah, myself, RevEng and the indie reviewer all experienced in Stella 4.7.

 

Did they really all see what you are seeing? English ist not my first language, but to me it seems that they are describing different issues.

 

For me personally there is way too much general flicker going on. I am not sure why you put blank screens in between. This creates the bad flicker.

Edited February 12, 2016 by Thomas Jentzsch

[Thomas Jentzsch]

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.

I think part of the problem is, that there is a difference between CRTs and modern LCDs.

 

On modern LCDs, a pixel is hold until the next frame is displayed, where on a CRT it is going back to black (more or less) in between. In the latter case, the human brain calculates intermediate pixels, so that you do not see the smearing which you face with LCDs. That's why gaming LCDs blink the background lightning to emulate a CRT display.

Edited February 12, 2016 by Thomas Jentzsch

[Mr SQL]

I write my code for real hardware and if I find a bug in Stella I help to fix it and improve its emulation (this happened multiple times). If anyone has a problem running my games in emulation, I provide help there too. Stella's default will always require additional setup, e.g. you have to tell Stella if your game uses a different controller than a joystick, if it supports a SaveKey/AtariVox or if it looks better with Phosphor emulation enabled. Its no rocket science to change that, just a few clicks. And if someone still has a problem with that: asking a question and getting an answer in no time is normal on AtariAge.

 

My Specs: 1.3 GHz, 2 GB RAM, 32 Bit (it doesn't get much lower today, does it?).

 

 

 

Did they really all see what you are seeing? English ist not my first language, but to me it seems that they are describing different issues.

 

For me personally there is way too much general flicker going on. I am not sure why you put blank screens in between. This creates the bad flicker.

 

Depending upon the architecture we may need to multiply the GHZ x2 to compare it to 64-bit; 1.3 can = 2.6 in perf.

 

From Keatah and the indieretronews reviewers descriptions it seems clear they saw the same phennomena. Your demo (too fast) tears with Direct3D intermittenly, the sync is spiking.

 

I think we just have a different perspective; to me you described a fantasy scenario where because users know to adjust phosphor and common simple settings that many games require, they will also drill into configuration control panels and install drivers.

 

I think even power users like Keatah who can decipher and configure the OS control panels for Windows revised Direct3D settings (which according to the article no longer follows the same settings as OpenGL ) come to a different conclusion upon encounting the display breaks. They happened suddenly/intermittenly in a jarring way so it seems the objects are at different hz and breaking the display in a painful way.

 

I can't see any flicker at all btw, not even on LCD and your countryman Trixter claims there is minimal flicker "well within limits" and the game display is captivating (for those who Grok German) maybe he has a different display than you or you should stop splitting the emu window between screens on your dual monitor display

 

On a CRT Television it matches the 30 FPS broadcast signal for full frame animation - with Television the other "frame" is a field, 1/2 a frame that updates every other line so the effect is a smooth 30 HZ.

 

The VCS doesn't shift the lines; you don't need 60 HZ for a flicker free display, that's twice the frequency of NTSC Television. Often we use this rate just for the sprites which draws attention to them; 30 HZ is pleasant and has a subliminal effect on gaming - StarBlitz maximizes this effect by utilizing 30 hz for the full screen animation.

[Thomas Jentzsch]

I have written another test ROM, left difficulty controls the speed (B=60, A=30 Hz), right difficulty = A enables a blank screen every 2nd frame.

 

My observations:

• CRT TV @ 2600 console:
  • BB: smooth scrolling, no smearing or flicker
  • AB: smooth scrolling, noticeable smearing at the left and right edges, no flicker
  • AA: smooth scrolling, no smearing, hefty flicker
• LCD office monitor (slow switching), no phosphor @ Stella:
  • BB: smooth scrolling, slight smearing at the left and right edges, no flicker
  • BB: smooth scrolling, hefty smearing at the left and right edges, no flicker
  • AA: smooth scrolling, slight smearing at left edges only, hefty flicker
• LCD office monitor (slow switching), with phosphor @ Stella:
  • BB: smooth scrolling, hefty smearing, small black gaps are filled with grey, no flicker
  • AB: smooth scrolling, hefty smearing, left and right edges are flickering
  • AA: smooth scrolling, smearing at left and right edges, medium flicker

In all 3 scenarios for me BB looks best, followed by AB and then AA.

 

Notes:

• AA is the setting of Star Blitz
• BA makes no sense

Scroll_Test.bin

[Thomas Jentzsch]

Depending upon the architecture we may need to multiply the GHZ x2 to compare it to 64-bit; 1.3 can = 2.6 in perf.

Huh? Where do you get that strange idea?

 

For this type of software, the difference between 32 and 64 bit are hardly measurable.

 

On a CRT Television it matches the 30 FPS broadcast signal for full frame animation - with Television the other "frame" is a field, 1/2 a frame that updates every other line so the effect is a smooth 30 HZ.

Nope. A TV signal is interlaced, your display is not. Interlacing massively reduces flicker.

 

The VCS doesn't shift the lines; you don't need 60 HZ for a flicker free display, that's twice the frequency of NTSC Television. Often we use this rate just for the sprites which draws attention to them; 30 HZ is pleasant and has a subliminal effect on gaming - StarBlitz maximizes this effect by utilizing 30 hz for the full screen animation.

30 Hz animation is fine, but putting black frames in between causes hefty flicker. Please give my latest test program a try. It is very, very obvious (and annoying).

[RevEng]

It seems you are unable to reproduce the intermittenly jarring display issue breaking the gameplay with Direct3D that Keatah, myself, RevEng and the indie reviewer all experienced in Stella 4.7.

I'm not in this list. It's just as flickery for me on real hardware with CRT as it is on 4.7 Stella. I don't see tearing.

 

To be frank, you have a habit of framing people's responses in the most favorable light. The reviewer didn't mention that he had tearing in stella. Only "the cities flicker and can end up being abit to sharp to the eye.". That's consistent with what I experience on real hardware. Would have been useful to probe a bit more on his objection, rather than assuming it was a sync issue. If you can't see 30Hz flickering that's one thing, but a great many people can and find it annoying, not pleasant and stimulating. It's the reason they made broadcast TV signal interlaced in the first place. Check out the Flicker Fusion Threshold Wikipedia entry for more detail.

 

Stephena can correct me here, but I believe the reason sync isn't default is because it can cause problems with misbehaving drivers.

[Mr SQL]

Huh? Where do you get that strange idea?

 

For this type of software, the difference between 32 and 64 bit are hardly measurable.

 

Nope. A TV signal is interlaced, your display is not. Interlacing massively reduces flicker.

 

30 Hz animation is fine, but putting black frames in between causes hefty flicker. Please give my latest test program a try. It is very, very obvious (and annoying).

 

Interlacing draws one half of the picture and then the next half from the other field; this means each half of the picture frame is at 30 hz.

 

Your demo is running too fast - it's unpleasant to look at on the real hardware and causes optical illusion bending near the end of the screen. I do see a line breaking jaggedly on my windows 10 setup like my game does.

[Thomas Jentzsch]

Interlacing draws one half of the picture and then the next half from the other field; this means each half of the picture frame is at 30 hz.

Yup. And one half of your picture is all black -> Flicker!

 

Your demo is running too fast - it's unpleasant to look at on the real hardware and causes optical illusion bending near the end of the screen. I do see a line breaking jaggedly on my windows 10 setup like my game does.

You noticed what I wrote about the difficulty switches?

[Mr SQL]

I'm not in this list. It's just as flickery for me on real hardware with CRT as it is on 4.7 Stella. I don't see tearing.

 

To be frank, you have a habit of framing people's responses in the most favorable light for your works. The reviewer didn't mention that he had tearing in stella. Only "the cities flicker and can end up being abit to sharp to the eye.". That's consistent with what I experience on real hardware. If you can't see 30Hz flickering that's one thing, but a great many people can and find it annoying, not pleasant and stimulating. It's the reason they made broadcast TV signal interlaced in the first place. Check out the Flicker Fusion Threshold Wikipedia entry for more detail.

 

Stephena can correct me here, but I believe the reason sync isn't default is because it can cause problems with misbehaving drivers.

 

RevEng,

why not offer something more constructive? If a reviewer, Keatah and I can all see frames tearing in Stella 4.7 with specific Windows setups it can't have anything to do with the quaility of my game but I encourage you to try StarBlitz 5B and share your perspective on the game thread.

 

The games are fun and people have different perspectives but this is really a tangible problem, particularly if it's a bad low level layer as you're suggesting - the middleware is something we help Stephen identify and try to come up with a solution for to improve the emulator.

 

Besides, if my game quality is questionable I definitely want them to display correctly in the emu and not break apart on top of that - who would want to play them then?

[RevEng]

RevEng,

why not offer something more constructive? If a reviewer, Keatah and I can all see frames tearing in Stella 4.7 with specific Windows setups it can't have anything to do with the quaility of my game but I encourage you to try StarBlitz 5B and share your perspective on the game thread.

I am offering criticism of great constructive value. I have raised an issue that exists outside of Stella, and explained in concrete terms what it is. 30Hz flicker is perceptible and distracting to many. That's pretty much the definition of constructive feedback.

 

There are 2 issues here: One is tearing. The other is 30Hz flicker being detected by people. You have rejected that flicker is an issue outside of stella, and even went as far as to include my report of flicker as confirmation of tearing. To point out that you seem to have a bias in interpreting people's reports is also constructive. I have given you a concrete example, and it is something you can change. Here again, textbook constructive feedback.

 

Conflating the flickering and tearing issues does nobody any service.

 

If by constructive, you actually mean "positive" or "praising", then I will stop here, with only a suggestion that you have missed an opportunity.

[Mr SQL]

I am offering criticism of great constructive value. I have raised an issue that exists outside of Stella, and explained in concrete terms what it is. 30Hz flicker is perceptible and distracting to many. That's pretty much the definition of constructive feedback.

 

There are 2 issues here: One is tearing. The other is 30Hz flicker being detected by people. You have rejected that flicker is an issue outside of stella, and even went as far as to include my report of flicker as confirmation of tearing. To point out that you seem to have a bias in interpreting people's reports is also constructive. I have given you a concrete example, and it is something you can change. Here again, textbook constructive feedback.

 

Conflating the flickering and tearing issues does nobody any service.

 

If by constructive, you actually mean "positive" or "praising", then I will stop here, with only a suggestion that you have missed an opportunity.

 

RevEng, unconstructive posts seem more about sharing your personal perspective about your opinion being better/more unbiased than mine; that looks like a conversation you should have with Zylon Bane.

 

Clearly you can't speak for everyone with the claim I'm not doing anyone a service here even if my opinions are biased since it's a discussion forum by default and it's fun to collaborate and discuss ideas on these projects.

 

You're a programmer, why not join in the fun?

 

I've worked with Ekhard and Fred to solve issues on the other side (works in Harmony and Stella but breaks on the real hardware) on public forum threads and private discussion threads.

 

And I worked with Stephen previously on identifying and discussing a solution for the massive tearing issue with the 3.x default Stella configuration a couple of years ago.

 

I am interested in hearing your ideas about the low level driver causing the current sync issue if you're inclined to discuss.

 

Your feedback on the gameplay (good or bad) I'd definitely like to hear and explore on the StarBlitz thread with the other players.

[Thomas Jentzsch]

OK, flickering seems to be a problem related to the game itself (confirmed by at least RevEng and me). We can discuss this in the other thread.

 

However, IMO the tearing issue is most likely related to your computer's hardware setup. It could be the Direct3D driver or something related. Therefore I suppose to get better support, ask around in a hardware expert website.

 

BTW: Did you manage to record a video by now?

[RevEng]

RevEng, unconstructive posts seem more about sharing your personal perspective about your opinion being better/more unbiased than mine;

Citation for where I shared my personal perspective about my opinion being better than yours, please. I don't recall saying that.

 

 

Clearly you can't speak for everyone with the claim I'm not doing anyone a service here even if my opinions are biased since it's a discussion forum by default and it's fun to collaborate and discuss ideas on these projects.

If bias leads to the 2 different issues being conflated, it makes it more difficult to track down your technical issue. The added troubleshooting doesn't make things more fun.

 

 

I am interested in hearing your ideas about the low level driver causing the current sync issue if you're inclined to discuss.

I didn't say the low level driver caused the sync issue. Only that I believe that turning sync on for everybody as a default might be problematic for some cases, and I deferred to Stephena's experience.

[+stephena]

Just to add that now that Direct3D (for Windows) and OpenGL (for OSX and Linux) is the default, vsync defaults to on as well.

 

And vsync has no effect in software mode, since vsync implies double/triple buffering, and software mode is single-buffered (which is actually what causes tearing in rendering on most systems).

[Keatah]

Just a brief general observation.

 

VCS games are not simple Combat or Surround games anymore. As we push the limits of what is possible there are going to problems, like what is being talked about in this thread.

 

LCD panels vs. CRT displays. LCD has a ramp-up time. It takes time for the pixel twist itself into full brightness from black. And it takes time for it turn off as well. This results in smearing. It also results in leading edges (of a moving object) to be dim. And even compression of the object in the direction of movement.

 

CRT can turn on instantly, but cannot turn off instantly.

 

OLED can turn on instantly and turn off instantly.

 

All these different characteristics and affect how wide and how well defined the scrolling bars in the SB_Test.bin are.

[Thomas Jentzsch]

Spot on!

 

And especially for LCDs there are big differences in response times.

[Mr SQL]

Spice and I ran some tests and came upon another issue that could potentially be implemented into Stella's jitter code but it looks like something else is causing it, not sure what.

 

Here's the vid where you can see StarBlast role on a composite monitor whenever a meteor is hit.

starblitz vid.zip

It seems to be caused by the same problem KillerSquirrel encountered with DodgeItPA:

 

http://atariage.com/forums/topic/217787-dodge-it-panoramic-adventure/?p=2962740

 

That now happens on my Plasma too (but it didn't on my old plasma screen) and just turning the screen red will roll it continuously if I keep it red.

 

Spice's commodore monitor is so sensitive to whatever is causing this that 2 frames of red $34 or $36 roll the screen, but when we tried a cool blue $70 to flash the screen with, it doesn't roll.

 

imo the vid looks stable as an NTSC broadcast if anyone is inclined to discuss 30 hz flicker on the other thread.

 

Edit: Here is the revised build StarBlitz_v5B_rolltheorycheck.bin

 

 

Edited February 13, 2016 by Mr SQL

[Mr SQL]

Just a brief general observation.

 

VCS games are not simple Combat or Surround games anymore. As we push the limits of what is possible there are going to problems, like what is being talked about in this thread.

 

LCD panels vs. CRT displays. LCD has a ramp-up time. It takes time for the pixel twist itself into full brightness from black. And it takes time for it turn off as well. This results in smearing. It also results in leading edges (of a moving object) to be dim. And even compression of the object in the direction of movement.

 

CRT can turn on instantly, but cannot turn off instantly.

 

OLED can turn on instantly and turn off instantly.

 

All these different characteristics and affect how wide and how well defined the scrolling bars in the SB_Test.bin are.

 

I've posted the video of what we were seeing happen on the other thread:

http://atariage.com/forums/topic/248509-starblitz/?p=3440109

 

Joe's video on RevEng's thread might give us some insight into why Spice's CRT is red sensitive with StarBlitz video signal.

 

Stephen, curious if you think phosphor can be emulated without running 120 frames beneath the 60. It falls apart otherwise with 30 FPS animation.