Rust on Consoles #90
Comments
|
I think, for now, all we can practically do is voice these wishes / ideas on the dev forums as those are places that filter ppl by NDA agreements already. |
|
+1 on using the pre-existing first-party-sanctioned means to discuss. (Sorry for speaking with all the charm of a wet blanket! I would love to see progress here too!) Another concern is that even if every technical issue were solved the title still has to pass cert. You might need a waiver to use non-sanctioned toolchains and I’m not sure how keen first parties will be to grant that. There is still lots of space for tools and backend services for AAA. I also feel that rust has to prove itself on PC and mobile before first parties will get behind rust in a meaningful way. Maybe we should try to kick off a conversation on one of them. We may need to coordinate which one, discord private messages might be the best place for that. |
|
We could start with the platforms where the tech-approach seems promissing. Hint-hint:
The reality is that gamedev & reasearchy things don't blend well together due to the usually hellish delivery constraints that gamedevs have. So maybe a studio that loves Rust can start something more serious in this space (@repi ? 😄). But as I said, let's take this discussion to the dev forums. |
|
Rust console support has not yet been a priority for us here at Embark, been focusing on desktops (windows, Mac, Linux) first. But I think it will be later during this year so likely will do some more experiments with it, but not ship anything with it this year. We a tracking issue on our page: EmbarkStudios/rust-ecosystem#18 But yes given the nature of the consoles and the NDAs, work on them can't be done in public. But if we do start on it we would want to do it as a private github repo with the platform companies managing access |
|
I'd definitely support this, if we can figure out a way to navigate the maze of NDAs the console APIs are wrapped up in. From what I understand, getting Xbox One support should be the easiest out of all of the consoles, since they support UWP, but I haven't looked into that too much so I'm not 100% certain on that. |
|
The easiest way to get going is (probably) to just shove the whole game into a This way, each platform can have whatever platform specific top level quirks, and the game doesn't really have to know much about it. You'd pass in a few function pointers for the "services" that the game will need to have provided for it (allocator, vulkan instance, how to read a file, etc etc) and then the inside of the game can otherwise be pretty agnostic to the platform in question. It's not the most ideal perhaps, but every console SDK can doubtless link to a C static lib, so to start just make Rust pretend to be a C static lib to the outside world. |
|
Hey, with that model that @Lokathor just mentioned, what if we then created a public crate that would define the standardized interface for communicating to the console. That crate would allow you to register callbacks for the console APIs that your game needs and it would provide the The crate could be public because all it does is define a C interface for use with the console SDK and a Rust interface used to hook those C calls to your game's Rust code. Then we could, in the open, collaborate on a console agnostic API. Obviously there are console-specific APIs that you might need to interface with, so maybe those would need to be separate private crates? Anyway, at that point, behind the "NDA walls" we could develop the glue for each console that links the console SDK to our interface crate's C API. |
|
You can't quite do that with functions because the thing with the functions to call would be your own game, not some dependency of the game. However, in terms of defining a common set of input types that can be used to form the "interchange" between outer OS shell and inner game lib, that's pretty doable. (Bonus: if you have this "game as a lib" setup working you can generally hotswap the game during development with not much difficulty) |
Ah, OK. Maybe we could make a crate with the standard types, like you said, and also include macros to generate the |
|
I would suggest plain and obvious function declaration, with no macros. Don't complicate things just for the sake of it being "rusty feeling". |
|
Fair enough. |
|
As much as I am pro rust-on-consoles, discussing it here just isn't practical at this stage. I know it's anoying but proposing things here leads to strange situations where ppl who know about how console SDKs look like and are capable of can't say anything, while people who didn't sign NDAs are left to speculate without gettting any feedback if any of the sugestions are practical or not (or even if they address an actual issue). For those of us who have NDAs signed, the forums are already there to facilitate more practical next steps. So, for these reasons I am semi-tempted to suggest parking this public issue for now. |
|
That whole situation is a bummer, but unfortunately I think that's sound reasoning. It probably isn't best to discuss here. Oh, well. Their consoles their rules I guess. |
|
@AlexEne I agree, with a caveat: XBox One supports UWP, and UWP is a public API. |
|
A recent URLO thread: "Is there a reliable way to support mainstream console(including std)?" |
|
I wonder how LuaJIT got console support. I do know that its console support is 100% open-source. Is it because LuaJIT just uses essentially C standard library functions? |
|
Ideally, we'd have an organization like "RustOnThisParticularConsole", which would have all the repositories in private, would only accept members who signed the NDA, and allow these Rust community members to collaborate on the ports. Otherwise, Embark does one thing, other team does another thing, single developers re-discover all those things and probably waste a lot of time. Did anybody try to confirm with platform holders if such organization/private repos structure is acceptable? |
Is UWP an option on XBox? |
|
rust-lang/rust#88991 ("Add Nintendo Switch as tier 3 target") |
I feel like I need to find more info there. That PR is uhhh it feels kinda sketchy as hell. I think I need to have an offline conversation with them to find out what they intend haha |
|
If you follow the Zulip link it's fairly clear I think. |
I spoke to Ryan C. Gordon, the primary maintainer of SDL, which as you might know, has a Switch port in a private Github repo. I asked them how they came to that arrangement, and they said that once they'd done the work of making the port, they spoke to their developer relations contact at Nintendo and asked if the username/password for the repo could be posted on the forums. They agreed to that. Perhaps we could do something similar for adding the Switch as a target for Rust? We can also create such a repo via the nda'd forums, though we'd want to talk to them before we post any links to it in the forums. |
|
I'm slowly starting studio "Eukaryote Interactive" focused on porting rustc and needed libraries for major consoles but costs of signing NDAs are high, but first we have to discuss technical side:
About the costs... let's start from that, after signing NDAs you cannot be a part of any other company (mostly tech ones like some studio, sony, nintendo, microsoft, apple etc.). Not every devkit is free or "easy" to acquire, switch one costs ~$500, xbox requires game prototype or already finished project to be approved and PS5 requires only a company just like others. Costs of maintaining studio in my country (Poland) are ~800€/mo without office place. Here is the beginning of the real problem, signing NDAs forces to quit your job which slowly makes it even harder to maintain and that I'm currently unable to hire people in order to help with ports of compiler, at least 10 different libraries, prototype etc. which may take much longer. (thus that may require some fundings 😢). If anyone is willing to help, you cannot be employed by any tech company, possibly have own studio or I will talk to console vendors about signing NDAs with them. EDIT: I forgot to add, code related to any console cannot be hosted as private repo on any public hosting because that NDA violation in some ways. It must be hosted independently on private host without direct access for outsiders (like gitlab/gitea/sourcehut instance, perforce and plastic-scm) |
|
@heavyrain266 Is this approach an option? |
Yes, you need to wrap your game in C (tested on PS5) to sign binaries with Sony's clang and deploy to the store See this gist: https://gist.github.com/HeavyRain266/824593ae4a961f1c1cf712e1cfc1ffb7 |
What I was referring to, and what I believe @zicklag intended, is to have an abstraction layer that is independent of any particular console, and which is developed in the open. Specific implementations of this abstraction layer would be behind an NDA. |
Ohh, got it! Well thats not really possible, there is no need for abstraction layer. What you really and only need is, port of allocator, standard library and then generated bindings used to start porting Bevy Engine by creating console specific backends in libraries such as |
|
Everything you just described is the abstraction layer. |
|
@heavyrain266 alongside porting the Rust gamedev ecosystem to several consoles, I think there is value in those two approaches: First, make console-specific functionality entirely self-contained. Instead of forking This should ideally be done with every functionality, apart from Second, identify common abstractions that apply to both consoles, mobile and desktop (like "display a notification") and implement a crate that does this in a platform-agnostic way, selecting the implementation with feature flags. Again, when selecting a console implementation, people should use |
|
Now, why am I proposing this? I think that there is value in upstreaming console support into foundational crates like |
|
So far, only PS5 requires closed source fork of |
|
Oh. Well, my suggestion then is to not fork |
I think this proposal to create a stub crate just to share the api is very interesting. It would be a way to "create" closed source rust crates when necessary, as in the case of consoles. |
|
@dlight That won't work either. I see that the whole conversation is pointless because some of you don't understand what NDA is and how it works really. You cannot share interface to the code from under NDA, even as closed source crate, that still violates their rules. As I said many times, only way is to have closed source forks which can only be shared with people which signed NDA for each console separately, otherwise you can end up being sued. |
|
wgpu is, itself, an interface, so that's clearly false. Perhaps you could share the specific NDA language you're concerned about? |
|
I would suggest we keep wgpu over some platform's API X separate from a rust ready to work on a given platform. wgpu isn't a required bit, and there are pretty good reasons why wgpu may not even be the right abstraction layer. I feel like the rest of the work is way more important. |
|
Wgpu causes too many technical issues for playstation but works fine for xbox and switch (dx + vk). I will just continue working on custom renderer for Bevy and only silver, gold, platinum sponsors and people which signed publisher contract will be able to benefit from it. |
|
@heavyrain266 thanks for the clarification! But I think it's very productive to have this conversation in the open. Many game developers want to port to consoles but didn't sign an NDA yet. |
|
@dlight: What about developers who do not want to do any porting, and just want their existing (portable) code to Just Work? For instance, some game devs might not be willing or able to sign NDAs. |
|
If you won't sign a console's NDA you can't publish your game on the console. These are closed platforms, you have to play along with the rules of the platform owners or you can't get anywhere. |
|
Most publishers claims copryight for your game to release it on consoles when you cannot sign NDAs. |
On that note, any shipped title goes through a certification process. The primary blocker here isn’t technical. It’s convincing first parties that supporting Rust officially and maintaining tooling for it is worth it to them. Or potentially having a game they want on their platform badly enough to be willing to waive certain certification requirements. One exception here might be wasm - as long as the interpreter isn’t JITing and is compiled via a certified path, I expect they would not object to it. And of course tools that do not ship in the end-product. |
I’m mostly thinking of games that are open source or are run by people who have other jobs. My understanding (from this thread) is that the latter prevents one from signing an NDA, and the former makes signing an NDA risky. Even if one has all of the console-specific code in a downstream fork, there could still be legal risks. Hence the desire to be able to treat the console as a black box, hidden behind console-specific forks of libraries that are API-compatible with the open ones. That allows one to develop exclusively against an open API. |
|
While signing NDA, they expect you to not work for any tech oriented company. As part of any studio, you cannot become a partner with Sony, Microsoft and Nintendo, unless you are self-employed director which is what I do right now. Your previous workplace can be questionable for them too. Like if you worked for Sony, Apple, Google or whatever then e.g. Nintendo can then take off your license without notifying you even. |
Those sorts of games just aren't going to end up on a closed platform. If you want a completely open API then perhaps the homebrew path could be a way to get your game on a console, but there are not open routes to official game development on consoles. That's just the reality of the situation. |
Hence why I was suggesting that there might be a route where someone writes an open game against open APIs, and someone else builds it against a closed implementation of these APIs. Is there something that prevents this from working, and if so, what is it? |
Licensing (most open games are GPL/AGPL), high costs and that, if you want it to be published by someone else, you still need a company to be pointed as original developer of the game unless you will allow them to claim copyright and publish as their own product. |
|
There is a target for nintendo switch, but apparently it's for homebrew: aarch64-nintendo-switch-freestanding |
Thats first step to upstream std for homebrew. |
There is a confirmed Switch port of SDL2. I have not found any information about SDL2 for Microsoft or Sony consoles. SDL2 for the Panic Playdate is a work in progress. In theory Rust bindings to SDL2 could be used. NDAs prevent talking about specific details in public, but the Playdate is an open platform. Playdate specifics can be used as an analogy for the kinds of quirky platform details console throw at developers. For example, IIRC Playdate does not have a standard libc. It has a propriety sorta libc with things like platform specific functions for printing instead of a normal printf. Game also need to be written as an event handler and an update function instead of a standard game loop. A while back, I started a Rust thread on the official development forums of one of the major game platforms. Feel free to join in the discussion there if you are behind the NDA-wall. |
FNA (which is developed by one of the SDL2 maintainers, and has a very strict policy about keeping platform code entirely in SDL2 rather than in the framework itself) does support Xbox, and has Playstation support in development, according to https://github.com/FNA-XNA/FNA/wiki/Appendix-B:-FNA-on-Consoles. So I think it is a fairly safe bet that SDL will work on these platforms in the not-too-distant future. |
|
Maybe it is best to only interact with the OS via SDL2 if one wants to support consoles. |
|
First, you need SDL2 bindings which are not few versions behind to easly swap the source code for e.g. Switch. But then you won't be able to release your game on PS5 because of Sony's licensing which makes it impossible to legally release rust game. EDIT: Few weeks ago talked with FNA maintainer about support for consoles and they said, there are many technical issues, mostly with FAudio, they suggested to stick with Rust for my game instead. C# is even more hacky becuse you need to compile dotnet IL into C++. |
|
I'm currently working on upstream xbox support in winit, starting from gamepad support on windows. Compiler licensing team also allowed merging Xbox Series X|S as new backend in compiler unless there will be needed some NDA code to fully compile binary with some special msvc version or GDK in std etc.. |
|
If Sony makes it legally impossible to release Rust on PS5 why does that make a difference for using SDL2 on the Switch? In general, using the "system" SDL2 is pretty simple. I was able to update the |
Sony just have some special licensing which I cannot discuss here but in general other consoles don't really care about language used. |
|
Sure, I get the NDA stuff. I don't need you to discuss it. My point is that if they're going to say "no" regardless of what you do, then forget about them and focus on consoles that will work. |
|
@heavyrain266 Being intentionally vague because this is a public forum, but I suggest you search the internal site for "R5085 rust" and see the related material. |
Hi there,
I'd like to help get Rust onto Consoles more. I have two devkits from the major platform holders (I'm trying to be a little subtle here to avoid breaking any NDAs) and have signed an NDA with the third.
I have tried at work to get others onto using Rust in gamedev, but the hardstop, for the kinds of games I work in, is console support. If you've ever wondered why Godot seems to have so little traction, a lot of it is a lack of console support. Every conversation about Godot, and, unfortunately, Rust, starts with "wow I love this" and ends with "pity I can't easily get it to run on consoles."
I think we would all agree, however, that Rust is excellent for gamedev, and it would be great to code less in C++. However, to even get to that point, we need to build some infrastructure. I think this would be in the purview of the WG and would love to discuss that with some of you. I imagine this would take the form of a private repository managed by the WG which requires an invite, predicated on demonstration of an NDA signed, to join. I would be very willing to help with that. It would be easier to talk about this over voice and in a less written way of course.
Getting that infrastructure down first allows us to tackle the actual code issues necessary for console support.
Let me know what you guys things
The text was updated successfully, but these errors were encountered: