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 2 months, 4 weeks ago.

Viewing 15 posts - 16 through 30 (of 50 total)
  • Author
    Posts
  • #11707

    AdamStrange
    Participant

    If I remove an Image that 50 sprites reference, then undo that deletion, how do I reconnect those broken references?

    seems like two initial options
    A. Keep the image, so the references don’t go
    B. update the references to the new image

    there is a third (more destructive way):
    Code the UI and the backend so as to try and keep what is happening as separate as possible.
    it sort of means that the ‘code’ you are showing has all the dependancies with it.

    or…

    you code each UI control for one purpose – possible using a cascade method development (each ‘thing’ depends on another ‘thing’).

    Here’s my approach to UI design
    – core control – this does most of the housework like the base mouse and keyboard, initial drawing stuff and has all the placeholders
    – button extends core – this is the basic button. it really is just the core control but with the mouse over, mouse press, and base drawing. ANY other buttons can just be extended from this with the needed bits added for drawing. the mouse and key code is already fully operational.
    – check button extends button. just add a boolean toggle Selected to the core. now you can toggle and draw as needed.
    – text extends core. text is the same as button but there is no actual UI interaction
    – edittext extends core. much more code to deal with user interaction on editing text
    As you progress, some functions like drawing of text will be removed and put in the core so all controls can have access.

    Here’s part of the import for my core:

    [/crayon]

    You can see I decided to have separate controls for each specific task
    Here’s a pic of this in operation:

    Unify is a normal button
    Smooth and Reverse are extensions that have a different drawing method that allows for the orange ‘hot key’ to be added

    The main thing is you are triumphing over one of the nastiest bits of codeing. UI stuff is always difficult and always needs rewriting half way through doing a task…

    #11716

    Angus
    Participant

    I’m pretty much doing your first suggestion, which is keep the object being referenced in a garbage heap for undeleting.  I still need to be able to link back to the relevant objects at the moment of “deletion” to nullify their references and mark them as invalid.  Also I need to conveniently store the previous references with the garbaged item in order to reconnect them if undeleted.  Long winded stuff, but I’m sort of there.

    My GUI is separate from my other “managed” objects, which I’ve been using variations of for years.  The GUI is pretty new and exists in a couple of pieces of source.  Like I say, my muddle over keeping track of these references is about the objects being editable at all, being able to undo actions like that is the key thing.  (or at least the one that’s presently slowing me down)  I did quite a bit of work to make the objects editable (besides to the gui) but what can I say, I’ve found there’s more to it.  Hardly a completely unique feeling for me 🙂

    The structure I use for my GUI probably isn’t that different to yours.  I’m happy to share the source for it, it’s pretty under-featured (and tangly) though and it’s major issue is that it uses my tweaked version of the mojo Canvas.  It could probably be tweaked back to use standard mojo and still be fine for me, both canvas classes can run together I’m certain.

    Now I’m just enjoying talking about coding because the actual stuff I’m doing is still pretty nasty.  I’m deciding (so far) to use a reference class for all references between managed objects, but in order to avoid casting the “target” field of the class (when needed) I’m creating an extension of the Reference class for each of my other classes.  This makes it somewhat tiresome to tweak to say the least 🙂  I’ll keep thinking…

    #14761

    Angus
    Participant

    5 months of boring old real life got in the way of this, I’m annoyed to say.  Been back at it a month and super frustrated at having left it so long, so often the way 🙂

    Lots of the things I was worrying about before are more or less decided.  I’ve still crazy heaps to do, but finally objects appear in the worktop and a set of widgets determine some of their attributes.  Is pointless to describe how much of a faff making all this has been, and how much being better at maths could have helped me.

    Here are some shots of great excitement to me, even though really they demonstrate how slow the progress is :)…

    It’s pretty abstract looking so far, I know, but the transformation tree is all editable and there are widgets to control it nodes.  Also I’ve implemented multiple viewports which should make some fancy effects possible a long way down the line…  for the time being this is what two viewports looks like:

    And I’ve drawn lots more icons.  Which also serves as a bit of a reminder of just how much editor I still have to write…

    Next immediate thing is loading/saving of entire projects.

    Still finding MX2 a pleasure to use, natch.

    #14762

    Mark Sibly
    Keymaster

    Looks very cool!

    #14793

    Angus
    Participant

    Saving and loading of objects and projects is progressing glacially but with less majesty.  Huge piles of code to control it have gone in and I reckon it’ll all work.  Re-connecting references to objects within the saved group and attempting to reconnect them with objects outside of it has been a confusing business but one I’ve known has been coming up and have (I think) dealt with.

    To properly test all the new saving and loading stuff I’ve got to make more proper editing options for objects.  Each new class I make edit boxes for will throw up more bugs in my copying and read/writing process as I’m able to stress them and see what they do in real time.  I’m prepared for lots of days of headaches, but it’ll be worth it.

    It’s slow going but here’s a shot of a prototype edit box for the sprite class and colour selector… I know it’s pretty “functional” but it’ll have to do until many other higher priority things are made 🙂

    Doing this has made me aware of bugs in my sprite class copying routine.  It’s not an exciting thing to know, but it’s what the next while of coding will be like… uncovering some silly things I wrote a while ago and making them better.

    #14794

    Angus
    Participant

    Also, reading one of the old posts I’m reminded about not knowing I should use Generics to avoid having to auto-generate huge piles of classes.  I feel all grown up 🙂

    #14795

    abakobo
    Participant

    Looking forward to try it !

    #14796

    Angus
    Participant

    And just to show I’m still at it, I tracked down the bug (actually bugs) in my sprite copying and now it’s easier to show that the colours are really doing something…

    I know, I know, it’s tedious without textures.  Next is a texture object editor then an imageDef object editor then it’ll start to look more interesting.

    Actually it’ll only really get fun when my curve and physics things are editable, but judge me on a curve here.

    #14797

    Mark Sibly
    Keymaster

    Not sure if it’s of any use to you, but I’ve just added a new ‘weak reference’ type that is already in the develop branch and will be in the next binary release in a few days.

    Weak references are mainly of use for writing ‘resource caches’ and the like – they are like variables in that they contain an object reference, only they don’t keep the object live for GC purposes.

    #14798

    Angus
    Participant

    I’d have to have a play, but they sound eerily like something I could use.  I should say, though, I’ve come so far down my present route that I may persevere for a bit even if they are just the thing.  I am aware that this isn’t always sensible course 🙂

    I’ll check them out, though.  I may find it’s worth just-one-more re-working.  This is the moment in the development for it, I guess.  Thanks!

     

    Reading back, I said “texture editor” and that’s grandiose.  Really an editBox that lets you select where a texture is coming from, with an ImageDef being a rectangle linked to a texture.  Anyway I digress… on with it.

    #14799

    Angus
    Participant

    One long day of faffing and the texture edit box (really just a load option) done and an image edit box half done:

    Yeh, texture editing just means selecting a different file.  More interesting is the Image editor which about half works just now.  The image inside it scrolls and zooms and will soon have widgets to arrange the image bounds.

    Piles of small and reusable sections of GUI have gone into making these parts work, which’ll accelerate future edit boxes.  The scrolling display for the image selector will also be the basis of my spline editor, for example.  Lots of others, too.  A little bit of fiddling to make it nicer tonight, but I’ll leave finishing the image editor til tomorrow.  All fun!

    Don’t ask me why I have a picture of trump.  The other loaded texture there is more typical of the sort of thing I’ll be scrolling around in the image editor.  I just thought trump looked funny in my GUI.

    #14804

    Angus
    Participant

    SquareTrump celebrates having been loaded from a file that was saved only moments before!

    Loading and saving of projects basically works!  All links connected up again, and broken ones making invalid objects that behave themselves nicely.  Principle is exactly the same as loading project subsets so will test that.  Re-connecting to outside existing objects is more of a gamble but should work fine.  Am super chuffed so far.

    Many things need attention next.  Finishing the image selector is still this afternoon, but next move after that could be one of a hundred things really.  The widget that controls an Xform frame of reference is an ugly collection of hotspots and needs to change into a set of draggable axis for their control.  Hotspots will be more for the object centred on the Xform.  A sprite for example, when selected on the worktop will show it’s Xform widget in the form of a set of draggable Axis in the correct frame of reference, with hotspots to drag it’s offset and size.

    Making clickable draggable lines on the worktop in this way will be my next job I think.  Then other editBoxes.  Plus general cleaning up along the way.

    Edit – looking at it again, there’s just too much trump in that image… will find another texture to play with…

    #14811

    Angus
    Participant

    Thinking about drawing those axis distracted me from finishing the ImageDef editor for another day, but here it is… as usual, exciting mainly to me.

    A draggable box in the edit window, snap and show options for the grid working fine.  I dont like the look of it much, but it’s functional enough.  Scrolling and zooming the grid is fun.  I think I’ll redesign the box to make the edit window larger, though.  I’ve an instinct to make the edit windows of fixed size.  Mainly because they’re easier to design, but also to give the impression of them being set forms.  In this case though, the window is too cramped for easy selecting.  I’ll make it a bit bigger.

    Drawing the nice axis for editing Xforms on the worktop definitely next now.  More opportunity for me to regret not studying maths 🙂 I’ll figure it out, but I know it’ll take about ten goes.

    #14812

    abakobo
    Participant

    Are you using mojox for your GUI, or custom GUI?

    #14813

    Angus
    Participant

    It’s a GUI I made myself when I started the project in M1. It’s got some major gaps but uses more of a Blitz+ syntax, which I stubbornly prefer.

    I’ve just moved to windows10 and like the clean look, so I might make a new skin to reflect it. Can you tell I’m an old Amiga fan?

Viewing 15 posts - 16 through 30 (of 50 total)

You must be logged in to reply to this topic.