Creating pixel art

By Manuel

Ascended (19465)

29-07-2017, 21:57

Grauw: It would be weird if the openMSX horizontal stretch setting would depend on the refresh rate, wouldn't it?

By hit9918

Prophet (2932)

30-07-2017, 00:38

well there is no vertical_stretch
vertical handling should be done with vertical_stretch_ntsc and vertical_stretch_pal variables used dependant on 50/60hz mode bit
the vertical stretch changes on the fly when the MSX changes the mode

and then it would be nice if one could change the window size
a fullsize window, almost fullscreen without going fullscreen
or make the window 16:9 shape

to be easy usable the window size change should zoom without changing the aspect ratio.
the display box of horizontal_stretch , vertical_stretch is zoomed without aspect change till it hits the window either in vertical or horizontal direction.

and then based on that mechanism the user can model all the "letterbox", "enforce 16:9", "4:3 overscan", "4:3 old TV", etc.

the horizontal_strech maxes out at 320, I guess to save another CLS. but it would be nice if the features could be tweaked in more range.

By Manuel

Ascended (19465)

30-07-2017, 11:31

This is how mth put it, and I think that's the right direction to go at some point:
<mth> well, what is the height of a pixel? if you define it as the distance between a pixel and its upper and lower neighbour, then 50/60Hz does change the pixel shape
<mth> but indeed the extra height at 60 Hz is in the black area (scanline efect)
<mth> what we could consider in the future, especially if we let go of the scale_factor setting, is for certain scalers to apply a different line distance for 50 and 60 Hz
<mth> then you'd see the image stretch when switching from 50 to 60, just like on real MSX

By hit9918

Prophet (2932)

30-07-2017, 13:37

yes a different vertical_stretch applied dependant on the mode
vertical_stretch_pal and vertical_stretch_ntsc

By Grauw

Ascended (10768)

30-07-2017, 18:32

Manuel: well, I’m not saying you should change how 50Hz is displayed (I think the current aimed-at-60Hz setting is also good), but a TV does show different pixel aspect ratios.

But I don’t think you should scale the height. In analog video the height is discrete, so it can be directly mapped to discrete pixels on the PC, I think that mapping is worth preserving. While the x resolution is continuous and can be anything (think V9990 B2 mode), and will never 1:1 match the PC pixels, so scaling the width makes more sense.

As for what to do with PAL’s extra height, you could increase the window height, but it’s not very useful imo, you’ll just be showing much more boring border region, so I’d keep that as-is.

By Grauw

Ascended (10768)

30-07-2017, 21:07

@hit9918 Maybe this is what you were saying, but I just realised:

PAL 4:3 pixel aspect ratio is pretty close to NTSC 16:9 pixel aspect ratio. So, if you would author the content for a 1.4 pixel aspect ratio, you could give your players a recommendation like “if playing on a 16:9 TV, use 60 Hz, if playing on a 4:3 TV, use 50 Hz”. The frequency switch in the V9938 is almost kind of like a widescreen switch.

Note that the difference in pixel aspect ratio between PAL 4:3 and NTSC 16:9 (~10% wider) is much less than the difference between NTSC 4:3 and PAL 4:3 (~21% wider).

From this follows also that any European game production (authored for PAL) can be played well on a widescreen TV, if the game allows you to switch the frequency to 60 Hz. Already a pretty large pre-existing library of widescreen content for MSX .

By Grauw

Ascended (10768)

02-08-2017, 02:16

I did some visualisations of the screen 11 colour space.

Each horizontal pixel increases Y, each horizontal block increases J, each line increases the K:

Each horizontal pixel increases Y, each horizontal block increases K, each line increases the J:

The 16 JK chroma planes (J×K) and the Y luma values from top left to bottom right:

And finally, a Youtube video:

Screen 11 YJK colour mode visualisation

Source mp4 also available here.

And here’s a nice (slow) Basic program to show all screen 11 colours on MSX2+ / turboR:

100 DEFINT A-Z
110 SCREEN 11
120 VDP(9)=VDP(9) OR 2
130 FOR J = 0 TO 63
140 FOR K = 0 TO 63
150 FOR Y = 0 TO 15 STEP 4
160 VPOKE (K\16)*16384 + J*256 + (KAND15)*16 + Y+0,(K AND 7)+(Y+0)*16
170 VPOKE (K\16)*16384 + J*256 + (KAND15)*16 + Y+1,((K+32)\8 AND 7)+(Y+1)*16
180 VPOKE (K\16)*16384 + J*256 + (KAND15)*16 + Y+2,(J AND 7)+(Y+2)*16
190 VPOKE (K\16)*16384 + J*256 + (KAND15)*16 + Y+3,((J+32)\8 AND 7)+(Y+3)*16
200 NEXT:NEXT:NEXT
210 VDP(24)=VDP(24)+1 AND 255
220 FOR I = 0 TO 500 : NEXT
230 GOTO 210

