Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One pixel shifted to the bottom in NTSC mode #650

Open
landloafer opened this issue May 25, 2019 · 21 comments

Comments

@landloafer
Copy link

commented May 25, 2019

Hi,
I see the top-most line of pixel has a grey line. Bottom-most line is too thin. I suspect the screen may have shifted one pixel to the bottom (or the behavior of NTSC filter)?

AppleWin_ScreenShot_000000002
AppleWin_ScreenShot_000000003

comparison_top_left
Top-left corner comparison

comparison_bottle_right
Bottom-right

@tomcw

This comment has been minimized.

Copy link
Contributor

commented May 26, 2019

Thanks for raising this issue. I will take a thorough look, but suspect it's just an "out by 1" vertical anomaly.

@tomcw tomcw added the bug label May 26, 2019
@tomcw

This comment has been minimized.

Copy link
Contributor

commented May 26, 2019

btw, can you let me know which AppleWin version you are using too?

@landloafer

This comment has been minimized.

Copy link
Author

commented May 26, 2019

It is v1.28.5.0.

I see they all show the same behavior in previous versions.

@landloafer

This comment has been minimized.

Copy link
Author

commented Aug 5, 2019

Turning on 50% Scanline on Color TV Mode will shift the screen 1px back up.

Prince of Persi_000000000
50% Color TV

Comparison
Top-left corner comparison

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2019

Thanks. I plan to look at this soon.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Aug 10, 2019

I've moved the two NTSC TV modes up 1 line (ie. half the thickness of an Apple II line, since AppleWin draw 2 lines per Apple II line), but now the last line (the 384th line) is not drawn to.

NB. The reason that the top line is grey, is because each line (in non- 50% Scanline mode) is a 50% blend of the current colour and the previous Apple II line, ie. 50% blend of line(0) and line(-2)... and the colour at line(-2) is always black.

