const values like that are basically variables that the compiler doesn't allow you to change. I see them as a way to make sure you don't accidentally change something that shouldn't be changed (such as a function that takes a const char *, where the contents of the string must not be changed), rather than helping the compiler to optimise. There may or may not be additional optimisations possible for const values, I don't know. But they're definitely not the same as actually putting the value in the code when it's compiled, and they can't be optimised in quite the same way.

For example, assembly for two member functions for calculating the offset in an array ( int calc(int x, int y){return y*XRES+x;} ), compiled using -O3.

This one uses a const member variable, exactly as in your Foo class (yes, I realise the two mov's at the start won't occur if calculating lots of offsets at once, it'll be stored in a register, but take this as a demonstration that extra instructions are likely and that this type of const behaves rather like a variable, and see paragraph below about spare registers).

mov    0x4(%esp),%edx
mov    0xc(%esp),%eax
imul   (%edx),%eax
add    0x8(%esp),%eax
ret    

This one uses a global variable "const int XRES=612;", which cannot be changed at runtime:

imul   $0x264,0xc(%esp),%eax
add    0x8(%esp),%eax
ret    

Removing most of the memory fetches for const variables only applies if there are enough spare registers to hold it. With the number of variables flying around in TPT, that may not be the case, or may cause some of the other variables to be saved and reloaded from memory. However, the compiler reduces memory fetches for normal variables too, this isn't unique to const variables. Variables aren't fetched from memory every time by default, "volatile" is needed to give that behaviour.

As for improving performance, I'll believe that when I see it. My instinct is that either data and instruction cache friendliness will both be poor, or data will be worse than instruction. There's a lot of jumping around in instruction memory with all those function pointers, but there's also a lot of jumping around in data memory in the pmap and parts arrays. I might go and run cachegrind and find out.

jacob1 removed a lot of unnecessary bounds checks which used XRES and YRES after I did that test, so it may well be a smaller (but still unwelcome) slowdown now.

More recent test results would be nice, but it's a lot of work.