inversephase
patreon
CTM development log recap
🕑 Added 2018-02-09 15:03:46 +0000 UTC It's been six days since the tracker video (please watch it if you haven't) and I've made some reasonable progress on the tracker. Let's take a look at some of my commits, which I'll paraphrase:While making the video, I noticed DEL didn't work right. It's because I moved some code around and that included moving the cursor according to the ADD value before the delete occurred. Now it will delete the current area and then move the cursor. Embarassing, but worth mentioning.
Next I attempted to make the mouse cursor suck less, removed some rather unnecessary semicolons (this is python, how could I miss those?), made a really basic instrument preview section, and added bitstreams and waveform drawing stuff so instruments could be "previewed". I added a little background for it too, so it's easy to see.
One thing I've spent some time on is optimization. It seems dumb to be doing this already, but wow, how much of a difference it makes! My text renderer isn't slow, but it's still slower than just plopping an image onscreen. So now I render out all the names of notes and other values like FX and volume ahead of time into a "shortcut" buffer. I also split up the screen updates a little, though I do need to take a suggestion to just use sprites. Anyway, I've nearly doubled the framerate just fixing what I've mentioned so far.
With the speed on point, it's time to clean up the tick timer! What the hell does that mean? Well, an old system like an NES or Commodore 64 won't have a real-time clock built into the machine. So what can we track (ha. ha. ha.) time with? Turns out old systems update the sound chip with data (and read input, and check if player 2 died, etc) every time they finish with a video update. In this (rather short) VBLANK period of time between ending one frame and starting the next, we have a convenient place to know that either 1/60th (NTSC) or 1/50th (PAL) of a second has passed. A lot of trackers refer to a VBLANK as a "tick" and base their speed parameter around it.
So, now it came time to make those controls work. I cleaned up the GUI a tad and enabled the "SPD" arrows, tying them to the internal value... and the result was anticlimactic; SPD didn't actually work yet, as I suspected from all my timing fluctuations and because the playback was WAY FAST in the video I made. Turns out the way I implemented ticks was incomplete and I committed like 3 lines of code to remind me to fix them. Then it turned out that code I wrote works after all and fixed the bug.
With all that working, it's been time to move the sound board channel reassignment into the GUI. No more ugly prompts in the console! When I tested it with a YM2149, I realised I didn't detect it properly, so I just added it into my sound drivers and made it use the same settings as the AY-3-8910 (but change the name, naturally). Also, reassignment can occur while a track is playing, no more issues with an input prompt blocking that from happening!
Hope you've enjoyed this little recap. Hopefully by the next time you hear from me I'll have either proper frequency matching (so that all boards will have meaningful tunings) or file I/O (because loading and saving is nice, I hear)!
If your Patreon account is tied to Discord (in Patreon, go to Settings, Account, and then look about halfway down) you can watch commit messages to CTM in #tech. Catch the updates as they happen!
Feel free to ask questions!
