shmupmametgm on Linux

Thread in 'Research & Development' started by DrPete, 25 Mar 2011.

  1. If you can tell exactly what the full path of SDL.h is, it should be easy to solve. Maybe the framework is structured differently (i.e. there is no SDL folder with the headers inside).
     
  2. I just wanted to say thank you sooooo much for providing this. TAP feels so amazingly awesome now.
     
  3. Okay, that problem's solved. Located the file directly, added its containing folder's path and changed the include directives from SDL/SDL.h to just SDL.h and they were finally found.

    However now I'm getting strange errors in the form of "error: unknown register name '%cc' in asm".
    No clue what's happening, and I've really no time to debug it further... If no one knows what's up with this then I just hope someone picks up the glove from this point on OS X.

    I also want TAP to feel amazingly awesome.. ):
    Got really hooked on T.A Death recently even though I usually top out around level 100...
     
  4. That clobber is unnecessary on asm statements with gcc. Try replacing these files.
     

    Attached Files:

  5. Alright, making progress. Your patch eliminated those errors.

    I also uncommented a special line in the makefile and SDL started working without adding the include path I added before to the makefile.

    I had a few more new problems that I was able to overcome, but I reached another impasse: errors thrown from osd_opengl.h expected ')' and from redefined class members, e.g:
    error: class member cannot be redeclared
    OSD_GL(void,glDisableClientState,(GLenum array))
     
  6. Which one? I think the best course of action here is to make a symlink to the Headers folder, like this:
    ln -s /Library/Frameworks/SDL.framework/Headers /Library/Frameworks/SDL.framework/Headers/SDL
    And restore every include to the proper #include<SDL/SDL.h> and similar, because maybe we are fiddling too much with the includes and that stuff is sensitive. And that will make sure SDL will work on any future project you want to compile.
     
  7. Good call. The line I was talking about has 'MACOSX_USE_LIBSDL = 1' (the line number probably wouldn't be the same for both of us).
    I commented it back and fiddled with the includes until it was working (apparently it doesn't like SDL2, but works with SDL for some reason. My guess is because of some macro doodad somewhere it's getting redirected differently)

    Alright, so far I've added these to the include paths:

    -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 \
    -I/Library/Frameworks/SDL.framework/Versions/A/Headers -framework SDL \
    -I/opt/local/include/ \

    Now no more SDL and OpenGL errors. First one takes care of a tr1 include that wasn't working, second for SDL, and 3rd for something that uses X11.

    now I got this error:
    src/osd/sdl/debugosx.m:1796:25: error: cannot initialize a variable of type
    'MAMEDisassemblyViewer *' with an rvalue of type 'MAMEErrorLogViewer *'


    But it looks like it's from a debug file and I don't know if we actually need it. Thoughts?

    Just wanted to say thanks again so much for helping me through this. It would be cool to get TAP working well on OSX. :)
     
  8. You definitely don't need that, I don't even know why does it want to do that by default. You can add NO_DEBUGGER = 1 after USE_DISPATCH_GL = 1 in sdl.mak inside that folder.
     
  9. Alright, worked. Next up I had some errors about pointer to unsigned int conversion, looked up a solution for it. Apparently pointer types to 32 bit type conversions throw errors, so I casted to size_t and then to unsigned int.

    Then at the end there the linker whined about SDL not being found again. I uncommented the line I mentioned before and it worked (Honestly I can't tell at this point what's happening with it but whatever)

    Aaaand.... It finally compiled fully. :)

    But... now that I'm running TAP it's all weird and slow, and the sound is seriously messed up. What the hell?
    Talk about an anti climax.. Any idea what could be causing it?

    Warning after executing from command line:
    mametgm64[73172:780355] 21:29:32.532 WARNING: 140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h.

    Average speed: 79.78% (7 seconds)
     
    Last edited: 10 Oct 2015
  10. Well it may be that shmupmametgm needs more CPU than the other one, but that probably isn't it, there are a lot of things that may be causing it.
    For now I can suggest looking up tweaks to improve performance in MAME, I don't know if this would fix the sound though. http://wiki.mamedev.org/index.php/FAQ:Performance
    Or you can try to tweak the compilation process a little and see if you manage to get a different result.
     
  11. The os x links for shmupmame seem to be dead. Does anyone have a mirror or back up?
     
  12. Never mind, I can just play it on windows, it just means that I can't play tgm at work...

    The bigger issue is the weird keyboard short circuit, If I'm holding down then left, my piece will stop moving down then go left. However, the opposite is not true. While holding left, pressing down does nothing, as if the key were not pressed.
     
  13. I'm looking for this too, if anyone has it handy.
     

Share This Page