NEW: mednafen-0.6.1 (really fast and super-cool video game emulator)

[adamw@…]

mednafen-0.6.1

the portfile can be found here: ATTACHED

Description: Mednafen is a video game emulator. It emulates the Atari Lynx, GameBoy, GameBoy Colour, GameBoy Advance, NES, TurboGrafx 16, and SuperGrafx. And best of all, it does it a billion times faster than any other emulator I've found so far for MacOS X. It has no GUI but it's better that way.

Homepage: ​http://www.mednafen.com/

Comments: Beware: there's one file that takes a bazillion years to compile.

[adamw@…]

Portfile for emulators/mednafen

[adamw@…]

One more thing: I'm a FreeBSD committer but I'm still relatively new to the dports system. Any suggestions you can give me on improving this port are very welcome.

[markd@…]

Thanks a lot for contributing. It compiles fine but I made a few minor changes. For dependencies, we've switched to forcing port installs rather than just seeing of the libs are present. And I copied documentation with the port because that is a good idea. And for this port you really should tell people how to start the program via the command-line, or provide a sample mednafen.cfg because most people will have no earthly clue how to start the program and they are going to file bug reports asking how. I can't even figure out how but I presume you know so tell them via ui_msg's in post-activate. Just fill in the blanks in the modified portfile I attached, reattach it and we'll commit it.

[markd@…]

Updated portfile

[adamw@…]

Well, as far as the configuration file goes, it should be created automatically if it doesn't exist (failure to do so was a bug in the older 0.6.1 version, and has since been squashed).

Starting the program is as simple as mednafen /path/to/rom-file. Does that really need to be explicitly stated to the user? I mean, downloading a ROM is probably the most complex part, and one cannot advise users to do that.

Perhaps something to the effect of "To use mednafen, first obtain a ROM file for your favourite game (through legal means, of course), and then run \"mednafen /path/to/rom-file\"."

Good call on adding the documentation (I wish I'd thought of that!), but is installing the TODO really necessary?

And as for the libraries, are you completely sure about this? For example, it forces people to install a new version of zlib, does it not? I hate taking away the choice to use the system zlib from people. If you just request a zlib and you have a properly-defined ld search path then you can pick up a user zlib or a system zlib. I'll go with whatever the SOP for darwinports is, but I at least want to register my skepticism.

[markd@…]

(In reply to comment #5)

Starting the program is as simple as mednafen /path/to/rom-file. Does that really need to be explicitly stated to the user?

I think if the programmers had put a few extra words in the mednafen command help none of this would be necessary. But my goal is for people not to file unneccessary bug reports and waste our time. In the MacPorts community we just can't say RTFM! We're just not like that. :)

I mean, downloading a ROM is probably the most complex part, and one cannot advise users to do that.

Agreed.

Perhaps something to the effect of "To use mednafen, first obtain a ROM file for your favourite game (through legal means, of course), and then run \"mednafen /path/to/rom-file\"."

Yeah that's all I had in mind.

Good call on adding the documentation (I wish I'd thought of that!), but is installing the TODO really necessary?

Not really.

And as for the libraries, are you completely sure about this? For example, it forces people to install a new version of zlib, does it not? I hate taking away the choice to use the system zlib from people. If you just request a zlib and you have a properly-defined ld search path then you can pick up a user zlib or a system zlib. I'll go with whatever the SOP for darwinports is, but I at least want to register my skepticism.

That is the way we do it except for "core" stuff like NET-SNMP, Apache, and X11. In those cases we prefer to let users keep Apple's own stuff. Even in those cases there are usually variants so that users can install MacPorts NET-SNMP, for example, if they choose by specifying options because the ports are usually newer than Apple's stuff. But for people inexperienced with a given port it is best if the most predictable and stable option is the default for us to troubleshoot. It isn't a perfect solution or anything but it is a more predictable environment. The port author invariably makes some choices for users. If users disagree with the default choices or ask for more options the port can always be modifiedby popular demand.

So forcing MacPorts zlib (and others) is defintely the preferred way. On the other hand, I don't like to be in the position of telling our authors, who make this all possible, into doing things they object to. So if you really object to forcing the port installs, I could send a message to our developer list and they could probably give better answers than I can for the reasoning behind this preference. A variant could be added to not force installs but I don't think any other ports do it for all dependencies that way and I think the other developers wold object to that.

Well let me know what you think. I've attached a revised portfile with updated ui_msg's and removed TODO. See what you think.

[markd@…]

Updated portfile

[adamw@…]

(In reply to comment #6)

(In reply to comment #5) So if you really object to forcing the port installs, I could send a message to our developer list and they could probably give better answers than I can for the reasoning behind this preference. A variant could be added to not force installs but I don't think any other ports do it for all dependencies that way and I think the other developers wold object to that.

No, your logic sounds quite sound to me. I'm used to the FreeBSD system, where the default system comes with practically nothing, and we have direct control over the things it DOES come with. You're completely right that, if there is any problem with the system zlib, there's very little you can do to squash it.

Well let me know what you think. I've attached a revised portfile with updated ui_msg's and removed TODO. See what you think.

It looks great to me, and you've done a fantastic job on the ui_msg. The only problem is an extra space before the word "game" in the first line. Other than that, I'm quite pleased with the changes you've made.

[markd@…]

Ok, it is committed. Thanks for contributing and good work! I managed to run a game ROM myself. Pretty cool. Thanks for your patience; I think submissions may start to happen faster now.