A problem I get into at the end of the second article is that gamma-correction is very important for good image scaling results. However, almost nobody gamma corrects during scaling, even today.
The simplest kind of mipmapping is a box filter, where you are just averaging 4 pixel values at once into a new pixel value. Thinking just of grayscale pixels, if you add 4 pixels that are each 1.0 (if you are thinking in 8 bits, 1.0 == 255), and divide by 4, you get 1.0 again. If you add two pixels that are 1.0, and two that are 0, you get a value of 0.5. Which would be fine if your bitmap were stored in units that are linear with the actual intensity of light; but they are not, because they are in a weird gamma! What you are going to get is something like pow(0.5, 2.2) which is way too dark.
Thus when you don't gamma-correct during mipmapping, bright things lose definition and smudge into dim things way more than actually happens in real-life when you see objects from far away.
That is true for common sRGB images, such as what you would see on the web. But for games which usually have tightly controlled art pipeline it would not be unfeasible to use linear colorspace bitmaps as textures, and in such case you would not need to have gamma-aware scaling.
In general, games only use light-linear texture maps when they also need HDR in the source texture, which is not that often. Ideally it is "purest" to use HDR for all source textures, but nobody does this because of the big impact on data size. (And even for the few textures that are stored as HDR source, often the data will not be integer, but some other slightly-more-complex encoding.)
[Claimer: I have been making 3D games professionally for 17 years, so this information is accurate.]
This is a great observation.
Standard res RGB monitors are not as crisp as PC monitors. But they are still quite nice and really do let the individual pixels shine through.
Most retro gamers now typically hook up their consoles via SCART to a CRT that accepts pure RGB, typically a Sony PVM. I've got all my consoles and my arcade boards running on a PVM and can really easily see the pixels making up the art.
here's a few examples I grabbed off the web: http://imgur.com/a/GXHyf They look even better in person.
Yeah most emulators provide filters that give you scan lines and all that jazz (none of them look quite right). And of course an RGB monitor does not look at all like an old game running in a modern emulator with no filters. But I would still definitely say you can see and appreciate each individual pixel.
One, I did not understood it well enough to try to explain even the basics.
Two, I could not find a binary or source I could compile easily to make a example image.
Also you can put a "three" there: it is not widely used, while even the recent xBR has a couple of plug-in implementations on emulators for example (and has binaries)
EDIT: Lack of binary is also why I did not made sections for 2xSal, SuperEagle and so on... If people help me finding that kind of stuff or creating the needed images, I will gladly update the article.
edit: comparison http://imgur.com/a/fC8iQ#1
Those are what I mention in my article (TVs that have triangle pixels composed of 3 circles)
I never use current CRTs emulation because I guess I never saw TVs that could be emulated, I think all CRT TVs I saw consoles running were of shadow mask type, having almost no scanline (and I was a curious child that used to put amplifying lenses in front of TVs to see their pixels...)
We even took the exact same artwork and made an 8 foot tall banner with it, and it looks great!
Our backgrounds for example frequently feature "digital painting" style, with stuff that is outright impossible to do in vector.
Of course, it does work almost perfectly for downscaling, because in this case we're not creating any edges, just reconstructing the original edges -- an those vary at most once every pixel.
The math does not really know the difference between upscaling and downscaling.
Most typically in that domain you also use windowed sinc filters and there's a ton of literature on the tradeoffs of specific window designs, as well as very fast fixed point implementations etc.
It's all pretty interesting stuff and trying to make it run efficiently on modern mobile hardware is a fun challenge.
It's a look at kind of a interpolation weighted by scale2x.