Massive Performance Hit with Dynamic Objects on XBOX

For some reason, playing my game on XBOX is just so laggy. It doesn’t lag nearly as much as it does on PC, and it’s the same version. My suspicion is that it’s a Roblox limitation.

The type of lag that I’m having is frame rate dips.

This only happens when I have a sizable map loaded in and something else is happing simultaneously. This happens on specifically on XBOX. For example, setting the CFrame of a single part or SetPrimaryPart of a model on loop cramps the game performance. For Example: My projectile system uses CFrame instead of conventional Roblox physics. So reloading (mag drops) or throwing a grenade put the game into a temporary laggy phase, no matter how many parts these objects are.

However, my helicopter is using Roblox body movers and it still lags.

To see this issue, play this game on XBOX. Simply reload your weapon. You can also pick up a grenade and throw it.

Captures:
Frame rate in corner

Any temporary fixes currently?

4 Likes

Are you setting CFrame on the server or on the client?

If you’re assigning to the CFrame on the server and waiting for it to replicate to the client it’s going to replicate purely as reliable ordered property changes, subject to the replicator send rate. The replicator send rate is slower than any of the stepped or heartbeat callbacks, closer to 20 FPS.

CFrame property assignments also get no interpolation at all, unlike things replicated through physics replication which are automatically interpolated, tweened, and smoothed. Every CFrame change from a property assignment done will clear the physics interpolation data. If you were using physics you would at least get interpolation. Otherwise you’ll have to implement custom replication and interpolate everything yourself in LocalScripts, which is a lot of extra work, both for you and your runtime scripts.

On top of that the XBox is probably nowhere near as powerful of a machine as your PC. Its specs are closer to a low end PC. The main advantage consoles have is fixed hardware and lower level graphics APIs that allow you to optimize some things better than on a conventional PC. When targeting consoles expect to spend some time focusing on general optimization.

2 Likes

All my CFrame and Helicopter Physics is being done on the client.

1 Like

I ran some profiling on your game and I see frame drops when switching weapons mostly. I’m not sure exactly what’s going in the script, but there are really long frames when this happens, up to 37-38ms at times.

The biggest chunk out of the frame is about 27.2ms. This includes a 2.7ms call to Destroy, 1ms call to clone and a 5.4ms call to Parent. Most of the rest of the frame are many calls to HUD, BodyArmorIncrements and ImageColor3, which add up.

If you’re unfamiliar with the microprofiler, you can find more info here - MicroProfiler

Unfortunately, you can’t run the microprofiler on console, but you might be able to see if you see similar, but probably not as long, frame on desktop or in studio.

MicroProfile Capture.html (2.0 MB)

3 Likes

I looked at your example place, and what I see is that you have everything updating on the client on RenderStepped, because of all the updates being in a loop that only yields via RenderStepped:wait(). That means the visual update has to wait for every subsystem in your game to update, including things like that object Destroy() call jmargh pointed out.

The recommended solution I got from maxvee, which hasn’t let me down, is to move nearly all of this to update on Heartbeat, and use RenderStepped only for things that have to move in sync with the camera, like if you have first-person weapons that need to be locked to the player camera and not jittering a frame or two behind. And of course the camera update itself, if it’s custom. But all the other stuff… projectile kinematics calcs and raycasts, the helicopter updates, UI, etc… you don’t want these to block rendering.

Once that’s separated, you can go about timing and profiling each of the things that updates per frame and see what it was that was taking so long for the 'nades and copter.

2 Likes

Yeah I thought of doing this.

I planned on making everything 30 hrtz and only the Camera it 60. I’ll tell you how it goes. Thank you for the help!

Things on Heartbeat will execute at 60Hz too when the computer is capable. The difference is that when the computer can’t keep up with the load on Heartbeat, it won’t immediately take your rendering FPS down with it. None of these fixes will likely help me survive Wave 8.

Can it be in the same loop tho, just not updating as fast? for example

local lastUpdated  = tick()

while true do
Camera:Update()
if (lastUpdated - tick()) > (1/30) then
   Helicopter:Update()
   Nades:Update()
   --etc, etc.
end
game:GetService("RunService").RenderStepped:Wait()
end