Manual Flicker Optimization

[Mr SQL]

I just loaded The Empire Strikes Back in Stella, and if you start the game, then tap the left arrow key 4 or 5 times, the playfield at the bottom seems to scroll pretty smoothly. Go full speed and the mountains at the top scroll smoothly. I turned on debug colors mode in Stella and they don't seem to be using the ball or anything else, so I don't know why the playfield seems to scroll so smoothly at certain speeds.

 

Cool observation RT, I just gave it a try too. The mountains do scroll smoothly at top speed but there are jarring breaks in the smoothness when a lot of other stuff is happening at once.

 

The game has two different scroll rates, it's a very cool effect but both have some jaggies when scrolling at smooth speed.

 

The reason for the smoothness is a scrolling speed of 20 FPS or more, 30 FPS is like watching a Television shows pan the camera - move an object in regular increments 20 or 30 times a second and it's going to look super smooth.

 

Empire Strikes Back is an awesome game, I didn't look at the debugger.

[Mr SQL]

Round two,,, Fight!!!

Fight only in Tournament Trinity!

 

The Kumate is March 28 for any programmers with code to back up their talk.

 

[potatohead]

 

I tend to divide the signal just as the manual describes so I can do more with it.

Here are the facts:

 

NTSC offers interlaced and non-interlaced video. For an interlaced signal, even scanlines are on one field, odd scanlines are on another field. Each field is 30hz. The vertical distance between the scanlines in any given field is spread out, so that the scanlines from the following field can fall between them. This results in a picture with ~400 scanlines, and one full frame of information every 1/30 second.

 

NON INTERLACED signals only consist of ONE FIELD. The FIELD is the FRAME, and the resulting FRAME is 1/60 second, or 60FPS. What happens to the scanlines? They are just farther apart, with a little gap there, where the interlaced ones would go. Since there is no interlacing, no scanlines go there, the image is stable, each FIELD landing on top of the prior one, and there are only ~200 scanlines.

 

Most significantly, those scan lines do not occupy more vertical space. On older devices, cranking up the brightness and or contrast does result in "blooming" that does fatten up the scanlines a bit, but it's not enough to close the gap that is there. An INTERLACED signal will still display a lot more information. A NON INTERLACED signal, again like the one the VCS outputs, simply outputs scanlines spread out enough to cover the display every FIELD, and those are farther apart on the screen by necessity.

 

You said (again for reference) " I tend to divide the signal just as the manual describes so I can do more with it."

 

And others here are telling you that when you do that, your images flicker as they are only displayed every other FRAME, due to a FIELD being a FRAME in the NON INTERLACED signal generated by the VCS.

 

There are no free lunches.

 

On a VCS, if you do not draw an object every single FIELD, it's going to flicker on a CRT type display. It may appear dimmer on some LCD type displays, and it will nearly always flicker on a Plasma display. (those are fast, like CRT displays are fast) Further, the motion of said object will be limited to 30Hz of motion. Both of these effects will be easily seen, and many VCS users dislike them, though they will tolerate them due to machine limits.

 

It can be confusing too! I have one LCD TV and one LCD VGA display that happens to correct the VCS flicker! Games that I know flicker, such as PAC MAN, don't on the LCD TV. They do on every other device I've ever owned. While this is cool, it's an artifact of the video signal processor in the display, not some way to get more out of a signal that we all know cold for 30 years plus.

 

When you do draw an object every field, that object won't flicker. Further, it's motion will be 60Hz motion. MANY, MANY games do this. BTW, another example of a game that animates at 60Hz both in terms of motion and object shape is KABOOM! That one is fast, and it employs the NON INTERLACED signal to the max! The entire game is frame locked, 60Hz motion (object position), 60hz animation (object shape). The little bomb flicker is an example of animation, and the movement of everything else is an example of 60Hz motion.

 

All that said, if you really want or need to draw things at 30Hz, do it! Just don't equate it to things drawn at 60Hz as the effects seen by the users, motions possible, etc... are very different. And when you do it, be aware that some users just won't find it acceptable. Them's the breaks.

 

