OFFICIAL Would you support a 64bit runner for Linux?

Would you support a 64bit runner for Linux instead of the current 32bit one?

  • Yes

    Votes: 49 90.7%
  • No

    Votes: 5 9.3%

  • Total voters
    54
L

Lee Chisholm

Guest
Linux users,

Would you support a 64bit runner for Linux instead of the current 32bit one?

We're interested to know here at YoYo Games so if you have any concerns or thoughts, please share them below.

- Lee
 

Eisenhans

Member
Linux users,

Would you support a 64bit runner for Linux instead of the current 32bit one?
Yes, absolutely.
1. Default 64bit Linux distros don't run 32bit apps out of the box. And make them do it by installing a full 32bit lib set is only a crutch, at best. Players will (legitimately) dislike this.
2. Native 32bit distro versions have been declining for years now (most maintainers have had them for legacy purposes only, anyway), and popular distros like Ubuntu, Arch etc. are or already have phased them out.

A 64bit Linux runner is absolutely necessary, if you want to keep that platform as an export option (which I most sincerely hope).
 

rIKmAN

Member
I would eventually, but priority wise I would put it behind a lot of the existing bugs and planned features on the roadmap (unless it's a simple task that doesn't take much time).

YYG are always stating how understaffed and short of manpower they are, so to dedicate some of this already thin time to something that is such a small market share above bugs and features for other targets that have a much bigger userbase seems illogical.

I have been trying to get Spine support improved / updated for a long time now, but I guess because not many GMS users use Spine that it's low priority, and I would assume the Linux target is in a similar position.
 

FrostyCat

Redemption Seeker
I agree with moving the runner to 64-bit, but not before getting to work on the long-standing issue with poor support for extensions and integrations.

It has been over a year since I made that post, and to date nothing has changed. People are still having issues with outdated/undocumented Facebook and IAP extensions, and built-in integrations like Spine are still regularly out-of-date. This is not a sign that GMS 2 is ready for expansion.

My suggestions:
  • Outsource the official plugins to community developers. There is clearly no capacity or will to do upkeep for those in-house. Set up a bounty system, put them on GitHub, hire some freelancers.
  • Outsource future integration efforts to third-party vendors by offering them free copies of GM. This allows interested vendors to start integrating their products without an upfront cost, an edge that Unity has exploited for years. It's work that you no longer have to do, and the vendors will be watching the changes --- something that YoYo has been doing poorly for ages.
  • Invest in extension documentation. Show people where to get at the main canvas, surfaces, the audio stream, buffers, data structures, system-level hooks, extension-specific events, etc. This allows users and vendors to become more self-sufficient and improves future-proofing (since they no longer need to reverse-engineer and end up hooking into parts of the runner not intended to be publicly stable).
  • Invest in WebSockets and HTTP+HTTPS functions. These are the main avenues for cross-platform integrations with online APIs, and topics like this and this demonstrate how inadequately the current implementation is done.

You've just announced an active partnership with Microsoft on the UWP export, now you're thinking about about a potential revamp of the Ubuntu export. A significant number of staff will be pulled away from upkeep for this expansion. If you don't act to minimize the number of things that you have to support in-house at the engine level, you risk neglecting more important and widespread use cases just to satisfy a PR exercise.
 

Mike

nobody important
GMC Elder
Just to clarify, compiling for 64bit is not a major task - we already build 64 bit for consoles, and have a windows 64bit internally. So this really is just about swapping the runtime over.

To me it's more important than most other things right now as the default download for Linux is now 64bit - and has been for a while. This means if you even want a user to run your game, they have to manually install a stack of things. This is horrible. So for such a small change, it's one we really want to make. if it were having to spend weeks or months changing and updating things, then I'd totally agree.

Also, because we're not talking about having both 32 and 64bit (like we would need with Windows) there is again no additional IDE or compiling work needed - it's just building for 64bit.


As to plugins. We've already been talking internally about open sourcing some of them, but have yet to decide, but it's defiantly on the table. There are some issues we thing we need to resolve first however.
We're already getting vendors to do their own integrations now (as shown by the new Game Analytics plugin https://marketplace.yoyogames.com/assets/5179/gameanalytics )

(audio streams, surfaces etc) Not all these things are available to extensions yet, and the runner needs pretty major work cross platform to allow it. Because users can do this themselves (create their own textures, surfaces etc) this is not something that is currently high on our list.

Web Sockets is definitely high on my list, but not something we can currently do just yet, we've too many other things going on - some of which will become clear soon I hope. HTTP and HTTPS is implemented across everything though?
 

FrostyCat

Redemption Seeker
As to plugins. We've already been talking internally about open sourcing some of them, but have yet to decide, but it's defiantly on the table. There are some issues we thing we need to resolve first however.
We're already getting vendors to do their own integrations now (as shown by the new Game Analytics plugin https://marketplace.yoyogames.com/assets/5179/gameanalytics )
OK, good to know.

(audio streams, surfaces etc) Not all these things are available to extensions yet, and the runner needs pretty major work cross platform to allow it. Because users can do this themselves (create their own textures, surfaces etc) this is not something that is currently high on our list.
It should be higher if you want GMS 2 to stop falling so far behind with Spine, staying put with non-HD raster graphics alone and continue having trouble with standard video formats. Many video, audio and image formats and tasks related to them are best integrated with native libraries, since GML often isn't fast enough due to dynamic type overhead and lack of threading (not to mention reinventing the wheel). There have been recurrent topics about how pixel graphics are over-represented in GM games, and my response to it was that GM has inadequate support for non-raster and HD raster graphics.

HTTP and HTTPS is implemented across everything though?
It is implemented everywhere, but not completely nor well. Look up http_request() on Mantis for the outstanding bugs. Several of them can shut down a third-party REST API integration. And there is still no documented way to download a binary file with additional authentication headers in the request.
 

Mike

nobody important
GMC Elder
Extensions can render things directly themselves, so if you need super high performance (dynamic or custom usage), then you can easily write your own rendering system.

Spine update is high on our list, we can't can't manage it right now - again, hope folk will see why soon enough.

k - I've not used the HTTPS myself so can't comment directly on issues with the current system.
 

zbox

Member
GMC Elder
OK, good to know.
It is implemented everywhere, but not completely nor well. Look up http_request() on Mantis for the outstanding bugs. Several of them can shut down a third-party REST API integration. And there is still no documented way to download a binary file with additional authentication headers in the request.
Sounds dangerous... I just searched on mantis, cant find. Mind linking?
 

FrostyCat

Redemption Seeker
@rIKmAN: Exactly, that's what I'm getting as well.

For everyone's information, here's a breakdown of the bugs regarding their effect on REST API integrations:
  • 0027632: Total breaker if unresolved. You can't mess with the verb on a REST request, period.
  • 0027116: Major breaker if unresolved, total breaker if http_request() is also affected. You can't mess with the body of a request if we specify one. And ignoring the response upon a non-200 is non-standard smart-alec behaviour.
  • 0026219: Total breaker if not closed. Description says it all.
  • 0027098: Breaker on older systems only. This has to do with the phone not supporting the cryptography used by the server's HTTPS implementation.
  • 0027099: No effect on standards-compliant servers.
  • 0026867: Can't replicate. The file has gone offline and json_decode() works correctly with the JSON provided here. Likely user error.
  • 0024827: Total breaker. Authentication-related headers come back through the request header, you can't just throw them out because you think we won't be needing them. With XMLHttpRequest.getAllResponseHeaders(), there's no reason not to get them all.
  • 0023078: User error.
  • 0021764: Total breaker, but on a platform with no market value.
  • 0019592: Significant breaker. It will throw off most current integrations, but it can be worked around by checking async_load[? "http_status"].
The developer responsible for the HTTP integration really needs to get in touch with affected users like Adam Coster and I. It almost seems that he/she is only testing with trivial cases and has no idea about what's going on in the wild.
 

Mike

nobody important
GMC Elder
Of the open (still to fix ones), the only one there that needs looking at sooner rather than later is the 0024827. Little worried this had "no" priority to it, as they should all have some. Have now bumped and reassigned.

0021764 - yeah... now a dead platform.....
 

rIKmAN

Member
Spine update is high on our list, we can't can't manage it right now - again, hope folk will see why soon enough.
Is that an integrated update or the breaking out to an extension Russell mentioned was the overall plan?

re: Linux - if it's not a big job and is simple to implement and swap runtimes then I don't really see the point in asking the question to the community. It's sounds like it's needed, is already high on your todo list and will be a pretty quick task so might as well just do it. :)
 

