Who still has difficulty building on windows?

[bonimy]

It's admittedly a major pain, even when knowing what we're doing. It'd be nice to make some effort improving the user experience of setting up working code.

Does anyone have any experiences they'd like to share in this regard?

[Romain-Piquois]

I am exactly in this situation right now... last time I build snes9x, it was when I toyed with it like 10 years ago and was "ok". But now, with out-of-date projects file, dependancy on old stuff like Cg (not supported by NVidia anymore), dependancy on DX9 APIs, default to using FMOD (which is not freely available), etc... I am just struggling to get a correct build.

Not even talking about some piece of code imported from MAME that do not build because it is using constant initalizations at member definition inside the class or use enum class XXXX syntax. (I used the original solutions files provided and ended-up building with VC 2010, even I do have 2015 on my machine)

Would be nice to have an up-to-date, build and execute right away project for VC 2012 at least or 2015 with minimal dependancy or none if possible...

[bonimy]

I like your suggestions about Cg and DX9 and FMOD. It'd be nice to bring snes9x into the present. I don't really know what the modern libraries are that can do this, but I figure that will come with discussion.

As far as getting a working build, I think my newest project files have been applied to the repo, but they may have errors. I haven't had a chance to look due to computer issue, but if you want to give it a crack, feel free to see how it feels.

If you have any questions, post them in here and I'll look it over. Just be sure to mention what version of windows you are running, and other important info.

Cheers

[qwertymodo]

I'm pretty sure you can build without the dependencies by removing the associated preprocessor flags in the project properties (right-click the project in solution explorer> properties>c/c++> preprocessor> defined symbols though I'm writing this from memory so I might have the names wrong).

[OV2]

There isn't really any alternative to the CG library for shaders. We could possibly add a define to remove the CG dependency. FMOD could be removed, that is another thing I left in because it continued to work fine.

Switching to DX10/11/12 brings no benefit to S9x (other than maybe making compiling easier) and removes WinXP support, so that's not really something I'm interested in. That said if someone wants to add support with a compile switch then I have no problem taking it in.

[bearoso]

There's an alternative. Retroarch has a newer glsl format that seems to be the Cg shaders run through some conversion script, and that's the only thing I can get it to download.

I'm not sure what they're recommending now, as they're still updating the shaders with Cg.

[qwertymodo]

+1 for GLSL, or HLSL for DirectX (especially if the DX11/12 support happens, but it should be supported all the way back to DX9).

[rnveach]

It may also be worse then outdated technology. I have seen some cases where the code is not buildable in the latest master.

https://github.com/snes9xgit/snes9x/commit/fc7a79b2bbf0e606fc880dfa070fd5bd14cb73d7#diff-a08543285418779776b105d3c76a5130R1570 This commit added this line with some spc_core variable but it is literally not defined anywhere else that I or my compiler could find. I can compile snes9x sources save from 2009 with MSVC++ 6 better then I can compile what is in current master with anything.

[qwertymodo]

Well, that case in particular shouldn't be compiling by default anyway, as the debugger doesn't get built unless you explicitly enable it. And I don't know how long it's been since the debugger was functional. That spc_core variable appears to be from the v1.52 APU, which has since been completely re-written once, if not twice.

[OV2]

I'll commit some changes that make the CPU debugger compile again without the APU debugger.