Thread: Updated tile editor screens

This is basically a re-designed interface for my tile editor. It still has some painting issues that are easily solved but overall I like it.

The far right docked window is a CDockedDialog derived from CDialog. It's my own custom class that allows you to use dialogs as non-popup modeless windows that can be docked to the frame. I can also use tabbed dialogs inside of dockable windows unlike the default CPropertySheet behavior.

The tile palette window is composed of a custom CPropertySheet-derived class with custom CPropertyPage classes which use CTilePalette windows (derived from CWnd) to draw the tiles.

The actual view is drawn by a separate CTileRdr class. Initially I had the same class drawing both views, but it was too cumbersome so I created two specific classes for this.

So far I think it is coming along quite well.

Ok so maybe this is a Windows post, but hey it's for a game editor so that counts. Doesn't it?

Calling ShowWindow() from inside of OnPaint() sort of defeats the purpose because that will in turn call OnPaint() again. If it didn't work right the first time, it probably would not the second time.

Without looking at your code I have no idea why that would be happening other than your window style might not have WS_VISIBLE in it.

The transparent windows are actually something that is readily supported by Windows XP and is quite simple to achieve. The results, as you see, are very impressive and make your application stand out among many.

Code:

PWnd->ModifyStyleEx(0,WS_EX_LAYERED);
pWnd->SetLayeredWindowAttributes(0,alpha_value,LWA_ALPHA);

That's it.

For drawing inside of a CDialog, it's quite simple. The dialog is pre-drawn for you with the existing controls and then your OnPaint() is called. You just use the dc and it's associated drawing functions to do some custom drawing.

All of this has come out of research as to why CRebar, CDockBar and CControlBar work the way they do. There really is no big secret and most of the work is done by Windows.
In order to do custom docking you must figure out how to resize the client area of a window. MFC provides no mechanism for doing so which would be easy to implement. The simple way is to do this:

pWnd->SetWindowPos(NULL,x,y,width,height,SWP_NOZORDER | SWP_FRAMECHANGED);

SWP_FRAMECHANGED will cause a WM_WINDOWPOSCHANGED message to be sent to the window. It also tells Windows to resize the client area to fit the new dimensions. So if you trap for this message in OnWindowPosChanged() you can readily perform much needed actions such as resizing memory DC's, bitmaps, etc. You can re-compute your scroll values and update other information vital to the resize.

After this is done, the client window will now reflect the changes. The problem is that the area that 'opened' as a result of SetWindowPos has nothing on it and therefore is not updated. The solution to docking windows is to create a dummy dock window that just draws it's children in OnPaint() so the background area is now covered and it looks like a docked window.

So a docked window has two parts to be done correctly. The actual window to be docked, and a dummy window that acts as the client window for the docked window. If you notice in the default behavior of docking windows in MFC, if you specify WS_CAPTION and attempt to move the window, it is clipped by the docked area indicating it is a child of that window.

Using this information I believe I can achieve any type of custom docking I want to with little effort to include using property sheets and pages as dockable windows.

To float the window you just trap for the user clicking on the gripper area which you then resize the client window, hide the dummy window, and set the dialog style now to (WS_POPUP | WS_CAPTION) and remove the WS_CHILD attribute. Now the dialog is floating like normal dialogs.

Pretty complex, but once you understand it, it works like a charm.

A friend (windows-hater) recently showed me a new Linux distro which was able to handle transparent windows very fast. He didn't like when I told him that Windows has had that feature for six years.

Hey Bubba, looks great as always man!

Here is an updated view with the painting fixed and my docking dialog working as it should.
The tile map here consists of 4 layers which allows me to do some very interesting things with the maps. Sprite will always be drawn on a certain layer and I believe we have decided it will be layer 2. Layer 3 will be for drawing overhangs and certain effects.
If I get really crazy I might set each layer's scroll speed to be in accordance with it's z layer from layer 0. That introduces some new problems, but it would look cool.

Don't ask me why I'm coding a Zelda 2D engine that far surpasses anything Nintendo ever did. I guess it's because we are not allowed to do 3D so I'm trying to pull all the stops out for 2D. Hopefully the artists will come up with some tile sets that 'hide' the grid rather than accent it and make it stand out like a sore thumb.

More screenies. Added a list so you can view all tiles in memory and their associated IDs. Changed the vector in the manager to a map so I can now change tile ID's on the fly. It does not change the tileset the tile appears in, just it's ID when written to disk. When it changes ID's it simply performs a swap. For instance if you assign a tile with ID 50 to ID 1, 1 becomes 50, and 50 becomes 1. Simple enough.

Notice my docking dialog is working just about flawlessly. Once it's fully implemented you can have any number of docking container windows with any number of docked dialogs docked inside of those windows. Hopefully later I'll add dock-to-float support for each CDockDialog.

This is sort of a blog post I reckon, but it shows how easy it is to make game tools with MFC.