Jump to content
IGNORED

New code making Stella 4.7 display inconsistant


Mr SQL

Recommended Posts

Changes to Stella since version 4 seem to have introduced a display bug on Windows when the TIA is heavily utilized.

 

Try the latest build of StarBlitz in Stella 4.7 on Windows with default settings to illustrate - the opening title screen is fluidly animated except for intermittent lags and glitches.

 

http://atariage.com/forums/topic/248509-starblitz/

 

These aren't pressent on the real hardware, and they are not present on Stella most of the time - aside from the intermittent lags and glitches Stella shows a smoothly animated and rock solid display.

 

Direct-X is a very high performance display engine but there appears to be a bottle-neck sending the data that wasn't there in Stella 4.1

 

I think StarBlitz is a good game to use to test Stella when making timing critical changes to the core because it pushes so much data through the TIA; kind of like a visual trace for display bottle-necks.

 

 

Link to comment
Share on other sites

I have analysed the first glitch (background color changing for two frames 29 and 30). The following code is executed:

L1D2a
  lda #$34
  sta COLUBK

So Stella only (correctly) executes what is defined by the game.

 

Not a glitch Tom, the red flash is intentional and happens when a meteor hit's your ion shields and gets vaporized!

 

I'm talking about the lags and display glitches that are not comming from the code; load the game on the real hardware and you will see it smoothly scroll the title screen. In Stella 4.7 you will see the smooth scrolling get interrupted by slight hesitations and glitches not connected to game events.

Link to comment
Share on other sites

Maybe try OpenGL mode (if you have the proper drivers installed). Some people have reported that OpenGL works better for them, even in Windows.

 

Also, make sure that v'sync is turned on. And if there's an inconsistent scanline count and/or not exactly 262 scanlines/60 fps, then the rendering will jitter from time to time. Sorry, there's no way around that one right now, at least until we can move to monitors that sync precisely to a rate set by the application (Gsync, etc).

  • Like 1
Link to comment
Share on other sites

Maybe try OpenGL mode (if you have the proper drivers installed). Some people have reported that OpenGL works better for them, even in Windows.

 

Also, make sure that v'sync is turned on. And if there's an inconsistent scanline count and/or not exactly 262 scanlines/60 fps, then the rendering will jitter from time to time. Sorry, there's no way around that one right now, at least until we can move to monitors that sync precisely to a rate set by the application (Gsync, etc).

 

The scanline count is a steady 262 except for a spike at the start of a new level.

 

I tried right clicking the Stella.exe process in task manager and giving it more power, first higher priority and then real time.

 

The issue almost completely cleared up with the real time setting - hesitations were present but now so infrequent not to affect gameplay or scroll smoothness, StarBlitz ran great with this setting! :)

 

It's possible to programatically usurp kernel mode if Stella needs more power; I'm running Stella on Windows 10 Pro (64-bit) with a powerful processor and lots of memory but I do have a lot of development tools and middleware on my workstation which could be causing the issue in lieu of code added since 4.1

 

Since no other Atari games are affected it looks to me like StarBlitz display engine (renders full screen animation 30 out of 60 FPS) is placing a larger load on your subsystems or just loading them differently than the other games do - the current MESS (now in MAME) Atari emulator breaks apart horribly running StarBlitz and was difficult to figure out (now you have to mount the SuperCharger BIOS first).

 

I think gamers like the Indieretronews crew would have a much better gaming experience with StarBlitz by running Stella as a realtime process:

 

http://www.indieretronews.com/2016/02/starblitz-defender-inspired-homebrew.html

 

I'm curious if you or Tom can also see the performance difference on your systems with Stella (default options) running the ROM in realtime mode?

 

Link to comment
Share on other sites

On my system (Linux), the display is very smooth using OpenGL (Direct3D not available in Linux). Note that since this is a 30Hz game, you should enable phosphor mode to eliminate some flicker that you might be perceiving as jittering.

 

On my system, the CPU usage is a little higher than other games, confirming that more work is probably being done in emulation compared to other games. But it's still in the 1% - 4% range, certainly nothing that will cripple the computer and cause slowdowns. Now, my development system is an Intel i7-6700K with 32GB RAM and Nvidia 750Ti graphics, so it's not exactly a weakling, and probably nothing emulation-related could affect it.

 

But I've tested Stella on much slower systems, and it didn't really start to have trouble until one got to 500Mhz or so, and then only with DPC+ games, which are also running ARM emulation too. The fact that giving it real-time priority helps indicates that something else on your system is competing for CPU time. And after all, the 2600 *was* a real-time system, which is very hard to emulate perfectly time-wise on a non-real-time OS.

 

