Editor Braindump

posted in Skipping a D
Published May 20, 2009
Advertisement
Almost a week since last update, So I thought I'd just talk a bit about the editor.

For some reason, writing one feels kind of like how doing homework felt. Well, minus the procrastination anxiety. It definitely has that fatiguing tedium of a project that you just want to put behind you so you can get on to other things; a project that, while technically necessary, doesn't really give you the feeling that you're getting any closer to your goal. Instead, building the boat that will get you across the river that separates you from your goal, the whole time wondering if maybe you could just swim it and skip all the bother.

In this case, "swimming it" would be my crazy (lazy?) idea of trying to make levels out of plain text files. Maybe draw the box with hyphens and pipes and junk, and annotate it with some XML or something. When faced with the prospect of reimplementing a property grid control in WPF, that was sounding really tempting. At first I was cursing WPF for not just including one out of the box, but then realized I would need to customize it anyway, so perhaps it doesn't make much difference. Still though, it feels like for every two steps forward, I take another step back; a net gain, but frustrating nonetheless.

I suppose part of the problem is that such a project is nontrivial in any windowing framework, so it's exposing all the weakest parts of my understanding of WPF, of which there are many, even after reading a rather comprehensive book about it. It is by far the most enormous and complex API I have ever used (hardcore win32 hackers will probably laugh, but hey, we're all bound by the limits of our experience). Not just in terms of the number of classes, methods, properties, events, etc. (seriously though, there's a lot, pull up any FrameworkElement derived class and try to mousewheel through it as fast as you can), but in terms of how those classes interrelate and all the functionality they expose: XAML, Dependency properties, routed events, commands, data binding, retained rendering, measure/arrange layout, templates, styles, triggers...

With all of this power available, I feel a constant nagging doubt that I'm not using it properly, or enough. If I just google a little harder, just follow that next link, maybe a whole new and better way of solving the problem will be revealed. In fact, this actually happened when trying make an XNA control. I was looking for all kinds of ways to render arbitrary pixel data. One way I read about involved using reflection to crack open a class and force the data through; another involved using an interop bitmap class and some win32 methods. Then almost by accident I stumbled across some posts about WriteableBitmap, which was added in a later version of the framework and did exactly what I wanted, but that I had no clue existed.

I don't want this to seem like I'm coming down on WPF, cause it's really quite good. In particular, the resolution independence is something I've been wanting for a long time, what with poor vision and the constantly increasing resolution of displays over the years. It's just that learning to use it was very intimidating, at least for me. I think I'm finally starting to come to grips with it though, and most importantly I'm learning to relax and just solve the problem, instead of obsessing over the perfectly elegant and proper solution using every single feature to its fullest.

I have an OrthographicViewport control that I'll use to display geometry viewed top-down in the XY, XW, and WY planes, with 3 more in a tab control that will show height with the XZ, YZ, and WZ planes. The views can be scrolled, zoomed, and updated, with custom major/minor grid-lines for each axis, with numbers on the major line. They're all data-bound together so they all use the same list of objects, and sync up their zoom factors and scrollbars (scrolling right on the XY display will also scroll right on the XW and XZ displays, etc.). Next I'm trying to make a MultiPropertyGrid that, given a collection of objects, will show only the properties those objects have in common, and allow you to edit them with custom type editors. I'll post some screenshots when it's working.
Next Entry Bleh
0 likes 2 comments

Comments

evolutional
My level editor is hacked together in XNA itself; but it's a simple TileMap editor and so is probably easier to work in than a full 3d editor like yours. I am faced with the need to add controls and am pondering whether to try and work in WPF, WinForms or remake them in XNA itself.
May 20, 2009 02:28 AM
Matt328
A MultiPropertyGrid is an interesting idea. My editor currently uses a property grid, which sits below a tab pane and I envision it being reused for whatever context of items are displayed in the tabs. In the course of the editor, it would be handy to have it able to support if multiple things are selected. Hopefully I'll get to tonight's journal entry in which I plan to show a few screenshots of my progress so far and talk about some of my impressions of WPF.
May 21, 2009 06:37 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement
Advertisement