Daggdroppen wrote:Bet those guys are most interested in LSDj.
3DS Homebrew users can already emulate Game Boy/[Colour] games.
Port Famitracker to the 3DS/N3DS!?
-
PostApocolyptica
- Posts: 218
- Joined: Sat May 23, 2015 4:48 pm
- Location: England, United Kingom
- Contact:
Re: Port Famitracker to the 3DS/N3DS!?
3DS Homebrew users can already emulate Game Boy/[Colour] games.
-
Daggdroppen
- Posts: 31
- Joined: Thu Feb 25, 2016 7:01 pm
Re: Port Famitracker to the 3DS/N3DS!?
PostApocolyptica wrote:Daggdroppen wrote:Bet those guys are most interested in LSDj.
3DS Homebrew users can already emulate Game Boy/[Colour] games.
Yep! I'm using Fatass tracker on my gbc emulator on my N3DSXL
I was probably a little bit unclear But RetroArchs gbc emulator is much better than Gameyob3DS!
Re: Port Famitracker to the 3DS/N3DS!?
Whatever I can do to help I certainly will if I can. But lacking a 3DS I probably can't. PM me if you want.
Also, RE the header file casing. Yes, I have provided patches to JSR for all of that but I don't think those patches are released since I haven't seen the source for 0.5.0.
I wouldn't recommend doing Qt statically. From what I remember when I tried it eons ago its performance was horrid and it wasn't as capable. Plugins don't come along for the static ride. Memory has faded a bit but the experience wasn't memorable in a 'good' way.
Also, RE the header file casing. Yes, I have provided patches to JSR for all of that but I don't think those patches are released since I haven't seen the source for 0.5.0.
I wouldn't recommend doing Qt statically. From what I remember when I tried it eons ago its performance was horrid and it wasn't as capable. Plugins don't come along for the static ride. Memory has faded a bit but the experience wasn't memorable in a 'good' way.
-
Daggdroppen
- Posts: 31
- Joined: Thu Feb 25, 2016 7:01 pm
Re: Port Famitracker to the 3DS/N3DS!?
cpow wrote:Whatever I can do to help I certainly will if I can. But lacking a 3DS I probably can't. PM me if you want.
Most developers in the 3ds scene use the windows 3ds emulator Citra, for testing
https://citra-emu.org
Re: Port Famitracker to the 3DS/N3DS!?
I know a forum isn't exactly the place for a blog post, but some would argue a game console isn't the place for FamiTracker. 
First off, some replies.
re: emulator testing
Citra cannot be used to boot a Linux kernel yet, as it is incapable of loading kernel-mode code.
A recommended setup, instead, would be to use qemu-arm to set up an armeabi-v7a/armhf Linux environment similar to, if not identical to, the one on the 3DS.
re: octave selection/scrolling keyboard
As far as octave selecting, there will likely be a hotkey mapped to 3DS buttons, an octave indicator on the screen, and an octave up/down button to the left and right of the virtual keyboard on the bottom screen. Scrolling may not be implemented. For one, I don't want to do scrolling, because I may need to render the bottom screen UI in software and spit it out to the framebuffer, perhaps marginally accelerated through DMA, rather than using the Wayland OpenGLES-accelerated top screen, so updating it for live scrolling may be slow. I'm using the bottom screen for static UI elements like instruments and pattern view. For another, tapping and dragging is a bad practice on a membrane/resistive display, even with a stylus. The 3DSFT UI seeks to minimize dragging actions.
re: development hardware
I'm not greedy. If anyone needs a homebrew-capable 3DS right now, it's cpow, for testing and development, if he wishes to join in on this.
Also, the cheaper 2DS works equally as well with homebrew, and can be had for much less than the 3DS or New3DS/XL.
re: "warez"/piracy, 3DS homebrew "scene" (plus a rant on homebrew in general)
I will bring up right now, that this project will not associate with, condone or allow warez or piracy.
If it comes to the point that homebrew development on the 3DS, like on the original XBOX, is made illegal, we will still provide and service the source code under the requirements of the GPL.
The DS, Wii and PSP HB scene was pretty good; the Xbox, PS3 and PS2 also had substantial homebrew development, too, but the Atari 8-bit systems, Sega Genesis/Megadrive, and Sega Dreamcast, have a still-thriving and still active homebrew community, with regular releases!
The reason the 3DS scene is slow, as it stands, is because you either need expensive hardware, or a system with a specific firmware, or to be lucky and never have updated, in order to participate. The PSP was like this for years, too, if you remember. It got softmods, just as the Wii did, though - as well as cheap hardware to unlock it (Pandora's Battery), just as the DS did (R4DS).
They still are developing homebrew and tools for the 3DS, and it's not slowing down, so once the 3DS, like the others, becomes unlocked, we will see a renaissance develop just as with the other systems.
re: publication of 3DSFT through official means on Nintendo eShop
No. There is little to no chance of Nintendo's indie vetting process passing a homebrew, Linux-based, relatively bloated, quick-and-dirty hack-job of a port of a QT wrapper for an MFC Windows application to the eShop. (No offense to cpow/FT devs and contributors. Your efforts are well appreciated!)
For starters, it runs in a Linux operating system, replacing the ARM11 application kernel! It disrespects the APIs and ABIs provided by Nintendo, and the limits set by their SDKs, in order to take full advantage of the hardware.
I don't think it would be a bad idea to publish a music-creation tool based on FamiTracker, but it would need to respect the GPL, which may be impossible to do in "by-the-books" official 3DS development, as it will be linking in proprietary, but necessary libraries for interfacing the 3DS, and leaking even the symbol names but keeping the 3DS libraries secret (as is usually done under the 'OS libraries' provision/memorandum-of-understanding, which protects Windows-based and other proprietary-OS-based GPL applications) may constitute a breach of NDA.
The GPL does not, to my knowledge, have provisions to protect NDA-encumbered system libraries.
I'm also slowly working on a game based on a GPL-licensed engine, and I plan on releasing the game on the 3DS eShop in the future, possibly. In order to do so, it will take a lot of jumping through hoops, and some techniques and loopholes in building with their SDK, which will not work with this project.
Finally, the FamiTracker UI has a bit of a learning curve to adjust to, plus the concepts of the effects column, volume and note balancing, and the restrictions of NES music creation, might be lost on a significant contingent of eShop users, who would complain about buying an app that didn't work for them. I'd recommend making a more user-friendly music tool which makes "8-bit" or "chiptune-like" music like, if not directly based on, Famicom's hardware.
re: cpow
As I mentioned above, you can certainly help!
If you can build it on Linux at all, it will be largely compatible. Perhaps a couple ifdef's could be used to separate a 3DS-compatible build from a desktop-compatible build, mostly for hotkeys and input.
If you want to test on something a little closer to the hardware, then you can use qemu.
Also, a 2DS (not the original DS or DSi family of systems) is compatible, and can be used instead of a 3DS, as well as any 3DS-family hardware with homebrew support (which is all of them, so far).
re: re: header file casing
It's not a major issue, I just start a build, find a missing library/header in the build error log, and rename something or change the header to match casing.
Sometime prior to the first major source release, I'd go about either making all the source filenames lower-cased, and edit the header includes to match, or just editing the header includes to match existing casing.
re: static Qt
That's as good a reason as any.
I just figured having a single executable would make things easier for those who already have a Linux environment on their 3DS and don't wish to waste the space.
Instead, I may make it use a self-extracting archive containing the necessary Qt libs and the executable.
Qt-FT for 3DS progress:
TODO so far:
On the roadmap:
Once I feel QT-FT is mostly feature-compatible on the 3DS, and the UI is prepared, I may discontinue developing it (small fixes aside) until 0.5.0's final release/GPL source release, and until then, work to incorporate 0CC-FT additions and code structure, since it is generally cleaner and more widely compatible than stock FT.
Feature-creep goals:
Perhaps in the distant future, I'll mod the Linux framebuffer driver, scratch up a kernel module and user-space support commandline tool, and add a /sys/ node, to support the 3D display, slider and 3D LED.
Just for a visualizer, among other optional visual spice. Working in 3D will kill your eyes, so the 3D will be disabled while not playing.
Closing words:
I will be opening a channel for discussion and coordination for 3DS-QtFT (working title) on the Famicommunity (originally FamiTracker Talk) Discord server, on the #famitracker-dev channel, here: https://discord.gg/0TKgUmSjoOFCLd3v
First off, some replies.
re: emulator testing
Daggdroppen wrote:Most developers in the 3ds scene use the windows 3ds emulator Citra, for testing
Citra cannot be used to boot a Linux kernel yet, as it is incapable of loading kernel-mode code.
A recommended setup, instead, would be to use qemu-arm to set up an armeabi-v7a/armhf Linux environment similar to, if not identical to, the one on the 3DS.
re: octave selection/scrolling keyboard
MiniMacro wrote:Stratelier wrote: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
As far as octave selecting, there will likely be a hotkey mapped to 3DS buttons, an octave indicator on the screen, and an octave up/down button to the left and right of the virtual keyboard on the bottom screen. Scrolling may not be implemented. For one, I don't want to do scrolling, because I may need to render the bottom screen UI in software and spit it out to the framebuffer, perhaps marginally accelerated through DMA, rather than using the Wayland OpenGLES-accelerated top screen, so updating it for live scrolling may be slow. I'm using the bottom screen for static UI elements like instruments and pattern view. For another, tapping and dragging is a bad practice on a membrane/resistive display, even with a stylus. The 3DSFT UI seeks to minimize dragging actions.
re: development hardware
Daggdroppen wrote:Yeah! I'm very happy that you are working on this, sirocyl! You will have a fourth 3DS if you finish your work
I'm not greedy. If anyone needs a homebrew-capable 3DS right now, it's cpow, for testing and development, if he wishes to join in on this.
Also, the cheaper 2DS works equally as well with homebrew, and can be had for much less than the 3DS or New3DS/XL.
re: "warez"/piracy, 3DS homebrew "scene" (plus a rant on homebrew in general)
Daggdroppen wrote: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.
I will bring up right now, that this project will not associate with, condone or allow warez or piracy.
If it comes to the point that homebrew development on the 3DS, like on the original XBOX, is made illegal, we will still provide and service the source code under the requirements of the GPL.
The DS, Wii and PSP HB scene was pretty good; the Xbox, PS3 and PS2 also had substantial homebrew development, too, but the Atari 8-bit systems, Sega Genesis/Megadrive, and Sega Dreamcast, have a still-thriving and still active homebrew community, with regular releases!
The reason the 3DS scene is slow, as it stands, is because you either need expensive hardware, or a system with a specific firmware, or to be lucky and never have updated, in order to participate. The PSP was like this for years, too, if you remember. It got softmods, just as the Wii did, though - as well as cheap hardware to unlock it (Pandora's Battery), just as the DS did (R4DS).
They still are developing homebrew and tools for the 3DS, and it's not slowing down, so once the 3DS, like the others, becomes unlocked, we will see a renaissance develop just as with the other systems.
re: publication of 3DSFT through official means on Nintendo eShop
MiniMacro wrote: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?
No. There is little to no chance of Nintendo's indie vetting process passing a homebrew, Linux-based, relatively bloated, quick-and-dirty hack-job of a port of a QT wrapper for an MFC Windows application to the eShop. (No offense to cpow/FT devs and contributors. Your efforts are well appreciated!)
For starters, it runs in a Linux operating system, replacing the ARM11 application kernel! It disrespects the APIs and ABIs provided by Nintendo, and the limits set by their SDKs, in order to take full advantage of the hardware.
I don't think it would be a bad idea to publish a music-creation tool based on FamiTracker, but it would need to respect the GPL, which may be impossible to do in "by-the-books" official 3DS development, as it will be linking in proprietary, but necessary libraries for interfacing the 3DS, and leaking even the symbol names but keeping the 3DS libraries secret (as is usually done under the 'OS libraries' provision/memorandum-of-understanding, which protects Windows-based and other proprietary-OS-based GPL applications) may constitute a breach of NDA.
The GPL does not, to my knowledge, have provisions to protect NDA-encumbered system libraries.
I'm also slowly working on a game based on a GPL-licensed engine, and I plan on releasing the game on the 3DS eShop in the future, possibly. In order to do so, it will take a lot of jumping through hoops, and some techniques and loopholes in building with their SDK, which will not work with this project.
Finally, the FamiTracker UI has a bit of a learning curve to adjust to, plus the concepts of the effects column, volume and note balancing, and the restrictions of NES music creation, might be lost on a significant contingent of eShop users, who would complain about buying an app that didn't work for them. I'd recommend making a more user-friendly music tool which makes "8-bit" or "chiptune-like" music like, if not directly based on, Famicom's hardware.
re: cpow
cpow wrote:Whatever I can do to help I certainly will if I can. But lacking a 3DS I probably can't. PM me if you want.
As I mentioned above, you can certainly help!
If you can build it on Linux at all, it will be largely compatible. Perhaps a couple ifdef's could be used to separate a 3DS-compatible build from a desktop-compatible build, mostly for hotkeys and input.
If you want to test on something a little closer to the hardware, then you can use qemu.
Also, a 2DS (not the original DS or DSi family of systems) is compatible, and can be used instead of a 3DS, as well as any 3DS-family hardware with homebrew support (which is all of them, so far).
re: re: header file casing
cpow wrote:Also, RE the header file casing. Yes, I have provided patches to JSR for all of that but I don't think those patches are released since I haven't seen the source for 0.5.0.
It's not a major issue, I just start a build, find a missing library/header in the build error log, and rename something or change the header to match casing.
Sometime prior to the first major source release, I'd go about either making all the source filenames lower-cased, and edit the header includes to match, or just editing the header includes to match existing casing.
re: static Qt
cpow wrote:I wouldn't recommend doing Qt statically. From what I remember when I tried it eons ago its performance was horrid and it wasn't as capable. Plugins don't come along for the static ride. Memory has faded a bit but the experience wasn't memorable in a 'good' way.
That's as good a reason as any.
I just figured having a single executable would make things easier for those who already have a Linux environment on their 3DS and don't wish to waste the space.Instead, I may make it use a self-extracting archive containing the necessary Qt libs and the executable.
Qt-FT for 3DS progress:
TODO so far:
- Build Qt for ARM, and install Qt for i386.
- Build Linux for the 3DS. The post on GBATemp makes it almost dead-simple.
- Get Qt-FT building on my desktop, and begin fleshing out the UI.
- Build QT-FT for the 3DS.
On the roadmap:
Once I feel QT-FT is mostly feature-compatible on the 3DS, and the UI is prepared, I may discontinue developing it (small fixes aside) until 0.5.0's final release/GPL source release, and until then, work to incorporate 0CC-FT additions and code structure, since it is generally cleaner and more widely compatible than stock FT.
Feature-creep goals:
Perhaps in the distant future, I'll mod the Linux framebuffer driver, scratch up a kernel module and user-space support commandline tool, and add a /sys/ node, to support the 3D display, slider and 3D LED.
Just for a visualizer, among other optional visual spice. Working in 3D will kill your eyes, so the 3D will be disabled while not playing.
Closing words:
I will be opening a channel for discussion and coordination for 3DS-QtFT (working title) on the Famicommunity (originally FamiTracker Talk) Discord server, on the #famitracker-dev channel, here: https://discord.gg/0TKgUmSjoOFCLd3v
Last edited by sirocyl on Fri Mar 04, 2016 9:28 pm, edited 1 time in total.
Re: Port Famitracker to the 3DS/N3DS!?
You invitation is invalid
-
Daggdroppen
- Posts: 31
- Joined: Thu Feb 25, 2016 7:01 pm
Re: Port Famitracker to the 3DS/N3DS!?
Yeah! very nice post, sirocyl!
I cant join discord server as well..
I can donate a 3DS to cpow, but I know nothing about him. Is he trustworthy? Do he knows stuff about the FT code? At what level is his coding skills?
There is a long way to get 3DS-QtFT working. If I donate a 3DS to cpow now, there are no guarantees this will even be at a boot-able state. Then I would be rather disappointed and unsatisfied
I cant join discord server as well..
I can donate a 3DS to cpow, but I know nothing about him. Is he trustworthy? Do he knows stuff about the FT code? At what level is his coding skills?
There is a long way to get 3DS-QtFT working. If I donate a 3DS to cpow now, there are no guarantees this will even be at a boot-able state. Then I would be rather disappointed and unsatisfied
Re: Port Famitracker to the 3DS/N3DS!?
Apologies, human-readable invites were limited to 30 minutes, and the UI didn't show that for me.
Here's a fresh, permanent invite! https://discord.gg/0TKgUmSjoOFCLd3v
He's reimplemented a large part of the Windows-specific code which Famitracker is built upon, using Qt, which is a cross-platform GUI and programming framework/toolkit. He's working on a full-stack cross-platform NES development environment, which includes FamiTracker, thus the Qt port. I'd say he's reasonably proficient.
I'm not expecting any donations, especially at the magnitude of a 3DS. Money corrupts projects, I'm in this mostly for the fun of it.
As mentioned before, I have three 3DS systems to test with, so I may arrange to lend one to cpow.
If the two of us, or a project led by us, manage to accomplish a working port of Famitracker, I won't have a need for another 3DS.
Here's a fresh, permanent invite! https://discord.gg/0TKgUmSjoOFCLd3v
Daggdroppen wrote:Yeah! very nice post, sirocyl!
I cant join discord server as well..
I can donate a 3DS to cpow, but I know nothing about him. Is he trustworthy? Do he knows stuff about the FT code? At what level is his coding skills?
There is a long way to get 3DS-QtFT working. If I donate a 3DS to cpow now, there are no guarantees this will even be at a boot-able state. Then I would be rather disappointed and unsatisfied
He's reimplemented a large part of the Windows-specific code which Famitracker is built upon, using Qt, which is a cross-platform GUI and programming framework/toolkit. He's working on a full-stack cross-platform NES development environment, which includes FamiTracker, thus the Qt port. I'd say he's reasonably proficient.
I'm not expecting any donations, especially at the magnitude of a 3DS. Money corrupts projects, I'm in this mostly for the fun of it.
As mentioned before, I have three 3DS systems to test with, so I may arrange to lend one to cpow.
If the two of us, or a project led by us, manage to accomplish a working port of Famitracker, I won't have a need for another 3DS.
-
Daggdroppen
- Posts: 31
- Joined: Thu Feb 25, 2016 7:01 pm
Re: Port Famitracker to the 3DS/N3DS!?
Cool! Most often it is true that Money corrupts projects. Ill join the discord and talk more about donations and stuff
One little downer is that the 3DS-Linux port but the great Xerpi seems to be in a rather early state. Just a little warning. But it seems like you know what you are doing
One little downer is that the 3DS-Linux port but the great Xerpi seems to be in a rather early state. Just a little warning. But it seems like you know what you are doing
Re: Port Famitracker to the 3DS/N3DS!?
I'm aware of the capabilities and the early state. Mind you, we are in no hurry when it comes to getting this done.
It runs a linux kernel, has graphics on both screens, a Qt-capable graphics stack, touch and likely sound.
SD card access isn't yet ready, but I may have a workaround until it is.
It runs a linux kernel, has graphics on both screens, a Qt-capable graphics stack, touch and likely sound.
SD card access isn't yet ready, but I may have a workaround until it is.
Return to “Source and development”
Who is online
Users browsing this forum: No registered users and 1 guest