3 ms·

> Any idea why Godot does not do consoles? Console SDK seems to be not compatible with open source https://docs.godotengine.org/en/3.0/tutorials/platform/cons

> Any idea why Godot does not do consoles? Console SDK seems to be not compatible with open source https://docs.godotengine.org/en/3.0/tutorials/platform/consoles.html https://docs.godotengine.org/en/3.0/tutorials/platform/conso...

e12e 5y ago
For those interested in Godot, but wanting console support - heaps might be of interest: https://heaps.io/ https://heaps.io/ It is another, smaller engine. I would say less featureful than Godot, but I imagine there are some overlapping use-cases? Ed: and for something quite different - dragon ruby seems a lot of fun (not free, not open source, though): https://dragonruby.org/ https://dragonruby.org/
- follower 5y ago
  I was curious how Heaps.io could be an Open Source project while also supporting consoles (PlayStation, XBox, Switch) so researched it a bit. The key aspect seems to be that there's a commercial entity behind the project who presumably has console development licenses. AFAICT none of the console specific source is Open Source but the implication seems to be that the source is (freely?) made available to registered console developers due to the fact the developer of both is a licensed console developer and has decided to make it available to others. Console development/distribution is mentioned in a couple of places in the documentation[0]: "The hello.hl file contains bytecode that can be run with the HashLink virtual machine using hl hello.hl. It does give quite good performances and have been proven by successful commercial games such as Northgard or Dead Cells. However, it is also possible to compile the HashLink code using a native compiler. This allows to compile for consoles and mobile. This will create a directory out containing a lot of generated C code that needs to be built using a native compiler and linked to the same HashLink runtime[...]" With regard to console support it says: "... for Consoles (Nintendo Switch, Sony PS4, Microsoft XBoxOne), please contact us at nicolas @ haxe.org if you are a registered developer for one or several of these" And here[1]: "The final resulting shader will then be compiled to the target platform native shader language (HXSL currently supports GLSL for OpenGL, HLSL for DirectX 11+, AGAL for AdobeAir, and PSSL for Sony PS4)." Also, this post[2] describes how the lower level parts (using Haxe/hashlink) integrate with native (i.e. console) platforms: "The game gets compiled to a cross-platform .hl file that can be run with HashLinkVM JIT. It can also be compiled to C directly and compiled using any native compiler, which we are using for our console ports on PlayStation, Xbox and Nintendo Switch." "We also have additional platform API libraries for Steam, as well as console integration libraries that are only accessible if you have a registered developer." In the same post the Heaps.io console implementation is described: "This architecture allows us to integrate new renderers or platforms by just porting a few classes given that the native libraries are been made available in HashLink. Heaps.io supports the following plaforms/renderer: [...] HashLink/C with NVN (Nintendo Switch SDK native graphics API) HashLink/C with GNM (PS4 SDK native graphics API) HashLink/C for Xbox One SDK" [0] https://heaps.io/documentation/hello-hashlink.html https://heaps.io/documentation/hello-hashlink.html [1] https://heaps.io/documentation/hxsl.html https://heaps.io/documentation/hxsl.html [2] https://haxe.org/blog/shirogames-stack/ https://haxe.org/blog/shirogames-stack/
  - follower 5y ago
    Some other details from spelunking the code base... The exposed console functionality interface can be found via `hl_console`, `usesys` & `usegl` references: * https://github.com/HaxeFoundation/hashlink/search?q=hl_console&type=code https://github.com/HaxeFoundation/hashlink/search?q=hl_conso... * https://github.com/HeapsIO/heaps/search?q=usesys&type=code https://github.com/HeapsIO/heaps/search?q=usesys&type=code * https://github.com/HeapsIO/heaps/search?q=usegl&type=code https://github.com/HeapsIO/heaps/search?q=usegl&type=code The "interesting" pieces are all in some other codebase, e.g.: * https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf0ed66b47d20d380fe95bc1bc3ec0/src/hlc_main.c#L42 https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... * https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf0ed66b47d20d380fe95bc1bc3ec0/libs/sdl/gl.c#L19 https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... And, if you're a weirdo like me that likes trawling for small console development details (e.g. they treated as ~BSD system) in the code base check out these: * https://github.com/HeapsIO/heaps/pull/491 https://github.com/HeapsIO/heaps/pull/491 (fixes for Nintendo "NVN") * https://github.com/HaxeFoundation/hashlink/commit/7af111a38f99f6e18d8b30cd8edadd24e0d6803e https://github.com/HaxeFoundation/hashlink/commit/7af111a38f... (PlayStation related naming becomes generic "console" naming) * https://github.com/HeapsIO/heaps/commit/0daba3517a7193566cd01d4077f69114f5aa2932 https://github.com/HeapsIO/heaps/commit/0daba3517a7193566cd0... (More specific console -> generic changes) * https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf0ed66b47d20d380fe95bc1bc3ec0/src/hl.h#L75 https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... (Console brand specific defines) * https://github.com/HeapsIO/heaps/pull/349 https://github.com/HeapsIO/heaps/pull/349 I guess it's all sufficiently vague to not break any NDAs. :) I think my curiosity is now satisfied. :D
