MINGW-packages VS mame

Have never tried to cross compile using mingw, however this page came up on a quick Google search: https://github.com/msys2/MINGW-packages/issues/6341

Then you setup a proper GNU environment, either mingw, cygwin or WSL, get the prereqs and start compiling with the proper target. You can see the used build recipe with the https://packages.msys2.org/package/mingw-w64-x86_64-gcc package. (ie https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-gcc)

If you take a look at the PKGBUILD file for mingw-w64-cmake base package, you'll see that it applies some patches that make sense for MinGW. Most notably, it makes Ninja the default build generator instead of Visual Studio.

Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=F:/MameDev/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-11.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev6, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --with-boot-ldflags='-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc' 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high' --enable-linker-plugin-flags='LDFLAGS=-static-libstdc++\ -static-libgcc\ -pipe\ -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high\ -Wl,--stack,12582912' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (Rev6, Built by MSYS2 project)

Yes, there are many challenges in reverse engineering these classic games. This is a good example.

https://www.youtube.com/watch?v=objL2hGAEgU

Living in L.A. in the 90's, I remember Pack Mann in Pasadena had this one.

http://www.arcaderestoration.com/games/3330/Gals+Panic+II.as...

The ROM dump's been done but people seem to be stuck on the RLE encoding. It's hard to say what kind of wizardry is needed in this case.

https://github.com/mamedev/mame/issues/5816

There's a good start at it in the tree ( https://github.com/mamedev/mame/blob/master/src/mame/yamaha/... ) but it's missing the sound generation which is kind of the important part :-)

> As requested by users, you can finally use delta CHD files for clone systems and software items. This allows for major disk space savings in some cases when you have multiple versions of a system or software item.

FWIW, this is commit https://github.com/mamedev/mame/commit/d1172bf710f2a7b1777ed...

The GitHub Actions workflow bgfxshaders.yml will rebuild the shaders and then zip them up as an artefact. If you push your shader changes to GitHub and let the workflow run, you can grab the rebuilt shades from there.

Note that the process of getting the MSYS64/MinGW build environment set up is simple enough that we have automated CI builds for it on GitHub Actions without needing any custom actions of our own.

I assume they’re free vend because they’re MAME based?