Mike

nobody important
GMC Elder
We've yet to decide. Part of the task is seeing how much work it'll be to break it out.

The reason we ask is for extensions. If we swap over without asking, then we'll break any games that use native extensions. These will have to be recompiled. This is pretty much the only reason...
But as I've said before, the current consumer downloads are all 64bit now, and that means we break for anyone trying to run a game, and that (for me) puts it at a higher priority than recompiling an extension (if you use any at all).
 

FrostyCat

Redemption Seeker
The reason we ask is for extensions. If we swap over without asking, then we'll break any games that use native extensions. These will have to be recompiled. This is pretty much the only reason...
Swapping over without asking isn't really problematic, swapping over without announcing is actually problematic.

If the extension authors have even half a finger in Linux development, they should already be aware of the 64-bit problem. The key is reaching out to them proactively, documenting the differences, giving them sufficient headway and releasing a final stable version of the 32-bit runner as fallback. There isn't a huge market for native Ubuntu extensions, so the number of affected products should be reasonably small and manageable.

Given that the runner migration isn't a major task on the technical front, I'd say just press on with it. The vote is already turning out rather one-sided, and the general market for Ubuntu apps demands this migration sooner than later.
 

Mike

nobody important
GMC Elder
Given that the runner migration isn't a major task on the technical front, I'd say just press on with it. The vote is already turning out rather one-sided, and the general market for Ubuntu apps demands this migration sooner than later.
Yeah it is... and it looks like we will. But we simply didn't know this would be the case, so we had to ask. :)
 

Fern

Member
I've had a number of customers with Linux distros complain about the lack of 64-bit Ubuntu support. I've also had Steam step in and flat out remove the "Ubuntu Supported" tag from my Steam page due to the lack of a 64-bit runner. SteamOS is 64bit as are most modern OS's. I find it very disappointing that we still don't have 64-bit exports for Windows/Ubuntu/Mac. Mobile platforms I can understand the lack of it as those games tend to be shorter on memory usage regardless.

Above all else I feel the constant pressure of memory usage while working on games in GM and it really does cut down the scope of GM projects to be limited to 3.4GB or whatever the current limit is before things begin crashing randomly. I'd love it if I didn't need to load/unload audio/images just to avoid GMs memory constraints.
 
S

Sam (Deleted User)

Guest
I kinda assumed this, but it would help having some clarification. If you guys added support for a 64 bit runner, would I then need to build a 64-bit version of my Linux extensions (*.so libraries)? In other words, does it apply to Windows, Mac, and Linux - or - would I only need to do that with Windows DLL's?

Also, is this 64-bit runner going to replace the 32-bit one? Or are we going to be given the option of which one we compile with? (really hoping the latter...)

Edit:

Ok so after reading further in this topic apparently you guys are replacing the 32-bit runner for Linux.

Will GMS 1.4 get this new Linux runner? Or just GMS 2? A lot of my older projects don't work in GMS 2 due to bugs, which is why I ask. Apparently supporting 64-bit on Linux is a lot more important than I originally thought.
 
Last edited by a moderator:

Mike

nobody important
GMC Elder
yes, you will need to do GMS2 Linux versions that are 64bit - GMS1.x will remain 32bit. Mac will have both 32 and 64bit, I'm not sure about extensions for both - I'll check tomorrow.

Windows remains 32bit for the time being.

Linux will be only 64bit in GMS2. Mac will likely be both (packages can contain both exes), windows (when it comes) will have an option.
 
S

Sam (Deleted User)

Guest
@Mike thanks for letting me know and I look forward to hearing about extensions so I can prepare things for this change. Thanks again!
 
S

Sam (Deleted User)

Guest
okay - so apparently going forward the Mac one will by a .dylib that contains both architectures, and that will work fine.
Alright, so that answers my question concerning Mac - did you find out yet how it works on Linux?
 

Mike

nobody important
GMC Elder
With them all being 64bit anyway, we're not fussed about even looking - especially with the 5 people that'll use it :(
 
S

Sam (Deleted User)

Guest
If it's too big a task to be worth a check I feel like you could've worded that a little nicer. But it's ok, understood. (Maybe I'm just reading in an exaggerated tone).
 
G

grixm

