Setting myself up for success!

Still tweaking and improving on the general flow and function on the machine. 

I found out that I could have one more interrupt "loop" attached beside the one I've been using for, well, mostly everything - so I've migrated to using two separate loops for display and switches etc. 

Doing solenoid and switch updates at 1400+ Hz turned out to be a bit overkill, so by separating screen refresh from that loop I could increase frame rate while still keeping a solid 200 Hz refresh rate on solenoids and switches. This is more than enough to dim/fade lights and from what I can tell, I haven't been able to *not* register a switch hit.   

The downside is that code is somewhat more complex (servos in particular has proven a bit challenging, since I obviously struck gold with my magic numbers the first time...) but I'm getting there. Getting all time & counter values updated took a while too, but now I got TIME_1MS variables to use that are exact and not "40 loops", which can be whatever... So it's all good. 

Basic gameloop as in start game, play game, end game, award match or highscore etc is in place. Not "final" but in place. And that's quite a relief - and this also means that for the first time in YEARS I've actually progressed further than I've ever been. *optimistic fanfare* 

1) Highscore is in place, both reading and writing to EEPROM - and of course, earning them in-game.
The eagle eyed might notice a slight ghosting. This is due to insufficient wait time during display-enable/disable cycle, but I'll get that fixed soon enough. I might even revisit the DMD rendering routine eventually to see if it's the most optimal version. I'm not terribly sure the timing is 100% when reading the documentation for the display, but it can't be far off either.   

2) Various stats are being recorded and available to view in the audit menu. Beyond being interesting I plan to use the data to decide if a feature is too easy or too hard, balls drain to fast etc. 

 

Luckily the audit stats are getting reset eventually, since ball times aren't exacty... spectacular... during testing... :) 

I've also added a lot of settings that can be tweaked, including ball save time, lamp brightness, coil power, hold start to launch ball,number of hits required for this and that. Each setting comes with a type of setting that is rendered differently such as slider ("volume bar"), cycle values, on/off, yes/no and so on. I've also added the possibility to disable certain features of the game, for instance - if the drill-arm breaks it can be disabled so the game won't try to run it etc. I'm trying to plan ahead and add as many settings I can (and since it's simple to do - why not) that allows for greater flexibility when designing the game. It would be great if some years down the road the machine won't be completely inoperable in case of mechanical failure of some part. Most professionally constructed machines compensate for broken switches and machinery, so I'm trying to be at least on par. 

But...

I'm at 62% flash usage already. 
Hopefully actual game rules won't have to be just random points and sound, hehe.

I'm not expecting and issues really, since most of the heavy lifting is done with all the various classes, mainframe and scene management. Game logic is relatively simple, after all, and worst comes to worst - I could probably offload all maintenance names and text to EEPROM and stream in when required. It should free up a few KB of valuable space, at least, and if necessary I could also squeeze out a few more KB by using binary values for letters and numbers instead of having a byte per pixel. That means I won't be able to use per pixel colors, but I'll cross that bridge if I ever get there. 

All in all, code is shaping up pretty nicely!