|
Dev question: is ioport_group redundant?
#265418 - 09/30/11 11:53 PM
|
|
|
Hello, this is a question for MAME developers.
Some background: I have an code base that I wrote and have been maintaining for maybe a year and a half now. I call it libmame. It wraps the MAME source code with a stable, well-documented, featureful API that allows any program to run games via the MAME "engine". I use it in a frontend program that I have been developing off and on for a while now with some unique features, which I won't go into detail on right now.
One thing that has been kind of a pain for a while now is the changes to the MAME code subsystems that have been happening - basically, the C++-ification of parts of MAME. I say this is a pain, what I really mean is that it's been a pain for me; I am sure that overall it is a good thing for MAME and that there are benefactors for the changes (MAME driver developers). I mention that it is has been a pain for me mostly to try to evoke sympathy so that MAME devs take enough pity on me to answer my question here and any other questions I end up asking on this topic. With every major MAME release, for the past year or so there have been re-jiggerings of many MAME internals that require me to update my libmame code, and it's not always been obvious how to do this. So far I've done OK though, I always figure it out; but it is a pain (once again, not trying to complain).
Right now the major overhaul of the input API is giving me fits. I only ever understood just enough of the old API to utilize it for my purposes; I never felt like I had a great grasp of its overall architecture or use. Now it's been converted mostly to C++ classes and I am more lost than ever. I feel like in order to adapt libmame to use the new API, I really should understand the input architecture better. So here is my first question in that regards.
There is a class called input_type_entry; two of its constructor parameters are "group" and "player", of types ioport_group and int respectively. The player parameter is described (via the code docs of the member variable it is used for) as "player number (0 is player 1)". But ioport_group is an enumeration which already includes IPG_PLAYER1, IPG_PLAYER2, ..., IPG_PLAYER8. This seems redundant.
Am I misunderstanding something, or is either the player member variable of input_type_entry, or the IPG_PLAYER{1,...,8} enumeration values of ioport_group redundant?
|
|
|
|
Re: Dev question: is ioport_group redundant?
[Re: Bryan Ischo]
#265441 - 10/01/11 12:36 PM
|
|
|
IIRC, ioport_group is mainly used to group the various inputs in the Input (General) configuration menu of the internal UI, and that's why you also have the IPG_UI & IPG_OTHER and not only the IPG_PLAYERn... see src/emu/uimenu.c
|
|
|
|
I think this was the necessary part of your post....
[Re: Bryan Ischo]
#265523 - 10/03/11 01:41 AM
|
|
|
Quote:
Right now the major overhaul of the input API is giving me fits. I only ever understood just enough of the old API to utilize it for my purposes; I never felt like I had a great grasp of its overall architecture or use. Now it's been converted mostly to C++ classes and I am more lost than ever. I feel like in order to adapt libmame to use the new API, I really should understand the input architecture better. So here is my first question in that regards.
There is a class called input_type_entry; two of its constructor parameters are "group" and "player", of types ioport_group and int respectively. The player parameter is described (via the code docs of the member variable it is used for) as "player number (0 is player 1)". But ioport_group is an enumeration which already includes IPG_PLAYER1, IPG_PLAYER2, ..., IPG_PLAYER8. This seems redundant.
Am I misunderstanding something, or is either the player member variable of input_type_entry, or the IPG_PLAYER{1,...,8} enumeration values of ioport_group redundant?
|
Consider it high comedy....sincere tragedy....whatever...don't take it personally.
The Culture
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Dev question: is ioport_group redundant?
[Re: etabeta]
#265541 - 10/03/11 04:10 PM
|
|
|
> IIRC, ioport_group is mainly used to group the various inputs in the Input (General)
> configuration menu of the internal UI, and that's why you also have the IPG_UI &
> IPG_OTHER and not only the IPG_PLAYERn... see src/emu/uimenu.c
Eta is correct. "player" is the player number in the game, "group" is primarily for the tab menu organization.
|
|
|
|
Re: I think this was the necessary part of your post....
[Re: mogli]
#265549 - 10/03/11 06:06 PM
|
|
|
So I should only post things that you think are necessary? OK I'll PM you next time I want to post and you can edit for me. Thanks.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: I think this was the necessary part of your post....
[Re: Bryan Ischo]
#265550 - 10/03/11 06:33 PM
|
|
|
> So I should only post things that you think are necessary? OK I'll PM you next time I
> want to post and you can edit for me. Thanks.
No, he means that your criticism of the C++ conversion of the input system validates his claim that MAMEdev suck and we should rewrite the project in x86 assembly.
|
|
|
|
Re: I think this was the necessary part of your post....
[Re: R. Belmont]
#265566 - 10/04/11 02:45 AM
|
|
|
> > So I should only post things that you think are necessary? OK I'll PM you next time I
> > want to post and you can edit for me. Thanks.
>
> No, he means that your criticism of the C++ conversion of the input system validates
> his claim that MAMEdev suck and we should rewrite the project in x86 assembly.
You're getting your trolls confused. Bizimonki is the one who hates C++ while Mogli is just a dick in general who thinks he's God's gift.
|
|
|
|
Re: I think this was the necessary part of your post....
[Re: R. Belmont]
#265567 - 10/04/11 03:05 AM
|
|
|
> > So I should only post things that you think are necessary? OK I'll PM you next time
> I
> > want to post and you can edit for me. Thanks.
>
> No, he means that your criticism of the C++ conversion of the input system validates
> his claim that MAMEdev suck and we should rewrite the project in x86 assembly.
I think you are being facetious, but just to be clear: I did not intend to criticize the C++-ification of MAME. It has been a pain for me as I mentioned but I certainly realize and accept that it is the right thing for the project and that it has benefits for all of the other developers. Mostly I was just looking for a little pity and also I was looking just to communicate; I have been working on a project based on MAME for a year and a half now with almost no outlet to talk about it at all, and sometimes I just want to vent because there is no where else to do so.
For what it's worth, I figured everything out without resorting to having to ask to have the new structure explained to me, which is what I thought I was going to have to do and my original post was intended to be a lead-in to this process.
I get tons of memory leaks with the new input system, as reported by valgrind; it seems that once the input objects for a given game have been instantiated they kind of never go away; I am not sure why. This could certainly be an artifact of the way that I am using them, although I don't quite know how. The only objects that I create are a global driver_enumerator created with:
Code:
emu_options options;
driver_enumerator *g_drivers = global_alloc(driver_enumerator(options));
Then various objects get hung off of that as I iterate over the drivers, get the machineconfig for each, initialize the ioport_list for each of its devices, and then inspect the contents thereof.
I would expect that since these are all hung off of the same driver_enumerator, and that it was created with global_alloc which sets the object up to be deleted at exit, that I would not get any memory leaks reported by valgrind. But I still do. Weird.
Edited by Bryan Ischo (10/04/11 03:05 AM)
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: I think this was the necessary part of your post....
[Re: Bryan Ischo]
#265602 - 10/04/11 04:28 PM
|
|
|
> I think you are being facetious
Bingo 
> Mostly I was just looking for a little pity
> and also I was looking just to communicate; I have been working on a project based on
> MAME for a year and a half now with almost no outlet to talk about it at all, and
> sometimes I just want to vent because there is no where else to do so.
You certainly should talk about it more. And maybe use the Programming Forum, where it's more on topic (it's not like much else happens there) We're certainly interested in absorbing any really interesting modularizations you come up with (ClientServer's backend is going to get absorbed at some point too, most likely).
> I get tons of memory leaks with the new input system, as reported by valgrind; it
> seems that once the input objects for a given game have been instantiated they kind
> of never go away; I am not sure why. This could certainly be an artifact of the way
> that I am using them, although I don't quite know how. The only objects that I create
> are a global driver_enumerator created with:
I don't know the details here, but Valgrind is fairly clean on current MAME with respect to core leaks. Plenty of drivers do leak here and there, of course, but those get fixed as they're caught.
|
|
|
|
Re: I think this was the necessary part of your post....
[Re: R. Belmont]
#265614 - 10/04/11 06:38 PM
|
|
|
> You certainly should talk about it more. And maybe use the Programming Forum, where
> it's more on topic (it's not like much else happens there) We're certainly interested
> in absorbing any really interesting modularizations you come up with (ClientServer's
> backend is going to get absorbed at some point too, most likely).
Doh - I wasn't even aware that there was a programming forum. Yes, that is definitely the more appropriate place for my questions, and I will be sure to post coding related questions there in the future.
I brought the topic up of what I had planned to do a year or two ago and there was some push back (at least I interpreted it as that, I was very new to the forums so maybe I hadn't fully calibrated yet). Since what I have done is to enable MAME to be compiled as a library with a C API, there was concern that this would just make it easier for the unscrupulous to create illegal products based on MAME. That is absolutely not my intention, and to be honest, I don't think that there really is any way to prevent the unscrupulous from doing bad things and I'd rather not limit the scrupulous from doing fun things in the process, but that's not my decision. Anyway, libmame has at the very least proven to me that it is an abstraction of the MAME engine that can remain stable over time; despite all of the internal changes in MAME that have occurred since 0.137 (which is where I started), libmame's API has remained constant. And my frontend which integrates MAME has thus been isolated from MAME source code changes. The main benefit of the way I have done this is that my front end can integrate the control of, rendering of, etc, MAME in a way that is more seamless than other frontends; I can render MAME within my 3D UI and then zoom in to play the game, zoom out, present custom rendered in-game menus, etc.
I'll make my next task to "productize" libmame (i.e. clean it up so that it's as nice as possible for anyone else to compile and use) and put it up somewhere so that anyone interested can take a look. Right now the biggest hurdle is that it doesn't compile on Windows (Linux only), because I am kind of a stickler about system APIs; I only use POSIX and demand that the operating system support it, rather than having to make my program support arbitrary operating system interfaces. This works OK for many things because Windows supports some POSIX APIs, but libmame uses some stuff that is going to require a shim layer for Windows to implement the POSIX support, and I haven't written that yet ...
|
|
|
|
Re: I think this was the necessary part of your post....
[Re: Vas Crabb]
#265636 - 10/05/11 12:26 AM
|
|
|
> You're getting your trolls confused. Bizimonki is the one who hates C++ while Mogli
> is just a dick in general who thinks he's God's gift.
Hahahahahahahah. I am godly. Difference. (Though I did ask a somewhat related question some months ago about assembly.) In any case, my suggestion, as has been common, was from a standpoint of post/conversation bloat. (This post being an example of economy.)
|
Consider it high comedy....sincere tragedy....whatever...don't take it personally.
The Culture
|
|
Previous 
Index 
Next 
Threaded 
Dev question: is ioport_group redundant?
Reply
[Re: 
