Category Archives: Uncategorized

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…

Congratulations to Yuki-chan, who, without any of my assistance, managed to compile SNES Tracker Debugger on his Linux machine! That a boy! Also, congratulations to vilxdryad, who was able to compile with my personal assistance! To my awareness, these are the first people to compile the project. Good job guys!

Remember, the “Audio” class in STD is/should be for/assoc. with Audio Drivers, I think. I have Music_Player class in my head also, and how it relates to “Audio.” That is confusing me. I just want “Audio” to wrap Driver Selection, and involve the following routines:

But I really did want to talk about Nall. And ruby. These are “things” made by byuu and co. that I love. Ruby really inspired to write wrappers for my code. It all started when I was about to modify STD to incorporate the newest feature Time_Scrub and it’s been awhile since I’ve been in the project. I realized how convoluted everything was and really deeply involved with the methods the library at hand called for (SDL). And I was writing all the GUI widgets from scratch.. After analyzing Ruby [in fact, I will publish the analysis in my next blog post], I discovered the beauty of the hardware abstraction layer. And now, I aim to find a way to describe STD in a library agnostic manner, accompanied by drivers for some libraries (partially SDL and wholly QT is my aim).

nall is a C++11 header library that implements a large number of containers
and classes. Although at times it does reimplement containers that exist in the
C++ standard library, it primarily only does so to offer greater consistency and
enhanced yet simplified functionality.

nall/vector allows O(1) amortized insert and remove at both the beginning and
end of the queue. Resizing the queue does not always require copying or moving
all objects through placement-new syntax and realloc (yet it still supports
non-POD objects and properly invokes constructors and destructors.) It also has
functions to optionally auto-resize an array when accessing an element out of
bounds, or to return a stock object if the array index is out of bounds.

nall also provides dozens of additional small libraries that do not exist in
the C++ standard library. For instance, rather than needing a 300KB dependency
on zlib or a 400KB dependency on libpng, nall/zip and nall/png provide simple
decompression support for these formats in a mere 10KB of code each.

As a header library, no separate object compilation is necessary. Simply
include the header(s) you want, and you can use it right away.

Some of the primary supported concepts implemented in nall are:

string

vector

set

hashset

map

sort

thread

unzip

png

image

config

markup/bml

markup/xml

varint

sha256

crc

dsp

stream

optional

file

filemap

directory

dl

endian

http

smtp

odbc

License

So we might be overwhelmed at all the cool things that nall has to offer, and I would be foolish to not take time to learn it. I’m mostly interested in maintaining its use in Ruby, the hardware abstraction layer, where the nall::any type is used.. I like it’s light-weight flauntiness. I’m going to try it out. 🙂 Nall is also really useful for its “config” capability as I’ve become well accustomed with in my hacking of bsnes-classic – it makes it super easy to have a config file for various features, and extending the configuration is easy. I will make a tutorial on this.

There are some other questions I have on byuu’s libraries .. Such as Phoenix / Hiro and the difference between the two. I have the instinct that Hiro picks up a dead Phoenix. But I’m not sure. For some reason I’m not too interested in the GUI abstraction provided by Phoenix and possibly Hiro(?) .. This may be of use to someone who is : https://github.com/apollolux/hello-phoenix

Zophar’s Domain is one such popular SPC site that distributes its SPC packages in 7z archives. I love the support I’ve added into SPC Tracker that can load RSN/RAR files, so I would love to go all the way with 7z support. I’ve looked into and made some discoveries quickly:

We can first inspect the archive for SPC files. If there’s none, don’t load. Then perform similar RSN/RAR duties. (RSN/RAR should perform similar safety check).

Part II

OK 7z support is implemented. In hindsight, additional functionality to 7zDec was required — ability to specify an output directory — and also NFD (NativeFileDialog) had a bug where file extensions < 3 chars were not parsing correctly. That was fixed 🙂 , although no pull request was submitted, I did submit an issue with an explanation and clear solution. Relevant links:

I am alive and well 😀 I just needed some time off the SNES Tracker wagonwheel. ???? Don’t know what’s in store! But I’m hoping to incorporate some GUI libraries or find some help on this project.. There’s a large intimidation factor, plus I don’t have a job, living with fam and hanging with friends. We’ll see where it all goes!!

I’ve been learning about VJing thru my VJ friends and have started maintaining a private wiki for my own knowledge base it’s really useful! I highly recommend you do the same, if you’re like me.. Always working and learning new things, and building new ideas.

This has nothing to do with SNES Tracker.. Well it might.. If for some reason SNES Tracker supports MSU-1 .. which it has no reason to.. they’re unrelated and operate independently of each other.. But anyways it was hard to figure out how to get this thing working correctly on new Higan..

Keep everything the same but add this SuperRoadBlaster.bml file to the SuperRoadBlaster.sfc directory.

Super Road Blaster source is obviously a gold mine.
Here's what I discovered tonight.. more details found in Makefile
converting video to png with ffmpeg, snippet from Road Blaster, https://github.com/DocSchoko/SNES-SuperRoadBlaster/blob/master/tools/xmlsceneparser.py:
os.system("ffmpeg -y -i %s -s 256x192 -pix_fmt rgb8 %s/video_%%06d.gfx_video.png -ss %s -t %s" % (options.get('videofile'), options.get('chapterfolder'), timestart, duration))
Super Blaster has tool to convert png to snes gfx..
this somehow gets compiled in a data file "gamename.msu" by https://github.com/DocSchoko/SNES-SuperRoadBlaster/blob/master/tools/msu1blockwriter.py
now audio
os.system("ffmpeg -y -i %s -acodec pcm_s16le -ar 44100 -ac 2 %s/audio.sfx_video.wav -ss %s -t %s" % (options.get('videofile'), options.get('chapterfolder'), timestart, duration))
https://github.com/DocSchoko/SNES-SuperRoadBlaster/blob/master/tools/msu1blockwriter.py also does the audio pcm file output..
it is up to you to follow Super Road Blaster further or create your own file format.. but basically you would be storing sequential frames of tiles, tile map, and color palette data, perhaps along with an audio track
create a skeleton snes program that sets up a BG layer at a certain VRAM address that MSU1 will upload to. and then u learn how to program MSU1 to send the data to VRAM
http://helmet.kafuka.org/msu1.htm
Good luck, cause there's not much doc on MSU1 that I can see...
Perhaps the original source code behind what we just watched: http://www.dforce3000.de/pub/SuperRoadBlaster.sfc.7z
https://github.com/DocSchoko/SNES-SuperRoadBlaster﻿