Godot: For loop does not work in 3.0 shaders

[efirdc]

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Windows 7, Godot 3 alpha 1, GTX 770, Driver version 378.49

Issue description:
Attempting to use a for loop in a shader:

shader_type canvas_item;

void fragment() {
    for (i = 0; i < 10; i++) {

    }
}

Gives the error: error(4): Expected expression, found: CF_FOR

Unsure if I'm doing something wrong, if this is a bug, or for loops just aren't implemented yet?

[eon-s]

Others, like while, seem to work (and is really easy to do infinite loops while writing conditions).

[reduz]

infinite loops are fine, opengl allows it.
but i think for is missing, will add it as soon as i'm done documenting the
language

On Thu, Aug 24, 2017 at 12:40 AM, eon-s [e-mail] wrote:

Others, like while, seem to work (and is really easy to do infinite loops
while writing conditions).

—
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/10560#issuecomment-324524340,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z23PlURUsrOoVcGXO05xiZmGYO0cSks5sbPDFgaJpZM4O_CWk
.

[eon-s]

@reduz an accidental while(true) kills the system :upside_down_face:

[reduz]

@eon-s Unfortunately detecting this is way too difficult, so you will have to be careful :)

[eon-s]

Can't it use an optional manual compilation? (this may be for another issue, I guess).

[reduz]

@eon-s what is an optional manual compilation?

[eon-s]

@reduz something to toggle off the instant shader compilation while writing it, or at least compile but let apply it manually to avoid system locks while constructing one.

[reduz]

@eon-s I'm not really sure if it's worth it, and i don't like the idea of having to spend time working around problems that won't happen in real use cases. I can easily detect whle(true) without a break, but if you make a while that depends on a uniform (very common case) and that in some cases it can go infinite, there's nothing that can be done. It's better to just wait and see if anyone has real problems with this.

[bojidar-bg]

@reduz Can't we generate something like this __in debug mode__? (psuedocode)

int counter = 0
while(<condition>) {
  if (counter > 100) break
  // or 1000, or 1e5, or any other value that won't be reached without lag anyway
  counter++
  <code>
}

This way, no shader would accidentally break the editor.

[reduz]

@bojidar-bg I thought exactly about that, but it's going to make the shader slower pointlessly