I found a solution to the CEF x86_64 requirement problem on macintosh computers.

First a little background:

Garrysmod’s built in browser is very outdated, ridiculously so. It was proposed a while back that garrysmod switch to using Chromium Embedded Framework (from here on CEF) however this was turned down by the lead developer of garrysmod due to the fact that it would require the porting of Garrysmod to 64bit on Macintosh computers because CEF only supports x86_64 on mac OSX which would require rewriting a good portion of the engine’s code. The switch is necessary in order to support the majority of HTML5.

Now here is my solution,
I had an idea inspired a little by the way the graphics and performance optimization mod for several popular games known as ENB handles very large textures and data in 32bit games. ENB boosts the effective memory the games have for high resolution textures and gamedata by offloading the texture and data storage to a secondary 64bit application that gets launched at game start and exits when the game closes. My idea to solve the problem with Garrysmod using CEF on mac OSX is to use a helper executable that is 64bit which contains CEF and handles all the rendering of web pages and then passes the textures either through some sort of gpu texture sharing or via memory sharing or some other mechanism to transfer the textures between executables, and garrysmod would pipe the necessary control input into this helper executable to allow interaction with the web pages being rendered. This should not be too much harder than simply switching to CEF without such a system.

Anyways thanks for your time guys I hope this helps move things along.

The problem is executing on a 32-bit Mac. Since CEF is 64-bit only for Macs, it would be leaving out (albeit a small) fraction of users. Emulation would be an option (on a software level), but a very slow one at that. Considering this you understand why the idea of running a 64-bit helper executable faces the same problem as CEF does for integration.

A final point would be that although the engine is written for 32-bit processors, it’s not impossible for it to interact with a 64-bit program.

  • snip -

Apple hasn’t made 32bit macs for a long time and the latest versions of mac OSX don’t even support 32bit macs iirc, even if you still want to support 32bit you could still use a second helper executable that gets dropped in that uses awsomium if 64bit isn’t supported by your cpu.

Too much hassle. Even to change from one to the other requires a lot of work I hear. You’d get more input from the devs in the next update thread, I’d give that a shot.

Wowie, it’s almost like that’s how it works already…

My only concern is that there could be some overhead of doing it this way, CEF probably isn’t designed to be used this way, and both supporting a more direct CEF interface and/or an awesomium fallback could be really difficult to maintain.

My question is WHY is CEF not supported on 32 bit OSX? Is there some underlying hardware/software/API issue that makes it difficult, or is it just a matter of there not being much demand for it?

Obviously chromium is a giant ball of code that takes ages to compile, so we probably wouldn’t want to be making any changes to the browser itself, just to get it working under OSX.

That’s not how it works now, blink, the chrome,CEF and awesomium renderer has it’s own helper executable that is used for rendering, the main browser code is still running in the gmod process. That thing you screenshotted is an example of blink’s helper executable for rendering, not a helper executable running the main browser code.

What about animations and interactivity, though? Awesomnium isn’t only used in the loading screen but also in UI (like the menu and Derma UI, etc.). You’d have to implement a way to check for clicks, key presses, events and make sure that animations and interactions are running at ~60 fps, otherwise you’re just creating a bottleneck for a single platform.

Your solution would work for what it does already, but not for browser rendering as how I see it.

Can someone find some statistics on how many people actually use/play Garry’s Mod on these Macs? Surely you could just get away with adding CEF if a tiny portion of players use these Macs.

Someone posted the statistic a few weeks ago, like 0.5% of Garry’s Mod players. I don’t believe you understand this from a business standpoint. Garry can’t make a game that users buy and then a little bit later be like “fuck you” and break the game for some users, no matter how small that is. There is definitely something in Steam’s terms not allowing games to do this and it overall just makes your game look bad.

There won’t be CEF in GMod. Move on to making your own game in UE4.

I get what you’re saying, but that absolutely happened when gmod13 came out, how was that any different?

Just a heads up, CEF already uses a pretty decent amount of IPC and I don’t even want to think about the level of clusterfuck you would have to go through to get this to work.

Hell, I have yet to figure out why my implementation is crashing so much and I’m not attempting anything like this.

It was different because the game still worked on everyone’s computers… The only thing that broke from Gmod 12 to 13 was addons.