libSDL_ttf dependency

[ebenblues]

We have an issue opened right now because blight_input doesn't load if libSDL_ttf is not installed on the system. Most systems have this installed, but fedora is the exception that we've seen. The solution was going to be to remove the blight_input dependency on SDL_ttf, but it appears I may still need it, even with the gtk gui. When you actually set a controller button, you still need an SDL window to pop up to capture the controller button. It seems to make the most sense to have the SDL window look like a dialog that says "press key or controller button to map to button X" or something like that, in which case I'd still need SDL_ttf.

Also, I'd like to make an enhancement to be able to draw temporary text on the screen during emulation to display helpful messages. Right now, if you change the statesave slot while playing a game, there's no feedback as to whether the slot change worked. I'd like to be able to write "Save Slot X" on the bottom of the screen so the user has some confidence that it worked. I've also added support for adjusting the volume during gameplay too, which also seems to require some kind of feedback written to the screen. SDL_ttf seems like the best way to perform the actual drawing of the text to the emulation screen.

So the solution to the issue seems to be to modify the makefile so SDL_ttf becomes a requirement to building mupen64plus rather than trying to remove any dependencies on it. Thoughts?

 

[okaygo]

I think it's only fair that some packages be required, however if we make it a dependency we should include a readme on how to install it.

 

[Tillin9]

I agree having fullscreen messages is a good feature. I honestly think some other things should be on the TODO first, but it should be there too. Look at Project64 1.7's implementation here: http://www.pj64-emu.com/blog/198-features.html

As far as the Blight input GUI, I'd have all the GUI stuff in gtk and if a separate SDL thread was needed to capture the input, make it hidden and pass the values to the GUI. This would be most extensible, so my Qt GUI could use it as well. I know its easy to say this, I'll have to work on it when I get there, so let me know if it seems really difficult and maybe I can lend a hand.

As far as the fullscreen I actually don't know the best way to do text. OpenGL has no built-in text ability and whenever I needed to do text I more or less use GLUT. I'm hesitant to require libSDL_ttf since its not just Fedora that doesn't have it by default. Debian's SDL meta package seems to leave it out as well.

 

[ebenblues]

I agree having fullscreen messages is a good feature. I honestly think some other things should be on the TODO first, but it should be there too. Look at Project64 1.7's implementation here: http://www.pj64-emu.com/blog/198-features.html

That's pretty slick looking. Don't expect ours to look that good right away. So...any idea what they used to render that text? :saint:

Are the other items that you think should be higher priority in our issues list? We're tracking all issues on the google site now. Please take a look and if there are issues missing, add them. I'm not sure if you're on the project member list on the google site, but if you are, you can help prioritize them.

As far as the Blight input GUI, I'd have all the GUI stuff in gtk and if a separate SDL thread was needed to capture the input, make it hidden and pass the values to the GUI.

I think this is possible. Guess I was just taking the lazy way out. If I find a way to grab SDL input without using an SDL window, I'll make sure it's a common function so you can use it too in the Qt version.

As far as the fullscreen I actually don't know the best way to do text. OpenGL has no built-in text ability and whenever I needed to do text I more or less use GLUT. I'm hesitant to require libSDL_ttf since its not just Fedora that doesn't have it by default. Debian's SDL meta package seems to leave it out as well.

That's kind of where I'm at. The only convenient ways I know of to render text in OpenGL is glut and SDL_ttf. Since we're already using SDL, we can't use glut, and like you said, SDL_ttf is not included with SDL on some systems. Unless someone knows of another more common alternative to rendering text, I'm going to have to go with SDL_ttf.

 

[Tillin9]

I'm 95% certain that Project64 uses DirectX 9's D3DXFont to render TrueTyppe fonts to textures. The goal was to mimic Windows Media Center's fullscreen messages which use the .NET DirectX bindings to do this. Too bad we can't do that (well without requiring libwine and OpenGL 2.x).

As far as the tracker, no issue I know of isn't there. Just let me know if you can confirm that the 0-9 save slot actually isn't working?

