This week I spent the majority of the week getting text to render neatly. This is a necessary feature for us to communicate information to the user. I hard-coded a 6×6 pixel font into a case statement switching between alphanumeric characters in addition to “:” and “.” characters. This covers the full range of necessary characters for our implementation. In addition, each character can be scaled to be larger than 6×6 pixels since that’s clearly too small to be visible in some cases. Since division is rather bad on FPGAs, scaling should be a power of 2, but otherwise it’s relatively trouble-free.
Using the text rendering, I implemented a counter that can track the number of lines cleared by the user in-game. This will be useful later to end the Sprint mode and also for calculating how many lines to send to the opponent. I also implemented a timer. This tracks time elapsed down to the millisecond for in-game time. This is important to enable us to show the user their time at the end of their sprint.
Aside from text rendering, I implemented a basic form of gravity (autodrop) this week. Currently it is hard-coded as a specific value, but the drop speeds from the NES implementation of Tetris have been added already. It’s just needs the logic to decide when to increase the difficulty. So for now, it is simply assigned to the slowest drop speed from the NES version of the game.
I have a Delayed Auto Shift (DAS) module handling user inputs now as well. This cleans up the top level module somewhat, since carry chains, cool-downs, and the valid input check can all be done in the DAS module rather than in the top-level module. Unfortunately, while the logic for DAS is implemented, the effect is currently invisible to the user because the buttons on the FPGA are jittery enough that the quick delay is almost never seen since the state machine reverts to the slower shift before picking up the next input almost always. It may be more practical to have a “re-input” time that takes in a user input @ faster intervals rather than relying on the outside input to be stable. I plan to push this off to when we have arcade switches installed since these intervals will be somewhat dependent on the input method.
I am still on schedule. I’ve started the beginnings of getting line clearing working but it is already clear to me that the logic for line-clearing is not trivial and may need a couple iterations to have a working prototype.
Schedule has been “updated” but the end-goal to have a working single-player game by spring break is still on track. I moved t-spins to the week after next week, since it makes more sense to build it after I have line-clearing working. In its place I’ll have hold pieces working, alongside line clearing this week.