If you handle the icon manipulation on the client you don't need to cache any icons. The graphics library takes care of the visual effect.
Forum_account wrote:
If you handle the icon manipulation on the client you don't need to cache any icons. The graphics library takes care of the visual effect.

Oh, I see. You were referring to something completely different than what I was talking about in my reply to Falacy (which was referring only to the current system using server-side manipulation).

Your bad.
I would just crop the associative list, but it doesn't really seem worth doing in the first place.
Icon manipulation is not a significant lag factor in most games. Even if quite a bit of customization is going on, I wouldn't expect this would impact lag much at all. Not to say this won't be addressed because we obviously want to revisit this, but "because NEStalgia has lag" doesn't really sound legitimate to me; it probably lags for reasons completely unrelated to icon processing. Only Silk can say that for sure.
Back when we had 10-15 people at most, the character creation (using SwapColor(), Scale(), and icon()) would be only thing that would cause a noticable server slowdown.

The most heavy use areas (battle and text draw) are really our only options if we want to "optimize" things.
Even yesterday with 50-60 people playing on the private-access Reddit server things were super smooth until someone new logged in and started creating a character.
Ah, good to know that. Then I guess it is more of an issue than I thought. One thing I'd love to have eventually is an ability to weed out cache icons that are no longer in use, because many icons that get created during character creation are only temporary, but we don't treat them that way.
If there is something that we can do to help you figure it out then please let us know. Whether its us trying to come up with some sort of demo or just sending you the NEStalgia source so that you can see that part of the code in action for yourself, we'll do whatever we can.
Lummox JR wrote:
Icon manipulation is not a significant lag factor in most games.

This is true because most games don't use icon operations. And I expect that's true because developers know that using icon operations would cause lag.

A lot of nice, simple visual effects could easily be created with client-side icon manipulation. Suppose you want to make an object fade and disappear, or make a mob look like a ghost by being partially transparent, you'd have to generate a lot of icons. With client-side support you could have an atom.alpha var which can easily be changed to create these effects. Saving CPU cycles and bandwidth is only part of the benefit.
I do believe that in games that do a lot of icon manipulation, the computational overhead is a factor. This was made worse in 4.0 which uses 32-bit icons; the lack of a palette makes any color->color swaps take longer. When I tested this on Incursion way back when, it was noticeable, but not horrendous.

Even if we kept everything server-side, we could improve this by palettizing applicable icons. Internally it's a little hairy to have to represent two formats. Ideally we'd get some feedback on whether this is in fact a bottleneck by getting some output from the profiler (maybe just a test game where you have people build some characters, so we can see what operations take up the time here).

This problem would also likely be solved with client-side icon transmission, where we don't generate the icon server-side but instead put instructions to generate it on a queue and forward that. We actually had this fully implemented like 5 years ago but abandoned it because it seemed like the testing would be too involved at that time. It's something we can revisit, though.

This is somewhat different from the feature request here, which is to again pass instructions but have the client apply them at runtime instead of creating a new icon for them. This would be useful for things like transparency and rotation. It's unclear to me how much benefit this would provide in general, considering that icon manipulation on a single client shouldn't really take too long.
Here's an interesting thing I found (which I assume ya already know). I have found that several icon procedures are actually not too slow. However, the speed starts to drop when the icon variable is set many times to each icon change that happens (due to creation of new cache entries). I did testing recently while working on a new version of a fangame, "Classic Tron BYOND Edition". Best thing to do right now is say for drawing, do it before actually showing the newly changed icon.

There was another request about cache access made by Popisfizzy a few days ago if ya interested in looking. That is all I have to say.
Tom wrote:
We actually had this fully implemented like 5 years ago but abandoned it because it seemed like the testing would be too involved at that time. It's something we can revisit, though.

I think I need a new monitor because this one has a fist-sized hole in it.
Well, I should clarify that by saying "fully implemented" means that theoretically the code should have worked but it was really slow and didn't survive many tests. Usually the initial idea takes about 10% of the total implementation time and it wasn't something worth investing in then.

Bandock-- yeah, the actual icon writes are slow compared to the operations, but still, a lot of internal icon math routines can still add up.
Ah, alright. I was just curious about why showing the changes was slow while the operations themselves seem faster. Thanks for summing that up.
Lummox JR wrote:
Icon manipulation is not a significant lag factor in most games. Even if quite a bit of customization is going on, I wouldn't expect this would impact lag much at all.

Icon operations are practically impossible to manage efficiently. As FA said, the reason they aren't used often, is because they drive the game into the ground. Check a single icon+=rgb() in the profiler, it probably uses thousands of times more CPU than any other built in function. They're always one of the most expensive things in my games, even though I use them as sparingly as possible.
Falacy wrote:
Icon operations are practically impossible to manage efficiently. As FA said, the reason they aren't used often, is because they drive the game into the ground. Check a single icon+=rgb() in the profiler, it probably uses thousands of times more CPU than any other built in function. They're always one of the most expensive things in my games, even though I use them as sparingly as possible.

And it's not just the CPU usage. Suppose you wanted a mob to be tinted red, you can do a simple icon operation, but what happens when you change their icon or icon state? You'd need to generate another red icon. Aside from the CPU usage, this is a hassle to manage. Being able to set atom.color = rgb(255, 0, 0) and having the client understand what that means would be a lot easier.
I originally had a system in BE that "flicked" enemies red when they took damage. But even after storing the rgb(ed) icons, so they were only created a single time, the simple act of changing the icon var seemed to be using a ton of CPU. So the system was removed.
Lummox JR wrote:
Ah, good to know that. Then I guess it is more of an issue than I thought. One thing I'd love to have eventually is an ability to weed out cache icons that are no longer in use, because many icons that get created during character creation are only temporary, but we don't treat them that way.

Yeah, it is a very big issue. I've had to remove countless features from Teridal that involved icon manipulation because of lag.

One icon operation freezes the entire server for a split second (barely noticeable, if at all) but 10+ icon operations going around the same time can freeze the entire server for multiple seconds (longer the more operations going on). And we're talking about online games here with 30 to 150 players all doing things at the same time, so 10+ icon operations is nothing. Not to mention being able to do serious icon manipulation would open many doors.

I think the servers have way too much work they have to do. As many things as possible need to go clientside so we don't have to have supercomputers to host a complex game with more than 50 players online.
Lummox JR wrote:
Ah, good to know that. Then I guess it is more of an issue than I thought. One thing I'd love to have eventually is an ability to weed out cache icons that are no longer in use, because many icons that get created during character creation are only temporary, but we don't treat them that way.

I posted a feature request that may be useful to this end, though I don't know about the complexity and difficulty of this.
Lummox JR wrote:
Ah, good to know that. Then I guess it is more of an issue than I thought. One thing I'd love to have eventually is an ability to weed out cache icons that are no longer in use, because many icons that get created during character creation are only temporary, but we don't treat them that way.

That has been one of the biggest issues with all of my projects. I do a lot of icon manipulation. I've been asking this for years but it's been shot down every time.
Page: 1 2 3