Can ZSNES be built successfully using MinGW?

Bahamut_ZERO_Clue · Post by **Bahamut_ZERO_Clue** » Fri Nov 19, 2004 12:48 am

Can you use MinGW with NASM, and the Allegro Gaming Library's Minimal DirectX 8.0 SDK for MinGW successfully even if the binary is unstable?

I heard a while back someone did by altering the sources a bit to do so, but I don't remember what exactly was editted to make it work. Currently this is my MinGW setup:

MinSYS 1.0.1.0
MinGW 3.1.0-1
MinGW Runtime 3.5
GCC Suite 3.2.3
Make 3.80.0-3
GDB 5.2.1-1
BinUtils 2.15.91-20040904
Win32api 3.1
MSYSDTK 1.0.1

I also have from the GNUWin32 set:

ZLib 1.2.1
LibPNG 1.2.7-1
UPX 1.24
UCL 1.02

And I have these:

DirectX 8.0 SDK (minimal set from the Allegro Gaming Library webpage)
SDL 1.2.7 (development package for MinGW and binaries)

Can anyone help?

evilant · Post by **evilant** » Fri Nov 19, 2004 3:36 am

I haven't tried this but I would be interested if you manage to get it to work!

In principle it should work, as (afaik) all the assembly code is in .asm files, and the .c/.cpp files probably don't rely on MS extensions.

Why don't you go for it and let us know the results? If you get stuck, post the details of what you tried and what you're stuck at, and maybe someone can help you out.

Note that you will need a version of NASM. I know that 0.98.35 and newer ones should work. Actually any version newer that 0.98.08 should work (or the original 0.98 might work, but DO NOT use Nasm 0.98.08, which has a bug).

I think you will have to hack the makefile up a bit:
- at the top of the file, change "CC=cl /nologo" to "CC=gcc"
- on the link line, change "cl" to "gcc"
- change command-line options to start with '-' instead of '/'
- comment out compiler-specific options like /Ox /G6 at first (put gcc-equivalents in later)
- instead of /libpath: you need something like -L
- comment out the .rc file and forget about it. Later, if you want an icon, use windres to compile it to an .obj which you can link with.
- with -DNO_PNG you should be able to get by with just zlib.
- in the compile rules, instead of "/Fo$@" you need "-o $@" (like in the ASM rule)
- probably other things I haven't thought of.

[Edit: P.S. are you bahamut_zero from RB ???]

Noxious Ninja · Post by **Noxious Ninja** » Fri Nov 19, 2004 5:29 am

In theory it should work, but in practice it doesn't. Last someone tried (about 3 months ago I think) it compiled fine, but crashed whenever you tried to load a ROM.

evilant · Post by **evilant** » Fri Nov 19, 2004 5:52 am

Well assuming you can make the compiler eat all the files, then any crashing that results is probably because of assumptions made in the asm code about either (1) structure layout, or (2) calling conventions.