My top things to fix, enhance before fullscreen messages. Again, this is just my opinion.
- Fog bugs, the normal one and radeon issue.
- GUI crashes if input plugin doesn't load.
- The various BlightInput issues (100% CPU, libSDL_ttf)
- Saveslots.
- GTK accelerators.
--- Possible 1.4 break?
- Working KDE GUI and the various GTK GUI fixes.
- Getting faux Analogue sticks.
- Widescreen support.

As far as SDL_ttf I'd say let's still try to remove it from Blight and cross the fullscreen message bridge when we get there.

 

[ebenblues]

My top things to fix, enhance before fullscreen messages. Again, this is just my opinion.
- Fog bugs, the normal one and radeon issue.
- GUI crashes if input plugin doesn't load.
- The various BlightInput issues (100% CPU, libSDL_ttf)
- Saveslots.
- GTK accelerators.
--- Possible 1.4 break?
- Working KDE GUI and the various GTK GUI fixes.
- Getting faux Analogue sticks.
- Widescreen support.

As far as SDL_ttf I'd say let's still try to remove it from Blight and cross the fullscreen message bridge when we get there.

That sounds fine to me. I'm working on adding a new tab to the config dialog to allow mapping of controller inputs to special functions, e.g. toggle fullscreen, exit, etc. I'm going to try to get controller input from the user without an SDL window. If I can pull that off, removing the SDL_ttf dependency from blight_input will be easy. I'll let you know.

Regarding fullscreen messages, I use mythtv which does this all over the place. I'll try poking around their source code to see how they do it.

 

[ebenblues]

As far as the Blight input GUI, I'd have all the GUI stuff in gtk and if a separate SDL thread was needed to capture the input, make it hidden and pass the values to the GUI.

I think this is possible. Guess I was just taking the lazy way out. If I find a way to grab SDL input without using an SDL window, I'll make sure it's a common function so you can use it too in the Qt version.

Update on this. I just added support for mapping joystick buttons/axis movements to emulator functions (fullscreen, stop emulation, etc) and was able to use only gtk for the gui and capture joystick input via SDL without opening an SDL window. I'm not sure if I'll be able to get this to work for keyboard/mouse events tho, but it's still progress.

 

[Günther1]

We have an issue opened right now because blight_input doesn't load if libSDL_ttf is not installed on the system.

Shipping an internal copy of libSDL_ttf is not unheard of, but probably not worth the downsides. After all, it's not hard to install the package

When you actually set a controller button, you still need an SDL window to pop up to capture the controller button.

It might be possible to tell SDL to use the GTK+-window - theoretically, GDK_WINDOW_XID() and SDL_WINDOWID should work.

 

[ebenblues]

It might be possible to tell SDL to use the GTK+-window - theoretically, GDK_WINDOW_XID() and SDL_WINDOWID should work.

This might be exactly what I was looking for. Thanks for the tip!

 

[nmn]

It might be possible to tell SDL to use the GTK+-window - theoretically, GDK_WINDOW_XID() and SDL_WINDOWID should work.

Would that work?! If that would work on all platforms where SDL and GTK are supported, I seriously need to remember that in the future. That is just plain useful.

By the way, with SDL in X11, you don't need a window to recieve input events. Won't help if we want to support more but just in case this method does not span that would be useful. Especially since GTK on Mac OS X is currently only supported well under X11.

 

[ebenblues]

Would that work?! If that would work on all platforms where SDL and GTK are supported, I seriously need to remember that in the future. That is just plain useful.

I've done some research and it looks like using SDL_WINDOWID in this way is largely viewed as a hack which is platform-specific (works in X11 and win32 only), so it's not a complete solution to the problem. I tried playing around with it last night for a long time and could not manage to get the xid of a GtkWindow. gtk_window_get_parent_window kept returning a null pointer to me instead of the parent GdkWindow. I'll have to keep messing with it.

By the way, with SDL in X11, you don't need a window to recieve input events. Won't help if we want to support more but just in case this method does not span that would be useful. Especially since GTK on Mac OS X is currently only supported well under X11.

