Mate you know how it goes, you need to make 32x32 blocks and put them together I know I know it will take you few months to make a whole map like that instead of few days but yeaaaaaaah good job. :V

Okay, I have engineered something of a fix for static objects.

This really should not be used with objects that are going to move. This hack does do the trick... I think. It does break clicking, verbs, and a hell of a lot more. But for simple background objects, this should at least prevent the flicker.

It's also really, really unoptimized, because reasons.

Without my system:



With my system:



Here's a link to a demo showing an implementation of it.

http://files.byondhome.com/Ter13/bigicontest_src.zip

In order to use it, you need to set big_icon_fix to 1 on the static scenery object. Then, you also need to set the fix_width and fix_height to the number of tiles that the icon takes up on each axis. You can calculate this by: ceil(icon_width/TILE_WIDTH), ceil(icon_height/TILE_HEIGHT).

Ceil means round up, by the way.

Fair warning, it's probably unwise to use this. It's a serious hack.

it basically uses 0 cpu too what more would you optimize?

The more big objects clustered in an area, and the more clients in the world, the worse performance will be.

There are likely ways to ensure that updates don't have to happen as often that they do. Currently, it has to loop through all "fixed" objects every time the client moves.

There are also likely major problems with it and corner cases where it's going to break shit... I really just wanted to prove the concept.

damn, looks like it does use too much CPU for a multiplayer game

Yep. Not much hope except for Lummox to fix it.

Ter that's brilliant that you've managed to solve that issue (to the best ability that we can in softcode), But are you aware that a for each in DM is faster than an iteration and then accessing the index of the list with that iteration?

for example:


(Not sure why DM's in+to+step operators are faster than an i++ loop, they just are, I know you have more knowledge of Byond's insides that I do and if you have any hints or ideas about it I'd love to hear them!)

Anyways a structure like this:


Appears a lot in your demo, to the point where the performance differences here may be enough to have an impact

For example, a profile of 1000 loops of a list of len 1000



Loops from the above demo:
(All that's missing is a len print verb and a for(var/i in 1 to fillamt) loop for populating the list)



Another optimisation that can be applied on top of the above is something that I've taken to calling an "istypeless-forloop", as you know specifying a type in a for header



allows byond to filter by that type, but if the list only contains that type (or prototypes of the type that has the var you need to access) then the filtering byond does is costly and needless. Of course this optimisation is VERY situational, requiring the list be of specific types


And with all the above optimisations, your above structure looks like this:



tl;dr Great demo, just take a look at the above optimisations and see if it alleviates some of the cost, as part of my work maintaining and optimising /tg/station SS13, these tricks have been VERY helpful.

Ter13 wrote:

Ter that's brilliant that you've managed to solve that issue (to the best ability that we can in softcode), But are you aware that a for each in DM is faster than an iteration and then accessing the index of the list with that iteration?

That's interesting, because The last person from /tg/ that talked to me about for..in told me it is actually slower than the for..in..to.. pattern. =/

Who were they? I'll bap them on the noggin :P


is faster than:

But DM isn't the best at indexed list access, so the for each wins out over these two when dealing with lists specifically

Surprisingly, "for = to" is faster than "for in to". (operators are interchangeable in terms of using the to operator)

I believe the in operator may be doing type checking for the value that follows it, thus making the "for in" slightly faster than "for in to". However, the case for the looping through indexes is so you can edit the list as you go, while the for each loop makes a copy of the list.

Exactly what I said it was: Not forgotten, but in limbo while I work on other important priorities. It is not a trivial thing to fix.

Zasif wrote:

How is this not a trivial thing to fix? a bug thats been around for at least 5 years, are you joking me? This bug makes things alot harder for developers that use large icons to actually work on those projects. Not trivial my hot butty!

"Non-trivial" does not mean "non-important". This bug is very important to me, and frankly I think it's going to end up being a much higher priority as large lighting objects and parallax backgrounds start to make their way into more games.

No, "non-trivial" means it's darned difficult to fix. Not impossible, just difficult. I have a rough idea of how to approach it, but it's going to take time to flesh that out, and in particular it will take dedicated time to work on it.

Zasif wrote:

I remeber this not been an issue in the more early versions of byond like 504-505, maybe you want to take a look back and see what has been changed to 506-507 that made the bug show up.

No, it's always been an issue. The code governing this hasn't changed.