Re: [Tuxnes-devel] compiling tuxnes for win32

[Mike M. <che...@ya...>]

--- Jason Dorje Short <jd...@us...> wrote:
> 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...)
> 
It's broke in tuxnes i'm affraid(read as sorry).

> 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).
> 
Saddly the SDL renderer is beyond my help, but I can fix the first row of
problems with GGI.  The X11 forever will be the 3ie7 way to go for
linux/unix systems and I woulden't drop it unless X was replaced.

> >>- 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.
> 
Then we will have to come up with something.

> >>- 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"?
> 
I may have jumped the gun, there should be a win32 branch if it breaks
others.  Good work thouh have bestoed upon and to the head it went.

> >>- 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.
> 
Make it so.  If you should, put all the type.h stuff in there.  io.{c,h}
can be renamed to something else oi?

> >>- 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.
> 
That's what I think is going to have to happen.  Maby you could find a
port of nestra to win32?

> jason


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools