Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news


  

Author Topic: MAMEInterop SDK v1.3 Released for Developers  (Read 16834 times)

0 Members and 1 Guest are viewing this topic.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #40 on: February 17, 2007, 07:58:07 pm »
Don't sweat it man, I'll just send the app to you and you can test it.  ;)

I forgot to write the docs so the release will be either late tonight or early tomorrow, depending upon how long I can manage to keep interested today.  A source-code release will soon follow.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #41 on: February 17, 2007, 09:48:57 pm »
Ok Guys, here you go.  Give it a spin and let me know if anything isn't working. 

And I can't stress this enough, please READ the readme.txt before even launching it.  You'll need to setup your ini file for your particular hardware.  My example default.ini has the qbert knocker and the 4 player start/coin leds already setup with some possible scripts to give you an idea of what you can do.  Questions and comments would be appreciated as scripts tend to confuse the hell out of people.

http://www.oscarcontrols.com/lazarus/files/mamehooker1.0.zip

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #42 on: February 18, 2007, 03:33:53 am »
Well I know nobody wants to hear what I think, but imho adding internalized support for the ledwiz in a fe is rather stupid and useless.  All it does is add more things to maintain when the same thing could be accomplished via command line calls.  Whenver randy updates the dll/ocx all the users are sitting on their hands until the fe dev gets around to updating the code. Also what exactly would you do with it fe-wise? Granted I know that most people  use their ledwizzes for nothing more than a way to light up their cp buttons with some blinky effects, but I can sell em 5 bucks worth of kit that'll do that and it wouldn't even have to be hooked up to a computer. :)

I don't think the dll will need to be updated anymore. All the code necessary to communicate with the LEDWiz is already in there. What updates are necessary? The only update to ledwiz.dll needed was made recently by MikeQ to change the SBA levels to go up to 49 instead of 48 since some devices didn't work with the PWM signal, and 49 is the only level that dosn't have a PWM signal. What needs to be updated? Nothing.

I don't get how you think adding internal support for LEDWiz in a FE is a bad idea. It's like saying adding internal LEDWiz support to J5 is "stupid and useless" [sic]. A command-line app is okay for lighting up buttons when you, say, want to view the game's CP. But what about realtime lighting while scrolling through a list for example? A command line app is not good enough for something like this.

How do you know what people want from their ledwizzes? People want to do as many things as they can, like "speak each button action while lighting it up", cool things like that were only available in PowerMame, now you can do it from the FE. In my opinion (and maybe noone wants to hear what I think either), it's better to have LEDWiz support in the FE than in a custom build of Mame. As anyone who knows will tell you maintaining a custom build is alot of work.

I don't see why it's better to have the LEDWiz support inside the CP Viewer. All that does is limit what you can do with the LEDWiz to lighting up your buttons when you view your CP. Unless you have J5 running resident and allow external programs to send commands to it, it's rather limited in what it can do. Some people like the buttons lit up while they play a game, some don't, and also attract modes are a must have feature for a LEDWiz too (IMHO), you can't do that in a CP Viewer app. I really don't understand your logic behind thinking that.

Where it's at is lighting up different color-coded layouts (like j5 and the other cp viewers) and messing with mame's outputs as then you are actually doing something useful with the ability to control multiple lights/motors/ect on the fly.

Lighting up different color-coded layouts is one aspect, but a LEDWiz plugin for a FE can do that, there is also attract mode and responding to Mame's outputs and plugins can do that too. Are you starting to see why I think it's better to have LEDWiz support in the FE rather than in the CP Viewer? BTW A plugin remains resident the entire time your running Mame and is constantly given calls from the FE telling it what event has taken place (keypress/game selected in list/mame started/mame finished/game launch/game stop/attract start/attract stop etc.) You can use all these events to control the LEDWiz in different ways. There is no two way communication between a FE and an external CP Viewer, all you can do is send it the ROM name in a command line parameter and have an ini file with your LED's setup the way you want. How do you tell J5 to run an attract mode sequence for example?

The only thing a fe can do really is use animations for when idle in the fe and various transition effects.  That's all well and good, but the can be done with a simple call to the command line utility.  Or better yet, a command line app that isn't dependant upon the ledwiz software.

Animations is not all it can do, it can do that and everything else a CP Viewer can do and a LOT more. I really don't get your reasoning behind what your saying. I'm racking my brain and I can't figure it out. I'm not trying to sound arrogant when I say this, but take a look at my LEDWiz plugin and tell me what features are missing that J5 has. Take a look at the Mala LEDWiz plugin, or the LEDWiz support in Atomic. They all do more with the LEDWiz than a CP Viewer ever could and the reason is because they are either plugins or built into the FE.

Really the fe's with built in support need to take it out in leu of a more generic solution.  I'm not trying to tell anybody how to code, but when you do a big project like a fe, you want to use as few dlls as possible as it just bloats your code and just makes it more complicated to manage.  After 4 years the dk beta now has a whole two dlls and it's driving me crazy because I can't get rid of them.  I wonder about people that don't bat an eye at using 10 or 20. 

I'm throwing all these dlls, ect in this hooking app so that I don't have to elsewhere.  It's going to be a god-awful mess dll wize, but it'll be worth it because this app is nothing but dlls, so there's not really any code to bloat.  :)

You really must have no idea about Windows Programming then. The whole Windows API is based around dll's and shared librarys. It's the same idea behind OOP. You sound like your avoiding using dll's for the sake of it. Your just going to send out the false impression that dll's are evil or something. Does having only two dll's in DK make you a good coder? No. There is nothing wrong with having dll's if they are written well.

VB6 is your main language so you should be using more dll's not less, and writing them in C++. What if you want a thread for example? VB6 will crash if you try to use threading. MameInterop is a point in case, the message loop for the Window that captures messages is infact in a thread. Try doing that in vB6 alone.

But enough ranting.....

You have a right to rant about anything you like and there is nothing wrong with disagreeing. For example I disagree with the main arguments in your post.

