"Middle-End thoughts" (For FE authors)

[Howard_Casto]

Raging Dragon's code is getting a tad bloated, so I've decided to make some fucntions external, which might be of some interest to other FE developers.....

Here's what I'm a gonna do......


I'll start out with impact simply because it's the smallest....

I'll compile a small little ImpactLauncher.exe that'll go in your impact diectory.  
I'll handle all simulated keypresses, game selection, ect.....

to launch a impact game you'll simply point to this exe like you were launching mame.

so to launch street fighter ex you would run:

ImpactLauncher.exe -sfex

Ok but what about exiting?  

Well for default, it'll exit you out if you press the "Esc" key, but if you want to choose another key then you can pass it like this:

ImpactLauncher.exe -sfex -56

where 56 is the keycode of a key (a list of available keys and their code would be included)

So what do you think guys? Is this a good idea?   Would you fe authors be willing to add support for otehr emus if i made it this easy and we had a univeral database to pull other info from?
(see the threads on a open source fe)

[Dave Dribin]

I think that's an awesome idea!  Wrapping emulators that do not have command line interfaces would be very valuable to FEs that only work with a CLI.  I do not have enough Windows knowledge to do this myself, so this would be saving me a ton of time.  Lemme know if I could help out in any way.

-Dave

[Mike]

I think if I'm write this is written in VB correct howard?

[)p(]

So what do you think guys? Is this a good idea?

[Lilwolf]

GREAT IDEA (now who was pestering you for that one  )

Would it make more sense to make a generic one?

something like

gamelauncher impactemu.exe c:\emu\impact -init,53,12,34 -57-12,34,57

so it would init, then send a 53, then a 12, then a 34 (or maybe a 53, wait 12 seconds, and 34?).
then if it sees a -57, it will convert it to a 12 then a 34, then a 57 (or 12, wait 34 seconds and a 57)?

I cant' think of a good command line off hand, but it seems like something could work.

[Howard_Casto]

I think if I'm write this is written in VB correct howard?

Yup    Before you all start moaning and goaing think about it.....  These emus are windows only, so cross-platform comp isn't really an issue.  Also it's simply api calls and I would release the source so if anyone wanted to modify it to work on their favorite non-command line emu they could.  Also if they just hate vb they could port it to C or whatever they like, although a "bug" in vb makes it realitively easy to do in vb, whiel it takes a tad more code to get the passing to occur in c++. (not really much code, just a timer and a case statment, the rest is api, but c++ would need an additional api to send the keys without a form)

Great Idea Howard...there are emulators that I just don't use so adding functionality for them is veruy low priority.  
In Emulaxian you can directly use it...create a custom gamelist and set one general commandline option for the the keycode and it will work as it is now

Yeah that's the idea.... one suggestion though... what would take all of maybe a half a line of code would be to make sure when users launch via these apps, you pass along whatever key is used to exit your fe, to the launcher.... That just complicates things less for the user's setup.  (only one exit key they have to worry about)

GREAT IDEA (now who was pestering you for that one  )

Would it make more sense to make a generic one?

something like  

gamelauncher impactemu.exe c:\emu\impact -init,53,12,34 -57-12,34,57

so it would init, then send a 53, then a 12, then a 34 (or maybe a 53, wait 12 seconds, and 34?).
then if it sees a -57, it will convert it to a 12 then a 34, then a 57 (or 12, wait 34 seconds and a 57)?

heh,  gee I wonder?    Actually I thought about that one and decided against it simply because if the fe has to keep track of all these keystrokes (or even a text/script file) then it complicates things and defeats the purpose.  What I might do however is make available a Vb "template"  which would allow programmers to simply follow along, make a case statment, fill in the keypresses for each and compile... your ready to go!  and if you distribute it, no one ever has to do it again!

I could add one more option though...... in impact, modeler, and im assuming final burn.... what happens is an inital set of keys is sent (to set focus on the list and select the first item)  and then one key is repeated a numer of times to select the game(usually the down key) and then a series of keys is pressed to start........  What I could do is have an option which tells you how many keys to press in the middle step, just in case a new game is added or the list is re-arragned.  If the option is omitted, it would use the internal case statment to determine what game to select..... That way if these aren't kept up they would still be functional and realitively easy to use.  

Of course if a text file was setup in the format listed above, then It would be fiarly easy to make custom emu setups and lists for them.  The only problem is im not sure if vb allows dynamically generated case statments. (each emu would have a diff number of games, which could have a number of keypresses associated with each game name, specified in the text file)

Also I had one more idea that popped into my head this morning.  I would need considerable help with this one, but the plus side is it could double as research for the universal database we've been discussing.  

Anyway, my idea is.... if were gonna do it, then lets do it all the way.  You know all of those nifty command line switches you can send to mame to output various information?  Why not include those in the wrapper as well?  All I would need would be info on the games (year manufacturer, ect) which could be found  on KLOV and other sources fairly easily.  Then there would be none of this "My fe only supports xyz"  if everything is exactly like mame, then, in theory with these external modules EVERY FE supports EVERY emu that has a module built for it!!

Now how sweet is that?


Also we could compile mameinfo/history dats for various emus as well, in the same format as the mame one's use.  As I said all of the info gathered could be contributed to the database project as well, so we woudl be killing two birds with one stone.  

Sound good?