Something I obviously don't understand about a Picture Control

[Neil Pate]

I am playing around with the character ROM from a Commodore 64. 

Extracting the contents and converting to bit arrays

 

Say I have this bit patten, and I convert it to a U8 [][], like this

 

Then I can display it on a Picture Control, no problems

Like this

 

So far so good...

Now does anyone know why this particular pattern (and a few others) don't work correctly? As you can see in the picture I am getting some light pink leaking through (almost like some kind of anti-aliasing).

 

 

It does not happen for any of the alphabetic chars, but does for a few others.

Any ideas?

 

[ShaunR]

It is anti-aliasing because you have the zoom factor cranked up, right?

Set the zoom factor to zero and get your magnifying glass out. 

Edited October 29, 2021 by ShaunR

[Neil Pate]

9 hours ago, ShaunR said:

It is anti-aliasing because you have the zoom factor cranked up, right?

Set the zoom factor to zero and get your magnifying glass out. 

That looks like a pretty broken anti-aliasing algorithm then!

You are right, I have the ZoomFactor cranked up to 25, but this really should not cause any kind of anti-aliasing.

Anyway, I don't want the picture control to do AA, this just seems strange to me.

Dropping the ZoomFactor down to 1 and then taking a screenshot (and then zooming in) shows it is actually working fine, so at some point the ZoomFactor must be screwing it up. Interesting...

 

[Neil Pate]

Further experimentation shows me this weird effect happens as soon as you go above 1 for the ZoomFactor. Even sticking with integer values for ZoomFactor causes it to happen as soon as ZoomFactor is > 1

[ShaunR]

Yeah. If you want a clean image at zoom you'll have to mask it.

woopswee.vi

 

[Dataflow_G]

It looks like the picture control is trying to be smart, and anti-aliases diagonal pixels of the exact same color. If the colors differ by a single bit, the anti-aliasing doesn't occur:

The picture control also does some kind of pixel hinting - try resize the picture control when the zoom factor is high. You can see it snaps the pixels to some hidden grid in an effort to align it to the picture control bounds. I don't see any properties for disabling the anti-aliasing or the hinting.

Perhaps a 2D array of color boxes could be used? With the classic controls there's no gaps between elements:

 

Edited October 30, 2021 by Dataflow_G

[Neil Pate]

I cannot really see the pattern though.

These have the anti-aliasing

 

But this doesn't and surely has similar groups of pixels

 

[Dataflow_G]

The diagonals need to be in the form:

[0,1]
[1,0]
or
[1,0]
[0,1]

The 'M' only has a single pixel, or three pixels in a 2x2 grid area, so the anti-aliasing isn't applied. Not sure why it has been implemented this way.

[Neil Pate]

55 minutes ago, Dataflow_G said:

The diagonals need to be in the form:

[0,1]
[1,0]
or
[1,0]
[0,1]

The 'M' only has a single pixel, or three pixels in a 2x2 grid area, so the anti-aliasing isn't applied. Not sure why it has been implemented this way.

Got it, thanks. This is a bit annoying, but I can use the technique @ShaunR suggested with the mask. I am busy making some kind of weird C64 with a real 6502 but ROM and RAM (and I guess VIC-II) faked in LabVIEW, so the speed is going to be terrible!

 

Edited October 30, 2021 by Neil Pate

[Dataflow_G]

Sounds like a cool project, especially with a real 6502 thrown in. I remember seeing an open source Apple II emulator written in LabVIEW: https://sourceforge.net/projects/labviewapple2/ Not sure how well it runs, but might be interesting to compare notes.

[Neil Pate]

1 hour ago, Dataflow_G said:

Sounds like a cool project, especially with a real 6502 thrown in. I remember seeing an open source Apple II emulator written in LabVIEW: https://sourceforge.net/projects/labviewapple2/ Not sure how well it runs, but might be interesting to compare notes.

Thanks, that is a nice project; I had not seen it. I found a C64 implementation, but this Apple II one is nicely structured.