The alternative is using QueryPerformanceCounter, it’s high precision, but it is subject to problems with older hardware (read around), although most bugs are gone by now.

const int UPDATES_PER_SECOND = 25;
const int TICKS_PER_SECOND = 1000; // GetTickCount() dictates 1000 ticks per second
const int TICKS_PER_UPDATE = TICKS_PER_SECOND / FRAMES_PER_SECOND;

So instead of SKIP_TICKS, we would just use TICKS_PER_UPDATE. This is clearer to me because I know what each number is measuring.

Fun find!

The computer metaphor doesn’t translate all that well into OOP.
Like JJ said, as a class in your code, the computer would provide an upgrade method itself, without the need for you to mess with internals. Another possibility would be to have a helper for upgrading. For example, if a computer object would be created via the builder pattern, the builder might as well be the one to ask for upgrades. No need to get rid of encapsulation.

The GUI example:
This case is similar to one I encounter from time to time in programming forums.
The usual situation where someone asks for help is as follows: There is a BaseClass, and SubClass1 and SubClass2 derive from it.
Now, that someone creates a container for objects of BaseClass, containing both objects of the concrete classes SubClass1 and SubClass2. He then asks, for example, how to iterate over the container’s contents and execute specific actions depending on the concrete subtype.
In summary: Abstracting from the concrete classes, and then asking how to break the abstraction again. This can be solved in clean ways – double dispatch and visitor pattern come to mind, so you’re still fine using encapsulation. However, in my experience, most of the time someone does something like this, his/her concept is faulty somewhere.

Now back to the GUI example. Cross-platform GUI toolkits abstract away from the concrete operating systems. By their nature, they must thus provide the lowest common denominator. Now asking how to access an OS-specific function means “you’re doing it wrong” in my opinion. But as I said, this can be solved without breaking encapsulation.

In the past I have used “FPS dependent on Constant Game Speed” (gameboy advanced 60fps) and “Game Speed dependent on Variable FPS” but I think now I want both to be variable! ie, a max display fps can be chosen and a max compute fps can be chosen (ie, 60fps display and 100fps if player accuracy is important). I think the source engine uses something like this (with compute capped to display) and that is the functionality I should aim for.

What would be the prospects of having several fps independant components? should I use semaphores and have the game objects independantly wait on results? – AI for example. or independantly different fps for input, ai, particles, physics, rendering? what could I expect from such an approach and how would I actually control such a thing?