pouët.net

the luma levels are very buggy. just look at the 2nd column. on 4 - 5 - 6 column you can see luma increasing in segments then restarting.

There are a lot of fancy luma calc and luma & color distance compare equations, use google to find them.

btw why no dither ? if you can swap a few framebuffers around and change palette, it will hardly use any cpu.

Well the system is very limited in this respect. It has no built in frame buffers and the only way to do this would have to be to copy the video memory in software and that's not feasible.

One trick I use on the Mega Drive for fading is to affect only one RGB component each step. This practically triples the range you have. The Mega Drive only has 3 bits per component, you have 4 so it should look better on your end.

Though, that method was mainly meant for fading (e.g. "turning off" the screen and such). Not sure if it looks good for gradients, I only tested it with animation.

Oh, just noticed psonice mentioned that method =/ Nevermind.

Just so you wonder though, with 3 bits (my case) there are 21 frames you can get without repeating steps. With 4 bits (which is your case) you get 45 frames - getting close to a second there. May want to consider it.

Only issue is if your image uses colors that are pure red, green or blue (i.e. only one component). On those the steps will be noticeable again. Be careful if you use those colors, though honestly if the fade is fast enough nobody will see it anyway.

What I tend to use in some of my C64 productions for fade/defade is to flick color combinations per frame. Would look not too nice on an emulator but at solid 50fps it should look smoother. Lets assume there are 4 shades (0-3) 0=black and 3=white.
Instead of having 0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3 in each frame, you can do something like
0,0,1,0,1,1,2,1,2,2,3,2,3,3,3,3

algo, god please no, it will look like flicker instead of new colors.

I have tried a couple of times a post-processing filter (in fragment shader) for converting a 24-bit HD image into what looks like a CGA (4 colors) or EGA (16).

First I do a downscale of the resolution (all with nearest neighbour).

Then each color in the palette is put into an array of vec3, so that:

a) The two colors from the palette that are closer (in RGB space distance) to the one we convert are found - P0 and P1
b) a theta value that minimizes: C=P0+(P1-P0)*theta - so that our color is expressed as a linear interpolation of P1 and P0
c) a unique random value is assigned per pixel. This value goes from 0 to 1. I emulate dithering by comparing the random value (R) to theta, and if < then C=P0 otherwise P1. This emulates moving from P0 to P1 through a random type of dithering.

It sort of works, but not as good as with hand paid EGA graphics (and definitely not CGA). Unfortunately I don't have a screenshot to show you, but you get the idea.

thats a naive aproach, did almost the same for c64 pictures, but I've used ordered dithering and the dither was weighed on how far the two colors were from the original. didnt work well. couldnt find correct gradients over longer color fades, and often picked horrible color mixes.

To fix that you can move into HSL- Hue Saturation Lightness space, then use handmade hue-brightness table for nice gradients, dither by oscillating in the table on adjacent brightness / hue values. Can also dither on Saturation by going for grayscale / non grayscale table.

On the Amstrad CPC we have a single level of gray. Something that works well for fading is using complimentary colors which add up to a lighter or darker grey.

For example you can do this:

white > light green > light magenta > grey > dark green > dark magenta > black

or for a gradient, do the same with dithering, possibly swapping the green/magenta at each frame to make things less noticeable.

CRT screen and eye persistence do the rest and watchers will see a smooth greyscale fade/gradient.

Guys, I think there is a lot of overcomplicating is happening here.

16 shades is GREAT. A typical fade in or fade out effect on ZX Spectrum is done in about 10-15 frames at 50fps. Because the palette is limited, people either use all colours in the palette (ZX Spectrum palette is already sorted by luminosity) or use a progression of colours from a colour ramp. If you do it quickly enough (5-10 frames at 50fps), the resulting colouring is not very noticeable.

I've done dithering too. It looks very impressive on a real computer, but flickers a bit. It also flickers a lot in an emulator (because typical PC frame rate tends to be different).

My point is: you do not want to do dithering. Just do 16 frames at 50fps (or what is target frame rate). This is about one third of a second. You'll get a beautiful fade in. If it is too fast, do a 25fps version of the same, that's over half a second of fading. You really won't get better quality with dithering.

palette > sort > by brightness?

Why do we always hear argument about thing not looking good on emulators? This is not how demos should be done! Screw them emulators or improve them to a point where they are equal to the real machine.

