strange GLFW error with rev 423f4d9 from bitbucket

jimjim
edited June 2013 in General discussions
I downloaded orx revision 423f4d9 and I build orx with msvc2010 express for Embedded Dynamic Debug. orx was built properly. Then I opened orx tutorial inside orx source, there was no problem building tutorials but as soon as I run them I get following message and program wont run
[22:12:14] [DISPLAY] [orxdisplay.c:orxDisplay_GLFW_CompileShader():795] Couldn't
 compile fragment shader:
ERROR: 0:1: 'texture2D' : no matching overloaded function found (using implicit
conversion)

But rev ac882d0 is working fine for me. Reading commit messages I can see there is some changes in GLFW plugin after ac882d0, maybe that broke some codes, not sure though.

Comments

  • edited June 2013
    Hi jim,

    Thanks for the report. For some reason the default shader doesn't compile for you. On which version of windows are you? Does it happen for any tutorial?
    I'll look into it tonight.
  • jimjim
    edited June 2013
    oh, i am using windows 7 64bit, yeah it happens for all the tutorials
  • edited June 2013
    Ok, same as me, I'll check it tonight, thanks.
  • jimjim
    edited June 2013
    Not related to this topic but I cant even build rev ac882d0 for mingw, my mingw version is 4.7.1, I get "Application unable to start error", thats a problem with the .dll created from mingw I think, maybe I need to update my mingw version.
  • edited June 2013
    If you're using gcc 4.7.1 you'll have to recompile all the dependencies as well (SOIL, libsndfile, openal-soft, GLFW, Box2D) as they're currently compiled with gcc 4.6.2 and are not binary compatible.
  • jimjim
    edited June 2013
    Ooops, last night I tried with gcc 4.7.2 and gcc 4.8.1 but did not work, now I know why. I will try it again once I get home.
  • edited June 2013
    I just tried all tutorials in debug & release with the latest from mercurial (87474ae294a4), compiled with VS2008 and they worked just fine for me.
    Are your OpenGL drivers up-to-date, just in case?

    The only bug I saw was in the viewport tutorial as it doesn't work anymore as intended, due to recent changes in orxRender_GetWorldPosition().
    I'll fix that soon-ish.
  • jimjim
    edited June 2013
    I tried with VS2010, don't know if thats the case. Well, afaik its updated. Because I can compile and run rev ac882d0 easily which is 4 days old
  • edited June 2013
    Well, between ac882d06b3c2 and recent revisions, I've completely removed the fixed pipeline from the GLFW display plugin. Everything is now using the programmable pipeline (unless you don't have any shader support at all, in which case it'll still use the old fixed pipeline, but that's for very very old architectures).

    There's now a default fragment shader used all the time (unless you use a custom one or use the geometric Draw* primitives):
    uniform sampler2D orxTexture;
    void main()
    {
      gl_FragColor = gl_Color * texture2D(orxTexture, gl_TexCoord[0]);
    }
    
  • jimjim
    edited June 2013
    I could run shader tutorial just fine when it was fixed pipeline. Okay, once I get home I will get the latest and build once again. I will also provide build log if that helps and will also see if I need to update my graphics driver or not. Thanks.
  • edited June 2013
    Thanks! Keep us posted with your findings.
    Which gfx card do you have?
  • edited June 2013
    A quick test you could do is to use the shader defined above as a custom shader when using an older version that was still working for you. Simply remove the first line and add the config property ParamList = orxTexture.
  • jimjim
    edited June 2013
    I have onboard graphics which is intel HD 4000, specification says it has support for opengl 4 and shader model 5. Dont know if its enough for programmable shader.
  • edited June 2013
    Yeah, you're fine. OpenGL 2.1/Shader Model 2 would be the minimum here. Well then I guess it comes from Intel's GLSL compiler then. I don't have access to any Intel HD card so it's going to be hard to help.
    You can fiddle inside the display plugin with the default shader (look for the code I pasted 2 posts ago) and check which version of OpenGL is initialized by GLFW.
  • edited June 2013
    Ah, I think I have an idea: I'll update the code on bitbucket right away. If you can get it, let me know if that changed anything for you.
  • jimjim
    edited June 2013
    I tried the changed version and it works :) All of tutorials now builds and runs perfectly. So what was the problem ?
  • jimjim
    edited June 2013
    Regarding problem with mingw. I could compile and run tutorials form rev 0933b3a with gcc 4.7.1, I had no problems which that. Though its outdated but it worked with gcc 4.7.1, wonder what might be the problem
  • jimjim
    edited June 2013
    Pardon me, but now I cant even compile that revision too. I don't know what is the problem, one thing I am suspecting is maybe I was using liborxd.a with orxd.dll (this .dll is created from visual studio) because I replaced the dll created by gcc with the visual studio version and it worked. No error, but error was there with the gcc dll.

    Edit: I don't know how to build GLFW for mingw, there is no codelite project for GLFW in build folder
  • edited June 2013
    There's a makefile for GLFW. If you type make, it'll give you all the options for all the platforms. You'll then have to copy the library in the right /lib/mingw folder when it's done compiling.

    Glad that the change made it work for you, I simply added the swizzle at the end of the vector as Intel apparently is very pedantic about that (doesn't accept texture2D(texture, gl_TexCoord[0]) but accepts texture2D(texture, gl_TexCoord[0].st)).
  • jimjim
    edited June 2013
    I saw the makefile, it has options like win32-mingw, win32-msys, msys-install. I am confused what to use. But I tried them all. But there is only one libglfw.a file under libmingw but any of the following generates libglfw.a, libglfwdll.a and glfw.dll files, I copied them to the libmingw folder and tried to build orx, but I got undefined reference for glfw.
  • edited June 2013
    Yep, win32-mingw + copying libglfw.a should be what you need.

    I'll try to give it a try with a newer version of mingw probably early next week, going to be hard before then.
  • jimjim
    edited June 2013
    I tried for the last time, But it did not work as I expected, ths size of libglfw.a from win32-mingw is around 80KB whereas 4.6.2 version is around 300KB. Its no problem to wait, I am also good with MSVC. But update would be nice as both the recent version of codeblock and codelite ship with gcc 4.7.1
  • edited June 2013
    Ah, of course, thanks for pointing out the size of the lib. There's an extra step needed to create that library.
    You need to embed libopengl32.a inside that library (the one that comes with your mingw distribution).
    To do so, you need to run this command:
    ar xv libopengl32.a | cut -f3 -d ' ' | xargs ar rvs libglfw.a && rm *.o && echo 'done'
    

    That means you need to have the linux tools ar, cut, xargs available on your machine. There are some windows binaries available on internet somewhere, but I usually do that in a virtual linux box as they're standard tools there.

    When it's done (and back on windows), you need to regenerate the index of the library by calling:
    ranlib libglfw.a
    

    Fun, isn't it? ;)
  • jimjim
    edited June 2013
    Thats cool stuff but I would probably wait for a week or two till the binary is updated.

    edit: ok, I searched my msys folder and found everything I need, and I executed the command you showed me. And wow, libglfw.a is around 330KB, but alas I could not found runlib.exe
  • jimjim
    edited June 2013
    I guess I did not need runlb as I used msys. So, then I went on building orx again, this time I got error from libopenal.a, then I saw that preious version of libopenal.a has size of 500KB and mine is around 300KB, something is fishy, so I replaced your version of libopenal.a with my one and this time orx compiled fine :) Now I can run any tutorial as good as they are supposed to be.
  • jimjim
    edited June 2013
    While building for profile and release mode, I got a warning like this
    cc1.exe: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but not for C [enabled by default]
    

    So, I noticed that for profile and release build. fno-rtti is added as compiler options. Why its added for profile and release btw ?
  • edited June 2013
    I'm glad you got it working.

    As for the version of gcc, the current MinGW installer comes with 4.6.2 and it's likely to be the one people will have installed in most cases. I'll switch to a new one when the installer comes with a new one as well.

    RTTI are only used in C++. However C++ is needed to compile the embedded plugins (mostly for Box2D), so I usually use the C++ compiler for compiling orx entirely as often it produces a better code, at least for Microsoft, as the C++ compiler is more maintained than the C one.

    RTTI (RunTime Type Information) are not useful for orx so they're deactivated solely for performance reasons.
  • jimjim
    edited June 2013
    Hmm, sticking with 4.6.2 seems more logical then. And its just warnings so does not matter much. And yep, mingw problem and GLFW problem is gone now, this post can be declared solved, I guess and thank you.
  • jimjim
    edited June 2013
    Looks like problems wont leave me easily. I noticed some weird assert and Log in some of the tutorials while running for only mingw in debug mode. So, downloaded the latest, here is what I did,

    1. I downloaded the latest, then I build all the external as you mentioned except openal, also build glfw and run those command, I also found ranlib.exe because in the past I searched for runlib.exe :p

    2. I generated codelite project file. and build orx for debug, profile and release. So far everything is good.

    3. Then I copied .dll files in tutorialsin, then went onto building tutorials.

    4. Tutorials 1 build and ran fine. But when I run clock tutorial, and pressed KEY_RIGHT, I got following assert and program terminated, this happens only in debug mode, for profile or release no such assert.
    [20:57:31] [ASSERT] [orxClock.c:orxClock_SetModifier():1059] [ASSERT] : <_eModTy
    pe < orxCLOCK_MOD_TYPE_NUMBER>
    

    5. In sound tutorial if I keep pressing KEY_LEFT, music volume decreases as expected, just when volume becomes 0, I get the following assertion
    [21:02:17] [ASSERT] [orxSoundSystem.c:orxSoundSystem_OpenAL_SetPitch():1768] [AS
    SERT] : <eError == AL_NO_ERROR && "OpenAL error code: 0xA003">
    AL lib: (EE) DSoundPlaybackProc: WaitForSingleObjectEx error: 0x102
    

    6. In Local tutorial, when I click or press space, I get following Log, this also happens in only debug. No such message in profile or release.
    [21:06:14] [DISPLAY] [orxFont.c:orxFont_CreateFromConfig():872] Couldn't find co
    nfig section named ().
    
  • edited June 2013
    jim wrote:
    1. I downloaded the latest, then I build all the external as you mentioned except openal, also build glfw and run those command, I also found ranlib.exe because in the past I searched for runlib.exe :p
    Hehe, yes, easier with the correct name. ;)
    2. I generated codelite project file. and build orx for debug, profile and release. So far everything is good.
    Well, actually you should have had some warning when compiling openal-soft as it requires the Direct Sound backend, but it's not par of the default MinGW distribution.
    One has to google for it (DirectX Mingw should work), and add the extra .h/.a to his/her MinGW installation.

    Then when you're done compiling, the size difference you noted is because I emebedded libole32.a inside libopenal32.a, with the exact same technique used with libopengl32.a/libglfw.a.
    3. Then I copied .dll files in tutorialsin, then went onto building tutorials.
    You don't need to do that. When compiling the first tutorial, there's a copy step that will do it for you.
    4. Tutorials 1 build and ran fine. But when I run clock tutorial, and pressed KEY_RIGHT, I got following assert and program terminated, this happens only in debug mode, for profile or release no such assert.
    [20:57:31] [ASSERT] [orxClock.c:orxClock_SetModifier():1059] [ASSERT] : <_eModTy
    pe < orxCLOCK_MOD_TYPE_NUMBER>
    
    Yes, it's just an assert that got too restrictive over time, I just modified it and that tutorial should work fine again.
    5. In sound tutorial if I keep pressing KEY_LEFT, music volume decreases as expected, just when volume becomes 0, I get the following assertion
    [21:02:17] [ASSERT] [orxSoundSystem.c:orxSoundSystem_OpenAL_SetPitch():1768] [AS
    SERT] : <eError == AL_NO_ERROR && "OpenAL error code: 0xA003">
    AL lib: (EE) DSoundPlaybackProc: WaitForSingleObjectEx error: 0x102
    
    That's because you don't have the correct DirectX backend.
    6. In Local tutorial, when I click or press space, I get following Log, this also happens in only debug. No such message in profile or release.
    [21:06:14] [DISPLAY] [orxFont.c:orxFont_CreateFromConfig():872] Couldn't find co
    nfig section named ().
    
    I'll look into this one, it's probably just a harmless message.

    Now that being said, I just updated all the external dependencies with gcc 4.7.2 in a new branch named mingw-gcc-4.7.2. If you sync it, you won't need to re-build the dependencies yourself. :)
  • jimjim
    edited June 2013
    Okay, I will get the mingw branch when I get home, is there any download button for that branch or I need to clone the whole repo to get that branch.
  • edited June 2013
    You can either clone the repository (which makes it much easier to stay up-to-date and switch from branches/versions to other ones), or go to the download page, and download any tag/branch version from there.

    You can actually download any specific version, at a given commit, by using a similar URL and simply replacing the name of the tag/branch by the hash of the changeset:
    https://bitbucket.org/orx/orx/get/<hash>.zip
    
  • jimjim
    edited June 2013
    Oh, I missed the download page. I would better clone the whole repo with source tree, last time they had no hg support. I hope its not much different from git, which I frequently use.
  • edited June 2013
    hg's very similar to git. Actually I think there are probably bridges that would let you use the hg repository seamlessly from git.
  • jimjim
    edited June 2013
    I tried the new branch today. Assert on the clock demo is gone, but still having the same assert for sound tutorial
    [23:12:46] [ASSERT] [orxSoundSystem.c:orxSoundSystem_OpenAL_SetPitch():1768] [AS
    SERT] : <eError == AL_NO_ERROR && "OpenAL error code: 0xA003">
    AL lib: (EE) DSoundPlaybackProc: WaitForSingleObjectEx error: 0x102
    

    Also, while building rox for debug I got some warnings like this
    ../../../include/../plugins/Display/GLFW/orxDisplay.c:4382:56: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
    

    Its may be C++11 related
  • edited June 2013
    Mmh, the sound tutorial works fine for me with the 4.7.2 branch.
    Not sure what I can do about, sorry. Did it work fine with the previous version?

    For the C++11 warning, I haven't modified any code to be C++11 compliant yet (most compilers are still not implementing the full specs anyway), so I'd recommend simply turning off this specific warning for now.
  • jimjim
    edited June 2013
    The tutorial works fine with release and profile mode, assert is only there in debug. I tried 1.4 now, surprisingly the assert is also there. I don't know what is wrong here.

    edit: the assert is triggered when I pressed down the LEFT_KEY and pitch becomes 0
  • edited June 2013
    Ah thanks for the detail, I'll update the tutorial to make sure this situation never happens then, it'll be cleaner. :)
  • jimjim
    edited June 2013
    This assert only triggered for mingw + debug build.
Sign In or Register to comment.