Quote
I don't think windows messaging would be fast enough.  All mame does is pump out the values of data used in real life scenarios (like a flashing light) and it seems to lag a little sometimes.  I can only imagine if you actually had to do something and wait for it to finish. It would work, but only if you aren't doing manual animation.  I'm not sure a server app would be a good idea for anything other than sending animation files.  Where the ledwiz needs that delay for the usb chipset issue every millisecond counts.  At least if you are doing anything advanced with it.  For a fe it'd be fine though since, as I complained above, you would really only want to send different layout files in a fe. I say make it command-line based, but that's just me. 

The way I was going to write is was to have commands where you can load lwa's into the server by pointing it to a bunch of lwa files and it will load them in memory so you can just send another command to execute them. I don't believe there is the delay issue with the ledwiz.dll only the ocx AFAIK, and I would recommend you use that instead of the ocx anyway.

Again, I disagree with the commandline option. Swindus has already written one called LEDWizLighter anyway so it's not like it's not an option. LEDWizLighter uses output from my LEDWizGen application which generates the lighting profiles for all games in controls.ini. Right now that can be used with FE's like MameWah that don't have support for LEDWiz built in. But it really does limit what you can do with the LEDWiz to just lighting the buttons for a game, which in my opinion dosn't really take advantage of all the other cool stuff you can do with it.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #43 on: February 18, 2007, 08:21:46 am »
Sorry man but you couldn't be more wrong. 

J5 can do attract mode sequences, for example.  It just does them a different way.  You set up the default state for all the lights, which cna be multiple states in sequence.  J5 IS a resident app, it's just optional because it uses some memory and some people don't like that.

ledwiz does have a delay.  There's even a checkbox to turn if off (or down) in powermame.  It has nothng to do with the connection method, from what I understand it's some sort of usb chipset issue.  Yes the ocx is significantly slower than the dll, but the dll stil can't instantly light something.

Your point about windows apis vs external dlls is invalid.  When m$ makes a dll update, they make sure it is backwards compatable, third-party dlls, not so much. You don't have to worry about dlls that you are calling via the api because they are installed by default with windows.  The only non-windows api calls I ever make are to directX, because, well if you are running mame without directx then god help you.  The whole reason the api layer was invented was so that developers don't have to package their stuff up with dozens or dlls and manage their registration, thus bloating and complicating the project.  And I did do multi-threading in vb6 remember?  I already had a working hooking app before you helped me with the variable issues, it just didn't get the name properly.  But to answer your question, when I find something that vb6 can't do, I don't do it.  Of course over the past 10 years or so there's only been maybe 2 or 3 things that I've needed to do in vb but couldn't. There's a flaw in your thinking there about the dlls.  If I was constantly writing C++ dlls to get things done then I just code the whole thing in C.  :)

You are confusing the issue of can with should.  Can you make a fe infinately more complex by doing all the coding requried to properly light all the buttons and properly assign all the labels?  Of course.  Should you?  Well if your fe is perfect and you never want to add another new feature then you probably have the time as a developer to do that, otherwise you'll be spending all of your time getting this feature integrated.  As of now only two applications assign labels and lights properly... j5 and powermame.  (And to be honest I'm not sure about powermame and labels, but I'm giving it the benefit of the doubt.)  It was easier in powermame because you don't have to recall data, it's in there already.  J5, on the other hand has a hard time doing it.  Getting all the data required to do this accurately and properly takes at least one call to mame and the parsing of up to 5 very large xml files as well as the controls.xml/controls.ini.  Some of the other stuff can be stream-lined by a more telented programmer I'm sure, but the mame call can't be avoided.  You can either do it per-game, which makes quick changes impractical, or all at startup, which would make your boot-time significantly longer.  I'm not the best programer in the world so I'm sure some speed improvement can be made, but not enough to make it practical to, lets say have the layout change on the fly while you are scrolling through the list to reflect the current game selected.  It can be done AFTER you stop of course, but at that point speed isn't a issue and you can just set it externally.  And before you start mentioning this fe and this app that does it quicker, yes I'm aware of many of them, but unfortuantely they do it wrong.  They output a rough reflection of what the layout should be, their accuracy is generally around 60% because they don't read the cfg, ctrlr, driver and device settings like I do.  And I understand that for a lot of people that this rough estimation is enough, but I said right in my first sentence in that post in the last post that this is what I thought.  I don't think you should do something if you aren't going to do it right.

And I want to make something prefectly clear, I'm not being arrogant about this, this is just the truth.  The reason j5 is so accurate is because I abandoned all of my other projects indefinately as I built the complex backend for it.  And guess what?  About the time I got it done, they up and changed mame's file system structure and I had to do it all over again!  Dk hasn't been updated in almost 2 YEARS.  That should tell you what a full time job it is to keep the stupid thing maintained.  It isn't the most accurate and feature driven because I'm god's gift to programming, it's that way because I spend way more time on it than any normal person would.  So that goes back to what I was saying earlier, while you can do it in the fe, it'd be a full-time job to implement. 

Yeah your right, I suppose you couldn't have your buttons "talk" to you ro anything crazy like that if you did it externally.  Maybe I'm having a lapse in logic or something, but why would you want to do that inside a fe in the first place?  At least some of the buttons on your layout are used for actual navigation in the fe, so it's impossible to press them all without launching a game or scrolling through the list inadvertantly.  Aside from that, this seems like a feature that would only be useful while playing a game.  Again, I might be missing something. 

Yes you are absolutely right, you can't have a dynamically-generated "scrolling sequence" via command line.  Again though, unless my logic fails me you can't have that even if it's integrated.  I don't know what the scroll speed is on the average fe is these days, but in my fe the time between transition from one game to another is less than 10 ms.  Yeah you could have em blink as you scroll or something but it'd be so fast that it'd give you a seizure or something.  :)  Now if you are referring to loading a different animation while scrolling that isn't keyed to the scroll speed, then you can do taht via external calls.  Send the scroll animation layout file when starting a scroll, and set it back again when idle.

And I'm not being sarcastic at all but your going to have to explain that last line.  Given what I've said about how a lot of the things you suggested are impractical to do what cool things are left that you can only do via integration? 

You seem to be upset or something and I don't get that.  You asked my opinion about the app and in order to give it, I had to explain why integration is a bad idea.  You can't exactly get upset because I gave you my opinion when you asked me for it.  If you wanted me to lie then you should have said so. 8)

I think you aren't getting what I was saying about the windows messaging being slow though.  There is some delay (not much, but time is taken) when you send or recieve a message.  It isnt huge at all but it causes issues because windows message threads are cached and there isn't any practical way to do a "frameskip" to ignore incoming message processing while you are setting the lights. 

You know that bug in basketball I mentioned the other day?  That's the perfect example.  See it's flashing so fast that I "miss" some commands while I set the lights.  The problem is they aren't "missed" they are waiting in the window's built-in message que building up as they are waiting to be processed.  Eventually the load is just too great.  If I manage to exit out of basketball before the build-up crashes the app it continues to blink on and off even after mame has exited for up to a full minute.  This isn't something I've coded that is making that cache, it's the way windows works so there is no getting around it.  The only way to solve this issue is to have two-way communication, but that kills your speed advantage right there.   For just setting layouts, yes messaging would work great.  For on the fly animation, it could be dangerious.

You are missing a much easier way to get things done though if you just really want to use messages.  We made the sdk right?  I'm writing this app that can do all kinds of things besides just ledwiz via the sdk right?  They use messaging right?  Ok, time's up, pencils down.  Instead of making a new message protocol and going to the trouble of writing an app that only handles the ledwiz, why not just write a dll everyone can use that "fakes" mame's output system?  Mame doesn't do anything special, it just sends it's hwnd and sends a set of custom messages, so an app doesn't have to be mame to take advantage of a sdk app.  Then a developer has access to anything coded via the sdk.  Heck if there's some feature missing from the little app I'm coding just add them and then you have an app that does everything you wanted plus it has all kinds of other crazy interfaces supported.

We are very fortunate with mame because inputs aren't changed quickly for the most part.  The few that are changed quickly are thankfully force-feedback-style effects and m$'s force feedback interface is so quick that time is measured not in milliseconds, but in microseconds.  So hopefully we aren't going to run into the issue there. 


Ok man take a breath, it's all going to be alright.  ;)
« Last Edit: February 18, 2007, 08:35:15 am by Howard_Casto »

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #44 on: February 18, 2007, 10:56:46 am »
When I was talking about making a LEDWiz SDK like the MameInterop SDK using Windows Messaging that's exactly what I had in mind (to do it like Mame does). There is only one way to use Windows Messaging and that is to have your own custom messages and send them via SendMessage or PostMessage and read them in the WinProc function. I've already written applications that do this so there is no problem with the method. It's when your sending lots of messages very fast that I'm not sure if it's the best method. I guess I need to do some testing. On slower machines this could be a problem, and we don't want to lag the calling program. Your issue with the bug in basketball hilights that very problem. There is the alternative method of using a localhost loopback with ports but I havn't done much winsock stuff.

Okay J5 is memory resident, it can do attract mode sequences, I STILL think FE's are a better place to handle the LEDWiz device. Or to use some sort of global solution. But for FE's that don't currently have LEDWiz support, J5 will be the perfect solution for those people.

I don't believe there is the usb chipset issue anymore. There has never been a FastCom mode for the ledwiz.dll so I assume it's all handled automatically.

The VB6 application you wrote was a common method of hooking a Window so you can read it's messages. Something I've done before in VB6 myself. But this has nothing to do with threading, so I'm not sure what your talking about there. VB6 can't to threading, simple as that.

Why not code in C then? I'm guessing the reason your not coding in C is because you don't know the language well enough. VC6 is not as easy to create windows forms in using pure API, and MFC has it's own annoying issues. So I would imagine many people would write apps in VB6 because it's easier to create the forms and have any of the lower level stuff stored in a C++ dll. It's all about using the right tool for the job. I only code C++ using VS6 so it's probably alot easier to write form based apps in C++ in one of the newer Visual Studio's.

