Hi res picture on the vcs

[+Andrew Davie]

I get the feeling you misunderstood.

 

 

That's because you're not used to my warped sense of humour, yet.

 

I do like reading the good comments, of course, but there's little anyone could say or not say which would restrict my experimentation. I might go underground occasionally, though, especially if the trolls annoy me.

 

Ta for the kind words.

 

Cheers

A

[SmileyDude]

Now someone who came in at the very end of this thread would go "Wow holy cow that's incredible!"

 

Wow -- I think MegaManFan pre-quoted me... Andrew -- this is great stuff. I think I need to go out and build a cart so I can try this stuff out on the real thing

[Godzilla]

and now that ive seen the dacing baby in color, i KNOW 2600 dragons lair is possible!

[ElectricTroy]

ooops

[ElectricTroy]

 

 

Wow! Reminds me of C=64 porn! Except more blurry.

[Godzilla]

I think AD already posted that earlier in here? non?

[+rbairos]

Hello everyone.
I realize this thread hasn't been touched in 14 years, but Ive been spending a large amount of time trying to distill exactly what the technical conclusions are here.
Ive read the forum, Andrew Davie's excellent writeups and tried a few demo roms supplied by many here.


Is the following true?


The native Atari 2600 can display:

102 x 192 bitmap image
with one color change per scanline
at 60 fps.

That's based on the slideshow bin once posted.
Im not quite sure if that 60fps is wrong, and the resolution is based on multiple passes per image.

Ive simulated some animations, using a realtime editor + glsl scripts, testing out several ideas and would be happy to post the results, once my initial assumptions are verified.

Thanks very much!

Rob

[Video]

One color per scan line would run at 60-50hz if that's all you show, it'll drop to 30-25 if you do two and 20-16 at three. With three you can use red green and blue, and get through POV white yellow, orange and purple. It would make a nice 8 color image.

 

Horizontal resolution would be 48 with multiplexed sprites. Or 40 for bg image, or 8-16 for not multiplexing sprites. I suppose you could bump it to 96 if you did blinds, or flickered the whole image, but that drops the frame rate further, I think 20 is as low as I'd go, a 96x8color image would drop you to 10-8 hz

 

I've still got the Christmas cart from back then, its an awesome demo.

 

Is there any actual games that use this, even if just for a title screen?

 

I was looking forward to seeing it implemented in a game, as title, cut scene, or even gameplay, and followed FuKung till it appeared to drop off the radar, I believe a lot to do with the programmers desire to release it in ultra limited quantities, lack of custom artwork, and some other stuff. May have been unpractical too, at the time there wasn't 64+ k sized cart available.

 

I'd still love to see this technique in a game at some point.

[+SpiceWare]

At the start of last year cd-w figured out the TIA tricks required to generate a 128 pixel display, it was first seen in the 32 character text topic, prior 32 character text routines had pixel gaps in the middle, so couldn't be used to show reverse field text.

 

Due to how the 2600 works, the height is not limited to 192, it can be whatever physically fits on the display (so quite a bit higher on PAL). The above was done using DPC+.

 

 

Later in the year cd-w and I were working on BUS Stuffing and ported the 128 pixel display routine to it for some of the demos.

 

 

 

Using Chronocolour results in this, though it's quite flickery in person:

 

Lastly, cd-w figured out TIA tricks to generate a 96 pixel display with a color change every 8 pixels:

 

This display requires the use of BUS Stuffing.

 

[+rbairos]

Wow, these are fascinating advancements.
In simulations, using glsl and TouchDesigner, I wrote up dithering algorithms (both R,G,B) and 1-bit for movie clips, but the results were very poor.
Even though it was per-pixel random. (no moire patterns or other patchwork artifacts from small lookup tables).

I found switching to greyscale produced most acceptable results for viewing the video clips.
I tried both 3 pass (8 greys @ 20 hz) or 4 pass (16 greys @ 15 hz), with more success.

Im now wondering if one can draw 40 bit playfield + 40 bit sprite per scanline, since I realized late last night
I can reduce the 4 pass to 3 pass, and increase it to 19 greys, using the following chart I teased out in a search algorithm:

pass0 = (0,1,0,1,0,1,0,0,0,0,0,0,1,7,7,7,7,7,7);

pass1 = (0,0,2,2,4,4,0,0,2,2,4,4,4,0,0,2,2,4,4);

pass2 = (0,0,0,0,0,0,6,7,6,7,6,7,7,6,7,6,7,6,7);

That is, with a black background, and:
pass 1: playfield grey 1, sprite grey 7
pass 2: playfield grey 2, sprite grey 4
pass 3: playfield grey 6: sprite grey 7

Then I can generate 18 unique greys @ 20hz. (3 passes).
That's contingent on drawing 40 bits + 40 bits per scanline of course. (ideally higher )
The movie clips are passably recognizable at this 40 x 192 resolution @ 19 grey levels, especially with audio.

My simulation also extracts the audio from the movie clip, and normalizes it, by using a low-pass envelope.
It results in all sound having full dynamic range, one 4 bit value roughly every scanline.
Not exactly hi-fi, but keeps everything understandable.