You aren't getting anything that others aren't getting out of the signal. Those limits were set years ago, and the parts of the manual that talk about 30Hz and FIELDS "to get more" on the screen do so in full recognition of the flicker described repeatedly on this thread.

 

None of this is a slight on any code you've written. It is rational fact.

Edited March 8, 2016 by potatohead

[potatohead]

One more thing, yes! TV is 30Hz. A unique frame of information is presented to the user 30 times per second. However, that frame consists of two fields, each 1/60 of a second. Artifact free motion happens at 30Hz, and that's required so that both fields get a chance to display the object fully. Motion that exceeds 30Hz, say 40, 50, 60Hz, will show tearing and object shape distortion due to the object position being different in the individual fields. Two of those are required for a complete display of the object. The result of motion faster than 30Hz on TV is the viewer never really sees the entire object in one place. The display isn't fast enough.

 

All of this is due to INTERLACED signals.

 

The VCS does not output INTERLACED signals. This means, it's motion is 60hz, twice as fast as TV broadcasts are. Again, go look at KABOOM! That's a 60hz game, and it uses that to the maximum effect too.

[alex_79]

One more thing, yes! TV is 30Hz. A unique frame of information is presented to the user 30 times per second.

Standard definition transmission shot on video (stored on tape like Betacam or Betacam SP) were natively recorded in interlaced mode (that is 60Hz motion). Each field was captured every 1/60th of second. Two consecutive fields were not part of the same still image.

News, documentary, sport events, low budget soap-operas, advertisings are some of the content shot in this way.

Also consumer camcorder (VHS, DV, miniDv, etc) worked in this way before HD and progressive display became common.

 

On a CRT you don't really see the combing artifacting with 60Hz motion, because you don't see both fields at the same time but 1/60th of a second apart (exactly like you do on the Atari progressive display). The effect is that you perceive double the resolution with static images (when the two fields are effectively part of the same still picture), while motion looks fluid but at reduced vertical resolution (a bit blurred, maybe, depending on the the individual persistence of vision, but not like in the combing-artifacting where you show the two fields combined at the same time. That only happens if you import an interlaced video on PC without any deinterlacing filter).

 

Movies and other content shot on film, which is progressive by definition (a series of still pictures at 24fps), are converted to video through telecine. Here effectively two fields in the resulting video belongs to the same frame in the original film. (Wel at least in PAL, in NTSC additional frames are needed to keep the right speed and in those cases each field comes from different frames of the original film. See Three-two pull down).

 

It's not difficult to tell if a TV transmission (in SD and on a CRT) was shot on film or video by looking at moving scenes. The first shows slightly more "jerky" movement but with a constant perceived definition, while in the latter motion is more fluid but less defined.

Edited March 8, 2016 by alex_79

[Mr SQL]

 

Most significantly, those scan lines do not occupy more vertical space. On older devices, cranking up the brightness and or contrast does result in "blooming" that does fatten up the scanlines a bit...

 

All that said, if you really want or need to draw things at 30Hz, do it! Just don't equate it to things drawn at 60Hz as the effects seen by the users, motions possible, etc... are very different. And when you do it, be aware that some users just won't find it acceptable. Them's the breaks.

 

None of this is a slight on any code you've written. It is rational fact.

 

potatohead,

I agree with this and most of what you've posted. If anyone else can do fluid scrolling animation at 60 hz let me see it; imo it requires the dumb terminal technique which can leverage 60 hz with the ARM, but I don't see how you're going to do it on the Atari.

 

The output on the vader is already cranked up; I didn't turn up the luma, contrast or chroma hence the scanlines are fatter as you explained. A composite mod tends to ruin this.

 

Who would argue that 30 hz is equal to 60 hz? There already have been experiments proving the 60 hz Atari signal is more stable than 30 hz NTSC (no free lunch). And kaboom doesn't scroll so it's no problem to do it at 60 hz. I've seen incorrect arguments that NTSC broadcast is at 60 hz because of the fields but that's not the screen.

 

Alex,

you've ignored my last reply; I'm not disagreeing with anything you say here I'd just like to see you post an example of your code or someone elses code that scrolls super smooth. I only see demo's so far, is there another game or were those hypothetical?

[Trinity]

Fight_in_tournament_only.png

Fight only in Tournament Trinity!

 

