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
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.
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.
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.
There's now a default fragment shader used all the time (unless you use a custom one or use the geometric Draw* primitives):
Which gfx card do you have?
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.
Edit: I don't know how to build GLFW for mingw, there is no codelite project for GLFW in build folder
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) but accepts texture2D(texture, gl_TexCoord.st)).
I'll try to give it a try with a newer version of mingw probably early next week, going to be hard before then.
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:
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:
Fun, isn't it?
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
So, I noticed that for profile and release build. fno-rtti is added as compiler options. Why its added for profile and release btw ?
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.
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
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.
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
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.
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.
You don't need to do that. When compiling the first tutorial, there's a copy step that will do it for you.
Yes, it's just an assert that got too restrictive over time, I just modified it and that tutorial should work fine again.
That's because you don't have the correct DirectX backend.
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.