Model, View, Controller (MVC)

I’ve spent a few days from the past couple weeks refactoring SNES Tracker Debugger (STD), and I quickly learned that my GUI code was bit tied in with the application logic. I came across a real winner, as far as an architecture – MVC. My implementation of MVC is custom in that it may vary from “official” descriptions. There may even be a different name for paradigm I have created from MVC. Offhand, here are some distinctions of my impl of MVC from the “traditional” description

  • No intent to connect models to views (but I may contradict if sensical to do so)
  • Views have their own GUI Logic (since this is not a webpage but a desktop app)

so let’s focus on what I imagine.

Model

This simply refers to the “data.” This is the least well-defined of the three entities. It is also intended (in my implementation) to be out of direct-contact with the View. However, I have given myself permission to make exception(s) if necessary, based on the on-going experience of creating this architecture in practice. (1)

View

The GUI components are now designed completely independent of the internal logic/data. They access the “internal” data and logic through controllers which expose APIs.

Controller

This is where the API functions and control logic reside. The core idea is that a controller will present an API to the View, typically representing one or many CRUD-like operations.


OK, that was a very vague description though (perhaps we could call it language-agnostic). So let’s start imagining the components in the language of CPP

CPP MVC Paradigm

There are some potential helper “things” I can use to spur development of this kind. These ideas were extrapolated from http://stackoverflow.com/questions/6929957/mvc-approach-with-c

  • boost state machines for the logic and boost signals to connect things together.
  • CPPInject

I am rather unclear on what I might use. So, let’s just talk conceptually.

Views

I plan on all GUI code to be a part of this “VIEW” sub-component .. There are different types of Views (not exhaustive)

  • One that will need data from a controller
  • One that will need data from a controller, and will update new data to the controller
  • One that needs no connection to a controller (unlikely?)

Of course, views can have their own internal logic to manage themselves. I anticipate a view that updates another part of itself based on certain internal state. This is normal, any GUI logic is simply part of the View.

It is here that a part of me wonders whether that kind of logic should be outside of View … But for my purposes I think it’s a good architecture to have all GUI logic separate, in what I will call the “View” or GUI code, and I think it’s OK for them to maintain their own state.

Controllers

I don’t understand yet how I will be connecting views to controllers in a CPP manner, but a View class might be able to “target” or “include” any number of specific controllers from its class definition. This might be from reference(s) passed to the View’s constructor, or via composition.

Models

This might best be considered as a mixture of data structures and “internal API.” Generally speaking, I intend on seeing only the controllers acting on this data.


Now I want to encapsulate this entire MVC paradigm within an Abstraction Layer for Video / Audio / Input (Keyboard, MIDI, ?)

Footnotes

(1) I initially thought “Direct” memory access could be beneficial for APU RAM access, for instance — but even so, I imagine an API will be better simply because different APU functions are necessary to modify different portions of the RAM … We’ll see…

 

 

 

Advertisements

I’m back!! What’s Next

Hi everyone! — I am back after a long hiatus (6-months?) — and I have a strong desire. Guess what I’ve done!? I’ve added preliminary support to compile:

  • Snes Tracker Debugger (STD) on Linux
  • STD for Windows from Linux

this is preliminary even at a prototype level, so it’s in a state right now where only I can compile it on my machine. —> but since I am the sole developer, that’s just fine! I’ve also:

  • started documenting the library dependencies found in this project.

IRC Community

I’ve started a community on IRC ESPERnet #snestracker. Please come join! I have 4 lovely people hanging out there right now — and we mostly idle until I have a new prototype which I need testers for. So far, the lovely vilxdryad has tested my first Windows compile of STD, which worked!

What’s Next

If you’ve been following my blog posts – you will have seen that before my hiatus, I was eager to overhaul the architecture of SNES Tracker Debugger into a library-agnostic style implementation. Well, as wonderful as that sounds — it’s too large a bubble for me to work with.. I don’t think I would ever finish the project! —> So I made the decision to stay bound at the library level for now…

Right now, that library is SDL — but SDL doesn’t have widgets and that kind of thing … That’s where I’m going to make my own — simply because I’m masochistic and want a really custom look to SNES Tracker. If I were to use QT — designing these widgets would be unnecessary, but I like challenges and I’m going to try to implement all of my own widgets. Besides, I’ve already designed several already!! And I can always change my mind later and replace the current UI with a widget system. (Easier said than done)


 

So, what’s next, is that I’d like to add the SPC Export feature which I had already started planning in an earlier blog post (link here that will never be). But this new feature has a dependency that I have not yet filled! Text-Edit boxes! Let’s open the discussion on this.

TextEdit Widget

So now begins my journey to creating a Text-Edit widget.. Of course, this widget will be as basic as possible at first, but eventually adding the bells and whistles (text highlighting / delete support, double-click select all, ?)

I’m going to implement this directly, or talk about it in a dedicated blog post. Then I will feel comfortable to start work on SPC Export feature 🙂 (I think)

Audio Format Support

Your goal is to design or seek out a library designed to convert input samples of a pre-defined audio format to destination samples of another, on-the-fly as samples are provided. But if you are feeling lazier than a goat, just design an “on-the-top” solution that will convert an entire buffer of samples.

Some Thoughts

Why: The SPC emulator writes to a buffer of:

  1. little endian
  2. signed 16/bit
  3. 2 channel interleaved stereo

Currently, the emulator can only dynamically account for different sample rates.

Thus, the 2 solution options truly become:

  1. Solution above – see “Audio format emulation layer”
  2. Modification to libgme/spc emulator to allow various flavors of audio formats.
  3. Create a new library specifically for converting samples on-the-fly, that libGME and others could use in their sample functions.

I rather like 2 because it fixes @ the source, speedier performance solution – also probably a lil’ more difficult (I also have a new saying “if you’re going for better performance, forget about it” — it needlessly complicates. HOWEVER – this whole post is a waste because I think the native audio format is the most popularly supported. Please research the most popular audio formats regarding endianess and bit-width. Irregardless, I would like to see support being offered to any lonely souls [computers].

For 2 – There is a func. where samples are filled into a buffer. This is a very repetitive function, which I needlessly thought about optimizing for performance sake – by having one-time logic checks beforehand and then executing a predefined code path based on the logic calculated at init.. But the saying comes to mind again — It’s difficult to know whether a compiler is already optimizing certain things I consider manually optimizing.. I will probably make another blog post about this research. Ultimately it became a question of function calls costing more than a boolean check anyways, and that the effort is not worth the potential gain in performance.

Thus, I propose the best solution, — 3 — design 1 as its own component which GME can use, as well as other projects that would want to add support for other audio formats, based on an input format. Much can be learned in doing these by investigating into SDL2’s audio format conversion techniques

Byuu and co.’s “Ruby” abstraction paradigm

Ruby

Ruby is an abstraction of a feature over several different drivers, allowing the automatic specification / compilation.

Shouts to the original contributors of bsnes/ bsnes-classic. I have a hope that by explaining Ruby, I can understand how to apply this in my own project, where I aim to produce a self-doing API abstraction for Audio over QT/SDL.

I will only explain the Audio section. I sometimes combine .hpp and .cpp files into one code listing, which I comment the beginning of the CPP with //IMPL
Continue reading