You probably won't have problems with (1) though--I don't think there are any C structures that are accessed by asm code, its all primitive types and arrays of primitive types (disclaimer: I haven't looked too closely, I might be wrong). The most likely source of problems would be calling conventions.

If you figure out how the default calling convention on MSVC treats registers (maybe MSDN will contain the answer), then figure out how to make gcc use the same convention, it might work.

Otherwise, some hacks to the assembly code in all the right places would be needed (to save additional registers, and pop--or not pop--formal args after a call, as appropriate). That might be a pain. But gcc can probably be coaxed into generating the right code somehow (it is pretty flexible)...I'm just not sure how.

byuu · Post by **byuu** » Fri Nov 19, 2004 9:50 am

The biggest problem I've experienced in switching compilers turned out to be bugs in the original software. Each compiler will usually place variables and structures in slightly different places, even though in theory they shouldn't.
Thusly, when you read / write outside of the bounds of some of these structs, the code would continue to work on one compiler, but fail on another due to GPF errors, etc.

Post by **Nach** » Fri Nov 19, 2004 12:17 pm

Thanks for pointing out "Allegro Gaming Library's Minimal DirectX 8.0 SDK for MinGW", using this I no longer get warnings upon linking.

Unforunetly the binary still doesn't load ROMs.

Jonas Quinn · Post by **Jonas Quinn** » Fri Nov 19, 2004 2:12 pm

The mingw build does load some roms for me. For example "Airwolf 92 (PD)" can be loaded with no problems. I figured out that ZSNES crashes only on roms that have sound.

But it is too slow:
22 seconds in real time are 10 seconds in ZSNES.

funkyass · Post by **funkyass** » Fri Nov 19, 2004 10:09 pm

My guess is, the minimal DX8 SDK doesn't have proper support for direct sound?

Jonas Quinn · Post by **Jonas Quinn** » Fri Nov 19, 2004 10:57 pm

I used the following versions to compile ZSNES:

-nasm-0.98.38-1
-DirectX 9.0 SDK - (October 2004)
-libpng 1.2.7
-zlib 1.2.2
-gcc 3.4.2
-binutils 2.15.91
-Mingw 3.5

Maybe it's a bug in initializing the sound in winlink.cpp.

BTW:
- Include ctype.h in initc.c to fix warning messages about implicit declarations of islower, tolower, isupper and toupper.

- In zpng.c the variable tmp2 is only used in Linux.

Bahamut_ZERO_Clue · Post by **Bahamut_ZERO_Clue** » Sat Nov 20, 2004 3:04 am

I do know the MinGW DirectX 8.0 SDK has no d3dx.lib (libd3dx.a) library. This could be substituted by d3d8.lib (libd3d8.a). Maybe this is why some stuff crashes and stuff is slow.

The sound issue could be related to winlink.cpp which was moreoverly designed around Visual C++ after a lookover. MinGW DirectX 8.0 SDK may have some issues with this file. This should be a concern.

Nach could you post a copy of your MinGW modified makefile.win here? I'd like to research it some.

Jonas could you post where you editted those files and what to add/subtract like in a .diff patching file?

BTW the issue with the icon is pety at best. Shortcut link edit swiftly solves that problem.

BTW one last thing... could someone really explain why we have two Water Effects for ther GUI and Smoke Effect is disabled? Why not get rid of Wtare Effect 2 and replace it with Smoke?

evilant · Post by **evilant** » Sat Nov 20, 2004 5:46 am

If the necessary libraries aren't there, it won't link. (Or if you load them dynamically and they aren't there, you should get the error dialog from zsnes?).

I still think calling conventions might be to blame. Though it sounds like gcc uses __cdecl by default on x86 (which is also the default for MSVC). MSVC has some other weird conventions though like __fastcall; virtual methods use a variant called __thiscall (in which ecx is preserved by the callee, and has the "this" pointer in it).

The reason I doubt it is structure alignment is simply that I don't see a whole lot of structures in the zsnes source code! The ones I could find are just in the C/C++ code and are not used by the assembly. It's not like snes9x (which has a bunch of EQUs in an .inc file which have to match up to C structures declared in header files).

I can imagine some differences in the way globals are laid out by the compilers in initc.c, but (since they are not structs) I can't really imagine that affecting the assembly code. Hmm.

Hey, how's this: if you have a look in makefile.dos, it uses "gcc" as the compiler! I think that is the djgpp version, but still

I see it has some options like -fomit-frame-pointer. Can you try adding those to your windows makefile?

evilant · Post by **evilant** » Sat Nov 20, 2004 5:49 am

funkyass wrote:My guess is, the minimal DX8 SDK doesn't have proper support for direct sound?

I'm pretty sure I've used that minimal DX8 SDK to compile Mame. Sound worked fine.

Since Jonas has had success with gcc, we can probably figure this out. Some compiler flag we need to tweak, or something!
[oops: I didn't read his post carefully enough...only success compiling]

[Edit: the linux port is compiled with gcc, right? How different is that from the windows version?]

Post by **Nach** » Sat Nov 20, 2004 5:39 pm

Here is the source I used way back when, note you'll need everything in the package.

http://nsrt.edgeemu.com/zsnesmng.zip

I made the following slight changes when compiling on Friday:

Added LL to the end of 3 constants in winlink.cpp
Remove the include of the initguid.h or something like that at the top of winlink.cpp
Had the make file link with initguid instead of direct draw and direct sound.

evilant · Post by **evilant** » Sat Nov 20, 2004 8:18 pm

If you are using gcc as the linker, then should you assemble the nasm source files with -f coff?

For the MS linker you use -f win32... but IIRC there is some sort of incompatibility between the two, something about MS interpreting the coff standard different from everybody else?

Post by **Nach** » Sat Nov 20, 2004 8:27 pm

evilant wrote:If you are using gcc as the linker, then should you assemble the nasm source files with -f coff?

Instead of randomly speculating, why don't you look at my zip file?

evilant · Post by **evilant** » Sat Nov 20, 2004 9:41 pm

Sorry Nach! My question was directed at thin air, not specifically at you. I only skimmed your post.

With that out of the way, I randomly speculate that you have a different version of NASM than I do, since mine has no gnuwin32 target. I have the win32 build of version 0.98.38 compiled on Sep 12 2003.

Unless I misunderstood you, you can compile and link but the binary won't load ROMs?

Post by **Nach** » Sat Nov 20, 2004 10:10 pm

evilant wrote: With that out of the way, I randomly speculate that you have a different version of NASM than I do, since mine has no gnuwin32 target. I have the win32 build of version 0.98.38 compiled on Sep 12 2003.

Notice I included the NASM you need, an unmodified version won't work.

Nach wrote: Here is the source I used way back when, note you'll need everything in the package.

kode54 · Post by **kode54** » Sun Nov 21, 2004 2:02 am

This should no longer be necessary, now that Visual C++ 2003 is available for free, since the build process is automated through a makefile, rather than Visual Studio project files.

Post by **Nach** » Sun Nov 21, 2004 2:26 am

kode54 wrote:This should no longer be necessary, now that Visual C++ 2003 is available for free, since the build process is automated through a makefile, rather than Visual Studio project files.

It is neccesary for two reasons.

1) The free VS doesn't have all the Windows stuff needed (at lease according to pagefault)
2) We would like if all platfroms could use the same compiler (GCC)

kode54 · Post by **kode54** » Sun Nov 21, 2004 3:46 am

Nach wrote:1) The free VS doesn't have all the Windows stuff needed (at lease according to pagefault)

