ID:151891
 Nov 3 2008, 10:18 am
|
|
I use the client.screen var heavily in my game and from what I can see from reading posting regarding it, I might be able to cut more lag down by handling the screen better. SilkWizard had an idea of having an external list that contains all the screen objects and when the list is updated, you would clear the client.screen list and then update with by copying the contents of the external list. Is this method efficient enough to use in my game (which uses the screen a LOT)? If not, are there any more suggestions?
| |
|
Nov 3 2008, 10:43 am
|
|
Xooxer
 |
You can reduce the color count in the icons you use for your HUD to make them as small as possible, decreasing the amount of bandwidth it takes to transfer them to the players.
|
Uh... this is a non-factor. The HUD icons are transferred once with the rest of the game's resources when the player logs in, not when the screen is updated or something.
| |
It probably depends on how you define 'a lot', and if there are a lot of screen objects active at 'once' or only 'occasionally'. The more you have, the more lag will occur each update, as 'everything' is updated. As for using lists to modify the screen list, it naturally helps as there are less updates done, yes. You could also just simply use the Add() and Remove() procs' multiple arguments function and don't have to necessarily use lists.
| |
Er.. What? Are you saying I'm transfering the very same icon again and again for each update I make to client.screen? o.0
| |
AFAIK, not the icon, just its presence in client.screen - Dream Seeker is sent some sort of identifier from the host that that tells the other end what to draw. In the case of client.screen, I'm pretty sure it doesn't only send changed identifiers - it just sends the whole thing.
This makes dynamics HUDs a little slow sometimes, for obvious reasons. It basically means adding or removing everything should occur in one big insta-block, rather than many little changes. Additionally, if you're just changing, say, a single icon in the HUD, don't remove and then add a different object - just change the icon_state of the object that's already in the screen. In fact, that should probably be your paradigm overall - don't add or remove to client.screen after client/New(), where you fill it with invisible objects placed in all the right places. Then, when you actually do things with the HUD, do it by changing the icon_state of several icons in the interface. I may be wrong, and that might not be a workable workaround, but I'm pretty sure it's what Silk does in Acheron's Awakening, to name a game with a complicated HUD. | |
Jp wrote:
AFAIK, not the icon, just its presence in client.screen - Dream Seeker is sent some sort of identifier from the host that that tells the other end what to draw. Well, duh. Why would it send the entire icon? Especially when the client already has it from the game's initial RSC DL. Anyway, this is what I meant in my reply to Xooxer, so your reply to that wasn't too well-placed. As I said, because of this the size of your icons are a non-factor, and there is no need or specific benefit in dumbing down their size when using screen objects. Additionally, if you're just changing, say, a single icon in the HUD, don't remove and then add a different object - just change the icon_state of the object that's already in the screen. Unfortunately, this also automatically internally updates everything in the screen.[leet wikipedia style ref] There's no escaping this. =\ There's also an issue with the possibility of replacing a screen object with another or similar, since you can't remove and both add in the same statement, it will update it (ie everything) twice. I suppose they may not be willing to possibly change this and provide a new proc or something to that extent? | |