Optimizing showimgs?

[jake13jake]

I really think there's a bit of need for documentation on how to best optimize the use of showimgs. It tends to take a lot of processor time when I use them in particular ways. How do you optimize using showimgs?

[_Z3phyr_]

My best guess is a for loop or a particle effect?

for (i=0;i<max;i++) { showimg(i,"imagename.png",x,y); }

[xXziroXx]

Originally Posted by jake13jake

I really think there's a bit of need for documentation on how to best optimize the use of showimgs. It tends to take a lot of processor time when I use them in particular ways. How do you optimize using showimgs?

Solution: Buy a new computer.

?

[Maniaman]

Don't constantly redraw them unless you have to.

[jake13jake]

Originally Posted by Maniaman

Don't constantly redraw them unless you have to.

I'm thinking of a nick system. If you have to constantly redraw them, you might want to minimize the amount of data in the showimg object in which you're modifying.

Here is my conflict. You'll have to cycle through all the players to check if they're in an area since you. There's no findnearestplayers function clientside, although I would find a findareaplayers function much more usable.

Even with findnearestplayers or findareaplayers, that array would be constantly different, so the index of your showimg would be constantly changing in reference to that array. New people could enter the area, people could leave the area, and people could also reenter the area. How would this be handled? Does the index of your showimg even matter in terms of optimization?

Another thing I would worry about is if you hide an image but want to show it again at some point. At least some of the data could remain the same. While text, x, y, and rgb could all change, some have longer update times than others (text, rgb). Can you even do that or would you be forced to reinstantiate the object?

While a findareaplayers function may not be the most efficient way of showing a nick of every player, if you could store the showimg objects in an array and stop the work of showing without destroying the data, it would be good to use in the sense that it would reduce the cycles you would need to look for the showimg objects you need to change, and it can probably be more efficiently done in a function in the language than a function not in the language. The reason there is a findareanpcs function and not a findareaplayers function is because the number of players is generally low enough that you don't have to worry about optimization, but in the case of using showimg objects, you would want to because showimg objects are quite processor intensive.

[xXziroXx]

Originally Posted by jake13jake

I'm thinking of a nick system. If you have to constantly redraw them, you might want to minimize the amount of data in the showimg object in which you're modifying.

Here is my conflict. You'll have to cycle through all the players to check if they're in an area since you. There's no findnearestplayers function clientside, although I would find a findareaplayers function much more usable.

Even with findnearestplayers or findareaplayers, that array would be constantly different, so the index of your showimg would be constantly changing in reference to that array. New people could enter the area, people could leave the area, and people could also reenter the area. How would this be handled? Does the index of your showimg even matter in terms of optimization?

Another thing I would worry about is if you hide an image but want to show it again at some point. At least some of the data could remain the same. While text, x, y, and rgb could all change, some have longer update times than others (text, rgb). Can you even do that or would you be forced to reinstantiate the object?

While a findareaplayers function may not be the most efficient way of showing a nick of every player, if you could store the showimg objects in an array and stop the work of showing without destroying the data, it would be good to use in the sense that it would reduce the cycles you would need to look for the showimg objects you need to change, and it can probably be more efficiently done in a function in the language than a function not in the language. The reason there is a findareanpcs function and not a findareaplayers function is because the number of players is generally low enough that you don't have to worry about optimization, but in the case of using showimg objects, you would want to because showimg objects are quite processor intensive.

Hello? Ever heard of ganis?

[Twinny]

Originally Posted by xXziroXx

Hello? Ever heard of ganis?

Lol yeah. Plus alot of servers have custom nick systems without problems... I don't see how it could ever be CPU intensive really.

[xXziroXx]

Originally Posted by Twinny

Lol yeah. Plus alot of servers have custom nick systems without problems... I don't see how it could ever be CPU intensive really.

It will take ALOT of CPU unless its scripted into a gani, trust me - Ive tried it.

[Admins]

Also cycling through players[] (even allplayers[]) is quite fast, I would say that the speed problem is somewhere else. On Zone the nicknames are displayed for all players when you press N, and it's fast.

[Twinny]

Originally Posted by xXziroXx

It will take ALOT of CPU unless its scripted into a gani, trust me - Ive tried it.

You must have been doing it quite oddly then

[jake13jake]

Originally Posted by Stefan

Also cycling through players[] (even allplayers[]) is quite fast, I would say that the speed problem is somewhere else. On Zone the nicknames are displayed for all players when you press N, and it's fast.

Alright, I'll time it and put in the averages. You know though, it isn't so much the cycling through players I expect to be slow, it's the modification of data based on that.

I don't know why the nick system is so slow -_-.
the GUI state system is pretty slow too, but that's because of storm's absurd use of variables in the prior system that I haven't gotten out of using yet.