I’ve been working on an MMO since early Alpha. The servers & server/client communication is a roll-your-own & has worked solid for quite some time.
I have already implemented many of the games features, holding off on pure melee combat evaluation (knowing how I wished to implement it so it was scale-able without relying on common stumbling blocks, such as lvl spread, etc, etc) until recently. I spent the majority of my time implementing feature such as NPC AI decision making, AI pathing, grouping, raiding, spell system implementation (targeted, group, AOE, over time, etc), blah, blah, blah,
Seeeeeew… on to the problem that seems to have arrived since the implementation of combat evaluation:
I have built a considerable number of custom NiftyGUI controls (such as resizable windows) with custom input filtering for use of right-click, scroll-wheel, etc, etc. These controls have also been working solid for quite a bit of time… HOWEVER, since passing along combat information, which continuously updates the graphically represented state of PC/NPC/Item stat display, FPS seems to be dropping exponentially the longer combat goes on.
There could MANY reasons that simply come down to not handling garbage collection properly, to ?? that would be problems with the code I have written. However, it also occurs to me, that I probably would have seen some sign of this prior to the constant updates to NiftyGUI controls.
Has anyone else had similar problems? (before I go through the process of dissecting the servers & client from the communication layer up).
Thanks in advance!!!
You can profile your application in the SDK using the “Profile” button and check where the CPU time is going.
@normen said:
You can profile your application in the SDK using the "Profile" button and check where the CPU time is going.
You.... are a saint!!
Thanks soooo much :)
Sorry to raise an older thread from the dead, though, I think I narrowed down this problem (got sidelined with the W word). I wrote a custom chat control in Nifty… It seems that after the number of appended messages gets past a certain point, it effects rendering.
Am I mistaken in the idea that visual elements in Nifty are not removable? I recall seeing something about flagging for removable, but… not sure if I understood that correctly. I am hoping that this means that they will be removed during the next render cycle. Perhaps I should move this topic to the Nifty forum, as I am absolutely sure that is where the problem lies (in my code… not Nifty).
If someone knows the answer to this (flag for removal in Nifty), please post here so I don’t have to start a new thread on the same old subject.
To be completely honest, I would prefer to create/destroy the UI components as they are needed, as apposed to hiding/showing them when needed (i.e. inventory window, script editor window, etc, etc).
Thanks!
[java]
myNiftyElement.markForRemoval();
[/java]
@glaucomardano said:
[java]
myNiftyElement.markForRemoval();
[/java]
Thanks you... am I correct in my assumption about actually removing the element during the next render cycle? or?
I think the element is instantly removed. Just look at the source code. That method calls this one internally:
[java]
public void removeElement(Screen screen, Element element, EndNotify endNotify) {
element.removeFromFocusHandler();
element.startEffect(EffectEventId.onEndScreen, new EndNotify(screen, element, endNotify) {
public void perform() {
Nifty.this.endOfFrameElementActions.add(new Nifty.EndOfFrameElementAction(Nifty.this, this.val$screen, this.val$element, new Nifty.ElementRemoveAction(Nifty.this), this.val$endNotify));
} } );
}
[/java]
But that code basically proves @t0neg0dess right… I am almost 100% sure that perform() method is only called in the next update cycle.
100% isn’t good enough anymore normen, and you know it
