Beginnings of my editor.

About Monkey 2 Forums Monkey 2 Projects Beginnings of my editor.

This topic contains 49 replies, has 5 voices, and was last updated by  Angus 8 months ago.

Viewing 15 posts - 1 through 15 (of 50 total)
  • Author
  • #11512


    I’ve been working properly with mx2 for a couple of weeks now I guess.  Converting code and having lots of fun.

    The system that I’ve used for a few projects has been gradually evolving for years, but my lack of an editor has made defining my tricky graphics objects slow and ineffective.  Writing a really good editor is a huge job I know, and I’ve always put it off, but the time it takes to do things by hand has overcome my resistance.

    As I started it in Monkey1 I began my own GUI, which seemed redundant on moving to mx2, but I’ve stuck with it anyway.  At the moment the GUI does the bare minimum I need it to, but I may develop it more (probably will have to).  I couldn’t stop myself modelling it on BlitzPlus, so I’m more familiar with the style than mojox anyway, I think.

    There’s very little to show just now, but I’m chuffed with the way it’s gone so far.  The features of Monkey2 have already improved my code, and the potential of what the editor might end up doing.  I’m sure I’ll get more out of it as time goes on as well.

    Here’s a proto-editor pic.  I guess a shot like this isn’t exciting to many people other than me, but it’s a great feeling to have made quite a bit of progress in a short time.



    Brilliant work. Gui stuff is never simple and it looks really slick.



    Thanks!  When I think about it, I’ve probably written half a dozen GUIs of varying usefulness over the years, so “bare minimum” isn’t too little.

    I knew I’d need a full-function string field, drag n droppable treeviews, tables, general scroll-panels and an event system (besides obvious windows and various buttons) to make it at least usable so it’s not too bad.  It’s also pretty versatile in terms of skinning, though perhaps not intuitively so.

    Nothing is missing to make my editor, but you couldn’t make a document editor out of it at the moment.

    Also it’s a bit inefficient to draw at the moment, I’ve just realised.  But it still seems very very fast, even with screens full of text… Strange.  I have a pretty sound plan to make it properly lean to draw if it becomes a problem.

    Though the screenshots are hardly thrilling for now, I’m pleased with the quantity of groundwork I’ve laid.  Extending the objects I’ve been using for a while to make them “editor ready” has been a lot of work, but I’m sure I’ve got most of the functionality there.  My hope now is that progress will be relatively gentle.  But that’s a laugh 🙂



    Been sidetracked by long-anticipated improvements to my treeview gadget, which have been semi-successful.  It works, and slightly better than previously.  If I find it getting too slow I might have to go back to it.

    Been very frustrating to be held up going over old (and also basically functional) code, though.  Glad to be passed it and microscopically further on with the thing as a whole.  I needed to make sure the treeview was properly sturdy as plopping objects in and moving them around in a valid way was important.

    Evidence of creeping progress below.  Again not exactly exciting for everyone, but heyho 🙂

    And yes, I have heaps of icons to define.  They’re the tip of the iceberg, really.



    in the tree editor, check the image sizes being used and also the alpha component. Monkey2 can use transparent png files without issue.

    The yellow “folders” look more like blobs than folders, so maybe have a look at tightening u you icon graphics so they don’t look to square?

    Just a suggestion 😉



    Pretty good suggestion, really 🙂

    I’m using a png with transparency already (all the text is drawn from such a texture), the look of the object icons was actually a deliberate (albeit daft) choice!  And I agree that shrunk so small the folder is really a blob.  I’ll re-think the look of those things, they have to look ok very very tiny.



    take a look at the base win32 icons:

    MS used a very limited color set (carefully chosen) that worked at very small resolutions 16×16 pixels.



    Daily updates may be dull for everyone but me, but I’ll persist as it slightly motivates me 🙂

    I made a tiny difference to my icons: redrew the folder and simply disabled one of the GIMP layers that was giving them their frame.  A tiny thing really, and they need more done to them than that, but it does look better I think.

    Much more important are those two tiny buttons I’ve popped up at the top right (edit:top left, been a long day…), which control the undo history for which I’ve been laying groundwork for days n days :).  It’s been a hassle, not something I’ve coded to such a degree before, and is still the framework of the system.  But I’m absolutely chuffed that it works as far as it does.  Not that you can do anything other than move objects around the scene tree at the moment, but it tracks it all and lets you undo and redo through it.  Next will be the most basic class editing window to test the next part of the history stuff.  Setting vectors.

    More quite boring shots to show the snail like progress…  they give me a little thrill 😀



    Another day, another half dozen tiny things that are almost invisible to the naked eye 🙂  The most basic of editing facilities is now present, and I can set the components of a vector.  Still not thrilling, but shows that another class of action is doable, undoable and redoable.

    In the process I realised that changing a name is different to changing values, which made me think about how to change names conveniently, which hurried my implementation of right-clicks in my gui.  When I was developing it in Monkey, I seriously wanted it to be something I’d use on Android devices, so I quite rigidly stuck to only sensing one mouse button.  For a while I’ve intended to change it, and today’s stuff moved it along.  I’m not exactly delighted with the way I’ve done it, but it’ll do for now.  Context menus are here, hooray!

    It’s slightly fun to see some numbers being set and remembered.  It’ll be much more fun when I can actually see my objects in the backdrop, but that’s not too far away.  Most of the object manipulation will be done on the canvas, but I want to get these essential and boring parts out of the way first.

    For the time being, context menus and the most basic of basic editing:



    Not much of an update but things are continuing.  There have always been a few parts of this project I knew I’d have difficulty thinking through, from inexperience or daffyness.  I’m  optimistic as quite a few of those parts are behind me, but I’m at the penultimate big problem just now.

    I need my objects to track references from outside objects for re-connection when being un-deleted.  I think I need that anyway.  At any rate it’s how I’m doing it and now I’m doubting it all lol.  I’ve tried pretty hard to think of ways to avoid weighing my classes down with further baggage that is only required for editing purposes, but it’s not too bad.  The reference-knowledge will come in useful for the final big thing I have to worry about, which is maintaining relative internal references when copying groups of objects.

    I’m pressing on and making the reference tracking thing just now.  There aren’t that many interlinks so it’s not too much work, it’s just not a thing I’m familiar with thinking about.

    I also have a niggling feeling that I should be using operator overloading in a Reference class to really streamline this whole thing, but I’m on  a knife-edge of risking the effort it would take to find out if I’m right when I’m pretty sure the more clunky way I’m doing it will work…  clunky way first.

    In the meantime, a couple of tiny other things are appearing, I can’t resist showing microscopic advances.  Here shows that you can edit object names (also undoable… I know that should be totally obvious, but I’m still pleased with it hahaha) and that the transformation tree window has appeared.  Though it’s very dull.  Also gone are control buttons at the bottom of windows, they seem pointless with context menus.  This may be against the best practice, I don’t know, but I prefer it.



    small thoughts on the list (still I know)
    make your – + boxes a bit smaller
    think about a folder as open and closed, so when it is not being used it is closed
    one last trick is not to use lines of the list connectors, but dotted lines – makes them look nicer. Easy if they are graphics, not so easy if they are a drawn line

    the blue used in your selections. is should possible be lighter so the black text stands out – again look at windows and the ui systems. If I remember they used a more desaturated color.

    Also watch your alignments with the ok/cancel buttons. if you look to the text boxes above – they jar slightly.

    But in saying all of that – brilliant work 😉



    Thanks!  And fair points, I tweaked some things based on them.

    Making the tree branches dotted in a nice way is tricky as they are rectangles with images drawn from a texture atlas (in fact all of the gui comes from one texture) but I agree they were too severe.  I lightened them and may do something else to make them fainter, or remove them I’m not sure.

    I don’t want to go too pale with the selection colour, it is also the colour for selected text, which up til now has been white within the selected area and still needs to contrast.  I could of course just make the selected text black as well.

    Anyway, it’s super easy to get distracted making these small adjustments when I’ve got horrible confusing things to write 🙂  onward onward



    I was once in a physics class in school when the teacher, smiling wearily, held up one pupil’s homework for everyone to laugh at.  We were supposed to design some sort of parallel light circuit and the guy had come up with the most insanely complicated network of wires and switches densely packed across a page of his workbook like it must have taken him hours.  He seemed to take it in pretty good humour when the teacher basically encouraged everyone to laugh at him, poor guy.

    I remember that day a lot, and trying to come up with a nice way to manage object references is giving me flashbacks.  I am sure I’m missing an obvious solution using a structure I’m not familiar with and it’s creating head-spinning confusion.

    I’ll get there.  For what it’s worth I am much further on in my thinking than I was yesterday.  Just not there yet.  Not even a snails progress of visible difference 🙂



    there is also another way to think about things:

    Maybe a list control, or drop down box, or whatever control is NOT the best way to show the inner working of some things.
    If that is the case it is VERY reasonable to come up with another type of control that does the job better.

    An example of this could be shown in iphone and other phone guis that completely took a different approach to what and how a UI should work.

    In your example of demeaning a guy in class for designing something over complicated. Was this actually tested? Usually it is the end result that matters not the getting there?

    Looking at the last image. it seems that there is a project. is there only one open at a time? if yes, then you can start to simplify:
    the scene box contains a project. but why not remove the project entirely and just leave the bits that are in the project

    Here’s a thought about lists for you:
    They inherently grow (usually down), the moment the go below the container box you need scroll bars or some other way of seeing the rest of the list. long lists get messy and humans are not good with long lists of things – they tend to forget what the list is about.

    If your lists are going to be filled with lots of stuff maybe look at a different approach.

    An example of this would be the file list of assets. Lets say 3d objects. Here is a visual and instantly usable way to show assets in a folder:

    there are no names, just the assets



    Thanks for your suggestions, they’re not wrong.  I’m just in a bit of a funk ‘cos I’ve been very confused by the things I’ve got to do but even now I’m a bit clearer about it.

    I agree about the way the editor is just now, very “wordy”.  I also agree that eliminating the “Project” node of the scene tree would be better, but it’s actually a real faf considering the way these things work 🙂  The parts that are there now are sort of a necessity.  As nice as it’ll be to drag and position sprites and curves and physics bodies, sometimes you really need to set a number, or organise the parts into groups for copying or designating as new objects.

    In fact all of the horrible things I’m doing now don’t change much depending on how the editing is presented.  The window names that are visible at the top of the display act like the bar at the bottom of Windows95> and can be used to bring windows to the front or minimise them.  I hope to spend most of my time with them minimised.

    The bit I’m doing just now will answer the question:  If I remove an Image that 50 sprites reference, then undo that deletion, how do I reconnect those broken references?

    It’ll do other things as well, but that’s the best way to characterise my present problems.

    Thanks again for the feedback, I’ll get there 🙂

Viewing 15 posts - 1 through 15 (of 50 total)

You must be logged in to reply to this topic.