Zugg Software :: View topic

Newbie Joined: 27 Oct 2006 Posts: 5

Once upon a time I heard that Cmud would support sexier health gauges then Zmud... Is this true? or am I halucinating again?

And another small question... Is it possible to display very large text over the entire Cmud interface without disturbing any game play? I may use a dirty word here, but I would like to make a trigger to echo damage over my entire screen so I don't miss it, much like WoW's SCT addon.

And if possible, it would totally blow my mind if you could combine the two, and display translucent health bars over text.

Anyway, have a nice day!

Posted: Fri Oct 27, 2006 11:50 pm

The "sexier health gauges" have been delayed for now. I've had my hands full just getting the gauges to work like they did in zMUD for compatibility. But this is definitely planned.

However, don't look for anything like text or gauges overlapping the main MUD window anytime soon. Any sort of translucent controls over the main text will slow down text scrolling by a huge amount (at least a factor of 10). This is because of how Windows repaints controls, and how zMUD and CMUD perform some tricks to get around this. Anything that requires a background repaint (using a BitBlt operation, for example) makes scrolling ten times slower than the optimized method that zMUD/CMUD uses now. And most people do not want their text scrolling to slow down by this much just for a pretty visual effect.

I've talked about this topic before. I have looked at DirectX to see if there is some speed to be gained there, but DirectX doesn't do much for scrolling text. It is optimized for 3D graphics and it's text handling is very primitive. For example, it's a real pain to use stuff like true-type fonts in DirectX. Which is why you see most games using fixed sized bitmap fonts (or not offering any sort of options for changing font sizes). When you get into scaleable font support, you discover that it's just as slow as the main Windows GUI routines.

So my dreams of fancy translucent buttons and gauges pretty much went out the window when I saw how slow they would make CMUD. It's possible that Vista will offer something better for this, but I really think it's probably a limitation of current graphics cards which are just not tuned for fast text scrolling and font scaling.

I actually use the WoW SCT addon myself, so I know exactly what you are talking about. Of course, WoW is a DirectX app so they can get really fancy with their graphics. The numbers and text that you see in the main window are actually not really text objects. They are polygon objects representing the symbols for text and numbers that can be scaled just like any other graphical object. The way the 3D games work is that you can display anything you want to the screen surface. Then it's up to the graphic subsystem to render the screen. Typically a high-end graphics card can give you decent frame rates. A decent frame rate in WoW is like 20-50 frames per second.

As a comparison, zMUD text scrolling operates at about 500 frames per second. That's the factor of ten I'm talking about. zMUD gets this speed because it's bypassing the normal windows background update buffering.

Anyway, probably way more detail than you wanted. Sorry, no miracles here.

Newbie Joined: 27 Oct 2006 Posts: 5

Thanks much Zugg, and I love the detail there.

Another question for ya though. Would it be possible to run another application that would only wait for information to be passed to it through some COM api or some file writing magic that could produce this effect? Would throwing the data somewhere and letting that program pick it up and process it work?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

That's called a plugin, Sage. As I recall, they haven't been reintroduced in CMud (maybe I'm just thinking of the COM improvements Zugg mentioned)?

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Wouldn't the plugin still cause the slowdown Zugg mentioned?

Posted: Sat Oct 28, 2006 3:06 am

It depends on how the plugin worked. The plugin isn't going to be able to paint itself over the MUD window or anything like that. A plugin can work quietly in the background (no user interface), or it can have a standard form-based user interface. I suppose a plugin could even initial a DirectX window and use that. But since it doesn't directly interfere with the CMUD screen painting, it shouldn't slow it down.

Of course, if the plugin started capturing all of the text from the mud in the Input processing routine, then yes, CMUD would slow down depending upon what processing the plugin did. But I suppose the plugin could quickly put the text into some sort of buffer and then process it in a different thread. But then I could forsee a lot of synchronization issues with the plugin lagging behind the MUD and getting it's buffer full. CMUD processing text so quickly that you'd have to have a pretty fancy plugin to keep up and not get out of synch.

So, in most situations, yes a plugin will slow it down. There is no magic free lunch here. But I can't rule out the possibility of some brilliant programmer doing something I haven't thought of.

And MattLofton is correct...the plugin API is not yet implemented in CMUD. I'm rethinking the plugin architecture since CMUD should allow a lot more possibilities than the limited zMUD plugin model. Probably won't see full CMUD plugins until after the first public release.

Newbie Joined: 27 Oct 2006 Posts: 5

Thankya much for the info, and the quick replies.

PEACE

Wizard Joined: 14 Aug 2004 Posts: 1269

If the plugin took a CMUD #command for its input (perhaps derived from a trigger) then I suppose that should be quite efficient on that side of it - I don't know anything about the graphics side though.