Jump to content
IGNORED

Movie Cart


rbairos

Recommended Posts

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.

 

image.thumb.png.6af6bbea0ee6b70f2ec4e0314a30aad6.png

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.
image.thumb.png.c794dfdc4bf81cdb4361088543d434b3.png

 

  • Like 1
Link to comment
Share on other sites

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.
 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)
 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by rbairos
Link to comment
Share on other sites

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 by JetSetIlly
  • Like 1
Link to comment
Share on other sites

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 by rbairos
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by rbairos
  • Like 2
Link to comment
Share on other sites

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?

 

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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 by Thomas Jentzsch
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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...? :D 

Link to comment
Share on other sites

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.
 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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).
 


 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...