The Kumate is March 28 for any programmers with code to back up their talk.

 

Hahaha!

 

I was thinking of this though,

 

[roland p]

BallBlazer has awesome effects, your latest release looks very solid

Thanks!

 

The 30 hz in StarBlitz only seems outrageous to a couple of programmers, most folk like the display as you did.

Well, while the effect is interesting I would still advice against using a black frame every other frame. And since you scroll 2 pf pixels at a time, you could scroll 1 pf pixel every frame at 60fps and have a smoother motion. Win-win! Edited March 8, 2016 by roland p

[alex_79]

I just loaded The Empire Strikes Back in Stella, and if you start the game, then tap the left arrow key 4 or 5 times, the playfield at the bottom seems to scroll pretty smoothly. Go full speed and the mountains at the top scroll smoothly. I turned on debug colors mode in Stella and they don't seem to be using the ball or anything else, so I don't know why the playfield seems to scroll so smoothly at certain speeds.

That's because the playfield can't move like the sprites and the only way to make it look in movement is to change the bits in it's graphic registers so that it appear to shift in one direction. By doing so you're limited to movement which are equal to the playfield pixels, and those are 4 color clocks wide (a color clock is the smallest "pixel" the 2600 can display, and that's equal to 1 pixel of a player sprite at normal size).

 

If you have a static playfield and a moving player, you can move the player with 1 color clock resolution (even if the player itself is displayed at 2x or 4x the size). You can use fractional values in calculating the position of the sprites, but you can only display the integer part That is, if you want the sprite to move 0.5 color clocks per frame, the results is that it will actually move 1 color clock every 2 frames. That's look quite good on screen.

 

If you want to show the same relative movement (0.5 color clock per frame) by using scrolling, that is with a stationary player and moving playfield, the result is that you shift the playfield graphics by one pixel every 8 frames. That looks pretty jerky (it's like a 7,5 fps animation).

 

Playfield scrolling at 2 color clocks per frame (1 pf pixel every two frames) start to look nicely smooth, in my opinion (In ESB, when you are at full speed, the mountains scroll steady at 1 PF pixel every other frame, while the ground at 1 PF pixel per frame).

 

ESB doesn't use any advanced trick to draw the display: The speeder is P0, the walkers are P1 (at 4x size), M0 and M1 are the shots for player and walkers, the ball is used for the "bomb hatch", playfield for ground and mountains. All the graphic objects are used and displayed at the same time, no flicker whatsoever and the parallax scrolling is a nice touch. 60fps of colorful fun!

[Mr SQL]

Thanks!

 

Well, while the effect is interesting I would still advice against using a black frame every other frame. And since you scroll 2 pf pixels at a time, you could scroll 1 pf pixel every frame at 60fps and have a smoother motion. Win-win!

 

RT brought up good question earlier related to this problem:

 

30 FPS of animation is television smooth, that's so smooth it's indistinguishable from fine pixel scrolling - in fact if we could scroll in 1 px increments at 240 fps instead of 8 px increments (2 playfield pixels) at 30 fps it would look to scroll no more smoothly.

 

I think it would be better to use single pf scrolling to effect multiple smooth variable scroll speeds.

 

With single pf (4 px) scrolling instead of 2 pf at a time, the engine could support two super smooth scroll speeds.

 

The problem here is we can't move in increments less than 4 px (aside from very cool experimental methods to do just that) so while I can scroll just as smoothly at 1/2 speed using 1 pf pix instead of two. I cannot drop the speed again without getting jagged scrolling like happens when ESB slows down the rate (Alex I think you mistake hz for fps).

 

If I could get my engine running at 60 hz there would be no need for flicker optimization but 60 fps is overkill, I still wouldn't want to do 60 FPS; Television shows how smooth 30 FPS of animation is.

 

High speed animation is also another optimization for conservative flicker not covered in the manual.

 

[Mr SQL]

Had a chance to try Empire Strikes Back on the real hardware - at top speed it was super smooth at 30 FPS (1 pf pixel every two frames) for the top and too fast for the eye to follow on the bottom at 60 fps (1 pf pixel every frame). There were no jarring breaks at top speed - that only happened in Stella.

 

It appears ESB is another game besides StarBlitz, and a classic, that flies apart in Stella on Windows 10 but runs fine on Windows 7.

 

Pretty cool there is another super-smooth scrolling game - and interesting that it also cannot be emulated; imo that's a really bad bug not being able to play smooth scrollers without jittering and hesitating.

[Mr SQL]

Hahaha!

 

I was thinking of this though,

 

 

The potty talk programmers have found the author of Empire Strikes Back!

They're upset he broke the emulator.

 

Compete in Tournament - write code, put the talk in the comments

 

My Super-smooth entry is 86 bytes with comments (compiled).

 

Easy to put on aires too, but not so easy to scroll smoothly, sculpt with phospor or leverage artifacting techniques like we did it back in the day.

[Mr SQL]

 

OK, thanks. So you were paraphrasing. That's why I couldn't find anything.

 

RT,

maybe you can help explain this one to me:

 

What are pm's threatening to "increase the potty talk" even supposed to mean?

 

More potty talk team reviews or more team programming efforts?

 

I think Jentzsch is an excellent programmer and prefer when he teams up with a programmer from the 80's who can write smooth scrollers.

 

I prefer friendly Spice to potty talk Spice and ditto for friendly Jentzsch. I'm pretty sure RevEng is 12 years old so he get's a pass but they should endeavor to mentor him and inspire; I like having inspired Spice to implement the dumb terminal work I've pioneered, great implementation too!

 

I think ignore is OK but then that can't mean more potty talk, victory laps and drive-by posts; only solidcorp deserves that for making an incredible version of Star Castle run in 8K:

(StarCastle running in 8k).

[+Random Terrain]

RT,

maybe you can help explain this one to me:

 

What are pm's threatening to "increase the potty talk" even supposed to mean?

It might mean that someone is going to call you some really bad names in public, but then Albert would ban the person, so I doubt it.

 

All I know is the mountains in The Empire Strikes Back game is smooth without hurting my eyes at the fastest speed, so if I ever make a scrolling game, I'll try to make it look like that. (The ground in The Empire Strikes Back looks like crap at the fastest speed, so I'll avoid doing that.)

 

One of these days, I'll see if I can make a very simple Defender-ish scrolling example program for the batari Basic page and try to make it scroll as smoothly as the mountains in The Empire Strikes Back.

[Kiwi]

The main difference is Empire Strike Back uses symmetrical playfield while your projects uses asymmetrical playfield which requires more CPU power to draw those playfield blocks while handing the other 5 on screen objects. It couldn't keep the screen on because it is writing playfield data to RAM in one entire frame with no game code running also need to keep the screen stable too, and then display the changes in the following frame while running the game code.

[Thomas Jentzsch]

The CPU power for drawing the asymmetrical is required during the kernel, so that's not deducting any cycles from the game logic.

 

The key problem is that you have to move a lot of memory between two frames. But this can be quite easily done (even with slow SuperCharger-RAM) within Overscan and VBlank. IIRC my Paradroid demo moves all the required SC-RAM in Overscan only.

[Mr SQL]

All I know is the mountains in The Empire Strikes Back game is smooth without hurting my eyes at the fastest speed, so if I ever make a scrolling game, I'll try to make it look like that. (The ground in The Empire Strikes Back looks like crap at the fastest speed, so I'll avoid doing that.)

 

