Hi all,
Olivier I was planning on CC-ing R. Belmont / Arbee on this, but he has
hidden his email wel (very wel). Can you forward this to him, thanks.
Also for further discussions having his private mail would help (I'll to
those of list then so that his well guarded email doesn't become public).
Or should I subscribe to the emuhype forums and post / discuss further
sdlmame improvements there? (I much prefer email).
Olivier Galibert wrote:
> I've finished[1] porting the new debugger to gtk for sdlmame last
> night. RB is coming back from vacation today or so, will try whether
> it compiles and works on anything else than my laptop with outrun, and
> will probably do a release shortly afterwards. At that point xmame is
> welcome to pick it up, even if it would probably be smarter to let
> people test it a bit first ;-)
>
> The code itself is very, very independant from the rest of sdlmame, so
> moving it around should be reasonably easy.
>
Very cool to hear that someone got the new debugger to work with gtk!
This has lead me into taking a look at sdlmame.
Before I continue, maybe first a short intro. I was the xmame maintainer
before Lawrence and I'm responsible for most of both the good and the
bad things in the current xmame code (iow I wrote/rewrote large parts of
it).
After retiring as xmame maintainer and letting Lawrence take over I've
been thinking a lot about a thorough cleaning up of xmame, as this is
much needed. And especially with the new core video code this has become
even more necessary. One of the options I've considered is dropping the
support xmame has for a gazillion different audio and video subsystems
and instead using SDL. I wasn't sure if this was the right way to
proceed because I didn't think that we could implement all important
xmame features with SDL. However looking at sdlmame now I think that the
future of xmame lies within / is sdlmame. We may not be able to support
every obscure feature xmame has (had?) but then xmame was suffering from
feature bloat, so I think a fresh start is a really good idea and
sldmame gives us proper HW-accelerated support for the new video core
which is IMHO very important, and gives us SDL to hide (most of)
underlying video and audio subsystems differences so we can concentrate
on the mame specific stuff.
Now on to the patch promised in the subject. When you start sdlmame on
linux/x11 with: "-video opengl -window" with a portrait oriented game
like pacman and then resize it horizontally (make it wider) without
resizing it vertical at the same time, then the right side of the game
becomes no longer visible (the game gets centered and everything right
of the original window size doesn't show).
The attached patch fixes this. I've added a quite large comment about
the why and how this fixes this (and some other resizing issues I've
been seeing too).
Besides this I've got some other features / ideas which I would like to
implement. The one idea which has evolved the most (IOW is ready to be
coded) is to use direct X11 access (same way as the attached patch does)
to ask the window manager to constrain resizing to a certain aspect
ratio. I don't know if you've ever used xmame with the Xvideo or OpenGL
drivers? There you can resize the window, but the window manager is
instructed to always keep the window width/height ratio constant this
works surprising well and is IMHO a very worthwile feature. Unfortunatly
SDL doesn't offer this so we need to use direct X11 access to get this
making this a Linux only feature. So I wondered if you are interested in
a patch that does this (for X11 only).
Regards,
Hans
diff -ur sdlmame0108u1.orig/src/sdl/window.c sdlmame0108u1/src/sdl/window.c
--- sdlmame0108u1.orig/src/sdl/window.c 2006-08-18 04:42:02.000000000 +0200
+++ sdlmame0108u1/src/sdl/window.c 2006-09-02 11:24:56.000000000 +0200
@@ -11,6 +11,7 @@
// standard SDL headers
#include <SDL/SDL.h>
+#include <SDL/SDL_syswm.h>
// OpenGL headers
#ifdef SDLMAME_MACOSX
@@ -163,6 +164,41 @@
void sdlwindow_resize(INT32 width, INT32 height)
{
+/* According to the SDL documentation this function should call
+ SDL_SetVideoMode() with the new width and height here:
+ http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fResizeEvent
+ However we don't want that as on MacOS-X and on windows this destroys and
+ recreates the OpenGL content. Under X11 not calling SDL_SetVideoMode() is a
+ problem because the SDL X11 code uses 2 windows a toplevel window-managed /
+ decorated one which the user has resized giving us the event calling to this
+ function, and a child window of this window, which is the window actually
+ used todo the drawing and to which the OpenGL context is attached. Things
+ work this way to be able to switch between fullscreen and window without
+ destroying the rendering window and thus the OpenGL context.
+
+ However because we are not calling SDL_SetVideoMode() this child window
+ does not get resized leading to all kinda problems. The piece of code
+ below fixes this by doing the resize manual. Another fix would be to
+ just call SDL_SetVideoMode() as the SDL documentation says, under X11 this
+ is not a problem as calling SDL_SetVideoMode() with the same flags will
+ reuse the existing window + OpenGL context. However we first need to check
+ we are on X11 first and with that code in place just resizing the window
+ ourselves is just as easy and quicker.
+
+ Last but not least we might also need todo some fixing up for other
+ platforms because of us not calling SDL_SetVideoMode() for windows see:
+ http://www.libsdl.org/pipermail/sdl/2006-June/075062.html */
+#if defined(SDL_VIDEO_DRIVER_X11)
+ SDL_SysWMinfo info;
+ SDL_VERSION(&info.version);
+ if ( SDL_GetWMInfo(&info) && (info.subsystem == SDL_SYSWM_X11) )
+ {
+ info.info.x11.lock_func();
+ XResizeWindow(info.info.x11.display, info.info.x11.window,
+ width, height);
+ info.info.x11.unlock_func();
+ }
+#endif
sdl_window_info *window = sdl_window_list;
window->wind_rect.right = width;
