has anybody made a hi-res game?

[Wookie]

So I noticed that sometime in the last 5 years, programmers figured out how to make the 2600 generate an interlaced signal which effectively doubles the vertical resolution of the 2600. Has anybody created a game the uses the "hi-res" display capabilities?

 

I've seen the demos both on real hardware and the z26 emulator. Are there any games?

 

-wookie

[accousticguitar]

Isn't Starmaster high res?

[Thomas Jentzsch]

No, I don't think so.

 

The vertical resolution is already almost twice as high as the horizontal one, so doubling that makes little sense IMO. And you need more memory and it flickers.

[SeaGtGruff]

The vertical resolution is already almost twice as high as the horizontal one, so doubling that makes little sense IMO. And you need more memory and it flickers.

I'd think it shouldn't flicker any more than regular standard-def TV, since reg SD TV is interlaced anway. But it flickers more compared to the standard 2600 screen, since that isn't interlaced. However, on modern HD TVs the results may vary depending on how the TV handles a 480i picture signal. On my 1080p HD TV a 480i picture is apparently displayed as 480p, so there's no perceptible flicker-- but it also automatically displays a 240p picture as 480p, so interlacing doesn't add any advantages. If I flicker between two different 240p frames, I still get a 480p picture. The only disadvantage I can see is that when there's rapid motion or a quick scene change I may briefly see an apparent "tearing" of the picture (not sure if that's the right word) where the 240 lines of the old scene is interleaved with the 240 lines of the new scene. This seems to be most apparent when I'm watching a DVD of a cartoon-- I suppose because the colors are so vibrant or "basic" so it's more obvious that the fields of two different frames have been combined together.

[RevEng]

... when there's rapid motion or a quick scene change I may briefly see an apparent "tearing" of the picture (not sure if that's the right word)

 

It's usually called combing or feathering.

[+Gemintronic]

The laymen call it "annoying"

[Tjoppen]

I did some minor investigations on interlaced effects, but nothing came of it. For me it's not really worth it - horizontal resolution is the issue anyway

[Phredreeke]

No, I don't think so.

 

The vertical resolution is already almost twice as high as the horizontal one, so doubling that makes little sense IMO. And you need more memory and it flickers.

 

In the best case scenario, horizontal player resolution is half the vertical resolution. The playfield horizontal resolution is something like 1/8 of the vertical resolution.

 

Also, keep in mind that for the longest time after Atari 2600 consoles still used a non-interlaced display. The Megadrive/Genesis and SNES could display an interlaced picture but the only Megadrive game I can think of that uses it is Sonic 2 for the versus mode, SNES games generally only used the interlaced mode for menu screens. It wasn't until the Dreamcast that using full interlaced resolution became standard and even on the PS2 a few games ran in non-interlaced mode (Ico comes to mind)

[roland p]

Do emulators support interlace?

 

It might be useful if you want a very smooth and slow vertical scroll. You could scroll one scanline each field. The scrolling speed would be 50% of the non-interlaced version.

[Phredreeke]

Generally when working with interlaced video you don't want to scroll vertically at odd number of pixels/field as it effectively undoes the interlacing. It could work but as it has been said, you already have twice the resolution vertically as you do horizontally.

[potatohead]

When using just the native CPU, there isn't enough time to really take great advantage of interlaced.

 

But, what about the ARM in the Harmony? Seems to me, sprites could be interleaved on a scan line basis for more visibility more of the time. Maybe it's not about effective resolution at all. A game produced at 25 or 30Hz, using interlaced display could trade per object flicker, for per scan line flicker, while keeping the 100 or 200 pixels or so vertical positioning and or detail resolution. (Two normal scan lines, becomes four, with part of a sprite always visible on one or the other, or both where there is no overlap.)

[SeaGtGruff]

Do emulators support interlace?

 

It might be useful if you want a very smooth and slow vertical scroll. You could scroll one scanline each field. The scrolling speed would be 50% of the non-interlaced version.

z26 supports interlaced displays, but Stella doesn't yet.

 

I should think the vertical scrolling would work as you describe-- but as has been pointed out, the vertical resolution is already higher than the horizontal resolution, so I don't know if there'd be any real advantage to it. Still, it would be a nice experiment.

[SeaGtGruff]

When using just the native CPU, there isn't enough time to really take great advantage of interlaced.

I don't understand why it would be any more time-consuming than using flicker. The vertical blank routines between each field would focus on whatever's needed for the upcoming field-- including anything that needs to happen on every field. As far as interlaced sprites, all you'd need are two different data tables, one for the "even" lines and the other for the "odd" lines. But they might be swapped around on the fields depending on the sprite's vertical position.

 

But, what about the ARM in the Harmony? Seems to me, sprites could be interleaved on a scan line basis for more visibility more of the time. Maybe it's not about effective resolution at all. A game produced at 25 or 30Hz, using interlaced display could trade per object flicker, for per scan line flicker, while keeping the 100 or 200 pixels or so vertical positioning and or detail resolution. (Two normal scan lines, becomes four, with part of a sprite always visible on one or the other, or both where there is no overlap.)

But that's what's already going on with "intelligent flicker," the only difference being that the flickered objects occupy the "same" scan lines rather than being drawn between each other's lines.

[potatohead]

That's the point! If they are drawn between, there is more overall visibility. The flicker is distributed, and multi-plexers take a lot of time. Look at Space Rocks, which is capable of a lot of objects for that exact reason. Sorting and then managing the limited display eats a lot of cycles.

 

There is just flickering always. Objects are drawn every other frame, allowing for multiple objects, and it's consistent.

 

SImpler games flicker entire objects. Either it's displayed, or it isn't. Two objects sharing the sprite flicker at 30Hz, and that can be very easily seen. There is a significant difference between flickered objects and not.

 

More complex efforts flicker only scan lines that overlap. The shared vertical space two objects occupy flickers at 30Hz, with the rest of it being displayed every frame. The flicker is smaller, and more edge cases are possible. IMHO, this is optimal and the most well tolerated, but the other two methods are perfectly reasonable, depending on what is happening, sizes, colors used, etc...

 

With the interlaced display, more cases are possible, particularly on sprites that have double line resolution. Some part of them is always visible, or the number of things on screen can increase, one or the other.

 

Now that I think about it, objects could have vertical resolutions that are in between the usual 1 or 2 scan lines, say 130 or so vertical position elements. On some displays, that's still pretty close to a square looking pixel that matches up nicely with the color clock resolution possible horizontally.

 

Anyway, no pressure. The OP asked something interesting, and it triggered an idea or two, that's all.

[roland p]

I found a demo that seems to work in z26.

I had to set Line-mode to interlaced.

Interlacing Game (19-08-2002) (Billy Eno).a26

Edited July 16, 2012 by roland p

[Thomas Jentzsch]

Lets not forget that interlaced graphics won't work well for PAL, since there the color signal is constructed out of two lines. So if you display a sprite only every 2nd line it can have no color.