MEGA65/SEAM: trim & flip char horizontally combined

[ghost]

With my game project I use the trim as well as the flip function combined for NCM chars.
As it turns out, pixel columns are cut on the wrong side in this case. Check out how it compares to hardware,
TEST PRG ATTACHED below.

In order to display only the 'right' pixel data of an NCM char, I cut off half (colour ram byte 0, bit 2) and flip it horizontally (colour ram byte 0, bit 6). Provided you store the gfx to the right of the char 'pre-flipped' it will display as desired. Useful if you want to make the best use of 8x8 pixel gfx in NCM format and memory. Because the otherwise wasted memory for the right side of the NCM char is thus made usable.

During research I came across a few things:

• NCM/FCM = OK

• MONO = OK

• (flip h) NCM/FCM = trim - reversed left to right

• (flip h) MONO = trim - reversed left to right

• NCM/FCM followed by gotox = ?

• MONO followed by gotox = ?

• (flip h) NCM/FCM followed by gotox = trim - reversed left to right

• (flip h) MONO followed by gotox = ?

• Bit 2 in colour ram byte 0 makes them disappear but has no effect on the hardware. This applies to characters with a width of 8 pixels (FCM/MONO) only.

• following gotox makes troubles

I'm all about trimming on the correct side when horizontally flipped regarding NCM chars, realizing this issue is difficult to manage but would be great to get rid of.

Xemu version: Xemu/MEGA65 20230216142236 (next)
ROM version: 920377

Attachment:
TRIMFLIP.zip

[lgblgblgb]

If I understand correctly, the problem here, that "trimming" and "flip" may happen in different order (as we can say here, loosely speaking) in Xemu than on a real hardware then.

[ghost]

See it that way too. I think I can remember, in my example, a GotoX is set after each char, that prevents trimming in some cases, whether flipped or not.

[ghost]

And trimming FCM/Mono chars in general uses only a 3-bit value on the hardware. Thus the char does not disappear completely.