tuxnes-devel — Development discussion for the TuxNES project

Re: [Tuxnes-devel] Smoother scrolling

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

Yes you are correct, how ever tuxnes takes care of counting ticks in the ASM.  Every time we draw
a frame it's been 1/60 of a second nes time, so we just need to make the real computer emulate
that.  In most video games timing will be constant, this way we don't get into complex
acceleration equations and such.  Too take care of the time we spend when were not sleeping we put
the gettime as close as posible to where we sleep.

Also I don't normally keep track of total time.  I don't know how different the 2 methods are, but
I know my way doesn't get overflowed.  What I do is reset my tick ctr to 0 every time I sleep, I
use the current time to populate basetime(Renamed to lasttime).  See my patch for an example that
includes a hybrid method.  I think it would be safe to remove the "if ( frame > 1800 )", I'd like
to here your comments.

--- digression ---

Yes you are correct, how ever video games use polling.  It's not clear what to do with a move once
the frame(round) is over, so processing(scoring) of that move MUST wait for the next round.  We
could take the input and differ scoring, but this would only make the usleep for this round a bit
less.  It's ok to ignore the input until it's round is being scored.

Also the nes uses polling, so we poll when it asks us too.  It would be cool to make this script
able for things like up-up-down-down...  Think mric type nes scripting :)

I've attached what I committed it's should hit the backup CVS server in 2 days.

mike

