My question is more theoretical than practial. I want to understand idea behind OpenGL API design in LWJGL.
For example in Android OpenGL API each following OpenGL API version just extends previous, I mean:
android.opengl.GLES30 extends android.opengl.GLES20
android.opengl.GLES31 extends android.opengl.GLES30
etc
You can see source code here: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/opengl/GLES20.java, http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/opengl/GLES30.java, http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/opengl/GLES31.java
Why in Lwjgl there is no such concept? What is the reason behind such design when I have to use GL11.glDrawElements(); instead of GL43.glDrawElements(); ?
It's a choice they made with LWJGL. Submission of indexed geometry has been around since OpenGL 1.1 and they make it a habit of exposing what was added in later revisions, instead of giving you a cumulative set of entry points, as is common with extension loaders like GLEW.
It doesn't have to be like this (clearly, Google went down a different path and so did others, independent of the programming language) but in the end, it doesn't matter. All that matters is that the entry point is exposed to you. Sometimes it's good to see (and to know) at which point in time a particular API was promoted to core, but dividing stuff up like this can be quite cumbersome for the developer.
If it were defined in another way in the language of your choice and provided that this language supports interfacing with native code, the function you'd be ultimately calling would still be the same, because under the hood, the corresponding function pointer is retrieved with some form of GetProcAddress (depending on the platform, YMMV) and would refer to the same C function defined by the ICD (unless you link directly against an OpenGL implementation, in which case you resolution of function names would either be unnecessary when linking statically, or handled automatically during program load).
Related
For whatever reason, I'm messing around with manual OpenGL extension loading.
Every tutorial I've found recommends first querying the extension string, then parsing it into a list of extensions, and then finally loading the function pointers for supported extensions. It seems to me that this whole process could be reduced to just getting the function pointers and then checking for any NULLs returned by wglGetProcAddress or equivalent.
My question is: What purpose does the intermediate query step serve? Is it possible for a function to be unsupported but for *GetProcAddress to return a non-NULL pointer?
The extension string is the correct way for a GL implementation to tell you about what extensions it supports. Querying pointers for functions which are not implied to be present by the extension string is undefined behavior, as far as the GL is concerned.
In practice, the situation might actually arise. One often has the same GL client side dll for different backends, as it is the case with mesa. The fact that the function is there does not imply that it is implemented for all backend drivers.
What purpose does the intermediate query step serve?
To see, which extension are actually supported by the OpenGL implementation backing the currently active context. Also not all extensions, like new texture formats or shader targets introduce new procedures (functions), but only new tokens. The only way to detect those is by looking at the extension string.
Is it possible for a function to be unsupported but for *GetProcAddress to return a non-NULL pointer?
Yes, this is possible.
I get OpenGL extensions using wglGetProcAddress. But on different machines it use different parameters: e.g. for using glDrawArrays I should call wglGetProcAddress with "glDrawArrays" or "glDrawArraysEXT". How todefine what to use?
There's two pretty good OpenGL extension loading libraries out there - GLee and GLEW. GLEW is currently more up to date that GLee. Even if you don't want to use either of them, they're both open source, so you could do worse than taking a peek on how they do things.
You may also want to check http://www.opengl.org/sdk/ which is a decent collection of OpenGL documentation online.
"glDrawArrays" or "glDrawArraysEXT"
Both! Even if they're named similar, and more often than not procedure signature and token values are identical, they are different extensions, where details may be very well different.
It's ultimately up to the programmer to decide, which functions are used. And if a program uses an …EXT variant of a function, then this very function must be loaded even if there may be a …ARB or core function of same name; they may differ in signature and/or used tokens and state, so you can't mindlessly replace one for another.
I am working on a project with my friend where we have to update existing version of a game which uses SDL 1.2 to use SDL 2.0 header files and functions.
I would like to know what is the standard procedure we follow while updating already existing source code to newer libraries.
The code has 28 source files with 11 header files and makes extensive use of keyboard and mouse events and sounds as well.
All the source files use c++ and sdl.Most source files are around 200 lines of code.
i have a time period of about 3 months to make the changes.I would like to know how to write a basic summary of my schedule for that time period on a week-by week basis or 2 weeks basis.
Can anyone provide me proper steps for the same so I can make a schedule for the same?
I don't know of standard procedures, but here are my thoughts:
In general, I can think of two approaches to porting an existing software to either another language, use of another library, or any change of the such; with minimal structural change
or with major structural change.
Minimal structural change means that you leave the structure of your program intact, and start replacing every single bit of it by its equivalent in the other library. For example, if porting from glut to SDL, you replacing the glut window creation with SDL's, keyboard handling with SDL's etc, all independently.
This method is faster, in the sense that all the changes are small and local. You are also less likely to introduce bugs. The result may not be so efficient though, as the structure of the program is not originally designed for this new library.
Major structural change means that based on the new library, you rewrite a large part of the program that is dependent on that library. For example, if switching from C++'s STL to C's standard libraries, rewriting string with its equivalent in C that keeps allocating/freeing/copying doesn't make sense because your approach should be fundamentally different.
This approach requires a lot more work but in the end will give you a much better quality.
Back to your particular case, I'm not sure how different SDL 2 is from SDL 1.2, but my guess is it's not fundamentally different. Therefore, I believe the first method should work in your case. That is, you should work out the equivalents in SDL 2 of the stuff you did in SDL 1.2, and replace them in your code accordingly.
What is the difference between the functions glGenBuffers()/glBufferData()/etc, and the functions with ARB appended to the function name glGenBuffersARB()/glBufferDataARB()/etc. I tried searching around but no one ever points out the difference, merely they just use one or the other.
Also, is it common for either function to be unavailable on some computers? What's the most common way of getting around that kind of situation without falling back to immediate mode?
glGenBuffers() is a core OpenGL function in OpenGL 1.5 and later; glGenBuffersARB() was an extension implementing the same functionality in earlier versions.
Unless you're developing for an ancient system, there's no longer any reason to use the ARB extension.
Is it possible to implement monkey patching in C++?
Or any other similar approach to that?
Thanks.
Not portably so, and due to the dangers for larger projects you better have good reason.
The Preprocessor is probably the best candidate, due to it's ignorance of the language itself. It can be used to rename attributes, methods and other symbol names - but the replacement is global at least for a single #include or sequence of code.
I've used that before to beat "library diamonds" into submission - Library A and B both importing an OS library S, but in different ways so that some symbols of S would be identically named but different. (namespaces were out of the question, for they'd have much more far-reaching consequences).
Similary, you can replace symbol names with compatible-but-superior classes.
e.g. in VC, #import generates an import library that uses _bstr_t as type adapter. In one project I've successfully replaced these _bstr_t uses with a compatible-enough class that interoperated better with other code, just be #define'ing _bstr_t as my replacement class for the #import.
Patching the Virtual Method Table - either replacing the entire VMT or individual methods - is somethign else I've come across. It requires good understanding of how your compiler implements VMTs. I wouldn't do that in a real life project, because it depends on compiler internals, and you don't get any warning when thigns have changed. It's a fun exercise to learn about the implementation details of C++, though. One application would be switching at runtime from an initializer/loader stub to a full - or even data-dependent - implementation.
Generating code on the fly is common in certain scenarios, such as forwarding/filtering COM Interface calls or mapping OS Window Handles to library objects. I'm not sure if this is still "monkey-patching", as it isn't really toying with the language itself.
To add to other answers, consider that any function exposed through a shared object or DLL (depending on platform) can be overridden at run-time. Linux provides the LD_PRELOAD environment variable, which can specify a shared object to load after all others, which can be used to override arbitrary function definitions. It's actually about the best way to provide a "mock object" for unit-testing purposes, since it is not really invasive. However, unlike other forms of monkey-patching, be aware that a change like this is global. You can't specify one particular call to be different, without impacting other calls.
Considering the "guerilla third-party library use" aspect of monkey-patching, C++ offers a number of facilities:
const_cast lets you work around zealous const declarations.
#define private public prior to header inclusion lets you access private members.
subclassing and use Parent::protected_field lets you access protected members.
you can redefine a number of things at link time.
If the third party content you're working around is provided already compiled, though, most of the things feasible in dynamic languages isn't as easy, and often isn't possible at all.
I suppose it depends what you want to do. If you've already linked your program, you're gonna have a hard time replacing anything (short of actually changing the instructions in memory, which might be a stretch as well). However, before this happens, there are options. If you have a dynamically linked program, you can alter the way the linker operates (e.g. LD_LIBRARY_PATH environment variable) and have it link something else than the intended library.
Have a look at valgrind for example, which replaces (among alot of other magic stuff it's dealing with) the standard memory allocation mechanisms.
As monkey patching refers to dynamically changing code, I can't imagine how this could be implemented in C++...