July 3, 2018 at 9:17 am #14980
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 4, 2018 at 2:50 pm #14983
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 14, 2018 at 8:41 pm #15052
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 16, 2018 at 9:23 am #15057
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 18, 2018 at 7:22 pm #15077
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.
You must be logged in to reply to this topic.