Everything looks better in scanlines!

[robcfg]

Looking really great!

[Gryzor]

If you don't look too closely it is like you're looking at a CPC monitor

Also: Bob Winner, wish I had found this back in '86 - I'm sure it'd have blown my mind!

[roudoudou]

I have a proof of concept with Linux 64 bits version of CPCEC emulator
the video is supposed to be viewed in straight 1080p to avoid jerk
if someone know a little DirectDraw, we may expect a windows version of CPCEC ?


https://clips.twitch.tv/AffluentCoyHippoANELE-a4xx-lsJoymgVX88

[Gryzor]

Ohhh that rocked! I think there's too much vertical stuff going on but it's really promising!

[roudoudou]

Ohhh that rocked! I think there's too much vertical stuff going on but it's really promising!

the session was captured live so there is encoder jerk, especially in black zones
i changed some details again since the stream and improved performances

[Gryzor]

Yeah I saw the jerk and assumed it was the capturing/streaming, but it had me wondering, what sort of CPU overhead are you getting?

[roudoudou]

Yeah I saw the jerk and assumed it was the capturing/streaming, but it had me wondering, what sort of CPU overhead are you getting?

i have a Ryzen 5-2600 / 6 cores/12 threads / 3.4GHz
best results with 8 threads for rendering (17% cpu for 50 frames/second)
single thread was approx. 40% of CPU

[Gryzor]

That's quite a bit! But to be expected. Doesn't it take advantage of GPU computations?

[roudoudou]

That's quite a bit! But to be expected. Doesn't it take advantage of GPU computations?

it's CPU only, i don't know how to do shaders at all...

[Gryzor]

Was only asking out of curiosity, it's not a big deal

[andycadley]

Well I used to know a bit of DirectDraw but I'm pretty sure it's deprecated these days and thus a bit of a chore, I think it's mostly been superseded by Direct2D but it's been a long time since I was doing C/C++ coding so I don't know how different that is.


It does seem like this kind of thing would be well suited to a pixel shader though. For each component of a pixel, find the "nearest" emitter and then calculate how much of that color is mixed in. Possibly doing horizontal and vertical components separately to account for the slot shape? Feels like it should be doable. I might have a play around at some point and see what it would look like.

[roudoudou]

It does seem like this kind of thing would be well suited to a pixel shader though. For each component of a pixel, find the "nearest" emitter and then calculate how much of that color is mixed in. Possibly doing horizontal and vertical components separately to account for the slot shape? Feels like it should be doable. I might have a play around at some point and see what it would look like.

it's not that trivial (that's why all existing shaders doesn't look like real screens)
i do not compute low intensity like high intensity, that is the key 

[andycadley]

Oh, I don't doubt there's a lot of subtlety to it and I haven't really considered it in depth. I do think it's an intriguing problem though and something that should be doable as a shader (at least in theory).


I do think this is one of the more interesting areas of emulator development of late. As screen resolutions get higher and higher, we're well past the point where there was a 1:1 pixel correspondence and all those extra pixels (and colour depth) really should be usable for producing a more faithful image.

[pelrun]

I've just done a very rough attempt at a shader version using shadertoy: https://www.shadertoy.com/view/fsB3z1
Unfortunately it doesn't have any reasonable way of using custom texture inputs, so I'm stuck with using one of the provided ones.

[attach=1,msg200045]

[roudoudou]

I've just done a very rough attempt at a shader version using shadertoy: https://www.shadertoy.com/view/fsB3z1
Unfortunately it doesn't have any reasonable way of using custom texture inputs, so I'm stuck with using one of the provided ones.

as you are dealing with floats, before going further, it may be cool to use geometry of a slot-mask with red column higher than green, blue column lower that green
then raising intensity by overflowing the other columns (but not too much) to compensate the darkness
PS: i have some photographies to do of use cases, it may help for your shader
again a capture from Sylvestre with white pixel / gray pixel
the white pixel is wider than the gray (kind of energy distribution)

[pelrun]

as you are dealing with floats, before going further, it may be cool to use geometry of a slot-mask with red column higher than green, blue column lower that green

I'm not sure that's actually true of the slot mask; I think the offsets are actually due to the camera or the electron beam being slightly off-axis. After all some photos show the columns are perfectly aligned horizontally.
As for the "wider" bright pixels, that's a direct result of the non-linear response of the phosphors and should just happen once I implement that properly. I really need a proper high-contrast test image properly scaled before I can fiddle with that.

[roudoudou]

I'm not sure that's actually true of the slot mask; I think the offsets are actually due to the camera or the electron beam being slightly off-axis. After all some photos show the columns are perfectly aligned horizontally.
As for the "wider" bright pixels, that's a direct result of the non-linear response of the phosphors and should just happen once I implement that properly. I really need a proper high-contrast test image properly scaled before I can fiddle with that.

i counted 480 photophores for 768 pixels (770?) so if i'm right (for 480 count) there is 5 photophore each 8 mode 2 pixels


we may need a minimum of 8 photographies per color and intensity?

[Gryzor]

After all some photos show the columns are perfectly aligned horizontally.

I was going to ask, did the CTM really have the pixels placed diagonally as shown in the image above?

[roudoudou]

I was going to ask, did the CTM really have the pixels placed diagonally as shown in the image above?

the grid seems to be flat but the read beam seems to be upper than the others on the pictures i have
we may set this as a parameter?

[Gryzor]

the grid seems to be flat but the read beam seems to be upper than the others on the pictures i have
we may set this as a parameter?

I'm pretty sure MacDeath has shared the relevant grilles?

But yes, the red being a bit higher does not sound strange - going downhill from left to right though, certainly seems off.

[andycadley]

To me it looks like alternating groups of RGB are offset (as per the diagram of slot masks on page 6) but the RGB within a group are all aligned. That's not really the same as the "pixels" being offset, because CRTs don't work like that.

[Gryzor]

*subpixels.

There, fixed it.

[andycadley]

So I had a really rough stab at what I was thinking of. It's not a great PS and probably goes horribly wrong if there aren't the right number of pixels in the image etc but the results are something like:

[Gryzor]

Am I the only one seeing vertical RGB bands on the road?

[roudoudou]

Am I the only one seeing vertical RGB bands on the road?

nope, there is rainbow aliasing (even viewed in 1:1 pixel size)