I’m still stuck on this smoothness/interpolation thing. Just can’t seem to get it right.
I’ve tried using a stack of points, and that’s ended in failure, so now I’m trying to use the last three points (which are explicitly defined in the code already) and hope that there is enough leeway in the incoming data to allow fully smooth interpolation.
It’s not going well.
I keep feeling like I’m so close to a solution, but it keeps ending in disappointment. I’m now contemplating revisiting my attempts as using a stack. FML.
I’m having yet another crack at implementing genuinely smooth interpolated movement, and this time I’m trying to use a stack to make sure that the data is ready to be consumed at the point it is required – as opposed to creating an artifical pause at the start of every cycle while some heavy processing takes place.
It’s proving more difficult than I imagined, but I’m sure that truly smooth rendering is almost within my grasp.
After I’ve conquered this particular problem, I’m going to take a little break from developing Gee-Oh! / MakingTracksGPS, and probably a break from development altogether (except for my day job).
Need to recharge.
So I think I’ve solved the smoothness of interpolation issues I’ve been having, and now my main focus is on making downloads immediately cancellable.
I’ve been looking at imposing a short timeout, but I would really like a direct killswitch for any particular download.
My attention is currently drawn to the idea of wrapping the InputStream in a new class, InterruptibleInputStream, and linking whether or not to kill off the download to a global purge time.
Wish me luck.
I’ve generally been making good progress in recent months, but lately I feel like it’s one step forwards, two steps back when working on some key aspects:
- Smoothness of interpolation
- Still seem to be getting this rush to the last point, followed by pause
- Should be no excuse for this pause, it should be 100% smooth
- Need to aim towards the n-1 position
- Thread manager efficiency
- The current switchThreadManagers() functionality is causing a lot of “hangover” connection attempts etc. and it’s having a visual impact on performance – causing a pause every 5 or so seconds
- Need to implement a short timeout or “killable” download mechanism
- Instead of waiting for a long timeout to realise that something has gone wrong
- Rendering jumpiness
- This still appears to rear its head every now and then
- I believe this is fix in cases where !alwaysCentreOnCurrentPoint
- Still need to fully examine behaviour when centred
- The thread manager fix may have helped/solved this
So yeah, that’s the general mindset I’m in. I have to draw a line under these three key issues before I’m happy enough to move on and pick some of this low-hanging fruit:
- Finish off theming
- Auto-centre after theme switching
- Fix location discovery logic so that any new manual waypoint is added to the reduced list immediately
- Get better discovery sound
And then I will get stuck into some of this:
- Fix issue where grid squares above are being cleared, without having been properly replaced by the correct level below
- Finish off auto-update API work
- Improve offline download persistence (don’t just discard after 20)
- Design/implement mechanism to allow grid squares to be refreshed
That should cover it for a while. Ta ta!
I’ve just been looking at improving the smoothness of interpolation in MakingTracksGPS. I’d sorta accepted this little “jump” in location for a while, and struggled to solve it, but I’ve now decided enough is enough and I’m gonna tackle this little fucker.
Having sketched out a few ideas (as shown below) I’ve done a little refactor of the code in order to try and achieve absolutely smooth motion.
Having access to all the spatial/time data information in advance, there’s no excuse not to get this right, so that’s my current focus.
Best crack on, while I’ve got momentum.
I’ve implemented the first version of a load balancer, called GOTSLoadBalancer, that I’ll be using for (multiple instances of) GeeOhTileServer, and I’m pretty pleased with it.
It’s a SpringBoot app that catches all requests, queries which of the current selection of GeeOhTileServer services are least busy (based on an API which returns current ‘total requests per minute’), and forwards the request verbatim.
I’ve already got it running in production, with just a single instance (due to VM memory limitations), but I’m 100% happy with its function.
I’m definitely pleased to have addressed any worries regarding the scalability of GeeOhTileServer at this point.