nesdev.org

https://github.com/clbr/gsscli

The new compiled spc code, and a cli GSS exporter. The cli version's output differs in a few places from the Windows version though, probably some bugs somewhere. Couldn't yet test it on hw.

Is there a compiled .exe available? If not, could someone compile one? Thanks.

Oh, forgot to post here, this fixed the hangs. Using the cli exporter's output sounds fine too, the byte differences were minor and only in size bytes and sfx/music data. It created some bytes smaller optimized songs for some reason, which explained the size byte changes. One byte difference was in BRR data.

There is no exe.

There is no exe

Yes there is. The editor. Here's one.

https://github.com/nathancassano/snesgss?files=1

I haven't used it, but the documents say "The editor exports a number of files: spc700.bin"

I would assume that you had to modify the editor exe to get it to output a modified spc engine.

Right?

I don't see spc700.bin in your files, so am I to assemble it from spc700.asm ?

There is no exe, as in you need to compile it if you want one. spc700.bin includes all your sfx and sounds used by your music, so it's unique to your project.

I didn't modify the editor, I ported the cli logic to a platform-independent binary, under the cli/ folder. You certainly could compile the editor with my changed spc code if you have a suitable Windows Borland env. The cli version is able to export the bin files from a gss file, which you can create with the existing exe from Shiru (that github link is way out of date), but even in that case you need to compile the cli version.

calima wrote:There is no exe, as in you need to compile it if you want one.

Can I expect that developers of retro console games who use Windows will either have already installed MinGW-w64 and MSYS2 or be willing to install them? My current build process requires Python and GNU Make, and I occasionally get complaints that installing a Python interpreter is a barrier.

calima wrote:You certainly could compile the editor with my changed spc code if you have a suitable Windows Borland env.

Does the free "classic" Borland C++ compiler on this page work, or is the (trialware) C++Builder required?

tepples wrote:

calima wrote:There is no exe, as in you need to compile it if you want one.

Can I expect that developers of retro console games who use Windows will either have already installed MinGW-w64 and MSYS2 or be willing to install them?

Of course not. That'd be a barrier. /s

I wonder if people would install Free Pascal / Lazarus for my software... it's only 154MB too, only 1.3GB on disk...

I didn't modify the editor, I ported the cli logic to a platform-independent binary, under the cli/ folder

Ok, so if I'm understanding you. I just need to compile the stuff in the cli folder, which makes a minimal comand line tool to make the spc700.bin. (with the bug fix)

I don't have mingw, but I do have cygwin installed. And I have gcc on my linux computer (that I rarely use)

tepples wrote:

calima wrote:There is no exe, as in you need to compile it if you want one.

Can I expect that developers of retro console games who use Windows will either have already installed MinGW-w64 and MSYS2 or be willing to install them? My current build process requires Python and GNU Make, and I occasionally get complaints that installing a Python interpreter is a barrier.

Well, I already told that like, 2 years ago? Do not worry too much about that; if the tools do work, any free software/tools is fine for the common user. One easy step you can do to lower the barrier is to bundle the tools into an installer (Innosetup?) so the user just has to click "next" through it to install. Whatever that minimises the steps to get the thing running is good for the common "noob".