New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Mac OS X support #5

Closed
1l0 opened this Issue Jul 30, 2014 · 27 comments

Comments

Projects
None yet
@1l0

1l0 commented Jul 30, 2014

馃憤

@nf

This comment has been minimized.

Show comment
Hide comment
@nf

nf Aug 4, 2014

What stands in the way of this?

nf commented Aug 4, 2014

What stands in the way of this?

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Aug 4, 2014

Contributor

Hi all,

For Azul3D to be usable on OS X, we would need:

  1. Fix any build errors from azul3d.org/native/gl.v1, which is generated using azul3d.org/cmd/glwrap.v1. The fix would probably be ~100 lines.
  2. Find out if OS X already supports high-precision clocks via Go's time package, or if we need to add a high precision clock via some OS X API into the azul3d/clock.v1 package (high precision clocks are needed for measuring frame rate deviation, used to e.g. move something over a period of time).
  3. Run the examples and make sure that our OpenGL 2.x renderer (azul3d.org/gfx/gl2.v1) can run properly on OS X, perhaps we may run into some strange issue their with those graphics drivers.

For this issue to be closed fully, we would additionally need to:

  1. Fix any build errors with azul3d.org/native/freetype.v1, which shouldn't be too difficult.
  2. Fix any build errors with azul3d.org/native/cp.v1, which shouldn't be too difficult.
  3. Write a Cocoa backend for the azul3d.org/chippy.v1 package (which is the biggest roadblock for all of this), without that package people will have to use GLFW3 or QML for window management (there are two respective examples for this), which requires some verbose setup code.

I won't have any access to Apple hardware for around two more weeks, but I can set up a VM and see what good I can do from there w.r.t. most of the build errors listed above.

Stephen

Contributor

slimsag commented Aug 4, 2014

Hi all,

For Azul3D to be usable on OS X, we would need:

  1. Fix any build errors from azul3d.org/native/gl.v1, which is generated using azul3d.org/cmd/glwrap.v1. The fix would probably be ~100 lines.
  2. Find out if OS X already supports high-precision clocks via Go's time package, or if we need to add a high precision clock via some OS X API into the azul3d/clock.v1 package (high precision clocks are needed for measuring frame rate deviation, used to e.g. move something over a period of time).
  3. Run the examples and make sure that our OpenGL 2.x renderer (azul3d.org/gfx/gl2.v1) can run properly on OS X, perhaps we may run into some strange issue their with those graphics drivers.

For this issue to be closed fully, we would additionally need to:

  1. Fix any build errors with azul3d.org/native/freetype.v1, which shouldn't be too difficult.
  2. Fix any build errors with azul3d.org/native/cp.v1, which shouldn't be too difficult.
  3. Write a Cocoa backend for the azul3d.org/chippy.v1 package (which is the biggest roadblock for all of this), without that package people will have to use GLFW3 or QML for window management (there are two respective examples for this), which requires some verbose setup code.

I won't have any access to Apple hardware for around two more weeks, but I can set up a VM and see what good I can do from there w.r.t. most of the build errors listed above.

Stephen

@dskinner

This comment has been minimized.

Show comment
Hide comment
@dskinner

dskinner Aug 7, 2014

To note, I have an old 2011/2012 (idk) MBP running 10.4 I can fire up and test on. While I'm more interested in mobile, OSX support is important to me as well so I dont mind testing when changes start getting pushed.

dskinner commented Aug 7, 2014

To note, I have an old 2011/2012 (idk) MBP running 10.4 I can fire up and test on. While I'm more interested in mobile, OSX support is important to me as well so I dont mind testing when changes start getting pushed.

@comaldave

This comment has been minimized.

Show comment
Hide comment
@comaldave

comaldave Aug 9, 2014

I do not have OSX but I would be willing to try setting up a VM for testing. Just not sure the gl graphics will work with VM. I failed to get it working in windows VM. Not saying it won't work, just that I am not smart enough to do it.

comaldave commented Aug 9, 2014

I do not have OSX but I would be willing to try setting up a VM for testing. Just not sure the gl graphics will work with VM. I failed to get it working in windows VM. Not saying it won't work, just that I am not smart enough to do it.

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Aug 10, 2014

Contributor

Write a Cocoa backend for the azul3d.org/chippy.v1 package ... without that package people will have to use GLFW3

Ugh, tossing away years of work that went into making GLFW 3 solve that problem (as well as possible)... I would volunteer to do the other parts since I have immediate access to a Mac, but I'm not motivated to do this part.

Contributor

dmitshur commented Aug 10, 2014

Write a Cocoa backend for the azul3d.org/chippy.v1 package ... without that package people will have to use GLFW3

Ugh, tossing away years of work that went into making GLFW 3 solve that problem (as well as possible)... I would volunteer to do the other parts since I have immediate access to a Mac, but I'm not motivated to do this part.

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Aug 10, 2014

Contributor
  1. Fix any build errors from azul3d.org/native/gl.v1, which is generated using azul3d.org/cmd/glwrap.v1. The fix would probably be ~100 lines.

What do you think about using https://github.com/go-gl/glow? It seems to be solving the same problem, and is actively developed and maintained. It works on OS X already.

Contributor

dmitshur commented Aug 10, 2014

  1. Fix any build errors from azul3d.org/native/gl.v1, which is generated using azul3d.org/cmd/glwrap.v1. The fix would probably be ~100 lines.

What do you think about using https://github.com/go-gl/glow? It seems to be solving the same problem, and is actively developed and maintained. It works on OS X already.

@dskinner

This comment has been minimized.

Show comment
Hide comment
@dskinner

dskinner Aug 10, 2014

I may be mistaken, but I don't believe glow supports batching to start.

On Sun, Aug 10, 2014 at 3:50 PM, Dmitri Shuralyov notifications@github.com
wrote:

  1. Fix any build errors from azul3d.org/native/gl.v1, which is
    generated using azul3d.org/cmd/glwrap.v1. The fix would probably be
    ~100 lines.

    What do you think about using https://github.com/go-gl/glow? It seems to
    be solving the same problem, and is actively developed and maintained. It
    works on OS X already.


Reply to this email directly or view it on GitHub
#5 (comment).

dskinner commented Aug 10, 2014

I may be mistaken, but I don't believe glow supports batching to start.

On Sun, Aug 10, 2014 at 3:50 PM, Dmitri Shuralyov notifications@github.com
wrote:

  1. Fix any build errors from azul3d.org/native/gl.v1, which is
    generated using azul3d.org/cmd/glwrap.v1. The fix would probably be
    ~100 lines.

    What do you think about using https://github.com/go-gl/glow? It seems to
    be solving the same problem, and is actively developed and maintained. It
    works on OS X already.


Reply to this email directly or view it on GitHub
#5 (comment).

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Aug 10, 2014

Contributor

That's interesting. /cc @errcw

Are there any benchmarks聽showing that doing batching at the Go/cgo boundary is a worthwhile pursuit?

Contributor

dmitshur commented Aug 10, 2014

That's interesting. /cc @errcw

Are there any benchmarks聽showing that doing batching at the Go/cgo boundary is a worthwhile pursuit?

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Aug 11, 2014

Contributor

Ugh, tossing away years of work that went into making GLFW 3 solve that problem (as well as possible)... I would volunteer to do the other parts since I have immediate access to a Mac, but I'm not motivated to do this part.

I think you have misunderstood severely. Azul3D has a generic OpenGL 2.X renderer that works with any window/display manager as long as there is an active GL 2.X context available. It can work with GLFW3, SDL, QT5/QML, and Chippy. You would not need to write a Cocoa backend to use Azul3D on OS X -- you can just use GLFW3 in place of Chippy.

Working examples using Azul3D's GL 2.X render with both QML and GLFW3 are available:
https://github.com/azul3d/examples/tree/master/azul3d_glfw3_clearing
https://github.com/azul3d/examples/tree/master/azul3d_qml_clearing