Guest
Yes, please please. I've been waiting for 64-bit support for a long time and on Linux it's the most pressing for me.

It would actually eliminate the need for a separate Linux system for development, as you could use Windows Subsystem for Linux. I tried compiling with this locally once, and after installing a few packages it worked. But I never got to run it because guess what: One thing WSL does not support is executing 32-bit binaries.
 
S

Sam (Deleted User)

Guest
Ok, so apparently after some googling, when you try to call a 32-bit *.so library on Linux from an application, you can't do it if the application is 64-bit. The library and the application need to be the same bits. So for those of you who want to make Linux extensions for GMS 1.4, make sure your *.so library is built for 32-bit. Once they release the update to GMS 2 that includes the new 64-bit Linux runner, everyone will need to create a separate version for GMS 2 of your *.so library that is built for 64-bit. I think YoYo should mention this in the release notes when they release that new 64-bit Linux runner for GMS 2.

The only reason I asked Mike instead of googling it initially is for some reason I had the impression from a previous conversion that the whole "the dll and exe need to be the same bits on all platforms" was a GMStudio specific, potential requirement. But anyway I was wrong, I confirm that is in fact how it works with all software after some searching. :)

(I think whenever the new 64-bit Linux runner is released, someone should let everyone know in this topic).
 
O

Onigiri

Guest
Regarding the 64bit linux runner.. Would it be possible to modernize it a bit? Some of the dependencies date back to antiquity (libssl 1.0 etc) and are insecure and hard to come by on modern distros, that means that releases have to carry around a hawker's tray full of libs and LD_PRELOAD them.
 
T

TacticalCannonFodder

Guest
It's not clear on this thread... is the Mac 64bit runner out yet or still a bump in the roadmap?
 
G

grixm

Guest
Brilliant!

Is there any ETA on when windows will get 64-bit too? Or is that not planned quite yet?
 

Mike

nobody important
GMC Elder
That will take more work ad that will need to be an option, not just switch wholesale. There are still way too many 32bit windows systems out there to throw it away altogether.

However... if you really absolutely NEED 64bit windows, then the UWP module does allow both x86 and x64, so you could do that....
 

rwkay

GameMaker Staff
GameMaker Dev.
I have checked our Runner and we are not linking to a specific libssl version and we are using the libssl-dev for Ubuntu 16.04 (which our build machine is on) and that is currently set to (see https://packages.ubuntu.com/xenial/libssl-dev) I am not exactly sure what the problem is that you are talking about...

Can you point me at any online discussion of the problem that you are outlining???

Russell
 
O

Onigiri

Guest
Can you point me at any online discussion of the problem that you are outlining???
(I assume you are referring to my comment above)
Thanks for looking into this!
If the old libssl.so.1.0.0 is not present on the system executing the launcher, but only a current libssl, you get the following error:
"relocation error: libcurl.so.4: symbol SSLv3_client_method, version OPENSSL_1.0.0 not defined in file libssl.so.1.0.0 with link time reference"

On a different note: it would be worth a discussion if games that do not use any networking should have any network related dependencies in the first place. Right now it seems the runner is asking for all dependencies that cover any possible use case of its capabilities whether or not the actual executable needs them. This is a bit like permissions on mobile. Don't need them: don't ask for them.
 

Mike

nobody important
GMC Elder
On a different note: it would be worth a discussion if games that do not use any networking should have any network related dependencies in the first place. Right now it seems the runner is asking for all dependencies that cover any possible use case of its capabilities whether or not the actual executable needs them. This is a bit like permissions on mobile. Don't need them: don't ask for them.
This is not going to change. This would require dynamic linking, or dropping of sections of the runner if not in use. It's simply not written like this, and won't be changing any time soon.
 

Bruchpilot

Member
Just had a stab at the new 64bit linux runner. My prototype, which has about 1000 onscreen instances (real instances, not just drawn sprites) runs at about ~4000fps on a 2.5 year old PC.
Not too shabby.
 
S

Sam (Deleted User)

Guest
Just had a stab at the new 64bit linux runner. My prototype, which has about 1000 onscreen instances (real instances, not just drawn sprites) runs at about ~4000fps on a 2.5 year old PC.
Not too shabby.
Nice! I didn't know they released it yet. Super excited to try it out once I'm home again, (currently on vacation).
 
Top