SabbraCadabra wrote:
Misery wrote:
And simply because a game is 2D, doesnt mean there isnt alot of stuff going on in the background that has nothing to do with simple display issues.
Sometimes, but usually it's just a case of poor programming. A lot of computers have huge limits these days, so most coders don't care how sloppy and un-optimized their code is, as long as it's running (especially with indie games). Also, by default, XNA requires a card with...I think it was pixel shaders 2.0? There's a way to get around it, but the game has to be programmed that way.
On the opposite side, we have games like Retro City Rampage, which was originally going to be on the NES, until he got tired of struggling with limitations. I can only imagine how clean and concise the final game's code is.
I wish this dumb trend of bloated, un-optimized, resource-intensive programming would come to an end. I mean, it's one thing to code a resource-demanding program if the final output is something impressive (like I dunno, Crysis 3), but it's a whole other thing to make something that should be relatively simple fairly computationally intensive (like Minecraft). I mean, what happened to the demoscene, and its programming ethic? Demoscene programmers write really cool graphical demonstrations, often with really strict size and/or hardware limitations, and as a result their code has to be efficient and concise. Back when the demoscene was a bigger thing, mainly in the 80s and 90s, demoscene programmers would actually sometimes join game development teams, and bring their style of coding into the programming of various games. This lead to some really impressive titles, such as Zero Tolerance on the Sega Genesis/Megadrive, a surprisingly decent FPS for a 16-bit system with a 7MHz CPU and 64k of ram!