Angus

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 70 total)
1 2 … 5
  • Author
    Posts
  • July 18, 2018 at 7:22 pm in reply to: Beginnings of my editor. #15077

    Angus
    Participant

    Viewports braindump.  I don’t like having to think about new things, and these are annoying.  I’m really just posting this to clarify what I need to do for myself, but I hope to have this problem solved in the near future and want to look back at myself and laugh.

    I reckon my thinking block is that I need the editor objects to do something I don’t want my code objects themselves to ever do.  This is already the case for a couple of little things in my “object” code, and I shouldn’t let another stop me, but it grates.

    I need to be able to zoom and scroll around a projection of the display as it’ll finally be.  Partly to have a clearer overview of all viewports and their stencils, but also because I want to determine the display as an arbitrary rectangle.

    If I want to make a portrait mode handheld program, I want to be able to see the display on my worktop regardless of my worktop resolution. With this in mind, I don’t want to assume the final resolution either. (Or perhaps the exact aspect ratio)  So I want to be able to determine a rectangle that can represent the display with a virtual resolution in which the viewport’s positions and dimensions are defined.  Um, roughly.  My instinct is to restrict what is “definable” to the aspect ratio of the display and a “width” in units.  This’d mean that the display has proportional axis, but on the other hand I could allow both dimensions to be determined to provide the option of forcing them out of proportion… I’m in doubt about this bit.

    But ultimately an extra transformation will occur for the benefit of the editor’s worktop display, and that’s an annoying thing to place in my code.

    I also need to allow the resolution of the viewport texture to be a thing determined automatically based on the display size in pixels or alternatively predetermined.  For without-filtering blocky graphics?

    Ok, I think I’ve written enough confusing rubbish to begin to think about coding something.  I wonder if when I’ve solved the problem it looks anything like what I’ve been babbling about.

    July 16, 2018 at 9:23 am in reply to: Beginnings of my editor. #15057

    Angus
    Participant

    Random thoughts on where its at.

    I have gone back to make some “simpler” object editboxes.

    This brought me to Viewports, which were a late addition and need some more thought.  Until now, Viewports have appeared in their own ultimate position and objects are edited within the currently selected Viewport.  However, they’re clumsily defined by how large you want them in pixels and how you want that scaled, rotated and positioned.  Fine for working with during development, but no good in the long run.  I want to be able to determine a hypothetical display on the worktop and be able to arrange Viewports on it.

    I need a further transformation that allows me to “zoom out” of the whole worktop, and VP attributes defined more as proportional to the ultimate display.  Or something like that, I haven’t completely decided.  It’s one of those things I just need to bang my head against for a couple of days.

     

    Also I’m almost surprised by just how much it really is hanging together and is getting dangerously close to being useful.  I’ve accrued a series of things, a bit like the VP stuff, that really need tidied up but they’re not too serious.  I’m going to sort a couple of them and try to prepare the source for posting.  It’s not a thing I’ve done before really, mainly because my code is pretty ropy and I haven’t evolved that much from a time when posting code online was the stuff of fantasy.  My project and code structure is just whatever I’ve gleaned over the decades rather than something super well thought-out.  If someone were to ask me why I’d done something a specific way, I might not be able to answer 🙂

    One by one the Editboxes are stacking up.  I want to get all my current graphics objects out of the way.  It’s pretty obvious that these are the objects I’ve been using for ages as they don’t use any of Monkey2’s fancier shader effects.  This doesn’t mean they won’t go in.  In fact I’ve already got some of the stuff ready for them, but it’ll be a wee while.  There are a handful of other graphics classes I’d like to add, but that’s also for later.

    Once the graphics objects as they stand are editable, I’ll move on to the physics objects.  Some of these will need slightly sophisticated editboxes, like scrollable displays to define convex polygons or circles for individual shapes or for editing “on body”.  These aren’t too hard to code, but will take a while.  Most of the physics objects should have fairly simple editBoxes, though.  Only a few attributes define most joints, and can be best edited on the worktop.

    This is really just a pep talk for myself.  Still tricky things to think about, but if I had to guess I’d say I’m about a third of the way through.  (I’m an optimist, deep down)

    July 14, 2018 at 8:41 pm in reply to: Beginnings of my editor. #15052

    Angus
    Participant

    Back last night and at it again today, have been frustrated to do so little coding over the last week and a half 🙂

    It took all day today to do the last 10% of the TextRail editing, but it’s complete now. (for now)

    It may look pretty similar, but I’ve fixed the scrolling aspect and added a new type of worktop hotspot to control the offset.

    Again, 720p is a little better to look at.  I’ve greatly improved the look of the curves, and the colours are more sensibly interpolated.

    More importantly, the textrail really represents three different classes of object, including some tricky ones.  Having it work completely (touch wood) suggests a greater amount of all that copy/read/write stuff is still holding up.  I’m firmly expecting horror bugs to come, but this has been a satisfying one to see function.

    Also, the addition of the blue sliding hotspot works well enough as a worktop control for more arbitrary object attributes than positions of things.  This should come in useful for other more complicated objects.

    Now there are lots of things I can do again.  Still the tricky spline combiner ahead, but I might heave in a few simpler objects first, I could fill out much of the list before tackling something too hard.  Also I have to do some grid snapping n showing things for the worktop… oh and a thousand other things.  It’s good to be back at it.

    July 4, 2018 at 2:50 pm in reply to: Beginnings of my editor. #14983

    Angus
    Participant

    I’m about to go away for a few days, I’ll have my laptop and will keep working, but may be out of the reach of the internet.  Before I go I’ve got about 90% of the way toward completing TextRails.  I’d have like to have had a complete demo to show, but I need to head and what I’ve got is still fun.

    And still, sorting my video quality has taken low priority, but here’s me untangling a load of hotspots…

    These are scrollable, but I’ve been playing with their internals in a way that has made them not quite work.  If I can’t get them working my new way, I’ll revert to my old method.  Hopefully within a week I’ll be back with a video of them doing just that.

    Edit:  Youtube selects very low quality by default, but the vid is 720p…

    July 3, 2018 at 9:17 am in reply to: Beginnings of my editor. #14980

    Angus
    Participant

    The simple text object editing is in:

    Ok, I shouldn’t swear I’ll do things… I haven’t yet sorted my video quality.

     

    Making this work meant revisiting my text object and I’m pleased to see it holding up ok after all these months.  I made some small alterations.  As I work through these edit boxes, as predicted I am getting a chance to properly investigate the reliability of all the undo/redo, copying, and reading/writing components of the objects.  On the whole it’s seemed like I’ve made fewer goofs than I had expected.  Not none, but it’s been satisfyingly robust.  Having said that, I’m not working on the most horrible objects yet 🙂

    TextRails are next, which are sort of the first interesting object and the first that use splines on the worktop, so a new little challenge.

    July 2, 2018 at 12:24 pm in reply to: Convert seconds to Time() #14971

    Angus
    Participant

    Yes, it seems much safer than relying on my guesswork 🙂  Haven’t gotten round to implementing it myself yet, but the time will come soon enough.

    July 1, 2018 at 5:36 pm in reply to: Convert seconds to Time() #14964

    Angus
    Participant

    Can’t check it just now, but will soon. I’ll need this to work myself so I’ll have to keep coming back til it does 🙂

    July 1, 2018 at 4:38 pm in reply to: Convert seconds to Time() #14963

    Angus
    Participant

    Hmm as I think about this, though, I’m sure it’ll have a problem with dates before 2000.  Like I say the doubts I had were correct in that they were with how I was interpreting what he was doing.  The month, for example is correct if January=0, as it does when being read from an array.  Worth bearing in mind when displaying the month as a number.

    So I suspect a further look at how I made his code into M2 code would be worth it, I’m not too sure about where I might be making an error.  Frustrating as it’s really close, and it’s fun to see words appear out of that opaque looking number.

    July 1, 2018 at 4:35 pm in reply to: Convert seconds to Time() #14962

    Angus
    Participant

    Sweet little change!

    July 1, 2018 at 3:53 pm in reply to: Convert seconds to Time() #14960

    Angus
    Participant

    Hmmm I’m so prone to tweaking.  Actually the code I’m going to use is more like this, as it makes vaguely more sense.

     
    I’m gonna stop playing with this and go back to other things 🙂

    July 1, 2018 at 3:40 pm in reply to: Convert seconds to Time() #14959

    Angus
    Participant

    I did that, and made a couple of other small changes, and I guess this is what I’ll use…

     

     

    If there aren’t any other functions to do this, I could add it in the code library.  Are there things about the way I did it that make it unsuitable?

    July 1, 2018 at 3:23 pm in reply to: Convert seconds to Time() #14958

    Angus
    Participant

    In fact looking at it again, having gone to the trouble to structure it that way, I may remove the local variables all together and make them permanent globals to work with.  Would I just be wasting my time?  I’m not sure…

    July 1, 2018 at 3:19 pm in reply to: Convert seconds to Time() #14957

    Angus
    Participant

    I figured out my silly mistakes and this is the code as I’ll use it.  I made it this way as I imagine rattling through potentially thousands of files and having to make names for each…

    So if I say:

    Print UnixTime.ToString(1364485543)

    it outputs:

    Thursday, 28th March 2013 15:45:43

     

    I tested it a fair bit and it seems ok, but perhaps I’m still making a mistake.  Using the same logic you could make it convert to different things.

    July 1, 2018 at 2:05 pm in reply to: Convert seconds to Time() #14956

    Angus
    Participant

    The more I play with this the more I think I’ll just fudge it myself to add one to the month at the last minute and 1900 to the years.

    I guess I could do some things to make daylight savings correct as well, but that’s more annoying.  Everything else seems ok, including the day. 0-sunday 1-monday etc…   I looked at some files for last year and they were correct, or at least predictably incorrect.

    I’d rather have an error I’m making pointed out tho, I trust his code more than my fudges and still suspect I made a mistake.

    I’ll post what I’m going to end up using if no-one can see an error.

    July 1, 2018 at 1:54 pm in reply to: Convert seconds to Time() #14955

    Angus
    Participant

    Well this probably makes more sense, given the output of the filetime function, but it’s still the same…

    But trying it with some other files, it’s really close to being right.  Looks like the month is one unit too early (annoying) and the year is out (very annoying), but the day of the month and the day of the week and the time all seem right… a file in January reports the correct time, suggesting it doesn’t compensate for daylight savings.

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 70 total)
1 2 … 5