One of these days, I'll see if I can make a very simple Defender-ish scrolling example program for the batari Basic page and try to make it scroll as smoothly as the mountains in The Empire Strikes Back.

 

Awesome project RT, it would be cool to see more BASIC smooth scrollers.

 

 

The main difference is Empire Strike Back uses symmetrical playfield while your projects uses asymmetrical playfield which requires more CPU power to draw those playfield blocks while handing the other 5 on screen objects. It couldn't keep the screen on because it is writing playfield data to RAM in one entire frame with no game code running also need to keep the screen stable too, and then display the changes in the following frame while running the game code.

Good assessment Kiwi! I might find enough cyles in the blanks to do the 30 fps at 60 hz instead of 30 hz by only updating the bottom six rows instead of all 10 rows of tile pixels.

 

The CPU power for drawing the asymmetrical is required during the kernel, so that's not deducting any cycles from the game logic.

 

The key problem is that you have to move a lot of memory between two frames. But this can be quite easily done (even with slow SuperCharger-RAM) within Overscan and VBlank. IIRC my Paradroid demo moves all the required SC-RAM in Overscan only.

 

Cool demo! Maybe I will create a custom 60 hz version of the runtime for StarBlitz updating just the bottom 1/2 the playfield screen but I actually wanted everything specifically at 30 hz in this game for the subliminal effect

 