EDIT: On my Windows test system (i3-4130 w/16GB RAM), I find that Direct3D works better than OpenGL, but again, this is a very powerful machine. Basically any machine made in the past 5 years is more than powerful enough for most emulators, and is complete overkill for Stella.

Link to comment
Share on other sites

On my PC, Stella is running at 1 or 2% CPU load, sometimes peaking 3%. I strongly doubt that anything can cause a slowdown here.

 

Stella 4.7, using OpenGL, Win7 64 Bit, i5-3570K @3.4 GHz using built-in GPU.

 

You're not using the default Direct-X setting most users use though.

 

Stella is using up to 18% of the 64-bit CPU (2 GHZ, 4GB RAM) before changing the process priority on my workstation and a bottleneck can be too transient to show in taskmanager or could be raised elsewhere; you could try upgrading to Windows 10 to see if that is part of it too (more subsystems).

 

Stephen, good point something else is competing for CPU time, I am running multiple database instances and related services that can compete heavily for the CPU but I'm not seeing this issue with other Atari games besides StarBlitz and some gamers (like the reviewer) are seeing it too with their systems while other gamers have great performance.

 

StarBlitz is pushing 12,000 playfield pixels of animation per second through the TIA whereas most Atari games render a relatively static playfield display.

Link to comment
Share on other sites

He says he's seeing 30Hz flicker. I wouldn't leap to the conclusion that he has the same issue as you. Many people find flickering the playfield objectionable.

 

No he's saying he sees flicker on the city and that it is sharp and hard on the eyes and causes fits or migraine headaches - those effects are limited to the animated playfield and go away when I escalate the priority on my system.

 

Can you see flicker? 30 frames of animation per second (encapsulated in 60) looks like smooth single pixel scrolling because most people are not capable of percieving the individual frames at that rate.

Link to comment
Share on other sites

Can you see flicker? 30 frames of animation per second (encapsulated in 60) looks like smooth single pixel scrolling because most people are not capable of perceiving the individual frames at that rate.

30 Hz ON/OFF is detectable. I see 30Hz flicker generally, and in this game specifically. I'm fairly flicker tolerant, but some find it more disagreeable. IIRC I made Random Terrain physically ill once with a 30Hz flicker test that featured a spaceship that flickered between 2 colors.

 

It's not the same thing as a 30Hz animation, though people can also tell the difference between 30Hz and 60Hz animation. Its not about being able to perceive any one frame.

Link to comment
Share on other sites

You're not using the default Direct-X setting most users use though.

Direct-X causes the same, very low load.

 

StarBlitz is pushing 12,000 playfield pixels of animation per second through the TIA whereas most Atari games render a relatively static playfield display.

For modern CPUs, 12k (or even 120k) pixel should be peanuts. icon_smile.gif
Link to comment
Share on other sites

Direct-X causes the same, very low load.

 

For modern CPUs, 12k (or even 120k) pixel should be peanuts. icon_smile.gif

 

Well in 3.x Stella's screen would tear apart badly trying to render this kind of display under the default settings despite running on modern CPU's. Modern code, can slow down modern CPU's. Direct-X is a powerful rendering engine written in asm but there still seems to be a delay stemming from the emu core.

 

There are plenty of Atari games that push 12k of playfield pixels per second to render a static image, but none pushing that much playfield animation (and tearing under 3.x or needing to run in realtime mode with 4.7).

 

I'd like gamers to have the best experience playing this game, it works great on real hardware and Stella supports the same programming technique when the ARM chip is used to animate an otherwise static display (like in Draconian) instead of the standard Atari chipset.

Link to comment
Share on other sites

There are plenty of Atari games that push 12k of playfield pixels per second to render a static image, but none pushing that much playfield animation (and tearing under 3.x or needing to run in realtime mode with 4.7).

12k per second means just 200 per frame. Lots of games are doing that. I suppose you mean 40*200 PF pixel/frame, right?

 

Even that is matched by quite some games, e.g. Thrust is moving ~180*40 PF pixels/frame while scrolling. And even original games scroll the whole playfield vertically (e.g. River Raid, Espial or the prototype of Xevious and Thwocker).

Link to comment
Share on other sites

12k per second means just 200 per frame. Lots of games are doing that. I suppose you mean 40*200 PF pixel/frame, right?

 

Even that is matched by quite some games, e.g. Thrust is moving ~180*40 PF pixels/frame while scrolling. And even original games scroll the whole playfield vertically (e.g. River Raid, Espial or the prototype of Xevious and Thwocker).

 

No 12,000 animated playfield pixels per second works out to 400 per frame with 30 frames of animation.

 

Those 400 pixels form 200 tile pixels - BoulderDash is the only Atari game with a comparable tilemapping engine and you and Andrew did the calculations in advance, not real time, not to mention using a much smaller CAM view (only part of the screen).

 

