MAMEWorld Forums - Programming - libmame patch discussion please

Hello. I am tempted to put this topic in the MAME Chat forum because I feel like topics get much more discussion there, but I'll be good and try to keep this on the relevant board.

As MAME devs will know, I submitted a patch a few days ago to mamedev via the patch submission email for libmame. You can read about libmame at:

http://www.ischo.com/libmame

I would like to get feedback on my patch and the general ideas and implementation thereof. I realize that I cannot expect my patch to be accepted within just a few days of being sent, so please don't take this as a demand for immediate action. I just realize that my patch is almost 100% guaranteed to not be acceptable as it is for a variety of reasons and I want to have a forum for getting the inevitable feedback, and I hope this thread can serve as that.

I believe that the biggest problem with my patch is going to be philosophical: the MAME team probably does not see the point of it, or even if it does see the point of it, may specifically not want to allow the MAME code to be used in this way.

With that in mind, can we talk about the benefits of allowing MAME to be used as a pure emulator, without any of the UI on top of the emulator, via a stable and well documented API? And can we talk about whether or not my API could be better?

Let me start off with re-making some of the points that I made in my patch submission:

Allowing MAME to be compiled as a library with a simple but complete API means that it can be easily used (for both good and bad) in ways that it cannot be easily used now:

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

Now I know that MAME is inteded to just be a 'documentation' of arcade history and so such esoteric features are not/should not be a part of MAME itself. That is exactly why making the MAME engine be nothing more than the low level emulation engine, and having all of these other components be 'add-ons' in separate projects, makes so much sense. In fact I would go so far as to say that MAME itself should be nothing more than libmame, to satisfy the purposes of documenting games via emulation; and the end-user product of being able to play those games and add all of these bells and whistles should be a separate project.

It is in a way kind of counter to the entire purpose of MAME, as it is claimed by the MAME team, to have the UI that exists in MAME currently in there; and the video recording capability, and lots of the other end-user functionality. Of course we could argue that all of these things are essential because they allow for a reasonable development platform - features needed for bug feedback and such - but there certainly is alot of grey area there where MAME features are not clearly just for the benefit of developers.

libmame would allow for the true goal of MAME to be very clearly delineated; everything on the 'inside' of libmame would be solely there for the purpose of documenting games via emulation, and everything on the 'outside' would be end user features (which may also be necessary/useful for developers).

OK, now onto the specific design of my libmame patch:

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?

How does the MAME team feel about the fact that libmame is an 'enabling' technology for MAME license breakers - in that it makes it easier to re-use the MAME emulator in a productized form? I personally feel that you can't stop these people from abusing MAME in this way, and that their job in doing so is already so easy that my additions do not make it materially easier; but MAME devs may disagree. I would love to hear opinions on this.

Finally, would the MAME team be interested in breaking the MAME functionality up in the way that libmame suggests? I.e. moving everything that is emulation onto the inside of libmame and moving/re-implementing everything that is not to a layer or component on the outside? I believe that doing so would make the MAME codebase more amenable to innovation. How do the MAME devs feel about it?

Well even if the libmame patch is not accepted into MAME I intend to maintain it as an external patch so it's going to be out there. It would certainly make my life easier if it were integrated into MAME so that the devs had to make sure not to break it instead of me having to fix it on every MAME release (Aaron Giles is very adept at breaking libmame with his C++-ification efforts!

But that being said, the external API of libmame has not changed even over all of those C++-ification changes in the past 3 or 4 MAME releases, so programs using the libmame API have been completely isolated and protected from these MAME internal changes, which I think proves the value of the libmame approach), but I do not expect or demand that the MAME team shares my viewpoints and will not hold a grudge if they don't want my patch. I just want to have reasonable discussion and to be given an opportunity to make my case. Thank you!