Jump to content
  • Advertisement
Sign in to follow this  
chronosifter

Interface Developement Tool / XSLT

This topic is 4060 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well I've been working on an interface editor for a famous MMORPG for awhile now (EverQuest). It uses a nicely assembled set of XML files as it's Scene Graph for the interface. At first I figured I'd just read in all that data from the XML into a set of classes and use those classes for the scene graph, but this is starting to get costly on the CPU, so I started to look into applying XSL Transforms to the Xml files to create some document form that is capable of displaying images of multiple formats. First thought was use .net's HTML viewer control and transform it to HTML. Worked good except 2 problems. The HTML viewer is incapable of displaying TGA and DDS images, DDS I could care less about, but TGA are the most commonly use format among EQ UI developers. So what I'm looking for is a format that is capable of taking OnMouseDown, OnMouseUp, and OnKeyPress events, but also capable of displaying GIF, TGA, JPG, PNG, and potentially DDS images. The event's capability isn't really important, I could always code them into the panel containing the display control. Though my problem about being costly on the CPU could lie elseware. The structure I was using for the Scene Graph is a tree structure, each node updates it's children after updating itself, so that the top most node is in the background and bottom most node is the foreground, which is how the UIs act in-game. I'm also somewhat a newbie to XML serialization/deserialization in .Net languages (before .Net I just used string functions which when replicated in C# are slower than the .Net xml objects). Pretty much been getting stumped with every method I've tried at keeping the Scene Graph easily editable to be later Serialized into an XML file, and vice versa. Seems there is a trade-off to editability/performance no matter which methods I use. I am willing to send a copy of the source code to anyone who wants to look at it and give me a few pointers. The display code however is in shambles due to heavy editing over the last few days, so only code that really compiles and makes any sense at the moment is the XML reading and class data storage.

Share this post


Link to post
Share on other sites
Advertisement
How often are you rebuilding the scenegraph from the XML tree? It seems to me like the solution is pretty easy: deserialize from XML into a runtime representation in memory, do all your editing against the memory version, and only go back to XML when it's time to serialize again. We use basically that exact approach for a very large game scenegraph (much larger than any UI's scenegraph would be) and we've had no problems at all with CPU load.

It sounds to me like you could use some profiling on your implementation to figure out exactly where the bottleneck is located. There shouldn't be any problem at all with having a tree of nodes that update per frame and render up to the screen as you've described; that's basically the idea of a scenegraph, after all [wink]

Share this post


Link to post
Share on other sites
Well I've zeroed in on the problem. It was a between the chair and keyboard type problem, directly out from the monitor. I was somehow over complicating the entire editing method, when it was already solved with the implementation of the xml to class data, just waiting for the few lines of additional code to make it fit into the rendering engine.

I think my brain melted two days ago when I started to encounter the problem or something, was a true slap on the head moment when it became clear.

The whole CPU load was coming in because the xml handling and rendering engine are in separate dlls so I created an overcomplicated way of transforming the class data into scene objects, when the class data was already plenty of info to be a scene object. Basically was copying the entire UI every time an element was edited to the point of being stable again.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!