Thanks for the bug report. I fixed this issue in svn (the logo file was moved to the icons subfolder during the gui/nogui merge). I'm not sure how the binary release is going to work with the new multiuser support. We may need to provide an install script to make sure everything gets copied to the right place.Also, I compiled from trunk and there is a really minor logo problem (i.e. a make error which was fixed by just # commenting out the cp for the logo. in the master Makefile) The big news is the recent speed improvement almost doubled my framerate under Glide64.
Mupen64-amd64 and RiceVideoLinux v1.1 is here
- Thread starter Richard42
- Start date
burpnrun,
Are you using a current distro and Kernel? If so, there's no need to install all those joystick calibration programs. In the older 2.6.18 Kernels I used to have to add joydev as a module to load at boot in YaST System Config Editor, but since 2.6.22 and OpenSUSE 10.3 this wasn't needed at all.
I use the same gamepad you do, and previously a Thrustmaster 2-in-1 Dual Trigger Rumblepad, and neither needed any kind of preparation or calibration like old midi port gamepads did. I simply plugged it in and it worked. KDE has a calibration and checking tool right in KControl but that simply confirms everything and I've never needed to go deeper into it and actually run the calibration in there. Gnome doesn't have that, but the Kernel driver still supports it and so the gamepad works regardless.
The only reason I need to check things in KControl or in /dev/input when in Gnome, is because I keep both the Logitech and my Adaptoid plugged in all the time and sometimes when the computer is started up the Kernel reverses the js0, js1 order of the pads (I keep the Rumblepad 2 as js0 and the Adaptoid as js1). In KDE when logged in I open Configure Desktop-Personal Settings (KControl on SUSE) and look in the KDE Components-Hardware-Joystick area to see which order the Kernel picked this time. If it's wrong I unplug them and plug them in with the Rumblepad first and that fixes the problem. If in Gnome I check in the /dev/input folder in the one that does the naming by name and make sure the Rumblepad is first. If not, again I just unplug them and plug them in in the correct order and things are fine. No calibration needed.
The Mupen64 joystick configuration works great as long as the system always uses the same joystick order (js0, js1) as when you originally set them in the GUI. As I check this in KControl or the dev folder at least once after a computer startup before playing any game that uses my gamepads that'll always be correct.
The jscalibrator stuff has been known to actually interfere with correct gamepad calibration. Some folks don't get things working properly until they uninstall that thing.
Are you using a current distro and Kernel? If so, there's no need to install all those joystick calibration programs. In the older 2.6.18 Kernels I used to have to add joydev as a module to load at boot in YaST System Config Editor, but since 2.6.22 and OpenSUSE 10.3 this wasn't needed at all.
I use the same gamepad you do, and previously a Thrustmaster 2-in-1 Dual Trigger Rumblepad, and neither needed any kind of preparation or calibration like old midi port gamepads did. I simply plugged it in and it worked. KDE has a calibration and checking tool right in KControl but that simply confirms everything and I've never needed to go deeper into it and actually run the calibration in there. Gnome doesn't have that, but the Kernel driver still supports it and so the gamepad works regardless.
The only reason I need to check things in KControl or in /dev/input when in Gnome, is because I keep both the Logitech and my Adaptoid plugged in all the time and sometimes when the computer is started up the Kernel reverses the js0, js1 order of the pads (I keep the Rumblepad 2 as js0 and the Adaptoid as js1). In KDE when logged in I open Configure Desktop-Personal Settings (KControl on SUSE) and look in the KDE Components-Hardware-Joystick area to see which order the Kernel picked this time. If it's wrong I unplug them and plug them in with the Rumblepad first and that fixes the problem. If in Gnome I check in the /dev/input folder in the one that does the naming by name and make sure the Rumblepad is first. If not, again I just unplug them and plug them in in the correct order and things are fine. No calibration needed.
The Mupen64 joystick configuration works great as long as the system always uses the same joystick order (js0, js1) as when you originally set them in the GUI. As I check this in KControl or the dev folder at least once after a computer startup before playing any game that uses my gamepads that'll always be correct.
The jscalibrator stuff has been known to actually interfere with correct gamepad calibration. Some folks don't get things working properly until they uninstall that thing.
Another minor bug report. I'm been playing around with making a native Qt GUI,
And noticed that the accelerator keys in our GTK interface don't work. Since we're creating them with menu_item_new_with_accelerator() I'm assuming we want accelerators.
Also, we don't seem to use any icon or hotkey convention. I'm not sure if there is a Gnome convention, but the GTK GUI should use it. I linked the icon paths to in my GUI so that they're now themable with the rest of the KDE / Qt apps.
Finally, and the reason for Kwrite to be open in the picture is I'm hitting a snag with the toolbar. I'd like the toolbar to be like the Kwrite toolbar, i.e. extend the length of the window and to have icons the same size. My icons are too small and not adjustable (there's a right-click menu which lets you make the icons bigger in Kwrite). This may be a Qt / KDE issue. Was wondering if anyone here knew the answer.
And noticed that the accelerator keys in our GTK interface don't work. Since we're creating them with menu_item_new_with_accelerator() I'm assuming we want accelerators.
Also, we don't seem to use any icon or hotkey convention. I'm not sure if there is a Gnome convention, but the GTK GUI should use it. I linked the icon paths to in my GUI so that they're now themable with the rest of the KDE / Qt apps.
Finally, and the reason for Kwrite to be open in the picture is I'm hitting a snag with the toolbar. I'd like the toolbar to be like the Kwrite toolbar, i.e. extend the length of the window and to have icons the same size. My icons are too small and not adjustable (there's a right-click menu which lets you make the icons bigger in Kwrite). This may be a Qt / KDE issue. Was wondering if anyone here knew the answer.
Last edited:
The Qt gui looks good so far. Thanks for working on it! Are you working with the latest svn code? I just want to make sure you're working with the code after I did the gui/nogui merge because a lot has changed. If you're working with code before the merge, then you may be doing more work than you need to. I pulled a lot of non-gui-specific code out of the gui_gtk dir and put it into the main/ dir for use by any gui, e.g. language translation functions and functions to read/write the mupen64.conf file. Most of the changes are summarized in this thread. If you have questions, PM me and I can give you more details.
Last edited:
I have the latest svn. I waited to begin in earnest till after your merge. I also will wait for multiuser and probably the next release before thinking about a real branch / merge for a Qt GUI.
Right now I'm working on just getting the widgets right, and this toolbar is a bit of an issue. There's little point in a Qt GUI if it looks worse than the GTK one with the Qt-GTK theme engine applied (nearly every person running KDE has the GTK libraries anyway) as right now both GUIs are functionally identical.
I'm not sure how GTK development works, but much of Qt is using Qt Designer. Basically making the GUI .ui files, actions, and signals and slots. The GUI above is a preview from the designer (sorry if it seemed that I was further along), so right now while the GUI is somewhat complete, compiles and GUI things like accelerators and hotkeys work, no real emulation functions are registered. Actually plugging the GUI into the emulator is the easy part.
I eventually plan on a gui_qt dir to parallel your gui_gtk one, and a flag to pick which GUI to build.
My biggest question is how should we handle the plugin GUIs. Our plugin_exec_x() way of calling plugin registered functions leaves a lot to be desired. Not only do most plugins not have an About or Test, so instead of a default "Not yet implemented box." we get nothing, but it means there is only one GUI for the plugin. Right now if I was to make my Qt GUI, Rice and Glide would still have GTK configs, and Blight's is SDL. This is not ideal. A more extensible plugin API is needed. Ideally plugins should also not depend on GTK / Qt / SDL #defines either, meaning one could use binary plugins with either a GUI or non-GUI build. Sadly this is some major work.
Right now I'm working on just getting the widgets right, and this toolbar is a bit of an issue. There's little point in a Qt GUI if it looks worse than the GTK one with the Qt-GTK theme engine applied (nearly every person running KDE has the GTK libraries anyway) as right now both GUIs are functionally identical.
I'm not sure how GTK development works, but much of Qt is using Qt Designer. Basically making the GUI .ui files, actions, and signals and slots. The GUI above is a preview from the designer (sorry if it seemed that I was further along), so right now while the GUI is somewhat complete, compiles and GUI things like accelerators and hotkeys work, no real emulation functions are registered. Actually plugging the GUI into the emulator is the easy part.
I eventually plan on a gui_qt dir to parallel your gui_gtk one, and a flag to pick which GUI to build.
My biggest question is how should we handle the plugin GUIs. Our plugin_exec_x() way of calling plugin registered functions leaves a lot to be desired. Not only do most plugins not have an About or Test, so instead of a default "Not yet implemented box." we get nothing, but it means there is only one GUI for the plugin. Right now if I was to make my Qt GUI, Rice and Glide would still have GTK configs, and Blight's is SDL. This is not ideal. A more extensible plugin API is needed. Ideally plugins should also not depend on GTK / Qt / SDL #defines either, meaning one could use binary plugins with either a GUI or non-GUI build. Sadly this is some major work.
Most of my input issues had to do with Blights input plugin SDL configuration screen. So it would be most welcome if a Qt GUI could be created for it.
I think that's the most logical way to do it, and I would suggest including the special files used by Qt Designer in the gui_qt folder (maybe in a subdir). Judging by the code I've looked at, the GTK gui was all written by hand.I'm not sure how GTK development works, but much of Qt is using Qt Designer. Basically making the GUI .ui files, actions, and signals and slots. The GUI above is a preview from the designer (sorry if it seemed that I was further along), so right now while the GUI is somewhat complete, compiles and GUI things like accelerators and hotkeys work, no real emulation functions are registered. Actually plugging the GUI into the emulator is the easy part.
I eventually plan on a gui_qt dir to parallel your gui_gtk one, and a flag to pick which GUI to build.
I agree that there are issues with each plugin having to implement its own gui. I don't see a simple, extensible solution to this that's worth all the effort it would take. We may just have to go the route of implementing separate gui's for each plugin that we package with mupen64plus and pass an option to the top-level Makefile determining which gui to build. I know this isn't great, and I'm open to better ideas.
I'm glad to hear a request for this as I was planning to rework the blight input configuration gui to use GTK (and not 80% of the CPU
). I'm going to try to preserve the controller diagram, but add nice things like real checkboxes and enhance the plugin so you can also map higher level functions like exit, fullscreen, statesave, etc to controller buttons. Obviously this won't happen before the upcoming release of mupen64plus, but I'm shooting for getting that into the following release.I'm thinking the easiest thing is to change the API slightly. Mandate that the plugin register more GUI info, like which GUI options it has callbacks for, which toolkit they use, and pointers to them. The main program can then pick the best one, or if there is none, push a standard "Not implemented" dialogue. The current, search the plugin for the handle at runtime leaves a bit to be desired.I agree that there are issues with each plugin having to implement its own gui. I don't see a simple, extensible solution to this that's worth all the effort it would take. <snip>I know this isn't great, and I'm open to better ideas.
This should help in getting out the pad data:
SDL_SaveBMP (SDL_Surface *surface, const char *file);
Hopefully this implement's .bmp's alpha properly. I'll use krita to change it into an svg (what Qt likes). You should be able to do the same to get something for GTK.
I guess I'll also tackle Rice's while I'm at it. It seems a big pain to made multi-tabbed GUIs in GTK by hand, which is why I guess we have one big panel. The Rice for Project64 has a much better interface (some more options which may or may not apply, yet - I haven't checked) which shouldn't be too hard to reconstruct via Qt.
Thanks for the tip. I was able to extract the image to a bmp. The alpha channels didn't work properly, but I used the GIMP to manually remove the background. Here's the image converted to a png in case anyone else ever needs it:
Last edited:
For the gui options (I assume you're talking about config/test/about), a simpler implementation that doesn't require changing the API would be to just remove the DllConfig/DllTest/DllAbout function definitions from any plugins where the functions are currently just stubs. Then the mupen64 code will know which ones are supported based on whether the function is there or not.
I like the idea of adding GUI toolkit info to the API though. Maybe we can modify the plugin info struct to provide a predefined bitfield indicating which GUI toolkits are supported. Then we can add an API call to set which toolkit the plugin should use.
i have little problems with SDL
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libpng.so when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libpng.a when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: cannot find -lSDL
but all libsdl installed
http://sl1pkn07.no-ip.com/imagenes/libsdl.png
http://sl1pkn07.no-ip.com/imagenes/libsdl2.png
greetings
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libpng.so when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libpng.a when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: cannot find -lSDL
but all libsdl installed
http://sl1pkn07.no-ip.com/imagenes/libsdl.png
http://sl1pkn07.no-ip.com/imagenes/libsdl2.png
greetings
Last edited:
- Thread Starter
- #72
Looks like you're trying to build a 32-bit version of Mupen64 but only have the 64-bit development libraries installed, or vice versa.
aaa. sorry ><. im using "all" flag.
works with "bin-64" flag
(make VER=1.1.svn.254 bin-64 PREFIX=/usr)
EDIT: yes i have install SDL 32bits:
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn$ ls /usr/lib32/libSDL*
/usr/lib32/libSDL-1.2.so.0
/usr/lib32/libSDL-1.2.so.0.11.0
/usr/lib32/libSDL_mixer-1.2.so.0
/usr/lib32/libSDL_mixer-1.2.so.0.2.4
/usr/lib32/libSDL_ttf-2.0.so.0
/usr/lib32/libSDL_ttf-2.0.so.0.6.3
/usr/lib32/libSDL_net-1.2.so.0
/usr/lib32/libSDL_net-1.2.so.0.0.5
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn
works with "bin-64" flag
(make VER=1.1.svn.254 bin-64 PREFIX=/usr)
EDIT: yes i have install SDL 32bits:
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn$ ls /usr/lib32/libSDL*
/usr/lib32/libSDL-1.2.so.0
/usr/lib32/libSDL-1.2.so.0.11.0
/usr/lib32/libSDL_mixer-1.2.so.0
/usr/lib32/libSDL_mixer-1.2.so.0.2.4
/usr/lib32/libSDL_ttf-2.0.so.0
/usr/lib32/libSDL_ttf-2.0.so.0.6.3
/usr/lib32/libSDL_net-1.2.so.0
/usr/lib32/libSDL_net-1.2.so.0.0.5
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn
Last edited:
- Thread Starter
- #74
Actually this is deprecated now. You should check out and build the Mupen64Plus project instead. Our new home page is:
http://code.google.com/p/mupen64plus/
While I wasn't able to get much coding done, here's my new controller image:
for use in the Gtk GUI. I'm planning on making the KDE GUI for blight, but if someone else has more free time and wants to do it now, feel free.
Also, feel free to give me comments on how it can be improved. I think its 95% there, but still needs a little more tweaking to be perfect. I also need to make the arrow overlays. (which will be a seperate graphic)
P.S. It seems the shadow on the bottom got cut off somewhere. This can be fixed by copying from one of the other curved and streching slightly. Sorry.
for use in the Gtk GUI. I'm planning on making the KDE GUI for blight, but if someone else has more free time and wants to do it now, feel free.
Also, feel free to give me comments on how it can be improved. I think its 95% there, but still needs a little more tweaking to be perfect. I also need to make the arrow overlays. (which will be a seperate graphic)
P.S. It seems the shadow on the bottom got cut off somewhere. This can be fixed by copying from one of the other curved and streching slightly. Sorry.
Last edited: