|
SoCoder -> Blogs Home -> Blogs |
|
|
|
|
Cower
|
MilkAs the fiddler fiddling |
Milk is an experimental editor I keep rewriting from the ground up every time I go to work on it. It's meant to be something of a brush-based CSG editor, sans CSG. Basically, building environments using primitives and patches as you would in Quake 3 (anyone who's suffered my ramblings about game development is probably well-aware that I consider Quake 3 to be the high point in ease of use as far as dev tools are concerned). I've only ever gotten as far as getting very basic brushes into the editor before scrapping it. This is the current iteration: Originally, Milk was written in C++ using wxWidgets, and was cross-platform between Windows and Linux. It looked something like this:  This was an early UI test, so it's not really representative of what it looked like before I dropped it in favor of a rewrite. It was a lousy app in terms of structure, and even after rewriting the app several times I've repeated the same mistake far too many times. Right now I'm in the process of doing another rewrite, which is what I wanted to talk about, since I finally got my head out of my ass and thought about how I would do this before actually writing any code. It still sucks, probably, but it sucks a lot less. Mainly though, I want to talk about the viewports in the editor, since these are what you interact with most in an editor like this. If there's a flaw in the viewports, it's going to ruin the entire app, end of story. You can have a beautiful sidebar, and I do currently, but it's not going to count for shit if your viewport can't be worked with, either by the user or in your own code. First off, the original implementations of the viewports in particular was bad. I still have the source code, so I'll try to outline very briefly the main issue: the viewport was a monolithic class that handled just about everything that looked at it funny. Input and such were handled by it, and that was normal. You should probably expect that. But it also handled brush creation, it handled every single rendering feature embedded in the viewport, etc. and none of this is easily removable, except perhaps the grid drawing code that I keep reusing (because it just works). The code ended up being messy, the way the components all interacted was highly unpleasant, and it just didn't work out in the end. I've repeated this mistake in designing Milk a number of times, and I won't be surprised if I make the mistake again in some different way (bad design in general). So, I'm trying to do myself a favor now and break up the viewport code into smaller components. First off has been the rendering, which is being pushed off into subclasses of an NRenderer class. Like so:  Next, I'm thinking I'll have some code to handle input in terms of context. E.g., if an event is received, it'll be passed on to each context until one can accept it. If none accept it, then the input was useless. The renderer subclass is intended to only communicate with a viewport when it's drawing, so I'm still not sure, yet, how I'll get multiple renderer components to synchronize data with each other. It's probably not as complex as I'm thinking it will be, and some data will still be better off stored in the viewport class (current X,Y,Z location and such, so for example the grid/brush renderers will draw at the correct offset and such). At any rate, I think the end result here will be a little more useful in the long run, even if this ends up being canned again. |
|
|
|
|
Comments |
|
| |||
|
| ||||