> Just wondering, why are only uneven scale factors used and not also even factors?

Resizing is done by color averaging. If there's no remap, shadow, or bg, it's a simple average. But let's say there's some bg: if the factor is 3, you'll have a 3x3 square, which is 9 pixels.
If there's, eg, 5 bg pixels then no averagin is done and the destination pixel is bg. If there's maybe 6 "easy" colors, they're averaged. The thing is that there's never a case where the number of bg and other colors is equal. Example: with a factor of 2, a 2x2 square has 4 pixels. Suppose there's 2 bg and 2 of other colors.

> And you said your resizer is faster. But is that with or without SHP compression?

Compression is always on. The trick is that the data is resized before conversion to SHP. The obvious disadvantage is that you can only have integer downsize factors, and no upsize factors. But hey, it's meant for AA, no for enlarging/shrinking images.

I think you're conversion is faster though, since mine seems to be slow with smaller images and downsize factor of 1.

> > I encourage you to make fun of the UI, which is openGL.

> Why did you use OpenGL?

It's all I know. I started playing with it 2 years ago and never really learned WinApi. Plus I use PellesC, which is not only C but also doesn't have that tremendous win AFX library (or whatever it was called).

> > Binary file IO sure was easier then I thought. I was kind of afraid of it, to be honest.

meselfs himself!