Set limit framerate (LN for Get FPS)

Is it possible to do this? I look through the sources, but I can’t find anything on this topic. I understand that the value is set to 60, but I want flexibility =)

I’ve seen this post and commit. But the code of the App class has changed and there is no longer such a possibility. Therefore, after such changes, I’m interested in the ability to configure (set 30 fps, for example) or not? So far, my searches and experiments have yielded no results.


I think it is not possible anymore to change the frame time but in iron/system/Time.hx there is some references to display frequency.

I think since the VSync uses the display frequency to limit the frame time, maybe you can do a workaround and “fake” the display frequency to 30. You may open another issue for this.

I also would like to change the fps limit, 60 fps in mobile is not a good idea :confused:

Good look!

While looking for a way to set the FPS limit, I decided to output the current value through a logical node. This is sometimes more convenient than printing the entire debug console.



The FPS change situation is funny:

  1. Kha has a Scheduler class to which tasks are added to be executed (update function from Iron).
    When the task starts, the following code is executed:

    vsync = Window.get(0).vSynced;
    var hz = Display.primary.frequency;
    if (hz >= 57 && hz <= 63) hz = 60;
    onedifhz = 1.0 / hz;
  • The vsync variable is a setting from the Flags panel and is responsible for considering the frame limit or not.
  • Further, the frequency value (as it is determined, I have not yet found, but I mean there just a constant for each platform).
  • Next, it calculates how many milliseconds must elapse between frames.

In the executeFrame() function, it is checked that the required time interval has passed and the task is completed.
In the code of each platform (in the Kha/Backends folder) this feature is taken into account.
It turns out that without upgrading Kha, you cannot change the FPS.

  1. You can slightly modify the iron.system.Time class and change the frequency (but within the range, as I understand it, from 0 to 60, due to the Kha limitation).

The funny thing is that in both cases, the DebugConsole and the FPS logical node will output 60 frames. I believe that this is due to parallel processes (updating, rendering in a separate thread) and artificially underestimating is used, and real time is used for calculating frames per second (iron.system.Time.realDelta, iron.App.renderPathTime, which use kha.Scheduler.realTime()).

Demo: web

Kha I do not want to modify, not the fact that the developers will like it. Then it turns out to restrict through Iron with restrictions.
And the DebugConsole and my new node need to be redone.


Studying and experimenting with Kha and setting the FPS limit, I found training material and got interesting results. Looking here, you can see how the update and render function are assigned.
The update function is assigned through the Scheduler and you can specify the period of its call. Thus, you can specify how many times per second to execute it.
And the render function is assigned via kha.System.notifyOnFrames(). Further, as I wrote earlier, in implementations for each platform, drawing is performed at its event. For example, Krom:

private static function renderCallback (): Void {
    Scheduler.executeFrame ();
    System.render ([framebuffer]);

As a result, we can execute the update function with a given frequency from Iron, but render will be drawn 60 times (or as many times as it can with VSync off).

Can anyone tell me how, without interfering with Kha, you can replace the value in Display.primary.frequency?
Then executeFrame() will be executed on the specified value.

1 Like

As a result, after another study of the source codes, Kha came to the following conclusions:

  • the render function, which is registered for execution so kha.System.notifyOnFrames(render), in any case, either 60 (enabling the VSync option) will be executed, or how much the PC pulls. Because it depends on the call event on the chosen platform;

  • adds the update function to the Scheduler and you can specify the frequency of more execution. You can specify a value of 30 and it turns out that the scene is render 2 times, and updated 1 time. Because neither are executed in parallel.
    To specify this setting, either in the Display class (it is located in ArmorySDK\Kha\Backends\[target_name]\kha), you need to specify a value for the platform in the get_frequency() function. Or, in the Time class of the Iron engine (ArmorySDK\iron\Sources\iron\system) in the init() function, specify the frequency value instead of what is there.

To make the render function run with the same frequency as update, you can register an “empty function” in kha.System.notifyOnFrames() (only to store the value from the frames[0] array passed in the framebuffer field). And execute the real function in update. In this case, the empty function will still be executed 60 times, but the “workers” will only be 30.

And for the “correct” display of the FPS value in the DebugConsole and in the Get FPS node, it is necessary to correct that the time during the calculation was used from Schedule, and not the real one (which will produce 60 FPS).

I haven’t been able to find any other way to limit the frames per second other than upgrading the Iron. In this case, you can display settings in the nodes or the Blender interface. But this is a limitation at the level of one of the layers. Iron developers may not like this option.

I did not find other ways without changing Kha. And Kha is difficult to rule. The developers are in no hurry to introduce such a possibility (judging by the topics on the forum ( and the request in git (


Interesting findings!

I haven’t been able to find any other way to limit the frames per second other than upgrading the Iron. In this case, you can display settings in the nodes or the Blender interface. But this is a limitation at the level of one of the layers. Iron developers may not like this option.

I would suggest opening an issue in the iron repo to see what lubos thinks of this and if something can be done from Iron.

Done (