Movie Cart

[+rbairos]

32 minutes ago, Thomas Jentzsch said:

I wonder if picture quality would improve if we keep the PF color active for the whole sprite area. So that we have no black gaps, but colored ones. This would increase color saturation, but also decrease contrast.

 

Here is my demo doing what I described.

 

movie_kernel_v3.bin 2 kB · 2 downloads

I thought about that, but it would make the content more transparent no?
Similar to overlaying a solid background transparency over the original content.


 

[+rbairos]

33 minutes ago, Thomas Jentzsch said:

That clearly indicates a coding error.

Given how little is my emulator kernel, I'm suspecting some type of uninitialized variable, or I'm probably reading into an adjacent array that is zero'd in debug but not production.
Still confused about the step-right issue.
 

[Thomas Jentzsch]

23 minutes ago, rbairos said:

I thought about that, but it would make the content more transparent no?
Similar to overlaying a solid background transparency over the original content.

That's what I meant with reduced contrast. Maybe it would help to reduce brightness of the PF colors, but still...

 

Anyway, I am still looking for a way to reduce the vertical bands and/or increase horizontal color resolution. That's why I came up with this idea.

[+rbairos]

1 hour ago, Thomas Jentzsch said:

That clearly indicates a coding error.

Yup, my OSD data array needed an extra blank line.
This is now part of the pull request.