I now understand screen 11 slightly better :D.

Not sure if it’s enough to attempt to make pixel art for it though… I’ve got some more clarity on what colour gradients are possible for each 4-pixel group, and selecting the right colours is now easier referencing those images. But it’s still difficult to work with in a general-purpose editor.

p.s. Some bonus links: The MSX 2+ screens, nice article by Alex Wulms which explains the basics, and Issues on YJK colour model implemented in Yamaha V9958 VDP chip by Ricardo Cancho Niemietz which offers some interesting critiques on Yamaha’s implementation.

By Grauw

Ascended (10768)

23-10-2017, 23:47

According to openMSX the 5-bit colour values are 0, 11, 21, 30, 39, 48, 57, 65, 74, 82, 91, 99, 107, 115, 123, 131, 139, 147, 155, 163, 171, 178, 186, 194, 202, 209, 217, 224, 232, 239, 247, 255. These are perfectly linear if you take into account the openMSX gamma correction setting of 1.1 and some loss of precision due to an 8-bit colour buffer. Nice!

But I previously mentioned the 3-bit colour values were 0, 39, 82, 115, 155, 186, 224, 255. Not linear. Notable here is that these are a subset of the 5-bit values; if the palette was truly 3-bit, this shouldn’t be the case, [0..7]/7 is not a subset of [0..31]/31. Turns out that those are actually the colour values for the V9958, where the DAC is 5-bit, and the 3-bit values are mapped to 5-bit as 0, 4, 9, 13, 18, 22, 27, 31.

This means that the V9938, which has a 3-bit DAC, actually outputs slightly different colours than the V9958 does! I just checked, and indeed, openMSX tells me: 0, 43, 81, 118, 153, 187, 221, 255. Perfectly linear, with some gamma correction.

This is very good to know. I’m glad I found that out, I was already puzzled by the nonlinearity of the values I saw before. I guess I should tweak the colour values in my graphics intended for MSX2 now.

And lastly, for completeness’ sake, screen 8’s 2-bit blue values map to 3-bit indices 0, 2, 4, 7.

So, new summary of VDP colour component values (gamma corrected by 1.1):

V9938 2-bit: 0, 82, 153, 255
V9958 2-bit: 0, 83, 156, 255
V9938 3-bit: 0, 43, 82, 118, 153, 188, 222, 255
V9958 3-bit: 0, 40, 83, 116, 156, 187, 225, 255
V9958 5-bit: 0, 11, 21, 31, 40, 49, 57, 66, 74, 83, 91, 99, 108, 116, 124, 132, 140, 148, 156, 163, 171, 179, 187, 194, 202, 210, 217, 225, 232, 240, 248, 255
V9990 5-bit: Same as V9958.

By hit9918

Prophet (2932)

02-08-2017, 22:57

the paper says "yamaha confused G and B".
who knows, maybe yjk makes nicer ramps than yuv.

yjk
r = j + y
g = k + y
b = 1.25y -0.5j -0.25k

when you decrement Y
then r goes down by 1, g goes down by 1 and b goes down by 1.25.

how would yuv go, g and b exchanged, so,
when you decrement Y
then r goes down by 1, g goes down by 1.25 and b goes down by 1.

in your video at 0:20 dat nice brown ramp, YUV can only be worse.
I start to wonder whether yjk is generaly nicer for nature video.

another argument:
yuv slides g by 1.25, this is more brightness change than yjk which slides g by 1.
so yjk has finer grained brightness slides.

By Grauw

Ascended (10768)

02-08-2017, 23:56

Yeah, I thought a similar thing about maybe nicer ramps, although I didn’t look into it carefully so I didn’t comment on it… I want it to be true, though if you look at the 16 chroma planes pic above, it feels maybe there’s too much blue in the warmer colours and too little in the colder colours so… not sure. I did find some nice ramps indeed, like I liked the brown and green to yellowish-white ones I found, good for outdoors nature.

I may make a quick web tool which looks like the video, but where you can select the chroma and luma value. If I get around to do that, should be easy to add an YJK / YUV mode switch, then maybe it’s easier to compare the colour ramps. (V9990 has both YJK and YUV mode btw.)