Menu
▾
▴
glsdk-devel — Main development list for the OpenGL SDK
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(248) |
Sep
(51) |
Oct
(9) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Jason M. <ko...@gm...> - 2008-09-22 02:57:25
|
So, GLE is progressing. I have added GLE to the CMake build, and it seems to build. I even ran the library through a test application; it seems to work. However, I can make no guarantees as to how well it actually works outside of Win32. I started off making GLE with the assumption that I'd be able to #include gl.h as part of it. Of course, the Windows version of gl.h includes 1.0, 1.1, and even defines some things for a few extensions. It isn't exactly consistent about how this stuff gets defined, and I suspect that non-Windows versions of gl.h include different stuff defined in different ways. In short, the only conclusion I can come to in the long term is to fully replace the gl.h include with one we create ourselves. This is how GLEW works. My main concern with this is how functions are defined in the different versions. Windows defines its function entrypoints for the stuff in gl.h, not as function pointers, but as live functions. I doubt that wglGetExtension will work for them. So I'm not entirely sure how to go about handling this part. Any suggestions? In the short term though, GLE will load all of the 2.1 or 3.0 core features. I haven't tested it on GL 3.0, but I know the loading code works in 2.1. It doesn't load any WGL stuff yet; that's my next task, which shouldn't be too difficult. |
|
From: Jason M. <ko...@gm...> - 2008-09-15 18:44:56
|
On Mon, Sep 15, 2008 at 10:44 AM, Camilla Berglund < cam...@gm...> wrote: > Branan Riley wrote: > > GLX supports extensions natively. You don't need a context to see what > > extensions are available, or to get the GLX entrypoints, IIRC. > > GLX extensions are not the same as OpenGL extensions. It doesn't make > any sense to retrieve GL extensions without a context, as at that > point the renderer hasn't been chosen yet. > > By the way, why not layer GLE on top of GLFW? What exactly do you mean by layering GLE on top of GLFW? Do you mean that GLE should be called by GLFW? I don't think that's such a good idea. I would like GLE to be something that can be used regardless of how one creates a context. Now, it's OK if GLFW called GLE on its own, but GLE should be exposed to the user in case they want to do special context creation stuff. |
|
From: Jason M. <ko...@gm...> - 2008-09-15 18:41:12
|
On Sun, Sep 14, 2008 at 9:16 PM, Branan Riley <br...@gm...> wrote: > Shouldn't the extension string returned by the GL only include the > extensions for the context version anyway? Is there really a need to set the > version twice? (Once for context and once for extensions) > > GLX supports extensions natively. You don't need a context to see what > extensions are available, or to get the GLX entrypoints, IIRC. > I suppose we can determine the version automatically, by checking what the context says. And we can say that gleLoadWinFunctions() needs a valid context only in Win32. |
|
From: Branan R. <br...@gm...> - 2008-09-15 18:11:25
|
I'm sure most of you have noticed by now, but the OpenGL man page source has been released: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=245768#Post245768 . It doesn't say anything about license, and I haven't checked it out from SVN to actually see what the license is. It looks like it's 2.1 only for now, though. Branan |
|
From: Camilla B. <cam...@gm...> - 2008-09-15 17:44:44
|
Branan Riley wrote: > GLX supports extensions natively. You don't need a context to see what > extensions are available, or to get the GLX entrypoints, IIRC. GLX extensions are not the same as OpenGL extensions. It doesn't make any sense to retrieve GL extensions without a context, as at that point the renderer hasn't been chosen yet. By the way, why not layer GLE on top of GLFW? Regards, elmindreda |
|
From: Branan R. <br...@gm...> - 2008-09-15 04:16:14
|
Shouldn't the extension string returned by the GL only include the extensions for the context version anyway? Is there really a need to set the version twice? (Once for context and once for extensions) GLX supports extensions natively. You don't need a context to see what extensions are available, or to get the GLX entrypoints, IIRC. On Sat, Sep 13, 2008 at 1:08 PM, Jason McKesson <ko...@gm...> wrote: > OK, so I've finished with the parsing work. I can gather up a list of > enums and extension entrypoints for GL, WGL, and GLX. I even have some > preliminary code generation scripts. > > But, as I started actually generating code, I came to realize that there > are larger questions that we should probably discuss before I take an > action. > > Here is my plan for how GLE will work from a user perspective. > > The API will provide this interface function: > > gleLoadFunctions(GLint majorVersion, GLint minorVersion); > > This will load all functions and extensions up to the given GL version. > It will work similarly to the way ARB_create_context is specified to do. > That is, if the version given is 2.1 or less, it will load whatever > extensions and functions it can up to version 2.1. This includes the > core extensions released with 3.0. If the version is 3.0 or greater, it > will load exactly and only that version and whatever extensions apply to > it. Giving it the wrong version for the current GL context (2.1 context > but 3.0 loading) then this function will return an error. > > We will provide headers that expose enums and entrypoints, but they will > be versioned. There will be a 2.1 header that exposes 2.1 appropriate > functions and enums, and there will be a 3.0 version. When 3.1 comes > out, there will be a version for that too which is separate from the > others. > > If the ARB decides to release a new version that is backwards compatible > with the old one, (if they decide not to remove the deprecated features > in 3.0 for the 3.1 release) then we will still have separate headers, > but one can simply #include the other. > > This all does not mean that headers from one version cannot be used with > another version. For example, if 3.1 does remove the deprecated > features, you can still use the 3.0 headers; what matters is what > context you create and what version you pass to gleLoadFunctions. > > BTW, I call it "load functions" rather than "load extensions" for > marketing reasons. Since you have to use this just to use any modern GL > version, it sounds silly to a GL newbie to call these things "extensions." > > Speaking of context creation, I don't know how it works in GLX, but WGL > creates a certain stress on the creation of contexts. Often, when making > a GL context, you want to create a fake context just so that you can get > access to wglGetExtensionsStringARB and load the WGL extensions. > > Because of that, it is useful to have the following function: > > gleLoadWinFunctions(); > > This loads only the WGL/GLX extensions. It requires a valid GL context, > but you can destroy that context afterwards and the WGL/GLX functions > should still be available. > > The API will also provide global variables, one per extension, which > will be 0 if the extension is not available and 1 if it is. These > variables will only be viable if one of the two load function calls has > been made. > > The structure of the headers will look like this: > > gle_2_1.h > gle_3_0.h > gle_wgl.h > gle_glx.h > gle_main.h > > The first two headers are for the core GL enums and functions. The next > two are for WGL/GLX enums and functions. gle_main.h is where > gleLoadFunctions and gleLoadWinFunctions is defined. Any header that > contains enums and functions will also define the global variables that > one uses to tell whether the extension is available, but only for those > extensions that it has. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > |
|
From: H. H. <hen...@gm...> - 2008-09-13 21:44:07
|
Hello, The GLM mathlib is now mostly done and ready. I submitted a patch written by Vesa Tuomiaro which fixes the glmMatLookAt problem. Apidocs are also mostly written too. I feel I would like to move on to something new now. Some people in the OpenGL forums have requested us to do a C++ bindings to the mathlib. While we agreed that the OpenGL SDK should be written in C, do you think we should do something like this? I would be willing and interested in doing this and I think I could get it working in a week or two. -- Henri 'henux' Häkkinen |
|
From: Jason M. <ko...@gm...> - 2008-09-13 20:07:53
|
OK, so I've finished with the parsing work. I can gather up a list of enums and extension entrypoints for GL, WGL, and GLX. I even have some preliminary code generation scripts. But, as I started actually generating code, I came to realize that there are larger questions that we should probably discuss before I take an action. Here is my plan for how GLE will work from a user perspective. The API will provide this interface function: gleLoadFunctions(GLint majorVersion, GLint minorVersion); This will load all functions and extensions up to the given GL version. It will work similarly to the way ARB_create_context is specified to do. That is, if the version given is 2.1 or less, it will load whatever extensions and functions it can up to version 2.1. This includes the core extensions released with 3.0. If the version is 3.0 or greater, it will load exactly and only that version and whatever extensions apply to it. Giving it the wrong version for the current GL context (2.1 context but 3.0 loading) then this function will return an error. We will provide headers that expose enums and entrypoints, but they will be versioned. There will be a 2.1 header that exposes 2.1 appropriate functions and enums, and there will be a 3.0 version. When 3.1 comes out, there will be a version for that too which is separate from the others. If the ARB decides to release a new version that is backwards compatible with the old one, (if they decide not to remove the deprecated features in 3.0 for the 3.1 release) then we will still have separate headers, but one can simply #include the other. This all does not mean that headers from one version cannot be used with another version. For example, if 3.1 does remove the deprecated features, you can still use the 3.0 headers; what matters is what context you create and what version you pass to gleLoadFunctions. BTW, I call it "load functions" rather than "load extensions" for marketing reasons. Since you have to use this just to use any modern GL version, it sounds silly to a GL newbie to call these things "extensions." Speaking of context creation, I don't know how it works in GLX, but WGL creates a certain stress on the creation of contexts. Often, when making a GL context, you want to create a fake context just so that you can get access to wglGetExtensionsStringARB and load the WGL extensions. Because of that, it is useful to have the following function: gleLoadWinFunctions(); This loads only the WGL/GLX extensions. It requires a valid GL context, but you can destroy that context afterwards and the WGL/GLX functions should still be available. The API will also provide global variables, one per extension, which will be 0 if the extension is not available and 1 if it is. These variables will only be viable if one of the two load function calls has been made. The structure of the headers will look like this: gle_2_1.h gle_3_0.h gle_wgl.h gle_glx.h gle_main.h The first two headers are for the core GL enums and functions. The next two are for WGL/GLX enums and functions. gle_main.h is where gleLoadFunctions and gleLoadWinFunctions is defined. Any header that contains enums and functions will also define the global variables that one uses to tell whether the extension is available, but only for those extensions that it has. |
|
From: Branan R. <br...@gm...> - 2008-09-09 17:50:57
|
You are, of course, absolutely right about it breaking non-msvc.
Also, since you've reminded me that all the examples are in one CMake
file, you can set the property for all of the targets in one command -
just place all of the targets before PROPERTIES:
set_target_properties(boing splitview triangle wave PROPERTIES
LINK_FLAGS "/ENTRY:mainCRTStartup")
Branan
On Tue, Sep 9, 2008 at 10:34 AM, Camilla Berglund
<cam...@gm...> wrote:
> Branan Riley wrote:
>> IF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
>> SET_TARGET_PROPERTIES(<exename> PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
>> ENDIF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
>
> That won't make GCC-based (or any other non-VS) build chains happy, though.
>
> How about something like:
>
> if(MSVC)
> set_target_properties(boing PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
> set_target_properties(splitview PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
> set_target_properties(triangle PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
> set_target_properties(wave PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
> endif(MSVC)
>
> Oh, and -mno-cygwin isn't set yet. I'll fix that not today.
>
> Regards,
> elmindreda
|
|
From: Camilla B. <cam...@gm...> - 2008-09-09 17:34:16
|
Branan Riley wrote:
> IF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
> SET_TARGET_PROPERTIES(<exename> PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
> ENDIF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
That won't make GCC-based (or any other non-VS) build chains happy, though.
How about something like:
if(MSVC)
set_target_properties(boing PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
set_target_properties(splitview PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
set_target_properties(triangle PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
set_target_properties(wave PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
endif(MSVC)
Oh, and -mno-cygwin isn't set yet. I'll fix that not today.
Regards,
elmindreda
|
|
From: Branan R. <br...@gm...> - 2008-09-09 15:59:23
|
I'm at work so I can't make a patch right now, but here's the CMake
code to make a win32 GUI-app use main() as the entry point:
IF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
SET_TARGET_PROPERTIES(<exename> PROPERTIES LINK_FLAGS "/ENTRY:mainCRTStartup")
ENDIF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
These lines needsto be added after the ADD_EXECUTABLE call in all the
examples. I can do it and make a patch when I get home tonight (about
8.5-9 hours), if no one gets to it by then.
|
|
From: Camilla B. <cam...@gm...> - 2008-09-09 15:31:45
|
Branan Riley wrote: > Once again, the patch is all-inclusive Applied, except for the console stuff. Regards, elmindreda |
|
From: Camilla B. <cam...@gm...> - 2008-09-09 15:15:40
|
Running a little behind... Branan Riley wrote: > The 2.x-lite branch of GLFW is now being pulled on a GLSDK checkout, > via svn:externals. Yay. [1] https://sourceforge.net/tracker/?atid=534940&group_id=72569 > I have no idea what the versions are for other distros Etch (Debian stable) still has 2.4, with no 2.6 on backports.org. Lenny (testing) has 2.6, but when I installed this laptop, that package still lacked ccmake so I'm running the Sid (unstable) package. ...but since neither project is going to be released tomorrow, perhaps that's okay. Regards, elmindreda |
|
From: Branan R. <br...@gm...> - 2008-09-08 21:55:36
|
I just disabled the footer added to messeges sent by this mailing list. It didn't really have any useful information, IMHO. Branan |
|
From: Branan R. <br...@gm...> - 2008-09-08 02:37:17
|
I see it *slaps forehead* I got your error backwards. For some reason, I was thinking it was showing console and needed to be set to Windows. I've set it to console, but now it will show the dos box. The real solution is to chaing the entry point to mainCRTStartup, as described in tutorial 0 on the GLFW website. I'm not sure how to do that in CMake, but I will look into it. Once again, the patch is all-inclusive Branan |
|
From: Branan R. <br...@gm...> - 2008-09-08 01:36:55
|
I have no idea why it's failing. The executable targets _should_ work fine, as far as I can tell. I'm probably just not seeing it. I'll look again tomorrow, maybe fresh eyes will help. For now, I've add a new CMake option to the GLSDK build system, so GLFW is diabled by default on all platforms, and can be enabled with -DGLSDK_GLFW=1. Branan |
|
From: Orhun B. <orh...@gm...> - 2008-09-07 19:23:32
|
They all fail with the same error. PS: I have to leave for the rest of the day. But I'll look into this tonight if I don't hear back from you. -- Orhun Birsoy |
|
From: Branan R. <br...@gm...> - 2008-09-07 19:19:21
|
The CMake file looks like it's correct to generate a win32 program, rather than a console app... Does it give the same error building boing.exe or gears.exe? Branan |
|
From: Orhun B. <orh...@gm...> - 2008-09-07 19:11:55
|
It almost worked.. It compiles but, the link fails with 1>Linking... 1>MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup 1>C:\home\orhun\development\3rdparty\glsdkbuild\third_party\glfw\examples\Debug\triangle.exe : fatal error LNK1120: 1 unresolved externals The reason is SubSystem flag in Linker/System is set to "Windows", It should have been "Console". If I manually change it to "Console", everything works and I see the spinning triangle. I have no idea how this is set in CMake though. -- Orhun Birsoy |
|
From: Branan R. <br...@gm...> - 2008-09-07 18:56:28
|
OK, this should fix those. This patch includes the first one, so be sure to run 'svn revert' in the glfw directory before applying it. Branan |
|
From: Orhun B. <orh...@gm...> - 2008-09-07 18:49:39
|
OK. It worked. But the compile fails with 1>win32_dllmain.c 1>..\..\..\..\..\glsdk\third_party\glfw\lib\win32\win32_dllmain.c(31) : fatal error C1083: Cannot open include file: 'internal.h': No such file or directory "third_party\glfw\lib" is missing from the include directories. After manually adding this directory to Visual Studio project, glfw lib compiles but the triangle example compile fails with, 2>triangle.c 2>..\..\..\..\glsdk\third_party\glfw\examples\triangle.c(10) : fatal error C1083: Cannot open include file: 'GL/glfw.h': No such file or directory Triangle project has these include directories set, C:\home\orhun\development\3rdparty\glsdk\inc;C:\home\orhun\development\3rdparty\glsdkbuild\inc;C:\home\orhun\development\3rdparty\glsdk\include either "third_party\glfw\include" should be included to the search paths or, glfw.h should be added (or copied during build) to "inc/GLSDK", but I am not sure whether it should be "GLSDK/GL/glfw.h" or just "GLSDK/glfw.h". -- Orhun Birsoy |
|
From: Branan R. <br...@gm...> - 2008-09-07 18:32:43
|
I see the problem. GLFW asumes that it's a top-level project. This patch should fix that Branan On Sun, Sep 7, 2008 at 11:16 AM, Orhun Birsoy <orh...@gm...> wrote: > I just tried building but CMake failed with > CMake Error in third_party/glfw/lib/win32/CMakeLists.txt: > Cannont find source file "enable.c". Tried extensions .c .C .c++ .cc .cpp [snip] |
|
From: Orhun B. <orh...@gm...> - 2008-09-07 18:16:31
|
I just tried building but CMake failed with CMake Error in third_party/glfw/lib/win32/CMakeLists.txt: Cannont find source file "enable.c". Tried extensions .c .C .c++ .cc .cpp [snip] -- Orhun Birsoy |
|
From: H. H. <hen...@gm...> - 2008-09-07 08:35:20
|
I'm using Arch Linux and CMake 2.6 version is supported. I have no objections to this. On Sun, Sep 7, 2008 at 5:48 AM, Branan Riley <br...@gm...> wrote: > The 2.x-lite branch of GLFW is now being pulled on a GLSDK checkout, > via svn:externals. > > It currently fails to build for me on Linux, using CMake 2.6, due to a > change in the way CMake handles X11 stuff. I can make a patch, but it > will move the minimum required CMake version up to 2.6. All the recent > distro releases have 2.6, and it's the version we're requiring for the > GLSDK. There are a couple problems with that, though: > > * On Gentoo, CMake 2.6 is still marked as testing > * I think that Hardy (and soon Intrepid) are the only Ubuntu versions with > 2.6 > > I have no idea what the versions are for other distros > > For now, it's only set to build on Windows. So if anyone on Windows > wants to try to build GLSDK revsion 66, and see what happens, that > would be awesome > > Branan > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > -- Henri 'henux' Häkkinen |
|
From: Branan R. <br...@gm...> - 2008-09-07 02:48:06
|
The 2.x-lite branch of GLFW is now being pulled on a GLSDK checkout, via svn:externals. It currently fails to build for me on Linux, using CMake 2.6, due to a change in the way CMake handles X11 stuff. I can make a patch, but it will move the minimum required CMake version up to 2.6. All the recent distro releases have 2.6, and it's the version we're requiring for the GLSDK. There are a couple problems with that, though: * On Gentoo, CMake 2.6 is still marked as testing * I think that Hardy (and soon Intrepid) are the only Ubuntu versions with 2.6 I have no idea what the versions are for other distros For now, it's only set to build on Windows. So if anyone on Windows wants to try to build GLSDK revsion 66, and see what happens, that would be awesome Branan |
1 message has been excluded from this view by a project administrator.
