
Title bar icon downsampling in XP/Vista
Title bar icon downsampling in XP/Vista
I've made a new bounty of $20 for this. Basically, when the icon got re-added after the GUI rewrite, it came back for Linux unscathed, but Windows wasn't so lucky. The icon is now appears to default to a harsher downsampling method and the shapes are noticeably malformed. Below is a comparison shot of what it looks like currently (left) to .018 when it was fine (right). A proper fix should not create other issues and not externalize the icon. But as always, receiving the bounty is totally dependent on byuu accepting the fix.


-
- ZNES Developer
- Posts: 215
- Joined: Mon Aug 02, 2004 11:22 pm
Edit #2: Icon removed, as it was unneeded.
Last edited by DOLLS (J) [!] on Sun Apr 13, 2008 9:06 pm, edited 2 times in total.
I've only offered one monetary reward for fixing the Mecarobot bug for me, which is of the utmost importance. It was mostly a joke, because I know nobody here can fix it anyway.Nope, just on minor insignificant things that people only notice if they are told that they exist.
Never stuff that a lot of people would enjoy having done and keep noticing, like supporting more hardware.
Everything else has been FitzRoy offering money to others for the things he personally cares most about. Though I'm extremely flattered by this, I don't honestly like the idea of money being involved; but it's his money, so he can do whatever he wants. I just won't accept any of it personally is all.
If you want the multi-tap emulated so badly, feel free to offer your own bounty. But please quit being bitter that I won't drop what's important to me to add support for that controller. It's getting old.
-
- ZNES Developer
- Posts: 215
- Joined: Mon Aug 02, 2004 11:22 pm
I'm surprised nobody actually tried the damn thing.
Edit: Not anymore, I see it crashes if you replace any resource in the file and I can't recompile it myself.
Edit #2: The icon resource contained in bsnes.exe looks good in an editor but somehow it defaults to 8bpp display on my desktop, whilst bsnes.ico which is included in the source package does not, they look the same in an editor. Perhaps this has something to do with the mangling, if you look closely you will notice that both 16x16 pixel versions look good, so it's not a problem with the graphics themselves, perhaps the icon header is being modified once it is included within the executable file and what is most likely happening is windows using a bigger version of the icon and downsampling it for toolbar display.
Desktop:

Editor:

Edit: Not anymore, I see it crashes if you replace any resource in the file and I can't recompile it myself.
Edit #2: The icon resource contained in bsnes.exe looks good in an editor but somehow it defaults to 8bpp display on my desktop, whilst bsnes.ico which is included in the source package does not, they look the same in an editor. Perhaps this has something to do with the mangling, if you look closely you will notice that both 16x16 pixel versions look good, so it's not a problem with the graphics themselves, perhaps the icon header is being modified once it is included within the executable file and what is most likely happening is windows using a bigger version of the icon and downsampling it for toolbar display.
Desktop:

Editor:

