• Embedded directly in a UI wrapper program ("front-end") that has complete control over the running of, display of, and input to, the emulated game
  
• The UI menus that control the game can be implemented using whatever visual presentation style a front-end builder wants to implement, not relying on the simple (but effective!) MAME UI
  
• MAME can be embedded in places that it cannot easily be embedded now; I can't imagine every way in which this could be useful but there must be something
  
• A much cleaner mechanism for add-on features, that doesn't require ANY changes to the core MAME code; for example:
  - client/server play mechanisms
  - rewind/ffwd/resume from prior point of games in progress (for best support of this I would like to alter the libmame API to allow the save/load callback for game states to be passed in instead of always being file based; so the library user could, e.g. store game states in memory instead of on disk)
  - AI mechanisms for playing games automatically
  

• It espouses the philosophy of 'POSIX is the portable interface'; systems that don't support POSIX calls (i.e. Windows) have crutches and shims in place in the code to make them look like they do, at least as much as is necessary to support the POSIX calls used. Surely this must rub some MAME developers the wrong way.
  
• It is structured as an OSD layer called 'posix' that implements as much of the OSD interface using POSIX calls as possible, and leaves the remainder up to a different layer to provide. This essentially turns the whole "OSD" concept on its head, saying that instead of an OSD, we should just assume POSIX and make that work. I imagine that the MAME team may not like this way of doing things.
  
• The libmame API specifically bypasses all of the internal input setup logic of MAME. Instead I espouse a philosophy of collecting every possible controller input into one giant structure, and expecting the program using libmame to provide input via this structure. The program must identify which actual controller input is relevant to the game at hand (there are libmame calls for querying this information), and do its own thing in terms of mapping user input, via whatever mechanism it wants to do that, to game input. This throws away a good deal of MAME's built in technology for doing this. I imagine the MAME team must not like this concept since it discards MAME's approach. But I make no apologies I think this is the right way; different programs built on top of MAME may want to handle user input very differently, and MAME takes some options away from them that libmame gives back.
  
• Is there anything obvious that libmame is lacking in terms of access to MAME emulation mechanisms? 'Adjusters' is one that I can think of. Access to memory maps and stuff of emulated games is another (for, e.g. cheat systems). Access to the debugger functionality is a third. I would be happy to incorporate such features and lean on as much existing MAME functionality as possible.
  
• Given that I understood the whole MAME internal input device system just well enough to implement libmame, it is possible - actually, very likely - that there are hidden problems with the way that I have done things, especially in the input setup stuff in libmame_rungame.c. I kind of abuse the MAME input mechanism pretty badly, generating virtual input 'devices' (keyboards, mice, light guns) as needed for each game and then hooking those up in a way that libmame then controls them as needed. Are there pitfalls to this that were not obvious to me - things I don't understand well, like analog joystick dead zones, weird device ports that work in weird ways that I might not be covering properly with libmame's input system, anything else?
  

{
	global: LibMame_*;
	local: *;
};