Lack of dithering in N64 framebuffer causing color banding

[TorutheRedFox]

Dithering is honestly necessary to produce a correct (and actually somewhat good looking) N64 framebuffer, as it's quantized with no dithering, which deviates from hardware, which does infact have dithering

[dankcushions]

getting build error with this on rpi4:

/home/pi/RetroPie-Setup/tmp/build/mupen64plus/GLideN64/src/BufferCopy/BlueNoiseTexture.cpp:533:1: error: narrowing conversion of ‘-1’ from ‘int’ to ‘char’ inside { } [-Wnarrowing]
 };
 ^

(repeats many times for same line for some reason)

[gizmo98]

@dankcushions Maybe we should use s8 instead of char here: https://github.com/gonetz/GLideN64/blob/master/src/BufferCopy/BlueNoiseTexture.h#L5

@gonetz Wouldn‘t it be better to use stdint.h with standard types like int8_t and uint8_t instead of Types.h?

[gonetz]

Wouldn‘t it be better to use stdint.h with standard types like int8_t and uint8_t instead of Types.h?

It would be better to use stdint.h from the start, but now I see no sense to do such refactoring.

[gonetz]

Maybe we should use s8 instead of char here:

It can help indeed. -1 is valid value for signed char. Strange that narrowing conversion is an error and not a warning.

[gizmo98]

@gonetz A error message seems to be default for G++ and C++11: https://gcc.gnu.org/wiki/FAQ#Wnarrowing

Char is unigned by default for ARM targets. https://answers.launchpad.net/gcc-arm-embedded/+question/428043 http://www.keil.com/support/man/docs/armcc/armcc_chr1359125009502.htm https://www.arm.linux.org.uk/docs/faqs/signedchar.php

So s8 or compiler switch "-fsigned-char" should solve the problem.

[gonetz]

@gizmo98 Thanks for explanations! I changed type to signed char: 0cca2fa2f

[dankcushions]

great, compiles and works!

however definitely dropping some frames on RPI4 with dithering and the rest at default (blue noise etc), but cool for devices with more horsepower!