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. |
|
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. |
|
Where is the rust console support now? Are things moving? I couldn't find any public information on what happened in the meantime. |
|
I don’t think there will ever be public support for Rust on consoles, except for Steam Deck (which really is just Linux), XBox UWP (apparently discontinued?), and homebrew. Some manufacturers might not allow the use of Rust unless it is compiled via C or C++, in which case one would need a Rust ⇒ C/C++ compiler. Otherwise binding to SDL2 or another public library with a console port would be the best option. |
|
Not sure what you mean with "public" in this case. I'm this thread there was talk about creating closed source libs, that enable Devs with dev kits for specific platforms to build rust for that platform. Have there been such advances? |
|
I’m not sure what you mean, to be honest. By the nature of how console NDAs work you wouldn’t really see that work anywhere except the console forum. I think what you’re asking is: “if I made a rust game is there a path to consoles”… and the answer to that is “yes with lots of work”. The compiler supports the architecture of every major console, std isn’t that hard to port if you use it, your main hurdle is some licensing restrictions that one of the console manufacturers has in place, but everything is negotiable (if they want your game they’ll bend the rule). |
I thought that one could publicly say “We ported ABC to console XYZ and it has the same API as the open source version” without violating any NDAs. At the very least, I have seen such an announcement for SDL2. Obviously the content of the port would be under NDA, but I didn’t expect its existence to be under NDA.
Is there anything more that can be done in public, or should this issue just be closed? |
|
This issue can basically just be closed. There's no progress it can make. |
What I'm actually asking is this: if I had access to the respective console forum, will there be things that other people have shared, that make it a reasonable amount of work to port rust to that console. |
|
The purpose of a console's development forum is that everyone there has signed the NDA, and they can all discuss with each other. You aren't supposed to really take specific info outside the NDA wall, of course. That's the purpose of the forum. But like was already said, there was a public announcement a while back that SDL2 can work on consoles, and Rust can bind to SDL2. |
|
Thanks for your answers 🙏 What I'm getting from that, is that Rust can be compiled for the cpu architecture+os of the major consoles and there are SDL2 bindings, which enable interaction with all the hardware from the consoles. So if you were rolling your own game engine just on SDL2, then you could, with individual effort per console, build for consoles. What about Godot 4? There are rust bindings for Godot. Godot can now be ported to consoles. Rust can be compiled for consoles... @rrohrer what did you mean with "porting std"? Why would the rust std lib need porting if rust can be compiled for that arch+os? (Sorry for the simple question) |
|
I once has a dev describe their particular process to me. Essentially they compiled for the no_std target flavor of the arch to get |
|
So from what I could find online the ps5 runs on a x86_64 CPU and os based on freebsd 11 the Xbox series X/S run on x86_64 and os based on windows nt the switch runs on armv8-a and very custom os based on android/freebsd Now, I did not find the armv8-a target in the the rustc docs, but from what i could find, the armv8-r target could work. From that perspective the switch seems to be the hardest to target, since, as you said, the std lib can't be used and a That might also be true for the others depending on the details of the OS. But it's not that bad not to use std, since there is the corelib which basically contains everything from std except plattform related code, i.e. file I/O, text I/O, os, processes, environment, threads, collections and stings (because of allocation) and collections (and strings?) can then be added manually as described in the link above. Very interesting. Thank you for elaborating. |
|
Please Note: you likely wouldn't actually write your own allocator at all. You'd just write a GlobalAlloc impl that calls either the system allocator, or even you could call the SDL allocator and let it call the system allocator for you. https://doc.rust-lang.org/alloc/alloc/trait.GlobalAlloc.html This would be like 10-20 lines of code probably, it would hardly be any time compared to the other steps you'd be doing. |
and others
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: