MAMEWorld >> Programming
Previous thread Previous  View all threads Index   Next thread Next   Threaded Mode Threaded  

Pages: 1

Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


IPT_TILT1 through IPT_TILT4 - is there any reason for these?
#289311 - 06/12/12 09:28 PM


I noticed that these port types are defined now.

IPT_TILT1 is used by a single driver ("icecold"); why can't that driver use IPT_TILT instead of introducing a new port type?

IPT_TILT2 through IPT_TILT4 are never used.

Is this cruft really needed for anything?



R. Belmont
Cuckoo for IGAvania
Reged: 09/21/03
Posts: 9713
Loc: ECV-197 The Orville
Send PM


Re: IPT_TILT1 through IPT_TILT4 - is there any reason for these? new [Re: Bryan Ischo]
#289329 - 06/13/12 12:27 AM


These types are primarily for the benefit of upcoming drivers, plus the likely future inclusion of smartphones and other MIDs in MESS.



Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


Re: IPT_TILT1 through IPT_TILT4 - is there any reason for these? new [Re: R. Belmont]
#289332 - 06/13/12 12:50 AM


Yeah, I figured; but why does there need to be both IPC_TILT and IPC_TILT1?

Is there a reasonable difference between these?

In case you're wondering, I'm updating libmame to support MAME 0.146 and enjoying more of the wonderful C++-ification that has happened, and at the same time noticing other changes like the IPT_TILT1-4 one.

I'm currently dealing with the fact that it seems that you can no longer get the name of a button that was given in the port definition macro for "core" input port types unless you have a running machine. Which makes no sense.



Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


Re: IPT_TILT1 through IPT_TILT4 - is there any reason for these? new [Re: Bryan Ischo]
#289334 - 06/13/12 12:56 AM



> I'm currently dealing with the fact that it seems that you can no longer get the name
> of a button that was given in the port definition macro for "core" input port types
> unless you have a running machine. Which makes no sense.

In particular, this seems like pretty bad C++ style:

(from device.h, device_t definition):

public:
// getters
running_machine &machine() const { assert(m_machine != NULL); return *m_machine; }

Returning a value as a reference when it is valid for the value to be NULL (as it is before the device has had set_machine() called on it, which is true before a machine has been created and set into the device by set_machine()), but using an assert, is pretty bad.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 398
Send PM


Re: IPT_TILT1 through IPT_TILT4 - is there any reason for these? new [Re: Bryan Ischo]
#289361 - 06/13/12 06:34 AM


It's valid for the value to be NULL as long as you don't ask to use it. Calling machine() means you're going to use it, so it's normal you get a runtime error. The real question is why whatever method you're using to get at the names calls machine(), and whether it's really necessary.

OG.



Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


Re: IPT_TILT1 through IPT_TILT4 - is there any reason for these? new [Re: Olivier Galibert]
#289365 - 06/13/12 06:51 AM


> It's valid for the value to be NULL as long as you don't ask to use it. Calling
> machine() means you're going to use it, so it's normal you get a runtime error. The
> real question is why whatever method you're using to get at the names calls
> machine(), and whether it's really necessary.
>
> OG.

The way the class is written, it is possible for a device_t to be in a state such that any call to machine() will always blow up. If it returned a pointer to a machine instead of a reference, then at least the device_t class could represent that it doesn't have a machine yet to the caller by returning NULL. As it stands, device_t is a timebomb until it gets its machine.

As it turns out, calling name() on an ioport_field tries to get the current ioport_manager, by calling manager() on the containing ioport_port, which itself calls machine() on the containing device_t. That blows up because of this code.

But calling name() on an ioport_field before there is a machine is perfectly valid - or at least, it used to be, until Aaron Giles' C++-ification struck again. Calling name() on a field without having instantiated a machine is how the info stuff (that dumps XML descriptions of all games) would display, for example, a button's name. I noticed that the info stuff has been adapted to not call name() of fields any more, and thus never shows button names; or maybe it never did, I'm not sure.

Anyway, *my* code calls ioport_field::name() without a machine, and it used to work. And I'm not saying that it's such a big deal for there to be bugs in software, every software developer makes bugs. The thing that is a little irritating is that the bugs are cropping up because of a C++ coding style that just invites trouble. There is a reason that encapsulation is one of the most important features of C++. Making methods that will break without warning unless the caller has some special knowledge of some global state is an encapsulation violation.

Well after an hour or two of investigating this and coming to a better understanding of how the code works, I "fixed" it by adding a has_manager() method to ioport_field and ioport_port, and a has_machine() method to device_t. Then I made ioport_field() call has_manager() and do the right thing if there is no machine (return NULL) rather than blowing up.



jonwil
Lurker
Reged: 10/06/03
Posts: 536
Send PM


Re: IPT_TILT1 through IPT_TILT4 - is there any reason for these? new [Re: R. Belmont]
#289831 - 06/19/12 09:49 AM


I cant think of any device old enough to be considered for MESS and yet new enough to have sensors that would need these IPT_TILT inputs.



R. Belmont
Cuckoo for IGAvania
Reged: 09/21/03
Posts: 9713
Loc: ECV-197 The Orville
Send PM


Re: IPT_TILT1 through IPT_TILT4 - is there any reason for these? new [Re: jonwil]
#290059 - 06/22/12 04:20 PM


> I cant think of any device old enough to be considered for MESS and yet new enough to
> have sensors that would need these IPT_TILT inputs.

Pinball machines? The original 2007 iPhone (not that we're suicidal)?



SailorSat
MAME Fan
Reged: 03/04/07
Posts: 169
Loc: Germany
Send PM


Re: IPT_TILT1 through IPT_TILT4 - is there any reason for these? new [Re: jonwil]
#290345 - 06/27/12 06:09 PM


> I cant think of any device old enough to be considered for MESS and yet new enough to
> have sensors that would need these IPT_TILT inputs.

Virtual Reality Cabinets maybe? =)



I do all that stuff even without a Joystick
Soft-15kHz, cabMAME, For Amusement Only e.V.


Pages: 1

MAMEWorld >> Programming
Previous thread Previous  View all threads Index   Next thread Next   Threaded Mode Threaded  

Extra information Permissions
Moderator:  Pi 
0 registered and 1 anonymous users are browsing this forum.
You cannot start new topics
You cannot reply to topics
HTML is enabled
UBBCode is enabled
Thread views: 2734