Wasn't really sure where to post this. It's more of a direct question to Tom and Lummox about inner workings of DM, but I suppose the response could be beneficial to everybody.
I've noticed that as I add more and more grids to a project that the game starts to get laggier. Not sure if it's a coincidence or something else at work.
I know grids auto update. But it seems rather limited. If the object is in a mob's contents, then the grids they are displayed in will update if said object's icon/overlays change.
Now the first question is, do grids auto update in ticks or only when something changes and the grid needs updated? If they only update when the object in the grid changes, that's great, but if not, then it would be good to know, because hundreds of grids constantly updating is a performance issue.
Secondly, I've found that with the implementation of multiple maps, that they would be a more powerful display component to use instead of grids, but if they auto update as much as the default map, then again, there is a problem changing hundreds of grids into maps.
Lastly, when a window is hidden, do the grids and maps on them auto update (if they do in fact update on ticks), or are they disabled until the window is shown again? If they also auto update, even when hidden, then I will seriously have to rethink the way I do things.
Teridal has a massive interface with close to a hundred grids which I would like to change to map displays (and most likely add many more, but probably less maps overall than grids since a map doesn't have to look like a grid).
So answers about the above questions would be much appreciated and help me improve performance on my projects.
Thank you.
ID:132328
 May 4 2011, 4:55 pm
|
|
Do you honestly need that many? Can none of them be combined, or be reused? Also, can you actually have more than 2 maps now? Yes. You can't do as much customization with the current grids and you can't gather information about individual cells when you click on an object or mouse over it and much more. And we're talking about a large game with tons of windows for the many different systems in the game. And you can't really use a single grid across multiple windows. Also, some windows have different grids in different sections of the window, it's not like everything is just displayed in a nice little grid. With all that said, switching from grids to maps would let me combine current grids together into a single map, which is why I'd like to go that route. Only issue is you can't do some things with client.screen as you can with grids, like displaying the same object multiple times across an interface, so I'll have to use half and half most likely. | |
Aaiko wrote:
Do you honestly need that many? Can none of them be combined, or be reused? Also, can you actually have more than 2 maps now? Fair enough you can't gather information about individual cells when you click on an object or mouse over it and much more. The location parameter of most mouse processes should hold the cell it occurred in when the control is a grid. And we're talking about a large game with tons of windows for the many different systems in the game. And you can't really use a single grid across multiple windows. Also, some windows have different grids in different sections of the window, it's not like everything is just displayed in a nice little grid. It sounds like secondary map controls might work better for you, then. It looks like the two-map restriction has been removed. You could always use proxy-objects to mimic an object being in multiple places at once. Also, you never specified if the lag you were feeling was from client CPU usage or increased network usage. I hear they'll be releasing a network profiler in the next version of BYOND, so maybe that will help you pin it down further. | |
The location parameter of most mouse processes should hold the cell it occurred in when the control is a grid. Good to know. Didn't realize it did grid cells, but, still have the customization issues. It sounds like secondary map controls might work better for you, then. It looks like the two-map restriction has been removed. You could always use proxy-objects to mimic an object being in multiple places at once. The problem with proxy-objects is you have to update them all when one changes. One example is Teridal's action bar. You have 48 slots (maybe more in the future, who knows). If a player puts the same ability in every slot (sure there's no reason to do this, but people could do it), then I'd have to create 48 new objects. And once the ability is used, I would have to add a cooldown overlay to all 48 objects (including the object on the ability window). Grids allow me to display the ability as many times as I want in as many grids as I want and then just give the object a cooldown overlay and every grid updates on its own. Of course, this is just one of many examples. So I'll probably be using a mixture of grids and maps. Also, you never specified if the lag you were feeling was from client CPU usage or increased network usage. I hear they'll be releasing a network profiler in the next version of BYOND, so maybe that will help you pin it down further. Honestly, I think the lag is either network or client based. Sadly, I wont really be able to use the network profiler as much as I'd like, since it's only for Dream Seeker, but I'm sure it'll help pinpoint possible issues during testing. I have a feeling that interfaces work in the background even when they're not visible. I know for a fact that if you send commands to a window that isn't displayed, it'll still update. So if anything updates in ticks or whatever, they could all be doing processes even when the user can't see them, creating lag. The lag seems to relate to how complicated and bigger the interface gets, so I think they're probably related. Either that or just newer BYOND versions are the problem (can't really go back and check because half the stuff wouldn't even work). Interfaces I work on get more complex as new BYOND versions come out, so it's hard to know for sure. | |
Aaiko wrote:
I've noticed that as I add more and more grids to a project that the game starts to get laggier. Not sure if it's a coincidence or something else at work. Additional grids could slow down DS, but their only impact on network traffic should be when you specifically update them. As I recall, any objs added to a grid won't have updates specifically requested. Now the first question is, do grids auto update in ticks or only when something changes and the grid needs updated? If they only update when the object in the grid changes, that's great, but if not, then it would be good to know, because hundreds of grids constantly updating is a performance issue. The actual network updates are not done once a tick. But every tick, the client does look at existing grids that contain cells with objects in them, and it updates the image and/or text in the cell. If it detects a change, it will go through the resizing process after the cells in that grid have been updated. The resizing part might be easier to modify and would probably improve performance, if for instance the grid could detect that it wasn't visible and wait until it's shown again before resizing. Secondly, I've found that with the implementation of multiple maps, that they would be a more powerful display component to use instead of grids, but if they auto update as much as the default map, then again, there is a problem changing hundreds of grids into maps. Like the main map, they'll only update when you make changes. Whenever you change the HUD, a flag is marked that tells the server you need updates, and that forces it to send information on which screen objects have changed. Lastly, when a window is hidden, do the grids and maps on them auto update (if they do in fact update on ticks), or are they disabled until the window is shown again? If they also auto update, even when hidden, then I will seriously have to rethink the way I do things. Yes, they will all update when hidden. A map control shouldn't try to draw or get an updated icon list during this time, so the map overhead is really minimal. Grids on the other hand will always go through that update and possible resizing I mentioned; I think that can be improved on. Lummox JR | |
The default map will of course receive regular updates from the server about what is in its view. I believe Lummox JR has said in the past that the client.screen is only updated when it changes (so the secondary map shouldn't update unless you're changing its screen)
However, if you're referring to CPU usage and not network usage, I don't think the interface system was designed with those kinds of numbers of controls in mind.
Do you honestly need that many? Can none of them be combined, or be reused? Also, can you actually have more than 2 maps now?