I would like to get an opinion in regard of this, some of my current project code uses functions that are activated within the _process function, myself favoring it over signals because it would make the whole code run faster with less variables, however, i've read that signals would be less resource-intensive, no matter how many signals an object has. Right now i have no runtime problems with my project, however, given that _process uses CPU cycles instead of waiting for a signal, that might change later on, hence this discussion. Is it better to use signals rather than allocating functions to _process?, or will "n" amount of signals "clog" the project?. Needless to say, there's no "stupid" reply, i would really like to hear your opinions on this.

    Xrayleader Signal emissions are just function calls. Each time a signal is emitted, the cost is execution time of all connected functions. If the signal is not emitted in a frame, the performance cost is near zero. Memory footprint of signal connections is also negligible.

    Signals are event driven, while _process() runs every frame no matter what. They are meant to deal with different types of things. The code that needs to run every frame should go into _process(). On the other hand, the code that you want to execute only upon some event - goes into signal handlers.

    So there is no actual "vs" between signals and _process()

      Xrayleader Well, without having benchmarked it I'd say that for example declaring 100 signals and sending one of the signals at the proper time is a lot more efficient than having to check 100 conditions in _process() which as @xyz already said gets called every single frame. Meaning you do a lot of work every single frame.

      So without knowing the code my gut feeling would be to go with signals unless for some reason this would turn your code into some horrible mess. But in that case there is probably something going wrong anyways.

        Xrayleader it depends, signals and process sort of do different things.

        A signal is good for when you need something to happen in reaction to something else. It's useful, say, if you want a sprite to fade out after an animation ends (like an enemy getting defeated.) I prefer to use signals when I have events that "chain" together or need a specific sequence, because then you can connect them all without too complex of logic (though you should know how to connect in code, especially if you use a lot of instancing).

        process(delta) has already been discussed at length here but it's not a bad idea to use it, especially if there's a piece of logic that needs to be "heard" that is outside of the typical signal connections. Of course, you can always make custom signals as well to trigger whenever you need them with signal.

        Generally though, I use process whenever I need something occurring every frame - like say, a stamina meter refilling. You'd plug:

        func _process(delta):
    if _stamina < _maxStamina:
        _stamina+=_stamRegenRate

        That works per frame. What I will say is if you're starting out, and it works, just do it. Programming sometimes requires creative solutions.

        But be real careful when you work per frame, especially if you're instancing a lot of objects, or tying any resource loading to it. 'process' may also be too fast for some functions, or you may not want to repeat certain functions. It really depends on the project.

        • Toxe replied to this.

            SnapCracklins Generally though, I use process whenever I need something occurring every frame - like say, a stamina meter refilling. You'd plug:

            func _process(delta):
            if _stamina < _maxStamina:
            stamina+=stamRegenRate

            That works per frame.

            But is also dependent on frame rate so you would need to multiply _stamRegenRate with delta.

                Toxe Yes that's certainly a way to do it. But could also implement it via other means such as lerps or tweens such that there would be a delay after using stamina before it starts regenerating or whatever. It certainly can be done in process but it's perhaps not the best example since it doesn't strictly have to be done there.

                • Toxe replied to this.

                    Megalomaniak Oh I am not saying that it should be done in _process(), I was just pointing out that the above code would be frame rate dependent and needed some delta adjustments.

                      I'd say, as a rule of thumb, do as little as possible in _process(). If something can be done any other way - do it that other way.

                        xyz Great advice. I would recommend this as your start out. In most cases this will lead you down the correct path.

                          Well, I didn't really mean to say or imply that you shouldn't do it in process either. Just that you should always weigh the pros and cons of doing things in process.

                          Xrayleader It really depends on what you want to achieve. Personaly, my current game uses 0 _process(). It would simplify my code quite a lot but process is fired every frame. Unless you are doing something that requires you to check every frame, try not to use it.

                          But, if your game is not generating any problems, why the need to optimize it? You can fix the bottleneck if there is one but optimizing before it is needed is just waste of time.

                          But my general rule of thumb is: Use events for "almost" everything. They reduce the amount of bugs, crashes, problems in the long run and allow the code to be decoupled, etc. Use _process() for things that require to be updated every frame (FPS movement as an example).

                          Those are just my two cents.

                            Thanks for that @Toxe - I had the delta on my movements but didn't realize I had forgot in some processes.

                            I generally try to use process only when there's a variable I want to update in real time. I don't ever attach anything hefty (like say instancing) to each frame. Mainly just light number updates.