Zugg Software :: View topic

Posted: Wed Oct 05, 2005 1:50 am

Well, I'm very disappointed today. I had a really cool vision for the new interface in zMUDXP. But apparently my vision is well beyond what is possible in Windows.

My vision was to use DirectX (or some fast graphics routines) to create a layered main MUD window. On this window you could create semi-transparent (alpha blended) chat windows anywhere you wanted them, and resize them and move them around. You could also place buttons and gauges anywhere you wanted them and also set them to be semi-transparent.

Basically, the idea was to mimic the interfaces used in MMORPGs such as EQ or WoW except without any 3D world view...just chat windows and other interface elements.

Well, I've verified that while extremely difficult, it *is* possible to do this. The problem is the performance. To be blunt, the performance sucks. You can actually verify this in WoW by making the chat window full-screen and then looking at the jumpy scroll rate.

First, normal DirectX has no hardware support for alpha-blending (transparency). Direct3D has some hardware support for alpha blending, so you end up having to convert stuff like the chat windows into 3D objects (textures), which has it's own overhead. In addition, neither DirectX nor Direct3D directly support normal Windows fonts, so you have to either create your own font or convert existing fonts.

And even when this is done (which took me over a week to even get a test program working), the scrolling performance is *so* much worse than normal zMUD that it is basically unusable (we are talking over 100 times slower!).

The other problem is that in Direct3D mode, the normal GDI components, such as edit boxes, buttons, etc cannot be used directly. So I'd have to create an entire set of user interface components designed for Direct3D. There isn't anything good for Delphi that I can even buy. And none of the free stuff I have found for Delphi is even documented at all (stuff like DelphiX or Asphyre). And this would mean not using zApp, which defeats all of the other benefits that I was planning. So that's no solution either.

So, DirectX is out. Without DirectX there is a Delphi library called G32 that has some faster alpha-blending routines. They seem to work better than DirectX, but are still much much slower than normal zMUD scrolling. Also, when working in normal Windows GDI mode, I have to perform some tricks to make the existing controls transparent. And unfortunately, Windows doesn't support transparent controls very well. The new WS_EX_Transparent style in Windows 2000 and XP helps, but has lots of bugs associated with it. So even outside of DirectX, doing alpha blending still has lots of problems. I'm still pursuing this possibility, but it's not looking good.

I was really excited about the possibility of this new flexible interface. But it looks like I'll have to stick with a more traditional interface (docking windows, etc...but with new fixed docking code from zApp).

I still think there will be enough differences in zMUDXP to make it worthwhile. But I'm disappointed that I can't *wow* everyone with this completely new interface. This is exactly why I wasn't hyping my ideas until I could verify whether or not they actually worked.

Frankly, I was amazed that there wasn't hardware support for alpha blending with DirectDraw. And I'm also dismayed at the lack of text support in DirectX. No wonder game companies need dozens of programmers these days. I was also very disappointed in the lack of decent components for DirectX in Delphi. The much-hyped DelphiX stuff is just horrible with no documentation.

My vision is that someday we'll have an operating system that supports Layers properly. I'd like to be able to specify which layer a particular control (button, edit box, etc) goes on and then set alpha channels for each layer. I don't even think Longhorn will do something like this. Although if it does then it looks like we are in for an even slower operating system unless that hardware support for alpha blending improves.

Since zMUD is all about speed, and I want zMUDXP to be even faster, I guess I'll have to give up on my dream for a fancy graphical interface.

Of course, if anyone thinks they know of some Delphi resources that I'm missing, or knows of some tricks to do alpha-blended layers in Windows, then definitely let me know. I've already done a ton of Google searching on this, but maybe I missed something.

Posted: Wed Oct 05, 2005 5:33 am

Take heart Zugg... Windows Vista may offer some of what your hoping for... (at least if I fathomed my quick glance at Avalon, and siphoned away all the marketing crap)

I know that it doesn't help much for now.. but when they retrofit some of it back, you may be able to use some of those features in a year or two.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Sounds like Longhorn is what you're after. There's a snap from MS' website with a few transparent windows etc and they make a fuss over how graphics intensive it'll be.

Avalon and Aero Glass being their snazzy names for it all.
I think maybe Avalon is supported in WinXP SP2.

Perhaps possible to add in the features but make it possible to turn them off for the time being?

Posted: Wed Oct 05, 2005 3:16 pm

As cool as it seems, the idea isn't very useful. IMO, it is quite disconcerting, reducing clarity. Personally, any UI that does this gets dumped from my setup, and I actually focus a window if I'm interested in its content. What a novel concept. If you've ever worked with AutoCAD (2004 and up) and its inane transparent palettes, you have had firsthand experience with this type of junk.

