View Single Post
Old 25 March 2016, 11:54   #4
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,480
Well, I meant fairly obvious once you're aware the problem exists, and that some pixels in HAM6 images on AGA have $x0 colour components instead of $xx.

For anyone that's interested, the bug was this code:
Code:
} else { /* AGA mode HAM6 */
    while (unpainted_amiga-- > 0) {
        int pv = pixdata.apixels[ham_decode_pixel++] ^ bplxor;
        switch (pv & 0x30)
        {
        case 0x00: ham_lastcolor = colors_for_drawing.color_regs_aga[pv] & 0xffffff; break;
        case 0x10: ham_lastcolor &= 0xFFFF00; ham_lastcolor |= (pv & 0xF) << 4; break;
        case 0x20: ham_lastcolor &= 0x00FFFF; ham_lastcolor |= (pv & 0xF) << 20; break;
        case 0x30: ham_lastcolor &= 0xFF00FF; ham_lastcolor |= (pv & 0xF) << 12; break;
        }
    }
}
Instead of RGB components being modified to (hex) $xx, corresponding to $x OCS/ECS 4-bit values, the component was set to $x0.

The image defect will persist along the scanline, possibly getting worse if more than one component gets modified, until a pixel which is one of the sixteen base colours is reached.

The fix would be to change the expression (pv & 0xF) to, for example, ((pv & 0xF) * 0x11), so:
Code:
case 0x10: ham_lastcolor &= 0xFFFF00; ham_lastcolor |= (pv & 0xF) * 0x11; break;
case 0x20: ham_lastcolor &= 0x00FFFF; ham_lastcolor |= (pv & 0xF) * 0x11 << 16; break;
case 0x30: ham_lastcolor &= 0xFF00FF; ham_lastcolor |= (pv & 0xF) * 0x11 << 8; break;
mark_k is offline  
 
Page generated in 0.07782 seconds with 9 queries