Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Godot 3.3

godotengine.org

Post reply on HN
Print view View original

121–130 of 138 posts

Re: Godot 3.3

#121

Post by follower »

follower wrote: post #119
e12e wrote: post #103

Earlier quoted context omitted.

For those interested in Godot, but wanting console support - heaps might be of interest: 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/

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 co…

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_conso...

* https://github.com/HeapsIO/heaps/search?q=usesys&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/4c4de37d49cf...

* 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 (fixes for Nintendo "NVN")

* https://github.com/HaxeFoundation/hashlink/commit/7af111a38f... (PlayStation related naming becomes generic "console" naming)

* https://github.com/HeapsIO/heaps/commit/0daba3517a7193566cd0... (More specific console -> generic changes)

* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... (Console brand specific defines)

* 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

Re: Godot 3.3

#122

Post by aroman »

lewispollard wrote: post #109
aroman wrote: post #44

Earlier quoted context omitted.

Sure, but as someone working on a moderately sized 2d game in Unity - I’ve never really found that to be anything more than a minor annoyance. At most it’s just an extra cast here or there. Are there other examples of it being better for 2d?

It uses pixels as its units for 2D, which is the main advantage over Unity, depending on your use case (ie, it's very good for pixel perfect 2D games). If you want to move your sprite 33 pixels, you just add 33 to the translation. This also applies to physics, GUI elements, etc. You can also combine the separate 2D and 3D renderers, while maintaining 2D pixel vectors for your 2D objects, and 3D unit vectors for 3D. Y…

Thank you much for this incredibly detailed and thoughtful answer!

Re: Godot 3.3

#123

Post by follower »

adkadskhj wrote: post #99
keyle wrote: post #63

Earlier quoted context omitted.

I shipped a game exclusive to PS4 using UE4 about 4 years ago. Godot by default does not support consoles. Yes, you can to employ another company to port it for you, but that is a no go for me. UE4 on the other hand you can do it all yourself once you get the developer kit and access (legally) to the platform of your choice. On the other hand you can easily do mobile with Godot.

Any idea why Godot does not do consoles? Is it a licensing problem, resources problem (ie technical difficulty), or..? I'm curious because i'm dabbling in some gamedev and wanting to eventually ship mobile and console. I'm more focused on bleeding edge tooling though, Rust gamedev specifically, but i'm curious if the reasons Godot doesn't ship to console also means any Rust project won't be able to ever, either. Is t…

Someone else already answered with the link to the official Godot information page[0] which can be summarized as:

* Godot dev team isn't a commercial entity with console development license agreements.

* Even if they were, the console support couldn't be truly Open Source due to licensing & NDA agreements with the console manufacturers.

* There are third parties who have ported Godot to consoles who may work with you port your own Godot game.

* You could always port it yourself.

Another aspect that they don't mention is that for the Godot dev team themselves to support consoles they'd essentially have to create an entire parallel development infrastructure (repo, issue tracking, CI etc etc) per console to maintain the NDA confidentially requirements.

In regard to Rust, they were another example I mentioned up thread about this very situation:

"""

The situation is also the same for other FLOSS projects, e.g. the Rust language, where the issues tracking game console support basically say "if you have the ability to develop for (current) game consoles, you also know we can't talk about it here where others aren't under manufacturer NDA":

https://github.com/rust-gamedev/wg/issues/90

https://github.com/EmbarkStudios/rust-ecosystem/issues/18

https://www.reddit.com/r/rust/comments/jtqgn4/q_feasibility_...

"""

So, the "something" that is "preventing opensource lowbudget projects from shipping to console" is manufacturer license agreements/NDAs that are the antithesis of & a barrier to cross-company Open Source development. :)

[0] https://docs.godotengine.org/en/3.0/tutorials/platform/conso...

Re: Godot 3.3

#124

Post by follower »

adkadskhj wrote: post #107
megapoliss wrote: post #102

Earlier quoted context omitted.

> 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/conso...

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?

In another comment about Heaps.io I summarized their process: 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!)

Re: Godot 3.3

#125

Post by viceroyalbean »

keyle wrote: post #15
viceroyalbean wrote: post #9

Looking forward to checking this out. I've been playing around with some physics based ideas in Godot but had issues with collisions. Hoping that the collision fixes mentioned in the changelog applies to what I'm doing. I'm very impressed with the quality of Godot and its continuous improvements.

What issues are you having with physics? I should rephrase, what issues are you having with physics in Godot that are not in other engines? I say this because I've shipped physics simulation games and Godot has been the simplest most reliable engine for that.

I'm guessing I'm doing something wrong on a basic level, but I couldn't get collision detection working between a KinematicBody and a RigidBody. In the game my character (the kinematic body) would walk into the object and it would be pushed as expected, but the kinematic body would not register collisions.

I haven't played around with other engines that much so I can't comment on how they work.

Re: Godot 3.3

#126

Post by nightowl_games »

Flex247A wrote: post #23

Godot is a really good engine but there's one thing which I cannot get to work properly: UI font rendering. The interface font is blurry across platforms. I hope they introduce a fix for it.

There's a pull request for SDF based fonts that should make the labels really good all the time.

I have no issues with current fonts. Enable filter in your font settings, can try importing at a massive size designing at a high render scale, and using the viewport scaling to scale it down.

Native viewport (no scaling) and using no scale on your labels should make it all render as you'd expect, however.

Re: Godot 3.3

#127

Post by bartvk »

hnick wrote: post #77
Buttons840 wrote: post #36

Earlier quoted context omitted.

And as mentioned in the article/release, they are serious about maintaining Godot 3 and won't neglect it in favor of 4.

The more comments I read in this thread, the more this sounds like Perl 5 and Perl 6.

It'll take some time before you can confidently make that assessment, though. It took ten years for Perl 6 to come out, and then actually it didn't come out as Perl.

Re: Godot 3.3

#128

Post by nightowl_games »

publicola1990 wrote: post #6

Having been trying to using this, but strangely found that there is no c++ version available for Windows, whereas it is the preferred version in linux. Is this the case?.

I have done c++ Godot development on windows and Linux. They are equivalent. Only difference is the massive PITA that setting up your windows environment is. (Python, scons & msvc)

Re: Godot 3.3

#129

Post by bartvk »

lewispollard wrote: post #109
aroman wrote: post #44

Earlier quoted context omitted.

Sure, but as someone working on a moderately sized 2d game in Unity - I’ve never really found that to be anything more than a minor annoyance. At most it’s just an extra cast here or there. Are there other examples of it being better for 2d?

It uses pixels as its units for 2D, which is the main advantage over Unity, depending on your use case (ie, it's very good for pixel perfect 2D games). If you want to move your sprite 33 pixels, you just add 33 to the translation. This also applies to physics, GUI elements, etc. You can also combine the separate 2D and 3D renderers, while maintaining 2D pixel vectors for your 2D objects, and 3D unit vectors for 3D. Y…

Upvote for mentioning Jeff Vogel. His blog is here: https://jeff-vogel.blogspot.com/

He doesn't post often, but when he does, it's a great one about indie game development.

Re: Godot 3.3

#130

Post by kayamon »

onion2k wrote: post #92
keyle wrote: post #35

Earlier quoted context omitted.

To be fair, it's perfectly fine for 3D, such as traditional "isometric" style 3D. It suffers more with the lack of clever culling in first person style cameras, especially near large objects (it renders the whole object, even if 5% of it is seen).

it renders the whole object, even if 5% of it is seen Do other engines cull parts of objects?

No.
Post reply on HN