shmupmametgm on Linux

I'm wondering if someone could help me compile shmupmametgm on linux. I'm using vanilla MAME 0.137 sources and the source patch at http://mufunyo.net/tetris/mametgm/0137/

attempting to build gives the following:

Code:

O_O 16:04:52 pete@laptop:~/crap/shmupmametgm $ make SUBTARGET=tgm NOWERROR=1
Compiling src/emu/cpu/i386/i386dasm.c...
Assembler messages:
Fatal error: can't create obj/sdl/mametgm/emu/cpu/i386/i386dasm.o: No such file or directory
make: *** [obj/sdl/mametgm/emu/cpu/i386/i386dasm.o] Error 2

i can find no reference online to this issue. if anyone can suggest a solution, I'd be very grateful

failing that if anyone has any suggestions for making non-shmup mametgm run faster, I'd be equally grateful - it claims to run at 100.0% with TAP but the input seems to lag slightly, with autosynchros happening when I'm not intending them and such (though that could be because I'm coming from Texmaster which apparently is more responsive than real TAP or something like that)

i'll attach some snippets from my mame.ini in case they're useful or anyone can spot anything obviously wrong with them

Code:

#
# CORE PERFORMANCE OPTIONS
#
autoframeskip             0
frameskip                 0
seconds_to_run            0
throttle                  1
sleep                     1
speed                     1.0
refreshspeed              0
#
# CORE INPUT OPTIONS
#
coin_lockout              1
ctrlr
mouse                     0
joystick                  1
lightgun                  0
multikeyboard             0
multimouse                0
steadykey                 0
offscreen_reload          0
joystick_map              auto
joystick_deadzone         0.3
joystick_saturation       0.85
natural                   0
uimodekey                 auto
#
# PERFORMANCE OPTIONS
#
multithreading            1
numprocessors             auto
sdlvideofps               0

#
# VIDEO OPTIONS
#
video                     opengl
numscreens                1
window                    1
maximize                  1
keepaspect                1
unevenstretch             0
effect                    none
centerh                   1
centerv                   1
waitvsync                 1
scalemode                 none

once again, my gratitude if anyone has any suggestions. I'd love to see if I can get MAME running a little smoother for the Carnival of Death

 

thanks a lot, that fixed it

unfortunately it's now getting stuck at the linking stage. did you also have a problem like this one?

Code:

^_^ 21:18:16 pete@laptop:~/crap/shmupmametgm $ make SUBTARGET=tgm NOWERROR=1
Linking mametgm...
@g++ -Wl,--warn-common -s obj/sdl/mametgm/version.o obj/sdl/mametgm/mame/tgm.o obj/sdl/mametgm/mame/drivers/zn.o obj/sdl/mametgm/mame/machine/znsec.o obj/sdl/mametgm/mame/drivers/psikyosh.o obj/sdl/mametgm/mame/video/psikyosh.o obj/sdl/mametgm/mame/machine/psx.o obj/sdl/mametgm/mame/video/psx.o obj/sdl/mametgm/mame/audio/taitosnd.o obj/sdl/mametgm/mame/audio/taito_zm.o obj/sdl/mametgm/libosd.a obj/sdl/mametgm/libemu.a obj/sdl/mametgm/libcpu.a obj/sdl/mametgm/libdasm.a obj/sdl/mametgm/libsound.a obj/sdl/mametgm/libutil.a obj/sdl/mametgm/libexpat.a obj/sdl/mametgm/libsoftfloat.a obj/sdl/mametgm/libz.a obj/sdl/mametgm/libocore.a -lm -L/usr/lib -lSDL -lpthread -lX11 -lXinerama -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm -lcairo -lpng14 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lgconf-2 -lglib-2.0 -L/usr/X11/lib -L/usr/X11R6/lib -L/usr/openwin/lib -o mametgm
obj/sdl/mametgm/libemu.a(cpuexec.o): In function `cpuexec_timeslice(running_machine*)':
cpuexec.c:(.text+0x3035): undefined reference to `poll_if_necessary(running_machine*)'
collect2: ld returned 1 exit status
make: *** [mametgm] Error 1

i've had a look at the makefile and source, but my C++/linking knowledge is a bit rusty, so I can't figure anything out

 

Yeah, I never managed to get past the linker error either, so I just went back to the pre-built binary of the previous version.

I suppose that's why there isn't a Linux download for the latest version?

Edit: I also didn't try very hard. Once I get my decent computer back (next week?) I'll take a stab at debugging the linking issue if the problem isn't resolved by then.

 

followup: had another go earlier and worked around the linker error simply by removing all references to poll_if_necessary from cpuexec.c

i have no idea what, if anything, this will have broken but it seems to work from cursory testing

 

Hi there
No, I'm not here to beg for a binary, I actually got shmupmametgm (0.137) to compile on Debian Unstable after some quirks.
I am here to report my findings and hopefully get some advice to fix a problem with the input.
What I did in order to make it compile:

• Copy shmupmametgm over a mame 0.137 source code and compile it with make SUBTARGET=tgm (Obviously)
• GCC throws a hell of a lot of warnings so I removed -Werror from the makefile
• Seems like mame 0.137 needs gconf to compile, so I installed the package libgconf2-dev
• For some reason, GCC doesn't include by default the stddef.h macros used by MAME, so I added #include <stddef.h> at the beginning of src/emu/emu.h
• The folder obj/sdl/mame64/emu/cpu/i386 isn't created by default when compiling and it complains it can't put an object file there, so I created it manually
• The code parsed by m68kmake which is src/emu/cpu/m68000/m68k_in.c was using carry return to make new lines from the DOS era, those need to be removed to work in *nix systems. With the dos2unix tool packaged in most distros I converted the file
• The linker needs functions from pthreads to link the binary, so I added -pthread for the compiler and -lpthread for the linker in the makefile.
  
• The function that forces polling (poll_if_necessary) in osd/windows/input.c was only available in the windows folder, and the linker wasn't able to link the binary. So I made my own implementation on osd/sdl/input.c trying to mimic the behavior of the former, with the addition of adding the calls to it on the same places.

I think that's pretty much it, the games work but I don't know if it was worth it. If someone more experienced than me can actually check if there is a difference in input delay it would be wonderful, I can upload the binary here or to the wiki if needed, although I'm not sure if it will work on any distro.
Now to the problem itself, I was planing to play with the keyboard for now. It seems like if I press right or left, and then up without releasing the other key, it doesn't emulate the 4-way stick behavior and the pieces don't harddrop. I think it did on windows using the binary, I may check that later, but it doesn't work on Linux so it may be a problem with how SDL manages input.
Thank you for your time!

 

Here is the binary in case anyone wants to fiddle with it, it only works on Linux x86_64 (If it does, it may complain you have an outdated library or something)

 

I hope it didn't take you too long solve all the problems during compilation. I meant to write a guide outlining the steps you've listed above for building shmupmametgm on Linux, but it sort of slipped my mind. Since I primarily play on stick, I never experienced the 4-way stick emulation going awry. Did you test if it works properly on the pre-built Windows binary yet? In either case, I've been poking around the MAME source code, I'll give it a more earnest shot tonight.

 

The joystick update function (frame_update_digital_joysticks @ src/emu/inptport.c:2560) correctly, as far as I can tell, sets the joystick state (digital_joystick_state.current) and also sets another variable for the 4-way joystick state (digital_joystick_state.current4way).

The problem though is that the joystick is never really set to 4-way (when inspecting _input_field_config's "way" field, it kept reporting 0 to me instead of the expected 4), so MAME never looks at that variable. A quick and dirty solution is to just remove the check for a 4-way joystick and always use 4-way at src/emu/inptport.c:2860:

Code:

UINT8 mask = (field->way == 4) ? field->state->joystick->current4way : field->state->joystick->current;

to

Code:

UINT8 mask = field->state->joystick->current4way;

Since shmupmametgm is pretty much exclusively for TGM-games, I feel slightly less bad about "fixing" the input problem this way.

 

That worked wonderfully! Here is the binary, I only changed that line. Yes, there are some hardcoded things in mametgm, so it's not really a worry to strip it down just a little.

 

Just backported the framerate thing, at least to Linux for now. It was this commit:
https://github.com/mamedev/mame/commit/b3f944dd946f3e6d5c7ac3639915f9b91ecf55f6

 

Wow, that's a much smarter way to adjust the frame rate compared to how I did it in cpuexec.c.

As for updating MameTGM, it doesn't seem like it would be too difficult of a task to get done. The shmupmame and TGM patches for MAME 0.137 aren't that substantial. While the current MAME codebase looks a lot different than MAME 0.137, most of the differences are naming conventions and the use a few more C++ features.

I don't know how much we'd gain by updating to the latest version of MAME though. Since the frame rate issue can be fixed with the old version of MAME, the only issue I run into currently has to do with dual-head fullscreen with SDL < 2.0. The main advantage I can see right now is that there would be more of an impetus for rigorously testing things like input lag or the 4-way stick stuff.

 

Here is the source code, it should compile out of the box in Linux now. It also contains the 4-way fix and the framerate fix, which are platform independent.

 

Hey, thanks for all your work! (Same goes for all the other contributors).

I'm trying to compile on OS X using 'make SUBTARGET=tgm' as your readme says, but I keep getting errors about missing .mak files (e.g "src/osd/sdl/sdl.mak: No such file or directory"). They're indeed missing.

Any idea what the problem is? I couldn't work it out from the makefile.

Thanks again!

 

You need to copy that over a mame 0.137 source code.
Here: https://github.com/mamedev/mame/releases/download/mame0137/mame0137s.zip

 

Thanks, I'm a derp..

Next up, can't include SDL. I have SDL1.2 + SDL2.0 installed in /Library/Frameworks, but I don't know how to change the include directive so that it finds it. Ideas?

The error is thrown from sdlmisc_macosx.c from '#include <SDL/SDL.h>'.

Tried changing it to a bunch of things but none worked.

I'm afraid the only way could be to build with XCode but I really don't want to do that unless I absolutely have to.

 

If the headers are there, you can add the directory containing the SDL directory in the makefile.
Around line 455 in the makefile, you can add another directory to the CCOMFLAGS variable.
Change

Code:

CCOMFLAGS += \
    -I$(SRC)/$(TARGET) \

To

Code:

CCOMFLAGS += \
    -I/Library/Frameworks/SDL.framework/ \
    -I$(SRC)/$(TARGET) \

Or whatever the path containing the SDL directory is. Try to mimic the other lines, the '\' should be the last character on the line. Make sure you have the headers installed too.

 

Bah. It's still not finding it. I tried installing SDL through a package manager (MacPorts) in hopes of getting it to install somewhere in the include search paths but still no go.

If you're out of ideas at this point I guess I can let this go and wait until someone has the energy and motivation to get this to work on OS X.