Building in_gsf by SmartOne at 3:43 PM EST on February 26, 2009
Using Visual C++ 2008, I'm having problems. The first error was about not having the afxres.h header mentioned in the resource file, so I downloaded it from somewhere and slapped it into the include directory... Then there were a couple things about converting char to const char * or something, so I changed a couple lines. Then it wanted msvcrt.lib, so I downloaded something named as such and threw it into the directory required. Now everything seems to compile, but the linker has all these errors about "unresolved external symbols."
I'm new to C/C++. The only experience I have is Java. I thought it a grand idea to try to build in_gsf with updated components from VBA-M.
Could this work? I understand it would take some work, but in_gsf as it stands now isn't very good. Suggestions?
EDIT: I'm trying to build in_gsf as it is first. :P
The debug version compiled with VS 2003, and the plugin seems to work. So I replaced Sound.cpp and Sound.h with the new versions. I kept trying to build, getting more dependencies, downloading more source files of VBA-M, until the compiler didn't like the __restrict keyword used in Blip_Buffer.h...?
I don't know what I'm doing. Could one of you knowledgeable types tell me if this is worth the effort? (Can this be done?)
Come on, someone has to care about not having sucky GSF playback! You people have the know-how. A hint, perhaps? Thoughts? A pat on the back?
This is the least amount of errors I can get from the Linker when compiling the existing Release version:
1>------ Build started: Project: in_gsf, Configuration: Release Win32 ------ 1>Linking... 1>LIBCMT.lib(fflush.obj) : error LNK2005: _fflush already defined in MSVCRT.lib(MSVCR90.dll) 1>LIBCMT.lib(hooks.obj) : error LNK2005: "void __cdecl terminate(void)" (?terminate@@YAXXZ) already defined in MSVCRT.lib(MSVCR90.dll) 1>LIBCMT.lib(dosmap.obj) : error LNK2005: __errno already defined in MSVCRT.lib(MSVCR90.dll) 1>LIBCMT.lib(stricmp.obj) : error LNK2005: __stricmp already defined in MSVCRT.lib(MSVCR90.dll) 1> Creating library .\Release/in_gsf.lib and object .\Release/in_gsf.exp 1>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library 1>release/in_gsf.dll : fatal error LNK1169: one or more multiply defined symbols found 1>Build log was saved at "file://d:\Desktop\in_gsf_src_0.11\Release\BuildLog.htm" 1>in_gsf - 5 error(s), 1 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I've tried all the different possible combinations of compiler code-generating parameters (/MT, /MD, /MTd, /MDd) with the Linker argument /NODEFAULTLIB:library.
We had server issues with the host, needless to say. And they refuse that there is anything wrong >_<. so we are in the stage of switching over to a provider thats not so shite.
That said, try SourceForge for the VBAM SVN.
And you need MSVC2005 and up to compile VBAM. Main sound core changes are using blargg's filter and GB APU code, which he generously donated & assisted with implementing.
"*obligatory moan about no foobar support for GSF*"
Lunar, because Winamp's plugin SDK is a piece of shit, allowing for mess of code to occur, that would be a massive job. FB2K at least has some elegance about its SDK, not to mention having subsong support in the core....that said...O.O
The day FB2K supported Winamp plugins, hell would have freezed over. Not surprising since the FB2K dev was one of the original Winamp 2 devs.......
That said, I doubt the FB2K dev will allow a GSF component, at least without a major revision of the core for the code to be clean. They have strict standards in regards to how components are developed (ie, they must not use any things GUI wise not documented in thier SDK, etc...)
And then there is the licensing issues with the GPL (and the FB2K people are quite cautious about those)
Peter was actually a contractor later in the 2.5x+ stage of things from what i remember so not part of the 'original' team. and from what i've seen of the fb2k sdk, it's quite similar incertain ways to the Winamp3/Wasabi sdk but has been properly evolved and implemented in a very compentant manner.
yes winamp's 'api' is poor compared to fb2k but then again when it was attempted to make a better one people revolted (Winamp3 anyone?). there have been improvements to things to be more like the Wasabi interface for newer features but people have a reluctance to implement them (native transcoding in some of the plugins would be nice *shrugs* ). the age of winamp unfortunately hinders doing such things and really would people accept api breaks like happens with fb2k on 0.1 increments - there is always a compromise about such things (as spending too many years working on winamp plugins has taught me...).
to my understanding, fb2k can already cope with sub-songs and realistically, you can have clean code with winamp plugins, it sounds more like the gsf component was an evolutionary thing which often leads to what people deem to be 'poor' code (especially if you're only working against a single audio player to begin with).
both players have their advantages and dis-advantages. the real killer is getting the interest of someone/people to work on making a fb2k component or cleaning up the bad code, etc etc
I think fb2k was annoying to work with, because you couldn't use any custom tag editors or any sort of plugin configuration etc. Or maybe I only had scratched the surface a bit.
Mudlord, I'd appreciate any help, because I've never tackled any real programming projects. Thanks for the link to the source!
I figured the best course of action would be to build the existing in_gsf to make sure that at least worked, which obviously resulted in confusing Linker issues... Still unresolved.
You can use custom tag editors or dialogs in foobar2000 through the context menu API, but it's advised to simply support the built-in tag editor through the metadata NAME=VALUE system. Certain tags can be mapped on read/write for convenience, such as ALBUM<->GAME.
Configuration is also implemented through a custom dialog and configuration variables which are stored on shutdown and restored on startup.
As for foobar2000 only being used by 1% or less of the population, I suppose that is correct, since there were only 417,489 downloads of v0.9.6.4 last week, and that's way less than 1% of the global population.
Porting tip: If making the emulator core reentrant and exitable at any point is too complicated, I would advise using cothreads or fibers to execute the emulator and exit when the audio output buffer is full, rather than using full blown threading.
I think fb2k was annoying to work with, because you couldn't use any custom tag editors or any sort of plugin configuration etc. Or maybe I only had scratched the surface a bit.
You only scratched the surface. It has actually quite a nice SDK.
it's quite similar incertain ways to the Winamp3/Wasabi sdk but has been properly evolved and implemented in a very compentant manner.
And thats what I like about FB2K's system. Much better than what seems to be bolted-on code in Winamp's case.
Had to make some mods to it to get it to compile. Namely, removing libresample, since thats not needed when using blargg's audio core.
http://www.sendspace.com/file/hawsro
(You need MSVC2008)
All that needs to happen now, is the implementation of Gb_Apu to HA, to get it to the same level as VBA-M (VBA-M uses a 1.8.0 w/ CVS patches core, HA seems to use the 1.7.2 core)
Great!... but it refuses to compile. I'm using Microsoft Visual C++ 2008.
Building the Release version, the Linker wants "C:\Program Files\Microsoft Visual Studio\VC98\lib\msvcrt.lib"
I don't have that, so I change the command line parameter to /NODEFAULTLIB, then it wants libresample.lib, blah blah blah.
Something's wrong.
foo_gsf by Richter X at 2:02 AM EDT on April 7, 2009
Would totally love to see that foo_gsf idea, guys. Especially if it had that bandlimited synthesis stuff for the GB Audio, and some selectable interpolation like SNESAmp has (Linear, Cubic, Sinc, etc.)
The compile option I didn't try, naturally. I didn't even notice the compiled plugin packed in with the source! It already sounds so much better. When I get some time I'll try to figure some stuff out.
Thanks!
What's the purpose of GSF files for Gameboy music?
I always figured it was either proof of concept (any sound a GBA can produce can be a GSF) or a way to have GB songs in single tracks rather than all together in a GBS.
As I understand it, GBS2GSF was mostly to show that it could be done, but also because it allows you to have tags/times for GBS songs. Sure, there's an overall loss of quality. But for some people, that's not a major issue. If there's anyone working on making a M3U for Link's Awakening, take a look at the the GSF set (here). While it's not perfect (actually, I have quite a few complaints with the set), it can be helpful for anyone attempting to create the NEZplug playlist things.
If you use the Zelda4 GSF set, PLEASE NOTE that the person who tagged it didn't know better, and they listed track 60 as blank (WHICH IT'S NOT!!!). Track 60 is the credits music. In the game, it takes 30 seconds for the music to actually start playing. So whoever tagged it didn't bother listening to the song long enough. I pointed this out, and ugetab fixed the GBS file. I don't recall exactly what he did, but instead of taking 30 seconds to start playing music, it now takes about 3 seconds. Just a heads up there.
So yah, that's the major reasons for GBS files to be converted to GSF. Really, nothing special. As you can see (on CaitSith2's site), no one has submitted one (or the site hasn't been updated) in over 2 years. You're welcome to forget they exist, but I still think they're useful because they occasionally contain useful, well-done tags. Hope that answers your question. Mouser X over and out.
In NEXplug++, listen to track 60 of the US version, and track 60 of the German version. Also, the US version has 97 tracks total, but the German one only has 96. Ugetab ripped a missing song (the colored cave that's exclusive the DX version), and that's what #97 is. As near as I can tell, those are the only differences (I didn't finish listening to the German one though, so I might have missed something after 65) Mouser X over and out.
i'm tempted to just post what i had of the three gameboy zelda games for anyone else who wants to make .m3u lists. they're just text files, the link's awakening one isn't finished. if anyone is interested in doing this, i'll post up the text files.
The magic is in the emulation. At least the sound emulation. GB_Apu is loads faster AND more accurate than the current GB sound emulation in VBA at least.
But, we had to make revisions to the savestate format for blargg's sound core to work....I would imagine that would be a problem for GSF playback?
@SmartOne: Some GBA games use the normal GB audio channels. So GB_Apu affects those (other games use the Direct Sound A/B channels). And its required since the GB APU stuff is a part of the GBA HW.
@Knurek I was under the illusion that the GSF format used savestates when playing data, since I recall reading that the USF format uses savestates or smth.
You were correct that USFs use a savestate. However, in regards to xSFs in general, this is non-standard and frowned on. USFs get away with it for 2 reasons. 1) It allows the music to bypass the N64 bootup time (which can be lengthy), and 2) HCS was lazy. GSFs, PSFs, QSFs, and even 2SFs (now. This is a "recent" development) don't use savestates. Even when 2SFs did use a savestate, UF frequently complained about that fact, and wanted to fix it.
Really, if a xSF format uses savestates, it's safe to assume that it does so grudgingly. In fact, this is now an issue with USFs. Because they use a savestate, USFs are essentially locked to PJ64. This is one big reason why you don't see USF support used more widely. To get USFs supported elsewhere (PSP, Wii, etc.) it would more or less require that you port PG64 to the new platform as well. JoshW did a lot to clean PJ64 up, and even released a Linux build. But it's still very dependent on some stuff, and not terribly portable.
Hope that clarifies it a bit. Mouser X over and out.
I spent some time tracing the code to figure out the flow. It's a piece of work, that's for sure.
I placed the new VBA-M CPP and H files with the existing ones, and figured the best strategy would be to compile and use the errors to figure out how to link stuff up. (lol) DirectSound.cpp tried to compile, but it needs stdafx.h, which I'm assuming is some standard library I don't know about. Ah, part of the Microsoft Foundation Class Library. Not sure how to acquire such a thing.
stdafx.h is the default filename for the central include for precompiled headers. Typically, you throw all your includes into stdafx.h, and then stdafx.cpp does nothing but include that header and is built with compile flags to compile the headers rather than include them.
I'm guessing your project doesn't use that, so you can remove that reference and replace it with manual includes for all the necessary header files.
You don't need anything from DirectSound.cpp or the MFC port. You just need to focus on the core, which should be files like gba-arm.cpp and gba-thumb.cpp. Adding the core though would help with speed somewhat, and blargg's GB core....well we know how good that is :).
I've stared at this for hours. I changed soundTick() inside CPULoop(int ticks) of the GBA.cpp contained in the existing plugin to psoundTickfn() which, as far as I can tell, is the new sound tick emulating function of the VBA-M version of Sound.cpp.
Assuming this is even remotely correct, I still have no idea how to replace the SoundDriver functions all over Sound.cpp, for example, inside flush_samples(Multi_Buffer * buffer):