It may or may not help this issue, but I've sent byuu a more uniformly shaped icon which I was able to make with the help of a Paint.NET plug-in. If anyone noticed how the red circle's right side was getting slightly cut off, that's fixed now, too. Let's put this on hold until the next WIP when I can see how the new one downsamples.
-
- ZNES Developer
- Posts: 215
- Joined: Mon Aug 02, 2004 11:22 pm
I never learned how to compile. What do I need for windows, is there a foolproof guide somewhere?
Basically, what's happening here is that Linux sucks with ICO files integrated into executables, so now it's impossible to get bsnes to point to the 16x16 icon within the ICO file for the title bar. Instead, it's rendering the 48x48 png (I think) in the source "data" directory, which Linux is downsampling better than XP is. Byuu, could you explain the issue in more detail?
Basically, what's happening here is that Linux sucks with ICO files integrated into executables, so now it's impossible to get bsnes to point to the 16x16 icon within the ICO file for the title bar. Instead, it's rendering the 48x48 png (I think) in the source "data" directory, which Linux is downsampling better than XP is. Byuu, could you explain the issue in more detail?
-
- ZNES Developer
- Posts: 215
- Joined: Mon Aug 02, 2004 11:22 pm
You'd need a MinGW build, the habitual headers and libs, and I think some recent DirectX headers as well... A lightweight bundle of DirectX shits may even exist, avoiding the installation of the whole DirectX SDK.
I believe you can't embed a plain PNG file as a resource icon in Windows, you have to make a proper ICO file with the corresponding combination of display size / bit depth images. I still think the icon within the resource file is getting corrupted somehow, because, as I pointed, after you extract it from bsnes.exe it doesn't display correctly on the windows desktop.
Byuu: What are you using to add the resource file to bsnes.exe?, VS?, if so, have you tried re-assigning the icon resource within your project workspace?
I believe you can't embed a plain PNG file as a resource icon in Windows, you have to make a proper ICO file with the corresponding combination of display size / bit depth images. I still think the icon within the resource file is getting corrupted somehow, because, as I pointed, after you extract it from bsnes.exe it doesn't display correctly on the windows desktop.
Byuu: What are you using to add the resource file to bsnes.exe?, VS?, if so, have you tried re-assigning the icon resource within your project workspace?
Last edited by DOLLS (J) [!] on Mon Apr 14, 2008 7:46 am, edited 1 time in total.
-
- ZNES Developer
- Posts: 215
- Joined: Mon Aug 02, 2004 11:22 pm
It has nothing to do with the resource, of which I use rc and/or windres.
The problem is Windows wants you to use .ico files embedded as resources and tell the OS to display resource #nnn for your window icon. Linux doesn't have the same concept of resources, and GTK+ instead asks for raw pixels for the image.
I need my UI library to work exactly the same for both OSes. No #ifdef bullshit, no compromises. It has to be 100% identical. Since I can't rig GTK+ to use resources, I had to rig Windows to use raw pixel data.
I store the icon itself at 48x48, the highest resolution I have, so that the largest icon displays look good (eg alt+tab icon preview). Problem is, when the OS downscales that to 16x16, it looks like crap.
Best way to handle it is to write a higher quality image scaler into the GUI library to shrink the icon down. Reason for not doing so thus far is that it's very time consuming for such a small gain.
I could also store multiple image sizes, 16x16 all the way up to 48x48, but that's even more annoying. I want to keep the GUI lib simple.
The problem is Windows wants you to use .ico files embedded as resources and tell the OS to display resource #nnn for your window icon. Linux doesn't have the same concept of resources, and GTK+ instead asks for raw pixels for the image.
I need my UI library to work exactly the same for both OSes. No #ifdef bullshit, no compromises. It has to be 100% identical. Since I can't rig GTK+ to use resources, I had to rig Windows to use raw pixel data.
I store the icon itself at 48x48, the highest resolution I have, so that the largest icon displays look good (eg alt+tab icon preview). Problem is, when the OS downscales that to 16x16, it looks like crap.
Best way to handle it is to write a higher quality image scaler into the GUI library to shrink the icon down. Reason for not doing so thus far is that it's very time consuming for such a small gain.
I could also store multiple image sizes, 16x16 all the way up to 48x48, but that's even more annoying. I want to keep the GUI lib simple.
-
- ZNES Developer
- Posts: 215
- Joined: Mon Aug 02, 2004 11:22 pm
I understand now. Perhaps the following code will be of some use if you care enough about this.
These are two high-quality cubic filter kernels (better than Photoshop's own bicubic implementation):
And here's an example implementation to interpolate over double precision coordinates in a grayscale image:
Pardon the shoddy coding, as I'm still quite unexperienced.
The previous snippet interpolates over a 4x4-tap filter, which is ideal for image upsampling, I heard the best method for downsampling is to use enough taps that, for each destination sample, you are covering the area of 4 destination samples. (I.E: A 1/2 resample over each dimension would result in an 8x8-tap filter.)
These filters are separable, which means that you can actually first resample over one dimension and then the other in order to gain speed.
I think the Mitchell kernel with a proper set of initialization parameters could make a nice interpolation scheme for the whole SNES screen, if feasible, in pixel shader form.
Some references:
http://avisynth.org/mediawiki/Lanczos_lobs/taps
http://www.xs4all.nl/~bvdwolf/main/foto ... sample.htm
And to figure out the parameters for the Mitchell-Netravali filter:
http://www.cg.tuwien.ac.at/~theussl/DA/node11.html
These are two high-quality cubic filter kernels (better than Photoshop's own bicubic implementation):
Code: Select all
class Mitchell {
double p0, p2, p3;
double q0, q1, q2, q3;
public:
Mitchell(double b = 1.0 / 3.0, double c = 1.0 / 3.0) {
p0 = (6.0 - 2.0 * b) / 6.0;
p2 = (-18.0 + 12.0 * b + 6.0 * c) / 6.0;
p3 = (12.0 - 9.0 * b - 6.0 * c) / 6.0;
q0 = (8.0 * b + 24.0 * c) / 6.0;
q1 = (-12.0 * b - 48.0 * c) / 6.0;
q2 = (6.0 * b + 30.0 * c) / 6.0;
q3 = (-b - 6.0 * c) / 6.0;
}
double getWeight(double x) {
if (x < 1.0) return p0 + x * x * (p2 + x * p3);
if (x < 2.0) return q0 + x * (q1 + x * (q2 + x * q3));
return 0.0;
}
double getRadius() {
return 2.0;
}
};
class CatRom {
public:
double getWeight(double x) {
if (x < 1.0) return 0.5 * (2.0 + x * x * (-5.0 + x * 3.0));
if (x < 2.0) return 0.5 * (4.0 + x * (-8.0 + x * (5.0 - x)));
return 0.0;
}
double getRadius() {
return 2.0;
}
};
Code: Select all
/*
* EXAMPLE:
* Mitchell cubicFilter(0.4, 0.25);
* OR:
*/
CatRom cubicFilter;
static char cubicPoint(ImageType source, double u, double v) {
int dx, dy;
double currentElement;
int value;
double gValue = 0;
int iu = int(u);
int iv = int(v);
double px = u - iu;
double py = v - iv;
unsigned char* pixels = source.getPixels();
for (int i = -1; i <= 2; i++) {
for (int j = -1; j <= 2; j++) {
dx = iu + j;
dy = iv + i;
if ((dx >= 0 && dx < source.width) && (dy >= 0 && dy < source.height)) {
currentElement = cubicFilter.getWeight(fabs(px - j)) * cubicFilter.getWeight(fabs(i - py));
value = pixels[dy * source.width + dx];
gValue += currentElement * value;
}
}
}
return (char) std::min(255, std::max(0, int(gValue)));
}
The previous snippet interpolates over a 4x4-tap filter, which is ideal for image upsampling, I heard the best method for downsampling is to use enough taps that, for each destination sample, you are covering the area of 4 destination samples. (I.E: A 1/2 resample over each dimension would result in an 8x8-tap filter.)
These filters are separable, which means that you can actually first resample over one dimension and then the other in order to gain speed.
I think the Mitchell kernel with a proper set of initialization parameters could make a nice interpolation scheme for the whole SNES screen, if feasible, in pixel shader form.
Some references:
http://avisynth.org/mediawiki/Lanczos_lobs/taps
http://www.xs4all.nl/~bvdwolf/main/foto ... sample.htm
And to figure out the parameters for the Mitchell-Netravali filter:
http://www.cg.tuwien.ac.at/~theussl/DA/node11.html
guest(r) wrote a Shader Model 3.0 compliant HLSL pixel shader for Lanczos scaling, so I think Mitchell's algo shouldn't be unfeasible.I think the Mitchell kernel with a proper set of initialization parameters could make a nice interpolation scheme for the whole SNES screen, if feasible, in pixel shader form.
-
- ZNES Developer
- Posts: 215
- Joined: Mon Aug 02, 2004 11:22 pm
FitzRoy, there seems to be a serious issue with the icon on Win2k systems now. As you probably know, Win2k uses the 256-color icon, as it lacks alpha support.

The v0.031 icon is on the left, the new icon with the fixed right edge is on the right. Is this something you can correct? Worst case, maybe merge the old 256-color iconset with the new 32-bit icon set?
You'd probably have to set your desktop resolution to 256 colors to see it ...

The v0.031 icon is on the left, the new icon with the fixed right edge is on the right. Is this something you can correct? Worst case, maybe merge the old 256-color iconset with the new 32-bit icon set?
You'd probably have to set your desktop resolution to 256 colors to see it ...
Well I switched icon programs, so that's probably what did it. I use a Paint.NET plug-in now to save to ico format, and it's apparently not doing as good of a job making the 8-bit versions as AWIconsPro was. I set my XP windows desktop to 16-bit (that's as low as it goes) and compared an icon that included 8-bit versions and an icon that didn't, and the one that didn't looked fine. Maybe it'll work in 2k, too?
http://www.mediafire.com/?lmwfiipzclz
http://www.mediafire.com/?lmwfiipzclz