This is basically a catchall thread for anything involving basic effeciency, just as the Handy procs thread in Creations is for uh... procs... that are handy. At any rate:
When using a loop, do you really NEED to do everything in the loop through every cycle? Let's say you throw in a stat loop to upgrade an on-screen HUD for tracking HP. Why not pass the mob's hp at the end of the loop, to the next itteration?
src.Update(src.hp) // src.hp = 15 right now
Then take a peek at this:
Update(passed_hp)
if(src.hp != passed_hp)
// Tab up all existing code to here
spawn(5)
src.Update(src.hp)
What this does is keep you from modifying the icon each time around. If the hp hasn't changed, then obviously the icon won't either! This is the best approach to use if you need to update it constantly, but don't want to edit all your existing code to Update() after the mob takes damage. It would be even more effecient, however, to kill the loop entirely, and just update the on-screen whenever the variable is modified, and maybe once every 10 seconds just for odd modifications (like administration verbs).
~Polatrite~
ID:153451
 Feb 3 2004, 10:15 am
|
|
Polatrite wrote:
This is basically a catchall thread for anything involving basic effeciency, just as the Handy procs thread in Creations is for uh... procs... that are handy. ...and ironically, not at all efficient. ;) At any rate: Excellent question, and the answer is usually no. This is one of the easiest ways to optimize: Pull anything you can out of a loop. This especially includes if/else checks for a condition that is true or false throughout the entire loop. Let's say you throw in a stat loop to upgrade an on-screen HUD for tracking HP. Why not pass the mob's hp at the end of the loop, to the next itteration? For situations where a loop would be best, I'd definitely try something along those lines (although in this case, you need to record src.hp before calling Update() in the spawn, or else it'll be the new value you end up passing). Problem is, I can't think of any situations like that except when handling a timer. Doing this for a semi-static var in a HUD, you should go to the trouble of modifying your existing code for update-on-demand anyway. There's really no chance that hp is modified often enough to make that difficult, and you can do a Find for all included files to find every spot it changes. It would be even more effecient, however, to kill the loop entirely, and just update the on-screen whenever the variable is modified, and maybe once every 10 seconds just for odd modifications (like administration verbs). Not sure I follow that last part. Any modification you need to display can be run through a simple update proc to handle the display. Lummox JR | |
Lummox JR wrote:
For situations where a loop would be best, I'd definitely try something along those lines (although in this case, you need to record src.hp before calling Update() in the spawn, or else it'll be the new value you end up passing). Problem is, I can't think of any situations like that except when handling a timer. Oops! Absent-mindedness strikes again! Not sure I follow that last part. Any modification you need to display can be run through a simple update proc to handle the display. Certain administration variable editing code can dynamically edit variables using vars[] and text arguments, therefore they would need to add the Update() check to the end of these sort of verbs manually, since you can't just find-and-replace in this instance. | |
Did you know?
Probably not, but I'm going to tell you. Screen objects can actually be placed *off* the map screen. This means you can make borders and such, without 1) using up map area, and 2) causing extra bandwidth problems by increasing the map area. Very handy! To set screen objects outside the map area, just use coordinates + or - your existings max (11, for default view size of 5), and min(1). I encourage you all to try this. Especially Leftley. =P ~Polatrite~ | |
Polatrite wrote:
Not sure I follow that last part. Any modification you need to display can be run through a simple update proc to handle the display. Easier to modify the admin code to signal an update routine when a var changes. All it needs to do is send a copy of the object, the var name, and the var's new value. You could also use a custom user proc to accept or reject such changes. Lummox JR | |
Polatrite wrote:
I encourage you all to try this. The border in Lode Wars doesn't take up a full tile in each direction. Hence those portions can't go outside the map area. Lummox JR | |
I'm a little concerned that this thread is mostly just how-to at this point. If that was your goal, the forums really aren't the place for it; it belongs in Bwicki. The forums would be a better venue for discussing efficiency.
Lummox JR | |
I'm almost positive that creating a new thread and calling the procedure again would be less efficient than modifying a variable.
| |
But, why use a loop if you're just editing a HUD object? Just use, locate(). That's how I do my stat bars when using HUD. I just place a few var/obj/hud/health/H=locate() in src.client.screen, then make a few checks to make sure it located it, then change its icon state.
| |
Goku72 wrote:
But, why use a loop if you're just editing a HUD object? Just use, locate(). He's not using a loop to find it; only for updating. Lummox JR | |
Lummox JR wrote:
Polatrite wrote: You're both wrong (assuming that I understand Polatrite's pointed comment correctly: suggesting that some of the performance problems in Lode Wars are caused by transmitting excess data for portions of the map obscured totally by the HUD background). At its "thinnest" point, the border is 1 tile thick, but at its thickest, it's still less than 2 tiles. Therefore, the outermost layer (which includes the almost purely decorative strips on the top and righthand sides) is placed one tile outside of the view area. Unless Polatrite is simply commenting on the fact that there is half a tile obscured along two of the sides, in which case I say "Meh." It looks waaaay cooler this way, although admittedly it would probably be a better idea to put the little hovering team indicator in a spot where it wouldn't get hidden if you see an enemy along a certain edge of the screen. | |
Has anyone figured out why Lode Wars is so slow? It's too slow to play on my computer. I die before I see the enemy, most of the time.
| |
Polatrite wrote:
Has anyone figured out why Lode Wars is so slow? It's too slow to play on my computer. I die before I see the enemy, most of the time. I've wondered this myself. The answer that most of the players seem to stick to is "because the HUD is generated by horrible laggy bogeymonsters! WooooOOOOOoooOOOOOoooooOOOoooo!" On my current computer, an old 333 mHz box, the full HUD background causes a lot of client-side drawing slowdown when moving diagonally (particularly northeast), but otherwise is barely noticeable. Go figure. Never had any problems on my (late) development computer. | |
Let me say that again.
Making lots of objects, all in a short time, is bad.
I've seen many games continually keep popping up battle backgrounds, title screens, and other things like this. They keep making new objects and deleting the old ones. Is there a point to this? No, they just don't know any better. Why not simply change the icon, icon state, layer, and invisibility when you toggle? After the icon no longer needs to appear, make it completely invisible (100? 101?), then when it needs to reappear, set the proper icon and attributes, then make it visible again! Easy as pie. If you've ever played In the Hood and looked at the login screen, you'll notice it scrolls quickly, and without much lag, if any. If it does lag, then you obviously have a computer that is worse than my 6 year old machine, and are in vital need of an upgrade, like myself. This lack of lag is achieved using the same techniques listed here. Give it a shot, and somebody make some cinema scenes.
~Polatrite~