Global rom instance

[pulsarrush]

In cb7ddbdd47122f71127ec93491add12eb4ba165a the rom was made a global. I have a particular use case, using this project as a library, which requires having multiple roms loaded and multiple sequences playing at once, would you accept a partial revert of this?

Would you also accept a PR which splits the project into two folders, core and gui?

[ipatix]

The original intention was that I found the code to be really ugly having to drag the Rom reference through every single object. Because of this I'm rather against the idea of doing (even a partial) revert. Though, after a later refactor we now have the PlayerContext, which now might be suitable to hold it (at least I can confirm that this already allows asynchronous players to run on the same game).

Do you need multiple instances for the GUI (which I wouldn't know how it's work) or only for the Core? The latter one would make sense to me and I'd say I'm generally open for such a PR. But before you put unnecessary work into it, I'd like to get a rough idea on how you'd go about it.

Also, the Rom instance is not the only global object. For example, how would you deal with configuration, which currently uses ConfigManager::Instance()?

[pulsarrush]

I didn't see PlayerContext before, that does look like a good place to hold it.

Just the core, my current implementation based off 2018-ish agbplay, which just created a custom Player.cpp that simply provides an interface to generate samples to a buffer. And it's compiled by including only a subset of files ignoring any GUI related code.

            "agbplay/src/CGBChannel.cpp",
            "agbplay/src/CGBPatterns.cpp",
            "agbplay/src/FileContainer.cpp",
            "agbplay/src/GameConfig.cpp",
            "agbplay/src/ReverbEffect.cpp",
            "agbplay/src/Rom.cpp",
            "agbplay/src/SongEntry.cpp",
            "agbplay/src/SoundChannel.cpp",
            "agbplay/src/SoundData.cpp",
            "agbplay/src/SoundMixer.cpp",
            "agbplay/src/StreamGenerator.cpp",
            "agbplay/src/Types.cpp",
            "agbplay/src/Xcept.cpp"

I was thinking of just putting the GUI and Core related code into subfolders, and not changing anything specific in this project, and simply using a build script to only include the core folder's files for my uses. But it might involve some minor tweaks besides just moving files, I also had to create a function exposing the raw buffers from StreamGenerator to the custom Player implementation.

I didn't realize Config was changed to a global either, I never had a use for GameConfig in the past, and just replaced it with a default one for all roms. So leaving this global wouldn't break anything for me, but it might be good to move it into PlayerContext too.

[pulsarrush]

I have some time and I want to work on this, which would you prefer I do first? Moving code to distinct folders, or removing dependencies on global ROM/GameConfig in-favor of a PlayerContext reference?

[ipatix]

Sorry for delaying this for so long, but I unfortunately do not have much time for this at the moment. I hope that I can have a look at it as soon as possible.

[ipatix]

I think this will probably be caught by what I'd consider agbplay 2.0 #68 with "libagbplay" since this will become somewhat necessary.