Could you elaborate? I found this to be true for joystick input, but for keyboard/mouse, you need an SDL window open that has focus, otherwise the window manager gets all the events, not SDL.

 

[nmn]

Crud, That's right, keyboard events don't get caught. Well if you wanted to cut off SDL_ttf the obvious solution would be to use Pango or Freetype directly.

 

[Richard42]

Does GTK have a message loop? If so, why not catch mouse or keyboard messages from the GTK message loop, and joystick movements or presses from SDL? You could spawn a thread to listen for SDL events and push custom messages back to the parent GTK thread. We could file a patent on it.

 

[nmn]

Does GTK have a message loop? If so, why not catch mouse or keyboard messages from the GTK message loop, and joystick movements or presses from SDL? You could spawn a thread to listen for SDL events and push custom messages back to the parent GTK thread. We could file a patent on it.

To be completely honest, I thought of that. Why not do it?
* Doesn't it just seem a little hackish?
* It does require that the SDL window is focused on Windows and Mac OS X

 

[ebenblues]

Does GTK have a message loop? If so, why not catch mouse or keyboard messages from the GTK message loop, and joystick movements or presses from SDL? You could spawn a thread to listen for SDL events and push custom messages back to the parent GTK thread. We could file a patent on it.

That might be a viable option if I can't get SDL to listen on the gtk window.

 

[Richard42]

To be completely honest, I thought of that. Why not do it?
* Doesn't it just seem a little hackish?
* It does require that the SDL window is focused on Windows and Mac OS X

I wouldn't consider it to be too much of a hack if it were written properly. Just imagine that you're building a threaded client-server system with the SDL thread serving up joystick events. I agree that it's not ideal, but without a hybrid scheme like there is no way around being stuck with a non-native looking dialog (which is what we have today). The alternative is to spruce up the existing SDL box as much as possible.

 

[Günther1]

I've done some research and it looks like using SDL_WINDOWID in this way is largely viewed as a hack which is platform-specific (works in X11 and win32 only), so it's not a complete solution to the problem. I tried playing around with it last night for a long time and could not manage to get the xid of a GtkWindow. gtk_window_get_parent_window kept returning a null pointer to me instead of the parent GdkWindow.

I think GDK_WINDOW_XID(widget->window) should work. The documentation for gtk_window_get_parent_window is not really helpful, but maybe it just returns 0 for top-level-windows. Those have their own GdkWindow (widget->window - one has to remember that GTK is not yet a toolkit where everything is only accessible by functions).

Of course it's not platform independent, but I thought the Win32 stuff does not even use SDL anyway. But if it does, one should be able to get the Win32 window from Gdk in a similar way.

As for using GTK+ for text/mouse input and SDL for joystick/gamepad stuff, I'm using that in a Linux port of a game, and it works well. You can just alternate between the two event loops in the same thread. The problem is, you have to use the GTK window for the OpenGL context, because it has to have the focus to receive the events. Or maybe one could also get GTK to listen to the events of the SDL window, but that's just as platform dependant as the other solutions.

Maybe you could also just use the keycode GTK+ gives you and use that instead of listening to SDL events. After all, both just pass the X11 event down.

 

[Danny]

Why not just make Mupen a .deb installer package and check for dependency's and install them if they are missing (sdl for instance)

Would save a lot of work.

I sure can't think of anything more globally supported than sdl.

Either that or supply Mupen as a binary package and have a separate .deb package that checks for dependency's and installs anything missing.

Seems like a good compromise.

 

[ebenblues]

Why not just make Mupen a .deb installer package and check for dependency's and install them if they are missing (sdl for instance)

Would save a lot of work.

I sure can't think of anything more globally supported than sdl.

Either that or supply Mupen as a binary package and have a separate .deb package that checks for dependency's and installs anything missing.

Seems like a good compromise.

Yes, that's a good solution for any distro that has package management with dependency checking support. I think most of our discussion is related to those who want to download the source zip and compile it. In that case, you don't have packages, so you still need a way within the build system to notify if there are missing dependencies.