   The graphics programming/apis evolution
  Not really a question, just a bunch of thoughts I wanted to share to "hear" your opinions, expecially from the point of view of the elder coders.I began working with graphics/game programming back in 1992. The target screen resolution was 320x200x256 colors (8 bit), DOS was the environment and coding 3d engines meant knowing a heap of trigonometric algebra, plus a good deal of assembly language to speed up things.When the first 3d hw came out, some years later, I approached OpenGL and what I found out left me with a mix of enthusiasm and discomfort: suddenly all I needed to draw a res-independent gouraud-shaded triangle onscreen was some function calls - whereas for years I had to write down hundred lines of super optimized code only to efficiently plot a coloured line in fixed resolution. It was like all my efforts were ridiculed by that high level api and its sheer simplicity, then I realized the possibilities and went on rewriting my 3d engines with greater freedom and results.The years passed. OpenGL 1.5, 2.0, DirectX 7, DirectX 10. Yet, something is amiss: the big leap, the simplification, the grouping of widely used techniques into simple to use high level functions. That "WOW, now I can leave migraineous algorithms behind and just think about gameplay" effect.Take Shadowmapping. Everyone uses shadowmapping, it's a must, it's a need for 90% of the 3d apps out there, like once drawing a single coloured triangle was. It's something sooner or later you have to pass through, and yet it's still extremely complex. Go on the DirectX subforum and you'll see tons of requests on shadowmapping with all sorts of issues, bugs, doubts. That because it's difficult to achieve and requires a good deal of knowledge, like it was seventeen years ago... if you wanted to draw that damn single coloured triangle.So, in a sense thanks to programmable shaders we are now - again - in the situation we had when we coded everything in pure software: we had control over the single pixel, over the whole "pipeline" that brought that little dot onscreen at given coordinates. All that freedom was mantained, yet wrapped in higher level functions to help the next generation of coders and free them from need to worry about microscopic details if they didn't want to.Don't you think it's time for another wave of high level wrapping, still mantaining the low level control through HLSL and such (the equivalent of 20-years-ago-assembly)?   
  Your description fits many rendering engines. No one forces you to implement shadowmapping and mesh rendering from scratch. You can fetch Ogre3D SDK or something and just code the game, caring less about the actual graphics rendering.   ;Quote:Original post by i_luv_cplusplusYour description fits many rendering engines. No one forces you to implement shadowmapping and mesh rendering from scratch. You can fetch Ogre3D SDK or something and just code the game, caring less about the actual graphics rendering.Of course, that's the purpose of an engine. That's what we did, even in the pure software days, we built groups of high level functions. DrawTriangle(a,b,c), so to say. But engines are built over the API layer. And what I am envisioning is a set of higher level functions "standardized" at that level, the API level.   ;Quote:Original post by resleOf course, that's the purpose of an engine. But engines are built over the API layer. And what I am envisioning is a set of higher leve functions "standardized" at that level, the API level.In fact, that's exactly the opposite of what is currently happening. The current trend is to simplify APIs, remove unneeded high level mechanisms and basically be left with a bare bones thin layer to the hardware. Just look at OpenGL 3.x. And this is a good thing, because it emphasizes the two most important aspects of a graphics API: performance and flexibility. Every high level mechanism you add takes away flexibility and introduces overhead. Take your example of shadow mapping. There is no "shadow mapping algorithm". There are hundreds of different algorithms that could fit into the shadow mapping category, and new ones are being added regularly. Not every algorithm performs well in each situation. One that is very well suited for a certain type of 3D environment or scene can be totally unusable with another. There is just no way to add a "standard" shadow mapping algorithm to an API, because it will only fit a small minority of usage cases.The same reasoning applies to the fixed function pipeline versus shaders. The FFP could be thought as a high level shader API (even though it was obviously a technical limitation of the time). Yet, by being so high level, it lacks all the flexibility that todays do-it-yourself shaders allow.Basically, if you need high level, then an entire engine is the way to go.   