Rendering issues causing lag, need help.

[Ben_Sherman]

What's up everyone, so I've recently discovered that one of my scripts is causing massive lag for people. As it never caused it for me I never discovered it till now 2 months later. The problem here is that the radar created is causing lag as it's being rendered and on top that it has a loop fetching the server icons/blips which are causing the problems. Since I'm out of ideas how to resolve this maybe someone here knows what to do.

The main issue is that this loop is being called once per frame, 60 frames * 60 icons/blips = 3600 times per second, you might see the problem I'm having now, I've tried limiting it to nearest blips/icons however since I don't know how to do this from the loop itself without looping through all of them it doesn't really have an impact. The only solution I've actually found to this is disabling the loop itself but then I got no blips/icons which I kinda need.

I've wrapped my head around this all night and can't seem to figure a solution out without loosing FPS or losing the blips, maybe one here is smarter then me.

for _, blip in ipairs(getElementsByType('blip')) do -- PROBLEM IS THIS
    local blipX, blipY, blipZ = getElementPosition(blip)
    
    if (localPlayer ~= getElementAttachedTo(blip) and getElementInterior(localPlayer) == getElementInterior(blip) and getElementDimension(localPlayer) == getElementDimension(blip)) then
        local blipDistance = getDistanceBetweenPoints2D(blipX, blipY, playerX, playerY)
        local blipRotation = math.deg(-getVectorRotation(playerX, playerY, blipX, blipY) - (-pRotation)) - 180
        local blipRadius = math.min((blipDistance / (streamDistance * Minimap.CurrentZoom)) * Minimap.NormalTargetSize, Minimap.NormalTargetSize)
        local distanceX, distanceY = getPointFromDistanceRotation(0, 0, blipRadius, blipRotation)
        
        local blipSettings = {
            ['color'] = {255, 255, 255, 255},
            ['size'] = getElementData(blip, 'blipSize') or 20,
            ['exclusive'] = getElementData(blip, 'exclusiveBlip') or false,
            ['icon'] = getBlipIcon ( blip ) or 'target'
        }
        
        local blipX, blipY = Minimap.NormalTargetSize * 1.5 + (distanceX - (blipSettings['size'] / 2)), Minimap.NormalTargetSize * 1.5 + (distanceY - (blipSettings['size'] / 2))
        local calculatedX, calculatedY = ((Minimap.PosX + (Minimap.Width / 2)) - (blipSettings['size'] / 2)) + (blipX - (Minimap.NormalTargetSize * 1.5) + (blipSettings['size'] / 2)), (((Minimap.PosY + (Minimap.Height / 2)) - (blipSettings['size'] / 2)) + (blipY - (Minimap.NormalTargetSize * 1.5) + (blipSettings['size'] / 2)))
        
        if (blipSettings['icon'] == 'target' or blipSettings['icon'] == 'waypoint' or blipSettings['icon'] == 0 or blipSettings['icon'] == 1) then
            blipSettings['color'] = {getBlipColor(blip)}
        end
        
        if (blipSettings['exclusive'] == true) then
            blipX = math.max(blipX + (Minimap.PosX - calculatedX), math.min(blipX + (Minimap.PosX + Minimap.Width - blipSettings['size'] - calculatedX), blipX))
            blipY = math.max(blipY + (Minimap.PosY - calculatedY), math.min(blipY + (Minimap.PosY + Minimap.Height - blipSettings['size'] - 25 - calculatedY), blipY))
        end
        
        dxSetBlendMode('modulate_add')
        dxDrawImage(blipX, blipY, blipSettings['size'], blipSettings['size'], 'files/images/blips/' .. blipSettings['icon'] .. '.png', 0, 0, 0, tocolor(blipSettings['color'][1], blipSettings['color'][2], blipSettings['color'][3], blipSettings['color'][4]), false)
        dxSetBlendMode('blend')
    end
end

 

[Mr_Moose]