It is because I consider myself lucky when people check my prods out in an emulator. 95% of the views, I bet, are coming from the Youtube. That's what the reality is for retro platforms.

Well, then make sure there is a proper youtube recording? I agree that temporal dithering may be a bit problematic there.

"Proper youtube recording" is a bit of oxymoron :)
Since until very recently youtube limited the frame rates to 30fps, there are basically no ZX Spectrum demos that you can view there "as they are". Recent promise of an upgrade to higher frame rates is very welcome, but it is not there yes, to the best of my knowledge, and it will take years to do new captures and uploads anyway.
I am sure the same is true for all other home computers from the 1980s, since they were all designed with standard TVset signals in mind.
Emulators also suffer from this, because no-one seems to be able to render 50fps on 60hz monitors well. It is better than youtube, but that's about it.

I thought this was already common knowledge, but currently there's no way to get emulators or Youtube "right", as long as there's the 50/60 or 50/30 raping. If you haven't seen it in 50Hz on a CRT monitor, then you have only seen an extremely distorted version of it. If you only watch the mutilated version, you don't know what you're missing, but if you place them physically side by side, the difference is dramatic. And this applies to any sort of motion, not just flicker color effects.

If the source material was 60fps, chances are high that they will re-encode the videos automatically for you, as they did when introducing higher resolutions.

I personally always reduced the frame rate offline, because Youtube's internal frame rate conversion is not very good. For example, "gigascreen" effects, achieved by flipping two images at 50hz, rely upon temporal smoothing on the real TV/monitor and can result in a very significant flicker when the frame rate is reduced (because of the insufficient frame rate). I cannot say for everyone, but I bet that the vast majority of captures that are currently considered "good" were done using manual frame rate conversion.

Regarding the 50/60Hz dilemma: You know that most graphics cards have an option to go 50Hz hidden somewhere in their control panels, do you? Does wonders for emulators or oldschool vid caps or even youtube videos (YT scales 50Hz back to 25).

The only thing to hope for is that the _monitor_ supports 50Hz properly. TVs do but most cheap and even not so cheap desktop screens resample to 60Hz internally. I'm lucky to have a monitor that can do 50Hz properly at home, but eg. at Revision the only two screens where the oldschool recordings aren't jerky (despite all hardware running at 50Hz) are the CRT in the recording room and the big screen :)

https://www.shadertoy.com/view/MsXXDj
Slightly bored at the office. Looks decent enough IMO, but needs gamma correction =)

@kb_, I do have two monitors that support 50Hz, so I do understand the issue well. However, as a rule of thumb, most monitors do not support 50Hz and this brings us back to the combination "must understand the 50Hz issue + must have 50Hz monitor + must be knowledgeable enough to set up and run emulator" which makes even my 95% estimate a bit overly optimistic.

50Hz videos support by the Youtube will make a lot of difference. Nothing else will.

would 50 hz video on the tube change anything? you wanna force the video mode on screen that perhaps don't support it? 60 is standard. and the hz conversion to 60 is always doing it wrong anyway. you always have duplicates if not native 50. precisely measured every framerate uneven of multiple native hz screen laggs slightly. they could only blend the frames for the sake of the interpolated color fade, but you won't get it correct native or flicker fades or anything. not much of guessing. it doesn't do it.

Let's just wait a few years until everyone uses DisplayPort 1.2a with its variable frame rate and all OSes have learned to adapt the output rate to the content in the foreground, shall we? :)

Most monitors don't support 50Hz but there are several that support 100Hz. So just use 100Hz when watching a 50Hz prod. The real issue though is that the emulator will miss the vertical retrace every so often which will completely break the illusion again (and there isn't any workaround for this, short of making the emulator run on DOS or something like that).

Well, it is all relative. It would look MUCH better than the current 25Hz or 30Hz videos on the standard 50Hz monitor, so it will make a lot of difference in this sense. You are correct, it won't be perfect. At the moment it is not even passable.

You can easily test it youself. Get yourself any 50Hz video and watch it on 60Hz monitor. It won't be silk-smooth, but it'll be OK. Then upload it to the Youtube and compare the result. If not fully convinced, try doing the same with a video featuring a significant amount of flicker at 25Hz ("gigascreen" or something similar). It is not simply non-smooth, it becomes all wrong because of the insufficient discretization frequency and the resulting beating.

E.g. compare Youtube video vs the emulator version for this demo: http://www.pouet.net/prod.php?which=57610
They are two very different beasts, to say the least.