Your saying that adding LEDWiz support to a FE is a bad idea because it takes alot of time to write. Well I'm not the author of GameEx, but I'm writing the LEDWiz support. That is the whole point of having plugins (which in reality are just dll's).

If I have to parse ListInfo.xml every time the plugin runs, the way I would do it would be this way:

1. Having the full path to the mame exe, I launch Mame with the command-line option to generate the ListInfo.xml to a file.
2. Parse ListInfo.xml writing only the outputs necessary for the plugin to an ini file in a compact format.

Eg. ROM Name|Parent|NumButtons|etc.

3. Next time you run the plugin it compares the Mame.exe version or creation date with the last time it was run, if it's newer then goto 1.
4. If it's not newer and the compact ini file is available parse that instead.

That will get parsing ListInfo.xml to under a second. Parsing the entire ListInfo.xml takes about 5 seconds on my machine but it will only need to do that everytime you update Mame. I store all the info I need from ListInfo in RAM, so it's instantly available at any time - so realtime lighting during list scrolling is possible.

Also your point about list scrolling, the way it works in GameEx anyway, is that while you hold down your joystick to scroll down the list the GameSelect() event isn't triggered every time. If you let go of scrolling for a second then the event is triggered and the LED's light up for the game.

Right now I'm not that worried about people who map their keys in strange ways. For a while now I thought parsing controls.ini was enough but I will deal with that eventually. It can't be that difficult, I mean even parsing a bunch of files and referencing them, it can't be that hard. I never knew that you needed to read cfg, ctrlr, driver and device settings to get perfectly accurate LED lighting, I might have to E-Mail you for a more detailed rundown on how I should go about that if you don't mind. I like to do things the right way too, so your help would be appreciated on that.

I'm definately not upset so I'm sorry if I come across like that, try to take me with a grain of salt, I mean no offence even if I'm being blunt. I tend to be very dry when I'm talking about technical issues and I do try my best to avoid sounding emotional about it. I appreciate your opinion even when I disagree with some things you say. Though the majority of the stuff you say makes sense and I agree with.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #45 on: February 18, 2007, 03:08:17 pm »
I'm not going to argue, BUT  one thing you said is laughable. 

You said you weren't worried about "people who map their controls in strange ways".  There's nothing strange about how my controls are mapped and there is a LOT of remapping.  And this isn't just because I like it that way, it's to make the games playable.  Mk is a hugely popular series, it is totally unplayable with the default mame mappings.  So there's 4 games (or one driver) right there.  All the street fighter games are upside-down, so those, while not required probably should be remapped.  Any neogeo game with 4 buttons (which are all fighters) have to be remapped to be playable as a standard layout would put button 4 above button 1 and almost all the kof combos use combinations of a/b and c/d and it'd be really hard to hit c/d at the same time like that.   And those are just the games that I personally like, there are probably hundreds of games in mame that need re-mapping to be playable.  So basically like I said, if you don't go to all the trouble that I mentioned, your accuracy is 60% or less on ANYBODY's layout.  I'm not that much of a glutton for punishment.  Wouldn't have done it unless it was necessary. 

And your right it isn't complicated at all, it's just that there is a lot to parse and there is a lot of "cause/effect" branching going on depending upon what you parsed at certain steps. And the device and -joystick/-mouse/-lightgun calls are a nightmare.  You get it parsed perfectly and then how those settings are set totally changes it.  That bit isn't crucial but if you've already ran 49 yards you might as well go for the touchdown.  I'm more than willing to help anyone who needs it, but so far whenever somebody asked me about it and I explained roughly how to do it they got scared and were never heard from again.  ;)

The fastcom stuff is handled internally in the ocx (thus the lag) and via code in the dll.  Afaik the issue still exists.  Even if it didn't a HID class device is "slow" by nature.  I don't want randy jumping all over me so let me explain that.  HID devices, all hid devices have a speed limitation.  We are talking milliseconds here, it's not a big deal, but there is a delay even on the quickest of hid devices.  In normal use it's never going to be an issue, but with that whole backed up buffer deal it could be. 

Oh and winsock is scary.  I've done some winsock apps, (one for the daphne team, but I never got around to sending it. :( ) and they are quicker, but they are a mess to code because you have to have so much error handling.  If you set it up to have app 1 wait until app 2 sends a "recieved" message back and something happens to app 2 you program is essentially frozen.  Also, much like a serial connection the two apps pretty much have to know they are going to talk to each other and if one misses the startup then you are screwed.  There are ways around that but they aren't pretty.  Makes for more complicated programming.  That was actually why Aaron did messages instead.  (Yes as frightning as it sounds we managed to have a short discussion about it without killing each other back then.)

(p.s. Don't think that I was angry either, that's just how I am.  All the smilies on the last post were intetional so you wouldn't think  I was "yelling" at you.)
« Last Edit: February 18, 2007, 03:10:17 pm by Howard_Casto »

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4298
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: MameInterop SDK v1.0 Released for Developers
« Reply #46 on: February 18, 2007, 04:01:00 pm »
Quote
(p.s. Don't think that I was angry either, that's just how I am.  All the smilies on the last post were intetional so you wouldn't think  I was "yelling" at you.)

You are getting soft in your old age  :laugh2:

PS I agree with HeadKaze on how a Led-Controller should be set-up (in most part) as far as it's use goes (In a FE ect.....)

But really there is no right or wrong...  like a cab design it's just a matter of personal taste.

I'm sure you would hate my light fittings in my house  ;)
« Last Edit: February 18, 2007, 04:03:12 pm by loadman »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #47 on: February 18, 2007, 07:04:05 pm »
PS I agree with HeadKaze on how a Led-Controller should be set-up (in most part) as far as it's use goes (In a FE ect.....)

No you don't man, you just think you do.  Aren't you the same guy months ago who pmed me frustrated that mala doesn't support the ledwiz? Well if the iowarrior stuff had been externalized then it would because somebody would have taken the stand-alone exe and replaced it to work with the wiz. 

See there are two types of fe programmers out there, the type that says "Ok I know what people want so I'll only add support for the good devices and that's that." and the type that says "I think, I know what people want, but I'm not superman and I can't do it all so I'll build the structure so that bits of my app can be replaced or interfaced with."  Sometimes it's unintentional though, but regardless the funny thing is it takes the same amount of time to do things the right way (modular) vs doing them the not so right way (internalized)  and the end result functions exactly the same.  The only difference is with my method the user doesn't have to buy new hardware when they switch fes.  I could accomplish 99.9% of what people have been doing with the led hardware in fes by simply having a user-configurable command-line call at various keys points in a fe's code and using some of the great stand-alone utilites that alredy exist for the led wiz.  It works the same and yet the user isn't limited to what I thought would be useful or what hardware I personally have. 

When I wrote above "it makes the code more complicated and more bloated" I thought you guys knew I said that because if you add support for "device a" then out of fairness you have to add support for every single similar device available to the community.  On the other hand if you set it up so that you control "device a" externally then you don't have to support every single device under the sun because you have left a window open for users to add any additional support they may need.

Now you can add built-in support AND support external calls, but why would you when you can keep your code cleaner and achieve the same functionality by using the external interface you just setup?

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4298
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: MameInterop SDK v1.0 Released for Developers
« Reply #48 on: February 18, 2007, 07:31:00 pm »
... Yeah you make good points but that is not really what I meant.

This is what I don't agree with personally:

Quote
Also what exactly would you do with it fe-wise? Granted I know that most people  use their ledwizzes for nothing more than a way to light up their cp buttons with some blinky effects, but I can sell em 5 bucks worth of kit that'll do that and it wouldn't even have to be hooked up to a computer.


Really? I'll take two for $5

What I like a Led Controller to do is:
* Lights the appropriate controlls as you scroll through the list
* Play sexy attract modes
 - When Idle
 - When launching games
 - When switching lists/ emus
- Leave the appropriate Controlls lit after launching a game.
I'm not to worried about colours of buttons etc

But that is just me..... :dunno

anyway back on track

Quote
Don't sweat it man, I'll just send the app to you and you can test it. 


Is there anything I can do to help?

« Last Edit: February 18, 2007, 09:51:00 pm by loadman »

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #49 on: February 19, 2007, 03:46:06 am »
You said you weren't worried about "people who map their controls in strange ways". 

If your gonna quote me, at least quote me properly :P

I said "Right now I'm not that worried about people who map their keys in strange ways", meaning that eventually I do want to add the code to get the lighting as accurate as possible for people who do map their keys differently. Just right now I'm sort of in the middle of redoing my CP with RGB buttons and two LEDWiz controllers. At least then I can see the results of my plugin so I can debug it more easily. I'll worry about all the extra file parsing a bit later down the road.

And I agree with loadman in that it's a matter of personal taste. I think having choice is what makes this scene so great. So I don't think we need to argue the finer points of where the LEDWiz support should go.

Quote
I'm more than willing to help anyone who needs it, but so far whenever somebody asked me about it and I explained roughly how to do it they got scared and were never heard from again.

Lol! Yeah I can imagine it's probably a number of steps, but I have code to parse Mame's output, so I just need to add those extra steps. It's not the code to do it that confuses me, it's what process needs to be taken to find out which button assignment associates to which button on the control panel. But thanks for the offer I will e-mail you about it.

I have the CommIO.dll here, but I havn't written up a VB6 demo to use it yet, it's pretty easy to use, but there will probably need to be some UNICODE conversion on the VB6 side for this one. I'll send it along to you soon.

A remember reading that a few people were upset about the Mame's output system being a Windows only solution, whereas a localhost loopback method would have been portable. For the LEDWiz server/client type app in .NET is probably easy to write like most things in .NET. But I would want to write it in pure C++ so there are no dependancies and so anyone can use it. But it's still got to be better than using the clipboard method ;)

About making things modular so you can add support for other hardware. Right now my plugin supports BetaBrite, BPP-440, CrystalFontz, PJRC, ProLite using COM port output and LEDWiz hardware using MikeQ's ledwiz.dll. Adding Parellel Port output is easy but I havn't got around to that. In the future I probably will add support for defining your own custom protocol if you happen to have a device that is not supported internally. And even though my plugin is not currently written to support things like force feedback, I don't doubt that would be a simple matter of sending outputs to DirectInput in Background/Non-Exclusive mode kinda like how my Exit plugin works now. So really what I am doing is not far off from being modular in design, the problem is I code in C# these days, and writing this as a global solution like a resident toolbar icon app means a whole bunch of extra work so users outside of GameEx can do the same thing. Unfortunately I've done too much bloody work on it to decide that I want to release it for everyone, and since I'm a GameEx user it suits me and other GameEx users well enough.

MameInterop on the other hand is designed so authors can easily add Mame outputs to their own apps. I didn't really invision it as a global solution like where you are taking it. I have nothing against the work your doing, it's just not the direction I'm heading with the GameEx plugin. I will help you as much as I can though with your app, infact I have offered the CommIO.dll to you so you can add COM port output to it. But I must warn you Com output will be much more complex to add than Parallel output. It requires a fair bit of protocol reading - or you can make the users look it up and put the data into an ini file or something I guess.

While I'm on the subject of parallel port output, I notice you have a value assigned to a ledx output to send to the parallel output. Since it is paraellel, shouldn't it just be defined as a pin number, then you take that pin number and OR it with other pin's in case you have two led's lit up at once. Currently from what I see if you send the output for an led while one is already supposed to be lit up it will turn the other one off.

Me and loadman have helped each other out while working on our plugins so we can both get more features added into them using what's available in our own FE's plugin arcitecture. So when you say about loadman complaining about not having LEDWiz support in Mala, your actually talking to one of the guys who has helped code the the plugin to support it. He is also working on the LCD/LED plugin that outputs to the same devices mine does. While you may see it as all this work on our own solutions, you have to realise the plugin method is what works best for the FE's we use. And we both code in different languages (he codes in Delphi, I code in C#). So it's impossible for us to work together on a global solution. If you look at what Youki did to support LEDWiz, it sort of led the way (pardon the pun) to others adding internal support. You and me were the only ones talking about making some sort of global solution back then (which is why LEDWizLighter and LEDWizGen were made). But things ended up chaging and everyone went about doing their own thing. It's kinda too late to turn back now IMHO.

youki

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1612
  • Atomic Front End Creator
    • Atomic Front End
Re: MameInterop SDK v1.0 Released for Developers
« Reply #50 on: February 19, 2007, 05:36:11 am »
It seems it is the moment to start an real open source Front End project.  It should solve all your issues...   ;)






headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #51 on: February 19, 2007, 06:26:36 am »
It seems it is the moment to start an real open source Front End project.  It should solve all your issues...   ;)

