Messages

1

Scripting / Re: How to keep second monitor visible?

« on: March 12, 2017, 02:18:52 PM »

BTW, thanks for the suggestion on controlling it thru MAME itself.   Right now, I'm happy with my "fix" to Attract Mode to keep the monitor from clearing itself, so I don't think I need to go the MAME layout route.  I'd like to get a proper fix into Attract Mode though to make it easy for anyone to do.  I'm running under Windows though, so I've taken a detour to try and get Attract Mode compiling under Visual Studio so I can develop with an actual debugger.

2

Scripting / Re: How to keep second monitor visible?

« on: March 12, 2017, 02:15:08 PM »

I posted the fix for Multimon on another thread - fe_vm.cpp was missing a definition for PresentableParent.  Here's the fix again:

   fe.Bind(_SC("PresentableParent"),
      Class<FePresentableParent, NoConstructor>()
      .Overload<FeImage * (FePresentableParent::*)(const char *, int, int, int, int)>(_SC("add_image"), &FePresentableParent::add_image)
      .Overload<FeImage * (FePresentableParent::*)(const char *, int, int)>(_SC("add_image"), &FePresentableParent::add_image)
      .Overload<FeImage * (FePresentableParent::*)(const char *)>(_SC("add_image"), &FePresentableParent::add_image)
      .Overload<FeImage * (FePresentableParent::*)(const char *, int, int, int, int)>(_SC("add_artwork"), &FePresentableParent::add_artwork)
      .Overload<FeImage * (FePresentableParent::*)(const char *, int, int)>(_SC("add_artwork"), &FePresentableParent::add_artwork)
      .Overload<FeImage * (FePresentableParent::*)(const char *)>(_SC("add_artwork"), &FePresentableParent::add_artwork)
      .Func(_SC("add_clone"), &FePresentableParent::add_clone)
      .Func(_SC("add_text"), &FePresentableParent::add_text)
      .Func(_SC("add_listbox"), &FePresentableParent::add_listbox)
      .Func(_SC("add_surface"), &FePresentableParent::add_surface)
   );

   fe.Bind(_SC("Monitor"),
      DerivedClass <FeMonitor, FePresentableParent, NoConstructor>()
      .Prop(_SC("num"), &FeMonitor::get_num)
      .Prop(_SC("width"), &FeMonitor::get_width)
      .Prop(_SC("height"), &FeMonitor::get_height)
   );

3

Scripting / Re: How to keep second monitor visible?

« on: March 12, 2017, 10:28:16 AM »

OK, so looks like Attract Mode doesn't quite support this out-of-the-box yet.  I can see a couple of ways to make it work for my use case, but I don't know what the right general solution is.

Option 1:  Don't block.  In fe_settings.cpp, where it calls run_program(), I could pass block = false.  This keeps Attract Mode from blocking on emulator completion, which means that it's running the full logic loop (including window redraws) while the emulator is running.  This keeps the marquee visible, which is great, but I'm not sure it's a good side-effect to have Attract Mode running.  If nothing else, it's probably bad that you get the FromGame transition callback before you've actually come back from the game.  On the other hand, I can see where it would be powerful to have an in-between answer here where you don't block, but you also don't get the FromGame transition until the emulator process actually ends.  You could use the running logic loop to drive animations, sound, blinking LEDs, or whatever you want.  This option could get a bit tricky though, since the code isn't currently set up to keep track of the spawned process outside of the run_program() function.  I'm also not entirely sure how to keep the exit hotkey working in this situation.  Ideally, this would also be a per-emulator setting, since there are probably some use cases where you *don't* want both running at the same time.

Option 2:  Don't clear.  In fe_window.cpp, in the wait_callback(), I could remove the win->clear() call.  This keeps the windows "frozen" on the last thing they displayed before launching the emulator.  This also keeps the marquee visible while still keeping Attract Mode in the blocked state.  This is the one I'm currently going with, because it's less intrusive and doesn't have any real side effects.  Ideally, this option would get exposed either to the .nut files or as a per-emulator setting as well.  I really like the idea of making Option #1 work is a more pretty fashion though.

