Roadmap

[gpascualg]

Hello!

Let me first say I'm highly hyped on this project, but there are a few things I can't figure out.

1) When/Where is electron used?

2) Is there any roadmap or features list or something where new developers/contributors could adhere to? I'd love to contribute but I don't exactly know neither where to start nor what is being done.

Thank you!

[chyyran]

1) Electron is used to host (as in, use as the web browser) for any HTML themes that Snowflake will run, specifically it is used at Snowflake.Shell.Windows.

Basically it gives the theme a window to display in, as well as access to the filesystem through electron's APIs. I do development on Google Chrome because it's easier and electron isn't fully implemented yet, but in the user will access it through Electron. All interfacing with the backend is done by https://github.com/SnowflakePowered/snowflake.js, which communicates with the StandardAjax plugin.

Snowflake runs a local webserver to host (as in, serve the HTML files). Themes such as paper-snowflake are structured as a normal web page with an index.html point of entry, so Electron is just pointed to the localhost URL (http://localhost:30000), and it runs as like a web page.

Ideally there would be a theme selector, but this isn't exactly implemented fully yet, I just use a local HTTP server at my theme's root and debug stuff in Chrome. If you want, you can try your hand at implementing a theme selector for electron, themes are loaded from %appdata%/roaming/Snowflake/theme, or %cd%/theme in DEBUG mode, with each theme having it's own directory, and theme metadata stored in a theme.json file at the theme root.

2) Yeah, sorry about not having a clear roadmap. At this point in time, although the base API is essentially complete, there are a lot of plugins that need to be written so that Snowflake is fully functional. Right now, I need some help wrapping emulators to work with Snowflake, see issue #140. If you need examples, check out emulator-RetroArchBridge (in fact there are a lot of RetroArch cores I have yet to wrap), or emulator-DolphinBridge to see how I hack around the configuration files of each emulator, and to get yourself acquainted with the flag system.

I'm also working on a revamped scraping API at issue #170. If you're familiar with reading data from a ROM file, writing a few FileSignature comparators would help. It's a rather self-explanatory interface

If you're good with web design, see if you can improve https://github.com/SnowflakePowered/theme-paper-snowflake, or even start writing a brand new theme.

note

Once you clone the repository there are a few steps to get started. First you must get the platform and controller definitions and run grunt on them so they spit out *.controller and *.platform files, and drag theme into the controllers and platforms folder in the application directory if in DEBUG build, or the correct appdata location in RELEASE builds. Then you have to copy the emulatordef file for an emulator into the emulators directory, so that Snowflake knows the emulator exists, and download and extract the emulator files into a directory with the same name (i.e, RetroArch goes into emulators/retroarch/). Then you copy Snowflake.StandardAjax.dll into the plugins folder to expose the AJAX endpoints, and any relevant plugins into the plugins folder. To be honest, this is all a big mess right now without proper instructions, which is another thing to do on the list.. I plan on writing a script to set up the environment properly but other things take priority.

Also, Scraping is very slightly broken at the moment, which is what #170 attempts to fix, so if you get your environment set up you may have trouble adding games to test with. If you need I can send you a dummy games.db so you can test flags or stuff.

[gpascualg]

That's a lot of information ;) But it's fine, I'll take a look at how it all works first and as soon as I get the hang of it I'll start working on something.

Themes

About themes, why doesn't debug releases look on the %appdata%... folder also? On a side note, does on Linux search in (for example) $HOME/.snowflake/theme? Of course %cd%theme would still also work.

Sorry for all that questions, but programming that theme selector might be a good start.

Portability

Just a quick question, I've been looking throught the emulators bridges and I've seen all of them use "windows extensions", such as .exe and .dll. My main interest being linux, has that been thought?

Maybe, in case it is not, we could skip the extension and let the API (or its handler) decide the extension.

Signatures

Sure, althought I've never worked with ROMs I've done quite a few parsers for savegames, so it shouldn't be that hard. Which platforms are you interested in?

---

I'll keep you updated! Thank you for all that info. Do you mind if I write some kind of setup guide on the wiki? Might be useful for new users/devs.

EDIT: Just seen 138...140 issues, those answer some questions

[chyyran]

Sure, you can have DEBUG look in AppData as well, relevant lines are here, just comment out the #if. Yes, I do believe if Snowflake is run in a Mono environment it looks at $HOME/.snowflake/theme as a replacement for AppData.

As for portability, as the EmulatorBridges and the shell (Snowflake.Shell.Windows) are the only part of Snowflake that interact with native assemblies, the plan is to rewrite them for each operating system Snowflake supports. Everything else, including all the APIs are intended to be platform-agnostic, provided there is a proper runtime for it to run on, i.e. Mono, or in the future, CoreCLR. There isn't much way to determine the proper extension as the behavior of emulators vary wildly. For example, RetroArch takes in a core (either .dll or .so on Linux) as an argument, while other emulators are run directly from the executable. These changes are trivial but I wanted to keep the API as low-level, for lack of a better word, as possible so that if someone comes along and decides to do something crazy like call directly into the libretro API, they can do that.

In fact, the only reason this hasn't been ported to CoreCLR is because there may be some libraries I rely on that do not yet have a version that supports CoreCLR, and those parts of code that rely on such libraries will have to be rewritten.

So, for now, the plan is to run on Mono. It's not an ideal solution but it works fairly well, and Snowflake isn't very complex so I don't forsee any major bugs. The only issue is writing a shell (something like Snowflake.Shell.Linux) that works properly with Linux, as well as emulator bridges that call the Linux equivalents of the emulators.

Feel free to write a setup guide, that would be awesome.

---

In regards to parsers, theres the list at #170. All it needs is a verification of the game header, and if possible, getting a game ID from the header. For some of them I use .NET DiscUtils and extract the relevant files from the ISO, for others like the PSX one, as the CD-XA format isn't readable by any library I've found I just opened up the first few hundred KiB and used regex to search for the ID.

[chyyran]

I've written up a comprehensive roadmap at the wiki:

https://github.com/SnowflakePowered/snowflake/wiki#roadmap

If you have any more questions, feel free to contact me.