I don't know if this is really necessary, I don't see the point in starting from scratch on a FE when there are perfectly good ones closed source. A plugin system means you can develop for it without needing the source code so I'm happy with that sort of thing.

youki

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1612
  • Atomic Front End Creator
    • Atomic Front End
Re: MameInterop SDK v1.0 Released for Developers
« Reply #52 on: February 19, 2007, 07:13:04 am »
It would be a good occasion to get all the best of each front end in only one!

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #53 on: February 19, 2007, 03:35:57 pm »
Is there anything I can do to help?

We there's something you all can do actually.  Download that proggie I made and try it with any of the hardware you have available to you.  A lot of the code I couldn't test because I don't have the hardware.   I could test ledwiz and force feedback only.  Because I ditched all my hard-wired keyboards I don't even have the hardware to test the keyboard leds!  Also if anybody has some of the more high-end force feedback controllers (flight sticks and wheels) I need to know if the ff works for you. 

The configuration isn't exactly user-friendly atm, but I can walk anyone through it that wants to try it out. 

hk

About the parallel port thing.  What you don't see is internally I have a buffer keeping track of all the other pins states and when a state changes I update the buffer (a series of 0's and 1's) translate that into the integer number and send it.  I'm aware of the fact that you have to send the entire data state each time, but I made that function so users didn't have to do that themselves. 

And the serial port thing.....  I just wanted to put that in as a just in case thing.  I don't see anyone making a serial interface anytime soon.  I'll probably just setup raw commands so all the init, connection ect can be written by the user via the scripts.

Youki, when and if vista ever gets to the point of which we are all forced to upgrade I'll probably start an open-source front end in one of the .net languages.  Although I doubt it'd end up working I would be willing to give it a shot.  Other front-ends seem to be defficent in skin features, but on the other hand people like you are really good at adding animation script functionality.  I'm really good at list managment but I totally suck at making setup programs.  It could happen.

