Topic: MK Community needs the Wolf Unit Driver

[Athelstone]

I don't often post here but just wanted to say that I'm impressed with the passionate support you guys are giving.

[Konqrr]

Unfortunately, supporting Mortal Kombat and sequels in FBA is far from trivial. It requires support for several CPU cores (some of which are unlike any currently in FBA), and support for all sorts of other things such as timers and new sound cores. We're not shy of taking on big tasks but none of us are particuarly big fans of the MK series so I really wouldn't hold your breath waiting for a driver. That's not to say never - it's just very unlikely!

I'm sure that others like myself would be willing to donate to the cause.  I know something like this is a huge daunting task when you already have a successful emulator, but you can make it so much better by adding a whole new community to it!

You have my support.  MK for life.

[9.95]

I'm sure that others like myself would be willing to donate to the cause.  I know something like this is a huge daunting task when you already have a successful emulator, but you can make it so much better by adding a whole new community to it!

You have my support.  MK for life.

Konqrr, you took the words out of my mouth.  I'm sure that we could certainly get players to donate to this cause to make it worth your time to add MK to FBA.

[REO]

this would be sick.

[Gerchap]

This goes to the big guys from here:

As for right now this can't be possible right,

If it has to do with financial issues let me know, I can donate and set up a donation program at my Site

Contact me if this makes sense

Thanks,
Gerchap
MoralKombatUnited.com

[styroteqe]

I for one know that there are plenty of players around that would love to see this happen.  Currently the only means of playing MK requires players to either buy two consoles (PS3 and 360), or be forced to play on mame where there are several problems on any emulator that you choose.  (Sound distortion, inability to access complete character roster easily, inefficient use of the roms which causes slowdown).

I concur. The MK Kommunity is vast and could use the ability to play via GGPO. There are a great deal of players out there who are frustrated due to the above mentioned issues and more which plague the attempts to play a stable match online. We've seen what great leaps have been made with other klassik 2d fighters being emulated via FBA and played on GGPO/2df. We would like to enter the fold.

If there is anything we can do to help facilitate this development and a port of the Wolf Unit code to FBA, please let me/us know. I work for a software development house and can offer some very powerful hardware for you guys to build on. Consider it a donation to your project.

-styroteqe
 

[9.95]

I will also discuss with Shock and Scheisse, as well as Storms the possibility of setting up donation funds on Ultimatemk.com, Classicmk.com, and Mortalkombatempires.com in order to help make the time worth your while.

-Phil

[Barry Harris]

I will also discuss with Shock and Scheisse, as well as Storms the possibility of setting up donation funds on Ultimatemk.com, Classicmk.com, and Mortalkombatempires.com in order to help make the time worth your while.

-Phil

I would never accept donations for my time. It is unfair to all those who have worked on MAME (which would be used as a reference) and I also don't want the pressure of having to deliver results (I have a job and a young family - that keeps me busy enough!). It is also unfair on anyone who has worked on FBA in the past.

You should probably not be expecting a magic boost in speed over MAME should an FBA driver exist. We would use the cores from MAME to get it up and running. If it's slow it's because it is demanding - porting it to FBA would not change that.

[9.95]

I would never accept donations for my time. It is unfair to all those who have worked on MAME (which would be used as a reference) and I also don't want the pressure of having to deliver results (I have a job and a young family - that keeps me busy enough!). It is also unfair on anyone who has worked on FBA in the past.

You should probably not be expecting a magic boost in speed over MAME should an FBA driver exist. We would use the cores from MAME to get it up and running. If it's slow it's because it is demanding - porting it to FBA would not change that.

The game runs, speed wise, just fine... but there are just somethings that aren't the greatest with MAME in general, such as being so user-unfriendly and so bad regarding netplay with kaillera.  I think that one of the biggest things that all of us are so interested in, is seeing it get supported by FBA so that it would have better netplay via 2df/supercade and GGPO.  Currently, p2p kaillera is not the best, its better than normal kaillera, but there are so many problems, whereas 2df/supercade and GGPO are so user friendly and the netplay is so fast and so smooth that it's very attractive to anyone who uses them... including MK players.

[Haze]

This thread is hilarious....

If MK were added to FBA it would be using MAME's cores, the game is entirely driven by the CPU + framebuffer and it would run *exactly* the same speed as it does in MAME using the same cores.  FBAs video functions etc. are faster, but MK wouldn't be using them as the game(s) aren't tile or sprite based.

Just how many accounts do you need to create to beg for something?....  I strongly suspect there are other reasons behind this, maybe some see FBAs licensing as more lax, but in reality if they just copy cores directly from MAME they're subject to the MAME license anyway unless special permission is granted.

Don't the FBA dev team also consider all these netplay solutions you mention illegal, as most of them are only providing binaries and no source?  you're not going to get much support here if that's the case, as I believe that was mentioned in other posts.  MAME is hostile to netplay for a reason, most of the people developing these 'solutions' seem to think they're above any licenseing terms (in the name of anti-cheating), and implement things as such god-awful hacks they're not worth considering.  If somebody does it RIGHT I'm sure MAME will get some form of netplay which doesn't make it one giant security risk.  That said there may still be objections to it because such things do attract a very annoying obsessive 'fan-boi' like usergroup, I honestly can't think of any examples to show you what I mean by that, but I'm sure you can find some.


 

[iq_132]

If MK were added to FBA it would be using MAME's cores, the game is entirely driven by the CPU + framebuffer and it would run *exactly* the same speed as it does in MAME using the same cores.  FBAs video functions etc. are faster, but MK wouldn't be using them as the game(s) aren't tile or sprite based.

Agreed. Though I imagine fba will be slightly faster given less overhead. Though, I'm fairly certain they aren't worried about speed as much as the fact that the only way they can play it online right now is with a decrepit old MAME build with kaillera.

Just how many accounts do you need to create to beg for something?....  I strongly suspect there are other reasons behind this, maybe some see FBAs licensing as more lax,

It is in really only more lax one way -- we allow linking to closed-source dlls. Other than that, our license is very similar to MAME's in what it requires.

but in reality if they just copy cores directly from MAME they're subject to the MAME license anyway unless special permission is granted.

Which we will be seeking sooner rather than later.

Don't the FBA dev team also consider all these netplay solutions you mention illegal, as most of them are only providing binaries and no source?  you're not going to get much support here if that's the case, as I believe that was mentioned in other posts.  MAME is hostile to netplay for a reason, most of the people developing these 'solutions' seem to think they're above any licenseing terms (in the name of anti-cheating), and implement things as such god-awful hacks they're not worth considering.

I honestly have never heard of 2df, but I imagine you are correct.  GPPO, up until last week was off-limits for discussion here as well.  They have agreed to release their sources to their fba build. We did not ask them to release the sources to their closed-source dlls.

If somebody does it RIGHT I'm sure MAME will get some form of netplay which doesn't make it one giant security risk.

I have suspicions about that? Your own comment about "fanbois" and the like is exactly why I don't see anyone on the MAMEdev team being willing to put any sort of effort into seeing a netplay option.

[Haze]

Agreed. Though I imagine fba will be slightly faster given less overhead. Though, I'm fairly certain they aren't worried about speed as much as the fact that the only way they can play it online right now is with a decrepit old MAME build with kaillera.
It is in really only more lax one way -- we allow linking to closed-source dlls. Other than that, our license is very similar to MAME's in what it requires.
Which we will be seeking sooner rather than later.
I honestly have never heard of 2df, but I imagine you are correct.  GPPO, up until last week was off-limits for discussion here as well.  They have agreed to release their sources to their fba build. We did not ask them to release the sources to their closed-source dlls.
I have suspicions about that? Your own comment about "fanbois" and the like is exactly why I don't see anyone on the MAMEdev team being willing to put any sort of effort into seeing a netplay option.

Nobody on the team is likely to put in any effort, it's not a primary concern, however if an external solution was available which was compatible, and implemented properly then I imagine it would be considered.

I haven't studied the FBA license, but the key thing about the MAME one is the no-commerical use clause, otherwise it's basically the BSD license.  The no-commercial use clause is rather important tho, and a fair few devs (especially ones behind the sound cores like Jarek) have in no uncertain terms stated that they don't want their code used in any commercial product, or used in a commercial way.  I share the same opinion, and unless it's a request from the original manufacturer I don't expect nor want any code I've written, nor code derived from that being used for commercial purposes.

The reason I'm suspicious is because there was a thread on another forum recently along similar lines where somebody was trying to get people to port drivers to other things like Raine and FBA in order to avoid the MAME no-commercial clause (MK was mentioned in that too).  If this was to become the norm I imagine you'd end up with various demands to remove all MAME-sourced code from FBA, or ensure you were fully license compliant which would basically mean adopting the MAME license (or seek the individual authors of each piece of MAME code you used and get them to agree to relicence it for you).  The CPS3 driver for example is heavily derived from my code, to the point of it having the same comments, so I don't think there is much of a legal argument as to where it came from ;-)  The only reason nobody has done this so far is because nobody on the team feels like being an asshole to a project which is both interesting and gives people an alternative to use and learn with.

[Barry Harris]

Agreed. Though I imagine fba will be slightly faster given less overhead. Though, I'm fairly certain they aren't worried about speed as much as the fact that the only way they can play it online right now is with a decrepit old MAME build with kaillera.
It is in really only more lax one way -- we allow linking to closed-source dlls. Other than that, our license is very similar to MAME's in what it requires.
Which we will be seeking sooner rather than later.
I honestly have never heard of 2df, but I imagine you are correct.  GPPO, up until last week was off-limits for discussion here as well.  They have agreed to release their sources to their fba build. We did not ask them to release the sources to their closed-source dlls.
I have suspicions about that? Your own comment about "fanbois" and the like is exactly why I don't see anyone on the MAMEdev team being willing to put any sort of effort into seeing a netplay option.

The license is very similar - and commerical use is strictly prohibited. As iq said the main difference is in allowing linking to non-emulation related dlls, eg, netplay libs. The way I see it, allowing this takes the netplay crowd away from MAME to some extent.

We have been actively seeking license compliance recently. FBA Shuffle is apparently dead, GGPO has released their code (bar the netplay DLL). I had never heard of 2df either, although I did look into more on Friday and I will be contacting them when I look into it further.

If MAMEdev preferred, I personally have no objection to changing the dll policy to just dlls we give permission to (and I don't mind contacting MAMEdev to ask about obtaining permission on a dll basis either). I wouldn't want to completely remove dll linking as I do think it does some good taking some (most?) netplay away from MAME. That said if the only way the project could survive was to adopt the MAME license then it is something we would more than likely accept and adhere too.

[Haze]

The license is very similar - and commerical use is strictly prohibited. As iq said the main difference is in allowing linking to non-emulation related dlls, eg, netplay libs. The way I see it, allowing this takes the netplay crowd away from MAME to some extent.

We have been actively seeking license compliance recently. FBA Shuffle is apparently dead, GGPO has released their code (bar the netplay DLL). I had never heard of 2df either, although I did look into more on Friday and I will be contacting them when I look into it further.

If MAMEdev preferred, I personally have no objection to changing the dll policy to just dlls we give permission to (and I don't mind contacting MAMEdev to ask about obtaining permission on a dll basis either). I wouldn't want to completely remove dll linking as I do think it does some good taking some (most?) netplay away from MAME. That said if the only way the project could survive was to adopt the MAME license then it is something we would more than likely accept and adhere too.

That's alright then, all I can say is that from a legal point of view if you're using MAME code you should technically also be using the MAME license. 

Aaron himself isn't that big on the no-closed DLLs approach but it has a few advantages, including preventing people from writing closed source emulation cores, and linking them with the project, or closed-source DRM based 'protection' schemes and offering ROMs complete with versions of MAME we can't support.  It also helps keep the code multi-platform, as closed libs are by their nature often windows-only (and if you combine this with the previous point, would not be good for the project at all).  It's not only an anti-netplay thing, it's about keeping MAME open and ensuring the developers always have access to all the code, and won't become tied to something which can't be developed, can't be debugged, can't be fixed, and can't be ported.  (A critical security vulnerability in something like a netplay lib would become a critical vulnerability in MAME beyond the developers control)

That's the reasoning why I've always insisted such clauses are a good thing, and for a project where the primary goal is documentation and everything benig open I feel it's important to stick to it.

I doubt anybody is going to force you to adopt the license, because as I said the team generally aren't going to be assholes about such things as long as the code isn't being abused, but from a legal point of view you should almost certainly be using the MAME license if you're using MAME code or code which has been adapted from MAME code, which you are.

[Barry Harris]

That's alright then, all I can say is that from a legal point of view if you're using MAME code you should technically also be using the MAME license. 

Aaron himself isn't that big on the no-closed DLLs approach but it has a few advantages, including preventing people from writing closed source emulation cores, and linking them with the project, or closed-source DRM based 'protection' schemes and offering ROMs complete with versions of MAME we can't support.  It also helps keep the code multi-platform, as closed libs are by their nature often windows-only (and if you combine this with the previous point, would not be good for the project at all).  It's not only an anti-netplay thing, it's about keeping MAME open and ensuring the developers always have access to all the code, and won't become tied to something which can't be developed, can't be debugged, can't be fixed, and can't be ported.  (A critical security vulnerability in something like a netplay lib would become a critical vulnerability in MAME beyond the developers control)

That's the reasoning why I've always insisted such clauses are a good thing, and for a project where the primary goal is documentation and everything benig open I feel it's important to stick to it.

I doubt anybody is going to force you to adopt the license, because as I said the team generally aren't going to be assholes about such things as long as the code isn't being abused, but from a legal point of view you should almost certainly be using the MAME license if you're using MAME code or code which has been adapted from MAME code, which you are.

Agreed on all - that's why I deliberately said non-emulation dlls. Anything emulation related (CPU cores, etc.) should all be distributed as code if they are utilised by any FBA build. It would be grossly disrespectful in my opinion to not share such things with the community.