godotengine / godot-demo-projects

Demonstration and Template Projects
https://godotengine.org
MIT License
5.82k stars 1.62k forks source link

[TRACKER] Porting the demos to Godot 4 #697

Open aaronfranke opened 2 years ago

aaronfranke commented 2 years ago

This issue tracks the progress of porting the Godot demo projects to Godot 4.0. This list is in alphabetical order by folder path.

Calinou commented 2 years ago

I have an ongoing 4.0 port of the 3D Global Illumination demo: https://github.com/Calinou/godot-demo-projects/tree/add-global-illumination-demo-2-4.0

Edit: Pull request opened: https://github.com/godotengine/godot-demo-projects/pull/718

voylin commented 2 years ago

I have fixed the Pause demo with pull request #701 And I checked the Autoload(Singletons) demo in pull request #702 I hope I'm helping in finishing off all these tasks. I'm pretty now to contributing so please tell me when I'm doing things wrong!

Edit: Had some more time so decided to fix the Translation demo as well with pull request #704 The Control Gallery Demo also got fixed/adjusted so the layout is correct again with previous version. This is done in pull request #705

GeorgeS2019 commented 2 years ago

@Calinou I wonder if it makes sense to discuss here what to do with the Godot4 c# demo examples. Should there be discussions among Godot4 mono users or we wait until Godot4 dotnet6 is merged into the master?

@voylin Do you do Godot4 c#? Thank you for volunteering.

Calinou commented 2 years ago

@GeorgeS2019 Porting C# demos will have to wait until the .NET 6 work is merged in master. Until this happens, the API is too unstable for porting to be worth it.

aaronfranke commented 2 years ago

@GeorgeS2019 That's a good point, I added a new emoji to this tracker to reflect this status ❌.

voylin commented 2 years ago

I've been trying to get some of the demo's fixed but 2D Lights as Mask and 2D Lights and Shadows are not possible yet. There are some rendering issues with light2D which make the demo's not work.

Calinou commented 2 years ago

I've been trying to get some of the demo's fixed but 2D Lights as Mask and 2D Lights and Shadows are not possible yet. There are some rendering issues with light2D which make the demo's not work.

Indeed, see https://github.com/godotengine/godot/issues/55806.

alex9099 commented 2 years ago

I just tested the voxel game and it seems to work without problems (no debugger errors nor anything seemingly wrong rendering wise) on alpha 7

voylin commented 2 years ago

@voylin Do you do Godot4 c#? Thank you for volunteering.

@GeorgeS2019 Sorry for the late reply, hadn't seen the message. I am willing to test the c# stuff as well, but we will have to wait until the beta I guess. Like Calinou said, .NET 6 stuff should first be merged.

voylin commented 2 years ago

2D Physics Test demo is having a bug which is occurring because of find_children. Issue godotengine/godot#54939 has to be solved first. That demo should also have the tilemap icon as one of the tests uses the Tilemap.

voylin commented 2 years ago

I just tested the voxel game and it seems to work without problems (no debugger errors nor anything seemingly wrong rendering wise) on alpha 7

@alex9099 The voxel demo still has some rendering bugs. @aaronfranke worked on this demo in #694 But when testing it I found rendering issues especially when breaking blocks in the flat space, not all the faces on the sides don't get updated. This demo will probably need to wait until the beta releases before it can be checked of the list.

Anutrix commented 1 year ago

All these need to be rechecked with Godot 4 beta or newer. Probably most of them are broken again now.

Tried Bullet Shower(tagged βœ…) on master build and got: Line 59:Function "update()" not found in base self. Built-in 3to4 Converter didn't help either.

Calinou commented 1 year ago

I'm going through the 4.0-dev demos to update them as we speak.

This one-liner (run in the repository root) makes it easy to go through all demos in the editor one-by-one:

for demo in **/*.godot; do godot $demo; done
scriptsengineer commented 1 year ago

Multiplayer Pong: Ported to godot 4 beta 5 -> https://github.com/godotengine/godot-demo-projects/pull/792

zoeesilcock commented 1 year ago

I have noticed that simply opening and running the demo projects on Godot 4.0b10 causes diffs in some scenes. It can be simple stuff like certain attributes have changed place or bigger stuff like removed attributes. Should these changes be committed as we find them or is there a plan to go through and commit all these scene-diffs caused by Godot 4.0 at one time later on?

Calinou commented 1 year ago

I have noticed that simply opening and running the demo projects on Godot 4.0b10 causes diffs in some scenes. It can be simple stuff like certain attributes have changed place or bigger stuff like removed attributes. Should these changes be committed as we find them or is there a plan to go through and commit all these scene-diffs caused by Godot 4.0 at one time later on?

I think we can do this once 4.0 gets closer to release, as some bug fixes may still cause changes to occur in scene files.

hsandt commented 1 year ago

I tried to run Platformer 2D and it failed immediately due to API change in Game.gd. I could fix the pure script errors but the project is buggy after that (incorrect behavior). I suppose it's worth doing a first PR just for the scripting error fixing, but since I haven't forked the repo yet I'll just drop my notes here for now:

OS.window_fullscreen = not OS.window_fullscreen becomes toggle_fullscreen() where the function is defined as:

func toggle_fullscreen():
    if DisplayServer.window_get_mode() not in \
            [DisplayServer.WINDOW_MODE_FULLSCREEN, DisplayServer.WINDOW_MODE_EXCLUSIVE_FULLSCREEN]:
        DisplayServer.window_set_mode(DisplayServer.WINDOW_MODE_FULLSCREEN)
    else:
        DisplayServer.window_set_mode(DisplayServer.WINDOW_MODE_WINDOWED)

get_tree().set_input_as_handled() becomes get_viewport().set_input_as_handled()

However, I noticed that both are mentioned in https://github.com/godotengine/godot/blob/master/editor/project_converter_3_to_4.cpp (with the subtlety that fullscreen has two variants and the converter only cares about exclusive fullscreen, so user would need a bit of manual work after the auto-conversion to get the exact behavior they want), which is itself used by command godot4 --convert-3to4.

I suspect that because only the gist converted script https://gist.github.com/aaronfranke/79b424226475d277d0035b7835b09c5f was run, the newest changes in project_converter_3_to_4.cpp have not been taken into account. So before I start forking the project and converting things manually, maybe we should try to run the latest --convert-3to4 on the projects that still need it to see how far we can automatically update things?

I think this is also a good idea to spot what --convert-3to4 can do and what it can't, and for anything that it didn't convert, we should decide if: a. the missed conversion is simple enough to be integrated into project_converter_3_to_4.cpp b. the missed conversion requires human interaction to decide subtle edge case and wanted behavior, in which case it should be added to some migration guide (like https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976 but I think this one is unofficial, so we could do the same with an official one; on a personal note, this gist receives a lot of comments and seems to be a good basis to work from)

At the end, we would have a compilation of all the manual things we did to upgrade the demo projects that would contribute to this migration guide.

aaronfranke commented 1 year ago

@hsandt You are welcome to convert with any of these means, and submit any improvements you'd like to the converter. Just make sure that the final PR you submit has been hand-checked to have only good changes.

hsandt commented 1 year ago

For 2D demos using the tilemap:

In Platformer 2D, I noticed this tilemap break:

image

due to Rendering Texture Origin being by default (0, 0) which means centered, causing tiles with Texture Region Size not matching TileSet Tile Size to have a representative area (with orange borders inside the green rectangle) to be misaligned.

I'm gonna fix the Texture Origin to some value so that the orange box matches the top of the tile, but it would be easier with some Texture Origin anchor direction I think (an enum with values: Center (current), Top-left, Top-middle, Top-right, Middle-left, Middle-right, Bottom-left, Bottom-middle, Bottom-right).

Or maybe the better way of doing this is to just split the big 32x64 tile into two parts of 32x32? I'm doing this in this in my own project (and also using auto-tile even with slopes, see https://github.com/godotengine/godot-proposals/discussions/6157).

For now I'll just fix the offset for minimal change, but I'd like to know the purpose of the demo to know better how I should use Godot 4's new features. Basically, are we demonstrating the tilemap too and trying to do things nicely in this demo, or are we just demonstrationg platforming, leaving TileSet demonstration to some other future TileMap demo?

hsandt commented 1 year ago

I opened a new branch for Demo Platformer 2D porting: https://github.com/hsandt/godot-demo-projects/tree/4.0-dev-platformer

I will send a PR when I get something decent to play. Unless you prefer that I regularly send small PR as long as there is some visible improvement?

Calinou commented 1 year ago

For now I'll just fix the offset for minimal change, but I'd like to know the purpose of the demo to know better how I should use Godot 4's new features. Basically, are we demonstrating the tilemap too and trying to do things nicely in this demo, or are we just demonstrationg platforming, leaving TileSet demonstration to some other future TileMap demo?

I'd say the demo should mostly be about platforming. Correct TileSet configuration is nice, but not essential for this kind of demo. Eventually, we should have a separate demo showcasing procedural 2D level generation with TileSets + TileMaps (most likely with a top-down/three-quarter view).

I opened a new branch for Demo Platformer 2D porting: hsandt/godot-demo-projects@4.0-dev-platformer

I will send a PR when I get something decent to play. Unless you prefer that I regularly send small PR as long as there is some visible improvement?

You could open a draft PR now, or wait later and open a full PR directly. I personally prefer opening a draft PR as soon as I have something workable, so someone else can continue the work in case I no longer have time to complete it.

voylin commented 1 year ago

Maybe a good idea to remove the visual scripting ones as the folder has already been deleted from the branch and the visual scripting has been removed from the engine in 4.0

Will this script be updated again once 4.0 is released? I will have some spare time at the end of this month and would be able to go over some of these projects to see if I can check/fix the demo projects for 4.0, would be helpful to see here which ones aren't finished yet.(probably quite some work to keep this list up to date but just asking to check)

hsandt commented 1 year ago

You could open a draft PR now, or wait later and open a full PR directly. I personally prefer opening a draft PR as soon as I have something workable, so someone else can continue the work in case I no longer have time to complete it.

Here you go. BTW should I prefix all my commits with [4.0] instead of [3to4] ? I changed convention between my commits and my PR title (maybe it doesn't matter if you squash the whole thing, but it will if you preserve the full commit history).

hsandt commented 1 year ago

If you have trouble with the camera being too zoomed out in your demo, mind that the Zoom factor convention has been reversed: it now zooms in when the value increases, zooms out when the value decreases. So you have to reverse the value: in the case of 2D platformer, I changed (0.5, 0.5) -> (2.0, 2.0).

Godot 3 demo

image

Godot 4 demo before change

image

Godot 4 demo after change

Still wrong offset, but proper zoom

EDIT: offset is now fixed, it was a bad local change to position that kept restoring even after git revert + Reload scene in Godot. I should probably report this as an editor bug, in fact.

image


EDIT: OK, I just found out it was in the offical guide: https://docs.godotengine.org/en/latest/tutorials/migrating/upgrading_to_godot_4.html

I'll make sure to read the rest, it could help me a lot on other features to upgrade.


OLD remark below:

I suppose it could be added to --convert-3to4, but since the property name is not changing, it is particularly difficult to decide what to do, unless you are certain that you are actually converting a Godot 3 project. Basically, since the change is about reversing values, it is not idempotent, so you cannot use --convert-3to4 multiple times, guaranteeing no further changes.

I suppose we could add an option --force-convert-3to4 or something that will convert values this way (maybe only if project is actually using Godot 3; this won't work for people who started converting their project with an older version of the converter, unfortunately).

Or we could just show a warning when Camera zoom values != (1, 1) are detected (in scene or in script; in script, we could even add a comment above).

But if it's too complicated, we could add this to some upgrading guides so developer can just do it manually. For now I'll just comment on the two unofficial guides I know (https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976 and https://www.reddit.com/r/godot/comments/tsxgnj/migrating_from_3x_to_40/).

InfiniteProductions commented 1 year ago

3D/MaterialTesters with 4.0 RC6 on my computer give me this:

godot-4rc6-3D-mattesters-issue

importing assets (_sandrough.jpg) stuck Γ  94%, CPU is 100% use (the decrease in CPU graph comes from a change of affinity from all to only 2/8 cores), then I decide to kill Godot.

Trying to reimport it directly from project list makes Godot stuck at "park.hdr" 0%, still 100% CPU usage, then finally project is loaded after several minutes: godot-4rc6-3D-mattesters-issue2

I don't call this working actually.

For the record, it's on an Asus G750 JH with a core i7 and a GeForce GTX 780M, I know it's far from being the best available these day, still it's not yet a low-end computer. (tool used is System Informer)

Calinou commented 1 year ago

Trying to reimport it directly from project list makes Godot stuck at "park.hdr" 0%, still 100% CPU usage, then finally project is loaded after several minutes:

This could be due to https://github.com/godotengine/godot/issues/61948. That said, all *.hdr.import files in the demo already have compress/mode=0, which indicates they're using lossless compression and not VRAM compression. This can be seen in the Import dock:

image

I've tried removing the .godot/ folder then reimporting the demo locally, it successfully imports in less than 10 seconds with 4.0.rc 8208060c2. Are you using a self-compiled editor build? If so, make sure it was built with optimizations.

I don't call this working actually.

I have to remind you that we have a Code of Conduct. Please stay constructive.

InfiniteProductions commented 1 year ago

I've checked all the import settings after the project is reopened in the editor, all are using VRAM compression, including HDR backgrounds, except one.

Only _sandshine.jpg texture use lossless mode, it's 1024x1024 RGB8 texture, no mipmap using ~3MB memory, I don't believe it could be responsible for the import delay alone. And I don't know also if settings has been somehow modified automatically by the editor as I did not change anything not delete the .godot folder inside the project.

By the way, opening the project again is as quick as it is expected. And to answer your question, no, I'm using official 64bits build (v4.0.rc6.official [0cd148313]).

InfiniteProductions commented 1 year ago

I've done more testing on RC6 build:

platformer 3D failed (it looks like there is a regression), I just run the project, then I get this error right away, with a sounds looping while the debugger is running: godot-4rc6-3D-platformer-issue

physicsTest (3D) also have at least one case of failure:

with tests/functional tests/collision pairs using collider type "capsule" and shape type "capsule": godot-4rc+-physicsTest-issue

godot-4rc+-physicsTest-issue2

To reproduce the error, run the project, select the test "functional tests/collision pairs", select "test options" menu, click on "collider type" "capsule (3)" then "shape type" capsule checkbox => error occurred. (it's happened for pretty much every choices, I use box, sphere, convex/concave polygon) In fact, selecting the second option trigger the issue.

and there are a lot's of errors: godot-4rc+-physicsTest-errors-output

hsandt commented 1 year ago

So, how do we publish the demos already ported to Godot 4.0, now that it's out? I'm thinking in particular about 2D platformer which recently reached a decent state thanks to https://github.com/godotengine/godot-demo-projects/pull/851

Calinou commented 1 year ago

Only sand_shine.jpg texture use lossless mode, it's 1024x1024 RGB8 texture, no mipmap using ~3MB memory, I don't believe it could be responsible for the import delay alone. And I don't know also if settings has been somehow modified automatically by the editor as I did not change anything not delete the .godot folder inside the project.

That texture isn't used anywhere in the project. It could be removed at this point: https://github.com/godotengine/godot-demo-projects/pull/869

InfiniteProductions commented 1 year ago

Platformer3D still fail with the same error (see my previous report above) with latest stable release (v4.0.stable.official [92bee43ad]).

Calinou commented 1 year ago

Platformer3D still fail with the same error (see my previous report above) with latest stable release (v4.0.stable.official [92bee43ad]).

The Platformer 3D demo needs updating to account for recent breaking changes in AnimationTree: https://github.com/godotengine/godot/pulls?q=is%3Apr+sort%3Aupdated-desc+transition_request+is%3Aclosed

Note that merely changing /current to /transition_request isn't enough, as it'll break the jumping animation and cause an error to be spammed every frame.

InfiniteProductions commented 1 year ago

The Platformer 3D demo needs updating to account for recent breaking changes in AnimationTree: https://github.com/godotengine/godot/pulls?q=is%3Apr+sort%3Aupdated-desc+transition_request+is%3Aclosed

Note that merely changing /current to /transition_request isn't enough, as it'll break the jumping animation and cause an error to be spammed every frame.

ok thanks. The first post by @aaronfranke need to be updated accordingly as it shows the demo is fully working with zero issue (check mark + checkbox checked).

I guess we have too check all demos again on the stable release.

aaronfranke commented 1 year ago

Thanks for the reminder @InfiniteProductions. I have reset the tracker to have all boxes unchecked to ensure we re-check everything. Contributors such as @Calinou, please re-check anything that's known to be working.

InfiniteProductions commented 1 year ago

I have started to check demos with latest 4 release, @aaronfranke I've sent you some emails (on the address of your github profile) don't know if you've received them, anyway, this is a cleaner file with all test results I've got so far, with no filtering to let you decide if a demo is ok or not by the expected standards.

jls-has commented 1 year ago

The Audio Generator Demo seems broken in Godot 4.0. The buffer fills, but does not seem to delete as it plays. The audio generator makes a boop, but then won't accept any more frames. Any help would be much appreciated.

InfiniteProductions commented 1 year ago

@jgalbertus you may need to be more specific.

Tested with v4.0.1.stable.official [cacf49999] on Windows, frame count increase and decrease as tone is played, I just add some print statement with _tofill value.

GeorgeS2019 commented 1 year ago

Update 14th July 2023

Track Godot 4.1 demo projects

23th May 2023

Godot-4-Overgrown-Subway

image

Desert Light

image

Update 1st May 2023 # Update 1st May 2023 [Expose interpolation methods for 3D track in Animation class](https://github.com/godotengine/godot/pull/73656)
Update 9th April 2023 # Update 9th April 2023 ## Requested Demos - [ ] WebRTC MediaStream: Real-Time Video Streaming > - [X] [Godot4 Demo ?](https://github.com/godotengine/godot/pull/62737#issuecomment-1489511267) > @mattkanwisher [Add MediaStream support to WebRTC for real-time video streaming](https://github.com/godotengine/godot-proposals/issues/2553) > Issue to address: [Move video playback out of core and into an officially supported GDExtension](https://github.com/godotengine/godot-proposals/issues/3286) > godot-video-reference: [When will the ffmpeg be supported in this project for godot4](https://github.com/kidrigger/godot-video-reference/issues/2)
Update 31st March 2023 # Update 31st March 2023 ## List of WIP demo for IK and topics - [Ballhead constraints for FABRIK](https://github.com/godotengine/godot/pull/62003) > @KaruroChori => Do you have a screenshot to help us understand your IK PR? - [IK and Physical Bone Improvements](https://github.com/godotengine/godot-proposals/issues/750) > @NHodgesVFX => Do you have a screenshot to help us understand your IK PR? - [The ability to Limit(constraints) IK](https://github.com/godotengine/godot-proposals/issues/3712) > @ywmaa => Do you have a screenshot to help us understand your IK PR? > https://github.com/ywmaa/Advanced-Movement-System-Godot - [New Animation Editor (with working mockup) ](https://github.com/godotengine/godot-proposals/issues/3950) > @rossunger => Do you have a screenshot to help us understand your IK PR? - [Retool AnimationTree parameter system to use a blackboard-based approach](https://github.com/godotengine/godot-proposals/issues/3352) - [Implement Motion Matching](https://github.com/godotengine/godot-proposals/issues/6122)
Some of Open Issues for Godot4 4.0.1 Demos # For Godot4 .NET 4.0.1 - [ ] 3d/add-physical-light-camera-units-demo => very timely new Godot4 demo - [ ] 3d/[add-3d-sky-shaders-demo](https://github.com/godotengine/godot-demo-projects/pull/809) => **not working in godot 4**
Sky Shaders in Godot 4.0 | What You Should Know https://www.youtube.com/watch?v=SzNmHPr4vf8
- [ ] 3d/add-large-world-coordinates-demo - [ ] 3d/[ik](https://github.com/godotengine/godot-demo-projects/issues/853) => **no back-up plan and prompt decision/action**
Godot4 3D IK ## [discusison](https://github.com/godotengine/godot-proposals/issues/3099#issuecomment-1489596552) Just found this=> ## How should I introduce the current state of the ik problem? https://docs.google.com/document/d/1SCG5FOuFqXti5RJIl5hVvU_h84JIpcedTw0AaAEycZs/edit#) #### [Status Feb 2023](https://github.com/godotengine/godot/issues/63513) #### [Procedural Animation In Godot 4.0](https://www.youtube.com/watch?v=G_seJ2Yg1GA) - https://github.com/CBerry22/Godot-4.0-Procedural-Animation #### [Animation with Inverse Kinematics modifiers coming to Godot 4!](https://www.youtube.com/watch?v=6EkKXhTSBFY) - https://github.com/godotengine/godot-proposals/issues/3099#issuecomment-1489436457 - https://www.youtube.com/watch?v=w1RnhmC3hgI - https://www.youtube.com/watch?v=_timNOvSm_U - https://www.youtube.com/watch?v=H9wcD7X8pXM
- [ ] audio/generator

User-Contributed Scenes

Godot 4.0.1 @RPicster If you have sharable version, would be great ![image](https://user-images.githubusercontent.com/49812372/228676263-d2eafc92-ccbf-4596-a1d3-e02d2839eca7.png)
Godot 4.0.1 RC 2 https://github.com/godotengine/godot/issues/74965#issue-1626454140 ![image](https://user-images.githubusercontent.com/49812372/228675635-e7d84e18-094e-411c-b691-031c6f638f72.png)
Godot 4.0.1 RC 1 https://github.com/perfoon/Abandoned-Spaceship-Godot-Demo ![image](https://user-images.githubusercontent.com/49812372/228675172-473d637a-dbe7-491d-9bcf-f29e0cbfb9fd.png)
Godot 4.0 RC 6 ![image](https://user-images.githubusercontent.com/49812372/228676739-4a4490c6-55e1-4209-b7fe-bbfaec1fd71c.png)
Godot 4.0 RC 4 https://github.com/Calinou/godot-photo-mode-demo ![image](https://user-images.githubusercontent.com/49812372/228677342-8da3a529-c913-4c4f-aeae-fa1529619727.png)
Godot 4.0 beta 15 https://gitlab.com/magnusmj/godot4classroom ![image](https://user-images.githubusercontent.com/49812372/228677988-0dec42a1-98dc-4720-bdcc-9ac0adddce46.png)
Godot 4.0 beta 6 https://github.com/HungryProton/scatter/tree/v4 ![image](https://user-images.githubusercontent.com/49812372/228679014-17c36078-41d7-42c2-a36b-5a88d7db17f8.png)

Additions

Unreal Sun Temple Reference Scene https://github.com/godotengine/godot/issues/75440 ![image](https://user-images.githubusercontent.com/49812372/228682526-cd7e2a6f-1726-42f8-a0cb-85cbf876e9b1.png)

From GamefromScratch

RPicster commented 1 year ago

Hey :) What would be the best way to help? The list at the top is still completely blank. How is the process of porting projects to G4? Just open a PR? Where will the G3 versions of the demos live? Sorry if this has been answered or planned somewhere and I just ask the obvious questions...

InfiniteProductions commented 1 year ago

@RPicster the status has been reset a few weeks ago by @aaronfranke, I've tested again a bunch of demos with various 4.0 release along the way, there was quite a rush on releases and I couldn't catch up and redo all tests for every releases as it should be done, I've fill a file with all the results and status I've got, see my reply above from 3 weeks ago.

If you find an issue and/or have a fix, do not hesitate to fill a PR. You could also test the demos I didn't test or test those which have been checked first again with the last release. I just report editor message from import and runtime warning/error + if it's work or not.

It looks like releases process is slowing down, it would leave us time to test all 89 or so on the very last release if there are enough people to test I guess.

RPicster commented 1 year ago

@InfiniteProductions Ok! Thanks for getting back to me. Now how is support for the 3.x demos planned? 3.x is still LTS, so the demos should not be hidden in some branch or old commit from my pov. Would it make sense to handle them in separate repos?

InfiniteProductions commented 1 year ago

You're welcome.

I've no idea about the support for 3.x demos.

3.x is still LTS, so the demos should not be hidden in some branch or old commit from my pov. Would it make sense to handle them in separate repos?

Branches are not hiding places, there is no point making a separate repository whereas branches are just the right way to handle this case. You can switch to any branch any time.

Calinou commented 1 year ago

There's are 3.x and 3.5 branches now. While we recommend focusing on the master branch, you can still create new demos for the 3.x branch, and we can cherry-pick changes compatible with 3.5.x to the 3.5 branch.

Anutrix commented 1 year ago

Continuous 4.0.x releases is making demos never reach any stability. Waiting for Godot 4 has become Waiting for Godot 4 Demos. Demos aren't few ranks behind Godot. They are few laps behind.

Lack of minimalistic but ready demos for things like 'websocket-minimal' is really make it hard for Devs understand how to use them or understand the new changes. Porting manually becomes harder too.

One drastic idea I can think off is temporary halting Godot's new 2-week release cycle and finishing as much demo upgrades as possible. And resume normal cycle once the demos are in passable state. Then, they can then be improved over time slowly. Making we can even set aside some time for it once every quarter/semester/year for demo-upgrade.

BTW, I am not saying there isn't progress or trying to be rude but maybe we need find a different way than current. Just like above Release-Break idea.

Maybe we need to arrange the demo list from least complex to most complex first.

GeorgeS2019 commented 1 year ago

@Anutrix

Godot is a community effort, FIRST, organize what is basic and missing in Godot4 and raise awareness in the community to get someone making it works in Godot4.

If you are not coding, keep hammering to make others to make the demo(s) happen.

GeorgeS2019 commented 1 year ago

@Anutrix

Maybe we need to arrange the demo list from least complex to most complex first.

If you have an idea to share. => Do it so the Godot management can choose your idea and integrate it.

Calinou commented 1 year ago

One drastic idea I can think off is temporary halting Godot's new 2-week release cycle and finishing as much demo upgrades as possible. And resume normal cycle once the demos are in passable state. Then, they can then be improved over time slowly. Making we can even set aside some time for it once every quarter/semester/year for demo-upgrade.

This is exactly what I did back in January 2023 :slightly_smiling_face:

The list in OP is outdated – a lot of demos could be checked as working in 4.0.2, but they need to be tested first. Also, please review pull requests and test them locally.

InfiniteProductions commented 1 year ago

I believe some coordination would be more than welcome in order to made progress all together without stepping on each other foot :). Maybe take charge of some testing (5, 10, or more demos) on a given version & architecture, report then have a regularly updated post like the tracker, but maybe something every willing participant can update via pull requests.

Issues could be created and assigned to people, but maybe it would need another project just for that, it may worth it although.

aaronfranke commented 1 year ago

@Anutrix I used to be on top of things, but I no longer have an abundance of free time like I used to, so I can't work on the demos. Someone needs to step up and actually do the work. It could be you, or someone you know. Or you could raise awareness on community channels.

There are a lot of people on places Discord that say they want to contribute, and then tell them that Godot needs people to contribute to the demos, but so far nobody has stepped up to actually do the work. I have even offered to pay people money to work on the demos and still nobody has stepped up.

Anutrix commented 1 year ago

One thing that stops me from updating official demos is what amount of changes is okay and what counts as stable. Do I need to it to be running in all 3 rendering drivers. Is running with few warnings are fine?. Should I test with .NET version of Godot too?, etc. I still don't know the answer to some of these questions.

I think many contributors gets discouraged because they don't know what should be basic tests/requirements when they make demo fixes or upgrades. In order words, 'Is my changes for 'Official Demos' good enough?'.

It's much harder than making changes in https://github.com/godotengine/godot code. There we just need fix the bug and check for stability before starting with draft MR. Here, just opening a file will make changes. For example, on just opening websocket_chat in Godot 4.0.2, we see this diff:

$ git diff
diff --git a/networking/websocket_chat/project.godot b/networking/websocket_chat/project.godot
index 68cd0394..44581c17 100644
--- a/networking/websocket_chat/project.godot
+++ b/networking/websocket_chat/project.godot
@@ -8,22 +8,6 @@

 config_version=5

-_global_script_classes=[{
-"base": "Node",
-"class": &"WebSocketClient",
-"language": &"GDScript",
-"path": "res://websocket/WebSocketClient.gd"
-}, {
-"base": "Node",
-"class": &"WebSocketServer",
-"language": &"GDScript",
-"path": "res://websocket/WebSocketServer.gd"
-}]
-_global_script_class_icons={
-"WebSocketClient": "",
-"WebSocketServer": ""
-}
-
 [application]

 config/name="WebSocket Chat Demo"

This scares me as a contributor. Some FAQs in Official Docs saying 'Minor changes in project.godot when opening the project is expected' would be encouraging.

Btw. I was looking for demo guidelines. Do we have any guidelines, FAQs or similar page for 'Contributing to Godot Demo Projects'? The reason my first contribution to a public open-source project was Godot Engine was because of its amazing 'https://docs.godotengine.org/en/latest/contributing/ways_to_contribute.html' section. It even helped me contribute to non-godot public projects.

Can we have something something similar for the Godot Demo Projects? We can start with a simple FAQ page too.

Lastly, I'm interested in getting websocket demos working. I will make an MR if and when I succeed. It will most probably be rough but I guess it can be fixed on first review by maintainer. If all goes well, I will try making more MRs.