Currrently I am updating the whole playfield screen with a soft-blitter with horizontal and vertical scroll registers surfaced to the BASIC, 400 blitter operations per frame or 12,000 pixels/second. Probably doesn't help that I am decompressing the video RAM on the fly as well, I left the RAM doubler in place from the CBS RAM version.

[Mr SQL]

StarBlitz_60hz_Beta2.bin

 

Some really interesting effects on different display setups, not sure what ot make of all of them, some thoughts on the different displays I've tried:

 

It has an interesting artifacting effect all it's own on CRT; reminds me of the way 30 hz StarBlitz artifacts on Plasma as a side effect of the deinterlacer (blank frame) - gradiations and detail within the buildings, but the effect is gone on the plasma now, the deinterlacer is degrading the display a bit.

 

imo it's not quite as smooth on real hardware with NTSC or as easy to see because of too much phosphor, and the hypnotic 30 hz effect is lost (there's a lot of interesting research on the 30 hz effect and amplifying it without the alternating field).

 

On the technical side I am scrolling just three rows of the playfield in the top blank and two more rows in the bottom blank (couldn't fit 3) for a 1/2 height 60 hz 30 fps display - both bands can scroll the playfield at different fps, different speeds and different directions; the ideas on this thread and the advanced smooth scrolling thread were inspiring, I'm planning to surface band registers to vwBASIC as an option to put the bands anywhere on the screen at 60 hz instead of full screen 30 hz animation.

 

Here's a previous beta that shows both bands because they were offset by one tile pixel:

StarBlitz_60hz_Beta.bin

[Kiwi]

One other way to avoid full screen flickering is double buffering. One screen stay on one bank of SC RAM, run game while building the pieces by pieces of the new screen on another bank of SCRAM. When that screen finish building in that bank of RAM, move the pointer to that bank and start building a new screen on the old screen RAM.

 

I had to do that with Colecovision version of Flappy Bird to avoid having the pipe flickers. I build the background across 3 frames, and then draw a pipe per frame and then display it.

 

<- click to animate

The first half of the gif shows the flickering pipe due to drawing on one screen, and the other half shows it drawing on the other screen and then displaying the finished screen.

I would avoid full screen flicker and keep the flickering to the small screen elements.

[Mr SQL]

One other way to avoid full screen flickering is double buffering. One screen stay on one bank of SC RAM, run game while building the pieces by pieces of the new screen on another bank of SCRAM. When that screen finish building in that bank of RAM, move the pointer to that bank and start building a new screen on the old screen RAM.

 

I had to do that with Colecovision version of Flappy Bird to avoid having the pipe flickers. I build the background across 3 frames, and then draw a pipe per frame and then display it.

 

FlappyBirdexample.gif <- click to animate

 

The first half of the gif shows the flickering pipe due to drawing on one screen, and the other half shows it drawing on the other screen and then displaying the finished screen.

 

I would avoid full screen flicker and keep the flickering to the small screen elements.

 

Nice port! You are animating every 3rd or 4th frame?

 

StarBlitz display is built and double buffered at 30 fps weather running at 30 hz or 60 hz.

 

The 30 hz version builds and double buffers one frame of animation per physical frame. The 60 hz version doubles up the frames so it's also 30 fps, but the doubled frame is static, just reusing the buffer. This gives me the time to run the game.

 

StarBlitz has no time to run the game logic during the double buffered animation frame, it can only build the display. The static frame has all of the game logic because the VCS has only enough power to display a static playfield image that size while also running game logic - your earler observation was right on

 

With the 30 hz version it's less obvious because there isn't a second frame to be seen when the game is played on a real Atrai, not even with a modern interlaced display.