FPS drops when I add an overlay (health bar) to my camera view? (UPBGE)

Hello, when I run my game it plays at 30fps which is fine, but when I add a health bar overlay this drops down to 20fps for some reason. Is there any way of having an overlay in camera view without a significant performance drop? Thanks

Answered already to your question on Blender Stack Exchange:

https://blender.stackexchange.com/a/248566/123064

1 Like

You use standart setup game engine? if you use on vsync and 4x or 16x samples FPS fall to 15-20 frame per second, if off vsync and assign for samples 2x and restrict animation frame to 60 fps this setups get for you stability game. If you add in you game scene standalone scenes fps always fall down but this happen only one round and next frames fps return to stability - maybe in you standalone scene somebody working always? true run sensors or hard logic or script make error - need check objects in standalone scene, and last - you add you standalone scene only one touch? if add scene always console make message warning - but scenes add only one exemplar

1 Like

it will do unnecessary loop if you use “always” logic brick to overlay collection
and it will be very effected to framerate.

what you need to do is let active scene be overlaid just 1 time when game starts

I recommend you to register HUD collection as a component of character
because it will be easy to connect character data to HUD, and update just some part of HUD when some activity of character was triggered.

the result is I can keep framerate at 35-40 fps

we can use a 2d filter / a few position vectors / an offscreen buffer to draw elements in post

I have a example of this in resources.

this uses almost no resources :smiley:

1 Like

Thank you master.

Could I use python instead of C in 2D custom 2Dfilter script?

This performance drop relating to overlays is really disturbing. I’m currently testing my own HUD, and I can say, my average framerate drops from 60 down to 17fps or even lower with an armature in the background. This is a massive regression, and something you’d expect from the early 80’s in terms of a 3D game engine, not the 2020’s! If 2.79 and 0.2.5 can maintain 60fps with an overlay, why can’t UPBGE 0.3+? It’s almost as if Collections were either never designed this way or that the Collection actuator is severely broken.

Adding a collection as an overlay can crash UPBGE proving my point that the Collection actuator is at fault here, and needs to have it’s code tested and redesigned. I hope UPBGE 0.42 for macOS fixes this! I think the Collection Actuator was rushed here, as evidenced by how it’s Overlay feature does not work properly.

Another reason this proves my point that the Collection actuator was rushed is that it cannot even function on the same camera, forcing you to use another camera or the overlay’s camera.

To the UPBGE developers: This is a critical issue you need to fix with overlays. In order to really make your game engine shine, you must properly fix all severe performance issues, use GPU-based armature skinning, and implement proper Collection-based overlays with the actuator. It’s no wonder people use the legacy 0.2.5.0 game engine.

there is a bunch of settings in overlay camera for performance*

this would not work if there was 1 camera *

I have found out that UVWarp modifiers also slow UPBGE a lot. Only activate when needed. You can implement Python checks to activate/deactivate them.

This helps prevent a strain on the performance.

Unfortunately, your working mouse atlas cannot be used for Apple Silicon until Metal is fully integrated into UPBGE - it just says that the shader is not supported by the chip.

I think adding more input types and ways to feed data to composition nodes could solve ui.

We can redo the mouse atlas in it, making it gpu egnostic.