I understand that there are a large number of people here waiting on OS X support -- and I am working on it. Please be patient or, if you can, help out. Once I have solved some of the issues at hand I will ask some of those with actual Apple hardware around to test and ensure everything works OK.

What do you think about using https://github.com/go-gl/glow? It seems to be solving the same problem, and is actively developed and maintained. It works on OS X already.

I'm not so certain either way. Our binding generator (ahttps://github.com/azul3d/cmd-glwrap) does support call batching, and I don't know what the performance is either way. I don't have any benchmarks of it.

But it also supports full tracebacks of OpenGL calls when an OpenGL error arises, I'm not sure if glow also supports that. I think it would be better to just solve the issues at hand with that tool.

Stephen

Contributor

slimsag commented Aug 11, 2014

Ugh, tossing away years of work that went into making GLFW 3 solve that problem (as well as possible)... I would volunteer to do the other parts since I have immediate access to a Mac, but I'm not motivated to do this part.

I think you have misunderstood severely. Azul3D has a generic OpenGL 2.X renderer that works with any window/display manager as long as there is an active GL 2.X context available. It can work with GLFW3, SDL, QT5/QML, and Chippy. You would not need to write a Cocoa backend to use Azul3D on OS X -- you can just use GLFW3 in place of Chippy.

Working examples using Azul3D's GL 2.X render with both QML and GLFW3 are available:
https://github.com/azul3d/examples/tree/master/azul3d_glfw3_clearing
https://github.com/azul3d/examples/tree/master/azul3d_qml_clearing

I understand that there are a large number of people here waiting on OS X support -- and I am working on it. Please be patient or, if you can, help out. Once I have solved some of the issues at hand I will ask some of those with actual Apple hardware around to test and ensure everything works OK.

What do you think about using https://github.com/go-gl/glow? It seems to be solving the same problem, and is actively developed and maintained. It works on OS X already.

I'm not so certain either way. Our binding generator (ahttps://github.com/azul3d/cmd-glwrap) does support call batching, and I don't know what the performance is either way. I don't have any benchmarks of it.

But it also supports full tracebacks of OpenGL calls when an OpenGL error arises, I'm not sure if glow also supports that. I think it would be better to just solve the issues at hand with that tool.

Stephen

@errcw

This comment has been minimized.

Show comment
Hide comment
@errcw

errcw Aug 11, 2014

But it also supports full tracebacks of OpenGL calls when an OpenGL error arises, I'm not sure if glow also supports that

FWIW adding OpenGL function tracing is a trivial addition to Glow (at least the simplistic version logging every function call and its arguments); Glow also supports the OpenGL debug callbacks. If this is the feature holding you back from adopting Glow I'd be happy to prioritize it immediately. While I want to support a diverse Go/OpenGL ecosystem I'd also like to ensure we can all benefit from collective improvements to common packages.

errcw commented Aug 11, 2014

But it also supports full tracebacks of OpenGL calls when an OpenGL error arises, I'm not sure if glow also supports that

FWIW adding OpenGL function tracing is a trivial addition to Glow (at least the simplistic version logging every function call and its arguments); Glow also supports the OpenGL debug callbacks. If this is the feature holding you back from adopting Glow I'd be happy to prioritize it immediately. While I want to support a diverse Go/OpenGL ecosystem I'd also like to ensure we can all benefit from collective improvements to common packages.

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Aug 11, 2014

Contributor

But it also supports full tracebacks of OpenGL calls when an OpenGL error arises, I'm not sure if glow also supports that. I think it would be better to just solve the issues at hand with that tool.

It may be better/easier in the short run, but what about long run?

https://twitter.com/ID_AA_Carmack/status/452582113955426305

We have the opportunity to do better. Both go-gl repos and Azul3D repos are open source and anyone can contribute to make them better. Assuming two packages have an identical purpose, wouldn't it be nicer to have just one place to contribute to instead? You are welcome to open issues in go-gl, submit PRs and even become a collaborator eventually if you wish.

