I'm as excited as you guys are! A lot has been going on, but since none of it is visible on the front-end and I'm not quite finished with what I ultimately decided to do, I can't really post about it yet... So thank you, everyone, for your patience. I realize it's probably felt like a blank wall in this thread lately, but it's totally worth the wait. <3
My OCD got the better of me with regards to the mechanics of the VIP window and I found myself unable to allow it to slip through in a "good enough" state that I wasn't exactly happy with. After all, that's how we get shoddy, bloated, over-par software: we make compromises early on under the assumption that it will be "improved later on", and then ultimately "later" never comes around. I don't want that to happen. Not to my project, and not to Virtual Boy. I want it done well, and I can do it well.
How this mess got started in the first place was an unfortunate assumption. When I first designed the VIP window, I started with the Character tab and figured I could set up a simple little mechanism to decode character memory into pixel patterns. Then I did the BG Maps tab and recognized that I needed to rely on the functionality of the Characters tab, also requiring additional palettes and mirroring capabilities. Then I worked on the Worlds tab and found the need to rely in turn on the functionality of the
BG Maps tab, and so-forth. What started as a "simple quick thing" wound up becoming the cornerstone of the entire UI, and I wound up gluing more and more onto an abomination instead of building a lean machine from the outset. Right now, finally, I bit the bullet and decided to build that darn lean machine.
It caught me off-guard because in software design, it becomes second-nature to design code in such a way that it is what they call
loosely coupled. What this generally means is that all code that pertains to a certain concept should be as self-contained as possible, with only minimal interfacing with other modules. This is
almost universally the best way to set it up, since it means modules can be hot-swapped with others in the event of--for example--new development, but it isn't always possible. In the case of the VIP window, I went into it thinking each tab would be loosely coupled from the others, and designed them to be self-contained independently from one another. Once I began implementing them, however, I found that they were intrinsically linked because later tabs relied on the features of earlier tabs--resulting in a tightly-coupled situation. It was a mesh of contradicting design philosophies, and while the outward appearance was satisfying, the backing code left a lot to be desired.
The plan is once again to have the VIP window done "this week", but I realize I've said that before... But so help me if it doesn't come to pass, because it's
sooo close to a reality that I can taste it. I'm extremely eager to sink my teeth into actual VIP implementation in the emulation core and finally see programs running on their own, and this is the final task between this moment and that one.