Neil Pate Posted October 29, 2021 Report Share Posted October 29, 2021 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
ShaunR Posted October 29, 2021 Report Share Posted October 29, 2021 (edited) 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 Link to comment
Neil Pate Posted October 30, 2021 Author Report Share Posted October 30, 2021 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... Link to comment
Neil Pate Posted October 30, 2021 Author Report Share Posted October 30, 2021 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 Link to comment
ShaunR Posted October 30, 2021 Report Share Posted October 30, 2021 Yeah. If you want a clean image at zoom you'll have to mask it. woopswee.vi 1 Link to comment
Dataflow_G Posted October 30, 2021 Report Share Posted October 30, 2021 (edited) 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 Link to comment
Neil Pate Posted October 30, 2021 Author Report Share Posted October 30, 2021 I cannot really see the pattern though. These have the anti-aliasing But this doesn't and surely has similar groups of pixels Link to comment
Dataflow_G Posted October 30, 2021 Report Share Posted October 30, 2021 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. Link to comment
Neil Pate Posted October 30, 2021 Author Report Share Posted October 30, 2021 (edited) 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 Link to comment
Dataflow_G Posted October 30, 2021 Report Share Posted October 30, 2021 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. 1 Link to comment
Neil Pate Posted October 30, 2021 Author Report Share Posted October 30, 2021 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
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now