Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose disable_render_loop property to GDScript #39541

Merged
merged 1 commit into from
Jun 16, 2020

Conversation

rsubtil
Copy link
Contributor

@rsubtil rsubtil commented Jun 14, 2020

Exposes the disable_render_loop property from main.cpp to GDScript.

I've put the new code on VisualServer as it felt the most logic class to put to.

@rsubtil rsubtil requested a review from a team as a code owner June 14, 2020 17:10
@samdze
Copy link
Contributor

samdze commented Jun 14, 2020

Maybe it is better to rename the property render_loop_enabled and the corresponding getter and setter is_render_loop_enabled and set_render_loop_enabled?

@rsubtil
Copy link
Contributor Author

rsubtil commented Jun 14, 2020

@samdze yeah it looks better indeed. I sticked with the existing variable for some reason 😛

@Calinou Calinou added cherrypick:3.x Considered for cherry-picking into a future 3.x release enhancement topic:rendering labels Jun 14, 2020
@Calinou Calinou added this to the 4.0 milestone Jun 14, 2020
@rsubtil rsubtil force-pushed the feature/disable-rendering branch from 4026d1b to 97ed09f Compare June 14, 2020 17:48
@@ -47,6 +47,7 @@ class RenderingServer : public Object {
static RenderingServer *singleton;

int mm_policy;
bool render_loop_enabled;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be initialized.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is implicitly initialized from main.cpp, but should it be more explicit then? And if yes, should I do it on the header or on the constructor?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be explicitly initialized here, in the header.

Disabling the render loop is an edge use case, so the default should be that it's enabled.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@akien-mga
Copy link
Member

Can you explain what's your use case?

@rsubtil
Copy link
Contributor Author

rsubtil commented Jun 15, 2020

Sure. My use case is for a integration testing framework I'm developing, where a user "records" a gameplay session that saves all the input given, and a few screenshots. Running the test is running the game with the input supplied, and comparing the screenshots to see if they suffered many changes.

Do to this, I would use this property to disable rendering and speed up a lot of the logic processing, and force_draw() every few frames to get the screenshots I'll later compare.

There's also the aforemention of being useful to get data for an AI/machine learning system, as noted #1731 and here

@rsubtil rsubtil force-pushed the feature/disable-rendering branch from 97ed09f to d001a06 Compare June 15, 2020 11:07
@rsubtil rsubtil force-pushed the feature/disable-rendering branch from d001a06 to 46b2689 Compare June 16, 2020 09:39
@@ -1895,6 +1895,10 @@ void RenderingServer::_bind_methods() {
ClassDB::bind_method(D_METHOD("has_os_feature", "feature"), &RenderingServer::has_os_feature);
ClassDB::bind_method(D_METHOD("set_debug_generate_wireframes", "generate"), &RenderingServer::set_debug_generate_wireframes);

ClassDB::bind_method(D_METHOD("is_render_loop_enabled"), &RenderingServer::is_render_loop_enabled);
ClassDB::bind_method(D_METHOD("set_render_loop_enabled", "render_loop_enabled"), &RenderingServer::set_render_loop_enabled);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make the argument only enable, otherwise it's too redundant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah sorry, forgot about that binding as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@rsubtil rsubtil force-pushed the feature/disable-rendering branch from 46b2689 to 03879a5 Compare June 16, 2020 14:44
@akien-mga akien-mga merged commit 93d7902 into godotengine:master Jun 16, 2020
@akien-mga
Copy link
Member

Thanks!

@Xrayez
Copy link
Contributor

Xrayez commented Jun 17, 2020

I'll link a proposal of mine so that this feature doesn't seem too corner case: godotengine/godot-proposals#104 (see "Use case: recording input states for playback" section).

@akien-mga
Copy link
Member

This can't be cherry-picked trivially as beyond the VisualServer -> RenderingServer rename, the main.cpp init differs too. If this is wanted for 3.2, a dedicated PR should be made.

@akien-mga akien-mga removed the cherrypick:3.x Considered for cherry-picking into a future 3.x release label Jun 18, 2020
@rsubtil
Copy link
Contributor Author

rsubtil commented Jun 18, 2020

This can't be cherry-picked trivially as beyond the VisualServer -> RenderingServer rename, the main.cpp init differs too. If this is wanted for 3.2, a dedicated PR should be made.

I thought as much. In that case I'll re-implement it for the 3.2 branch

@rsubtil rsubtil deleted the feature/disable-rendering branch June 18, 2020 10:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants