NewsForumsCodeLogsGallerySpecsSearch

GLFW3 Target

Monkey Targets Forums/User Targets/GLFW3 Target

Samah(Posted 2014) [#1]
Guys,
I've upgraded the existing GLFW target to work with GLFW3.
Compiles for 32-bit Windows when using MinGW32.

Get the fork here:
https://github.com/swoolcock/monkey/tree/glfw3

To build 64-bit, get mingw-w64 here and change the library paths in the Makefile:
http://nuwen.net/mingw.html

If you use Diddy, update to the latest changeset for glfw3 support.
https://code.google.com/p/diddy/source/detail?r=f856ce9180b1a31520e33f37c490f1d6fdfa3312

Please test it as much as you can!

Samah


ziggy(Posted 2014) [#2]
Awesome news


SLotman(Posted 2014) [#3]
So... what are the changes from current GLFW to GLFW3? I tried looking at glfw website, but couldn't find anything...

Is it possible to switch from window to fullscreen without having to reload everything?


Samah(Posted 2014) [#4]
Well the big thing is that you can have multiple windows, thus (in theory) multiple monitor support. I think the "reload everything" was more of a Mojo implementation limitation, so it's possible that could be worked around.


therevills(Posted 2014) [#5]
What have I done wrong?

Building...
'make' is not recognized as an internal or external command,
operable program or batch file.
TRANS FAILED: Error executing 'make CCOPTS="-Wno-free-nonheap-object" OUT="Debug/MonkeyGame"', return code=1
Abnormal program termination. Exit code: -1


[edit]
Opps I hadn't updated my MonkeyX config to point to MinGW....

Seems the update is too fast?


Samah(Posted 2014) [#6]
Seems the update is too fast?

As I said, they removed glfwSleep(). For now it updates once every render, and it renders as fast as possible. GLFW has a bunch of funky threading stuff in it, so I might see if i can use that to fake a sleep to limit the update rate.


Skn3(Posted 2014) [#7]
Good job! Will check this out soon when I have some scheduled work-on-my-stuff time :D

http://www.glfw.org/docs/latest/news.html

Quite a nice list of new features!


therevills(Posted 2014) [#8]
As I said, they removed glfwSleep().

Where?
Cross posts :/
http://www.monkey-x.com/Community/posts.php?topic=8827&post=92453

Since I've "installed" MinGW 64bit, I now cant build the normal desktop target...


Samah(Posted 2014) [#9]
Since I've "installed" MinGW 64bit, I now cant build the normal desktop target...

Yep, and I'm still fighting with C/C++ and its stupid workflow/toolchain. How anyone can use that antiquated language and stay sane is beyond me.
For now you'll have to switch back to the old MinGW if you want to compile for GLFW2. I guess this means the main benefit of the GLFW3 target is for those who want to make their app 64-bit.
I'll look at fixing the update rate and maybe seeing what other features from GLFW3 can be made available. It's hard to add new stuff without modifying Mojo to some degree, and then of course it's target dependent.


Samah(Posted 2014) [#10]
Update rate fixed. Also fixed a white flicker therevills mentioned.
Go go pull!


Soap(Posted 2014) [#11]
Glad to see this!


Nobuyuki(Posted 2014) [#12]
@Slotman

So... what are the changes from current GLFW to GLFW3? I tried looking at glfw website, but couldn't find anything...

Is it possible to switch from window to fullscreen without having to reload everything?



http://www.glfw.org/docs/latest/moving.html

1. Scroll wheel represents a delta instead of an absolute position. This should (in theory) mean no more hacks needed to get consistent scrolling behavior across targets, and maybe Mark will add MouseScrollX() / MouseScrollY() or something to Mojo with consistency available? In any case, it's there.

2. Capture of certain hotkeys has been removed. This may or may not be a problem since mojo doesn't enumerate every keycode anyway. The keycodes glfw3 have defined are for a US international keyboard. Again in theory, polling can differentiate between left shift/right shift, maybe detect some keys it couldn't before.

3. Window handling's different. Perhaps this will allow for easier context-switching. The way window handling worked in previous versions of GLFW caused some issues with features like stencil buffer access on different targets (if you were using the modules gles11 or nDrawExts, for example). Mark later added a workaround to re-init the GLFW window from Monkey but perhaps with glfw3, it can be implemented cleaner and less hacky. glfwCreateWindow's parameters now are all hints, meaning that the OS is free to ignore them. Defaults might change -- The aforementioned stencil buffer is initialized to 0 bits in mojo currently; most systems consider that a hint, but a few disable the buffer. Maybe this will change?

4. Joystick support has improved. You'll be able to have better joystick support on systems that previously didn't support a wide variety. You can detect if a joystick is available (important for passing Microsoft app standards).

5. Glfw3 can hide and capture the mouse cursor, should you need this for direct input purposes.


Samah(Posted 2014) [#13]
Scroll wheel represents a delta instead of an absolute position. This should (in theory) mean no more hacks...

Capturing input in GLFW uses callbacks, and MouseScrollX/Y() or similar is not a callback. Basically it needs to cache scrollwheel information somewhere in a similar way to key polling. I had to temporarily disable MouseZ() in Diddy for GLFW3.

Mark later added a workaround to re-init the GLFW window from Monkey...

This is currently a really dirty hack and I'm hoping I can clean it up a bit.

Joystick support has improved. You'll be able to have better joystick support on systems that previously didn't support a wide variety. You can detect if a joystick is available (important for passing Microsoft app standards).

Glfw3 can hide and capture the mouse cursor...

Going to need to modify the Monkey side of Mojo for these, though. I've been trying to avoid it so that the native code for other targets won't need to be touched (especially since I can't check in any changes to non-free targets)..

Lots of possibilities, though.


Nobuyuki(Posted 2014) [#14]
just an update; I checked 3.0.4's source code and it still uses winmm on windows for joystick input. Somewhat frustrating, but they've set xinput support as a 3.2 target now...


Samah(Posted 2014) [#15]
@Nobuyuki: just an update; I checked 3.0.4's source code and it still uses winmm on windows for joystick input. Somewhat frustrating, but they've set xinput support as a 3.2 target now...

Thanks, I'll have to keep that in mind. My goals at the moment:

1) Get GLFW3 target compiling under Visual Studio in both 32- and 64-bit. I should be able to static link against the prebuilt libraries rather than compiling the whole thing like the current GLFW2 target.
2) Clean up the window creation code.
3) Try to get it linking against the LibOVR prebuilt VS libraries (not technically part of the main GLFW3 target, but it was the original goal, so it'll be a secondary target).
4) Look at adding some minor features (scrollwheel, mouse capturing, joystick enumeration, etc.) If I can keep it restricted to graphics/input device driver classes there should be no changes required to Mojo; it would just be a separate module that interfaces with it.


nigelibrown(Posted 2014) [#16]
downloaded and copied over my MonkeyXPro78h install and I am getting the error "Native OS module not implemented" from os.monkey can you help please?


Samah(Posted 2014) [#17]
Ok, looks like I didn't use the monkey.os module in my tests. I'll take a look at it tonight.
On another note, I managed to get it compiling with standard MinGW32 so I'll push that when I can. It means it will compile with 32-bit by default.


Samah(Posted 2014) [#18]
Fixed. Pull the latest glfw3 branch when you're ready. You should change your config.winnt.txt to point to the old MinGW32 installation.
If you want to still use MinGW-w64, open the Makefile and either add the -m32 flag to CPPFLAGS to force 32-bit, or change the library paths to Win64 to build 64-bit.
I might make a second target for 64-bit, instead.

Edit: Also added support for borderless windows!
Open CONFIG.MONKEY and set:
GLFW_WINDOW_BORDERLESS=True


therevills(Posted 2014) [#19]
Cool! Time for a pull request to the main Monkey repo?


Samah(Posted 2014) [#20]
@therevills: Cool! Time for a pull request to the main Monkey repo?

Done. :)

https://github.com/blitz-research/monkey/pull/66


starfox(Posted 2014) [#21]
Good stuff! Any luck getting this to work on Linux too?
This would open the possibility of using hardware accelerated graphics in OpenGL ES programs, running on things like Raspberry Pi.


nigelibrown(Posted 2014) [#22]
just testing out the latest and greatest, and I am getting a problem with 'Identifier "SetRender" not found? From app.monkey OnCreate()

Strict

Import minib3d.app
Import mojo

Class MyApp Extends MiniB3DApp

	Method Create:Int()
		Return 0
	End
	
	Method Update:Int()
		Return 0
	End
	
	Method Render:Int()
		Return 0
	End
	
	Method Init:Int()
		Return 0
	End
End

Function Main:Int()
	New MyApp	
	Return True
End



Samah(Posted 2014) [#23]
@starfox:Good stuff! Any luck getting this to work on Linux too?

I don't have a Linux machine at home anymore, so I'll have to set it up in VirtualBox or something. I might take a look later.

@nigelibrown: just testing out the latest and greatest, and I am getting a problem with 'Identifier "SetRender" not found? From app.monkey OnCreate()

I don't have any experience with the MiniB3DApp class. Maybe it's some kind of weird conflict? I'll give it a shot.
What version of Monkey are you using? Just a straight clone from github?


nigelibrown(Posted 2014) [#24]
@Samah: I have just downloaded MonkeyXPro78h and the latest minib3b along with monkey-glfw3, and using the above source i get the error 'SetRender' to set-up I have copied the contents of monkey-glfw3 over the new MonkeyXPro78h and created a new folder with the source code from last post in this thread. builds with DesktopGame but not GLFW3 DesktopGame.

Is there a set of install instructions anywhere?


Samah(Posted 2014) [#25]
Ok, this is what I did:
1) Downloaded 78h and set MinGW path in config.winnt.txt
2) Copied the targets/glfw3 directory from the forked repo into the extracted 78h dir
3) Copied modules/mojo/driver.monkey
4) Copied modules/mojo/native/mojo.glfw3.cpp
5) Compiled and ran this program with no errors:
Strict

Import mojo

Function Main:Int()
	New MyApp
	Return 0
End

Class MyApp Extends App
	Method OnCreate:Int()
		SetUpdateRate(60)
		Return 0
	End
	
	Method OnUpdate:Int()
		Return 0
	End
	
	Method OnRender:Int()
		Cls
		DrawRect(100,100,100,100)
		Return 0
	End
End


Can you give me a code sample that causes the error?


nigelibrown(Posted 2014) [#26]
@Samah, followed your instructions and got

"C:/_MonkeyXPro78h/bin/transcc_winnt" -target=GLFW3_Desktop_Game -config=Debug -run "C:/_MonkeyXPro78h/bananas/nigelibrown/main.monkey"
TRANS monkey compiler V1.68
Parsing...
Semanting...
Translating...
Building...
g++  -Wno-free-nonheap-object -I../glfw3/include -I../openal/include -I../stb -I../tinycthread -D__STRICT_ANSI__  -c -o ../main.o ../main.cpp
g++ -Wl,--subsystem,windows -L../openal/libs/Win32 -L../glfw3/lib/Win32 -o Debug/MonkeyGame ../stb/stb_image.o ../stb/stb_vorbis.o ../tinycthread/tinycthread.o ../main.o -lglew32 -lglfw3 -lopengl32 -lglu32 -lgdi32 -lws2_32 -lOpenAL32
c:/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible ../glfw3/lib/Win32/libglfw3.a when searching for -lglfw3
c:/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible ../glfw3/lib/Win32\libglfw3.a when searching for -lglfw3
c:/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible ../glfw3/lib/Win32/libglfw3.a when searching for -lglfw3
makefile:21: recipe for target 'Debug/MonkeyGame' failed
c:/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lglfw3
c:/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible ../openal/libs/Win32/OpenAL32.lib when searching for -lOpenAL32
c:/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible ../openal/libs/Win32/OpenAL32.lib when searching for -lOpenAL32
c:/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible ../openal/libs/Win32\OpenAL32.lib when searching for -lOpenAL32
c:/devtools/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lOpenAL32
TRANS FAILED: Error executing 'make CCOPTS="-Wno-free-nonheap-object" OUT="Debug/MonkeyGame"', return code=2
collect2.exe: error: ld returned 1 exit status
make: *** [Debug/MonkeyGame] Error 1
Done.



Samah(Posted 2014) [#27]
At the moment you need to be using mingw32, not mingw-w64. Alternatively you can try forcing 32-bit, but you'll need to update the library paths and add the -m32 flag to CPPFLAGS.


Nobuyuki(Posted 2014) [#28]
got this error:



Copied over to a version of 79e, but using the minGW toolchain automatically installed by jungle, which I'm not sure is different than the main install but I went with it because it's portable and had no extra stupid requirements. Am I doing anything wrong? Is there an easy fix?

edit: copied over to 80b and still having the same issue.


Soap(Posted 2014) [#29]
No project files for using msbuild instead? xcode? linux?

I tried a bunch of things but couldn't get examples to build. Tried using 3 different versions of mingw with different errors... including the x64 error posted above already. Tried on 80b and 78g.

TRANS monkey compiler V1.73
Parsing...
Semanting...
Translating...
Building...
gcc  -Wno-free-nonheap-object -O3 -DNDEBUG -I../glfw3/include -I../openal/include -I../stb -I../tinycthread -D__STRICT_ANSI__  -c -o ../stb/stb_image.o ../stb/stb_image.c
gcc  -Wno-free-nonheap-object -O3 -DNDEBUG -I../glfw3/include -I../openal/include -I../stb -I../tinycthread -D__STRICT_ANSI__  -c -o ../stb/stb_vorbis.o ../stb/stb_vorbis.c
gcc  -Wno-free-nonheap-object -O3 -DNDEBUG -I../glfw3/include -I../openal/include -I../stb -I../tinycthread -D__STRICT_ANSI__  -c -o ../tinycthread/tinycthread.o ../tinycthread/tinycthread.c
g++  -Wno-free-nonheap-object -O3 -DNDEBUG -I../glfw3/include -I../openal/include -I../stb -I../tinycthread -D__STRICT_ANSI__  -c -o ../main.o ../main.cpp
In file included from c:\mingw\include\direct.h:34:0,
                 from ../main.h:15,
                 from ../main.cpp:2:
c:\mingw\include\io.h:301:14: error: 'off64_t' does not name a type
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
              ^
c:\mingw\include\io.h:302:14: error: 'off64_t' does not name a type
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
              ^
../main.cpp: In member function 'virtual FILE* BBGame::OpenFile(String, String)':
../main.cpp:1946:70: error: '_wfopen' was not declared in this scope
  return _wfopen( path.ToCString<wchar_t>(),mode.ToCString<wchar_t>() );
                                                                      ^
<builtin>: recipe for target '../main.o' failed
mingw32-make: *** [../main.o] Error 1
TRANS FAILED: Error executing 'mingw32-make CCOPTS="-Wno-free-nonheap-object -O3 -DNDEBUG" OUT="Release/MonkeyGame"', return code=2
Done.



Parsing...
Semanting...
Translating...
Building...
g++  -Wno-free-nonheap-object -O3 -DNDEBUG -I../glfw3/include -I../openal/include -I../stb -I../tinycthread -D__STRICT_ANSI__  -c -o ../main.o ../main.cpp
g++ -Wl,--subsystem,windows -L../openal/libs/Win32 -L../glfw3/lib/Win32 -o Release/MonkeyGame ../stb/stb_image.o ../stb/stb_vorbis.o ../tinycthread/tinycthread.o ../main.o -lglew32 -lglfw3 -lopengl32 -lglu32 -lgdi32 -lws2_32 -lOpenAL32
../stb/stb_image.o: file not recognized: File format not recognized
collect2.exe: error: ld returned 1 exit status
Makefile:21: recipe for target 'Release/MonkeyGame' failed
mingw32-make: *** [Release/MonkeyGame] Error 1
TRANS FAILED: Error executing 'mingw32-make CCOPTS="-Wno-free-nonheap-object -O3 -DNDEBUG" OUT="Release/MonkeyGame"', return code=2
Done.
Hide full text



dawlane(Posted 2014) [#30]
Well so far I've had no problems getting it to work with Linux.

Edit:
Something for Linux users to play with.
After you have download the github files. Put it in the monkey targets/glfw3 directory and just copy over the binaries from the monkey bin directory.

Edit: And if you don't like the idea of using a pre-compiled binary do the following.
After getting Samah's files and extracting.
Copy over the Monkey binaries.
Download the GLFW source.
Extract src and deps directories and place them in the /monkey-glfw3/targets/glfw3/template/glfw3/ directory.
Make a directory in /monkey-glfw3/targets/glfw3/template/ named gcc_linux and create an empty file inside called Makfile.
Open this file up in a text editor and paste the code below and save.
CC=gcc
CFLAGS=

CXX=g++
CXXFLAGS=

CPPFLAGS=$(CCOPTS) \
 -I../glfw3/include \
 -I../glfw3/deps/GL \
 -I../glfw3/deps/ \
 -I../openal/include -I../stb \
 -D_GLFW_X11 \
 -D_GLFW_GLX \
 -D_GLFW_USE_OPENGL \
 -D_GLFW_HAS_GLXGETPROCADDRESS \
 -D_GLFW_USE_LINUX_JOYSTICKS \
 -pthread

LD=g++
LDFLAGS=
LDLIBS= -lGL -lopenal -lX11 -lXxf86vm -lXrandr -lXi -lpthread

OBJS=../glfw3/deps/getopt.o ../glfw3/deps/tinycthread.o ../glfw3/src/clipboard.o ../glfw3/src/gamma.o ../glfw3/src/context.o ../glfw3/src/glx_context.o ../glfw3/src/init.o ../glfw3/src/input.o ../glfw3/src/joystick.o ../glfw3/src/monitor.o ../glfw3/src/time.o ../glfw3/src/window.o ../glfw3/src/x11_clipboard.o ../glfw3/src/x11_gamma.o ../glfw3/src/x11_init.o ../glfw3/src/x11_joystick.o ../glfw3/src/x11_monitor.o ../glfw3/src/x11_time.o ../glfw3/src/x11_unicode.o ../glfw3/src/x11_window.o ../stb/stb_image.o ../stb/stb_vorbis.o ../main.o

all : $(OUT)

$(OUT) : $(OBJS)
	$(LD) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)



dawlane(Posted 2014) [#31]
@Nobuyuki: Edit the Makefile in gcc_winnt and remove the -lglew32 from LDLIBS=. You should find it compiles then.


Samah(Posted 2014) [#32]
dawlane:
If you're happy to work on Linux compatibility, would you like push permissions for the glfw3 fork?


dawlane(Posted 2014) [#33]
Samah:
I'll do what every I can, when I can as a family member is seriously ill at the moment. But I would have to read up on GLFW (it's not something I played around with much). Plus I'm not familiar with github and I wouldn't want to screw it up.

TDM-GCC-64 with Win7 doesn't like the v80b std_image.c. I haven't checked prior versions yet, but I'm sure they did compile with warnings.
-D__STRICT_ANSI__ issues warnings with incompatible implicit declaration of built-in functions. Could try to add -fno-builtin to the C/CPPFLAGS for the ones the compiler complains about if that particular directive is needed.

nigelibrown's openAL issue
The work around is to add the OpenAL32.dll to the openal/libs/Win32. Of course there will need to be a 64bit version of OpenAL32, if the std_image.c is solved.
And the only way to get a 64bit version of OpenAL is to build it using the sources from OpenAL-Soft or you can get the sources from SourceForge. You will need cmake to compile.
Edit: Just re-read his post and missed the glwf3 problem. If your having problems with the pre-compiled binaries then do then do the same thing that I did with the Linux version and replace the Makefile in templates/gcc_winnt with the code below.
CC=gcc
CFLAGS=

CXX=g++
CXXFLAGS=

CPPFLAGS=$(CCOPTS) \
 -I../glfw3/include \
 -I../glfw3/deps/GL \
 -I../glfw3/deps/ \
 -I../openal/include -I../stb \
 -I../stb \
 -D_GLFW_HAS_GLXGETPROCADDRESS \
 -D_GLFW_WIN32 \
 -D_GLFW_USE_OPENGL \
 -D_GLFW_WGL \
# -D__STRICT_ANSI__
#-DUSE_THREADED_DELAY

LD=g++
LDFLAGS= -Wl,--subsystem,windows -L../openal/libs/Win32 -L../openal/libs/Win64

LDLIBS= -lopengl32 -lglu32 -lgdi32 -lws2_32 -lOpenAL32

OBJS=../glfw3/deps/getopt.o ../glfw3/deps/tinycthread.o ../glfw3/src/clipboard.o ../glfw3/src/gamma.o ../glfw3/src/context.o ../glfw3/src/wgl_context.o ../glfw3/src/init.o ../glfw3/src/input.o ../glfw3/src/joystick.o ../glfw3/src/monitor.o ../glfw3/src/time.o ../glfw3/src/window.o ../glfw3/src/win32_clipboard.o ../glfw3/src/win32_gamma.o ../glfw3/src/win32_init.o ../glfw3/src/win32_joystick.o ../glfw3/src/win32_monitor.o ../glfw3/src/win32_time.o ../glfw3/src/win32_window.o ../stb/stb_image.o ../stb/stb_vorbis.o ../main.o

all : $(OUT)

$(OUT) : $(OBJS)
	$(LD) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)

Compiling problems with std_image.c and std_vorbis.c with TDM-GCC-64 are down to __forceinline. The errors should be something like there's multiple storage classes in declaration specifiers.
Adding
#if defined(__MINGW64_VERSION_MAJOR) && defined(__forceinline)
 #undef __forceinline
#endif
before each of the ifndef __forceinline should allow you to compile without error or warnings, but it really needs to be fixed properly.
Edit: This should fix it for MinGW/GCC. You will still need the code above. I haven't test this with VS or Xcode
#ifndef _MSC_VER
	#if defined(__GNUC__)
		#define __forceinline __inline__ __attribute__((always_inline))
	#elif defined(__cplusplus)
		#define __forceinline inline
	#else
		#define __forceinline
	#endif
#endif


I will also look at knocking up a VS2010/VS2013 Project file and one for xcode at some point.


Nobuyuki(Posted 2014) [#34]
@dawlane

it works! Thanks a bunch. I never thought to do that because I figured glew was a requirement.

BTW, the binaries for OpenAL-soft come with 64-bit versions.


dawlane(Posted 2014) [#35]
Nobyuki: Come to think of it. You shouldn't need to link GLU either. On some distributions of Linux, it's faster to install the GLU development libraries as it install all the GL and most of the X11 stuff. As for OpenAL, the linker complains about incompatible libraries. The ones you see in the openal templates, if I remember are for static linking in VS and are not compatible for the GNU tool chain which expects a compressed object file (.o wrapped in an .a archive) or dll. And besides. You shouldn't be really statically linking to openal-soft with it being under the LGPL license unless you are going to release the application under the LGPL as well.


Samah(Posted 2014) [#36]
@dawlane: I will also look at knocking up a VS2010/VS2013 Project file...

That'd be great, because I'm still having issues getting LibOVR working with MinGW. They have precompiled binaries for VC++, though.

Edit: I'm going to be away for about 3 weeks, so I won't be able to check this thread! Be sure to post your experiences for my triumphant return. :)


dawlane(Posted 2014) [#37]
OK VS is causing me problems. I can get it to compile after a few tweaks of Main.h, but running the executable generates a MAV on game.SetDelegate in the App class. So either I'm missing something or the target requires Visual Studio specific fixes.
Mark says he has a GLFW3 target ready to go, but is reluctant to release it because of the bugs in the GLFW3 library it's self and by reading some of the GLFW forum posts I couldn't blame him. Maybe could badger him to release what he has sofar as a separate down load.

There are a few post on the Occulus forum on compiling libOVR with MINGW, but on for the full SDK.


Samah(Posted 2014) [#38]
@dawlane: Mark says he has a GLFW3 target ready to go, but is reluctant to release it because of the bugs in the GLFW3 library it's self and by reading some of the GLFW forum posts I couldn't blame him.

This is what experimental feature branches are for. If Mark wants the community to contribute to the Monkey SDK by putting it on GitHub, he should be as transparent as possible with what he's doing. Developers helping developers - it's a win-win situation! :D

@dawlane: There are a few post on the Occulus forum on compiling libOVR with MINGW, but on for the full SDK.

I've read most of them already, and all of the forks people have provided are way out of date with the mainline. I managed to compile everything nicely with the penultimate release, but it would crash as soon as it tried to initialise the OVR OpenGL device. Common problem, apparently, and fixed in the newer SDK.

Also, hi from Sorrento, Italy!

Edit: dawlane, please give me your GitHub info so I can add you.