Port Famitracker to the 3DS/N3DS!?

[cpow]

The resources could be supplied in source form in a zip file next to the program's one and parsed at runtime. If you want I can do that for you, because text processing is always fun to me.

I'm not sure I get the idea you're proposing, but I would very much appreciate help in making the resources runtime parsed.

It should -- now -- be a fairly simple text processing affair. I just haven't bothered with it.

As an example, all taken from https://github.com/christopherpow/nesic ... racker.cpp:

Code: Select all

#include "SpeedDlg.h"
void qtMfcInitDialogResource_IDD_SPEED(CDialog* parent1)
{
   CSpeedDlg* parent = dynamic_cast<CSpeedDlg*>(parent1);
   QHash<int,CWnd*>* mfcToQtWidget = parent->mfcToQtWidgetMap();

//   IDD_SPEED DIALOGEX 0, 0, 196, 44
   CRect rect(CPoint(0,0),CSize(196,44));
   parent->MapDialogRect(&rect);
   parent->setFixedSize(rect.Width(),rect.Height());
//   STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU
   parent->toQWidget()->setWindowFlags(parent->toQWidget()->windowFlags()|Qt::CustomizeWindowHint|Qt::WindowCloseButtonHint|Qt::WindowTitleHint);
//   CAPTION "Custom speed"
   parent->SetWindowText("Custom speed");
//   FONT 8, "MS Shell Dlg", 400, 0, 0x1
//   BEGIN
//       DEFPUSHBUTTON   "OK",IDOK,139,7,50,14
   CButton* mfc1 = new CButton(parent);
   CRect r1(CPoint(139,7),CSize(50,14));
   parent->MapDialogRect(&r1);
   mfc1->Create(_T("OK"),BS_DEFPUSHBUTTON | WS_VISIBLE,r1,parent,IDOK);
   mfcToQtWidget->insert(IDOK,mfc1);
//       PUSHBUTTON      "Cancel",IDCANCEL,139,23,50,14
   CButton* mfc2 = new CButton(parent);
   CRect r2(CPoint(139,23),CSize(50,14));
   parent->MapDialogRect(&r2);
   mfc2->Create(_T("Cancel"),WS_VISIBLE,r2,parent,IDCANCEL);
   mfcToQtWidget->insert(IDCANCEL,mfc2);
//       CONTROL         "",IDC_SPEED_SLD,"msctls_trackbar32",WS_TABSTOP,7,7,101,16
   CSliderCtrl* mfc3 = new CSliderCtrl(parent);
   CRect r3(CPoint(7,7),CSize(101,16));
   parent->MapDialogRect(&r3);
   mfc3->Create(WS_TABSTOP | WS_VISIBLE,r3,parent,IDC_SPEED_SLD);
   mfcToQtWidget->insert(IDC_SPEED_SLD,mfc3);
//       LTEXT           "60 Hz",IDC_SPEED,112,11,26,12
   CStatic* mfc4 = new CStatic(parent);
   CRect r4(CPoint(112,11),CSize(26,12));
   parent->MapDialogRect(&r4);
   mfc4->Create(_T("60 Hz"),WS_VISIBLE,r4,parent,IDC_SPEED);
   mfcToQtWidget->insert(IDC_SPEED,mfc4);
//   END
}

You can see that it should be a straightforward A<-B replacement. Where each dialog element has a specific MFC instantiation.

Code: Select all

//       CONTROL         "",IDC_SPEED_SLD,"msctls_trackbar32",WS_TABSTOP,7,7,101,16
   CSliderCtrl* mfc3 = new CSliderCtrl(parent);
   CRect r3(CPoint(7,7),CSize(101,16));
   parent->MapDialogRect(&r3);
   mfc3->Create(WS_TABSTOP | WS_VISIBLE,r3,parent,IDC_SPEED_SLD);
   mfcToQtWidget->insert(IDC_SPEED_SLD,mfc3);

I left the dialog resource file content in as comments, and build the actual dialog element underneath it.

The control's rectangle, style flags, and ID are used directly. The control's Create method is invoked. Then the Qt/MFC linkage is established.

[Roflo]

