[quote]An immediate-mode replacement is nice but what’s the use of it? It’s convenient to draw a triangle but it doesn’t really scale beyond this triangle.
Define “scale”. It’s the simplest way to handle things like text rendering, debug drawing (show me a vector, arrow pointing this way, etc), showing GUI elements, and so on. The setup work necessary to render a line between two arbitrary points is pretty significant without immediate mode. With it, it is trivial.
It’s not intended to scale to rendering large meshes. Not everything you want to render is a large mesh, after all.
[/QUOTE]
Erm so your reason is because immediate mode is easier?
I disagree strongly but that’s hope to you.
[quote]Have you considered using GLI?
I saw it, but I wrote my own instead. I did so for several reasons:
1: GLI has too narrow of a focus. It centers around the texture2D
. That’s great… unless you’re not working with 2D textures. I see no need to have that restriction. Why are 3D textures, cubemaps, arrays, etc forbidden? I know that GL Image currently only implements 1D and 2D textures, but I’m going to start cubemaps soon.
2: Relative difficulty to use. There is no quick and easy way of just telling it to upload a texture2D
to OpenGL. My GL Image library takes of 3 lines to go from a file to an OpenGL texture. And the last one is just a deletion of the glimg::ImageSet object, so if you stick it in a smart pointer, it only takes 2. The SDK is intended for new users. And while I’m totally fine with new users seeing the details of how texture uploading actually works, I would rather they do so in a proper, structured learning environment. IE: my tutorials.
3: Undocumented. This is a deal-breaker for me. The SDK is for a relatively new user, so clear and strong documentation is absolutely paramount.
The other issues are just personal pet-peeves of mine. I don’t get why you needed the GTX vs. core concept here. In GLM, that made sense, as you want a demarcation between what GLSL provides (GLM core) and what additional convenience functions you’ve added.
Also, it’s header-only. Again, in GLM, that made sense, as most of the functions were tiny and templated. texture2D
is not a template. gli::load
is not a template. I just don’t feel that I should have to compile the entire C++ source to a DDS loader, in every .cpp file that I include it in, just to be able to load DDS’s. This is what static libraries are for, after all. Not everything needs to be header-only.
Overall, I just felt that it wasn’t ready for the SDK. GLM is a much more mature tool, while GLI seems to be simply whatever you needed for your examples. Plus, writing an image loader wasn’t that hard. [/QUOTE]
[/QUOTE]
There are some good points and I agree with you. GLI does actually much more but it’s true that it’s not mature at all. I have been working for a long time already on a version 0.4.0 which support 1D, 2D[ARRAY], 3D and cubemap.