Hello and welcome to another day of Bazz’s SNES tracker development blog posts. Today I want to talk about my experience returning to the project, the bad things I’ve discovered about my projects, and what needs to be fixed in order to have a better development process.
As you might know it’s been a few months since I’ve coded for SNES tracker debugger. When I came back to the project a week ago, I realized how convoluted everything was. I found it really difficult to implement a new feature (see the very end of document for an expounding composite on this experience, and a conceptual solution). At the time I knew I had been agile-style developing, and I guess I rather lacked the sense that I have now.
As an example, libGME – and much, much more has to be said about my version of it – has been thus far directly compiled into the executable. Even worse, there were parts of libGME & SNES tracker debugger that only compiled when the two were used directly together. I’ve taken a new focus on fixing flaws like these. I am planning on making a tutorial blog post that demonstrates the improvements I’ve made, allowing libGME and the new features I’ve added to be compiled independently as a little dynamic library. But, For now I’d like to only talk about my vision for SNES Tracker debugger.
Individual Repos – Self-fulfilling
What with the abstraction of libGME’s new features back into its own independent library, and with my own modified use of utilities such as unrar and 7zDec (7zip extraction program), I am planning on individualizing these aspects of snes tracker into their own repositories and maintaining a Github Account called SNES tracker, which encapsulates all these different repos. This is akin to RetroArch, the multi-emulator thingy. Like RetroArch, I plan on having a “Super” repository that pulls in all of the other repositories and provide scripts and/or make files for compiling the final project. This’ll be really useful, since I imagine other projects that might call upon some of these individual repos which can now work independently, or at least that’s what I hope for. I am sure I would consider licensing at some point.
I’m also working on adding abstractions in STD’s main CodeBase. Currently it is a convolution of specific library implementation code and bad object oriented programming. I want the code for SNES tracker debugger to be a wrapper beyond any specific Library implementation. I’m seeking to code SNES tracker in this “Blueprint” style so that I don’t have to think in terms of a specific library, I can simply think how I want this tracker debugger to work, and then write drivers underneath the abstractions for whatever library or libraries that end up being the ones. I admit I have to be careful when I design my wrappers, I do indeed have a mindful approach towards some of the libraries I intend on implementing so that I know the wrapper and driver will agree with each other.
It should not be underestimated how difficult it is to create abstraction layers for the individual components. I’ve just finished implementing an SDL driver for an abstract Timer class I designed this weekend. It was a lot of work but I also learned how I can minimize about 90% of that work – for me it’s just a matter going to sleep on time and not thinking too hard. You’d be amazed at how hard I worked on it and ended up taking out much of the code I added. But us experienced programmers know it is not about the amount of code at all – that does not reflect the quality. Less is more always. I’m the very feature full person so it’s tough for me to stay true to that. Whatever moving on..
A bit about how I work extra hard on things and I end up learning an incredible amount of information that I don’t disseminate into documentation. This happened to me yesterday with the SDL timer implementation, I ended up deeply studying the SDL timer source code, and I learned a lot about it but it was just so much I don’t know what to say I would like to try to disseminate that information somehow so I’ll give it a shot today. It’s rather interesting stuff I think. I don’t know, there’s a lot I would love to do today.
Anyways I will continue to be this way I hope you like it. I hope you like what I’m doing with the project as far as abstracting everything and really just trying to organize this project and have it be self-fulfilling.
Afterthoughts / Concerns
… I don’t think I have anyone to rely on externally for this project but I’m trying my best to create environments so that teammates can join up. People who are interested can listen and be informed and hopefully become involved. So in order to create such an environment I have created the forums on http://snestracker.club that would love attention. For more serious players I have made a slack subdomain which is invite-only and I would love to invite you if you’re interested. Please feel free to shoot me an email and demonstrate some self-motivation and interest for the project – because if you don’t have that I won’t come to you. my email is mbazzinotti SKIPPITY_DO gmail.com. I just assume that nobody’s interested in this project except for me, as developer. I am also not much of a team player. I’m not even sure if I’ll be open to other people’s ideas. A part of me just doesn’t want listen to anybody. And that’s me folks, take care.
Subheadline — My experience with trying to implement a new feature after some time away from the project.
SubSubHeadline —> ,along with some very important notions on self-fulfilling classes, and the wrapper layer.
One of the first things I appreciated were the Youtube videos, more specifically the time invested into the videos I make on the SNES tracker Youtube channel. I knew that those videos might not benefit anyone else but I made them anyways and it’s true; they benefit me a lot and they would benefit anyone who was coming into the project as a developer, although I do keep the videos unedited so they are rather long, I don’t care.
Problem: Design by Library Implementation
Now the problem I experienced that might be inescapable in the sense, is that the program was designed around the Library implementation. The library that has been initially used for SNES tracker is SDL, and it has its quirks. Some of its features will require a certain design, a shaping of everything. Now I am not sure by my new ambition to abstract everything, if I could ever quite escape a necessary shape for the project’s main loop to take. That means that whenever you add a new feature, well say for instance a feature that would require new widgets to be displayed and logic based on the widgets interaction with the user, you have to know the proper places to put all of the corresponding event processing code and whatnot. At least, that’s how it is right now in SNES tracker debugger. I don’t like that at all. If anything I wish I could just have an objects definition or class definition of a new feature that was just self-fulfilling – a class that knew it is for visual interaction (based on some declaration) and they automatically can put themselves or their functions in the proper location(s) to be processed and what not. That would be really cool. And I’m sure it can be done, that’s really cool. (say an array of function pointers?? I don’t know)
So you see, that idea could even be implemented in STD now, with its hardcoded dependency on SDL. But I have another ambition, which is to code SNES tracker in an abstract way so that underlying libraries can be used independently of the core abstract code base. As long as drivers have been implemented, you’re good. I like this idea because it allows SNES trackers core CodeBase to be universal even during library changes.
Concerns and Design Constraints
Now, I realize that there probably are going to be libraries that don’t agree with the wrapper layer. There are probably, maybe going to be some libraries that have a certain implementation which almost disagrees with the notion of the wrapper. I love SDL and QT so I’ll probably keep them in mind. <– I am debating even this.
I want to soon focus on self-fulfilling classes, after the simpler components are abstracted.
Inspired by bsnes-classic, RetroArch, and myself