Porting GLUT/C -> Cocoa+NSOpenGLView
Hi,
I have a simulation program written in pure C with GLUT which builds and works as a charm both on Linux and on MacOs, w/o any modification. When linked against the MacOs frameworks, glut uses all the standard Aqua widgets - everything is very nice *but*... I would like to port my application to Cocoa, in order to update the interface and make it more "MacOs compliant" (at the moment, a drop-down menu is managed by GLUT and most of the actions are keyboard-driven).
Here comes the problem(s). At the moment, I rely on the glut run-loop to perform the calculation/rendering and to capture user events. When porting to cocoa, is there anything like GLUT? I refer both to the "simplified" OpenGL routines (including dealing with the trackball) and to the keyboard-handling loop. I "isolated" three possible "problems":
1) Keyboard handling: indeed, even though the interface will be streamlined, I would like to keep some commands keyboard-driven (don't know how to do that but I guess capturing such events will not be particularly tough in cocoa).
2) Dealing with the application loop: calculations and rendering can be put into a NSTimer or even spawned into threads (I know how to do that). I don't know yet if another timer/thread is needed to deal with the keyboard.
3) Rendering: the actual implementation of rendering scares me the most because I know nothing of "pure" OpenGL. The only thing I can imagine is to subclass NSOpenGLView and implement my custom drawRect()...What to put inside the "drawRect()" is not clear to me though :)
If you are curious about what I am talking about, the program can be found here (I also attached the files to this thread):
http://www.fisica.unige.it/~cavaliere/soft/Wm3D.zip
and the (admittedly messy) source here
Attachment: Wm3D.zip (625.0KB)
Attachment: Wm3D_Src.zip (13.0KB)
The Hillegass has a small section on OpenGL. Also see Apple stuff: http://developer.apple.com/graphicsimaging/opengl/
For keyboard commands, make shortcuts in the menu bar (Interface Builder). The keyboard is dealt with in the menu bar, and also on buttons. Again, the Hillegass speaks of this.
As K says, please look at the book by Aaron Hillegass and download/build/run some of Apple's sample code. I think you'll feel a "out of your comfort zone" initially - however you'll be fine. Try to learn and accept Apple's ways of doing things and all the Cocoa goodness will be yours. If you try to force cocoa to be an emulation of your more familiar environment, you'll probably be frustrated and not get the benefit of the good things in Cocoa.
I don't know what GLUT is - however I've see the term used in connection with OpenGL, so I think you will find that your application will port over to the Mac.
If you want the keyboard events (before they arrive in the menus), this is quite possible. So you can use keys for navigation, panning and zooming. This is not a common UI convention on the Mac, however it can be done if you wish. It's more common to have commands in the Menu's and associated hot keys (cmd-U for U, cmd-D for down) and the like. Of course this involves two key depressions - however Apple users expect this.
drawRect is called and you are expected to use drawing/OpenGL to draw into the rectangle. If you have your image already rendered, you could BLT (block transfer) the graphics to the display. However I suspect that when you "go with the flow" and use Apple's OpenGL support, you'll soon be quite happy.
I'll have a look at the code you send after work this evening on Linux.
Done that! Working with the NSOpenGLView is a bit tricky to say the very least but...task accomplished. Only thing left, to print the GL view. Trying to do that, today, resulted in a fully-fledged *kernel panic* (the first in something like 4 years). Great! :)
kernel panic eh?
Congratulations on getting that work done. I can sense that you feel good about this. That's great.
Printing in Cocoa is usually quite easy. It's about the same as drawing to the display. I deal with this in the "Diary" tutorial. http://clanmills.com/articles/cocoatutorials/
I'm very surprised to hear about a kernel panic. I honestly can't remember the last time I've seen any on my machines (Mac or Linux or Windows) crash.
As far as I understood it, the usual
NSOpenGLView *glView;
// Render stuff
[glView print: self]
won't work with the NSOpenGLView (indeed, it does not). One has to copy the rendering into a NSView and then print the NSViewRep.The crash occurred in the bit-to-bit copy from the OpenGL buffer to the NSView, by choosing the wrong pixel format. And the crash was *within* the NVidia driver! I think Apple engineers will be happy to see my crash logs...
Goodness! I am surprised. So you're saying that OpenGL is rendering directly to the video card hardware and then you're doing a bit by bit copy from the hardware framebuffer to memory (NSView). That's an unusually complex thing to do. Manipulating the bits in a framebuffer is often rather tricky. Well that explains the kernel panic - you are crashing in "the other side".
Yes, power of the pointers! Apparently, you must first copy to an offscreen buffer in order to be able to print. Still I did not sort out the issue and I fear to do so, since each debugging session is potentially costing me a reboot. Too bad, I thought the glPixelRead thing or so was not *that* low level. And the worst thing is that, using Carbon and Glut the system creates "by default" a "main menu" with a "print" voice which worked like a charm. Oh, the joy of porting... ;)
