View Full Version : New Mupen version???
jogibear9988
October 12th, 2007, 14:46
Is it planed to release a new Mupen Version in the future?
I see so many patches floating arround in this forum, and i need the no_gui version for use with mythtv! maybe hactarus, you have the time to create a new version with all patches includeed?
Surkow
October 12th, 2007, 17:44
I think there is no new version but one of the members worked on a 64bit Linux build. Having a command line version of Mupen64 would be a cool feature which would make different frontends possible.
GarulfoLinux
October 12th, 2007, 22:26
A new version of Mupen64 is planed yes. Hacktarux works on cheat system and i think there will are other changes.
kdubya
October 13th, 2007, 00:52
jogibear9988 I am using it with myth, there is only one patch you need to apply. It was really easy. Actually its the only patch I have ever applied to any code ever.
This is the only patch you should need... http://www.emutalk.net/showthread.php?t=33833 ... for whatever reason the "-c" option runs slow for me, just like the guy says in the thread, so you have to put in all the plugin options in the command to start the emulator that you put into mythgame.
aside...
I love that Mupen lets you quit just be hitting escape. To get out of fakenes takes 4 freaking keystrokes, which is a complete pain in the ass from the standpoint of someone that doesnt want a keyboard in the livingroom. Why do so many emulators have elaborate GUIs.. you only need to set up all that crap once, then after that you should be able to get in and out quickly.
Doomulation
October 13th, 2007, 12:00
...Why do so many emulators have elaborate GUIs.. you only need to set up all that crap once, then after that you should be able to get in and out quickly.
Because otherwise the entire computer scene would only be kept afloat by savvy users like you who hates GUI.
All the casual users would stay a 1000 kilometers away from computers and that's never a good idea. Welcome to the future. Welcome to GUIs.
NOTE: Don't get me wrong. I'm all FOR GUIs instead of AGAINST. If it were for me, it would be law that all applications must have a GUI.
_Zack_
October 13th, 2007, 15:06
If it were for me, it would be law that all applications must have a GUI.
I second that :P
Surkow
October 13th, 2007, 15:12
I would rather think it's best to have a nice working backend (an API) that frontends can use. The core shouldn't need a GUI to do it's job.
Doomulation
October 13th, 2007, 17:42
True enough, but then there HAD to be an official frontend that existed. And defining an API is trickier than incoporating a GUI directly.
Toasty
October 13th, 2007, 22:15
How about programs that have GUIs that can be optionally invoked with a CLI option that disables the GUI? Eh??? :P
kdubya
October 14th, 2007, 00:00
How about programs that have GUIs that can be optionally invoked with a CLI option that disables the GUI? Eh??? :P
Winner!
Thanks for getting the point. No one said no gui at all.
I did a nice job of destroying this thread
Doomulation
October 14th, 2007, 00:19
How about programs that have GUIs that can be optionally invoked with a CLI option that disables the GUI? Eh??? :P
No. GUI by default and an optional switch for no GUI and CLI options, if needed!
Toasty
October 14th, 2007, 02:08
That's what I meant. Now that I look back at the way I worded it I can see how it might have been misleading. I meant the programs can be invoked that way - not the GUIs. English is so cool.
nmn
October 14th, 2007, 20:16
There already is a mupen64_nogui binary when you build from source, you know. I've tried, i always get a binary alongside with "_nogui" attached, and i never applied a patch. Weird.... That, or my memory is REALLY bad.
Anyways...
I don't see why we need something like a "libmupen64" but i also don't find it a bad idea. Maybe its in Mupen64's future somewhere... But then again, there is no real reason you can't just write a GUI into the source code.
I believe a GUI is important, not only for those who are new to PCs, but to those who are experts. GUIs can make debugging quicker or occasionally more useful. I think Mupen64s recursive ROM browsing feature is the greatest thing since sliced bread. Also, GUIs, a lot of times, can make work less tedious, just as a terminal does for other things. I'll tell you right now i would've destroyed my file systems multiple times if i did all of my partition work from the command line. I've done some from it, and I'm certain I couldn't do much more... Plus, Isn't configuring plugins so much better in GTK then say, a few dialog commands or a ncurses GUI could ever get, even though technically both are GUIs? Because, I know INI/file based options are nice, but they aren't very well/portable if you want to make it work in real time. Gconf? Yeah, its alright, but isn't that mainly for Linux, and isn't it tedious to edit Gconf keys on the command line anyways? Eh, I guess the point is, GUIs are and always will be important. Terminals aren't important all the time anymore, but they come in use a lot for those who know how to use them!
Surkow
October 14th, 2007, 21:08
I haven't tried compiling Mupen64 myself so I didn't know a "nogui" version was created alongside it after compiling. I agree that the GUI certainly is useful and writing a GUI in the source code is a lot easier than creating a library. Besides users wouldn't that happy to be forced to use the commandline because they aren't used to it.
I was rather thinking about being able to use different frontends when you have something like "libmupen64". For example SMPlayer (http://smplayer.sourceforge.net/en/index.php) is a frontend for MPlayer (a media player) even though MPlayer itself already has a GUI (besides the command line options). The reason for creating such a frontend can be that the current GUI of a program does not offer what you need (imagine different toolkits used), is too difficult to maintain or is just too old.
nmn
October 14th, 2007, 21:38
Uhh... Mplayer is a movie player and I'm very familiar with the concept of it.... It does have an official GUI, its just not default on. The reason why its GUI is not attached to it is because of its background though - a frame buffer movie player would definitively not have that sort of thing, or at least shouldn't.
Powered by vBulletin® Version 4.1.10 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.