Problem description:
So last night after spending hours developing a new map I began testing it, and notice extreme sluggishness while in battle, once all enemies were gone/dead my attackspeed and everything began working as normal. Being very confused, I ask myself what did I do to create such a game breaking bug. I begin debugging like a madman removing/commenting whatever I thought was the problem. I ended up removing the entire hud and notice the delay was gone. I thought this was very peculiar because I've had this hud for long enough and haven't had any problems with it.
While slowly trying to re-implement the hud, I remembered something about a limit on screen size or resolution. I really enjoy this games perspective and wide view and will try whatever to keep it as is. So I tried reducing the world.fps, the highest I could get the world fps without the sluggish combat was 11. The scrn shot of it is below. I'm thinking the new client.fps will help if worst comes to worst but do you guys have any suggestions or information about this particular limitation. Also what do you call this type of lag/sluggishness. I'm thinking I'm going to be force to transform the hud into mostly interface which I think would be hard with fullscreen map.
1
2
In response to Ter13
|
|
Ter13 wrote:
How does that minimap work? This might derail the topic a bit, but I am curious to know why minimaps seem to blow so much on BYOND? Is it because they're dynamically created/refreshed? If my recollection serves me right, Ultima Online, a game made in the dark ages of 1997, was one of the pioneers of minimaps and they managed to make it work quite well. I believe it was implemented by having the minimap as an image which was compiled from the map turfs at server start. So, even if you were a GM who spawned new turf/objects at run-time, the minimap would not update because it's running off of the server start map. Would this approach fix the minimap lag problem? |
In response to Azurift
|
|
It fixes a lot of it, it's how most SS13 servers (that have minimaps) handle minimaps.
Whenever a map change has been detected at server start the new map is made into a minimap .png, and anything interactive are just cheap /images re-positioned on it. |
This might derail the topic a bit, but I am curious to know why minimaps seem to blow so much on BYOND? Is it because they're dynamically created/refreshed? That's part of it. The other part of it is that BYOND is a server-directed engine. BYOND doesn't do any cropping when it renders, so if you are rendering a small bit of a minimap inside of a second map element, it is going to draw the whole minimap every single frame, which is extremely expensive. The only really viable way to handle minimaps is by using a browser element, but it's just... Well, beyond most developers here as well as fraught with problems. |
From my testing it was just hud objects in general that caused sluggishness. I didn't even have the minimap implemented before I changed the fps to 11. Surprisingly the minimap code is supereffective causes 0 cpu. Im using it for a project much bigger than this and have 0 problems with it. The only thing that happens players move is it shift screen_locations.
The issue from my understanding is the overall viewport, seeing if I increase the zoom, I run into no sluggishness. Perhaps if I put all the hud objects on to one plane it will be less likely to lag... |
Okay so that plane idea was a very bad idea, it only made the problem worst. Heres some host files so you can experience what I'm talking about.
40 FPS, No Minimap With Hud http://files.byondhome.com/FatAlbert/ Wrath%20of%20The%20Gods2.zip 40 FPS, With Minimap No Hud http://files.byondhome.com/FatAlbert/ Wrath%20of%20The%20Gods3.zip |
I think I found the one of the problems.
For a quick healthbar. I was scaling a bar and giving it maptext. And I'm guessing maptext doesn't like to be scaled. This was the original code. Update() This is simplified code Update() I found it to be less sluggish but yet still sluggish. |
40 FPS No Minimap, Hp,Mana & Energy bar disabled.
http://files.byondhome.com/FatAlbert/ Wrath%20of%20The%20Gods4.zip I still feel slight sluggishness while fighting, its noticeable cuz you can see the attackspeed slow down. |
Here at the codes for the other hud objects.
//Onscreen Stat Display |
After many days of new features. I stumbled across the source to the sluggishness problem.
Basically I was being lazy and had the minions spawn with their transform/=2 so they were smaller and I would give them real icons when I had the chance. After developing some innovating codes that correctly positions separate weapon objects on the player, I notice the sluggishness monster was back and more powerful than ever. With proper debugging and the process of eliminations, I removed the stupid transform on the minions and Zoom everything was back to smooth and I was even able to enabled the entire hud with no problem. Interesting enough, I'm slightly puzzled on how some many separate functions/features(Hud, transform, fps, viewsize) seemly produced the same effect making it hard to know what was exactly causing the issue. |
To be honest I have no idea how transforms could slow things down like that. Unless you're rendering in software mode, transforms really should be pretty seamless as far as the GPU is concerned.
|
Yeah, false flag. This sluggishness be acting weird, it seemed like it was all gone, then comes back hard. And I'm not sure what I'm doing that is making it act spontaneous.
|
yeah, its some graphical background stuff, cause when I zoom everything is smooth and runs nice. I just got to keep the world.fps around 15. I'm hoping when 511 is release client fps will allow higher frame rates and won't reproduce the sluggishness.
|
That doesn't make any sense. If you raise the FPS, any sluggishness will get worse, not better.
On top of that, 511 is already out; it's just not the stable release yet. I would strongly suggest experimenting with it if you have any questions about how FPS will act in that version. One thing I know for sure is that having other controls, like output, on top of the map is a sure way to kill performance. |
In response to Lummox JR
|
|
Lummox JR wrote:
One thing I know for sure is that having other controls, like output, on top of the map is a sure way to kill performance. Explain |
One thing I know for sure is that having other controls, like output, on top of the map is a sure way to kill performance. We need a major overhaul as far as customizable screen-based UI elements are concerned. Maptext is a performance killer, and there's no way to get the width or height or layout of the text it generates for the client so we can't easily build dynamic layouts that are rendered at reasonable rates on the client side like we can with the webclient. Missing are the ability to clip, scroll, etc maptext to create an easy, fast onscreen output element. Missing is the ability to select and copy text from maptext elements. Missing is the ability to interact with maptext with the mouse at all. Missing is the ability to use a client-side maptext input element at all with selection, copying and pasting. We can actually make reasonably decent UIs in DS with just screen objects, but anywhere text input or output is concerned, the engine has absolutely no tools built in that are at all helpful to developers. |
I'm definitely open to feature suggestions that might open up maptext more.
In terms of performance, for the past couple of releases DS has been caching maptext once it's drawn, which should be a big improvement since it doesn't have to be redrawn or re-parsed. |
1
2
My money is on the minimap being the issue.