--- Jason Dorje Short <jd...@us...> wrote:
> Mike Mestnik wrote:
> > I was chasing a simular problem, but I coulden't get any thing to work.  I don't think it's
> > correct to cahnge the usleep, as it's based on the NTSC standared.  I.E. 16666 = 1 frame and
> if
> > were n frames ahead 16666 * ( n - 1 ) is how long we wait.
> 
> You don't want to usleep for a fixed amount of time, or you'll get 
> *behind*.  For instance if you sleep for 10 useconds and then do some 
> calculations that take 5 useconds, your tick length is actually 5 
> useconds instead of 10 useconds as you wanted it to be.  (Just using 10 
> as an example.)
> 
> Instead you want to do your 5 usecond calculations then sleep for just 
> the remaining 5 useconds.
> 
> The easiest solution is to track the time of each tick.  Use a timeval 
> struct to tell when the next "tick" should occur.  Then before sleeping 
> figure out how long is left between now and then, and sleep for that long.
> 
> Something like:
> 
>    struct timeval next, now;
>    int usec;
> 
>    /* This is the only time we call gettimeofday on 'next'.  After
>     * this we just increment it. */
>    gettimeofday(&next, NULL);
> 
>    while (1) {
>      next.usec += TICK_TIME;
>      if (next.usec >= 1000000) {
>        next.usec -= 1000000;
>        next.sec++;
>      }
> 
>      do_something();
> 
>      gettimeofday(&now, NULL);
> 
>      usec = 1000000 * (next.sec - now.sec) + (next.usec - now.usec);
>      if (usec > 0) usleep(usec);
>    }
> 
> In short, something like the attached patch should work.  I haven't 
> tested it, though.
> 
> 
> --- digression ---
> 
> There are also external events that generally need to be handled.  You 
> generally shouldn't poll for these (however this is NES emulation so 
> it's probably okay to be inefficient).
> 
> I've generally written network code where you want to call select() 
> while having a "tick" in place as well.  This works great since select 
> just takes the timeval struct as an argument.
> 
> In GUI code you want to either get interrupts or pass the waiting off to 
> a GUI function that can handle the interrupts directly.  My experience 
> is in GTK where you call a function to set a timer, then pass control 
> back to GTK.  While GTK has control it can do updates (like redrawing 
> windows), handle events (if a key is pressed GTK will call your 
> program's handler for that key), or handle the tick when the time comes 
> (GTK will call your program's handler for that tick).  SDL has something 
> similar, although it's generally implemented with polling anyway.
> 
> jason
> 


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Re: [Tuxnes-devel] Smoother scrolling

[Ryan J. <pro...@ya...>]

On Tue, Jan 20, 2004 at 03:43:48AM -0500, Jason Dorje Short wrote:
> 
> but I guess the problem would kick in after about 60 minutes anyway, so 
> it's just as well.  This calculation needs to be done with an 8-byte 
> "long long".  (Side note: I didn't know a "long" was only 4 bytes???)

I tried that myself, but forgot a cast, so the emu just hung. I got
frustrated and gave up.  I feel stupid now :-(

> So, here's a new patch.
> Does this work better than the current behavior on your system?

Definately!  Things look a lot smoother now.  I've noticed a couple of
things however.  It seems to run more smoothly in some display modes
than in others. Might this have something to do with the difference
between the NTSC refresh rate and whatever rate my monitor is running
at?  (I don't know too much about that stuff (yet)).

The new behavior seems to make the emulator more sensitive to timing
problems when sharing the CPU with another cpu-bound process. Example: I
was testing the patch with Super Mario Brothers.  After a few minutes,
cron started a password-cracking process in the background.  Not only
did play slow down (as with the old behavior), but every few seconds the
graphics would glitch.  It looked like it started to redraw the
framebuffer, but instead of drawing it at the top of the screen it
started in the middle.  Kind of hard to describe. :-/

Other than that, it looks good.

Re: [Tuxnes-devel] Smoother scrolling

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

Ryan Jackson wrote:
> On Mon, Jan 19, 2004 at 02:27:47PM -0500, Jason Dorje Short wrote:
> 
>>This is hard to change because timeframe is a very different concept. 
>>But this patch may be a little better (now that I got tuxnes to 
>>compile).  It's indistinguishable from the current behavior on my computer.
> 
> 
> It works great on mine... for about a minute, then the emu goes nuts.
> usec overflows and wraps around, becoming negative.  Because of that, it
> thinks we've missed a whole crapload of frames, so it just resyncs over
> and over again.

It wraps around on frame 2148.  Imagine that.  In part this comes 
because of my overzealous desire to be accurate: I use

   (1,000,000 * frame) / 60

instead of

   (1,000,000 / 60) * frame

but I guess the problem would kick in after about 60 minutes anyway, so 
it's just as well.  This calculation needs to be done with an 8-byte 
"long long".  (Side note: I didn't know a "long" was only 4 bytes???)

Instead of using "long long" it would be nice to use sint64, if such a 
thing exists.  SDL defines an Sint64, but not all of the code uses SDL, 
right?

So, here's a new patch.

Does this work better than the current behavior on your system?

jason

Re: [Tuxnes-devel] Smoother scrolling

[Ryan J. <pro...@ya...>]

On Mon, Jan 19, 2004 at 02:27:47PM -0500, Jason Dorje Short wrote:
> This is hard to change because timeframe is a very different concept. 
> But this patch may be a little better (now that I got tuxnes to 
> compile).  It's indistinguishable from the current behavior on my computer.

It works great on mine... for about a minute, then the emu goes nuts.
usec overflows and wraps around, becoming negative.  Because of that, it
thinks we've missed a whole crapload of frames, so it just resyncs over
and over again.

I've been playing with it a bit, but my patch has some problems (timing
issues with some games).

Re: [Tuxnes-devel] Smoother scrolling

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

Ryan Jackson wrote:
> Changing the usleep() delay doesn't sound right to me either, but it's
> the only thing I've found that works.
> 
> Which gettimeofday() call did you remove: the one in set_timeframe() or
> set_frameskip()?  I tried changing set_timeframe(), but all that
> happened was the emu ran way too fast.  The scrolling was smooth though.
> :-)  What exactly was the problem you were chasing?

The problem is that resynchronize() is only accurate to within 1 frame; 
i.e., 1/60 of a second.  Under my patch it should be accurate to within 
1 microsecond (1/1000000 of a second).

The patch removed both set_frameskip and set_timeframe.  The timeframe 
variable is removed entirely.  All we track is the current frame, and 
from this we can determine what time we should be at.  So the usleep 
sleeps until this time when resynchronize() is called.  resynchronize 
also sets frameskip (if we're more than 1 frame behind) and desync (if 
we're more than 20 frames behind).

jason

Re: [Tuxnes-devel] Smoother scrolling

[Ryan J. <pro...@ya...>]

Changing the usleep() delay doesn't sound right to me either, but it's
the only thing I've found that works.

Which gettimeofday() call did you remove: the one in set_timeframe() or
set_frameskip()?  I tried changing set_timeframe(), but all that
happened was the emu ran way too fast.  The scrolling was smooth though.
:-)  What exactly was the problem you were chasing?

Re: [Tuxnes-devel] Smoother scrolling

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

Jason Dorje Short wrote:
> Mike Mestnik wrote:
> 
>> I was chasing a simular problem, but I coulden't get any thing to 
>> work.  I don't think it's
>> correct to cahnge the usleep, as it's based on the NTSC standared.  
>> I.E. 16666 = 1 frame and if
>> were n frames ahead 16666 * ( n - 1 ) is how long we wait.
> 
> 
> You don't want to usleep for a fixed amount of time, or you'll get 
> *behind*.  For instance if you sleep for 10 useconds and then do some 
> calculations that take 5 useconds, your tick length is actually 5 
> useconds instead of 10 useconds as you wanted it to be.  (Just using 10 
> as an example.)

Well, that patch didn't work at all.

The problem, though, is that you're tracking time in frames instead of 
in useconds.  If you're half a frame ahead and you wait for one frame, 
then you'll be half a frame behind.  Or if you wait until you're a frame 
and a half ahead and then wait a frame, you get uneven playing (2 frames 
in quick succession, then a wait before the next frame).

This is hard to change because timeframe is a very different concept. 
But this patch may be a little better (now that I got tuxnes to 
compile).  It's indistinguishable from the current behavior on my computer.

jason

[Tuxnes-devel] Compiler warning

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

When I compile tuxnes I get a simple compiler warning.  This patch fixes it.

jason

[Tuxnes-devel] aclocal fails

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

When I run autogen.sh I get:

[jdorje@devon:~/src/tuxnes]$ ./autogen.sh
aclocal: configure.ac: 42: macro `AM_PROG_AS' not found in library

I'm using debian unstable (sid).

[jdorje@devon:~/src/tuxnes]$ aclocal -v
aclocal: unrecognized option -- `-v'
Try `aclocal --help' for more information.
[jdorje@devon:~/src/tuxnes]$ aclocal --version
aclocal (GNU automake) 1.4-p4

Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Written by Tom Tromey <tr...@cy...>

I do have the option of upgrading my automake.  But if a more recent 
version is required autogen should check for it.

jason

Re: [Tuxnes-devel] Smoother scrolling

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

Mike Mestnik wrote:
> I was chasing a simular problem, but I coulden't get any thing to work.  I don't think it's
> correct to cahnge the usleep, as it's based on the NTSC standared.  I.E. 16666 = 1 frame and if
> were n frames ahead 16666 * ( n - 1 ) is how long we wait.

You don't want to usleep for a fixed amount of time, or you'll get 
*behind*.  For instance if you sleep for 10 useconds and then do some 
calculations that take 5 useconds, your tick length is actually 5 
useconds instead of 10 useconds as you wanted it to be.  (Just using 10 
as an example.)

Instead you want to do your 5 usecond calculations then sleep for just 
the remaining 5 useconds.

The easiest solution is to track the time of each tick.  Use a timeval 
struct to tell when the next "tick" should occur.  Then before sleeping 
figure out how long is left between now and then, and sleep for that long.

Something like:

   struct timeval next, now;
   int usec;

   /* This is the only time we call gettimeofday on 'next'.  After
    * this we just increment it. */
   gettimeofday(&next, NULL);

   while (1) {
     next.usec += TICK_TIME;
     if (next.usec >= 1000000) {
       next.usec -= 1000000;
       next.sec++;
     }

     do_something();

     gettimeofday(&now, NULL);

     usec = 1000000 * (next.sec - now.sec) + (next.usec - now.usec);
     if (usec > 0) usleep(usec);
   }

In short, something like the attached patch should work.  I haven't 
tested it, though.


--- digression ---

There are also external events that generally need to be handled.  You 
generally shouldn't poll for these (however this is NES emulation so 
it's probably okay to be inefficient).

I've generally written network code where you want to call select() 
while having a "tick" in place as well.  This works great since select 
just takes the timeval struct as an argument.

In GUI code you want to either get interrupts or pass the waiting off to 
a GUI function that can handle the interrupts directly.  My experience 
is in GTK where you call a function to set a timer, then pass control 
back to GTK.  While GTK has control it can do updates (like redrawing 
windows), handle events (if a key is pressed GTK will call your 
program's handler for that key), or handle the tick when the time comes 
(GTK will call your program's handler for that tick).  SDL has something 
similar, although it's generally implemented with polling anyway.

jason

Re: [Tuxnes-devel] Smoother scrolling

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

I was chasing a simular problem, but I coulden't get any thing to work.  I don't think it's
correct to cahnge the usleep, as it's based on the NTSC standared.  I.E. 16666 = 1 frame and if
were n frames ahead 16666 * ( n - 1 ) is how long we wait.

My solution was to eliminate the extra gettimeof day call.  You only need one to get timing right.
 Here is how I normaly do video games...

Loop ()
  Read input  <-- this is done inline with nes code and will not be called every frame.
  Adjust position of objects, calculate score, ect  <-- this is all in nes code.
  Draw
  x = gettimeofday 
  sleep frametime * ( x - y - 1 )
  y = x <-- we now use another gettimeof day call for this
endloop

This is how tuxnes lookes...
set_renderer_basetime
Loop () { /* renderer.c */
  set_timeframe /* This is my y = x */
  call nes rom { /* These may happen in any order based on rom loaded */
     Optionaly read input
     Optionaly play sound
     Change memory /* This includes drawing something */
  }
  Draw contens of nes memory.
  set_frameskip
  resynchronize /* Notice time spent in resynchronize is not accounted for! */
}

Here is the last commit.
Mon Dec 8 16:46:33 2003 UTC (5 weeks, 6 days ago) by cheako
RCS file: /cvsroot/tuxnes/tuxnes/emu.c,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- tuxnes/tuxnes/emu.c	2003/12/05 23:05:37	1.89
+++ tuxnes/tuxnes/emu.c	2003/12/08 16:46:33	1.90
@@ -4,7 +4,7 @@
  * Please see the README and COPYING files for more information regarding
  * this project.
  *
- * $Id: emu.c,v 1.89 2003/12/05 23:05:37 cheako Exp $
+ * $Id: emu.c,v 1.90 2003/12/08 16:46:33 cheako Exp $
  *
  * Description: This file contains the main() function of the emulator.
  */
@@ -2116,7 +2116,7 @@
     }
 
   /* enter the Game Genie codes */
-  while (gamegenie != 0)
+  while (gamegenie > 0)
     {
       if ( gamegenie == 1 ) gamegenie = 0;
       if (verbose) fprintf (stderr, "------------------------\n");
@@ -2162,6 +2162,7 @@
             fprintf (stderr, "Game Genie: value at %04X = %02X\n", address,
                      MAPTABLE[address >> 12][address]);
         }
+      if ( gamegenie == 0 ) break;
        ggcode[--gamegenie] = '\0';
        for (; gamegenie >= 2; gamegenie--)
 	  if ( ggcode[gamegenie-1] == ',' ) break;



--- Ryan Jackson <pro...@ya...> wrote:
> I'm new to the list, but I've been following the project for quite some
> time now.  So please forgive me if I say something stupid ;-).
> 
> I've noticed that on my hardware (a rather unimpressive PII-350 with
> nVidia RIVA TNT video card) that tuxnes' scrolling seemed kindof choppy.
> I started looking around the code, and found the resynchronize()
> function.  By tweaking the value passed to usleep(), the scrolling
> became almost perfectly smooth.  The one side effect I've noticed is
> that sound gets out of sync a bit more often than before, but not by
> much.
> 
> I was considering writing a patch that would add a command-line option
> to decrease this delay by some amount (1 or 2 milliseconds seems to do
> it for me), but I was wondering if anyone might have a better solution.
> I'm not sure what unintended effects my hack might have.  Any ideas?
> 
> Also, has anything been committed to CVS in the last couple of months?
> There have been some postings to the list that indicate there has, but
> 'cvs update' doesn't download anything.  Maybe I'm just smoking
> something... ;-)
> 
> -- 
> Ryan Jackson
> pro...@ya...
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxnes-devel


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

[Tuxnes-devel] Smoother scrolling

[Ryan J. <pro...@ya...>]

I'm new to the list, but I've been following the project for quite some
time now.  So please forgive me if I say something stupid ;-).

I've noticed that on my hardware (a rather unimpressive PII-350 with
nVidia RIVA TNT video card) that tuxnes' scrolling seemed kindof choppy.
I started looking around the code, and found the resynchronize()
function.  By tweaking the value passed to usleep(), the scrolling
became almost perfectly smooth.  The one side effect I've noticed is
that sound gets out of sync a bit more often than before, but not by
much.

I was considering writing a patch that would add a command-line option
to decrease this delay by some amount (1 or 2 milliseconds seems to do
it for me), but I was wondering if anyone might have a better solution.
I'm not sure what unintended effects my hack might have.  Any ideas?

Also, has anything been committed to CVS in the last couple of months?
There have been some postings to the list that indicate there has, but
'cvs update' doesn't download anything.  Maybe I'm just smoking
something... ;-)

-- 
Ryan Jackson
pro...@ya...

Re: [Tuxnes-devel] CVS commits

[Jeroen Ruigrok/a. <as...@wx...>]

-On [20040105 22:32], Mike Mestnik (che...@ya...) wrote:
>Go ahead, I have access if you fail and you can attach or copy past any
>patches to me.

It still works. :)

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://diary.in-nomine.org/
I must be cruel, only to be kind...

Re: [Tuxnes-devel] CVS commits

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

Go ahead, I have access if you fail and you can attach or copy past any patches to me.

--- Jeroen Ruigrok/asmodai <as...@wx...> wrote:
> I should see if I can still commit to the tuxnes repo and get some of
> these patches in.
> 
> -- 
> Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
> PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
> http://www.tendra.org/   | http://diary.in-nomine.org/
> We must believe in ourselves and in our dreams.  For all is not lost.
> We have only to stand straight and tall, knowing ourselves to be no less
> than those who came before us.  And we must never loose hope, never,
> never, never . . .
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxnes-devel


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

Re: [Tuxnes-devel] Fwd: present but cannot be compiled (Was: I was asked to report this.)

[Jeroen Ruigrok/a. <as...@wx...>]

-On [20031204 17:32], Mike Mestnik (che...@ya...) wrote:
>Thankyou for your answer.  I'm new at dealing with these sorts of
>things.  I guess the question is, how do we get ./configure to do what
>we want?  It's not important to me how autoconfig dose it's thing.  I
>just would like to make sure that if I use Xshm.h and for OSXYZ I also
>need to use strings.h or something, that it gets done.

I could do this, been doing that for TuxNES in the past. :)

(if only subversions would come online with the autoconf CVS already,
*sigh*, got to love having rooted boxes which host open source projects)

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://diary.in-nomine.org/
Water, water every where.  Nor any drop to drink...

[Tuxnes-devel] CVS commits

[Jeroen Ruigrok/a. <as...@wx...>]

I should see if I can still commit to the tuxnes repo and get some of
these patches in.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://diary.in-nomine.org/
We must believe in ourselves and in our dreams.  For all is not lost.
We have only to stand straight and tall, knowing ourselves to be no less
than those who came before us.  And we must never loose hope, never,
never, never . . .

[Tuxnes-devel] (no subject)

[Will D. <wd...@po...>]

[Tuxnes-devel] configure.ac

[Jason D. S. <js...@an...>]

I took configure.in and:

- Applied the Xlib warning fix.
- Renamed it configure.ac (this forces the use of newer autoconfs).
- Removed acconfig.h (running autoconf will tell you to do this).
- Made sure all AC_DEFINE calls had 3 parameters.
- Ran autoscan, and added new checks based on what it said.
- Merge AC_SUBST calls.

This isn't going to make any big difference, but the removal of 
acconfig.h is generally helpful.


There is a lot of cruft in there that I would never have put there, but 
the original authors probably wouldn't want removed.


For instance:

if test "x$enable_warnings" = "xyes"; then
   CFLAGS="$CFLAGS -pipe -W -Wall -ansi -pedantic -Wbad-function-cast \
   -Wcast-align -Wcast-qual -Wchar-subscripts -Winline \
   -Wmissing-prototypes -Wnested-externs -Wpointer-arith \
   -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings"
else
   CFLAGS="$CFLAGS -pipe -Wall"
fi

is generally not too helpful, since only the developers will want it and 
you can get the same effect just by adding a CFLAGS to make.  It is also 
likely to break under non-gcc compilers.


Then we have:

dnl--------------------------------------------------------------------
dnl Don't assume we want high level optimisations, it is known to
dnl produce broken code on certain architectures using certain compilers
dnl --------------------------------------------------------------------
CFLAGS="-O -g"

which again seems gcc-centric and is probably wrong (I'm told that every 
"common" compiler bug in optimized code is actually a bug in the code 
being compiled).


jason

[Tuxnes-devel] goodnight, here is a patch for some of the warnings. comments welcome.

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

goodnight, here is a patch for some of the warnings.  comments welcome.

We need some more .h files, any takers.


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: [Tuxnes-devel] Fwd: present but cannot be compiled (Was: I was asked to report this.)

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

I'l take patches for now, directly or via the list.  If I start getting allot of support from
other developers it would then be better to actually USE cvs.  The way I see it now, it's just an
archive of patches.

--- Jason Dorje Short <js...@an...> wrote:
> To begin with, apply the patch I sent earlier.  This will #include 
> <XLib.h> while checking for the other libraries.
> 
> After that I would rename configure.in as configure.ac, remove 
> acconfig.h, and change the existing AC_DEFINE calls appropriately.  Once 
> autoconf works again, run autoscan to look for missing tests.
> 
> If granted CVS access I'd be willing to work on this.  Of course, I 
> can't guarantee I won't break anything but the end result should be 
> better than the current build system.  Or I can keep sending patches.
> 
> jason
> 

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: [Tuxnes-devel] Fwd: present but cannot be compiled (Was: I was asked to report this.)

[Jason D. S. <js...@an...>]

Mike Mestnik wrote:
> Jason
> 
> Thankyou for your answer.  I'm new at dealing with these sorts of things.  I guess the question
> is, how do we get ./configure to do what we want?  It's not important to me how autoconfig dose
> it's thing.  I just would like to make sure that if I use Xshm.h and for OSXYZ I also need to use
> strings.h or something, that it gets done.

To begin with, apply the patch I sent earlier.  This will #include 
<XLib.h> while checking for the other libraries.

After that I would rename configure.in as configure.ac, remove 
acconfig.h, and change the existing AC_DEFINE calls appropriately.  Once 
autoconf works again, run autoscan to look for missing tests.

If granted CVS access I'd be willing to work on this.  Of course, I 
can't guarantee I won't break anything but the end result should be 
better than the current build system.  Or I can keep sending patches.

jason

[Tuxnes-devel] warnings while compiling

[Jason D. S. <js...@an...>]

I get lots of easily preventable warnings when compiling tuxnes.  Stuff 
like:

emu.c:1185: warning: no previous prototype for `set_homedir'
emu.c:1200: warning: no previous prototype for `prep_conf_dir'

Some of these may cause bugs or slower performance.  (For instance in 
this case, most likely these functions should be static.)

To find these run make as

make CFLAGS="-g -O -Wall -Werror -Wcast-align -Wmissing-prototypes 
-Wmissing-declarations"

-jason

[Tuxnes-devel] Starting development.

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

I have just completed my first commits into the CVS server and they are visible.  Go forthe and
have at it.

If you have any bugs/patches or any thing else now is the time to bring it up.
I'm trying to decide where tuxnes week points are.
  Yes it's true it dosen't have a gui, once the game is going.
  There is no support for suspending the emulator.
  There may be Mappers that NEED or SHOULD be added.
  Lacks config files, a good tuxnes.sh can fix that I think.
  I always use -f, can/should this be made the default?

  Also the SDL renderer is not working, for me at least.  I guess I have been the only person with
an x86 to test that, and I hope every thing works for ppc(apple/mac) ppl.
  With all that could be done I think X11 full screen support can wait, as there are work arounds.

This all started by me patching 0.75.  As the new code probably will not be released for a while. 
Some ppl may wish to use CVS0.75 as most will just download from the SFDL page.  What all should
be backported to 0.75?  From what I see there is the new Sound config support and the no zlib fix.
 Are there any patches ppl have made that they use for 0.75?  I'd like to put these in if they are
?well? tested.

What I'd like to know is what kind of user base tuxnes has and what kind of successes these users
have.  What I think needs to be done is to encourage users to post to this list with there
comments.  This can be done by having the web page attract attention to this issue.  One thing
that would really help is if the Bugs and RFE pages where used by more ppl.  Consider this message
the start of this effort :)

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: [Tuxnes-devel] Fwd: present but cannot be compiled (Was: I was asked to report this.)

[Keegan Q. <ic...@wa...>]

On Thu, Dec 04, 2003 at 01:32:32AM -0500, Jason Dorje Short wrote:
> Looking at configure.in, I see lots of changes that could/should be made=
=20
> to take advantage of more modern autoconfs.  Doing this generally makes=
=20
> the tests more complete and the amount of autoconf code smaller.  Is=20
> there any interest in this?

Yes, please!

 - Keegan

Re: [Tuxnes-devel] Fwd: present but cannot be compiled (Was: I was asked to report this.)

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

Jason

Thankyou for your answer.  I'm new at dealing with these sorts of things.  I guess the question
is, how do we get ./configure to do what we want?  It's not important to me how autoconfig dose
it's thing.  I just would like to make sure that if I use Xshm.h and for OSXYZ I also need to use
strings.h or something, that it gets done.

--- Jason Dorje Short <js...@an...> wrote:
> Mike Mestnik wrote:
> > I hope some one can make sense of this, I'm not an autowhatsit type person.  I know different
> > headers need other headers but I thought ./configure was supposed to figure all that ought. 
> Any
> > way it's not high on the list but I think it should be an easy fix.
> 
> Recent versions of autoconf try to compile the header as well as simply 
> looking at it.  Xshm.h doesn't compile so it fails this test. 
> Presumably this happens because other headers are needed to be included 
> as well.  This is probably a bug on the part of the authors of the 
> headers, but what can you do...
> 
> In this particular case it seems to be <X11/Xlib.h> that is missing. 
> The attached path will probably work.
> 
> Looking at configure.in, I see lots of changes that could/should be made 
> to take advantage of more modern autoconfs.  Doing this generally makes 
> the tests more complete and the amount of autoconf code smaller.  Is 
> there any interest in this?
> 
> I should say that I'm no expert on autoconf.  But I have used it a fair 
> amount with Freeciv (http://freeciv.org/) and GGZ (http://ggz.sf.net/).
> 
> jason
> 
> > ? autom4te.cache
> ? depcomp
> ? stamp-h1
> Index: configure.in
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/configure.in,v
> retrieving revision 1.53
> diff -u -r1.53 configure.in
> --- configure.in	15 May 2002 15:42:52 -0000	1.53
> +++ configure.in	4 Dec 2003 06:31:36 -0000
> @@ -90,9 +90,10 @@
>  dnl --------------------------------------------------------------------
>  if test x"$no_x" != xyes
>  then
> -  AC_CHECK_HEADERS(X11/xpm.h X11/vroot.h \
> +  AC_CHECK_HEADERS(X11/Xlib.h X11/xpm.h X11/vroot.h \
>                     sys/ipc.h sys/shm.h X11/extensions/XShm.h \
> -                   X11/extensions/Xext.h)
> +                   X11/extensions/Xext.h, [], [],
> +		   [#include <X11/Xlib.h>])
>  fi
>  
>  dnl --------------------------------------------------------------------
> 

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/