hqx implementations, cargo culting, 16bit color, etc.

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

User avatar
VoidMage
Posts: 18
Joined: Sat Apr 11, 2015 5:30

hqx implementations, cargo culting, 16bit color, etc.

Post by VoidMage » Wed Jun 10, 2015 21:22

:sigh:

So, I'm not sure how to start...
Recently I've felt like comparing available hqx implementations.
Those that I've managed to find were the original one, the slightly tweaked (and most cargo-culted (after all, I've fallen for it too)) from googlecode, fmpeg conversion of it and a shader one (glsl one has a trivial typo, but other than that works).

As I was comparing ffmpeg one with the shader, I've learned that those aren't equivalent - shader does float <-> integer correctly, ffmpeg - not quite.

So, I've looked at the original again...

Well, looking at it, what it calls YUV isn't really YUV.
As some of you here have some experience with 16bit color, do you have any idea what the original author what trying to get via this conversion ?

Code: Select all

{
Y = (r + g +b) >> 2;
u = 128 + ((r -b) >> 2);
v = 128 + ((-r +2g -b) >> 3);
}
Also, I've got that ffmpeg conversion rewritten to be usable in GZDoom - the code size (both in source and compiler output) is far smaller and compiles FAR faster than the current one (the object size of linux 64bit is about 5.5% of the current (even less, if were talking about code with debug symbols)), so if you're interested...

The above doesn't account for the Interp functions, which are weighted sums, but also don't do the rounding quite right...

Return to “GZDoom”