Limit frame rate code-side only

[Oen44]

Hi,

I've made fading and floating text effect like this:

It's cool, I like how it ended up but... There is framerate issue. When making this, I was at 75FPS cap (VSync) and after unlocking to unlimited FPS, text started moving way too fast.

Here is the code

@SubscribeEvent
public void onRenderOverlayText(RenderGameOverlayEvent.Text event) {
	ScaledResolution sr = event.getResolution();
	EntityPlayer player = Minecraft.getMinecraft().player;
  
	GL11.glPushMatrix();
	GL11.glScalef(1.0F, 1.0F, 1.0F);

	for (int i = 0; i < 12; i++) {
		if (!this.isVisible(i))
			continue;

		this.alpha[i] -= 3;

		this.height[i] += 0.6f;
		if (this.height[i] > 50.0f) {
			this.hide(i);
			continue;
		}

		Minecraft.getMinecraft().fontRenderer.drawStringWithShadow("+" + this.xp[i] + " XP",
				sr.getScaledWidth() / 2 + 50, sr.getScaledHeight() / 2 - this.height[i],
				0xFFFFFF | (this.alpha[i] << 24));

		GL11.glScalef(0.5f, 0.5f, 0.5f);
		Minecraft.getMinecraft().renderEngine.bindTexture(icon);
		this.drawTexturedModalRect((sr.getScaledWidth() / 2 + 32) * 2,
				((sr.getScaledHeight() / 2) - 5 - this.height[i]) * 2, i * 32, (i > 7 ? 1 : 0) * 32, 32, 32);
	}

	GL11.glPopMatrix();
}

 

Is there any way to make this run at same pace? Like deltaTime?

Edited August 15, 2018 by Oen44

[Draco18s]

6 minutes ago, Oen44 said:

this.height[i] += 0.6f;

You need to multiply this value by the deltaTime between frames (after dividing out the deltaTime at 75 fps).

I'm not sure where you'd get that value, though.

[Oen44]

long oldTime = newTime;
long newTime = Minecraft.getMinecraft().getSystemTime();
long deltaTime = newTime - oldTime;

deltaTime ready.

this.alpha[i] -= 0.3 * deltaTime;
this.height[i] += 0.06f * deltaTime;

Calculations ready.

 

Working perfectly

[jabelar]

Doing your own delta time works, but there is another more common approach which I figured is worth mentioning. The game logic runs in a loop that "ticks" 20 frames per second. The render refresh rate can vary depending on your monitor, settings and power of your GPU.

 

So whenever you're doing animations in Minecraft you should set the positions and angles based on the game ticks, not the refresh rate. So you would really increment the position every tick rather than every event (which fires at the refresh rate). However, doing that has the side effect that it will look a bit jerky because it will only update position 20 times per second which is a bit less than needed for perception of smooth motion (traditional movie film used 24 fps). So to smooth it out, there is the concept of "partial ticks" that are passed to the rendering methods (and events).

 

So an alternative, arguably more common, way to do animations is to update the position using the ticks plus a bit of adjustment using the partial tick. For example, the game overlay event has a getPartialTicks() method to help with this.

 

Just thought you'd be interested. Point is that partial ticks are used to communicate difference between refresh rate and tick rate and are commonly used to control animation speed.

[Oen44]

14 minutes ago, jabelar said:

Doing your own delta time works, but there is another more common approach which I figured is worth mentioning. The game logic runs in a loop that "ticks" 20 frames per second. The render refresh rate can vary depending on your monitor, settings and power of your GPU.

 

So whenever you're doing animations in Minecraft you should set the positions and angles based on the game ticks, not the refresh rate. So you would really increment the position every tick rather than every event (which fires at the refresh rate). However, doing that has the side effect that it will look a bit jerky because it will only update position 20 times per second which is a bit less than needed for perception of smooth motion (traditional movie film used 24 fps). So to smooth it out, there is the concept of "partial ticks" that are passed to the rendering methods (and events).

 

So an alternative, arguably more common, way to do animations is to update the position using the ticks plus a bit of adjustment using the partial tick. For example, the game overlay event has a getPartialTicks() method to help with this.

 

Just thought you'd be interested. Point is that partial ticks are used to communicate difference between refresh rate and tick rate and are commonly used to control animation speed.

So how ticks work compared to deltaTime?

Lower FPS (30):

