ciomalau: some people here is talk about upscaling - i don't know if this counts but there is a game on gog tomb raider 1 which came out in 1996. however i play that on 1920 x 1080 resolution and i'm sure such high res didn't exist back then in 96
Trilarion: That's why you can be sure that this resolution is an upscaled pseudo resolution, not the effective resolution or level of detail that is contained in the displayed images. That's why it's not very meaningfull to only count on the resolution of the monitor (it could even be a 4k pixel monitor). If the signal that reaches the monitor has not enough details / resolution then also a high resolution monitor cannot display a better graphics.
In principle your Tomb Raider 1 should not look (much) better than the original Tomb Raider 1 from 1996 on the screens available back then. Or does it?
Oooh! You're so close! :p All, right, not really.
But yes, Tomb-raider, a various number of crystal dynamics games, etc., can run in resolutions that are much higher than what you had available on a monitor back then. And still not get the "scaling" artefacts you expect. Early 3d games in general tend to have this curious feature.
Until you find that one single 256x256 static texture they used for a specific object that was difficult to draw with cubes and half-circles - and it looks like someone blew up a minecraft guy. But everything else looks fine, or at least as bad/good as it did back then. Fairly often you actually also see UI that has vector-graphics or is made up of scalable elements. So when you change the resolution, they might get a bit crunched, or stretch in a different way, but they're still functional and get stuck on the right side of the screen, etc.
On the other hand, when you start to get a little bit newer games than that, with much larger amounts of textures and static resources, they look absolutely horrible all round in higher resolutions. There are.. not many exceptions to that. Take the tie-fighter collector's cd-rom (the actual one, not the crap they re-released) for example. It could theoretically scale upwards (apart from the cockpit drawing), while the so-called "3d version" couldn't. Because that has very specific textures painted on the hull of all the ships to mask the crappy models, and once you start to scale that up, it just becomes ugly blocks.
The reason for all of that is:
1. All of those early games were made for graphics cards that had ram-sizes like this
http://www.vgamuseum.info/images/palcal/3dfx/808_generic_3920465a1_600-0012-04_voodoo1_top_hq.jpg Count the 512Kb chips. That's right - 4Mb. Who would possibly want to use more than that on /computer graphics/? :p Seriously, though -- In truth, drawing the objects that then are masked with textures are proportionally speaking smaller in the used ram now than they used to be back then.
2. After a certain point in time, no "full game" is ever on a size lower than at least one cd-rom. Worse, if the game was particularly large, it would still be on a cd-rom, just with more texture compression. Because now people start to replace geometry with static resources completely on purpose. It's like a resurgence of 2.5d, just with better sprites.
3. A lot of these early games were "multiplatform". Yes, that's right, they were made to run on different hardware and different resolutions (and form-factors) in the first place. Garage-developers with two people managed to account for that for the most part, between the dreamcast, pc, 2d and 3d-versions and different apis.
4. People didn't use static resources, and didn't build entire levels of reusable bits by hand, and then run it through the sdk so it puts 50.000 variants of a tree in different resource files to be loaded one after the other. You could probably say that, well, that's why the games are so ugly, right? That they don't have fifty million trees in separate models. No one wants to see the same tree used over and over again?
And then you run into something like randomly slotted tilesets. Or shadows on objects that actually are generated in real-time instead of crafted with a colour-filter plus a shader anchored to a fixed point (so that if you saw it outside the cutscene, it would look ridiculous). Or mobile games with real-time physics and weight and direction-based shaders. That weighs in at a whooping 100mb. And you realize that it is actually possible to make very complex looking geometry with just location data for all the squares and half-cubes before you even approach the cost of a single texture.
Meanwhile, the reason why you get these "remastered" games in upscale (unless they actually go back and redo or repackage the original resources). And the reason why people prefer that over actually increasing the resolution on "low res assets" is because the static resources don't scale well. They're just meant for a very specific context.
In a way, it's the precursor for the current industry: publishers who rather pay huge amounts of money to repackage the game for all the "targets" the game is supposed to release on (to justify their existence). Rather than spend money on having a developer create a toolchain that can output in different targets. This is 100% analogous to the current "ideal" where "AAA" developers tend to have very, very large budgets on pre-production and art assets. Even if they actually don't end up being used - or if they are used, they're not actually depicted in the detail the artist actually made them in (to fit it on the hardware limitations, and blabla - the simple engine of course had /nothing/ to do with it...). And where not using that approach is the domain of "indie developers". Even though, as we see more and more, those indie developers can create target outputs that are visually speaking very similar. And sometimes also much better and more believable - when also counting what happens outside the cutscenes.
Basically: static resources vs. geometry and scalars. Welcome to 1994, people. :)