The idea was to create a h/w movie playback cart. I have some ideas on this that may forego the use of fpga/fast processing since
I think the opcodes can be delivered in such a way as never requiring branches / non-sequential instruction order.
That is, I might be able to eliminate any need for full address decoding, the host processor should always know what the program counter will be.


I'll post links to the atari-ified movie clips shortly.

Cheers,
Rob.

Edited November 18, 2017 by rbairos

[+SpiceWare]

I tried both 3 pass (8 greys @ 20 hz) or 4 pass (16 greys @ 15 hz), with more success.

One thing to be aware of is the 128 pixel routine and the 96 multicolor routine are both already using 30 Hz flicker, so 3 passes for 8 grays really ends up as 10 Hz.

 

One thing that helps reduce the apparent flicker is to repeat each row of pixels twice, which halves the vertical resolution.

 

Galaga at 128x200:

 

Repeated rows, for Galaga at 128x100:

[+rbairos]

In my simulations, each scanline is out of phase with its neighbours to help reduce flicker.

My basic question though is:

-whats the maximum resolution that can be drawn per each scanline in one pass? (no gaps)
-can 40 playfield and 40 sprite pixels be drawn simultaneously in one scanline?

Thanks!

[+rbairos]

Here's a youtube upload of 4 test animations side by side.
You need to be playing at HD 60fps settings for the blending to work.
Degraded a bit after upload as well. Original simulations look crisper.
Also made a mistake where each pass of the 3 is on a different frame, instead of the same frame, causing some interlacing lines during motion. will fix

Top left is unattainable.
Hoping bottom left is possible in hardware: 40 bit playfield (single color) + 40 bit sprite (single color) each scanline.

Right side is single pass dithering filters I was playing with.

Rob.

Edited November 18, 2017 by rbairos

[+SpiceWare]

You can show a 48 pixel sprite and a 40 pixel background at the same time without any flicker. Where those 48 pixels appear has strict limitations though. Normally they're set to be in one group, commonly used for the 6-digit score display, though they can also be spaced apart as seen in the game Time Warp. That spacing is fixed, each group of 8 pixels that you can individually control is followed by a gap of 8 pixels that are off.

 

[+rbairos]

"Normally they're set to be in one group, commonly used for the 6-digit score display, "

Are they contiguous in that case?
Can they be double or quad width, or is it restricted to some fixed offset from first left fat playfield for example?

Thanks again for all your insight,
Rob.

[+SpiceWare]

For the typical usage the 48 pixels are contiguous. They can start anywhere on the scanline, as seen by the dragon in Dragonfire, though that starting position is not easily changed on subsequent scanlines.

 

that short black line in the green area is what happens when you reposition the players (done here to center the score).

 

 

The players (the sprites of the 2600) can be configured for one of the following display options:

0 = one copy

1 = two copies - close

2 = two copies - med

3 = three copies - close

4 = two copies - wide

5 = double size player

6 = three copies medium

7 = quad sized player

 

the 48 pixel routine works by setting both players to three copies (usually close). If you choose double or quad width you no longer get the extra copies, so only have 8 pixels for each player.

[+rbairos]

Right, I had assumed double or quad width was independent of the number of copies.
That being said, there's no way then to have the 48 pixels roughly span the 40 playfield blocks underneath them.
The most overlap you can achieve would be:

48 player pixels, overlapping with (48/4 = 12 playfield pixels).
And those overlapped 48 pixels, cover (48/160) = 30% of the screen.

So in my movie cart scenario, the two options would be either:

A) middle 30% of the screen: 48 pixels x (64 roughly), 3 passes/20hz, pseudo 19 grey levels.

or

B) full screen, 40 pixels x 192, 4 passes / 15 hz, 16 grey levels.

Every step of this involves carefully weighed artistic compromise. Maybe thats why its so addictive.

Cheers!

[+rbairos]

Actually Im going to explore the 96 + color change every 8 pixels you mention above using bus stuffing.
Can I assume that each scanline in that format, uses 12 cells of 8 pixels. Where each cell is 2 colors (black + specified color)
(Running interlaced at 30hz).
Reminds me of graphics on the Adam/Coleco with 8 pixel cells, and color bleed.

Thanks.

[+SpiceWare]

Just be aware that Bus Stuffing doesn't work on all systems.

[+rbairos]

Question, the 96 x 192 mode (with color change every 8 pixels).
I realize its interlaced, but for those interlaced lines, is there enough cycles to set the background color, once for each of those black lines?
ie: can I have a solid custom colour for each blank line instead of black?

[EDIT: Actually this won't help my example]

Edited November 19, 2017 by rbairos

[+rbairos]

Okay, Ive made another test clip. Been a bit obsessed with this format this weekend.

It's 96 x 192 interleaved.
Floyd-steinberg dithered, but selects an atari-2600 palette colour every 8 cells.
Also increased contrast.

From across the room, it actually looks pretty recognizable.

The important part of this setup, is that all colouring is done on the original 2 interleaved fields, so it still 30hz.

Be sure to set youtube playback to HD 60 fps to avoid interleave flicker.

Not applying the coloring, seems to allow for slightly more detail.
Something for the color/bw console switch

Any feedback appreciated.
Rob.