Something I'd like to see is a frontend that converts all the artwork (snaps/flyers ect) into native texture files when it generates gamelists.  It'd really eat up disk space to have a second set of artwork files lying around, but think about the speed boost!  Literally the only thing holding back what we can do graphically is the amount of external images we have to load up and convert.  Even as large as some of them are, if they were native before we loaded them up even the puniest of cards could handle the most complex of skins. 

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #54 on: February 19, 2007, 03:58:30 pm »
Hk me and you have some more coding to do.  Looks like santa got my wish list.

From 112u2 what's new:

"
Added pause support to the output system: [Bob Seidel]
 - added "pause" message through the Output system to let clients
    know when MAME is paused
 - the state of an item is now sent when the item is first created
 - updated ledutil to use the pause state
"

This will be great for init, it solves a lot of the problems I ran into and had to make work-arounds.  Basically on your end the sdk dlls need support for the new pause message.  For the examples we can basically just send the pause message to the debug window and be done with it.

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4298
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: MameInterop SDK v1.0 Released for Developers
« Reply #55 on: February 19, 2007, 04:06:35 pm »
 - added "pause" message through the Output system to let clients
    know when MAME is paused.

That is so cool.   

A Led Attract mode could be triggered
You could update display on your LCD or whatever to say MAME PAUSED

Nice

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #56 on: February 19, 2007, 04:11:46 pm »
A remember reading that a few people were upset about the Mame's output system being a Windows only solution, whereas a localhost loopback method would have been portable. For the LEDWiz server/client type app in .NET is probably easy to write like most things in .NET. But I would want to write it in pure C++ so there are no dependancies and so anyone can use it. But it's still got to be better than using the clipboard method ;)

Yeah, that was intentional.  He figured no matter which solution he used there was still going to have to be platform specific code due to how different oses acess a tcp/com style interface.  So since they all need different functions anyway he might as well optimize the windows version.  The code is setup in such a way that others could add loopback support for linux/macos ect if they wanted to.  You gotta remember that at the time the only output device readily available was the ledwiz and I think it lacks linux support.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #57 on: February 19, 2007, 04:16:46 pm »
- added "pause" message through the Output system to let clients
    know when MAME is paused.

That is so cool.   

A Led Attract mode could be triggered
You could update display on your LCD or whatever to say MAME PAUSED

Nice


Well more importantly now we have protection.  Solenoids can't be left on.  I was worried about how I'd universally add solenoid protection code when in theory you can hookup a solenoid through any device.  Now I don't have to.

Also this solves the J5 ahk script issue.  Instead of syncing with the "p" key, I can listen for a pause message instead!  Pretty sure ahk supports message handling, but if not I'd be willing to write the dang code just to get rid of that error.

Red 5

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 77
  • Do something stupid and we will make you famous
Re: MameInterop SDK v1.0 Released for Developers
« Reply #58 on: February 19, 2007, 08:10:16 pm »
I'm guessing this would work as a simple turnkey solution?



8 relay outputs, kit form $34.95

Click here for more details


Jon
I accept CASH, Hostages and Gold Krugerrand

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #59 on: February 19, 2007, 11:35:19 pm »
Yes it would.  A tad pricey (could be built for a fraction of that).  But that essentially uses the 8 data pins on the parallel port to trip 8 relays.  It'd be a nice solution for solenoids or high amperage lights. 

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #60 on: February 20, 2007, 12:02:51 am »
Hk me and you have some more coding to do.  Looks like santa got my wish list.

From 112u2 what's new:

"
Added pause support to the output system: [Bob Seidel]
 - added "pause" message through the Output system to let clients
    know when MAME is paused
 - the state of an item is now sent when the item is first created
 - updated ledutil to use the pause state
"

This will be great for init, it solves a lot of the problems I ran into and had to make work-arounds.  Basically on your end the sdk dlls need support for the new pause message.  For the examples we can basically just send the pause message to the debug window and be done with it.

This is great! Okay, I'll download the 112u2 source and update for pause.

EDIT: I'm not sure if an update is necessary, since the current version of MameInterop works with pause.

The outputs look like this:

Code: [Select]
update_state: id=12345 (pause)  state=1 <-- paused
update_state: id=12345 (pause)  state=0 <-- unpaused

Do you think we should add another callback just for pause? Eg. mame_pause(int state) ? Or just leave it as is and let the user deal with it? I don't mind either way really.

P.S Just sent you my CommIO.dll with a VB6 example
« Last Edit: February 20, 2007, 03:00:19 am by headkaze »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #61 on: February 20, 2007, 03:50:15 pm »
Well that's an odd way to do it, but I guess whatever works.  Your right, no need to monkey with the dll. 

