Remove CGO requirement from OSX builds

[200sc]

No description provided.

[gedw99]

Have you considered gioui ?

https://gioui.org/

It uses shiny but the rendering engine is very advanced on comparison .

There is even a working p5 package for gio.

it seems a perfect match for oak

perf will be much higher than our current platform

compiles for web, desktop and mobile

building a 2d game on top of gio is something others are also doing .

You can also mix 2d and 3d . Seem their examples .

and you get highly quality forms / widgets for data entry etc

oak has all the higher level stuff already done . I found this repo because of the gamepad as I wanted to hook up gio to a gamepad btw :)

[200sc]

Oak's drivers are extensible-- a gio driver is probably feasible to write. I don't know anything about comparable performance, but I'll take a shot at it. It will probably take me a bit of time, as even cloning gio's repository down to look at the code is apparently not straightforward (fails with Bad file descriptor, index-pack failed), but I'm trying some workarounds.

As far as this issue goes, it wouldn't remove the cgo dependency (https://git.sr.ht/~eliasnaur/gio/tree/main/item/internal/cocoainit/cocoa_darwin.go), but I'm not sure if the dependency is possible to remove.

[gedw99]

Weird that your got a problem with git cloning.. Never had it myself.
I normally work off github not sourcehut. So maybe thats why.

your right. there is be some CGO at the bottom. It's impossible to remove as at some point to bring up a canvas you have to call the Native OS level.
If you compile to web, there is no CGO of course.

In terms of perf, i can point point you to some similar 2D drawing apps:
here is the p5 gio lib btw: https://github.com/go-p5/p5. Might be interesting for you.

https://github.com/ajstarks/deck

https://github.com/ajstarks/giocanvas

Not sure if its your thing, but i would start with this example to get going: https://github.com/gioui/gio-example/blob/main/component/main.go
It shows a good way to lay things out, and has a polished GUI. Its fast perf .
Compiling this to Web, Desktop and Mobile shows how well the framework performs on all these operating systems.

there is a video component, RTL / LTR with multi language support happening too in the PR's so you will get those for your game if you want them eventually.

[200sc]

@gedw99
I took a shot at integrating the two libraries: https://github.com/oakmound/giodriver
To me, they seem at odds with each other. You can't easily tell gio that a screen element is going to be constantly updating, and if you manage to do this, the screen constantly flickers.

And your description seems like you'd want to have both oak and gio components in your rendering logic, which is also a bad match-- gio components are immediate-mode, and oak components are retained-mode. It's going to be tricky to actualize that.

But maybe there's something there for someone!

[200sc]

Another approach -- you could build a render.Stackable out of a gio layout / graphics context object. But this would not have any performance or platform portability elements from gio.

[gedw99]

@200sc

wow that is great to see. Good old pong game too :)

I could not work out how to run this as there is no main package. But anyway to address the other things...

The flickering is odd. Never had that myself with GIo apps. I suspect its because its mixing the gio immediate mode with the oak retained mode.

About updating a screen element.. You only do it in the Render loop. Everything is an Op.
Because its a Render loop, any other work must be done in a goroutine. So you end up with a backend and frontend in the same app. Quite a bit like how in web apps with Service workers, where the service works is a Proxy / backend, and the Window is he frontend, with message passing between them. This is an analogy, I dont mean that true message passing is needed. I know this is harder than retained mode thinking.

render.Stackable sounds doable but as you say, you would not have the Portability, Perf.

I suspect in order to use Oak with GIO, you would need to go "all in" on Immediate mode and GIO. It would be a full port.

Here is a game in gio that also has a server with websockets. It is a good reference point perhaps.

https://git.sr.ht/~whereswaldon/pointstar

• its old but still works
• uses the golang websocket lib that works with wasm and native.
• very simple code. with golang on backend and frontend coordinating state between the backend and frontend gets trivial.

[gedw99]

also have a look at the examples here: https://github.com/gioverse/chat/tree/main/example

this repo is where alot of the challenges of binding to data and async aspects is shown.

[200sc]

I've looked at enough examples for my liking at this time, but thank you. All of this seems to come from a perspective of understanding how gio works but not understanding how oak works-- for example, you can use oak's joystick library without using any other component of oak. If that's all you want, you're already there. Its my understanding that gio is not intended to work with applications that need to readily update everything on screen-- it can work with things that update individual components at predictable times, but the architecture assumes that things are not changing instead of assuming that they are changing. This is great for a lot of purposes, but not for most video games, where entities are actively changing. pointstar looks like a board game, which sounds like a good fit.

This is all to say I do not think this discussed integration will work. Its possible it will, and others (you, even!) can take on the task of learning gio and oak well enough to write an integration of the two that suits your needs, but to me it:

1. doesn't look like it would produce high-fps games
2. would use immediate mode graphics, which I think is fundamentally incompatible with most games
3. would take >10 hours of work

So I'm not motivated to spend who knows how much time on an integration that, at the planning stages, looks dead in the water. If you believe you can make it work, just like the joystick package, all of oak's packages are designed to be usable without oak itself running; you can use any of them by themselves in your integration. If you want advice on how things in oak work to build this integration, you're welcome to ask questions.

I'm not going to respond to further comments that seem to me like they are attempting to convince me to put more time into coding this myself.

[gedw99]

I did not realise you thought I expected you to code it yourself.

On Tue 30. Nov 2021 at 14:38, Patrick Stephen ***@***.***> wrote: I've looked at enough examples for my liking at this time, but thank you. All of this seems to come from a perspective of understanding how gio works but not understanding how oak works-- for example, you can use oak's joystick library without using any other component of oak. If that's all you want, you're already there. Its my understanding that gio is not intended to work with applications that need to readily update everything on screen-- it can work with things that update individual components at predictable times, but the architecture assumes that things are not changing instead of assuming that they are changing. This is great for a lot of purposes, but not for most video games, where entities are actively changing. pointstar looks like a board game, which sounds like a good fit. This is all to say I do not think this discussed integration will work. Its possible it will, and others (you, even!) can take on the task of learning gio and oak well enough to write an integration of the two that suits your needs, but to me it: 1. doesn't look like it would produce high-fps games 2. would use immediate mode graphics, which I think is fundamentally incompatible with most games 3. would take >10 hours of work So I'm not motivated to spend who knows how much time on an integration that, at the planning stages, looks dead in the water. If you believe you can make it work, just like the joystick package, all of oak's packages are designed to be usable without oak itself running; you can use any of them by themselves in your integration. If you want advice on how things in oak work to build this integration, you're welcome to ask questions. I'm not going to respond to further comments that seem to me like they are attempting to convince me to put more time into coding this myself. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#175 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMVPLFDJJG27IESVGDTCTDTUOTHVXANCNFSM5HBNVBVQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

--

[gedw99]

@200sc

I've looked at enough examples for my liking at this time, but thank you. All of this seems to come from a perspective of understanding how gio works but not understanding how oak works-- for example, you can use oak's joystick library without using any other component of oak. If that's all you want, you're already there. Its my understanding that gio is not intended to work with applications that need to readily update everything on screen-- it can work with things that update individual components at predictable times, but the architecture assumes that things are not changing instead of assuming that they are changing. This is great for a lot of purposes, but not for most video games, where entities are actively changing. pointstar looks like a board game, which sounds like a good fit.

good points. I appreciate the feedback.

This is all to say I do not think this discussed integration will work. Its possible it will, and others (you, even!) can take on the task of learning gio and oak well enough to write an integration of the two that suits your needs, but to me it:

1. doesn't look like it would produce high-fps games
2. would use immediate mode graphics, which I think is fundamentally incompatible with most games
3. would take >10 hours of work

So I'm not motivated to spend who knows how much time on an integration that, at the planning stages, looks dead in the water. If you believe you can make it work, just like the joystick package, all of oak's packages are designed to be usable without oak itself running; you can use any of them by themselves in your integration. If you want advice on how things in oak work to build this integration, you're welcome to ask questions.

I will see if i can get something working. I am currently working with rendering dynamic content on gio and it might be possible to shoe horn oak with gio. But yes i agree the problem is the dynamic nature.

I'm not going to respond to further comments that seem to me like they are attempting to convince me to put more time into coding this myself.

[prologic]

I'm curious... What's the C dependency that's currently used or pulled in on macOS? 🤔

[200sc]

It's going to be under mtldriver's internal directories + the dependencies for metal within the mtldriver

[prologic]

It's going to be under mtldriver's internal directories + the dependencies for metal within the mtldriver

Thanks!