Ruminate actually works pretty well with monogame-sdl2/FNA on Linux.  I implemented one of my menus to use it instead of the menuing functions I had started to create myself, and it was quick and easy.


Until I ran into one little issue…  Ruminate polls the mouse state in several different places other than the main Update method, and the polled location is used to make things like the sliders work.

That’s fine, for “normal” applications where the coordinates of the screen will always match up with the surface being rendered.  But, my demo project renders the game to a background RenderTarget2D then blits that at the end to the (user resizable) window, or centers and scales (at the normal aspect ratio) the surface as large as possible when in full-screen mode.  This means the user can resize the window as much as they like and the game scales, or they can run it fullscreen and the game automagically uses their current desktop resolution.  This seemed to be the best solution for pixel-art style games.

So the problem is:  in my fullscreen mode, the mouse’s real world screen coordinates are most likely not at all the same as the RenderTarget coordinates where Ruminate thinks its GUI widgets lie.  Fullscreen on my 2560x1080p monitor, Ruminate has no idea the whole surface is being rendered 800+ pixels to the right of the where it thinks the GUI starts (and is being stretched vertically as well).

The solution was a method to translate the screen coordinates into RenderTarget coords and a small amendment to the Ruminate update methods so that they can accept mouse state as a passed parameter.  This replaces the multiple places where Ruminate was polling the mouse state itself.

Overall, Ruminate’s much better designed than where I was going with my own menuing system.  Scott Franks obviously put a lot more time and thought into GUIs than I have.  If I end up using this for other projects, I’ll try to get my additions pushed upstream.