Adding more needed builtin uniform variables

[Jobima]

as said in this post and in this

I suggest adding those

• “FieldOrder” [0=none (progressive), 1=bottom field first, 2=top field first]
• “FieldSeparate” [0=frame based (use FieldOrder to know whether it progressive or not), 1=it’s the bottom field, 2=it’s the top field]

– both will help a lot in interlaced cases

• “GameConsole” will help in case if the resolution is not enough, like if the console has special form of composite signals
• “GameRegion” will help in case if the game is PAL or even special form of PAL like PAL-N, or in case of NTSC-J vs NTSC-M, etc…
• “OriginalResolution” will help in case of the core render in more than 1x like 4x and 8x so the shaders can use that to give correct output and work faster

[Jobima]

@Jobima

“GameConsole” will help in case if the resolution is not enough, like if the console has special form of composite signals

if this get integer value, like if the NES get value of “9” and if the core output as raw then “-9” can be used

Edit: I forget

• “OriginalOverscan” it will help if the retroarch or the core didnt crop the Overscan and leave it to the shader

Edit #2: maybe OriginalOverscan can have negative value to output pure composite grayscale output (with Colorburst and other stuff) just like composite/s-video video from the real console, and negative value of GameRegion to output as s-video instead of composite

[anikom15]

To calculate correct artifact colors we need to reconstruct the dot pattern of the signal. To do this we need to know the exact horizontal frequency, the color subcarrier frequency, and the number of lines and pixels including blanking. Some examples:

NES/SNES: Get framerate from OriginalFPS, multiply by 262 to get H freq., multiply by 341 (derived through a parameter) and divide by 1.5 to get SC freq.

Genesis: Subcarrier is exact to standard, get framerate from OriginalFPs, multiply by 262 to get H freq. Guesstimate nonactive horizontal because it depends on the mode (usually 100 px for 320 mode)

N64: OriginalFPS is wrong, use a hardcoded value…

Even if cores report horizontal frequency or region, it isn’t enough to know the right way to get the correct composite artifacts. I had to implement different modes for different situations because the consoles all work in different ways. In NTSC, sometimes the line count is 262 and sometimes it’s 263 (and for PC Engine it can switch between fields). In PAL it can be 312 or 313.

Probably the most natural for emulator authors would be pixel clock freq and current number of lines + v. blanking, as I believe emulators need to be aware of both for timing to work accurately. Those two values combined with OriginalFPS can be used to derive a lot of the other timings.

[Jobima]

so that mean

• “HorizontalFrequency”

• “SubcarrierFrequency”

@anikom15

Even if cores report horizontal frequency or region, it isn’t enough to know the right way to get the correct composite artifacts. I had to implement different modes for different situations because the consoles all work in different ways. In NTSC, sometimes the line count is 262 and sometimes it’s 263 (and for PC Engine it can switch between fields). In PAL it can be 312 or 313.

Probably the most natural for emulator authors would be pixel clock freq and current number of lines + v. blanking, as I believe emulators need to be aware of both for timing to work accurately. Those two values combined with OriginalFPS can be used to derive a lot of the other timings.

maybe the Solution is to give horizontal frequencies as array? and that array has every horizontal frequency for every line

or gone full analog style (which mean using horizontal lines just like analog tv) with maybe negative value of FieldSeparate