Adept Joined: 04 Feb 2005 Posts: 246

Since I haven't seen a mock-up of what Zugg had in mind, I can only imagine... but I think I would think that it isn't all that useful, at least to me. Layering and transparent windows can somewhat work when you layer on top of an image that isn't too "busy" and when what you are layering on top of is not all that important itself. But given that you might be layering a text chat window on top of other text, I would think it would make it next to unreadable. Either the front window has to be so opaque that you can't read behind it (in which case, why bother) or the front layer is so transparent you can't read it.

Eve Online has transparent windows, and when layered on top of other windows, I need to re-tile them so they are not.

Plus, the idea that these element are constrained to some sort of "main zMUD" window is not all that attractive. I think a much better windowing model was that created for the now-cancelled WISH MMOG, where the game allowed its sub-windows (inventory, map, chat, etc.) to be dragged *outside* of the confines of the main graphics window. Granted, zMUD can do this now (for windows, not sure about stuff like buttons since I don't use them). I just wouldn't want to see this go away.

Posted: Wed Oct 05, 2005 4:21 pm

nema32, I mostly agree with you. The way "alpha-blending" and "transparent windows" have been implemented in Windows 2000 and Windows XP is very bad. What *I* wanted to do was to have a semi-transparent window background (so that you could see your map behind the chat window, for example), but have the foreground *text* NOT alpha-blended.

All of the routines I have seen for WinXP make the *entire* window semi-transparent. I just want the background to be semi-transparent...I don't want the text to fade too. As you said, if you fade the text it just makes the window unreadable.

Maybe Microsoft will improve this in Longhorn, but I doubt we will see any backwards compatibility with WinXP. Hopefully they will pay more attention to details like having a separate alpha-blend for just the background of a window rather than the entire window. Otherwise it's just a gimmic for eye-candy and not actually useful.

Anyway, for zMUD it was more about being able to see your map behind your chat windows rather than overlapping multiple chat windows. Also, the ability to put a semi-transparent button over part of your chat window would have been useful. For example, the space on the right side of the chat window isn't used as much, and putting semi-transparent buttons that become more opaque when you move the mouse over them would have been interesting.

Anyway, thanks for the feedback. I think I'm going to spend another couple of days rethinking interface ideas.

In fact, if people want to use this thread to discuss their "favorite user interface" ideas for zMUD, I'd be happy to listen. Wonder whatever happened to that guy who thought he had all of these great ideas on how to improve the zMUD interface?

Adept Joined: 01 Mar 2005 Posts: 277

Zugg, I have some Win2K\WinXP API's that will make the window transparent but not the text. You can still use DirectX by drawing to a canvas control and then using the API for making the background of a window transparent.

SpriteCraft can attach to a picturebox (canvas control's) handle. Make the canvas control full screen and then display owner forms with the transparent background (but visible text.)

BTW, SpriteCraft can use OpenGL or DirectX I belive.

Posted: Wed Oct 05, 2005 4:45 pm

I would think having a background that consists of your map would be doable with just the GDI. I mean, there have been toolbar backgrounds for years, and I assume they are just blt'd in WM_ERASEBKGND or perhaps in WM_PAINT.

You'd just set up a memory DC, have the mapper window use that, and then copy it onto the chat window after perhaps operating on it to make it lighter, or whatever transparent effect you need. You'd have to worry about how to scroll the map, and stuff, but once that happened, you'd just invalidate the entire chat window, and viola, the background would be updated.

Anyway, I don't like that sort of thing-- information overload which results in unusability... I just keep the mapper window off to the side, completely separate. Works fine even at 1024x768 for me.

Also, just because I don't like transparent windows and similar ways of "saving" screen real-estate, doesn't mean it's bad. As a developer, I certainly understand the "do what Microsoft is doing" camp. I just don't usually agree their latest interface novelty. Back in the 3.1 days, they had pretty good standards, but now, Office and Visual Studio just usurps my _chosen_ selection color and uses its own predefined color for selected menu items. This infuriates me to no end as does a lot of their latest concepts which tromp all over your custom adjustments which you spent considerable time getting just right.

The difference is that not all users work the same way. People like me who sit for hours in front of their computers doing real work tend to be much more concerned with clarity and ergonomics than the casual user who browses the web after work. So, even though I believe their new interface is complete garbage, I predict it will be a stunning success.

Beginner Joined: 27 Feb 2005 Posts: 24

What might be a possible option is to have "tabs" on the right side of the screen, and when your mouse goes over them, they roll-out towards the left. (a real roll-over, not a rescale of the windows) So that maybe you can hide your map/status/chatwindow/settings/panel with buttons/other there. But that way they are still easily accessible.

Posted: Wed Oct 05, 2005 7:41 pm

I need to give you more information on the speed requirements here...

zMUD is able to scroll 2000 lines in 0.4 seconds, updating the display every 10 lines.

That's 200 "frames" in 0.4 seconds, or 500 FPS.

500 FPS is an incredible update rate. This update speed is what makes zMUD faster than anything else out there.

As soon as you add any sort of BitBlt for a background image or any sort of fancy effect, this rate drops tremendously. For example, if I paint to an offscreen bitmap and then BitBlt the image to the screen, then the above 2000 lines get displayed in 13 seconds, for a FPS of 15. That's 30 times slower just to add a background image!

Think of it this way...without a background image, zMUD just needs to clear the screen and then output text. This can be fast. By displaying a background image you are essentially replacing the ClearScreen call with a BitBlt. This is obviously much slower.

DirectX has a faster BitBlt. The problem with using DirectX is that you loose all interaction with the controls themselves. You can "paint" the screen faster onto a DirectX Surface, but that surface no longer knows anything about what's on it...it's just an image. For example, if you paint an Edit Box onto a DirectX Surface, it gets displayed correctly, but you can't focus it with the mouse and enter text into it...it's just an image and no longer an Edit Box.

So using DirectX for chat windows would mean that you couldn't enter text, you couldn't select text, you couldn't click hyperlinks in text, etc. Of course, I could implement all of that myself, which is essentially the same as writing a DirectX Edit box control. As I said, this defeats the point of using zApp for the user-defineable interface. And remember that the chat control needs to implement ANSI color, MXP/HTML, etc. So this isn't any simple job.

So it all comes down to BitBlt speed. If someone can find me a BitBlt routine that is 30 times faster than Windows without requiring me to switch to DirectX mode, then I'd be happier.

The *GOOD* news that I have to report is that I've been doing speed testing of the RichView component that I use for the MEMO control in zApp. This component is used in the Editor demo for zApp. I was able to make some simple improvements to this control that allows it to scroll text as fast as zMUD. Same 0.4 seconds for 2000 lines. The advantage of the RichView control over the current zMUD control is that it already has full HTML parsing, along with flexible tables and other display features. This would remove all of the problems of the current Editor window in zMUD that is so quirky and instantly give me features like Find/Replace, HTML export, better image display, etc, etc. All I need to do is add my ANSI/VT100/MXP parser to it (which is still a job, but not a huge one).

So, at least I know I can make tons of improvements even if I stick with a text-based docking interface.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I know there's a way to get edit boxes/etc working in DirectX, I did it myself when playing around with the concept for my graphical mud client... it had something to do with clip regions or similar.

http://www.rainchild.com/TileTest.zip is the binary example, I will try and dig up the source code for it when I get home.

I based it on examples found at http://www.gamedev.net/ which is a fairly useful source of info about directx/game programming in general.

Btw, with regards to your 500 frames per second... it's kinda moot, given that a monitor's refresh rate is at best around 120, and most of the LCD's that everyone is buying nowdays are around 60.

If you focus on multiple threads, make the input thread handle the 2000 lines per 0.4 second, but only sync the display thread to the monitor's refresh rate so you're not wasting cycles trying to redraw the screen when it won't physically be displayed anyway.

Also, it was a little hard to tell, but it seemed the chat windows in EQ2 scrolled fairly well even at full screen, perhaps WoW doesn't have the best font rendering routines? I have my doubts about scrolling at 500 fps, but they didn't seem to be jerky.

Posted: Mon Oct 10, 2005 1:58 am

A couple of problems:

1) Yes, setting up a clipping region is pretty easy and I've done this. But the API for making stuff transparent and alpha-blended only works for Windows with the EX_LAYERED bit set, and this doesn't work for individual controls. So you can have a full edit control on top of a DirectX background, but no way to blend the background of the edit control with the DirectX background.

2) You can't do screen updates in a background thread. Only the main thread can update controls and user-interface stuff, at least in Delphi. And I also have no idea how thread-safe the DirectX stuff is. Typically low level hardware access kind of stuff isn't a good idea in a thread.

In any case, it's pretty much a moot point. I'm going to concentrate on some other features that are actually *useful* rather than worrying too much about the pretty visual aspect of it. At least to start with. Nobody is going to want zMUDXP if it just has prettier graphics...it has to have some major new functionality and that's what I'm working on for the next couple of weeks.

I just had to vent about the user interface issues because it was frustrating at the time. I'll take a look at the link you posted...hopefully they have some Delphi stuff which seems to be pretty scarce.