(Couldn't reproduce the step-right issue, think it was user error, as I may not have been in timecode mode)
 

[JetSetIlly]

10 minutes ago, rbairos said:

Yup, my OSD data array needed an extra blank line.
This is now part of the pull request.

(Couldn't reproduce the step-right issue, think it was user error, as I may not have been in timecode mode)
 

The issue @Andrew Davie described with the Kong video is still present or is that what you mean by the step-right issue? If you just let the video play, without fast forwarding, the video breaks down towards the end.

[+rbairos]

4 minutes ago, JetSetIlly said:

The issue @Andrew Davie described with the Kong video is still present or is that what you mean by the step-right issue? If you just let the video play, without fast forwarding, the video breaks down towards the end.

I'm not sure about that.
It happens on gopher as well?
If it's always in the same spot, Im thinking something went wrong during encoding,
but not sure what yet.

[EDIT: Still happening for me, even with the OSD random pixels fix]
 

Edited September 12, 2021 by rbairos

[JetSetIlly]

15 minutes ago, rbairos said:

I'm not sure about that.
It happens on gopher as well?

 

No. It doesn't.

 

Two videos for comparison. Gopher2600 first

 

 

Stella

 

 

on edit: Gopher2600 without CRT filter for closer comparison

 

 

Edited September 12, 2021 by JetSetIlly

[+rbairos]

7 minutes ago, JetSetIlly said:

 

No. It doesn't.

 

Two videos for comparison. Gopher2600 first

 

 

First of all.
I know turning it into a video, blends alot of the jarriness back out, but holy moly looks great!

Okay, I'll poke around.
Im wondering if at that point in the encoding it was paused and restarted so there's two even (or odd ) numbered frames in a row, and I'm suddenly looking at the wrong buffer. Similar issues happened in the past.


 

Edited September 12, 2021 by rbairos

[JetSetIlly]

2 minutes ago, rbairos said:

First of all.
I know turning it into a video, blends alot of the jarriness back out, but holy moly looks great!

 

It does, doesn't it. I kept the window small and that helps but honestly it looks good "live". It's an excellent encoding algorithm.

 

2 minutes ago, rbairos said:

 

Okay, I'll poke around.
Im wondering if at that point in the encoding it was paused and restarted so there's two even (or odd ) numbered frames in a row, and I'm suddenly looking at the wrong buffer. Similar issues happened in the past.

 

Maybe. I set the oddField flag by looking at bit 0 of the fieldNumber value that is encoded in the movie file. It's a few months since I looked at that bit of code but from memory, I treated fields differently to how you did in Stella. So it's possible I've accidentally smoothed over the issue.

 

[+rbairos]

3 minutes ago, JetSetIlly said:

 

It does, doesn't it. I kept the window small and that helps but honestly it looks good "live". It's an excellent encoding algorithm.

 

 

Maybe. I set the oddField flag by looking at bit 0 of the fieldNumber value that is encoded in the movie file. It's a few months since I looked at that bit of code but from memory, I treated fields differently to how you did in Stella. So it's possible I've accidentally smoothed over the issue.

 

Yup thats definitely it.
When I swap what I'm looking at, first half goes bad, second half works.
Investigating.

[+rbairos]

12 minutes ago, JetSetIlly said:

 

It does, doesn't it. I kept the window small and that helps but honestly it looks good "live". It's an excellent encoding algorithm.

 

 

Maybe. I set the oddField flag by looking at bit 0 of the fieldNumber value that is encoded in the movie file. It's a few months since I looked at that bit of code but from memory, I treated fields differently to how you did in Stella. So it's possible I've accidentally smoothed over the issue.

 

Alright. Fixed!
716c14ecfc95b

Though the timecode is still garbled in that one.
Would have to try encoding with the same font.
What I'll do, is upload a version of the TouchDesigner encoder with the proper font attached.
 

Edited September 12, 2021 by rbairos

[JetSetIlly]

34 minutes ago, rbairos said:

Alright. Fixed!
716c14ecfc95b

Agreed.

 

On edit: For reference: Stella with fix.

 

Edited September 12, 2021 by JetSetIlly

[+Omegamatrix]

The picture is outstanding. Kong never looked so good!

[+Andrew Davie]

2 hours ago, JetSetIlly said:

 

on edit: Gopher2600 without CRT filter for closer comparison

 

 

That CRT filter sure seems to over-emphasises the vertical black lines between the sprites.

Maybe you could reduce the gap if you know the filter is on?

 

 

[JetSetIlly]

Just now, Andrew Davie said:

 

That CRT filter sure seems to over-emphasises the vertical black lines between the sprites.

Maybe you could reduce the gap if you know the filter is on?

 

 

Yeah. It's bilinear filtering to emulate ghosting. I have it set like by default so the separation in the Zookeeper bricks is nice and sharp.

 

You can scale the effect strength down. Here's another version with it set to the minimum.

 

[Thomas Jentzsch]

12 hours ago, rbairos said:

I thought about that, but it would make the content more transparent no?
Similar to overlaying a solid background transparency over the original content.

Another idea would be to use the missiles to fill the gaps. PF would be enabled all the time, but be hidden by the missiles between the sprites. So there would be no solid colored lines, but the missile colors would be the color of the nearby sprites (color might change during missile display), thus changing. 

I haven't done a demo for this yet, the solution will become quite tricky (e.g. missile movement and color change timings). Just wanted to ask first if you think it might work or not.

Edited September 13, 2021 by Thomas Jentzsch

[+Andrew Davie]

Here's another test-rendering. It's the Toy Story trailer.

https://www.dropbox.com/s/zl1nrar3syht3sn/toystory.mvc?dl=0

 

[+Andrew Davie]

15 hours ago, JetSetIlly said:

Additional idea: a single bit in the cartridge that indicates the orientation of the encoding. It wouldn't do anything on the hardware (except maybe an LED indicator) but it could be used by emulators to rotate the TV output automatically.

 

I'd also like to see the TV format/palette of the encoding included.  That is, perhaps 2 bits which indicate NTSC/PAL/SECAM.  Useless for hardware, of course, but very useful for an emulator to auto-switch the palette when playing a moviecart.

[Thomas Jentzsch]

44 minutes ago, Andrew Davie said:

 

I'd also like to see the TV format/palette of the encoding included.  That is, perhaps 2 bits which indicate NTSC/PAL/SECAM.  Useless for hardware, of course, but very useful for an emulator to auto-switch the palette when playing a moviecart.

Good idea! But SECAM movies on an Atari 2600...?  

[JetSetIlly]

2 minutes ago, Thomas Jentzsch said:

Good idea! But SECAM movies on an Atari 2600...?  

If the format is to include metadata then it should include the name of the movie too.

[Thomas Jentzsch]

1 minute ago, JetSetIlly said:

If the format is to include metadata then it should include the name of the movie too.

And other stuff as well (creator/director, artists, year/date, ...). Whatever fits.

[+Andrew Davie]

48 minutes ago, Thomas Jentzsch said:

Good idea! But SECAM movies on an Atari 2600...?  

Here is a short section in SECAM. If I release an actual binary, Stella would be contractually obliged to support
 

 

 

 

 

 

[+rbairos]

8 hours ago, Thomas Jentzsch said:

Another idea would be to use the missiles to fill the gaps. PF would be enabled all the time, but be hidden by the missiles between the sprites. So there would be no solid colored lines, but the missile colors would be the color of the nearby sprites (color might change during missile display), thus changing. 

I haven't done a demo for this yet, the solution will become quite tricky (e.g. missile movement and color change timings). Just wanted to ask first if you think it might work or not.

Anything but the intended color, I found in the past gave poor results in my simulations.
When I originally had 2 alternating columns, I tried filling the black columns with a solid average representative color. Results were poor, washing out the image.

However, given how great these recent background encoding + kernel changes turned out, I've started re-examining 4-kernel solutions, like the one you suggested earlier.

One in particular that might be easiest to implement is 

A. checkerboard   (like before)
B. inverse checkerboard (like before)

Then A + B again, shifted 4 pixels to the right.

I hope to have a simulation of this posted soon.
 

[Thomas Jentzsch]

Thanks for the feedback. Good that you have tested so many variations. Meanwhile I don't think the shifted approach will work well. The frequency of each pixel will be reduced to 15Hz, and I am not sure, if this can be compensated by the surrounding pixel. But I am curious about the result nevertheless. 

[+rbairos]

38 minutes ago, Thomas Jentzsch said:

Thanks for the feedback. Good that you have tested so many variations. Meanwhile I don't think the shifted approach will work well. The frequency of each pixel will be reduced to 15Hz, and I am not sure, if this can be compensated by the surrounding pixel. But I am curious about the result nevertheless. 

Okay, left side using 4 checkerboard patterns.
Right side uses 2.

However right away I see my ordering on the left is bad.
Some areas are lit up:  1,1,0,0,  instead of 1,0,1,0  causing a noticeable flicker.
I might try another test with your shifted +4 arrangement next.

At minimum you can see virtual bands of 4 pixels instead of 8:

(Also please ignore the brightness/coloring, which is off on this one).