the first would be majorly based on the fact that it is frustrating that a “graphical” libray contains native support only for bitmap, i suggest you could provide functions for loading and maintaining more image types like TGA, TIFF, JPEG and JPG, and also handle things like image compression transparently.
Secondly i would suggest a clearer way of switching from 3D to 2D, as calls to Glortho can be lenghty and boring to write, of course you can call me lazy but its that sort of functionality that make things better when you dont have time to make reusable code.
First, I’ll address the second point. Calls to glOrtho aren’t any slower than calls to gluPerspective or glFustrum. All they do is set various hardware registers. There is no 3D or 2D mode; there are simply various transforms of the perspective matrix.
Secondly, OpenGL doesn’t support bitmaps. It supports giving it the most basic, fundamental information required for use as a texture. This information can also be used for functions like glBitmap. But, OpenGL is primarily a 3D library, so I would say that functions like glBitmap should probably be done away with.
In any case, no current hardware deals natively with decompression of various common file formats (like TGA, JPEG, etc). OpenGL should not deal with loading things from files; after all, what would those functions do on a device that has no files? In any event, driver writters would have to waste a lot of time writing code that is freely avaliable on the net to load various formats and transform them into suitable texture formats.
As for texture compression, the hardware already does that pretty transparently. The texture compression extension simply allows you to specify a particular compressed format, and the driver will do the compression for you. The user doesn’t have to do anything more than ask.
OpenGL should not contain any file loading capabilities, there are enough image loading libs out there, and it would be stupid to put this functionality into OpenGL (platform dependency (little endian - big endian issues usw.))
And as far as 3D or 2D does: there is no 2D in OpenGL. OpenGL has a pipeline which handles 3D data, and in one in the final steps those 3D “data” is projected onto a 2D place(to be displayed on the monitor). perspective and orthogonal projections are 2 common types, so OpenGL has a function to auto setup such projections instead of calculating the projection matrix by hand.
OpenGL is not supposed to be “all things a programmer even needs” but a 3D graphics library.
In fact, all i am asking is API functionality not hardware accelerated file loading, you may have missed my point here. I am perplex as to see that kind of reaction, because if you look into directx those features are supported, just take the native model importer *.x", maybe it would make sense for people that dont give a… about model optimization and the likes, i only want objectivity here. What i sense from your posts is old timer paranoia that your art is beginning to be more open to the grand public. because everything comes down to functionality over optimisation 70% of the time.
Well, I don’t think moving file loading stuff into OpenGL is the right thing to do. However, there could of course be file loading utils in something like glu/glaux, but I don’t think it has any place in the core API.
The OpenGL community has always been very supportive of hobbyists, but at the end of the day it’s driven by the needs of professionals, and “I couldn’t be bothered to link with more than one library” isn’t going to persuade anybody. (I’m just a hobbyist myself, btw.)
OpenGL implementations are (mostly) built by IHVs; therefore, it makes sense to restrict the interface to stuff that only they can do, or that they can do better than anybody else. Once you start piling “convenient” features on top of this, you just get bloat, loss of focus, wasted time for the IHV’s engineers, and wheels being reinvented over and over and over again. Loading an image file has nothing to do with your graphics subsystem, so there’s no reason whatsoever to shovel it in there.
As for “if you look into directx”… DirectX is, essentially, a game operating system. OpenGL is an immediate-mode rendering API. Comparing the two is a bit daft.
