I have a program on windows that manages OpenGL contexts, (things such as making them current, destroying them, pretty much everything but the actual creation). I've recently moved to programming on a mac, and I was wondering if there is some function similar to wglGetCurrentContext for OSX. I can't seem to find the documentation for these online.
Edit: The AGL (Apple GL) framework and more specifically the function aglGetCurrentContext are all deprecated.
You are looking for CGL (Core OpenGL).
The equivalent of wglGetCurrentContext() is CGLGetCurrentContext(). It works similarly.
There's the OpenGL Programming Guide for Mac, but I found the CGL reference to be rather more useful. I was unable to locate the CGL reference on Apple's website, but there's a mirror.
Related
Currently I'm doing some GLSL-stuff and to my surprise I cannot find a reasonable IDE for this (MacOS). Nothing to fancy, but just a way to change the code and see the results. I know of the Shadertoy-website, but I'm more interested in an offline solution.
So I came across the built-in OpenGL Shader Builder. According to Wikipedia, this is deprecated and superseded by GLSLEditorSample, which should still be available as an example project for XCode (of which I have version 7.3.1 installed). However, I basically cannot find anything about this, online nor on my computer. Therefor my question: Is this still relevant? If so, where is it located?
PS: if you know of any other GLSL IDEs, I'm open to that as well
Here they explain how to setup OpenGL on a MacOS on Xcode:
https://www.youtube.com/watch?v=Tz0dq2krCW8&list=PLRtjMdoYXLf6zUMDJVRZYV-6g6n62vet8
I'm an experienced Linux programmer, familiar with POSIX, stdio.h and so on, but totally new to Mac programming. This week I'm attempting to get a piece of source code written by someone else a few years ago to work on 64-bit Snow Leopard. It's a Photoshop plugin originally for CS3, now to be made to work with CS5. (Don't ask me about CS4.) This plugin is built at the command line with a handwritten makefile using gcc.
The main roadblock today is the compiler complaining about several undeclared functions: FSRead, FSWrite, SetFPos, GetFPos, and more, all having to do with files. I'm pretty sure I have the right paths, options etc.
After two days grepping headers, googling, and trying to cheap hacks, I am stuck. Where are these functions defined? Are they standard Mac OS X library functions, or Photoshop SDK functions? Some google results suggest these functions are obsolete, "deprecated" but I guess by now truly gone. If that's the case, what should I be using instead?
After two days grepping headers, googling, and trying to cheap hacks, I am stuck. Where are these functions defined? Are they standard Mac OS X library functions, or Photoshop SDK functions?
They are old Carbon APIs. You can use the Carbon framework, however Carbon is not ported to 64-bit systems. As Photoshop is 64bit, this simply won't work.
I'm not familiar with how Photoshop plugins are handled, but if you are looking for a direct replacement you would look at Core Foundation, a C API. In reality, you can also use the POSIX APIs. If Photoshop uses Cocoa and Objective-C, you can use the Foundation and AppKit family of APIs.
Is xlib still used? The helpful documentation I can find is http://tronche.com/ which looks, to me, very outdated. Who uses Xlib? Is GTK+ and QT built on it? thanks in advance, ell.
Yes, toolkits like GTK+ and Qt are still built on Xlib. Migration to xcb is in progress, but far from complete or universal. Applications though really should be writing to the toolkit API's, not Xlib.
BTW, you can also find Xlib docs directly from the source at X.Org: http://www.x.org/releases/current/doc/
These days, libxcb is used. There is also an xlib compatibility layer still available (xlib-xcb).
Well if you want hardware acceleration, according to freedesktop.org:
an OpenGL application on the X Windows must use Xlib and thus can’t be done using only XCB.
You have to have xlib even if you're only using xcb if you want opengl.
I want to learn Ocaml or Haskell and I want to do it by writing a simple game. Apparently, there's one small problem: nobody cares about Windows and I want to do it on Windows, natively.
Haskell has Cabal, which has SDL, but it doesn't build due to a trivial problem with no workarounds (order of parameters passed to gcc). Ocaml doesn't even have that, it's all in source packages, be it GLCaml or OcamlSDL or whatever.
Is there a place where I can get a working SDL for Haskell or Ocaml on Windows without fighting with a dozen versions of compilers?
The Haskell Platform comes with a binding to OpenGL which should work out of the box on Windows.
Concerning the SDL package on hackage, you can use cabal unpack SDL to get the source code and fix things yourself. To install the package with your changes, run cabal install in the unpacked directory. In any case, drop a line to the maintainer, I'm sure he'll help out.
It's not related to SDL, but you've mentioned OpenGL. There is LablGL binding for OpenGL in OCaml which works out of the box. Wiki example (http://en.wikipedia.org/wiki/Objective_Caml#Triangle_.28graphics.29) compiles and works just fine.
The best instructions I've found for getting SDL to work in windows with a the most recent Haskell platform can be found at this blog. I followed everything step-by-step and it worked perfectly, despite some configure error messages.
It isn't SDL but GLFW works on Windows with Haskell through Cabal.
My article High-fidelity graphics with OpenGL 2 (25th Feb 2008) explained how the GLCaml bindings can be used to write OpenGL-based applications in OCaml that use vertex and fragment shaders (a phong shader is given as an example). There are 9 articles in the OCaml Journal on OpenGL, albeit mostly using the older LablGL library for OpenGL 1.1.
I tried and failed to get OpenGL working from Haskell under Linux in 2007. The Haskell Platform may have changed that but I have neither had time to try it yet myself nor ever heard of anyone using it for this.
However, both OCaml and Haskell must rely upon fragile low-level bindings to OpenGL because they are standalone languages and nobody has ever managed to get any significant commercial software using them to work. As you're on Windows, F#+XNA is a far more logical choice because XNA is tried and tested and F# has a safe high-level interface to it. A Google fight gives you a good idea of what a pioneer you'll be: +haskell +opengl gives 437 hits on Google and +ocaml +opengl gives only 347 hits.
I thought this should be easy, but... geesh! A vendor gave me a fairly simple demo program meant to showcase some trivial icon animations. The target platform is an embedded system (MX51) with accelerated OpenGL ES 2.0/OpenVG and EGL support.
Unfortunately, the demo also has an annoying dependency on a few Qt utility classes (e.g., QImage). If not for this dependency, I would compile/run the thing on the target. But I don't relish the thought of cross-compiling Qt just to run this little demo---even if there were enough room for it on the embedded board.
I hoped I might be able to run the app on a standard(ish) Ubuntu 10.04 VM, and started following these directions to make it happen. And I actually managed---like, 10 hours later---to compile everything and get a runnable binary of the demo program. However, when I run it, I see the following error:
eglCreateWindowSurface: egl error "EGL_BAD_CONFIG" (0x3005)
Sigh. Not what I wanted to see after all that effort. This seems way more difficult than it should be.
Is the embedded GL landscape really such a ghetto that I have to run even trivial programs on the target using some vendor-supplied BSP? Judging from the lack of responses to this guy's question, I'm thinking the answer might be yes. But I don't even care about acceleration (yet). I just want to run the stupidest of OpenGL ES 2/OpenVG programs on a desktop PC and get an idea of how it looks. (It doesn't matter to me whether the PC is running Linux or Windows.) How do people do this sort of thing?
There are several OpenGL ES 2.0 emulators, such as:
For ARM Mali GPUs
For PowerVR GPUs
Also very recently, AMD has posted drivers that expose OpenGL ES 2.0 on desktop.
More recently, OpenGL 4.1 exposes the GL_ARB_ES2_compatibility extension, which makes OpenGL 4.1 drivers GL ES 2.0 compatible.
For OpenVG, you can use AmanithVG GLE.
Qualcomm's OpenGL ES emulator includes OpenVG support. You can download it from http://developer.qualcomm.com