- follower 5y ago
  Ah, seems its developer occasionally comments on HN: https://news.ycombinator.com/item?id=26292740 https://news.ycombinator.com/item?id=26292740 :)
adkadskhj 5y ago
Interesting. They mention porting is possible - what would that look like i wonder? Would you make your game run under both UE4 and Godot? Or do they attempt to put a layer between whatever engine you use and the actual console APIs?
- follower 5y ago
  In another comment about Heaps.io I summarized their process: https://news.ycombinator.com/item?id=26910210 https://news.ycombinator.com/item?id=26910210 Essentially the main parts are probably: * Support the platform native C compiler. (e.g. convert your build system & any idiosyncrasies in your/their code). * Support the platform OS. * Support the platform native graphics API. And, yeah, the easiest way to do this (while still maintaining cross-platform compatibility) is to have an abstraction layer of some sort between the game engine & console specifics. And, Godot does already have this abstraction layer to support multiple platforms, it's just that everyone who wants to use it on consoles has to reimplement it themselves--unless they work with a third party who has already ported it. (AFAICT there's nothing that would stop a company from doing a console Godot port and then saying "We can't Open Source this code but will license it freely to anyone who can prove they're a registered console developer" but I'm not sure what the commercial incentives for that might be. It'd reduce unnecessary duplication and could in theory allow for (licensed developers) to improve the code base in cooperation but would be quite the undertaking & also a significant but also necessarily invisible community contribution!)

e12e 5y ago

For those interested in Godot, but wanting console support - heaps might be of interest: https://heaps.io/ https://heaps.io/ It is another, smaller engine. I would say less featureful than Godot, but I imagine there are some overlapping use-cases? Ed: and for something quite different - dragon ruby seems a lot of fun (not free, not open source, though): https://dragonruby.org/ https://dragonruby.org/