The 2600's architecture is tremendously flexible and allows for alot of creative programming; it's likely there is a bottleneck in Stella that was simply never encountered during design; with Stella 3.x, Stephen and I determined the bottleneck was the rendering code written in a high level language could not keep up so the screen would tear apart. Direct-X is written in asm but needs a precision feed from the client application to render 60 FPS cleanly.

Link to comment
Share on other sites

I cannot duplicate this 'bug', and I'm not entirely sure it's a bug at all.

 

In any event, there could be multiple issues going on. For a 60Hz image (standard NTSC, 262 scanlines), we have 16.67 ms per frame. So the emulation core has to 'do its thing' (ie, TIA creates image, etc) in this time, and send it to the screen. But the rendering to the screen itself is dependent on the size of the framebuffer (160x320 or so, insignificant on any recent machine), the rendering mechanism (Direct3D, OpenGL, software mode) and whether up-to-date, accelerated drivers are installed. These are two separate issues; is it the emulation core that is slow, or the output of the data to screen?

 

This can be narrowed down in various ways. You could modify your ROM to only do (say) half of the work that it's now doing. If you still see graphical issues, then it isn't the emulation that is slow, but the rendering side of things (which may have nothing to do with Stella). Furthermore, I could modify the source to not output anything on the screen, and if that shows an appreciable difference in CPU time, again we know it's rendering-related.

 

Also keep in mind that unlike other emulators, Stella does not (and cannot) have frame-skip to speed things up. Skipping a frame could cause collisions to be missed, etc, so it needs to be cycle-exact.

 

Finally, I don't recall saying that the rendering code was inadequate, only that OpenGL mode was better than software mode, and to use the former you need properly accelerated drivers. In the final analysis, it could be that a faster computer or graphics card is needed, but unless we're talking about 10 year old hardware, I really doubt it.

Link to comment
Share on other sites

I've done a little more testing, and cannot see any screen tearing on my work machine when using OpenGL mode. In software mode there is indeed screen tearing, but that is simply an artifact of how the OS renders software mode. This cannot be made any better, which is specifically why I state that Direct3D/OpenGL is what you need to be using, and software mode is for testing only. I believe another user on here (Keetah, I think) tests on an older system which has an i965 GPU, something from 2007 or so. And even on that old system, Stella using Direct3D/OpenGL mode works fine. So if the end user is using software rendering, either by choice or because they haven't installed up-to-date video drivers, then they could indeed see the screen tear and fall apart. But it would be the rendering causing it, not the TIA core.

 

For example, when I switch from OpenGL to software on my machine, the CPU usage goes from 1% to 6%, indicating that it is less efficient. But that is still well within the range of being efficient, but the screen does tear. This is because Direct3D/OpenGL use double-buffering and software mode uses single-buffering. In single-buffered mode, you will see screen tearing, smearing, etc. There is no way around this.

 

I will attempt more testing on slower computers using both Windows 7 and Linux, but I do not anticipate any different TBH.

Link to comment
Share on other sites

I've done a little more testing, and cannot see any screen tearing on my work machine when using OpenGL mode. In software mode there is indeed screen tearing, but that is simply an artifact of how the OS renders software mode. This cannot be made any better, which is specifically why I state that Direct3D/OpenGL is what you need to be using, and software mode is for testing only. I believe another user on here (Keetah, I think) tests on an older system which has an i965 GPU, something from 2007 or so. And even on that old system, Stella using Direct3D/OpenGL mode works fine. So if the end user is using software rendering, either by choice or because they haven't installed up-to-date video drivers, then they could indeed see the screen tear and fall apart. But it would be the rendering causing it, not the TIA core.

 

For example, when I switch from OpenGL to software on my machine, the CPU usage goes from 1% to 6%, indicating that it is less efficient. But that is still well within the range of being efficient, but the screen does tear. This is because Direct3D/OpenGL use double-buffering and software mode uses single-buffering. In single-buffered mode, you will see screen tearing, smearing, etc. There is no way around this.

 

I will attempt more testing on slower computers using both Windows 7 and Linux, but I do not anticipate any different TBH.

 

Stephen,

all excellent points, I am primarily interested in what is happening with the default config/install of the emulator if the user doesn't change any settings.

 

I just tried the 64-bit compatible build of Z26, version 2.16 using SDL:

http://www.whimsey.com/z26/

It hesitates badly with the defaults and to add a piece to the puzzle, black lines above and a part of the comb (which should never be seen in this game) materializes on the titlescreen when it resets (blue screens) after a game ends.

 

Changing Z26's timing to be tied to the monitor instead of the clock and then experimenting with the different video modes eventually yielded a combination that displayed the game perfectly (then I also had to turn off phosphor since it's on by default and blurs this game).

 

I did not change the thread priority, does Stella also have timing options?

 

It's a lot of fun to push the VCS but I wish the users could all get the optimium gaming experience with my games that use this technique right off the bat in emulation like they can with other homebrews and classic Atari games.

 

I wonder if I'm doing something in the calulation frames (the other 30 frames) that is causing the issue for emulators; I believe while the timing is a matching 262 the blank frames have a larger blank on the top or the bottom/different sized blanks/middle and/or one blank merged with the middle. It makes no difference to the real hardware; I use a sensitive JVC Television that demands a steady framerate and a modern Plasma display for testing.

Link to comment
Share on other sites

No 12,000 animated playfield pixels per second works out to 400 per frame with 30 frames of animation.

Ok, that's about the same as for Thrust, which also scrolls at 30Hz.

 

Those 400 pixels form 200 tile pixels - BoulderDash is the only Atari game with a comparable tilemapping engine and you and Andrew did the calculations in advance, not real time, not to mention using a much smaller CAM view (only part of the screen).

It makes no difference how the screen content is calculated. That's solely done by the 6507, which is emulated very easily for a modern CPU.

 

So that leaves the number of pixel changes per frame. You claim 400 PF pixel. This is about 20% of the screen changing. Which is matched by numerous other games. Even a color flickering background caused more pixel to change. And there is zero tearing to be seen on my computer.

 

Please provide a video, so that we can see the problem in reality. Maybe we can identify it then.

Link to comment
Share on other sites

Ok, that's about the same as for Thrust, which also scrolls at 30Hz.

 

It makes no difference how the screen content is calculated. That's solely done by the 6507, which is emulated very easily for a modern CPU.

 

So that leaves the number of pixel changes per frame. You claim 400 PF pixel. This is about 20% of the screen changing. Which is matched by numerous other games. Even a color flickering background caused more pixel to change. And there is zero tearing to be seen on my computer.

 

Please provide a video, so that we can see the problem in reality. Maybe we can identify it then.

 

400 PF pixels = 100% of the screen changing in this instance; no other pure Atari game is changing 100% of the screen 30 times per second because there simply isn't enough time in the upper and bottom blanks to do the calculations when they are all at the bit level (no byte pushing).

 

Please try z26 2.16 which illustrates the issue better with the default settings or MAME 1.7 (has MESS integrated) which completely tears apart. I think the emulators may have an issue with how the blank frame is constructed (still 262, but different).

 

Also Windows Pro is like Windows Server so there is definitely more contention for the CPU and less optimization for gaming applications with the OS, but Stephen is seeing the screen tear apart in software rendering mode on his setup while the other games still perform fine in that mode so there is definitely an emulator perf issue with my game design; can you see anything going on in the blank frame construction that is nonstandard??

Link to comment
Share on other sites

If I flicker the background color of a blank screen, this changes the complete screen. Do you experience tearing then too? If yes, try to enable VSYNC in Stella.

No, good thinking though. The games display engine has two kernels, if I turn off the animation kernel (that's the blank frame) the image becomes rock solid like any other Atari game. This is leading me to think (along with what I saw in the Z26 emu above) perhaps the frame construction for the blank frame may be quirky to the emulators, I remember padding it in odd spots to balance it to 262 with help from OmegaMatrix when it was oscillating.

Link to comment
Share on other sites

Without source code, I can only spot a minor bug in vertical sync: VSYNC is not enabled for 3 full scan lines.

I think this may only be for the very first frame on startup because initialization runs, VSYNC is then enabled right away in both kernels as you can see easier with the labels below:

 

I've attached the source code for these kernels also with my comments about padding wsync's in odd spots and the kernels frames being off from each other in construction.

 

StartOfFrame ;-----------------------------------------------

;------------------------------------------------------------

; PRIMARY KERNEL is now only called when the playfield scrolls across the virtual world:

lda scrollvirtualworldtoggle

beq DisengagePrimaryKernel

jsr framerelay ; PrimaryKernel - can do lots of calcs during a blank frame :)

; lda #0

DisengagePrimaryKernel

lda #0

sta VBLANK

lda #2

sta VSYNC ; vertical sync signal; initiate electron guns to upper left corner!

sta WSYNC ; 3 scanlines worth of vertical sync (so TV get's a lock on it)

sta WSYNC

sta WSYNC

lda #0

sta VSYNC ; vertical sync finished

 

framerelay

; not like this - lda $fff9; use Bank 1 (CBS RAM), point back to bank 0 before JSR

lda #0

sta VBLANK

lda #2

sta VSYNC ; vertical sync signal; initiate electron guns to upper left corner!

sta WSYNC ; 3 scanlines worth of vertical sync (so TV get's a lock on it)

sta WSYNC

sta WSYNC

lda #0

sta VSYNC ; vertical sync finished

 

vwBASIC_template.asm

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...