Mac OS X progress
I have committed preliminary Mac OS support to the branches/macos folder in subversion. I am starting a new topic because the old topic has a bunch of discussion which isn't relevant now.
Things which aren't currently supported:
* Fullscreen
* WinForms integration, including GLControl
Things which are supported:
* Game window creation
* Keyboard and mouse events
* Enumeration of supported display modes
OpenTK Example results on my machine are listed below. My machine is a Mac Mini, with OS X 10.4.11 installed. Graphics card is a built-in Intel GMA 950.
GLSL 1: First shader: Works, but gives message about requiring OpenGL 2.0
GLSL 2: Julia set: Gives message about requiring OpenGL 2.0, then black screen with FPS counter
OpenAL: Playback: Works
OpenGL 5: Vertex arrays: Null reference exception
OpenGL: GLU Tesselation: KeyNotFoundException is thrown
OpenGL: Simple FBO: Works (I am unsure if the resulting image is correct though)
Test: Audio Context Test: No error message.
Test: GameWindow states: Fullscreen min/max not implemented.
Test: Input Logger: Works okay if you click on the "hidden input window" at first. If you click on anything else, it stops working.
Test: Math speed test: KeyNotFoundException is thrown
Test: Resolution changes: Not supported yet.
Tutorial 1: Simple Window: Works
Tutorial 2: Immediate mode: Works
Tutorial 3: Display Lists: Works
Tutorial 3: Fonts: Works
Tutorial 4: Text: Runs, but text layout is messed up, except for FPS counter.
Tutorial 5: Texture mapping: Works
Tutorial 8: VBO's: Works after message about needing OpenGL 1.5.
WinForms 1: Runs, but no colors appear.
WinForms 2: Runs, but no response to input.
WinForms 3: Works
WinForms 4: Runs, but nothing appears in controls.
The KeyNotFoundException appears to be a bug in the CarbonGLNative window, so I will need to examine that more closely. Kamujin, if you can run the examples and let me know if you get the same results that will be helpful.
I've also done some refactoring in the library in how platform specific classes are instantiated.




Comments
Nov 04
19:25:00Re: Mac OS X progress
posted by the FiddlerCan you post the list of supported extensions and the reported version (as returned by
GetString)? The errors about the GL version are probably a result of mis-parsing the version string in GLHelper.cs:397 (BuildExtensionList method).Edit: I'm working on the text issues on Mono (which are blocking the 0.9.2 branch).
Nov 04
19:43:00Re: Mac OS X progress
posted by kanatoOk I will do so
Nov 04
21:14:53Re: Mac OS X progress
posted by JTaltonSweet.
Nov 04
21:53:00Re: Mac OS X progress
posted by the FiddlerThe text layout issue seems to be a result of line-ending handling. Kanato, can you please confirm this by opening Examples/Data/Poem.txt, saving it with native line-endings and running the Text example?
I'm trying to find if there is any way to specify the desired line-endings to GDI+.
Nov 04
21:59:00Re: Mac OS X progress
posted by InertiaThe output from Simple FBO should look like this. It's just a bunch of random triangles with random colors to fill the textures, so your result will vary a bit.
Not sure about the GLSL Fractal, it might have fallen back to software and you need to wait 5 minutes until the first frame is done. According to the info a quick google search turned up on the graphics chip it supports GL 1.4, so I'm quite impressed it runs at all.
Good to hear that OpenAL is not complaining ^^
Edit: What Mono version is installed? (just to avoid Mono 1.x.x versions to cause any conflicts, there have been some iirc which might explain the problem with the VBO example)
Nov 04
23:38:29Re: Mac OS X progress
posted by the FiddlerUpdate on the text rendering bug: this is actually a mono bug in libgdiplus. Currently looking for workarounds...
Nov 05
00:34:00Re: Mac OS X progress
posted by kanatoOk, sorry this took so long to post. It exposed another bug that I need to deal with. Right now the call to CGDisplayAvailableModes to list the graphics modes that the display supports crashes, unless a Windows.Forms.Form is created first. So it looks like there's some initialization that Mono's OSX driver does that I am not doing right now. Will look into it ASAP.
Vendor: Intel Inc.
Renderer: Intel GMA 950 OpenGL Engine
Version: 1.2 APPLE-1.4.56
Extensions: GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_vertex_blend GL_ARB_window_pos GL_ARB_shader_objects GL_ARB_vertex_shader GL_EXT_multi_draw_arrays GL_EXT_clip_volume_hint GL_EXT_rescale_normal GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_APPLE_client_storage GL_APPLE_specular_vector GL_APPLE_transform_hint GL_APPLE_packed_pixels GL_APPLE_fence GL_APPLE_vertex_array_object GL_APPLE_vertex_program_evaluators GL_APPLE_element_array GL_APPLE_flush_render GL_NV_texgen_reflection GL_NV_light_max_exponent GL_IBM_rasterpos_clip GL_SGIS_generate_mipmap GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_multitexture GL_ARB_texture_env_add GL_ARB_texture_cube_map GL_ARB_texture_env_dot3 GL_ARB_texture_env_combine GL_ARB_texture_compression GL_ARB_texture_mirrored_repeat GL_ARB_shadow GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_point_sprite GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ARB_pixel_buffer_object GL_EXT_framebuffer_object GL_EXT_texture_rectangle GL_ARB_texture_rectangle GL_EXT_texture_env_add GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_texture_lod_bias GL_EXT_abgr GL_EXT_bgra GL_EXT_stencil_wrap GL_EXT_texture_filter_anisotropic GL_EXT_separate_specular_color GL_EXT_secondary_color GL_EXT_blend_func_separate GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_blend_equation_separate GL_EXT_packed_depth_stencil GL_APPLE_flush_buffer_range GL_APPLE_ycbcr_422 GL_APPLE_texture_range GL_APPLE_pixel_buffer GL_NV_blend_square GL_ATI_texture_env_combine3 GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod
ShadingLanguageVersion: 1.10
Responses to other things:
I saved and tested the Poems.txt file with three different line endings, dos (\r\n), unix (\n) and mac (\r) as saved in vim. dos and unix give the same result, and the mac setting is even worse as it puts all the text on the same line. None of them give good results.
The FBO results look just like that, with some randomness, so that's good.
Edit: I am using Mono 2.0.1.
Nov 06
09:36:00Re: Mac OS X progress
posted by the FiddlerThanks for the info.
[Version string]
I'm a little confused here... According to apple's docs:
The GL_VERSION string begins with a version number. The version number uses one of these forms:
major_number.minor_number
major_number.minor_number.release_number
Vendor-specific information may follow the version number. Its depends on the implementation, but a space always separates the version number and the vendor-specific information.
If I understand this correctly, the string "1.2 APPLE-1.4.56" means support for GL1.2. In that case why do the drivers report "ShadingLanguageVersion: 1.10"? (Is GLSL even supported by the GMA950?)
[Text problems]
The issue here is that Mono's implementation of libgdiplus cannot handle newline characters (relevant discussion). I'll commit a workaround asap.
Nov 06
15:23:29Re: Mac OS X progress
posted by InertiaGL_ARB_shader_objects
GL_ARB_vertex_shader
GL_ARB_fragment_shader
It appears to support GLSL 1.1, when looking at this I cannot get rid of the feeling that this driver is heavily work-in-progress. E.g. GL_EXT_framebuffer_object is GL 1.5, although version reports something different.
Nov 11
04:08:39Re: Mac OS X progress
posted by kanatoOkay, I think I fixed the issue on calling CG functions. I will do some more thorough testing at this point before I move on to adding new features.
Nov 19
04:48:43Re: Mac OS X progress
posted by kanatoI am going on thanksgiving vacation in two days, so I probably won't be available to comment or work on this until after thanksgiving weekend. After that I expect to hit the ground running on getting WinForms support working.
Nov 21
15:34:38Re: Mac OS X progress
posted by the FiddlerSounds great, happy thanksgiving!
Dec 02
07:03:38Re: Mac OS X progress
posted by kanatoOkay, I am back. I just upgraded my mac mini to 2 GB of ram from 512 MB too, so it will make development on it a lot more tolerable.
Dec 03
16:05:40Re: Mac OS X progress
posted by JTaltonI have had a couple of hits lately asking about OSX support for my GTK# GLWidget. Once this is solid, would there be any objection to using this code as a basis for getting GLWidget working with OSX?
Dec 03
19:52:40Re: Mac OS X progress
posted by kanatoI have no objections to that. What needs to be done to make GLWidget work with OSX? Do you just need the AGL wrapper codes or something else in addition?
Dec 09
20:15:57Re: Mac OS X progress
posted by kanatoOk, an update on progress getting GLControl to work. First let me say, wow, what a nightmare. It's one of those problems that seems so obvious in hindsight but was so unclear initially. The problem was that AGL requires a call to aglSetDrawable for a context, but you must pass the desktop window handle to it. That part was always clear, however what was not clear initially was that because the context was created in the GLControl constructor this is before the control is added to the form it will end up on.
So now we can render to GLControl on Mac OS X. The three examples all work, although in the last example (Multiple GLControls test) the colors only show up after the window is resized.
Now the only thing left to get working is full screen support. Also, more testing is needed, so if anyone has a mac, give it a shot!
Dec 09
20:30:14Re: Mac OS X progress
posted by JTaltonGLWidget is a single cs file that just needs the right calls to setup the context. I've never messed with the AGL but I don't expect it to be too different from the WGL and GLX.
In GTK there is a realized event, and when this first happens is when I initialize the context. This ensures that the proper handles have all been initialized beforehand.
I'd love to test out the new functionality on my Mac, but I currently have a few higher priority items. I'll try to test it soon.
Glad to have OS X support in OpenTK! Thanks!
Dec 09
21:08:12Re: Mac OS X progress
posted by objarniFor testing purposes: Could someone compile, zip and attach this in this thread so I can share it with MAC-friends..? Thanks beforehand..
Dec 10
05:50:00Re: Mac OS X progress
posted by kanatoOk, I have attached the compiled binaries for the example launcher. I packed them into a finder friendly application, so they should be able to unzip and double-click. Have them test at least the examples "OpenAL: Playback" "Tutorial 2: Immediate mode" and WinForms 1 & 2. WinForms 2 will also show the driver name, which is useful to know for reports of working or non-working status. A couple examples won't work for sure, like tutorial 4 and "Test: GameWindow states," and the GLU tesselation test. The animated Julia set doesn't work on mine, but that may be because my video card sucks. Resolution changing also does not work at this point.
Dec 11
07:32:16Re: Mac OS X progress
posted by objarniThanks kanato!
Do I have to tell my pals to download/install mono..? Which version if so? Or is it there by default? What about OpenGL/OpenAL?
Dec 11
08:31:00Re: Mac OS X progress
posted by kanatoYes, they will need to install mono. There is a Mac OS installer for 2.0.1 on the mono webpage, which should be adequate. I think they shouldn't need to do anything with OpenGL and OpenAL, those will already be there.
Dec 18
18:23:04Re: Mac OS X progress
posted by kanatoHas anyone else had a chance to test this? I've done a fair amount of testing of OpenTK using AgateLib, and have found no major issues. I would like to know that this code runs on another Macintosh.
Dec 21
15:27:03Re: Mac OS X progress
posted by JTaltonI'll try to see if this works on my MacBook Pro tonight or tomorrow.
Dec 24
16:41:35Re: Mac OS X progress
posted by JTaltonCrashes every time on startup.
Dec 24
18:21:44Re: Mac OS X progress
posted by kanatoIs there any stacktrace or output to the console?
Dec 26
14:30:21Re: Mac OS X progress
posted by JTaltonDec 27
21:00:00Re: Mac OS X progress
posted by kanatoHuh, ok interesting. Unfortunately, GameWindow is swallowing the error and disposing the CarbonGLNative object which pointed out a separate bug from the one that is making it crash in the first place. Can you look inside the Examples package (right or control- click->show package contents) and look for the Contents/Resources/debug.log and post that as an attachment?
Dec 28
12:48:56Re: Mac OS X progress
posted by JTaltonCreating GraphicsContext.
GraphicsMode: Index: 1, Color: 32 (8888), Depth: 16, Stencil: False, Samples: 0, Accum: 0 (0000), Buffers: 2, Stereo: False
IWindowInfo: MacOS.CarbonWindowInfo: Handle 10167120
OpenTK.Platform.MacOS.MacOSException: AGL Error: BadPixelFormat invalid pixel format
Dec 28
01:56:20Re: Mac OS X progress
posted by kanatoOk, can you give this one a shot? I have included some extra debugging information about the pixel format that is chosen, and also excluded some pixel format flags that aren't necessary. Also, what video hardware do you have and what OS version? All my tests have been on OS X 10.4.11 with an Intel GMA 950.
Dec 29
03:47:00Re: Mac OS X progress
posted by JTaltonMost tests work great! Here are a few errors:
OpenGL 5 : Vertex Arrays (hidden) - Null Reference Exception
OpenGL : GLU Tessalation Test - Opens and then closes (not crash)
WinForms 3 : Extensions - Crash
WinForms 4: Multiple GLControls Test - Controls don't look right
The OpenAL test works fine.
MacBook Pro
OS X 10.5.6
2.16 GHz Intel Core Duo
ATI Radeon x1600 - 256 MB RAM
Woot! Can't wait to see if I can get Golem3D running on it. :)