The latest Platform SDK can be downloaded separately, as can the latest DirectX SDK.

2) We would like if all platfroms could use the same compiler (GCC)

Understandable, although Visual C++ and Intel C++ optimize some code better or worse than GCC. I know ICL is better for some things, while GCC 3.3.x has proven to be the best for compiling libmad, with Intel doing worse than Microsoft, but that's the only exception I know of so far. Although, I guess this doesn't matter too much for ZSNES, considering how little C/C++ code there is.

evilant · Post by **evilant** » Sun Nov 21, 2004 4:28 am

Nearly all of the performance-sensitive code is in assembly.

Bahamut_ZERO_Clue · Post by **Bahamut_ZERO_Clue** » Sun Nov 21, 2004 8:09 am

Nach I went and redid a good bit of the sources but I have found out that winlink.cpp will need a MAJOR revamping to be compatible with MinGW. No small task. However the basic principle says it will work when this is done. I did some research on MSDN and I'm wondering why d3dx.lib is actually being used.

I also found the DirectX Import Libraries at this site so d3dx.lib can still be used as libd3dx.a

http://mywebpage.netscape.com/PtrPck/directx.htm

BTW

Post by **Nach** » Sun Nov 21, 2004 10:53 am

I was just looking some things over, and now I'm wondering if our problem is that we're not loading the DLLs...

I'll look into it.

kode54 · Post by **kode54** » Sun Nov 21, 2004 1:38 pm

Nach wrote:I was just looking some things over, and now I'm wondering if our problem is that we're not loading the DLLs...

I'll look into it.

Since it imports the relevant object factory functions manually, it should only need dxguids.lib, or the conversion thereof.

Post by **Nach** » Sun Nov 21, 2004 2:32 pm

kode54 wrote:
Nach wrote:I was just looking some things over, and now I'm wondering if our problem is that we're not loading the DLLs...

I'll look into it.
Since it imports the relevant object factory functions manually, it should only need dxguids.lib, or the conversion thereof.

Yeah, linking with libdxguid.a, guess my hunch was wrong. Also have to link with libdinput8.a. Not sure what the problem is, I tried disabling SPC emulation, but that didn't make a difference.