Return symbol ? NSAddressOfSymbol(symbol) : NULL Symbol = image ? NSLookupSymbolInImage(image, symbolName, NSLOOKUPSYMBOLINIMAGE_OPTION_BIND | NSLOOKUPSYMBOLINIMAGE_OPTION_RETURN_ON_ERROR) : NULL Symbol = NSLookupAndBindSymbol(symbolName) */
* if (NSIsSymbolNameDefined(symbolName)) SymbolName = malloc(strlen((const char*)name) + 2) * prepend a '_' for the Unix C symbol mangling convention */ Image = NSAddImage("/System/Library/Frameworks/amework/Versions/Current/OpenGL", NSADDIMAGE_OPTION_RETURN_ON_ERROR) Static const struct mach_header* image = NULL Static void* AppleGLGetProcAddress (const GLubyte *name)
#Pcsx2 mac code
However, if for some reason these things still need to be requested, I think it might be instructive to look at the code that glloadgen generates: #if defined(_APPLE_) This is what I use for a project of mine: #ifdef _APPLE_ It's the only platform for which one doesn't have to request function pointers and the like. The Apple headers contain all included GL functions and extensions. OTOH does anyone know what is the OSX equivalent for glXGetProcAddress? If there is no such dynamic querying functionality then just static references needs to be used. Sorry I'm of no more use, especially codewise, for now I'm just applauding from the sidelines. At least last time I tried, the pure SDL version of PPSSPP worked better than the Qt+SDL hybrid, which crashed. I believe PPSSPP uses it for joysticks, or something, but uses mostly Qt for the actual windowing. I'm not sure for what end SDL2 is actually used (joystick support?). pcsx2 currently has an option to build with SDL support, with some vestigial bits of SDL2 even. That said, I make most of my stuff with SDL2 and it's very simple (no Objective-C for the user of the library) so perhaps that can be used to get things up and running quicker. This could perhaps avoid the need for SDL2. (A core profile is needed because otherwise OpenGL is limited to 2.1).
#Pcsx2 mac Patch
But I found this wxWidgets bug-report / patch which I think allows creating a core profile directly from wxWidgets (for a PS3 emulator no less). I'm quite fuzzy on how wxWidgets interoperates with other helpers/toolkits for GL context. Good job, in my opinion :).Īpple's OpenGL framework implementation or SDL2 or something else. It looks really good, didn't expect to see it all squashed into one commit but then again it's quite difficult to predict the work necessary and thus split it into multiple commits to work on it. I have pushed branch for people interested to take a look. A bit like neovim does when it can't find the right dependencies (libuv and luajit). So there would have to be a shellscript/makefile/cmake-file that downloads and compiles the dependencies with the right flags. This basically means that for a 32-bit OSX build, all libraries would have to be compiled on the spot by the buildsystem instead of downloaded with a package manager (like the populer homebrew). It gets a bit nastier when you're using lots of libraries though. ( EDIT: I just tested with a very simple AppKit binary, and it still seems to work with the -m32 flag, which probably means that apple distributes some important. For a simple console program one just needs to supply the -m32 flag to both the linker and the compiler. dylibs/frameworks for cocoa and the likes. I'm not sure how GUI programs deal with it, I don't know if apple still deploys 32-bit.
Running 32-bits code seems to be more or less ok, at least for console programs. What is the issue compiling 32bits code? running 32bits code? both? I'm not really sure what would be most feasible between the last two.
Split out the 32-bit specific parts (recompiler et al.) and the 64-bit parts and make them communicate via IPC (easy to do with the likes of nanomsg/libuv/., works cross-platform).Make sure everything builds as 64-bit.Run on a 64-bit linux system with multi-arch.So you can't use the same trick as on linux: Moreover, OSX 10.9 does not have a 32-bit variant. Since modern OSX is very 64-bit focused, you don't generally have something like multi-arch. The true problem is the dependencies, you can't freely mix/link 32-bit and 64-bit libraries. Possibly, although in the age of OSX 10.9 that's not that relevant anymore, almost anyone will have x86-64 chips and installs. Don't you have fat binary on osx which support both x86 and x86-64.
0 kommentar(er)
