Supporting both is actually a lot easier than most people think. The actual parts of a graphics API that are used are pretty small, and the APIs need to be wrapped up behind a graphics interface for any non-trivial renderer no matter what. Really the hardest part by _far_ is just porting the shaders between the two, but that's where things like Cg come into play.Swtiching from opengl to other thing is not possible, this is a crossplatform software. And newer versions of d3d does not even available to XP, and 9 are old and legacy.
It is more work, yes, but on the other hand if you primarily develop on Windows and port later to OSX/Linux then you'll find that working in D3D natively will save you a lot of head-to-desk moments, lower your blood pressure, and let you keep more of your hair.
I was just at a conference earlier this year (DICE) geared solely towards marketing and business in the games industry, and there was an entire talk by an Activision exec about the "PC gaming is dying" myth. It's an often quoted statistic that's simply based on a misinterpretation of the market numbers. The talk is of course based on actual sales figures from actual AAA games over the last few years; they are very concrete, very objective, and very difficult to argue with.Steam is not AAA-only. I didnt sayd that pc game industry is dieing. Its not. But the pc game AAA level industry does. Its market share decrases in every year, it was on the top around the year 2000, now its basically almost below the detectable statistical margin, when compared to the other segments of the game industry.
AAA game sales for PCs have _increased_ since 2000. All that "market share" means is that for every new PC gamers, there's 3 new console gamers. It does _not_ mean that PC gamers are largely converting to console gamers nor does it mean that there are no new PC gamers. It's just a measure of rate of growth, and while both PC and consoles are growing, consoles are simply growing much faster. Both markets are growing, the console market is just growing much much faster, because it's an easier market to enter (parents are more likely to buy their children a $200 console than they are to buy them a $1000 mid-line game-friendly PC or a $2000 game-friendly laptop, and consoles don't require a high level of expertise and maintenance effort to keep working like Windows/OSX/Linux do).
Keep in mind that as far back as 2000, gaming was still a "nerd" thing to a large degree. Here in 2012 it's not uncommon at all to see whole families playing games, to see popular highschool girls having gaming parties with their cheerleader friends, to see the low-IQ jock-stereotype "bros" getting together for Halo or Madden nights, for middle-aged men and women to be MMO addicts or to be clan leaders in online FPS games, and so on. Gaming is mainstream now, so there's more than enough room for consoles to grow 600% while PC gaming _also_ still grows, because the industry as a whole has exploded in size.
This goes back to identifying the problem: I don't think the size of your engine has much to do with things on the GPU side. When it comes to graphics, the CPU side of your code is not going to have a huge impact, unless you're simply doing things on the CPU that should be on the GPU (e.g., like Skyrim's shadowing system, which is all CPU-side for some mind-fucking-insane reason). Point being, there may be some very small, simple things to rearchitect in your graphics pipeline to get very large increases in performance. Just have to identify if those do exist and if so what they are.This is why its slow: its totally a 2+ mbyte source code written in pure C, and even if i would optimise this mess for a month (sometimes i do it) i just can gain a ~10% performance incrase. Becouse the limitating thing is the engine itself. But it canot be bypassed, becouse without this, i would unable to writte things like maker. So the performance is sacraficed in the name of existence.