Universal SDL port + removing DOS support (2.0.13)

[TrashRaccoonSnuffy]

It's currently extremely hard nowadays to compile ZSNES for DOS, even with all the right tools such as DJGPP, older versions of borland C, etc, it is just simply way too outdated to the point where you really need to emulate or have the older hardware to do the compilation process. There should be an effort to clean up the codebase and remove all the DOS related code to make it easier to maintain and reduce the amount of bugs that come from it. 1.51 and 1.42 are pretty good versions for DOS, either way.

The official (albeit unreleased) ZSNES 1.53 removed MS-DOS support already. https://board.zsnes.com/phpBB3/viewtopic.php?t=139390

I prefer to wait on a response to this, as I'm planning to help with the major rewrite of the SDL interface and a proper port to SDL 2.0 so that there is only one universal version of the code that works with both Windows and Linux with their specific compilation tools.

[xyproto]

I am in favor of removing support for DOS!

Porting to SDL2 would be an excellent improvement. There is an sdl2 branch that compiles with SDL2, but does not run properly yet, but it is probably a bit outdated by now.

Thanks for all the commits and PRs.

[TrashRaccoonSnuffy]

https://github.com/xyproto/zsnes/tree/2.0.13-experimental (I don't know if 2.0.13-experimental is the best name for this branch). It's not ready for main yet so don't push.

I've started to work on a new branch that currently gets rid of all of the DOS/Windows code to make a universal branch that works on both Windows and Linux using SDL1.2 (I still haven't gotten around to converting it to SDL2, because I can't install the i386 package due to missing requirements that break apt), and it's compiling and running fully on Windows now.

Currently it only runs on OpenGL and SDL1.2, and I'm reimplementing the netplay (for #2 , can be used with the -join and -host console flags), it's still majorly incomplete though. It does work, but it has a lot of lag over the net. #19 is still a problem. And it needs the software renderer reimplemented too, and the crashes addressed.

[xyproto]

Not bad! I'll give it a spin.

[TrashRaccoonSnuffy]

Yeah, the branch does not have all features of the current main one. all games are playable though (minus some random crashes because of the multithreaded audio, i'll look into that too soon), but I'll be readding features and porting as I work on it further, filters and hires are also disabled, to simplify the rendering code to make it easier to port to SDL2.

It'd be nice to solve the compilation issues on Ubuntu, for now I added a flag to the makefile to use the repository folder for libraries.

[xyproto]

Yeah, I tried porting the Makefile to CMake, hoping that it would help solve the Ubuntu dependency issues, but after a lot of work and compilation, it ended up not working.

Part of the issue is that a parser tool needs to be compiled for one platform, that in turn generates code that needs to be compiled for another platform.

If I rewrote the parser tool, or could remove it, the build process should be much simpler.

[TrashRaccoonSnuffy]

Yeah, I tried porting the Makefile to CMake, hoping that it would help solve the Ubuntu dependency issues, but after a lot of work and compilation, it ended up not working.

Part of the issue is that a parser tool needs to be compiled for one platform, that in turn generates code that needs to be compiled for another platform.

If I rewrote the parser tool, or could remove it, the build process should be much simpler.

If you mean parsegen for generating the zsnes cfg file and the reader, I actually addressed this to some extent on the branch, there's a REGEN_PSR flag that's used to generate the PSR's C and header files once and it works for all platforms now that the psr files do not have any system dependant ifdef's. I'll probably move that to it's own folder.

[TrashRaccoonSnuffy]

Currently looking into the possibility of porting ZSNES to x32 instead (see -mx32 on GCC), as that is x86_64 with 32 bit pointers and most of the ASM code should remain compatible without much modifications, though all of the libraries (probably a lot because of SDL2 and X11/GL requirements) will have to be recompiled as x32 unless they can somehow interface with eachother, with x86_64 that might be a possibility but I'd have to look into it.

Also fixed a bunch of exhirom games not booting at all or having bugs, which was due to incorrect mapping from the Fusoya 8MB fixes. Still no dice for Super Mario RPG, though.