4

Scripting / How to keep second monitor visible?

« on: March 11, 2017, 03:26:24 PM »

I've got an arcade cab that has one monitor for the playfield, and one that's dedicated for a marquee.  Using MultiMon.nut, I can get the marquee to show up on the second monitor.  However, as soon as I launch MAME, the marquee disappears.  I've got MAME configured to only use one monitor.  What's causing AttractMode to clear the second monitor when launching an emulator, and how do I stop it?

Thanks!

5

General / Re: Windows 10 multiple monitor marquee

« on: March 05, 2017, 01:01:37 PM »

OK, tracked down the bug, I think.  I have no idea why this would be Win10-specific.  The problem is that FeMonitor derives from FePresentableParent, which is currently being defined in Squirrel.  This causes type lookups to go a bit, uh, squirrely.  (heh)

The fix appears to be changing fe_vm.cpp to look something like this:

   fe.Bind(_SC("PresentableParent"),
      Class<FePresentableParent, NoConstructor>()
      .Overload<FeImage * (FePresentableParent::*)(const char *, int, int, int, int)>(_SC("add_image"), &FePresentableParent::add_image)
      .Overload<FeImage * (FePresentableParent::*)(const char *, int, int)>(_SC("add_image"), &FePresentableParent::add_image)
      .Overload<FeImage * (FePresentableParent::*)(const char *)>(_SC("add_image"), &FePresentableParent::add_image)
      .Overload<FeImage * (FePresentableParent::*)(const char *, int, int, int, int)>(_SC("add_artwork"), &FePresentableParent::add_artwork)
      .Overload<FeImage * (FePresentableParent::*)(const char *, int, int)>(_SC("add_artwork"), &FePresentableParent::add_artwork)
      .Overload<FeImage * (FePresentableParent::*)(const char *)>(_SC("add_artwork"), &FePresentableParent::add_artwork)
      .Func(_SC("add_clone"), &FePresentableParent::add_clone)
      .Func(_SC("add_text"), &FePresentableParent::add_text)
      .Func(_SC("add_listbox"), &FePresentableParent::add_listbox)
      .Func(_SC("add_surface"), &FePresentableParent::add_surface)
   );

   fe.Bind( _SC("Monitor"),
      DerivedClass <FeMonitor, FePresentableParent, NoConstructor>()
      .Prop( _SC("num"), &FeMonitor::get_num )
      .Prop( _SC("width"), &FeMonitor::get_width )
      .Prop( _SC("height"), &FeMonitor::get_height )
   );

6

General / Re: Windows 10 multiple monitor marquee

« on: March 04, 2017, 09:27:00 AM »

FWIW, I'm still seeing this on Windows 10 with Attract Mode 2.2.1.  In poking at it a bit more, I get a bit more information:

CALLSTACK
*FUNCTION [onTransition()] D:\msys64\home\Mike\attract\plugins/MultiMon.nut line [82]

LOCALS
[my_config] TABLE
[tag] "mon2"
[mon] INSTANCE
1
[transition_time] 0
[var] 2
[ttype] 0
[this] INSTANCE
Script Error in transition function: onTransition - wrong type (unknown expected, got N5Sqrat5ClassI9FeMonitorNS_13NoConstructorEEE)

The specific line it's failing on in Squirrel is this one:
        C* ptr = ClassType<C>::GetInstance(vm, 1);

I have no idea why this would be a Win10-specific error, can anyone confirm that Multimon.nut is working correctly on other OSs?

The only thing that looks uniquely different about the FEMonitor array is that I think it's the only one where instances are getting created solely from the C++ side.  The other arrays I've been looking at (FEShader, FEImage) has instances that have been added from .nut files.  If I had to guess, I would guess maybe something going wrong with name mangling and registration?  I haven't found a way to dump everything that Squirrel knows about yet.