Client Sided Icon Manipulation:
Icon procs (Turn/Blend/Scale/ETC) could be processed on the client's side. Instead of being processed by the server, and then having the client download more files. This would help reduce server CPU and Bandwidth usage.
On top of that, there could be more dynamic client sided graphic processing. For example, a new /atom transparency variable could show things at a certain alpha level, without having to recreate and reassign the entire icon.
ID:92922
 Mar 15 2010, 6:36 am (Edited on Mar 8 2011, 11:52 pm)
|
|||||||||
Resolved
| |||||||||
An atom transparency var would belong to a separate request, but client-side icon processing has been attempted in the past and was put on hold due to difficulties getting it up and running properly.
| |
I hope to see this done in the future, then I could re-add in s_damage lib into my game with probably a per-client toggle on/off, before it would lag the whole server no matter what since the server did the processing, with this, it will make the server smooth, and then allow me to make on/off so individuals wont lag due to their computer now being the one doing the processing.
| |
Or you could just find a competent library, instead of using one that works like complete crap just because you could pass it off on the client.
Or even better, you could just not use a library at all. | |
If that is in response to me, I don't even use the s_damage lib anymore, and no matter how it's coded, it lags my sucky computer, which is why I want this to be added in.
| |
If s_damage has one major weakness, it's that it does not cache its icons. It should be easy enough to write something like it with caching.
| |
Lummox JR wrote:
If s_damage has one major weakness, it's that it does not cache its icons. It should be easy enough to write something like it with caching. But if you cache too many icons! Then the memory usage causes the game to crash. Double edged sword, indeed. | |
That depends on how many icons you create. s_damage keeps its icons entirely in one file, which means just one cache entry being created per color. If your range of colors is limited, then you'll only ever have so many icons generated by the library. It won't produce duplicates because cache entries use a checksum. The only problem with s_damage is that it doesn't have any way to know it's building a duplicate.
| |
Welp, I was using a cache system for the hair rgbing in BE and it just caused doom.
| |
Any word on this? It's gonna be a badass feature and one that will make a whole lot of ideas realizable.
| |
Well, was marked as "on the list" because (many years ago in fact) we did make a foray into this very project and the optimization was not nearly as promising as we had anticipated. Surprisingly, the server-side transmission of dynamic icons is actually not the bottleneck you'd think. It is something I'd like to revisit, even if it ends up being for special-case situations like: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=2205
| |
I'd be more concerned about CPU and memory usage than bandwidth. I tend to not generate icons at runtime but I'm sure other people have had problems when generating (and caching) lots of icons.
| |
The reason I'm interested is because I am dead set on making a game where a limitless amount of players can work on the same jigsaw puzzle with a ridiculous amount of pieces. I originally wanted to have it work this way for Ultimate Jigsaw.
Unfortunately, the dynamic puzzle generator for Ultimate Jigsaw uses Crop() once, Turn() two or three times, and Blend() three to five times, per piece. This is not to mention the upwards of several hundred thousand DrawBox() calls used to outline the puzzle pieces. Scale() is also used once for fitting the picture to the puzzle. I also have to use Scale(), Blend(), Turn(), and Crop() for rotating puzzle pieces on the fly. The HUD based custom skin/interface mash-up also uses Scale() to match the client's screen size to the player's resolution and this is almost a problem in single player, not to mention transmitting a new 1680x1050 icon to a client. EDIT: I guess my point is, in my instance, bandwidth may actually be a problem for multiplayer. For singleplayer, CPU is an issue. | |
Forum_account wrote:
I'd be more concerned about CPU and memory usage than bandwidth. Yup, this is exactly the problem. Bandwidth really doesn't have much to do with it. | |
Falacy wrote:
But if you cache too many icons! Then the memory usage causes the game to crash. Double edged sword, indeed. Or use a splay tree and regularly prune it, like any competent programmer. | |
Popisfizzy wrote:
Falacy wrote: I don't know why you wouldn't just use a hashtable. The most elegant solution is to handle the effect on the client. Most graphics libraries have support for rotations and transparency, the competent programmer would re-use those features instead of doing whatever you're talking about. SilkWizard wrote: Bandwidth really doesn't have much to do with it.Hiro the Dragon King wrote: bandwidth may actually be a problem for multiplayer. Bandwidth would be more of an issue, but since this is purely a graphical thing the features that would create bandwidth issues usually aren't essential. If bandwidth weren't a concern I think you'd see people use these effects a lot more. If any form of customizable client-side processing was to be implemented it would be important to have these effects handled on the client. Imagine you want to, at runtime, cause an object to fade away and disappear. Currently, the server would have to generate a set of increasingly transparent icons and send them to all clients. With client-side support for icon operations the server would just have to send the clients a sequence of messages saying "set the obj's alpha to 0.9", "set it to 0.8", "0.7", etc. With custom client-side effects the server would just send a single message that says "make the obj fade out" and the clients would all know how to handle that. This feature still isn't ideal but it's a *huge* step in the right direction. | |
Forum_account wrote:
I don't know why you wouldn't just use a hashtable. Because splay trees allow very good look-up times (not constant time, but I have doubts that BYOND can even implement a constant-time hash table due to a lack of any sort of manipulating memory) for the most-used cached data, and the least-looked up data can easily be pruned as they will be the leaves of the tree. It's a way of handling memory management well that can't be handled with a table. Hence 'competent programmer'. Managing memory. Did you even look up a splay tree, as your comments below makes me doubt it. The most elegant solution is to handle the effect on the client. Most graphics libraries have support for rotations and transparency, the competent programmer would re-use those features instead of doing whatever you're talking about. None of this is at all related to what I was talking about, in any case. I was referring to actually caching the icons, not manipulating them. | |
I understand exactly what you said. It's great that you learned what a splay tree is but you're way too eager to bring them up. The "competent" programmer might complicate the problem to create the chance to use a neat data structure, but the good programmer would find a more elegant solution. That's what we're talking about here, the more elegant solution.
| |
Forum_account wrote:
I understand exactly what you said. It's great that you learned what a splay tree is but you're way too eager to bring them up. The "competent" programmer might complicate the problem to create the chance to use a neat data structure, but the good programmer would find a more elegant solution. That's what we're talking about here, the more elegant solution. And an elegant solution is a tree structure with a very practical application in exactly what we're using it for: caching. One of a splay tree's main uses is for exactly this. It's self-optimizing, i.e. uses less processing to search for what is used most, and it easily allows you to manage memory usage. The only advantage of a hash table in this situation is that it has constant lookup time, and that's irrelevant in this case because you can not make such a hashtable in DM unless we have memory management added somewhere along the line, which is highly unlikely. So, yes, a splay tree is, in fact, the best and most elegant solution, hands down. | |
This is just one of those things BYOND handles opposite of how all other networking solutions handle things.