We might want to update the examples though to do something special with pause (like clear the text box or something.  But I dunno, it's probably ok as-is. 

I've been busy with house wiring today (ugh!) I'll take the comIO and the stuff loadman sent me and update my app shortly.  Then barring some testing I'll go ahead and make an official release announcment and release the source.

p.s.  I'm glad I didn't do the is2string thing now.  You know that "barring a major re-write" comment I made?  Well all the led1's will be a different number now, so it would have thrown everything off.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #62 on: February 20, 2007, 11:10:24 pm »
Ok, I added a universal pause code, so that's done. 

Things to add next:

wat milliseconds     A function to wait between commands, useful for animation.

iowarrior/mala functions.....

generic serial functions courtesy of headkaze

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4298
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: MameInterop SDK v1.0 Released for Developers
« Reply #63 on: February 20, 2007, 11:36:45 pm »
 :notworthy:

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #64 on: February 21, 2007, 02:25:50 am »
Ok wait is added and the com port functions are added.

I also added the ability to load long/complex script sequences via an external file.  It should make for trading scripts easier and it should help to keep ini files neater. 

That's all I'm doing toinght... mala stuff will have to wait till sometime tomorrow.


Things left to do:

mala/iowarrior

Modify the rgb function so that if you set the start position higher than 30, it'll automatically pick up the remaining outputs on the next ledwiz.

wiimote support??

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #65 on: February 22, 2007, 03:52:29 pm »
Nice work Howard  :cheers:

I have a question for you too, do you know why the Mame developers havn't added force feedback support into Mame? Why is it only implemented in the output system?

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #66 on: February 22, 2007, 09:13:52 pm »
Well, the main reason is they don't want to I guess.  I've brought it up a few times and while nobody said, "hell no we won't add it" or anything like that nobody seemed thrilled about gving it a shot, mainly because converting "real" force feedback (like afterburner) into directx force feedback is going to take a lot of work, probably a good weeks worth of actuator mapping to create the proper feel per game.  And then once it's done you try it on another controller and it doesn't feel right.  FF is very device dependant.  Like I'm using a xbox controller, cause they are cheap, so it's going to make it really hard for me to make effects for games like outrun.

« Last Edit: February 22, 2007, 09:26:16 pm by Howard_Casto »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #67 on: February 22, 2007, 11:45:21 pm »
Ok I need to squash some bugs first, but things coming down the pipe:

Added function to launch command line applications (useful for j5 and the like)

Added %rom% and %comma% tags, for obvious reasons.

IO Warrior functions are in place, but they are as of yet untested.

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #68 on: February 24, 2007, 07:53:25 am »
Using the method I described in a post earlier I can process ListInfo.xml in under a second.

Here are my test results...

Here I run my test application for the first time, it has to create ListInfo.xml, parse it, write a compact version to ListInfo.ini then output the values for 1942.

Code: [Select]
24/02/2007 9:48:17 PM : Start
24/02/2007 9:48:18 PM : Mame Version: 0.100
24/02/2007 9:48:18 PM : Detected New Mame Version
24/02/2007 9:48:18 PM : Creating ListInfo.xml
24/02/2007 9:48:23 PM : Reading ListInfo.xml
24/02/2007 9:48:25 PM : Writing ListInfo.ini
24/02/2007 9:48:25 PM : 1942 ParentROM:
24/02/2007 9:48:25 PM : 1942 NumPlayers: 2
24/02/2007 9:48:25 PM : 1942 NumButtons: 2
24/02/2007 9:48:25 PM : End
7 Seconds.

This takes 7 seconds here, which is expected for all the processing going on. But now that the compact version of ListInfo.xml now called ListInfo.ini has been created, so next time it should only process that file.

Code: [Select]
24/02/2007 9:48:30 PM : Start
24/02/2007 9:48:30 PM : Mame Version: 0.100
24/02/2007 9:48:30 PM : Reading ListInfo.ini
24/02/2007 9:48:30 PM : 1942 ParentROM:
24/02/2007 9:48:30 PM : 1942 NumPlayers: 2
24/02/2007 9:48:30 PM : 1942 NumButtons: 2
24/02/2007 9:48:30 PM : End
0 Seconds.

This time it takes less than a second to get the info we want from ListInfo.ini. But what if you update Mame? This program reads the Mame version and will process ListInfo.xml again if it detects a new version.

Code: [Select]
24/02/2007 9:48:54 PM : Start
24/02/2007 9:48:54 PM : Mame Version: 0.112
24/02/2007 9:48:54 PM : Detected New Mame Version
24/02/2007 9:48:54 PM : Creating ListInfo.xml
24/02/2007 9:49:04 PM : Reading ListInfo.xml
24/02/2007 9:49:07 PM : Writing ListInfo.ini
24/02/2007 9:49:07 PM : 1942 ParentROM:
24/02/2007 9:49:07 PM : 1942 NumPlayers: 2
24/02/2007 9:49:07 PM : 1942 NumButtons: 2
24/02/2007 9:49:07 PM : End
12 Seconds.

So this way of doing things it only takes time when you upgrade to a new version of Mame or run it for the first time, otherwise it takes less than a second to process.
« Last Edit: February 24, 2007, 07:58:42 am by headkaze »

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #69 on: February 25, 2007, 01:50:58 pm »
Do you think the Mame developers would be cool with adding "coindrop", "gamestart" and "gameover" events like they have with pause?

These would be cool for doing special effects when these events happen. Like user defined LEDWiz attract sequences or for LCD's you could have the message "GAMEOVER" written on them etc.

PowerMame for example had LEDWiz attract sequences during these events.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #70 on: February 25, 2007, 01:59:16 pm »
They might actually... aaron specifically updated the counter objects to avoid output use for coin dropping.

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #71 on: February 25, 2007, 02:12:19 pm »
Oh yeah never thought of that, that would open for abuse using coin counting. And we all know the drama that CoinDrop caused.

Hmm maybe just gamestart and gameover events then? Or perhaps only send the coindrop event the first time a coin is dropped in a game.
« Last Edit: February 25, 2007, 02:15:39 pm by headkaze »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #72 on: February 25, 2007, 02:32:19 pm »
If you can figure out how to do it... I honestly have no clue how powermame pulled that off.  I mean, mame just emulates the hardware and "plays" the rom.  I dunno how you detect when you are out of attract mode. 

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2942
  • 0x2b|~0x2b?
Re: MameInterop SDK v1.0 Released for Developers
« Reply #73 on: February 25, 2007, 02:42:16 pm »
PowerMame just used a timer for attract mode..

Quote
When a game starts up, attract mode will continue to execute until a button is pressed. There is also a timeout value that can be set. When the game has run for "timeout" seconds without controls being touched, it will start attract mode again until a button is pressed.

For the gamestart and coindrop events they could just be sent when those buttons are pressed. I guess there would be no way to detect a gameover sequence though.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #74 on: February 25, 2007, 07:14:16 pm »
Well you can't detect mamestart game start either without some serious hacking about in the memory.  See some games have cmos coinage so you can start a game without inserting coins (assuming there are some coins in the cache).  You'd have to read the current coinage, and I don't know how difficult that is.
« Last Edit: February 26, 2007, 12:01:31 pm by Howard_Casto »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #75 on: February 26, 2007, 12:54:00 pm »
just a quick update:

Loadman and I have finally sorted out the mala commands for the most part so a release will happen sometime this week.  I've been messing with the newly implemented read from script command to see what useful things I can do with it. 

Probably the most useful is to make a mamestart script and bind it to the mamestart output.  Inside I can do various cool things like light my start buttons up (seeing as how some mame games don't use coin lights) and do a little startup animation.  But the most practical thing you can do is use it in conjunction with the new shell function to launch an external app to light up your button lights for said game (like johnny 5 with the "-justlight" flag).  Since I've coded the app NOT to clear all the lights for ledwizzes and iowarrior based stuff, you can get your panel lighted this way and then still use extra outputs with the hooker to control coin lights and what-not.  It makes for a much smarter solution then to clutter the hooker app with all kinds of code to light your panel.

Also it means that your fe doesn't need support for these functions.

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4298
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: MameInterop SDK v1.0 Released for Developers
« Reply #76 on: February 27, 2007, 06:39:24 am »
Loadman and I have finally sorted out the mala commands for the most part so a release will happen sometime this week. 

Great work dude...

With your test ap the numbering differs from what is labled on the MaLa Boards and the  Modded Led-Wiz that use the same io-warrior40 chip

So we need to settle on how to deal with that

Here are four variations of io-warrior40 use as a LED controller that I am familiar with:




Here is table of what LED goes on when clicking on the appropriate button (labled 1-32) on your test ap:

The 1st column is Your Ap Button number
The 2nd column is how the Led is labled on the Mala Hardware board
The 3rd column is how the Led is labled on the Modded Led-Wiz

1  - 32 - 8
2 -  31 - 7
3 -  30 - 6
4 -  29 - 5
5 -  28 - 4
6 -  27 - 3
7 -  26 - 2
8 -  25 - 1
9  - 24 - 16
10 - 23 - 15
11 - 22 - 14
12 - 21 - 13
13 - 20 - 12
14 - 19 - 11
15 - 18 - 10
16 - 17 - 9
17 - 16 - 24
18 - 15 - 23
19 - 14 - 22
20 - 13 - 21
21 - 12 - 20
22 - 11 - 19
23 - 10 - 18
24 - 9  - 17
25 - 8  - 32
26 - 7  - 31
27 - 6  - 30
28 - 5  - 29
29 - 4  - 28
30 - 3  - 27
31 - 2  - 26
32 - 1  - 25

NOTE: Both the units above (2 and 4) that also drive a LCD display of course could only respond to 16 buttons (17-32) on your test ap as the other 16 are obviously used for the LCD.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #77 on: February 27, 2007, 10:07:11 pm »
Yeah the pattern is pretty apparent now....

For mala stuff I just need to reverse the pin order completely, this is simple enough to do, I can just step my function with a -1 when I "build" the binary array.

Now the ledwiz stuff uses the same bank order, but the pins in the bank are reversed.  This is a little odd, but still doable.  Makes me wonder why the pin order on "official" io warrior stuff is so different though.  I mean I can see it on the ledwiz hack, but not the mala stuff. 


Now here in lies the problem with me monkeying with the pins.  You see, all of these devices are going to show up as the same thing when I enumerate the hardware.  I have no way to determine which order to use, so the user will have to figure that out for themselves. 
« Last Edit: February 27, 2007, 10:08:54 pm by Howard_Casto »

loadman

  • Wiki Contributor
  • Trade Count: (+3)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4298
  • Cocktail Cab owner and MaLa FE developer
    • MaLa
Re: MameInterop SDK v1.0 Released for Developers
« Reply #78 on: February 27, 2007, 10:21:38 pm »
Yeah the pattern is pretty apparent now....

For mala stuff I just need to reverse the pin order completely, this is simple enough to do, I can just step my function with a -1 when I "build" the binary array.

Now the ledwiz stuff uses the same bank order, but the pins in the bank are reversed.  This is a little odd, but still doable.  Makes me wonder why the pin order on "official" io warrior stuff is so different though.  I mean I can see it on the ledwiz hack, but not the mala stuff. 


Now here in lies the problem with me monkeying with the pins.  You see, all of these devices are going to show up as the same thing when I enumerate the hardware.  I have no way to determine which order to use, so the user will have to figure that out for themselves. 

I think that it's just a labeling thing on the board. The chip behaves the same no matter what.

For the MaLa hardware I assume the numbering was deliberately reversed to simplify things. How you ask? Well if you use it as a 32 Led controller Pin 1 could drive Led 1. But if you use it as a LCD / LED controller Pins 1-16 are used  for that display so your first led would be 17. So to simplify things (Invisible to the user) it was reversed so no matter if you used a LCD or not Leds 1-16 would always be the same so you did not have to change your wiring or set-up.  My best guess anyway.  Swindus could confirm that I guess.

 In the case of the Wiz Mod the numbering on the board and the boards layout is for a different chip who's banks would by diffrent. I mean an easier fix is to just relabel the board with a pen to match MaLa H/W. (the reverse of your ap)   :-)

So even if you do nothing else it will be OK just as long as uses are aware.

Thanks again for supporting it
« Last Edit: February 27, 2007, 10:27:53 pm by loadman »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 16605
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: MameInterop SDK v1.0 Released for Developers
« Reply #79 on: February 27, 2007, 10:50:18 pm »
Well I've went ahead and took my function from the test app I sent you and intergrated it into the mame hooker app.  I then went ahead and made three seperate sets of functions, for the iowarrior, the mala board and a hacked ledwiz.  They re-number all the pins internally via a simple re-organization function. 

Now the tricky part is going to be reading the values (at least in my head). 

Let me explain...

See I figure for lighting panels at least, the ledwiz and iowarrior hardware are basically your only two chocies as they are the only popular devices with enough outputs.  Because we don't want to do compliacted things like light up the current game layout in the hooker app (see my post on it above) so what I do is leave the layout alone after the mamestart function is ran so that the layotu can be set via an external app and yet extra outputs on the device can still be used for mame-controlled outputs.  With the ledwiz this is simple, as you can set one led at a time (which is what I do) on the iowarrior stuff, however I have to basically set them all at once by maintaing a buffer. 

So I'll have to clear the iowarrior devices upon gamestart and then after the mamestart function is ran, I need to read all the states and update the buffers, so they don't all get turned off once I mame output flashes. 

I've gotta wrap my head around it, but it shoudn't be terribly hard. 

  
 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31