Well there's a few things you can do to optimize but I can't guarantee that it would make any big difference, but it's still worth a try tho. First of all, in this case you can replace ipairs with pairs which is slightly faster. As long as you don't need to process your blips in a certain order that change should be safe. 

for _, blip in pairs(getElementsByType('blip', resourceRoot, true)) do

The function getElementsByType can also be instructed to look into this resource only (or further down the element tree), in case that you have blips in other resources that shouldn't be processed by this loop. Last but not least since this appears to handle the mini map, you may want to look for streamed in blips only as well (all blips within a 180m radius from a player).  

[xyzii]

Loop through all the blips when player joins or the script restarts and insert them into a clientside table with the properties needed. Then loop through that table on client?

Edited March 15, 2017 by xyzii

[Ben_Sherman]

On 2017-03-15 at 07:37, Mr_Moose said:

Well there's a few things you can do to optimize but I can't guarantee that it would make any big difference, but it's still worth a try tho. First of all, in this case you can replace ipairs with pairs which is slightly faster. As long as you don't need to process your blips in a certain order that change should be safe. 

for _, blip in pairs(getElementsByType('blip', resourceRoot, true)) do

The function getElementsByType can also be instructed to look into this resource only (or further down the element tree), in case that you have blips in other resources that shouldn't be processed by this loop. Last but not least since this appears to handle the mini map, you may want to look for streamed in blips only as well (all blips within a 180m radius from a player).  

 

A little update, I've tested restricting it to one resource right now just as a test and that didn't drop the FPS to much however the problem is that I got tons of resources with creating blips dynamically based on what it is. Tried the streamed in function doesn't really do anything as all blips are still appearing even if I've set the blip distance to 60 when it was created.

I'm clue less how to do it.

[Mr_Moose]

Processing blips all over the map is a heavy task, maybe you could process blips within a distance of 180 distance units only (same size as the radar area). Try replacing line 4-5:

if (localPlayer ~= getElementAttachedTo(blip) and getElementInterior(localPlayer) == getElementInterior(blip) and getElementDimension(localPlayer) == getElementDimension(blip)) then
        local blipDistance = getDistanceBetweenPoints2D(blipX, blipY, playerX, playerY)

with this:

local blipDistance = getDistanceBetweenPoints2D(blipX, blipY, playerX, playerY)
if blipDistance < 180 and (localPlayer ~= getElementAttachedTo(blip) and getElementInterior(localPlayer) == getElementInterior(blip) and getElementDimension(localPlayer) == getElementDimension(blip)) then
        

 

[Ben_Sherman]

32 minutes ago, Mr_Moose said:

Processing blips all over the map is a heavy task, maybe you could process blips within a distance of 180 distance units only (same size as the radar area). Try replacing line 4-5:

if (localPlayer ~= getElementAttachedTo(blip) and getElementInterior(localPlayer) == getElementInterior(blip) and getElementDimension(localPlayer) == getElementDimension(blip)) then
        local blipDistance = getDistanceBetweenPoints2D(blipX, blipY, playerX, playerY)

with this:

local blipDistance = getDistanceBetweenPoints2D(blipX, blipY, playerX, playerY)
if blipDistance < 180 and (localPlayer ~= getElementAttachedTo(blip) and getElementInterior(localPlayer) == getElementInterior(blip) and getElementDimension(localPlayer) == getElementDimension(blip)) then
        

 

 

Oh you mean like that, tested a theory of that before however that still hits the performance which is basically just the loop itself that does it. The only way to reduce it is either removing the icons blips itself so there is like 10 of them for example or find a way to add the the nearest icons to the table.

[Mr_Moose]

That's strange, I was somehow convinced that all those calculations was the reason for the FPS drops. Have you considered using icon shaders on default blips instead? from what I can see this is some kind resource for managing custom blips, and those are usually pretty resource hungry no matter how you implement them. 

[Captain Cody]

The loop doesn't cause the lag, it's the calculations as Mr_Moose stated