So, I am remaking a top-down tile based game that me dad was working on in the early 90's. I'm gearing this more towards children in the 4+ year old category.
Anyway, the level editor will be included. Since I'm making this for young children, I need to make certain interface elements work in ways that Microsoft did not plan for. I have to assume that the person using the level editor cannot read or read well. This means that the UI must focus more on graphics than text. The problem is that Windows still seems to be holding on to its DOS roots. I'm finding the GUI to be extremely limiting. Everything is based on the idea that text will be displayed.
I come from a Mac programming background. My dad taught my to program Pascal on a Mac 512KE when I was 8. I spent most of my childhood, into my early adulthood, writing software for the Mac. There is one bit of functionality on the Mac that is missing from Windows and it is a glaring omission.
On the Mac, windows and menus are defined by procedure. The OS has several different types of window and menu procs that the developer can choose from, but there is more than adequate documentation on how to write your own. Now, Windows DOES have the ability to make custom windows, but there are many caveats. However, my issue is with the menus. On the Mac, the menu proc takes messages from the OS and processes them, not unlike a WndProc in Windows. However, on the Mac, I tell the OS what size to make the menu rectangle, where within this rectangle I want to place the items, how I they should be selected, how to draw them, etc. I am given full control over the layout of the menu with the only caveat being that the OS draws the frame and it must be a rectangle. If I want a tools menu where each item in on a 4x8 grid, 32x32 pixels with no text shown, I can do it. An owner-drawn menu in Windows must be in sequential order, from the top down like a regular menu, I tell Windows the size of the items and it tells me where I can put them.
Then there are cursors. Granted, Apple doesn't allow for large cursors either, but this is an old limitation when screens were small and screen real estate was precious. I lose my little 16x16 pixel cursor on my 1920x1080 display often. I've tried Windows 32x32 pixel maximum, but it isn't much better. I need 64x64 pixel cursors for my app. Can Windows display a 64x64 pixel cursor? Sure! If you are willing to increase the DPI settings, thereby reducing the resolution of the monitor to 1990's sizes. I've tried using layered windows as a work around, but there were too many unresolvable issues. What I did find is that 64x64 pixels is a perfect size cursor.
So, everything I have tried to do within the bound of Windows' GUI has been impossible. I wanted a simple, multiple-windowed app that, for the most part, went by Microsoft's standards, with only a few "simple" changes where needed. Now, I find myself using a single, full screen window, and writing a Mac-like window and menu manager in OpenGL.
I don't like skinned apps, but I am forced to make one. I understand Microsoft's reason for limiting the UI, but, again, I come from a Mac background. If anyone here ever had the entire collection of Inside Macintosh, you know that stacked, the books were over 12" high. The majority of the series dealt with the UI and Apple's (anal) UI standards. They went so far as to prescribe the size and placement of the OK and Cancel buttons in a dialog box. And yet, I could create any design of window or menu I wanted, with Apple's blessing. Heck, the process was fully documented. I could do exactly what I have in mind on the Mac with no issues, other than the cursor. Even then, it has been so long since I've done any Mac programming that OS X might have lifted that restriction as well.
Gaaa!
Windows GUI frustration...
Exclusive! Workman blames tool.....
Which platform are you using? .NET? Win32? ATL? MFC? Win32 is very limited and .NET is built upon it, so that's limited too. However, there are libraries available that provide fully customisable menus/dialogs/ribbons, you name it, whichever platform you're using.
Which platform are you using? .NET? Win32? ATL? MFC? Win32 is very limited and .NET is built upon it, so that's limited too. However, there are libraries available that provide fully customisable menus/dialogs/ribbons, you name it, whichever platform you're using.
I'm using Win32, but will need this to be cross-platform.
If you are talking about libraries like qt, I have yet to see anything that doesn't emulate Windows' GUI almost exactly. Most of those libraries seem to conform to the limitations set by Microsoft and most seem to be focused on custom controls. In other words, I can do similar things without ever leaving GDI.
It might help if there were screen shots on qt's page somewhere. What little I could see wasn't all that impressive. I've checked out wxWidgets and also wasn't impressed.
If you are talking about libraries like qt, I have yet to see anything that doesn't emulate Windows' GUI almost exactly. Most of those libraries seem to conform to the limitations set by Microsoft and most seem to be focused on custom controls. In other words, I can do similar things without ever leaving GDI.
It might help if there were screen shots on qt's page somewhere. What little I could see wasn't all that impressive. I've checked out wxWidgets and also wasn't impressed.
No, it's not like that at all. If you need it to be cross-platform, why are you even attempting to use Win32 in the first place?
QT would be an excellent choice, yes.
QT would be an excellent choice, yes.
I personally like win32. But the learning curve is hard. I don't know how mac works. But if you are finding win32 difficult, you probably have to start from scratch with a beginner book like "Programming Windows" (Charles Petzold)
Quote:Original post by maspeir
On the Mac, windows and menus are defined by procedure. The OS has several different types of window and menu procs that the developer can choose from, but there is more than adequate documentation on how to write your own. Now, Windows DOES have the ability to make custom windows, but there are many caveats. However, my issue is with the menus. On the Mac, the menu proc takes messages from the OS and processes them...
Hi, I'm Clippy, the friendly paperclip! It looks like you're not using the right tool for the job!
You want to build a cross-platform tile game. May I suggest Blitz Basic or some such? It's cross-platform and a piece of cake to work with. Instead of fighting an API which was never designed to be used the way you want to use it, you can use a tool that simply lets you get on with making your game. (And, yes, before all you purists jump in, Blitz Basic is plenty fast and powerful enough. There are professional casual games published with it.)
Another option is Unity, but that's heavily biased in favour of 3D games. It's probably best to wait until the v3 release, which is expected to include some improvements to make 2D games easier to build.
If you're hell-bent on using Windows' own APIs—and I've no idea why you would: they are, by definition, not cross-platform—then I suggest looking at DirectX or even XNA, which are actually intended for games.
Quote:Original post by Burnhard
No, it's not like that at all. If you need it to be cross-platform, why are you even attempting to use Win32 in the first place?
QT would be an excellent choice, yes.
Because what I need to do can be done on the Mac and I would assume Linux as well. This would make the programming easier since the only change needed would be the GUI code.
Quote:Original post by stimarco
You want to build a cross-platform tile game. May I suggest Blitz Basic or some such? It's cross-platform and a piece of cake to work with. Instead of fighting an API which was never designed to be used the way you want to use it, you can use a tool that simply lets you get on with making your game. (And, yes, before all you purists jump in, Blitz Basic is plenty fast and powerful enough. There are professional casual games published with it.)
Another option is Unity, but that's heavily biased in favour of 3D games. It's probably best to wait until the v3 release, which is expected to include some improvements to make 2D games easier to build.
If you're hell-bent on using Windows' own APIs—and I've no idea why you would: they are, by definition, not cross-platform—then I suggest looking at DirectX or even XNA, which are actually intended for games.
No, you're misunderstanding the point. The game engine uses OpenGl and is fully portable. The game itself will be full screen and have a custom UI. What I am having trouble with is the level editor. More to the point, the GUI for the tool editor.
I can completely understand your frustration. I went through the same thing building a very basic tile editor using Win 32.
With all the work your going through you should maybe look at writing your own. I've had some pretty decent success rolling out everything I need for a game or editor just using OpenGL or DirectX. But that really does depend on what kind of functionality your looking for. Also I had a lot of conflicts with DirectX and Win32, so in my case it was better to just build them.
The current editor i'm using at work was built with WTL, although its not really supported anymore it does seem to allow for a lot more options.
http://wtl.sourceforge.net/
Adam
With all the work your going through you should maybe look at writing your own. I've had some pretty decent success rolling out everything I need for a game or editor just using OpenGL or DirectX. But that really does depend on what kind of functionality your looking for. Also I had a lot of conflicts with DirectX and Win32, so in my case it was better to just build them.
The current editor i'm using at work was built with WTL, although its not really supported anymore it does seem to allow for a lot more options.
http://wtl.sourceforge.net/
Adam
I haven't looked into this, but I cant see much of a reason why you cant implement your own menus under the Win32 API. I tend to use wxWidgets for this stuff rather than the native API but since wxWidgets uses the native API's for the most part, hopefully you will be able to work out how to do this :)
Seeing as you want graphics and such the normal "File", "Edit", "View" etc. bar is most likely not what you want any more than the drop down menu you get from clicking them, so you can basically just ignore the built in menu/menubar functionality.
So your now left with a basic window with a title bar and border. Now divide this into two parts (most likly using 2 child windows), the top part with a fixed height, and the bottom part taking up the rest of the window. Do whatever it is your doing for your editor with the bottom part.
So now on the top part you put your menu controls, either as simple text buttons like the normal menu bar, icons, a larger button with an icon and text, whatever.
When one of these buttons is clicked on, you create a new child window (make sure this is on top of everything else) with no title bar, border, etc. You can then put your 4x8 grid or whatever on this window. If the user clicks anywhere outside this window, destroy it.
EDIT: Thinking about it a bit more, on the last bit if the user clicks outside the menu then your custom menu window should get an event to say it lost the mouse focus, destroy it on that event. This should also work if the user clicks on another application, or even uses a keyboard short cut (eg Alt + Tab, or the Windows Key).
Seeing as you want graphics and such the normal "File", "Edit", "View" etc. bar is most likely not what you want any more than the drop down menu you get from clicking them, so you can basically just ignore the built in menu/menubar functionality.
So your now left with a basic window with a title bar and border. Now divide this into two parts (most likly using 2 child windows), the top part with a fixed height, and the bottom part taking up the rest of the window. Do whatever it is your doing for your editor with the bottom part.
So now on the top part you put your menu controls, either as simple text buttons like the normal menu bar, icons, a larger button with an icon and text, whatever.
When one of these buttons is clicked on, you create a new child window (make sure this is on top of everything else) with no title bar, border, etc. You can then put your 4x8 grid or whatever on this window. If the user clicks anywhere outside this window, destroy it.
EDIT: Thinking about it a bit more, on the last bit if the user clicks outside the menu then your custom menu window should get an event to say it lost the mouse focus, destroy it on that event. This should also work if the user clicks on another application, or even uses a keyboard short cut (eg Alt + Tab, or the Windows Key).
What I don't understand here is why you want to make your level editor "full screen" and slap your own UI on top of it. Tools like that are much better done with a Window and an ordinary GUI (like QT). You want to focus on the tool, not the UI and there's no point reinventing the wheel. If your code doesn't easily transition between full-screen and window, then I guess that's a different problem.
Anyway, there are a large number of GUI's/templates/patterns you can use on Windows to achieve your ends. It's just a question of choosing the most appropriate one.
Anyway, there are a large number of GUI's/templates/patterns you can use on Windows to achieve your ends. It's just a question of choosing the most appropriate one.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement