Open pizthewiz opened 9 years ago
When I compile, it looks like those are being pulled from: Externals/GL/GL/glext.h.
I'm actually not very familiar with this deep of a level of the OpenGL structure. Is MacOS not supposed to use GL/GL/glext.h or is there a problem with a including it?
I don't know much about GL extensions, but these PFN
types are the function pointers that are seemingly not defined on OS X - I asked in #oculus
on Freenode after someone else mentioned compiling Dolphin on Linux, and it was suggested we use an extension wrapper like GLEW or GLee.
When the OVR SDK isn't found, the compile goes without a hitch (but dies linking on a missing OVR static lib), so I'm also guessing the errors come out some code for the Rift additions?
That tweak you made to FindOculus.cmake is actually necessary for general development on anything but Arch linux, so probably best to include it.
I think every operating system (Android, Windows, Linux, Mac) use a different GL extension, and they have to be tweaked individually to support them. It's probably an issue with missing implementation in whatever GL backend mac uses. (Windows uses WGL, Linux uses GLX, what does Mac use?) I'll see what I can do about supporting it but I don't really have anywhere to test.
@feilen I'm taking a look at this again and I think OS X uses AGL in Dolphin. I had to tweak FramebufferManager.cpp
on OS X and tweak AGL.h
and AGL.cpp
to add offscreen
variant methods, but it is still blows up on the unknown types. Does Linux use glext.h
and Windows uses wglext.h
?
diff --git a/Source/Core/VideoBackends/OGL/FramebufferManager.cpp b/Source/Core/VideoBackends/OGL/FramebufferManager.cpp
index eb97dc5..c94596e 100644
--- a/Source/Core/VideoBackends/OGL/FramebufferManager.cpp
+++ b/Source/Core/VideoBackends/OGL/FramebufferManager.cpp
@@ -6,6 +6,8 @@
#include "VideoBackends/OGL/GLInterface/WGL.h"
#include "VideoCommon/VR920.h"
+#elif defined(__APPLE__)
+#include "VideoBackends/OGL/GLInterface/AGL.h"
#else
#include "VideoBackends/OGL/GLInterface/GLX.h"
#endif
Okay, I've got a working, totally legitimate OSX install to play with now. I'm working on getting support up and running right now. Unfortunately I don't actually have functioning 3d acceleration, but it's working well enough to sort out compilation bugs, but I might need your help in testing it once I've got that sorted out.
Great! Just point me at a branch and let me know what you'd like some eyes on.
Guess the problem is more complicated than I thought. I'll have to get back to you.
I'm thinking a possible (well, probable) source of issues is where when porting I'd change something windows-specific to something like:
#ifdef _WIN32
// windows stuff
#else
// linux stuff, sometimes using glx.h
#endif
I'll go over the differences between this and the dolphin-core and find anything I can like that, see what needs changing there.
A small tweak is needed to find the OVR SDK on OS X:
which then results in:
But after doing so, complication of the GL bits seems to explode with unknown
PFN
prefixed GL types, which I think would have been defined byglext.h
no?