MAMEWorld Forums - Programming - Re: libmame patch discussion please

> Typically people run one at a time. The ability to switch
> out the 'heart' of the program is not really useful just
> due to the way things are distributed.

One nice thing that you can do if you can run MAME in the way that libmame allows is you can run multiple games simultaneously. This doesn't sound that useful but it is nice to be able to pause games that don't allow save state indefinitely while you run another game, in a way that is completely seamless within the frontend.

Also it's nice to start up a new game even before the old game has shut down, it makes the startup of games faster. One goal I have for my frontend is for it to be *fast* to start games; what I do is that I present a typical list-of-games interface and as the user scrolls through them, if you pause on any game for 1/4 of a second it automatically starts it up. The game doesn't take over the frontend or anything, it's just there playing in a small window (rendered within a virtual arcade cabinet) and if you continue to scroll, then the next time you hover on a game for 1/4 second, *that* game is immediately started even before the old one has been completely shut down. This produces an incredibly quick and seamless game start-up experience. By the time you've finally focused your eyes on the screen and are ready to press the select button to play the game, it's already started up.

> If it were me I would leave the .lib/.dll idea alone
> and concentrate more on the proper abstraction in the
> code.

I think of libmame as a first step. My belief is that the "proper abstraction" is: everything necessary to actually emulate games and produce a stream of textures and audio segments representing the running game, should be the true heart of MAME, and is all that MAME proper should contain. Even the basic MAME command-line frontend, if it were to be supplied integrated with the MAME source, should be a layer around the core engine library, a peer of all other frontends. As it is now the MAME command line interface is intertwined with the engine itself and there is no clean abstraction for other frontends to interface to.

libmame provides that abstraction, and if it were incorporated into MAME, I think the next logical step would be to move *all* front-endish functionality out of the MAME engine and into the frontend layer.

But I highly doubt this is going to happen, because I think that this concept of the MAME engine being useful outside of the MAME command-line frontend is not something that I think has buy-in from the MAME developers.

> I would be semi interested in the thinking behind
> cleaving it into two parts. Maybe I am seeing it wrong?

You are seeing it like I see it, but like I said, this is not the same as seeing it as the MAME team sees it.