Implement async timers to power the movement of game pieces

[archerbird]

Lets explore using @Greedquest 's async timers framework.

[Greedquest]

Just as an update - working on this, however converting my Ticker API to the second level has had a bit more complexity than anticipated, lots of circular references to sort out. Got it figured (I think) so should be on its way soon:)

[archerbird]

@Greedquest Hey - I've been so swamped with work lately that I haven't had time to work on this at all. But, with the holidays, I'm starting to get some free time again. Really curious to see what you had come up with for this, even if its not working. Hope you are well.

[Greedquest]

Yeah tell me about it!

Let me catch you up on what I found: So I got the timer addin integrated as another reference. The main functional change was in this commit Greedquest@657f112

It was pretty easy to get working (your code is very clean as a starting point!) although there's an intermittent issue with refresh rate which needs to be addressed (Excel doesn't seem to be generating/ processing WM_PAINT messages sufficiently quickly - DoEvents forces a repaint but is what we're trying to avoid. It's possible manually posting paint messages will magically fix this, or a small scroll or something).

It was in diagnosing this issue that I got a bit sidetracked. The reason I created the asynchronous timer addin was to make developing with WinAPI timers easier. Actually stress testing in a real project has been a great learning experience and has revealed a number of things, most importantly:

• When used in an addin rather than adding the vba files to a project directly, the stop button no longer terminates timers like it should
• A known issue with my approach is that while 90% of the runtime crash causes are eliminated :), when debugging you can still crash Excel by hitting the end button in a breakpoint. This is more annoying than expected to work around when debugging because you tend to click it as force of habit.

A ray of hope in fixing problem 2 is thanks to problem 1. The fixes tend to be quite complex, but in brief, you'll be aware I'm sure of RD's unit testing? They have a clever way of invoking VBA methods by accessing the COM interface to them directly rather than through the VBE (CallByName) which means they can gracefully handle stop button presses without leaving the thread unresponsive. This method of calling should be possible to replicate in pure VBA, and I'm hoping by putting the calling code in an addin it will still be "alive" to handle the stop button press.

Sorry bit complicated and I haven't explained it super well, but it's covered in my musings in these 2 issues:

1. Allow End or GUI stop button when debugging TimerProcs Greedquest/VBA-Timing-Methods#1
2. Stop button doesn't work when API referenced from Addin Greedquest/VBA-Timing-Methods#4

Anyway those are development issues and don't affect the functional capabilities of the Pacman code.

Back to this project, I think these 2 things would be good to focus on:

1. 64 bit compatibility (I accidentally switched office version so need to do this before I continue anyway:)
2. Think about splitting the animation and game logic into separate loops. The main advantage of using asynchronous programming is it allows much more flexibility over splitting execution paths. Animation should probably be handled entirely by the presenter, perhaps with a high level constructor specifying framerate but really the logic and animation should be independent so may as well hook into separate metronomes/tick events. I'm going to add something like DeltaTime to the level 2 ticker api which will improve smoothness of gameplay