Jump to content

Something I obviously don't understand about a Picture Control

Neil Pate

Recommended Posts

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?


Link to comment
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. :D

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


Link to comment

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 by Dataflow_G
Link to comment
55 minutes ago, Dataflow_G said:

The diagonals need to be in the form:


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 by Neil Pate
Link to comment
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.


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.