When in 50% Scanline mode, the blend operation is:

  • colour = (current colour) - (25% of previous Apple II line's colour)

For line(0) this means the colour doesn't change... so white remains white: since line(-2) is always black. It's this different blend operation that gives the impression that it "will shift the screen 1px back up".

I may revert the change I made at 8a11feb, as I'm not convinced there is really an issue here (other than arguably the blend operations).

@tomcw tomcw added this to the 1.29.2 milestone Aug 10, 2019
@landloafer

This comment has been minimized.

Copy link
Author

commented Aug 12, 2019

I see.

Only if the filter will blend the last line with an imaginery black line outside the screen.

A video in YouTube said to be an actual recording from Apple //e.
https://www.youtube.com/watch?v=7m7j2VuWhQ0

@landloafer

This comment has been minimized.

Copy link
Author

commented Aug 12, 2019

With some row counts: -

  • RGB Monitor Row is 2px
  • 50% Color TV Row is 2px
  • Color TV Row (after blending between previous and next line) is 3px

I guess it must be this reason, it makes us feel the last row of Color TV is thinner as it has only 2px.

AppleWin_ScreenShot_0
(I replaced the picture for accurate comparison)

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2019

I want to have a good look at the TV (non- and 50%) blend operations to properly understand them.

Unfortunately the original design/implementor (great though his work was) didn't leave any notes!

tomcw added a commit that referenced this issue Aug 25, 2019
tomcw added a commit that referenced this issue Aug 26, 2019
tomcw added a commit that referenced this issue Aug 30, 2019
@tomcw

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2019

@landloafer - try this experimental build of AppleWin1.29.1.1.zip

You can use Ctrl-9 to toggle between the old 1.29.1.0 TV rendering and the new 1.29.1.1.
Instead of using previous line+current colour, I'm using current+next line colour.

At 1.29.1.0, the 50% mode was:

  • previous inbetween line = current - 25% of previous line's colour.

Now at 1.29.1.1, it's:

  • next inbetween line = 50% of (50% blend of current + next line)

I think this solves the original issue you raised here.
Let me know.

@landloafer

This comment has been minimized.

Copy link
Author

commented Aug 31, 2019

Hi @tomcw, thanks for the experimental build.

I've got a little confused with the decision. It is now to decide whether to place the half dark line at the bottom or be originally at the top. The new built looks good to me personally since I already have the bias to this perception. The difference to the top line is not be that noticable to me comparatively. However, some other users may vote differently depending on their perception as they may see the top line being one pix less. It is very depending on other's personal taste.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Aug 31, 2019

I think it's better than before. Also NTSC/PAL isn't so precise, so the emulated image is more theoretical than reality. (And as a useful side-effect the underlying code become simpler removing a hack that was used to align the TV modes with the Monitor modes.)

For reference, here's Prince of Persia, zoomed in at the bottom. The bottom line (as you say "half dark") is due to blending the last line (280th line) and next 281st line (which is all black).

The top image is 50% Color TV, the bottom image is 100% TV Color:

pop50-vs-100

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Aug 31, 2019

Summary of change:

updateFramebufferColorTVSingleScanline():

  • Original (1.29.1.0): Prev1(inbetween) = current - 25% of previous AppleII scanline
  • GH#650: Next1(inbetween) = 50% of (50% current + 50% of next AppleII scanline)

updateFramebufferColorTVDoubleScanline():

  • Original (1.29.1.0): Prev1(inbetween) = 50% current + 50% of previous AppleII scanline
  • GH#650: Next1(inbetween) = 50% current + 50% of next AppleII scanline

The double-scanline difference is: instead of the in-between (mid-AppleII scanline) being drawn above (the current pixel), it's now drawn below. So in effective this shifts the image down 1 line.

EG. 3 pixels (X) and the in-between colour (x):

prev: xxx
curr: XXX  --> XXX
next:          xxx

NB. Since we are now blending with curr & next, this is actually current pixel and pixel 'from the next line from previous frame' (since pixels are drawn top to bottom).

There was also a hack (VideoFrameBufferAdjust()) for the 2 TV modes to shift the image (by 1 vertical pixel) via the StretchBlt(), but now isn't needed, so has been removed.

@landloafer

This comment has been minimized.

Copy link
Author

commented Sep 1, 2019

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2019

Ah, I was too focused on static images! Yes, you are right (and thanks for the nice gif animation too!). I'll fix this...

tomcw added a commit that referenced this issue Sep 1, 2019
@tomcw

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2019

@landloafer - here's a new build: AppleWin1.29.1.2.zip

Summary of changes:

updateFramebufferTVSingleScanline():

  • Original (1.29.1.0): Prev1(inbetween) = current - 25% of previous AppleII scanline
  • GH#650: Prev1(inbetween) = 50% of (50% current + 50% of previous AppleII scanline)

updateFramebufferTVDoubleScanline():

  • Original (1.29.1.0): Prev1(inbetween) = 50% current + 50% of previous AppleII scanline
  • GH#650: same as original

NB. For both single/double, the 280th next in-between line also get updated using the above respective single/double formula. This ensures that the last line overwrites any residue from another video mode (eg. changing from 'Amber Monitor' -> 'B&W TV'.

@landloafer

This comment has been minimized.

Copy link
Author

commented Sep 2, 2019

Thanks @tomcw, the shadow is gone.

But, I am sure it will be back after the Prince jumps into the mirror on Level 4 :)

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2019

Thanks @landloafer for testing this.
I will wait until I formally do a release before closing this.

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Sep 6, 2019

FYI, new AppleWin build 1.29.2 here.

But now I'm looking at a TEXT screen, and for the top line (eg. if it's a line of TTTTT) it's noticeable that the (old top) pre-grey line is missing.

Maybe for TV modes, it actually needs 561 lines... which I don't want to do!

@landloafer

This comment has been minimized.

Copy link
Author

commented Sep 7, 2019

Would it has any adverse effect to other modes if 561 lines?

@tomcw

This comment has been minimized.

Copy link
Contributor

commented Sep 7, 2019

I'll have to try it and see how it looks, because for the non-TV modes, they will gain an extra black line (probably at the bottom).

NB. There is already a 1px black frame around all the 348x560 images.

Maybe there's a better way to do the inter-line blending - as you say above, each row is 3px (in height) due to the prev/next blend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.