Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
I am finally within eyesight of the finish line for Qt FamiTracker 0.4.2.8, based on MFC FamiTracker 0.4.2. I am counting hours--but given my busy life hours quickly turn into days! This probably means a MFC FamiTracker 0.4.3 release is imminent. But rest assured, my confidence is building in my chosen approach to bring FamiTracker to cross-platform nativeness. So when 0.4.3 does come out, unless jsr has decided to whack me over the head with some more of his phenomenal MFC wizardry, an 0.4.3 migration should be fairly smooth. Especially if he really has been applying the patches I've been providing him in the bugs forum. ;)
Here's a summary from Beyond Compare of the MFC FamiTracker source and Qt FamiTracker source differences [MFC is "original"]:
The I prefix is "important" and the U prefix is "unimportant", where unimportant is whitespace or commentary. We'll ignore unimportant. Beyond Compare tells me there's 46692 important SLOC in MFC FamiTracker. It tells me that to that SLOC I've added 603 lines, deleted 1636, and changed 243.
The "deletions" are easy to explain. I haven't ported any MIDI stuff, and I haven't ported the Performance dialog. That is the bulk of the deletions.
The "changed" are also easy to explain. Most of these are header file name case changes to support cross-platform inclusion in case-sensitive filesystems. Another set of these changes are changes based on "bugs" [really 'Qt needs it to be done this way'] that I've found [and reported to jsr in the bugs forum]. A large portion of that category is the explicit casting to (LPCTSTR) I had to add to get rid of non-POD type passing to variadic CString methods.
The "additions" are code to do things in a Qt or cross-platformy way that [for now] are being done in the MFC source directly. An example is adding support for lib*.so style custom exporter libraries, and replacing DirectSound with SDL.
The upshot of all of this is that in large part [give or take 900 SLOC out of almost 47000 [less than 2%]] the MFC FamiTracker source code is *unchanged*.
Beyond Compare also tells me that my MFC HLE to support FamiTracker in Qt adds 22161 SLOC of important code [and 4451 unimportant ones for good measure].
I am really looking forward to getting this thing to the finish line! I realize it's been quite a bit longer than I originally proposed--hopefully it'll still be useful to those that have been waiting this long! Stay tuned...
Does this essentially mean MFC Famitracker is now obsolete? I mean, could this potentially replace a Windows build of Famitracker as well offer the opportunity to use the tracker on different platforms?
_______________________
Follow me on [url=https://twitter.com/jrlepage2a03]Twitter.
I record (some) NSFs on hardware. Feel free to [url=http://www.famitracker.com/forum/posts.php?id=3633]request a hardware render.
[quote=jrlepage]Does this essentially mean MFC Famitracker is now obsolete? I mean, could this potentially replace a Windows build of Famitracker as well offer the opportunity to use the tracker on different platforms?[/quote]
My goal was to make the Qt port as seamless as possible. I know jsr is not interested in switching to Qt to continue development. So I aimed to provide a platform where MFC source can be dropped in. Ideally the Source subfolder and a few extraneous files like resource.h would be identical. I am very close to that goal -- within 900 SLOC. I would take responsibility of maintaining the MFC HLE to ensure that it continues to support future MFC versions of FamiTracker.
As you've already noticed there may be behaviors in Qt FamiTracker that don't meet MFC FamiTracker users' expectations. Hopefully with feedback [like what you've already provided RE the DELete key behavior, for example] these issues can be quickly resolved and the user experience becomes largely identical between the versions. However, I currently have not ported the MIDI pieces, so a user wanting MIDI support needs to use MFC FamiTracker. I don't know if I ever will port the MIDI stuff.
[quote=cpow]I don't know if I ever will port the MIDI stuff.[/quote]
I don't think anyone will miss the MIDI file import feature, but those of us with MIDI keyboards (and I'm surely not the only one) would probably like to see at least the MIDI input capability included in the port.
It would be nice to have the possibility to add notes via MIDI every other row (or however many rows you want) so you don't have to go back and forth between your keyboards. I'd use MIDI input more often if someone implemented that.
[quote=Macromaniac]It would be nice to have the possibility to add notes via MIDI every other row (or however many rows you want) so you don't have to go back and forth between your keyboards. I'd use MIDI input more often if someone implemented that.[/quote]
Change Step to 2 instead of 1.
_______________________
"im going to continue making this crazy stuff then after a while my style will be so sick that you will be like damn suuun that shit is so sick i dont even get it. i will be like bro its ok.. you dont have to." -omgdonut
Ok I've put up Qt FamiTracker 0.4.2.8 linux build [url=https://sites.google.com/site/nesicideproject/documents/famitracker-linux-i386.tar.bz2?attredirects=0&d=1]here.
Since the last released binary, I've:
1. Fixed issue with DELete behavior reported by jrlepage.
2. Incorporated 64-bit fixes for UINT_PTR provided by Jarhmander.
3. Cleaned up the vast majority of the Qt hacks, down to only a few hundred SLOC to go.
4. Added support for toolbar button disablement.
5. Fixed support for menu item updating.
6. Fixed most issues with CSpinButtonCtrl/CEdit coordination.
Known issues:
1. Key presses that cause dialog closure [return key] are propagated to main window and cause "play toggle" to occur.
2. There are two CSpinButtonCtrl/CEdit widgets with problems that I know of. One being the Key repeat [it is being updated improperly in between setting causing it to always revert to 1] and the other being the DPCM offset [it is "off by one" but otherwise seems functional]. I am continuing to look into these.
3. Configuration of keyboard shortcuts is not quite working properly yet. I *believe* the defaults are working properly.
4. Help is not ported yet.
5. Still some minor widget size issues causing text to become truncated.
I'd appreciate feedback if there are any other glaring issues. Thanks for weighing in on MIDI.
.png)