theprojecter / snes9x-rr Goto Github PK

Allow for multiple macro setups for P1

./configure

reports:
./configure: line7219: syntax error near imexpected token `('

Tompa has reported me:
- the sound quality is terrible
- when he loads a save state, the screen goes like this
http://i55.photobucket.com/albums/g124/Tomtelala/SuperStarWars-ReturnoftheJediUV
1000.png

These reports are issues on 1.43, but I've heard that there are some issues
on 1.51 as well. I haven't seen the details yet, though.

Intentional, but should be fixed later.

If we have ported over Ram Search, why not Ram Watch?  GENS Ram watch is
the better dialog of the current RAM watching dialogs.

Steps to reproduce the problem:
1. Ensure that Windows has an uptime between 24.9 and 49.7 days. 
2. Press '\' or the assigned key.  

While expected to advance one frame, it will not do so.  This is caused by the 
function timeGetTime() returning a value >0x80000000, and lastTime being zero, 
causing the emulator to believe that less than 20 milliseconds have passed.  To 
reproduce, run the emulator on a system that is running for 24.9 days. 

Occurs using SVN revision 193. It was introduced in SVN revision 2. 

To fix, open wsnes9x.cpp, and head to HotkeyFrameAdvance.  Remove the cast, or 
if it is still necessary, change the cast from "int" to "unsigned int"

What steps will reproduce the problem?
1. Option Setting Execution cart NG
2. No't Option Setting Movie Recoding Select Emulator reset Execution cart NG
3. Snes9x14.cfg delete after Snes9x Execution Open cart Execution OK

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
Snes9x-rr 1.43 and 1.51 WindowsXPSP3(32bit)

Please provide any additional information below.
Clock Tower(J) Clock Tower(J)[b1] Clock Tower(J)[b1+C] all 
No't Movie Recoding

What steps will reproduce the problem?
1. Change Default Setting for Frame skip from Automatic to Fixed.
2. Exit settings and windows will report an error and close the application.
3. Reopening the application results in an immediate error until you delete the 
conf file.

I expected it not to crash. It crashed.


snes9x-1.52-rr-r185.zip
2600.xpsp_sp3_gdr.101209-1647


Please provide any additional information below.

snes9x-1.51-rerecording-svn147 works fine.
snes9x-1.52-win32.fix3 works fine.

I'm used to using VBA-rr, and being unable to rewind and unable to save my 
progress to an arbitrarily named file (Such as "Shadowrun (U) - Out of 
Morgue.sav") are making it extremely hard for me to redo anything with 
precision. I understand that the rewind thing isn't implemented because 
SNES9x's savestating is too slow to do it once a second without lag, but I was 
genuinely surprised that you can't "Save to File" like you can in pretty much 
any emulator except ZSNES and SNES9x. I understand this is probably just 
because SNES9x doesn't have it, but this is sort of hard for me to go without.

I understand that the save files are named [Game name].[Three digit slot 
number], but any random extension, such as .sav or .9xs will work.

Originally posted by [email protected]

It would be very helpful if there were a command line argument which caused
the specified smv to be autoplayed on startup. This is trivial to
implement. It requires about 10 lines of code to be added. The sections
that need to be edited are: S9xParseArgs, as well as platform-dependent
files like unix.cpp.

The lack of this feature is preventing me from making a tool which
automatically plays an smv when I click a link in my web browser, which
would be very nifty.

Dromiceius's request:

I recommend adding more keys for the cheat finder.

In the listview control:
ctrl+c = copy address to clipboard (so that it can be pasted into one's
notes, or the
"enter a value" edit control.)

In the emulator proper:
Keys to automatically select and search for each of the 6 comparison types.
Having
already simulated these hotkeys using an external app, I can attest that it
makes
address hunting ridiculously easy.

Will there ever be one based off of 1.53? Why haven't there ever been any based 
off of this? 

I guess we can port it from DeSmuME.

Ability to open .7z and other archive files.  If more than one valid rom in
the archive a dialog should open with a list of ROMs.

I think we should port over the GENS .7z system as it is the emulator that
has this best implemented.

For reference, FCEUX, GENS, Nestopia have this feature.

Once the lag counter is implemented, the auto-fire patterns should take it
into account.  This way, a user can rapid fire during laggy segments, or in
30 fps games.

What steps will reproduce the problem?
1. Load any game
2. Select Movie Record from the File menu
3. Choose to record from reset
4. Click OK

What is the expected output? What do you see instead?
The emulator should reset the game and start a re-recording movie, but instead 
an error occurs that says "The movie file was not found or could not be opened."

What version of the product are you using? On what operating system?
Snes9x-rr 1.52 svn185 on Windows XP SP3 (32bit)

Please provide any additional information below.
This happens regardless of the other settings I choose in the Movie Record 
dialog box and regardless of what games I try it on (I've tried many 
combinations of settings and games and always get this error).

It occurs randomly, so I cannot say how to reproduce it.

Sometimes it crashes at the beginning of S9xReportButton, sometimes it
crashes at S9xMixSamples to syncSoundBuffer, and sometimes it crashes when
closing the program (when writing snes9x.cfg?).

I guess there is a buffer overflow issue and it destroys those buffers
illegally.

What steps will reproduce the problem?
1. Load ROM
2. Load movie
3. Try to record AVI

What is the expected output? What do you see instead?
Snes9X crashes

What version of the product are you using? On what operating system?
1.51 on Windows 8 64-bit

Please provide any additional information below.

After recording a huge 5GB+ file (the first 5 hours of a playthrough of Live a 
Live), the next time I started to record, it produced a 0 byte AVI and would 
crash the next time I would record

a -lua command.

Requested by [email protected]

 Reported by [email protected], Apr 09, 2009

Snes9x probably still has some desync issues, even though it's been getting
better. I think what we should do is make sure should-be-identical
savestates are really identical (with the possible exception of parts of
the savestate that don't affect emulation and change separately from it),
in a methodical way. I checked in a way to verify that savestates are
identical and get a summary of which parts were different, which can be
used for this. Here's an example Lua script for checking desyncs:

    snes9x.frameadvance()

    state = savestate.create()
    state2 = savestate.create()

    while true do
        savestate.save(state)
        snes9x.frameadvance()
        savestate.save(state2) -- compare from here...

        savestate.load(state)
        snes9x.frameadvance()
        savestate.verify(state2) -- ...with here

        snes9x.frameadvance()
    end

Currently, when I run that script, I get some scary listings like:

&CPU::Cycles: byte 3(0x3): 28(0x1C) != 10(0xA)
&CPU::PC: byte 3(0x3): 200(0xC8) != 195(0xC3)
&CPU::PCAtOpcodeStart: byte 3(0x3): 197(0xC5) != 192(0xC0)
&CPU::WaitAddress: byte 3(0x3): 197(0xC5) != 192(0xC0)
&Registers::X.W: byte 0(0x0): 0(0x0) != 33(0x21)
&Registers::PC: byte 1(0x1): 136(0x88) != 131(0x83)
Memory.RAM: byte 72759(0x11C37): 0(0x0) != 8(0x8)
Memory.RAM: byte 72763(0x11C3B): 8(0x8) != 0(0x0)
Memory.FillRAM: byte 16923(0x421B): 0(0x0) != 1(0x1)
&IPPU::Joypads: byte 6(0x6): 0(0x0) != 1(0x1)
&GFX::LastScreen: byte 117882(0x1CC7A): 203(0xCB) != 132(0x84)
&GFX::LastScreen: byte 117883(0x1CC7B): 186(0xBA) != 65(0x41)
&GFX::LastScreen: byte 117884(0x1CC7C): 156(0x9C) != 132(0x84)
&GFX::LastScreen: byte 117885(0x1CC7D): 255(0xFF) != 65(0x41)
&GFX::LastScreen: byte 117886(0x1CC7E): 203(0xCB) != 132(0x84)
&GFX::LastScreen: byte 117887(0x1CC7F): 186(0xBA) != 65(0x41)
&GFX::LastScreen: byte 117890(0x1CC82): 203(0xCB) != 4(0x4)
&GFX::LastScreen: byte 117891(0x1CC83): 186(0xBA) != 41(0x29)
&GFX::LastScreen: byte 117892(0x1CC84): 156(0x9C) != 4(0x4)
&GFX::LastScreen: byte 117893(0x1CC85): 255(0xFF) != 41(0x29)

But sometimes I get lucky and there are barely any entries (especially if I
run it at the very start of emulation), like this:

&IPPU::Joypads: byte 6(0x6): 0(0x0) != 1(0x1)

I'm guessing that means (in this case) that the IPPU.Joypads field is the
culprit and first thing to change, and if we can make it stop showing up as
a mismatch then maybe all or most of those other mismatches will go away
too. (The left-hand side of the != is the "new" value, by the way. Also,
note that there's no need to load a movie to do any of this testing. Also
also, remember that it only works in Debug configuration, the verify
function is disabled in Release.)

Later, once the above test script works for all the games we try it on, we
should make sure that more complicated variations of it work (like
emulating 10 frames instead of just 1, or doing "out-of-order" loads, with
a movie recording, with a movie playing, separate runs of the same movie,
etc.), and it's also very important to make sure that savestates saved on
frame 0 after loading the ROM are identical to each other. (If they aren't,
that simply means the mismatching data is uninitialized and we have to set
it to 0 or something in the appropriate startup function.) This is
basically the process I went through on Gens savestates (especially
SegaCD), and those have become pretty rock-solid as far as I can tell, so
it seems to work well. Of course Snes9x 1.51 probably has even more
problems to track down but I think that should come after we're sure about
1.43.

Delete comment
Comment 1 by gochaism, Apr 09, 2009

Wow, your contribution looks so interesting. I'll read what you wrote when
I have
enough time (Actually, I'm recently busy).

Delete comment
Comment 2 by [email protected], Apr 10, 2009

The joypad issue was a false alarm caused by reloading the Lua script with
keys that
I also use for the joypad. I should've been more careful.

However, this mismatch could be a real problem (seen in Super Star Wars):

&APURegisters::PC: byte 1(0x1): 54(0x36) != 61(0x3D)

Also, I notice "Cycles" is in the SnapAPU struct twice now for some reason.

Delete comment
Comment 3 by [email protected], Apr 12, 2009

I found a bunch of desync problems and hopefully fixed them in revision 72.
Now I
don't see savestate mismatches happening anymore in most games (at least this
includes Super Star Wars, Yoshi's Island, Kirby 3, Kirby Superstar, Super
Ghouls 'N
Ghosts, and Seiken Densetsu 3). However, there are still issues with Mega
Man X2/X3
and Super Mario RPG and probably some more obscure games which I haven't
tried to fix
yet.

(The main problem had to do with the common practice for saving important
internal
things in Snes9x which was to "pack" and "unpack" them into/from certain
integer
variables as part of the saving and loading process. That was quite an
error-prone
way of doing it, in fact in all 3 separate cases where I saw that being
done (ICPU,
IAPU, and SA1) there was some kind of bug that prevented it from restoring
to exactly
the same thing that was saved. So I replaced those with the "regular"
non-clever way
of saving structs and it seems fine now.

Well, the other main problem was that at least one instruction/function in
spc700.cpp
accidentally uses the previous value of a should-be-local global variable
in its
calculations. So I had to add some of those global variables to the
savestates too,
even though they shouldn't need to be saved if Snes9x didn't have bugs like
that.
Incidentally, although we can't fix it in 1.43 without breaking movie
compatibility,
it looks like that bug has already been fixed in 1.51.)

Delete comment
Comment 4 by [email protected], Apr 13, 2009

As of revision 73, Mega Man X2/X3, Super Mario RPG, Super Mario Kart, and
PilotWings
seem to be totally clean now too. The only remaining problem game I know of
is Star
Fox (probably some bug in the SuperFX saving functions, which are written
in assembly).

RAM watch settings (ex. windows position) are not saved at this moment. It
should be improved.

What steps will reproduce the problem?
1. Load
http://code.google.com/p/gocha-tas/source/browse/trunk/Projects/SNESGanbareGoemo
n3/SNESGanbareGoemon3.wch?spec=svn45&r=45
2. only 97 variables displayed (it must be 100)

At least, current one doesn't have size information (8bit, 16bit, 32bit).

Posted by Nitsuja in old 143 project:

Or more accurately, the ASM and C cores have slightly different emulation
timings, even though the former is supposed to behave identically to the
latter. If we can solve the mystery of why they are different, we should
change the C core to behave like the ASM core does now.

This does not apply to the 1.51 branch at all.

To reproduce: Try playing the SMV file available at
http://tasvideos.org/2209S.html in Debug configuration, and notice that the
player quickly dies, whereas if you play it in Release configuration that
does not happen.

 Reported by gochaism, Feb 18, 2009

Lua joypad.set() doesn't affect Input Display.
Probably we'll need to modify controls.cpp more.

Delete comment
Comment 1 by gochaism, Feb 19, 2009

Hmm, joypad APIs seem to have more problems. I need to look on it again :/

Summary: Lua joypad API works buggy
Labels: -Priority-Medium Priority-High
Delete comment
Comment 2 by [email protected], Apr 28, 2009

Is it okay to change joypad.get() and joypad.set() to work more like in
Gens? (true
means pressed, false means unpressed, nil means normal.) Some things seem
really
inconvenient or maybe even impossible to do without that. Also, if I try using
joypad.set in a registerbefore callback, it fails to do anything.

I think this applies to 1.43 as well, but I haven't checked that yet.

What steps will reproduce the problem?
1. Any game with lots of movement like a shoot em up (SuperNova
2. Play at 50% Speed (But also happens at full speed)
3. Use a 360 pad. (Even setting up the buttons in Input gui can require a few 
presses.

What is the expected output? What do you see instead?

Fluid movement expected, but emu will periodicaly stop acknowledging input 
until button depressed and pressed again.

What version of the product are you using? On what operating system?

Windows7 64bit, Snes9x 1.43v10 , 1.51 svn185 tested. 

Please provide any additional information below.
Only affecting this emu so its not broken pad.
I dont have any other controllers to test with so dont know if problem is 
limited to just this pad.

Summary says all. Probably I forgot to write WM_KEYDOWN things in wsnes9x.cpp.

What steps will reproduce the problem?
1. Have any game running in fullscreen view
2. While the game is running, press Alt+F4 to close
3. Try to relaunch snes9x

What is the expected output? What do you see instead?
  The expected output is that it should close as it does but it wont 
  restart again, it is just crashing.

What version of the product are you using? On what operating system?
  My version is "1.51 v6" and I am running on Windows XP.

Please provide any additional information below.

 The only sulotion to fix this after this has happend is to delete the file
 "snes9x.cfg", but that resets all the settings. I am a litle lazy and
 just presses the Alt+F4 to close when I get tierd of playing.

What steps will reproduce the problem?
1. Begin encoding a video (I was using H.264 lossless)
2. Pause the emulator using the Pause Break button
3. Press F12 (I had pressed it multiple times)
4. Unpause

What is the expected output? What do you see instead?
I was expecting a screenshot dump, I instead got a lovely error window

What version of the product are you using? On what operating system?
Snes9x rerecording 1.43 v17 svn103.

Windows 7 RC (I need to buy the final product yet)

Please provide any additional information below.

I was encoding a Super Mario RPG run and got half way through it when I 
found a frame I liked. I have never liked SNES emulation, this just adds 
fodder to the fire.

Necessary in order to create a rewind script that won't slow everything
down to a crawl. 
It's nice that you can actually lower the compression but the emulator
still lags a lot when saving, nowadays HD space is rarely a problem and the
SNES ram is fairly small anyway, it really makes no sense, I think
uncompressed saves should be default.

Also everytime you save using LUA there's an annoying "SAVED SNLUAXXX"
screen message that can't be turned off, which is redundant since you could
just write an extra line of code if you really wanted confirmation.

Reported from Mister. Steps to reproduce the problem are:
1. Boot up the emulator (1.43 svn r98, whose savestate members are
different from the official one. The binary is available in the Downloads page)
2. Load a ROM and add a watch (target address can be randomly chosen)
3. Load a savestate which is made by old version (1.43 svn r64, 1.43 v9,
etc., all they should be same)
4. Congratulations, it crashes now \(^o^)/
Note: it didn't crash when I tested on debug build.

This crash happens because UnfreezeStructFromCopy destroys
watches[0].address. It's all I know at present and I'm really not sure how
we can fix the problem.

At present, there can be some emulations between emu.registerafter (and
gui.register) and emu.registerbefore. That causes 1 frame delay to RAM
display for certain RAM values.

What steps will reproduce the problem?
1. Load rom "Kick Off 3 - European Challenge (E) [!].smc"
2. Start an actual soccer match


What is the expected output? What do you see instead?
Graphics are messed up. The ball's sprite is corrupted, random characters are 
displayed in bg#3, and sometimes corrupted stuff is displayed in bg#1.


What version of the product are you using? On what operating system?
Snes9x rr 1.51v6, on Windows XP.


Please provide any additional information below.
Issue occurs both in DDraw and D3D mode. Game renders correctly under v1.43. 
Screenshot included.

http://dehacked.2y.net/microstorage.php/info/49343254/SuperPuyoPuyo2_Remix_02.sm
v
This movie desyncs at the second battle. The input of 4P is recorded, but
seems to not send to the SNES.

SPU_core works synchronously and writes its state to sound registers.
SPU_user can work asynchronously because it doesn't write its state to any
RAMs or registers. So it is used for platform-dependent mix.

If we could implement such a method in snes9x, we can remove way too
complex sound options, like Volume Envelope Height Reading, Fake Mute, and
Sync Sound. That is, we can get consistent sync but still use flexible
sound mix.

Well this is not a recording stuff I know
but how about some layer effect options like Photoshop's
Outerglow, drop shadow etc, those would look awesome

Problem #1:
-- output: -1
-- expected output: 4294967295
memory.writelong(0x7E0000, -1)
print(memory.readlongunsigned(0x7E0000))


Problem #2:
-- output: a clear, red-outlined rectangle
-- expected output: a white-filled rectangle
gui.register(function()
  gui.drawbox(0,0,50,50, 0xFFFFFFFF)
end)


The first problem is a bug in readlongunsigned in practically all re-recording 
emulators. I'm guessing it's necessary to use lua_pushnumber instead of 
lua_pushinteger in that function.

The second problem seems more Snes9x-specific, and it's a somewhat recent bug 
too. 0xFFFFFFFF should become 'white' but it gets interpreted weirdly. I'm 
guessing this is because the lua51.dll included with Snes9x was compiled 
without the necessary fixes that have been made in luaconf.h in the branch 
(especially making sure that lua_number2int uses a double/long union instead of 
inline assembler code "fld" and "fistp"). If that's some official/standard 
lua51.dll we're using, well, it has that bug in it so we have to either compile 
our own non-standard one instead or go back to compiling against Lua 
statically... and maybe this bug affects all other re-recording emulators that 
use a Lua dll, if there are any others.

SNES9x uses a custom license for distribution, and many of the contributive 
devs have NOT consented to a license change.

Once the lag counter is implemented, there should be a menu toggle /
checkbox that the user can select.  If selected frame advance will skip
over lag frames (via the lag counter).  This is especially helpful in 20/30
fps games.

For reference this is implemented in FCEUX and GENS10

What steps will reproduce the problem?
Playing any game, I encountered it in Mario All Stars.

What is the expected output? What do you see instead?
Sound problems. It's like some short "poc, pocs".

What version of the product are you using? On what operating system?
Snes 1.52, XPSP3

Please provide any additional information below.
It's noticeable more with XAudio2 sound driver.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?
Super Donkey Kong (J) (V1.1) in Snes9x 1.51 r66.
The Background is broken.
But in 1.43 r66 is not.

What version of the product are you using? On what operating system?
Snes9x 1.51 r66

Please provide any additional information below.
A screenshot for you.
Sorry about my English.My English is not good.

Trying to compile and run the latest version (revision 198) on Xubuntu 11.04 
AMD64 leads to all sorts of failures.

First, some changes needed to be made to Makefile.in to compile at all:
--- Makefile.in.orig    2011-06-26 09:56:25.012224478 -0600
+++ Makefile.in 2011-06-26 10:11:30.550840316 -0600
@@ -60,9 +60,9 @@ SOUNDOBJ=spc700.o soundux.o apu.o @I386S
 SOUNDDEFINES=-DSPC700_C

 ifdef ASMCPU
-CPUOBJ=$(CPU)/cpuops.o $(CPU)/cpuexec.o $(CPU)/sa1ops.o
+CPUOBJ=$(CPU)/cpuops.o $(CPU)/cpuexec.o $(CPU)/disasm.o $(CPU)/sa1ops.o
 else
-CPUOBJ=cpuops.o cpuexec.o sa1cpu.o
+CPUOBJ=cpuops.o cpuexec.o disasm.o sa1cpu.o
 endif

 ifdef DREAMCAST
@@ -250,7 +250,7 @@ offsets: offsets.o
 #      cd ../zlib && sh ./configure && make

 snes9x: $(OBJECTS) unix/x11.o $(AIDOOBJS) $(OFFSET)
-       $(CCC) $(INCLUDES) -o $@ $(OBJECTS) $(AIDOOBJS) $(GLIDEOBJS) 
$(OPENGLOBJS) unix/x11.o $(LDLIBS) $(GLIDELIBS) $(OPENGLLIBS) @SYSLIBS@ -lXext 
-lX11 $(EXTRALIBS) -lm -llua
+       $(CCC) $(INCLUDES) -o $@ $(OBJECTS) $(AIDOOBJS) $(GLIDEOBJS) 
$(OPENGLOBJS) unix/x11.o $(LDLIBS) $(GLIDELIBS) $(OPENGLLIBS) @SYSLIBS@ -lXext 
-lX11 $(EXTRALIBS) -lm -llua5.1

 unix/svga_keynames.h: unix/svga_get_keynames.pl
        unix/svga_get_keynames.pl /usr/include/vgakeyboard.h > unix/svga_keynames.h
@@ -267,7 +267,7 @@ ggisnes9x: $(OBJECTS) unix/ggi.o
        $(CCC) $(INCLUDES) -o $@ $(OBJECTS) unix/ggi.o $(LDLIBS) @SYSLIBS@ -lggi $(EXTRALIBS) -lm

 osnes9x: $(OBJECTS) unix/x11.o $(OPENGLOBJS)
-       $(CCC) $(INCLUDES) -o $@ $(OBJECTS) unix/x11.o $(OPENGLOBJS) $(LDLIBS) 
$(OPENGLLIBS) @SYSLIBS@ -lXext -lX11 $(EXTRALIBS) -lm -llua
+       $(CCC) $(INCLUDES) -o $@ $(OBJECTS) unix/x11.o $(OPENGLOBJS) $(LDLIBS) 
$(OPENGLLIBS) @SYSLIBS@ -lXext -lX11 $(EXTRALIBS) -lm -llua5.1

 s9xserver: $(SERVER_OBJECTS)
        $(CCC) $(INCLUDES) -o $@ $(SERVER_OBJECTS)

Now the emulator compiles, although there seems to be no way to activate the 
GTK GUI or debugger, and no way to use OpenGL rendering. Even with the 
following configuration:

$ ./configure --with-opengl --without-assembler --with-debugger --with-netplay 
--with-lua --without-x

the emulator still uses X drawing routines instead of OpenGL.

Once it's running, several error messages are output to the console:
$ ./osnes9x ~/games/snes/Super\ Mario\ World\ \(USA\).zip
Port 1: Pad #1. Port 2: <none>. 
/dev/dsp: No such file or directory
Sound device open failed
Using ROM Super Mario World (USA).sfc in /home/rena/games/snes/Super Mario 
World (USA).zip
No ROM file header found.
Map_LoROMMap
"SUPER MARIOWORLD" [checksum ok] LoROM, 4Mbits, Type: ROM+RAM+BAT, Mode: 20, 
TV: NTSC, S-RAM: 2KB, ROMId: ____ Company: 01 CRC32: B19ED489
Bad address
joystick: No joystick found.
XShmCreateImage failed, switching to XPutImage
Unrecognized command 'Mode7Interpolate'

My USB joystick isn't detected, nor any audio device.

The emulator won't actually run until I press plus to set frameskip to zero. 
With the default setting of auto, it only advances frames when clicking the 
mouse.

Finally, there's some kind of counter on the screen at all times, and things 
are rendered very wrong (Super Mario World has everything in crazy colours, 
backgrounds missing, etc).

The official Snes9x build has none of these issues and works great.

 Reported by [email protected], May 16, 2009

What steps will reproduce the problem?
1. ./configure
2. make
3. Watch the world burn.

What is the expected output? What do you see instead?
Expected output is to watch the scrolling text keep scrolling until it's
done.  It doesn't do that. :)

What version of the product are you using? On what operating system?
Attempted with the official release and the lastest svn

Please provide any additional information below.
There is numerous places where the compile fails because of a loss of
precision, it is simply required to change these from ints to longs

The other issue I ran into while compiling (the one that ultimately made me
give up,) was the Lua scripting engine, the configure.in seems to reference
-llua but I was completely unable to make that stay in my SYSLIBS all the
way to the end for whatever reason (I'm no Automake expert unfortunately) I
did attempt to simply dump all of the required files into the directory,
but it simply did not work.

If you need to get into contact with me, I would prefer if you got me on
the TASVideos forums or w/e :)