Godot: Godot 3.0 concerns

[RandomShaper]

I'm in the middle of the development of a game and I'd like to know how the Godot 3.0 project is going to be managed.

What I know/believe;

• a) Godot 2.2 is going to be skipped in favor of Godot 3.0.
• b) Godot 3.0 will be based on OpenGL ES 3.
• c) Godot 3.0 will break compatibility with 2.x at various levels (scripting, shaders, etc.).

Godot current master branch currently features pretty much everything I need, but during the lifetime of my project I will probably need to update some things (support for upcoming Android/iOS releases, engine bugfixes, etc.).

I can deal with adapting my project to 3.0 as long as no very complex changes are needed at the scene and script levels, but rewriting shaders and specially loosing compatibility with OpenGL 2 are big concerns for me.

Are these my only options?:

• Keep using 2.1 custom builds and hope no engine or platform support updates are needed.
• Switch to 3.0, readapt, rewrite shaders, etc. and loose support for OpenGL ES 2.

[akien-mga]

There's a point d):

• d) Godot 3.1 (a priori, unless done already for 3.0) will readd an OpenGL ES 2 compatible renderer based off the OpenGL ES 3 one.

This means that if your main concern is supporting GLES2, you can stay on 2.1.x for now, and switch to 3.x for 3.1.

Also, until a modern GLES2 renderer is available, we'll likely continue supporting 2.1.x to some extent. Likely not with many new features, but necessary bug fixes and tweaks for continued platform support could likely still be done.

[RandomShaper]

Nice to know!

[reduz]

We will attempt to make a converter from 2.1 to 3.0, which should do many
things automatically, others will have to be adjusted manually. I think
most should still work and only need small changes.
Regarding GLES2, the plan is to add a compatibility renderer eventually, so
it should still work.

On Tue, Oct 11, 2016 at 3:45 AM, Pedro J. Estébanez <
[email protected]> wrote:

I'm in the middle of the development of a game and I'd like to know how
the Godot 3.0 project is going to be managed.

What I know/believe;

• a) Godot 2.2 is going to be skipped in favor of Godot 3.0.
• b) Godot 3.0 will be based on OpenGL ES 3.
• c) Godot 3.0 will break compatibility with 2.x at various levels
  (scripting, shaders, etc.).

Godot current master branch currently features pretty much everything I
need, but during the lifetime of my project I will probably need to update
some things (support for upcoming Android/iOS releases, engine bugfixes,
etc.).

I can deal with adapting my project to 3.0 as long as no very complex
changes are needed at the scene and script levels, but rewriting shaders
and specially loosing compatibility with OpenGL 2 are big concerns for me.

Are these my only options?:

• Keep using 2.1 custom builds and hope no engine or platform support
  updates are needed.
• Switch to 3.0, readapt, rewrite shaders, etc. and loose support for
  OpenGL ES 2.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6785, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2-k5QGPdER8yrWSGBWqcch5h1SeTks5qyzCggaJpZM4KTS2G
.

[RandomShaper]

OK, thank you from letting me now.

[ret80]

Support GLES2 is not so important. Since "Apple A7" all devices support GLES3. With Androyd situation is worse. But many ustroistva support GLES3 (since 2013)

[reduz]

Still one or two more years until we can stop worrying about GLES2 on
Android

https://developer.android.com/about/dashboards/index.html

On Wed, Oct 12, 2016 at 6:45 AM, ret80 [email protected] wrote:

Support GLES2 is not so important. Since "Apple A7" all devices support
GLES3. With Androyd situation is worse. But many ustroistva support GLES3
(since 2013)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6785#issuecomment-253167820,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z27RDsGmPkcVaWnaQXJUsymU6WOzBks5qzKwggaJpZM4KTS2G
.

[vonflyhighace2]

Is a 32bit flavor of the engine still being supported. If so what's the maintenance like supporting 64 and 32bit. How many devs are using the 32bit version? With the limited resource would it not be better to focus on one branch. I for one found the 64bit editor to be superior to the 32bit which felt sluggish on the project I'm currently prototyping not to mention most engines have done away with a 32bit version.

[reduz]

developing 32 bits is no effort at all, as long as anyone is willing to
test it..

On Wed, Oct 12, 2016 at 6:21 PM, vonflyhighace2 [email protected]
wrote:

Is a 32bit flavor of the engine still being supported. If so what's the
maintenance like supporting 64 and 32bit. How many devs are using the 32bit
version? With the limited resource would it not be better to focus on one
branch. I for one found the 64bit editor to be superior to the 32bit which
felt sluggish on the project I'm currently prototyping not to mention most
engines have done away with a 32bit version.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6785#issuecomment-253343215,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z20fl0RyNhOPropFlqVNUhJF-FeCwks5qzU9wgaJpZM4KTS2G
.

[eon-s]

The way collision shapes work is going to change on 3.x too?

[vonflyhighace2]

The whole 3D physics system needs a update/rewrite because its is severely broken at the moment. That's why I believe there's not really many 3D projects being done with it yet.

[reduz]

The 3D physics engine is almost 10 years old.. I'm not willing to replace
it by an existing one because there is some functionality that would
definitely be lost (mainly related to kinematic bodies and areas, which is
not supported by traditional engines), but it definitely needs a good
rewrite.

On Wed, Oct 12, 2016 at 7:02 PM, vonflyhighace2 [email protected]
wrote:

The whole 3D physics system needs a update/rewrite because its is severely
broken at the moment. That's why I believe there's not really many 3D
projects being done with it yet.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6785#issuecomment-253353097,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z25gpgLfjc5qRehJqmeo8pNBwT71Kks5qzVkTgaJpZM4KTS2G
.

[ghost]

The 3D physics engine is almost 10 years old.. I'm not willing to replace it by an existing one because there is some functionality that would definitely be lost (mainly related to kinematic bodies and areas, which is not supported by traditional engines), but it definitely needs a good rewrite.

@reduz Perhaps it would be good to add those functionalities to an existing engine (like Bullet)?

[reduz]

Its probably easier to adapt the functionality from an existing engine to
Godot, which is a lot less bloat.

On Sat, Oct 29, 2016 at 9:27 AM, paper-pauper [email protected]
wrote:

@reduz https://github.com/reduz Perhaps it would be good to add those
functionalities to an existing engine (like Bullet)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6785#issuecomment-257088946,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z22SipVTq2b82Es0d7fTnpeUe8Gq9ks5q4zvNgaJpZM4KTS2G
.

[Algorithmus]

Apple does support GLES 3.0, which is all fine and good, but only in a forward compatible way. That means, no references to anything GLES 2.0 or earlier, or else the system will force GLES 2.0 on you. We experienced this while trying to get Krita's instant preview to work on OSX. If you are going to replace all the shader syntax and functions with the GLES 3.0 versions completely, and you're sure any libraries or frameworks you are using don't rely on GLES 2.0 specific stuff, then I suppose this won't really be an issue.

[RandomShaper]

Now _gles3_ is merged so _master_ cannot longer be used as a "pseudo-2.x" branch, I wonder some things:

In order to keep a healthy 2.1 branch, the best way of sending contributions relevant to both is submitting separate PRs, isn't it? Will they need to be marked with a trailing (2.1) or (3.0) in the title or will they be tagged according to their base branch?

As one of many still interested in 2.1 (until 3.1 is here) I'd like it to get all the bug fixes and platform support updates for it. Would it be a good idea to encourage double-PRing in the contribution guidelines or the way will be just cherry-pick every mergeable commit?

[akien-mga]

@RandomShaper Typically I try to cherry-pick relevant commits myself from the master branch to the 2.1 branch, so the workflow would be to PR on master, and maybe mention in the PR if you think it would be safe to cherry-pick without jeopardizing the stability of the 2.1 branch.

It worked well during the 2.1 development with the 2.0 stable branch, I'm not sure yet how it will turn out once we start really breaking compatibility in master - I imagine cherry-picking might become harder, and then double PRs might be necessary since the PR author would know how to best rebase their work. The 2.1 PR should probably only be done once the master one has been merged though.

[plucian]

will the enhanced GDScript be ported back to 2.1.x branch or will only be a 3.0 feature only ?

[bojidar-bg]

Backporting GDScript sounds like a nice thing to do (but to the 2.2.x branch, not the 2.1.x, I guess), as long as we don't crash into too many conflicts.

[RandomShaper]

I've cherry-picked some backwards-compatible stuff for the 2.1 branch; let's see if they merge. (#7494)

[plucian]

my understanding was that no 2.2 will ever be released, just 2.1.x, as s somewhat stable branch. That's why I guess people were saying 2.1 instead of 2.2. Anyway, whatever 2.2 or 2.1 I would still like to have this branch still maintained at least until 3.1 is ready.

[RandomShaper]

I think that's the plan. So we (they) will keep cherry-picking
backwards-compatible minor features and fixing bugs. Platform-specific
changes as well.

It seems the 2.2 name is confusing people. I was also confused when I first
saw it and pulled it to base my custom build upon it.

Would it be good to rename it to something that states its intent better?
Or perhaps just to put a visible notice about it somewhere?

El 11 ene. 2017 10:03 a. m., "Lucian" [e-mail] escribió:

my understanding was that no 2.2 will ever be released, just 2.1.x, as s
somewhat stable branch. That's why I guess people were saying 2.1 instead
of 2.2. Anyway, whatever 2.2 or 2.1 I would still like to have this branch
still maintained at least until 3.1 is ready.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6785#issuecomment-271814539,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCttONH2d0zV5mhT-vbMk4zY8MIbd1ks5rRJrKgaJpZM4KTS2G
.

[akien-mga]

It seems the 2.2 name is confusing people. I was also confused when I first
saw it and pulled it to base my custom build upon it.

Would it be good to rename it to something that states its intent better?
Or perhaps just to put a visible notice about it somewhere?

I guess I could rename it to 2.2-legacy or something. My intent with this branch was just to give people using the master branch in production a go-to branch, since I guess not everyone is confident enough with git to checkout the last pre-gles3 commit and make their own local branch out of it.

Eventually I'd also like to generate a set of official (but unsupported) 2.2-alpha binaries for those that were using stuff like the advanced multiplayer API for their games - the branch is stable-ish so could likely be used in production, even if not heavily tested and bugfixed as one would expect of a 2.2-stable.

For all other users, the supported branch stays 2.1 and I will soon do a massive cherry-picking of relevant master commits in 2.1, and generate a RC build to get early feedback on a future 2.1.2-stable.

[akien-mga]

I guess this discussion can now be closed ;)