While I want to support a diverse Go/OpenGL ecosystem I'd also like to ensure we can all benefit from collective improvements to common packages.

That's my vision too.

Contributor

dmitshur commented Aug 11, 2014

But it also supports full tracebacks of OpenGL calls when an OpenGL error arises, I'm not sure if glow also supports that. I think it would be better to just solve the issues at hand with that tool.

It may be better/easier in the short run, but what about long run?

https://twitter.com/ID_AA_Carmack/status/452582113955426305

We have the opportunity to do better. Both go-gl repos and Azul3D repos are open source and anyone can contribute to make them better. Assuming two packages have an identical purpose, wouldn't it be nicer to have just one place to contribute to instead? You are welcome to open issues in go-gl, submit PRs and even become a collaborator eventually if you wish.

While I want to support a diverse Go/OpenGL ecosystem I'd also like to ensure we can all benefit from collective improvements to common packages.

That's my vision too.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Aug 11, 2014

Contributor

I would like to stress that what may be best in the long run may not be best for this immediate point in time. I think switching to Glow right now would be more effort than fixing glwrap for OS X, and could potentially cause a degrade in performance due to lack of call batching.

Right Now:

  • We want OS X support, as soon as possible.
  • I know the glwrap code very well, the time it would take me to get the generated wrappers to work on OS X would be far less than it would take me to switch the renderer over to using Glow bindings.
  • glwrap supports debug builds (logging of OpenGL calls/arguments on glError) and batching of C calls already today, switching to Glow could cause a loss in performance (we literally do not know).

Long Term:

  • Combine our efforts.
  • Determine how much performance we get from C call batching, and add it to Glow if the results are good.
  • Add debug builds to Glow (just logging GL function calls and their arguments).
  • I've also had thoughts about this but haven't implemented it ever: find a way to generate wrappers for just the functions/definitions we actually need in the renderer. A lot of time is probably wasted compiling these large wrappers (for example, have Glow take a JSON file of symbols we want, or something like that).

I too want to ensure that we all collaborate and reap the benefits. I think debug builds would be a useful addition to Glow, and I think we should benchmark call batching to actually see what the benefit really is.

But I think for the short-term, it makes the most sense to just fix glwrap so we can get OS X working faster.

Contributor

slimsag commented Aug 11, 2014

I would like to stress that what may be best in the long run may not be best for this immediate point in time. I think switching to Glow right now would be more effort than fixing glwrap for OS X, and could potentially cause a degrade in performance due to lack of call batching.

Right Now:

  • We want OS X support, as soon as possible.
  • I know the glwrap code very well, the time it would take me to get the generated wrappers to work on OS X would be far less than it would take me to switch the renderer over to using Glow bindings.
  • glwrap supports debug builds (logging of OpenGL calls/arguments on glError) and batching of C calls already today, switching to Glow could cause a loss in performance (we literally do not know).

Long Term:

  • Combine our efforts.
  • Determine how much performance we get from C call batching, and add it to Glow if the results are good.
  • Add debug builds to Glow (just logging GL function calls and their arguments).
  • I've also had thoughts about this but haven't implemented it ever: find a way to generate wrappers for just the functions/definitions we actually need in the renderer. A lot of time is probably wasted compiling these large wrappers (for example, have Glow take a JSON file of symbols we want, or something like that).

I too want to ensure that we all collaborate and reap the benefits. I think debug builds would be a useful addition to Glow, and I think we should benchmark call batching to actually see what the benefit really is.

But I think for the short-term, it makes the most sense to just fix glwrap so we can get OS X working faster.

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Aug 11, 2014

Contributor

I would like to stress that what may be best in the long run may not be best for this immediate point in time.

I too want to ensure that we all collaborate and reap the benefits. I think debug builds would be a useful addition to Glow, and I think we should benchmark call batching to actually see what the benefit really is.

But I think for the short-term, it makes the most sense to just fix glwrap so we can get OS X working faster.

Great to hear, so we're in agreement! 馃憤

I didn't mean to imply you should switch to go-gl/glow right now or never. What I meant is that you should be aware of it and consider it, and if it makes sense, we can work towards a convergence eventually.

Thanks!

Contributor

dmitshur commented Aug 11, 2014

I would like to stress that what may be best in the long run may not be best for this immediate point in time.

I too want to ensure that we all collaborate and reap the benefits. I think debug builds would be a useful addition to Glow, and I think we should benchmark call batching to actually see what the benefit really is.

But I think for the short-term, it makes the most sense to just fix glwrap so we can get OS X working faster.

Great to hear, so we're in agreement! 馃憤

I didn't mean to imply you should switch to go-gl/glow right now or never. What I meant is that you should be aware of it and consider it, and if it makes sense, we can work towards a convergence eventually.

Thanks!

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Aug 15, 2014

Contributor

Could someone else verify that the azul3d.org/native/cp.v1 package builds on OS X? Please run:

go get -u azul3d.org/native/cp.v1

And report any errors encountered here: azul3d-legacy/native-cp#3

Contributor

slimsag commented Aug 15, 2014

Could someone else verify that the azul3d.org/native/cp.v1 package builds on OS X? Please run:

go get -u azul3d.org/native/cp.v1

And report any errors encountered here: azul3d-legacy/native-cp#3

@Zaerei

This comment has been minimized.

Show comment
Hide comment
@Zaerei

Zaerei Aug 22, 2014

FWIW, yes, batching is pretty clearly a performance improvement. I made a simple benchmark of a Function That Doesn't Really Do Anything鈩 (adding two numbers) using a naive batching mechanism, and the performance gains are immense. Gist:

https://gist.github.com/Jragonmiris/e94d92725704ff21550f

I suppose the impact likely goes down as the running time of the actual function goes up -- e.g. it may be less significant for "big payload" functions like glDrawArrays or glBufferData that do a lot of legwork, but it's almost absolutely significant for smaller functions like glUseProgram or glBindBuffer that do little more than call into C to set a flag somewhere.

Zaerei commented Aug 22, 2014

FWIW, yes, batching is pretty clearly a performance improvement. I made a simple benchmark of a Function That Doesn't Really Do Anything鈩 (adding two numbers) using a naive batching mechanism, and the performance gains are immense. Gist:

https://gist.github.com/Jragonmiris/e94d92725704ff21550f

I suppose the impact likely goes down as the running time of the actual function goes up -- e.g. it may be less significant for "big payload" functions like glDrawArrays or glBufferData that do a lot of legwork, but it's almost absolutely significant for smaller functions like glUseProgram or glBindBuffer that do little more than call into C to set a flag somewhere.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Aug 22, 2014

Contributor

@Jragonmiris and others: sorry that I didn't link my benchmark here earlier.

I did perform a benchmark of batching and the results can be seen here: http://github.com/slimsag/cgo-batching

There is also a somewhat in-depth (with more words from me soon) over at go-gl/glow#40 which talks a bit about adding it to Glow.

Stephen

Contributor

slimsag commented Aug 22, 2014

@Jragonmiris and others: sorry that I didn't link my benchmark here earlier.

I did perform a benchmark of batching and the results can be seen here: http://github.com/slimsag/cgo-batching

There is also a somewhat in-depth (with more words from me soon) over at go-gl/glow#40 which talks a bit about adding it to Glow.

Stephen

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Aug 30, 2014

Contributor

Would those willing to test on OS X please see this comment? Thanks!

Contributor

slimsag commented Aug 30, 2014

Would those willing to test on OS X please see this comment? Thanks!

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Sep 2, 2014

Contributor

nudge nudge here ya'll go:

http://azul3d.org/news/2014/mac-osx-support.html

As always, let me know what is broken =)

Contributor

slimsag commented Sep 2, 2014

nudge nudge here ya'll go:

http://azul3d.org/news/2014/mac-osx-support.html

As always, let me know what is broken =)

@slimsag slimsag closed this Sep 2, 2014

@dskinner

This comment has been minimized.

Show comment
Hide comment
@dskinner

dskinner Sep 2, 2014

this means today you can Azul3D to develop games

minor type, should be "you can [use] ..."

Look forward to trying it out, thanks!

On Tue, Sep 2, 2014 at 3:55 PM, Stephen Gutekanst notifications@github.com
wrote:

nudge nudge here ya'll go:

http://azul3d.org/news/2014/mac-osx-support.html

As always, let me know what is broken =)


Reply to this email directly or view it on GitHub
#5 (comment).

dskinner commented Sep 2, 2014

this means today you can Azul3D to develop games

minor type, should be "you can [use] ..."

Look forward to trying it out, thanks!

On Tue, Sep 2, 2014 at 3:55 PM, Stephen Gutekanst notifications@github.com
wrote:

nudge nudge here ya'll go:

http://azul3d.org/news/2014/mac-osx-support.html

As always, let me know what is broken =)


Reply to this email directly or view it on GitHub
#5 (comment).

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Sep 2, 2014

Contributor

Fixed, thanks for the heads up!

Contributor

slimsag commented Sep 2, 2014

Fixed, thanks for the heads up!

@1l0

This comment has been minimized.

Show comment
Hide comment
@1l0

1l0 Sep 2, 2014

Thank you for the brilliant effort!

1l0 commented Sep 2, 2014

Thank you for the brilliant effort!

@nf

This comment has been minimized.

Show comment
Hide comment
@nf

nf Sep 3, 2014

Thanks for the effort. I find that when I follow the installation instructions and run any of the examples, they just sit there apparently doing nothing. No window opens, no cpu usage. After a while I just hit ^C and they shut down.

I'm running go 1.3 on OS X 10.9.4.

nf commented Sep 3, 2014

Thanks for the effort. I find that when I follow the installation instructions and run any of the examples, they just sit there apparently doing nothing. No window opens, no cpu usage. After a while I just hit ^C and they shut down.

I'm running go 1.3 on OS X 10.9.4.

@slimsag

This comment has been minimized.

Show comment
Hide comment
@slimsag

slimsag Sep 3, 2014

Contributor

Andrew,

Thanks for reporting the issue! Sorry if it gave you any trouble. I actually already fixed the issue and made the appropriate change -- but failed to push it properly via git. If you update the gfx/window package and rebuild the examples everything should work A-Okay:

go get -u azul3d.org/gfx/window.v2

Let me know,
Stephen

Contributor

slimsag commented Sep 3, 2014

Andrew,

Thanks for reporting the issue! Sorry if it gave you any trouble. I actually already fixed the issue and made the appropriate change -- but failed to push it properly via git. If you update the gfx/window package and rebuild the examples everything should work A-Okay:

go get -u azul3d.org/gfx/window.v2

Let me know,
Stephen

@nf

This comment has been minimized.

Show comment
Hide comment
@nf

nf Sep 3, 2014

Yep, that fixed it. Thanks!

nf commented Sep 3, 2014

Yep, that fixed it. Thanks!

@peterhellberg

This comment has been minimized.

Show comment
Hide comment
@peterhellberg

peterhellberg Sep 3, 2014

馃憤 Thank you.

peterhellberg commented Sep 3, 2014

馃憤 Thank you.

@Andoryuuta

This comment has been minimized.

Show comment
Hide comment
@Andoryuuta

Andoryuuta Mar 6, 2016

This issue was moved to azul3d/engine#11

Andoryuuta commented Mar 6, 2016

This issue was moved to azul3d/engine#11

@borgellaj

This comment has been minimized.

Show comment
Hide comment
@borgellaj

borgellaj Mar 7, 2016

Was looking for a tutorial to do a basic 2d platform game is there one you could point me to?

borgellaj commented Mar 7, 2016

Was looking for a tutorial to do a basic 2d platform game is there one you could point me to?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment