3D Drawing - Which way to go? - Developers

Hi I'm just in the middle of developing a really quite small app which is basically a Tenori-On sequencer. I want to go for the style of 'simple and graphical' kinda like AudioSurf in the way that it's extremely pretty but a relatively simple concept. Anyway, there seem to be a stupendous amount of options in regards to how to go about drawing 3D elements. At the moment, I am using SDL and OpenGL which works alright but a few things have confused me so far and was hoping I could get some help clearing it up. gl.h and glu.h seem to ship with windows and are basically standard headers, however alot of example programs I can find (tutorials etc) also use GLUT. This doesn't seem avaliable to me. I found a windows port [url='http://www.xmission.com/~nate/glut.html']here[/url] which seemed to work alright but then started noticing that these things are extremely old and/or deprecated (GLUT expired at around 2000, OpenGLUT in 2005). OpenGL itself has different versions (4.1 released in 2010) while the only one I seem to be able to use is an incredibly old 1.1 or 2.1 (not sure). I looked at using some newer versions of OpenGL and it seems for any functions you want to use you have to manually get the function pointers for. SDL itself seems to manage windows and such alright, however another thing that ended up being a bit odd was MFC. To output sound for this, for now at least, I'm directly sending notes to the default MIDI device, for this to work it requires MFC classes for the Windows-ness and it can get a bit messy as some of the SDL headers like to #include <windows.h>, but MFC doesn't like that at all. For now I've gone around all the libraries and such that do include that but I think I might end up making a dll for the midi stuff and it can have it's own class and such so the main program shouldn't need to worry about MFC. I still don't know what ATL is. I saw a few articles and such recomending XNA and C# for a more managed way of doing things, is this a good idea? [url='http://waddles.teamawol.info/files/154_MidiTest.zip']This[/url] is what I've come up with so far but my question is this. tl;dr--- What interface/framework/library do people use and/or recomend for modern 3D development?

I would personally recommend OpenGL as there's still a lot you can do with OGL 2, it is just a bit more of a bitch to work with but I find it to be a bit more cross-platform compatible.

I actually use OpenGL myself, although I generally don't program on Windows. Most of my OGL stuff has been on Linux and Android. Microsoft doesn't want to encourage OpenGL use (or cross-platform development in general), so it makes sense that they wouldn't include the proper header files in MSVC. In regards to GLUT, I've never needed to use it. Most tutorials use it for opening windows and a few convenience functions because it's generally available. If you're using SDL, then you certainly don't need GLUT to open windows and the convenience functions are generally of marginal value. As for manually loading function pointers, you probably don't [i]need to [/i]with proper OpenGL headers. The reason this is generally done at run-time is because it allows for backwards-compatibility and fallback rendering pipelines. If you link the functions directly at compile-time your program will not function at all on computers that don't support the extensions you use. This problem isn't specific to OpenGL, it's common to anything written in a compiled language. There is a common library for loading OpenGL extensions at run-time called GLEW. Also, look into SDL_Audio. It's very easy to use, even if it is somewhat limited in its capabilities. OpenAL might be another, more powerful, option.

[QUOTE=ROBO_DONUT;29432073]I actually use OpenGL myself, although I generally don't program on Windows. Most of my OGL stuff has been on Linux and Android. Microsoft doesn't want to encourage OpenGL use (or cross-platform development in general), so it makes sense that they wouldn't include the proper header files in MSVC. In regards to GLUT, I've never needed to use it. Most tutorials use it for opening windows and a few convenience functions because it's generally available. If you're using SDL, then you certainly don't need GLUT to open windows and the convenience functions are generally of marginal value. As for manually loading function pointers, you probably don't [i]need to [/i]with proper OpenGL headers. The reason this is generally done at run-time is because it allows for backwards-compatibility and fallback rendering pipelines. If you link the functions directly at compile-time your program will not function at all on computers that don't support the extensions you use. This problem isn't specific to OpenGL, it's common to anything written in a compiled language. There is a common library for loading OpenGL extensions at run-time called GLEW.[/QUOTE] I am fairly sure that there is no way to statically link with OpenGL functions, but you're right about using the proper headers. You should use the latest headers, available on the OpenGL site.

Ok, thanks guys. Very informative. If I do end up needing to use newer features for OpenGL (which I doubt), I will probably end up using GLEW. [url='http://www.opengl.org/wiki/Getting_started#Accessing_OpenGL_functions']This[/url] page on the OGL wiki had me worried but it seems it should be fine.

I would not be writing anything in OpenGL 1.0 at this point. It's nothing like modern OpenGL at all. Go for OpenGL >=3.0 or OpenGL ES >=2.0. Previous versions of OpenGL still support the fixed-function pipeline which is both deprecated and horribly inflexible. [QUOTE=Overv;29432143]I am fairly sure that there is no way to statically link with OpenGL functions, but you're right about using the proper headers. You should use the latest headers, available on the OpenGL site.[/QUOTE] I thought I had at one point, but I could be mistaken (and if I had, it might not have been correct/portable). It's been nearly two years since I did anything in OpenGL with C, although I've done plenty in Python/Java where the extension loading is done for you.

Oh man. I remember seeing OGL 1. It still had traces of DNA from IRIS GL swimming around in it.

I actually checked the version of OpenGL my program currently runs at (for me at least) and it seems to use OpenGL 3.3.0 It doesn't seem like something that I can just switch around. [quote="OpenGL Wiki"]Also, there are no updated gl.h and opengl32.lib file. These are stuck at GL 1.1 and will be forever.[/quote]

[QUOTE=Tracker;29432786]I actually checked the version of OpenGL my program currently runs at (for me at least) and it seems to use OpenGL 3.3.0 It doesn't seem like something that I can just switch around.[/QUOTE] The API doesn't switch revisions. You decide which subset of the API you are going to be working in and read which functions are included in the OpenGL reference for that revision. Basically, your video card driver implements everything it can and it's up to you to decide what you actually want to use. The OpenGL wiki says that anything above GL1.1 can be accessed through extensions. You can load GL3.0 stuff through GLEW.

That's what GLEW is for; extensions give you access to modern features. The other major modern aspect, the newer shader syntax, is not even compiled with your program.

[QUOTE=Overv;29432143]I am fairly sure that there is no way to statically link with OpenGL functions[/QUOTE] Not "statically link" in the sense of linking to a static library, but in the sense of a normal compiled-in reference to a DLL symbol rather than a runtime lookup of a function pointer.

[QUOTE=Wyzard;29443181]Not "statically link" in the sense of linking to a static library, but in the sense of a normal compiled-in reference to a DLL symbol rather than a runtime lookup of a function pointer.[/QUOTE] Could you link to a document that describes how to do that?

I'm talking about an ordinary call to a function declared in a header file. In the compiled program, it produces an external reference that the dynamic linker will fill in (with an address from a DLL) before the program starts running. If the DLL doesn't contain a function by that name, the dynamic linker throws an error and the program fails to start. Contrast with using something like wglGetProcAddress(), where you can compile and run the program on a system where the desired function doesn't exist, but you have to do the lookup manually, and account for the possibility that it might return null. OpenGL extension functions aren't necessarily declared in the header, so you have to look them up at runtime. That's what GLEW is for. In later GL versions, those same functions may be built-in, declared in the header, so you can just call them normally and trust that they'll be present in the OpenGL DLL when your program is run.