follower 5y ago
I was curious how Heaps.io could be an Open Source project while also supporting consoles (PlayStation, XBox, Switch) so researched it a bit. The key aspect seems to be that there's a commercial entity behind the project who presumably has console development licenses. AFAICT none of the console specific source is Open Source but the implication seems to be that the source is (freely?) made available to registered console developers due to the fact the developer of both is a licensed console developer and has decided to make it available to others. Console development/distribution is mentioned in a couple of places in the documentation[0]: "The hello.hl file contains bytecode that can be run with the HashLink virtual machine using hl hello.hl. It does give quite good performances and have been proven by successful commercial games such as Northgard or Dead Cells. However, it is also possible to compile the HashLink code using a native compiler. This allows to compile for consoles and mobile. This will create a directory out containing a lot of generated C code that needs to be built using a native compiler and linked to the same HashLink runtime[...]" With regard to console support it says: "... for Consoles (Nintendo Switch, Sony PS4, Microsoft XBoxOne), please contact us at nicolas @ haxe.org if you are a registered developer for one or several of these" And here[1]: "The final resulting shader will then be compiled to the target platform native shader language (HXSL currently supports GLSL for OpenGL, HLSL for DirectX 11+, AGAL for AdobeAir, and PSSL for Sony PS4)." Also, this post[2] describes how the lower level parts (using Haxe/hashlink) integrate with native (i.e. console) platforms: "The game gets compiled to a cross-platform .hl file that can be run with HashLinkVM JIT. It can also be compiled to C directly and compiled using any native compiler, which we are using for our console ports on PlayStation, Xbox and Nintendo Switch." "We also have additional platform API libraries for Steam, as well as console integration libraries that are only accessible if you have a registered developer." In the same post the Heaps.io console implementation is described: "This architecture allows us to integrate new renderers or platforms by just porting a few classes given that the native libraries are been made available in HashLink. Heaps.io supports the following plaforms/renderer: [...] HashLink/C with NVN (Nintendo Switch SDK native graphics API) HashLink/C with GNM (PS4 SDK native graphics API) HashLink/C for Xbox One SDK" [0] https://heaps.io/documentation/hello-hashlink.html https://heaps.io/documentation/hello-hashlink.html [1] https://heaps.io/documentation/hxsl.html https://heaps.io/documentation/hxsl.html [2] https://haxe.org/blog/shirogames-stack/ https://haxe.org/blog/shirogames-stack/
- follower 5y ago
  Some other details from spelunking the code base... The exposed console functionality interface can be found via `hl_console`, `usesys` & `usegl` references: * https://github.com/HaxeFoundation/hashlink/search?q=hl_console&type=code https://github.com/HaxeFoundation/hashlink/search?q=hl_conso... * https://github.com/HeapsIO/heaps/search?q=usesys&type=code https://github.com/HeapsIO/heaps/search?q=usesys&type=code * https://github.com/HeapsIO/heaps/search?q=usegl&type=code https://github.com/HeapsIO/heaps/search?q=usegl&type=code The "interesting" pieces are all in some other codebase, e.g.: * https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf0ed66b47d20d380fe95bc1bc3ec0/src/hlc_main.c#L42 https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... * https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf0ed66b47d20d380fe95bc1bc3ec0/libs/sdl/gl.c#L19 https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... And, if you're a weirdo like me that likes trawling for small console development details (e.g. they treated as ~BSD system) in the code base check out these: * https://github.com/HeapsIO/heaps/pull/491 https://github.com/HeapsIO/heaps/pull/491 (fixes for Nintendo "NVN") * https://github.com/HaxeFoundation/hashlink/commit/7af111a38f99f6e18d8b30cd8edadd24e0d6803e https://github.com/HaxeFoundation/hashlink/commit/7af111a38f... (PlayStation related naming becomes generic "console" naming) * https://github.com/HeapsIO/heaps/commit/0daba3517a7193566cd01d4077f69114f5aa2932 https://github.com/HeapsIO/heaps/commit/0daba3517a7193566cd0... (More specific console -> generic changes) * https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf0ed66b47d20d380fe95bc1bc3ec0/src/hl.h#L75 https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... (Console brand specific defines) * https://github.com/HeapsIO/heaps/pull/349 https://github.com/HeapsIO/heaps/pull/349 I guess it's all sufficiently vague to not break any NDAs. :) I think my curiosity is now satisfied. :D
follower 5y ago
Ah, seems its developer occasionally comments on HN: https://news.ycombinator.com/item?id=26292740 https://news.ycombinator.com/item?id=26292740 :)

adkadskhj 5y ago

Interesting. They mention porting is possible - what would that look like i wonder? Would you make your game run under both UE4 and Godot? Or do they attempt to put a layer between whatever engine you use and the actual console APIs?

follower 5y ago
In another comment about Heaps.io I summarized their process: https://news.ycombinator.com/item?id=26910210 https://news.ycombinator.com/item?id=26910210 Essentially the main parts are probably: * Support the platform native C compiler. (e.g. convert your build system & any idiosyncrasies in your/their code). * Support the platform OS. * Support the platform native graphics API. And, yeah, the easiest way to do this (while still maintaining cross-platform compatibility) is to have an abstraction layer of some sort between the game engine & console specifics. And, Godot does already have this abstraction layer to support multiple platforms, it's just that everyone who wants to use it on consoles has to reimplement it themselves--unless they work with a third party who has already ported it. (AFAICT there's nothing that would stop a company from doing a console Godot port and then saying "We can't Open Source this code but will license it freely to anyone who can prove they're a registered console developer" but I'm not sure what the commercial incentives for that might be. It'd reduce unnecessary duplication and could in theory allow for (licensed developers) to improve the code base in cooperation but would be quite the undertaking & also a significant but also necessarily invisible community contribution!)