As far as I understand you simply hardcode the position etc. I'd suggest taking the resource code and either embedd it into the programm or (better and portable) putting in in a directory or archive next to the program so you just have to take the .rc files from the original an put it in there. The qt application can now, like the winapi functions do but with the compiled embedded resource, parse the files and built the widgets.

[Stratelier]

Heh, that mockup does look a lot better with a visual keyboard attached to the touchscreen. It would, however, have to be scrollable by tap-and-drag action (eliminating the need to hold a 'current octave' setting) . It would also need to have a placeholder keys for the note cut/release. (Basically, you have to go beyond just "a port" and actually start redesigning the interface on a large scale.)

[MiniMacro]

It would, however, have to be scrollable by tap-and-drag action

or arrow buttons to go up or down an octave
that would be easier
and in the octave selector's place, a button to toggle instruments display

[Stratelier]

or arrow buttons to go up or down an octave

Heck, a scrollbar/slider type widget would work well, too. Click the arrows on the edge to page up or down an octave, or drag the position slider around to select the range you want.

[Daggdroppen]

I will try to shrink the images...

The good news: many people in here actually seems to like to have Famitracker on the 3ds. And there are a couple of people in here who knows about coding!

The bad news: it seems to be very difficult to port Famitracker to the 3DS. No easy solutions here :/

[cpow]

The bad news: it seems to be very difficult to port Famitracker to the 3DS. No easy solutions here :/

I'm not sure it's difficult. I'm just not sure it's...necessary? Seems like a "just because we can" project. But I don't own a 3DS and I don't know the 3DS community. Perhaps there are a large number of 3DS owners who don't own PCs capable of running MFC Famitracker, or OSX or Linux boxes capable of running Qt Famitracker? Perhaps these people would "track if only..."?

If a solution is necessary it becomes less than difficult. But necessary can have individual meaning also, which is as I stated the original reason I ported Famitracker to Qt was because I wanted a tracker in my NES IDE.

Are there hordes of people with 3DS waiting for this?

[sirocyl]

I mean, I am working on it too, so there's that.
I think it's somewhere between a "because we can" thing, and, to me, the idea of composing on the go, is pretty neat. I don't want to have to whip out a whole laptop for a quick idea. It's like a sketchpad for FT, in my opinion. I almost always have my 3DS or a smartphone with me, but I don't always have a laptop.

Mind, an ARM small-screen port would easily translate to Android, too, but the lack of physical keys on recent Android phones is a bummer.

Also, what makes a port to the 3DS a lot easier, is a working armhf port of Linux, and a graphical Wayland environment, which Qt supports to an extent.
3DS Linux: https://gbatemp.net/threads/release-lin ... ds.407187/

The only thing that's needed for the UI, is fitting it to a small screen, and possibly dual screen capability.

I have a 3DS (actually, three!) with homebrew capability, and I am pretty savvy with configuring things like that, so I have no problem testing builds and getting the basics working.

The actual distribution, when the time comes, I expect to be in two flavors: a standalone binary for an existing 3DS Linux install, possibly with Qt statically built-in, and a "homebrew app" version, a folder you place on the SD card, which includes a tiny, fast-booting Linux root/image with Qt and just enough support to bring up 3DS-QtFT.

[Daggdroppen]

Yeah! I'm very happy that you are working on this, sirocyl! You will have a fourth 3DS if you finish your work

The 'autoboot' app sounds very exciting But is xerpis Linux working ok on the 3ds?

For me it wouldn't be a 'because we can' product. I'm tracking on a game boy and tracker called Fatass. On my N3DSXL. It's brilliant. But the Famitracker would even more brilliant. On my pc, I never get the inspiration to make music on trackers. I'm using Logic and Studio One instead.

The 3DS scene in general is really sleepy. Its mostly warez. The DS, Wii and PSP homebrew scenes were more than 10x active. So there are not many people who are waiting for Famitracker 3DS. Perhaps some people at chipmusic would like to have Famitracker 3DS. Bet those guys are most interested in LSDj.

[MiniMacro]

Well, maybe we could go to one of the indie publishers like Nicalis and with JSR's permission, get it published on the 3DS shop?