|
Mudlet
General Discussion
|
|
|||
| Hi, thought I'd let you know about a new client in the making, Mudlet (http://mudlet.org/). You can find out the planned features on the about page (http://mudlet.org/about/). I had a question in regards to ZMP though - is there any news on it's adoption? |
|||
|
|||
|
That looks like a very interesting client, I wish you guys all the best with it. It's kind of funny that we were just talking about an HTML\Javascript client not too long ago. Even though it sounds like you guys are still going with the download\separate app required thing it will be an interesting middle-step to see how HTML\CSS\Javascript presentation will work. | ||
|
|||
| A javascript client is not possible at this stage really. Javascript, even with the all new developments (albeit the js engine that webkit uses just got some improvements, and we haven't tested with that) is still quite slow. The current setup we have is that a c++ function calls a js one to add text to the html 'page', since we don't have direct DOM access in c++ yet with qt webkit. Well, it turned out to be a -real- chokepoint, so we're even implementing an alternative, plain (non-webkit) display for the time being so the client can run on older machines. But even doing the alias/trigger matching and scripting just in javascript would of 'ouch'. |
|||
|
|||
|
Hey Vadi, Neat looking client. So far as ZMP adoption, I'm not aware of a great deal of it. Not a single MUD operator has ever contacted me about it, although I do know of several clients that support it. (gnome-mud is the most recent, just added support a couple months ago.) Regarding your performance issues, I can attest that JavaScript is more than fast enough. If you're having performance issues with something as trivial as triggers or aliases, it's probably your code and not JavaScript itself. To imply that it would have trouble with simple text matching would mean that JavaScript is literally 10 orders of magnitude slower than native code, which is absurd. Even the JavaScript engines of several years ago were faster than the classic Ruby runtime engine, and that was (still is) used on servers -- processing large volumes of text -- running sites serving hundreds of thousands of visitors per minute. Ruby, up until 1.9, internally just executed an AST, not even bytecode, which is quite a bit slower for a great number of reasons... and yet it has no problem at all doing heavy text processing, GUIs, and so on. What you can have trouble with in a web environment is the speed with which you can update the DOM. It comes down to understanding what triggers re-layouting (not a word... what would be the right word?) in the DOM implementation to avoid the huge slowdowns with simple text updates. It's not hard, but it can be a little counter-intuitive at times (especially with IE6/7). I'm imagining that your JS function probably just did something like appending a DOM TextNode (or worse, appending text to an innerHTML element) which is always going to be horrendously slow, even if you do it from C++. When you do that, the layout engine completely recalculates everything for the whole block (and then any parent and blocks, and possibly sibling blocks depending on specific structure and CSS used). WebKit might also have some kind of performance issue with its C++/JS bridge, much like how the LiveConnect system in Mozilla (Java/JavaScript bridge) is ass-slow due to the moronic JRE design of running every line of code in 10 different threads. (Hello context switches, goodbye efficiency.) Or WebKit might just have shitty performance for DOM updates in general. Possibly something which is fixed in WebKit trunk already, if that's the case. Firefox 2 made huge leaps and bounds in terms of performance improvements for DOM manipulation, which made WAY more impact on web application performance than the TraceMonkey stuff is ever going to do. It's a lot like the original Java GUIs. People claimed (many still do) that Java is many times slower than C, despite benchmarks proving that a decent JVM is only about 3x slower. The problem was that the classic Java GUIs were just horrendously designed and made use of extremely inefficient algorithms and communication mechanisms... and much of the code in those libraries was native. |
||
|
|||
| Well, you're certainly welcome to help us out with the speed once the first release is out (and the code with it). The slowdowns just tend to occur on ANSI color maps now after we did optimization - because there practically every chacter requires html code, making the whole thing quite huge. We're also going with full utf-8 support, and that bites on the speed. |
|||
|
|||
|
|
One of my clients uses WPF\XAML controls for text output. This is only significant because the Rich Text Editor box uses a kind of syntax that is extremely similar to CSS\XML. You should consider using primarily spans, rather than individually wrapping each character, which I'm not sure why you would do unless your test case involves every character having its own ANSI setting. There's a chance you already do, but just the way you said it made me offer that up. What I generally do is start a new span on an ANSI open and then close it when another ANSI tag is opened. Even that isn't really optimized, but I haven't gone back to it yet. |
||
|
|||
|
|
You shouldn't be doing extra HTML tags for every character, unless you're playing one of those "epileptic seizures are sexy" MUDs. What works best is to try to operate on whole lines. Each line is its own div. ANSI state changes end and start span elements, with an appropriate class set for the ANSI state. A little work to deal with incomplete lines (usually only happens for prompts) and you're golden. |
||
|
|||
| Ah, I'm afraid you missed the "ANSI color maps" part, where each character is a different foreground/background color. Normally we just use spans for lines & prompt and divs for paragraphs, so it's decent. |
|||
|
|||
|
|
No, I got that. My point is, each individual character is not a different color in any sane MUD. Usually a single color is used for a whole word or phrase. You don't need to set an attribute on each individual color when you can wrap all adjacent characters that are the same color in a single span. I'm not sure what a "paragraph" is in a MUD, since TELNET offers no markers for such things. I recommended a div per line for performance reasons, though. You want each line to be its own block element (which is also achievable if you set display:block in your line spans) in order to reduce the amount of time the engine spends recalculating text layout when you insert more text. |
||
|
|||
|
|
I've seen the rainbow colored words in some MUDs. My eyes, they bled. =( |
||
|
|||
| Yes, we do exactly just that - but ANSI color maps is a case where practically each character has it's own colors. Here's an example: http://www.ubuntu-pics.de/bild/4038/screenshot_01_B0nTRO.png | |||
|
|||
| I have an older version of the client atm, I believe we optimize out the unneeded normals now, but here's how that map looks in HTML: http://pastebin.com/m30edd106 O.O |
|||
|
|||
|
|
Ah, gotcha. Looking at the HTML, I am wondering why you're slapping in individual style attributes instead of just using a CSS class or two. You can make a set of classes for foreground colors, another for background colors, and significantly cut down the amount of data stored per element. Plus it makes changing color settings easier: just dynamically change the CSS class properties. |
||
|
|||
| Okay, we'll give that a try later on. | |||
|
|||
Good news for Mac people: http://mudlet.org/115/mac-version-is-here/ |
|||
|
|||
| See http://mudlet.org/134/mudlet-pre-alpha/. Beta was delayed, but a pre-alpha started - if you have good lua experience, please give this a try! Sneak peek at what you can do: input manipulation. Heiko made this small sample script... regex: say.*(\w+).*(\w*).*(.*) command: sendRaw( "say " .. matches[3] .." " .. matches[1] .." ".. matches[2] ) result:  l]And other interesting stuff. If you know Lua well, please join in the testing . |
|||
|
|||
| Just wanted to point out that 1.0 is now available. | |||