Ticks - text is adapting to FPS and moves slow - not cool

Delta - text is smooth as for such low FPS and stays the same time as with high FPS - what I want

 

Higher FPS (around 600):

Ticks - text is smooth and very fast, again, adapting to FPS - not cool

Delta - text is smooth, perfect pace - what I want

 

Conclusion? Ticks are not good for that kind of animations.

Edited August 15, 2018 by Oen44

[Oen44]

2 minutes ago, diesieben07 said:

I don't think you understand how ticks work. Ticks happen at a constant rate, regardless of FPS.

That doesn't change anything. Ticks are not helpful here, it's just looking bad.

[Animefan8888]

10 minutes ago, Oen44 said:

That doesn't change anything. Ticks are not helpful here, it's just looking bad.

Since they happen at a set period of time after each other the game has a deltaTime(partialTicks) variable between each tick that is used for rendering things smoothly. So the game would update the position as to where it should be every tick and then render at that position with the partialTicks. Though your way of doing it works this is just the way minecraft handles these things.

[Oen44]

1 hour ago, diesieben07 said:

If it looks bad, then you are doing something wrong.

All I did was

this.alpha[i] -= (int) (0.4f * event.getPartialTicks());
this.height[i] += 0.1f * event.getPartialTicks();

And it's very slow on low FPS and getting faster with more FPS.

 

1 hour ago, diesieben07 said:

It is a very simple process:

float currentValue = 0
float prevValue = 0

tick() { // 20 times a second, always, that's what ticks are
    prevValue = currentValue;
    currentValue = (currentValue + 1) % 100;
}

render(float partialTicks) {
    float actual = prevValue + (currentValue - prevValue) * partialTicks;
    // render at position actual
}

Yeah, no idea where to put prevValue and currentValue. Should I make thread like this?

ScheduledExecutorService exec = Executors.newSingleThreadScheduledExecutor();
exec.scheduleAtFixedRate(new Runnable() {
  @Override
  public void run() {
    prevValue = currentValue;
    currentValue = (currentValue + 1) % 100;
  }
}, 0, 20, TimeUnit.SECONDS);

 

I just want to check how is that going to look like with what you wrote.

The thing is that RenderGameOverlayEvent is executed more times based on FPS so deltaTime is doing something to balance and it's easy to accomplish.

Edited August 15, 2018 by Oen44

[jabelar]

Maybe this would be clearer. 

 

In a tick handling event like ClientTickEvent, in one phase of that event, you would update the position in a public static field. This would have a very regular steady movement.

 

In the render handling event, you would get the position from that public static field and add a multiple of the partial ticks times the increment. 

 

Note that the tick value can be also updated in other ways. For example, the world keeps track of total time, so you could record the world time when the GUI was just opened and then calculate how many ticks it was open in the render event. 

 

I didn't mean to cause confusion. Just wanted to point out the way Minecraft normally handles the conversion from ticks to render frames for animations.

[Oen44]

15 minutes ago, diesieben07 said:

RenderGameOverlayEvent (careful: this fires many many times every frame!) is the render part in my code. You would need ClientTickEvent (check TickEvent#phase or your code will run twice per tick) for the tick part. 

Of course there is TickEvent... I should have think about that before, ohh my.

 

float prevValue;
float currentValue;

@SubscribeEvent
public void onClientTick(ClientTickEvent event) {
	if(event.phase == Phase.END) {
		prevValue = currentValue;
		currentValue = (currentValue + 1) % 100;
	}
}

float actual = prevValue + (currentValue - prevValue) * event.getPartialTicks(); // in RenderGameOverlayEvent.Text

Well... It's not working well. It's starting slow and then goes very fast and then slow again and so on (because of modulo i guess).

Edited August 15, 2018 by Oen44

[jabelar]

Not quite. If you assign previous value to current value, the increase current value and take modulo, then every once in a while the prev value is going to be way higher. Basically the previous value will roll over to zero one tick after the current value. 

 

What it should be is more like this:

- forget the previous value, you just need current value. So start current value at zero, and keep your line where you add one and do modulo. So current value is going to cycle from 0 to 99 over and over.

- just add partial ticks to current value. That will give the total number of ticks (the current value has the whole number of ticks, plus the partial ticks).

- multiply that result by whatever speed you want.

[Oen44]

Thanks for the help but I'll stay with deltaTime.

Can be closed