Drop Curtain Effect

[The Brew that is True]

When I startup a bin on the Stella Emulator, the screen slowly drops down, not unlike when a theater stage curtain comes down, or when the projection of a film begins while the movie screen is still being lowered.

 

I do not yet own a real 2600 so I am unable to test if this is emulating a physical 2600 phenomenon. 

And if so how does one code to prevent it.

 

Any insights appreciated.

 

I attached an example.

Match_Race_2600_baby_step_1.bin

[+splendidnut]

Stella's just emulating the initial screen roll that potentially happens on a CRT.  You can find that setting under Player/Developer settings:

 

https://stella-emu.github.io/docs/index.html#DeveloperVideo

 

[The Brew that is True]

3 minutes ago, splendidnut said:

Stella's just emulating the initial screen roll that potentially happens on a CRT.  You can find that setting under Player/Developer settings:

[snip]

Thank you! Much appreciated.

 

So if Stella is emulating something that could physically happen on a CRT (kudos to the Stella developers), I guess I need to think about coding around the physical phenomenon.

[+splendidnut]

It's really only something that happens on older TVs... most "newer" CRT TVs can catch sync within a frame.  You really only need to care about generating an appropriate VSYNC signal (3 complete lines of VSYNC enabled) and keeping the scanline count steady.

[+SpiceWare]

13 hours ago, The Brew that is True said:

if Stella is emulating something that could physically happen on a CRT 

 

If you're interested, you can read up on the initial jitter/roll routines in these 3 blog entries from 2015-2016:

• Overscan Jitter
• Overscan Jitter 2, DPC+ Jitter
• Jitter 3, Recovery Time

Jitter is what happens when the scanline count changes over time - if one frame outputs 262, the next 259, the picture would visibly jitter up & down. I wrote it because it was a common problem where people without hardware would write games that looked OK to them in Stella, but others would encounter jitter on real TVs.

 

Recovery Time is the addition of the screen roll, which occurs if the scanline count change is large.

 

Others have made updates to those routines since then to  improve them even more.

 

 

[The Brew that is True]

7 hours ago, SpiceWare said:

 

If you're interested, you can read up on the initial jitter/roll routines in these 3 blog entries from 2015-2016:

• Overscan Jitter
• Overscan Jitter 2, DPC+ Jitter
• Jitter 3, Recovery Time

Jitter is what happens when the scanline count changes over time - if one frame outputs 262, the next 259, the picture would visibly jitter up & down. I wrote it because it was a common problem where people without hardware would write games that looked OK to them in Stella, but others would encounter jitter on real TVs.

 

Recovery Time is the addition of the screen roll, which occurs if the scanline count change is large.

 

Others have made updates to those routines since then to  improve them even more.

 

 

Kudos SpiceWare, and thank you.

I will study those blog entries.

 

My hope is to code a game that resets/powers-up straight into live play so to speak.

 

As far as I can tell, once past the reset code and the first Vertical Synch Interval, my frames are consistently 262 scanlines at 60fps.

What remains, it seems, is to come up with a dependable way of getting through reset without causing screen roll.

If it turns out screen roll at reset is unavoidable, I at least want to wait out its passing before starting the game.

 

[alex_79]

The default when using developer settings is to have screen jitter set to high sensitivity and slow recovery time, because that makes irregularity in video timing much more evident, so that you notice them early during development.
I'm referring to varying video timing during the game. At power on that's inevitable, as you're switching from an unsynchronized video (the "snow effect" typically displayed by a CRT in absence of video input, where the electron beam retraces both horizontally and vertically when it reaches the maximum range allowed by that specific TV screen rather than in response to a horizontal or vertical sync pulse in the video signal) to a synchronized one.
Anyway, as @splendidnut said, most CRT TVs have much faster reaction times to varying sync, and will recover much sooner compared to Stella with default "developer settings".
And for people playing your game in emulation, they will typically use the default player settings (most of the time not even knowing about the options).

 

13 hours ago, The Brew that is True said:

My hope is to code a game that resets/powers-up straight into live play so to speak.

It shouldn't. Modern TVs (and often also the more recent CRTs e.g. from the '90s) typically blank the video (or display a blue screen) when not receiving sync pulses (e.g. when the console is powered off), and can take a few moments to display the image after starting receiving a valid signal. The game shouldn't power on directly into gameplay (that is, with a round already started), but wait for an input from the player before starting (typically a fire button or reset switch press).

 

 

[The Brew that is True]

12 hours ago, alex_79 said:

[...snip...]

The game shouldn't power on directly into gameplay (that is, with a round already started), but wait for an input from the player before starting (typically a fire button or reset switch press).

 

 

Thank you for the explanation.

 

Wouldn't a reset switch press typically be handled by a jump back to the reset code, cutting short the current frame, and possibly cause rolling all over again?

 

Are there games that just pause a short but "safe" amount of time after a soft or hard reset before automatically letting play begin?

 

Sorry if my questions seem naïve, the last time I played a video game was Pong at the Exploratorium sometime early 70s. 

 

Edited July 30, 2022 by The Brew that is True

[alex_79]

6 hours ago, The Brew that is True said:

Wouldn't a reset switch press typically be handled by a jump back to the reset code, cutting short the current frame, and possibly cause rolling all over again?

In my experience, most games don't do that, including the very early releases like "Combat", "Air-Sea Battle", etc. If you try them in emulation, you'll see that once the game is loaded the display is stable, and pressing "reset" doesn't cause loss of sync/ screen rolls.

 

6 hours ago, The Brew that is True said:

Are there games that just pause a short but "safe" amount of time after a soft or hard reset before automatically letting play begin?

There might be, I'm not sure. But I think it's better to keep the framerate stable and just avoid the issue completely, if possible. It looks better and more polished instead of having screen jitter/roll (or the "no sync" blue screen in modern TVs) each time you start a new round.

[The Brew that is True]

15 hours ago, alex_79 said:

In my experience, most games don't do that, including the very early releases like "Combat", "Air-Sea Battle", etc. If you try them in emulation, you'll see that once the game is loaded the display is stable, and pressing "reset" doesn't cause loss of sync/ screen rolls.

 

There might be, I'm not sure. But I think it's better to keep the framerate stable and just avoid the issue completely, if possible. It looks better and more polished instead of having screen jitter/roll (or the "no sync" blue screen in modern TVs) each time you start a new round.

Thanks, I'll look for disassemblies of "Combat" and "Air-Sea Battle" to study how they keep the frame rate stable during a reset.