Re: [Tuxnes-devel] compiling tuxnes for win32

[Jason D. S. <jd...@us...>]

Mike Mestnik wrote:
> Thank you for the patch, I'l see about commiting it.  Just one question
> are you running from CVS?  The tuxnes-0_75_branch is latest Stable, it has
> some fixes 0.75 did not but nothing that effects the build.

Yes, I'm working from the CVS version.

> Comments within.
> --- Jason Dorje Short <jd...@us...> wrote:
> 
>>Since I happened to be compiling some other programs for win32, I did 
>>the same with Tuxnes.  Naturally, it didn't work.
> 
> This is what the project needs, TESTING.  I'd like to make a realese for
> what is in CVS, but it's pre-alpha.  I'd like to post any Windows bins
> that we can get working.

I have little knowledge about what libraries the renderers require or if 
it's even possible to get a windows executable to work.

There is an SDL renderer, right?  But I haven't compiled SDL for 
windows, and it will probably take a lot of work to do so.  (On the 
other hand this would allow me to compile other programs with sdl...)

What about dropping the other renderers and keeping only the SDL one? 
Is there anything provided by the others that SDL doesn't have?  Not 
that this is needed or anything, but it might make maintainence easier 
(like the GGI problem - I don't even know what GGI is).

>>- I had to remove io.h since it conflicted with a header include file 
>><io.h>.  I didn't get far enough to find out if this caused problems. 
>>It should probably just be renamed.
> 
> Hmm, <io.h> != "io.h";  The only thing I'd change it to is "_io.h" as
> input-ouput.h is not my idea of short.  I don't know if this is realy a
> problem or not.  It would seam that any name we use could exist as a
> system header.

I suppose so.  But as "io.h" it definitely doesn't work.  fcntl.h has 
#include <io.h> for some important typedefs, and these get skipped.

>>- I imported mkdir.m4 from another project to check to see if mkdir 
>>takes two arguments or one.  I added this in m4/mkdir.m4 and modified 
>>autogen.sh accordingly.
> 
> I'm going to start a branch for win32, this will be the first commit.

A "branch"?

>>- Most of the other changes are good and obviously correct.  They may 
>>help compilation on some posix systems.  I've replaced some checks like 
>>"#ifdef __FreeBSD__" with better checks like "#ifdef HAVE_SYS_ENDIAN_H".
> 
> We need lots of this kind of house cleaning all over.  Feel free to go
> nutz.

Probably a new header file could contain a lot of the stuff.  I think 
autoconf recommends a system.h.  support.h is also a good name.

>>- Where I finally hit a wall was with mmap, which isn't available on 
>>Windows.

> This is where nestra realy shines, our parent project.  The mmap is needed
> for the hand made asm code that emulates the NES, there is a C based
> emulator try using it for win32.  Currently the nes memory image MUST be
> found at a [1]logical addess knowen by the person making the [2]asm code.
> 
> [1] The mmap makes the unix process see the same physical ram twice, at
> two diffrent addresses we only use the mmaped one.
> [2] In table.x86, the code in emulator_x86_asm.S is only used as a
> fallback for self modifying code.

Ouch.

Given that computer speeds are continually advancing while the NES 
emulation requirements remain constant, I would think C-based emulation 
would be the way to go.

jason