I am currently coding a module that lets you create floating “E” GUIs that the user can interact with similar to that in Jailbreak / Adopt me.
To create a floating GUI, you give the module:
- A part for it to follow
- Text to display by its side
- A function to run when it is triggered
An “E” GUI is represented by an ImageLabel in the PlayerGUI.
The system currently works as follows:
Each “E” circle is represented by an object held in a table. Every RenderStepped, that table is iterated and any circles within X studs of the player are displayed using :WorldToScreenPoint()
Circles too far away are hidden.
However, this can prove inefficient when the player has a large number of floating GUI objects that exist in the table. It will be regularly processing GUI objects that are incredibly far away, causing performance issues.
I have a few ideas on how to fix this issue:
Region 3
I could iterate through all the parts within 15 studs of the player and check if any of them are a property of one of the GUI objects.
However, this would require a nested for loop, one of which would check every existing “E” GUI.
So I am not as sure about its performance.
Billboard GUIs
Though these provide the functionality I need, with a distance parameter, I would ideally like to refrain from using them as the current PlayerGUIs I am using give me a lot more control and are integrated with other parts of my code.
I also do not like bits of the player UI floating around inside workspace. (ik i’m very stubborn)
Though I may just have to just give in and use Billboard GUIs instead of re-inventing the wheel, any advice on making the Surface GUI approach more efficient would be greatly appreciated!
Bonus Question
Say I used any of the above methods and there were 100+ GUI buttons all with functions connected to their Clicked events. Would this largely effect the performance of users on lower end devices due to large memory being used?