Switchres: modeline generator engine

[Calamity]

I've managed to patch if for Windows so both threads are synched through the VBLANK, so it's working now with multithreading 1 + throttle 0 + triplebuffer 1. I'm using the SetEvent / WaitForSingleObject Windows logic, and fortunately only the /src/osd/windows/window.c file needs to be patched.

Code: [Select]

diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-07 12:55:40.000000000 +0100
@@ -148,6 +148,7 @@
 
 static HANDLE ui_pause_event;
 static HANDLE window_thread_ready_event;
+static HANDLE video_ready_event;
 
 
 
@@ -243,6 +244,11 @@
  ui_pause_event = CreateEvent(NULL, TRUE, FALSE, NULL);
  if (!ui_pause_event)
  fatalerror("Failed to create pause event");
+
+ // create an event to wait for video update
+ video_ready_event = CreateEvent(NULL, FALSE, FALSE, NULL);
+ if (!video_ready_event)
+ fatalerror("Failed to create video ready event");
 
  // if multithreading, create a thread to run the windows
  if (multithreading_enabled)
@@ -328,6 +334,10 @@
  if (ui_pause_event)
  CloseHandle(ui_pause_event);
 
+ // kill the video ready event
+ if (video_ready_event)
+ CloseHandle(video_ready_event);
+
  // kill the window thread ready event
  if (window_thread_ready_event)
  CloseHandle(window_thread_ready_event);
@@ -779,6 +789,9 @@
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
+
+ // wait for video update
+ WaitForSingleObject(video_ready_event, INFINITE);
  }
  }
 
@@ -1364,6 +1377,8 @@
  mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
 
  ReleaseDC(wnd, hdc);
+ // inform main thread video update is done
+ SetEvent(video_ready_event);
  break;
  }
 

On the bad side, this patch only works when in fullscreen, so as soon as we switch to windowed mode or minimize it, the VBLANK signal is not available anymore so the fps gets crazy again. That's not so important as the aim of this is to run fullscreen all the time. However, in order to be perfect, the emulator part should be patched too, so we could keep throttle enabled all the time, but when we set mame for vsync or triplebuffer, just have the throttle function to exit itself, to avoid waiting twice, and when windowed or minimized or not vsynched, then use the normal throttle sleep wait.

[bitbytebit]

I've managed to patch if for Windows so both threads are synched through the VBLANK, so it's working now with multithreading 1 + throttle 0 + triplebuffer 1. I'm using the SetEvent / WaitForSingleObject Windows logic, and fortunately only the /src/osd/windows/window.c file needs to be patched.

Code: [Select]

diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-07 12:55:40.000000000 +0100
@@ -148,6 +148,7 @@
 
 static HANDLE ui_pause_event;
 static HANDLE window_thread_ready_event;
+static HANDLE video_ready_event;
 
 
 
@@ -243,6 +244,11 @@
  ui_pause_event = CreateEvent(NULL, TRUE, FALSE, NULL);
  if (!ui_pause_event)
  fatalerror("Failed to create pause event");
+
+ // create an event to wait for video update
+ video_ready_event = CreateEvent(NULL, FALSE, FALSE, NULL);
+ if (!video_ready_event)
+ fatalerror("Failed to create video ready event");
 
  // if multithreading, create a thread to run the windows
  if (multithreading_enabled)
@@ -328,6 +334,10 @@
  if (ui_pause_event)
  CloseHandle(ui_pause_event);
 
+ // kill the video ready event
+ if (video_ready_event)
+ CloseHandle(video_ready_event);
+
  // kill the window thread ready event
  if (window_thread_ready_event)
  CloseHandle(window_thread_ready_event);
@@ -779,6 +789,9 @@
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
+
+ // wait for video update
+ WaitForSingleObject(video_ready_event, INFINITE);
  }
  }
 
@@ -1364,6 +1377,8 @@
  mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
 
  ReleaseDC(wnd, hdc);
+ // inform main thread video update is done
+ SetEvent(video_ready_event);
  break;
  }
 


Cool, that's great, I am actually trying something similar on the SDL side right now where I'm doing all the work just in the window.c file too.  I realized that really it's at that point where after the draw primatives are prepared we need to wait for the last write to finish. 
On the bad side, this patch only works when in fullscreen, so as soon as we switch to windowed mode or minimize it, the VBLANK signal is not available anymore so the fps gets crazy again. That's not so important as the aim of this is to run fullscreen all the time. However, in order to be perfect, the emulator part should be patched too, so we could keep throttle enabled all the time, but when we set mame for vsync or triplebuffer, just have the throttle function to exit itself, to avoid waiting twice, and when windowed or minimized or not vsynched, then use the normal throttle sleep wait.  I am leaning away from changing the emu/ part now if somehow can get away with not altering it, but I did see how the minimized thing would alter things quite a bit.  I do adjust for the 'bench mark' setting I think, at least see that in there too as another thing to let just run free.  Great that you did this because the Windows side of things was making me get confused, but I did realize the issue was I couldn't open up a Critical section and needed the type of wait event you talked about and are using so this is wonderful.  Also confirms that what I'm doing in the SDL stuff to change it to just work in the window.c part is going to probably work.  I've got it mostly working but I'm seeing a slight fluctuation/jump in running speed every so often, sort of like I saw before I disabled the render_wait mutex in how I was doing it before.  Doing it this way definitely simplifies the code that has to be touched so is seeming much better than going all the way into the video.c and through that to the osd interface to the emu code.

[Calamity]

Yeah I agree not touching the /emu part is better and cleaner, and after all who cares about the minimizing issue. At least doing this has let me have some insight on the subtle differences among triplebuffer and syncrefresh/waitvsync options, inside the ddraw layer, something I had always wondered about, and the actual sequence and order of different waits happening.

[bitbytebit]

Yeah I agree not touching the /emu part is better and cleaner, and after all who cares about the minimizing issue. At least doing this has let me have some insight on the subtle differences among triplebuffer and syncrefresh/waitvsync options, inside the ddraw layer, something I had always wondered about, and the actual sequence and order of different waits happening.

Wow it's amazing how much simpler the SDL patch is now and same results, possibly even better ones most likely..

Code: [Select]

diff --git a/src/osd/sdl/window.c b/src/osd/sdl/window.c
index 404dd0a..e4615e4 100644
--- a/src/osd/sdl/window.c
+++ b/src/osd/sdl/window.c
@@ -990,7 +990,7 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                }
 
                // only render if we have been signalled
-               if (osd_event_wait(window->rendered_event, 0))
+               if ((video_config.waitvsync && multithreading_enabled) || osd_event_wait(window->rendered_event, 0))
                {
                        worker_param wp;
                        render_primitive_list *primlist;
@@ -1007,6 +1007,10 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        wp.machine = machine;
 
                        execute_async(&draw_video_contents_wt, &wp);
+
+                       // wait for last vsync to finish
+                       if (video_config.waitvsync && multithreading_enabled)
+                               osd_event_wait(window->rendered_event, osd_ticks_per_second() * 10000);
                }
        }
 }
@@ -1234,9 +1238,13 @@ static OSDWORK_CALLBACK( draw_video_contents_wt )
        }
 
        /* all done, ready for next */
-       osd_event_set(window->rendered_event);
+       if (!(video_config.waitvsync && multithreading_enabled))
+               osd_event_set(window->rendered_event);
        osd_free(wp);
 
+       if (video_config.waitvsync && multithreading_enabled)
+               osd_event_set(window->rendered_event);
+
        return NULL;
 }

Basically the 'rendered_event' SDL_mutex is just used slightly different in the vsyncwait+multithread case and given the ability to sleep.  It's interesting because what we essentially are doing is using the vsync to throttle and doing the sleep there, seems like the actual best correct way to do it other than the single threaded forced wait through drawing to the video buffer.  It's definitely nice to learn more about the internals of what we are trying to get to run with the vertical refresh, amazing though how much extra code I thought it'd take but this is all it actually needs.  Seeing your changes helped because I realized the places I was trying the new method in just window.c needed to happen a bit later than I was doing them, and looks like that was why I was seeing the slight speed hiccups every 30 seconds or so.  

[bitbytebit]

Yeah I agree not touching the /emu part is better and cleaner, and after all who cares about the minimizing issue. At least doing this has let me have some insight on the subtle differences among triplebuffer and syncrefresh/waitvsync options, inside the ddraw layer, something I had always wondered about, and the actual sequence and order of different waits happening.

I just submitted the SDL code/diff to the mame developers email address, If you want me to I can your windows one against 0141 and send it in your name or you can send it when you feel it's complete.  I think it'd be good to get both of these into mame so we don't have to worry about changes and also they might actually see something else and improve the vsync wait and multithreading some way we haven't thought of.  From the simplicity of both patches and pretty much cut and dry target at allowing waitvsync and multithreading to work normal and not break things, seems like a pretty straight forward fix that's needed and not a separate branch/patch from mame.  It's at least worth a shot, I'm guessing they'll be interested, might be open bugs or already a well known issue they just haven't had time to address and this might give them a handle on how to solve it.

[Calamity]

Oh, thanks so much, if you could also post my Windows patch. Even if they found a better way to do it, it's good to let them now as this issue should actually be addressed at some point, it's not really a hack but a feature that should be there.

[bitbytebit]

Oh, thanks so much, if you could also post my Windows patch. Even if they found a better way to do it, it's good to let them now as this issue should actually be addressed at some point, it's not really a hack but a feature that should be there.

I just sent it too.  Thinking about it seems like this basically allows the whole rendering/setup of the next frame update while the current write is being performed and vsync is being waited for by the drawing to the video card.  So hopefully from that angle, this seems like a good patch.  I'm thinking that possibly there are other things tied into the frame write which could be separated out like input event polling?  I'm not sure though if there are things that should be separated from the vsync/throttle waiting or if that actually is a bad thing and would probably throw the whole thing out of sync.  Possibly just the preparation of them though if not already done with the way it is currently, interesting to look and see to learn more, but thinking it's possibly the limit of multithreading gain just be what we've done.  At least from everything I've read seems to say that the way mame currently multithreads is as good as it can get from the technical limitations of being an emulator.

[Calamity]

Yes, page flipping is performed right when the electron beam starts its way up to the top of the screen, so when it begins drawing the screen the video memory buffer is already correct, and right after page flipping function returns the event is set so we start rendering the next frame while the electron beam is starting doing its work drawing the screen with the previous frame info, and if we are quick enough we'll end rendering the current frame before the previous one is completely drawn, so at that point we store the current frame into the back buffer and wait until the electron beam reaches the bottom, then we page flip and go on, so it's our videocard the one that provides the external timer we need and the cpu is released when we set it to wait.

For what I'm seeing, although the input is passed by the main thread, it's actually processed on the window thread. That makes me think that waiting for vsync in the window_proc callback is not a good idea as the thread will be locked for input during an instant. IDirectDraw7_WaitForVerticalBlank function had a param for passing it an event handle so that the waiting could be performed in a separate thread, but unfortunately they never supported it. So hopefully that is not affecting input too much, but anyway it was doing right that before multithreading, that might be a reason why different people have reported input lag when doing triplebuffer. The input lag by the way is something that should be studied to see if there's some way to reduce it. I read some time ago in the Soft-15KHz thread that SailorSat was working in a patch for polling the keyboard in a more effective way, it would be nice to know what he thinks.

[newmanfamilyvlogs]

I had the most bizarre input lag issue for a while when using triple buffering or vsync. It was most noticeable with trackball games-- rapid movement such as moving in one direction while simultaneously making loops (spiraling sideways, if you will) would begin to 'queue up' the input and then 'play it back' at a speed slower than originally inputted. It seemed to catch up when no input was being given. Sometimes this would lag input upwards of 2-3 seconds.

Doing some forum digging makes me think this might have been a quirk of ATI video drivers rather than mame; but deleting all the .INI files and starting fresh seemed to resolve it.

[bitbytebit]

This patch should in theory make input really responsive and fine grained (I'm not sure if I'm missing something where the main mame emu layer needs to also be running too?), this is only for the SDL layer but guessing the same could be done in the Windows changes for vsync+multithreading. 

Code: [Select]

diff --git a/src/osd/sdl/video.c b/src/osd/sdl/video.c
index 32ef4c8..e760797 100644
--- a/src/osd/sdl/video.c
+++ b/src/osd/sdl/video.c
@@ -338,6 +338,10 @@ void sdl_osd_interface::update(bool skip_redraw)
                 skip_redraw = 0;
         }
 
+       // poll the joystick values here
+       sdlinput_poll(&machine());
+       check_osd_inputs(&machine());
+
        // if we're not skipping this redraw, update all windows
        if (!skip_redraw)
        {
diff --git a/src/osd/sdl/window.c b/src/osd/sdl/window.c
index 69bfe65..0ac3506 100644
--- a/src/osd/sdl/window.c
+++ b/src/osd/sdl/window.c
@@ -1009,8 +1009,14 @@ void sdlwindow_video_window_update(running_machine *machine, sdl_window_info *wi
                        execute_async(&draw_video_contents_wt, &wp);
 
                        // wait for last vsync to finish
-                       if (video_config.waitvsync && multithreading_enabled)
-                               osd_event_wait(window->rendered_event, osd_ticks_per_second() * 10000);
+                       if (video_config.waitvsync && multithreading_enabled) {
+                               bool got_lock = FALSE;
+                               got_lock = osd_event_wait(window->rendered_event, 0);
+                               while (!got_lock) {
+                                       sdlinput_poll(machine);
+                                       got_lock = osd_event_wait(window->rendered_event, 1000);
+                               }
+                       }
                }
        }
 }


Basically the polling of the input seems to be done in that update osd function called from the emu layer, and so when we are waiting for the last vblank to happen, I'm just running that input polling the whole time.  So there's not any time period, besides 1000 milliseconds which should be nothing, where we aren't checking the input polling when in threading mode with vsync enabled.  Seems like what the issue would be with setups in the past having issues, and from just trying this, although I may just be having a placebo effect, seems like it's a bit more quick to respond to joystick movements.  If this isn't fully the fix, then it would also need the basic emu layer also moving to act on the input actions during this time.  I sort of doubt though that's really an issue, I'm guessing that this should remove any input lag when running without throttle and vsync.  Triple buffer may be a complete different story, I'm not sure, but it may need some other place to loop the input polling.  From what I can tell looping the input polling at any speed works fine, and it's not restricted to waiting for vblanks to occur.  That's the part I'm partly wondering about, is that really true, it so far seems correct though (unless it's basically not really helping if the actual lower emulation layer needs to also be freely running at the same time as waiting for the vblank).  Also it's interesting how with throttle, we always would be restricted it seems at not running the input like this, it's only possible through multi threading and vsync waiting together where we get this area of free looping to do tasks like input polling.  Also I found the minimum I could go is 1000 for waiting, any lower and CPU usage goes up, but at 1000 it's exactly the same as without the change.

[Calamity]

That patch looks really interesting, we'll need to find the right functions in the Windows part to do that. I think there will be a problem with that method in Windows, as even if we poll for inputs during the wait for event time, no input will be received as the thread that gets the input is the other one that's busy waiting for vsync. So the input will get stuck in the queue until the REDRAW message function exits. So we would need a third thread for achieving that However, depending on when the usual poll is performed, it might be useful to make sure we poll for inputs right after we exit vblank and before the next frame is rendered. Anyway I may be wrong with all this, will need to look deeper.

BTW this thread is interesting, there's some comments by PsikyoFan on the input lag stuff.

http://shmups.system11.org/viewtopic.php?f=1&t=26394&start=30

It's also interesting this Shumpmame project, although these hacks are on the emulator layer:

http://shmups.system11.org/viewtopic.php?f=1&t=30659

[bitbytebit]

That patch looks really interesting, we'll need to find the right functions in the Windows part to do that. I think there will be a problem with that method in Windows, as even if we poll for inputs during the wait for event time, no input will be received as the thread that gets the input is the other one that's busy waiting for vsync. So the input will get stuck in the queue until the REDRAW message function exits. So we would need a third thread for achieving that However, depending on when the usual poll is performed, it might be useful to make sure we poll for inputs right after we exit vblank and before the next frame is rendered. Anyway I may be wrong with all this, will need to look deeper.

BTW this thread is interesting, there's some comments by PsikyoFan on the input lag stuff.

http://shmups.system11.org/viewtopic.php?f=1&t=26394&start=30

It's also interesting this Shumpmame project, although these hacks are on the emulator layer:

http://shmups.system11.org/viewtopic.php?f=1&t=30659

Ah yeah, the input thing is sort of what I feared and possibly the same in SDL I'm guessing.  Although I did put the extra poll right before the part where we go into the video write stuff in that patch so it probably helps quite a bit I am guessing with just that.  Sounds like there would be some advantage to have another thread running doing input possibly just in the OSD so again wouldn't have to touch anything else that way.

Also in SDL 1.3 it seems to indicate this might be somewhat the case by default, something about a thread for it, not sure, but still figuring out.  At least seems to not hurt it with the change I made and I swear now I feel like i have more of a grasp on like pacman for instance, but then again it's hard to immediately say and might just be me thinking that or the other multithread patch doing that partly.

[Calamity]

I've seen that the patch I posted yesterday can be made much simpler just by modifying the PostMessage api call by SendMessage (as it's done without multithreading), so it could be replaced here and have the same effect:

Code: [Select]

if (multithreading_enabled)
PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
else
SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
mtlog_add("winwindow_video_window_update: PostMessage end");

SendMessage waits, Postmessage doesn't, so we get rid of the need of creating and mantaining an event object.

I've also done this other patch, that replaces the other ones:

Code: [Select]

diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-08 13:17:22.000000000 +0100
@@ -775,7 +775,14 @@
  last_update_time = timeGetTime();
  mtlog_add("winwindow_video_window_update: PostMessage start");
  if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ {
+ HDC hdc = GetDC(window->hwnd);
+ mtlog_add("winwindow_video_window_proc: main thread video update begin");
+ window->primlist = primlist;
+ draw_video_contents(window, hdc, FALSE);
+ mtlog_add("winwindow_video_window_proc: main thread video update end");
+ ReleaseDC(window->hwnd, hdc);
+ }
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
The idea with this one is to do the video update on the main thread instead of on the window thread, so at leat in theory the window thread will be free to receive and process input while the main/emulator thread is waiting for the page flipping to happen, so we just lock one of the threads. It seems to work here, I still need to test it to see if it really improves input response, as it's something rather subjective it seems (to be honest I can't notice the difference yet even when using Shumpmame but it could be I'm testing it on a lcd that has its own lag).

[Calamity]

This one patch is a variation of the previous one, to allow continuous poll of the input devices during waiting for vblank.

Code: [Select]

diff -Nru a/src/osd/windows/drawdd.c b/src/osd/windows/drawdd.c
--- a/src/osd/windows/drawdd.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/drawdd.c 2011-01-09 18:43:57.000000000 +0100
@@ -55,6 +55,7 @@
 // MAMEOS headers
 #include "winmain.h"
 #include "window.h"
+#include "input.h"
 #include "config.h"
 
 
@@ -179,7 +180,7 @@
 static int drawdd_window_init(win_window_info *window);
 static void drawdd_window_destroy(win_window_info *window);
 static render_primitive_list *drawdd_window_get_primitives(win_window_info *window);
-static int drawdd_window_draw(win_window_info *window, HDC dc, int update);
+static int drawdd_window_draw(win_window_info *window, HDC dc, int update, running_machine *machine);
 
 // surface management
 static int ddraw_create(win_window_info *window);
@@ -344,7 +345,7 @@
 //  drawdd_window_draw
 //============================================================
 
-static int drawdd_window_draw(win_window_info *window, HDC dc, int update)
+static int drawdd_window_draw(win_window_info *window, HDC dc, int update, running_machine *machine)
 {
  dd_info *dd = (dd_info *)window->drawdata;
  render_primitive *prim;
@@ -457,10 +458,12 @@
  if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X unlocking blit surface\n", (int)result);
 
  // sync to VBLANK
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh))
  {
- result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
- if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
+ BOOL lpbIsInVB;
+ while (IDirectDraw7_GetVerticalBlankStatus(dd->ddraw, &lpbIsInVB) == DD_OK && lpbIsInVB == FALSE)
+ {
+ winwindow_process_events(machine, TRUE);
+ wininput_poll(machine);
+ }
  }
 
  // complete the blitting
diff -Nru a/src/osd/windows/video.c b/src/osd/windows/video.c
--- a/src/osd/windows/video.c 2010-11-06 18:24:58.000000000 +0100
+++ b/src/osd/windows/video.c 2011-01-09 18:48:50.000000000 +0100
@@ -221,7 +221,7 @@
  // if we're not skipping this redraw, update all windows
  if (!skip_redraw)
  for (win_window_info *window = win_window_list; window != NULL; window = window->next)
- winwindow_video_window_update(window);
+ winwindow_video_window_update(window, &machine());
 
  // poll the joystick values here
  winwindow_process_events(&machine(), TRUE);
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-09 17:03:16.000000000 +0100
@@ -157,7 +157,7 @@
 
 static void winwindow_exit(running_machine &machine);
 static void winwindow_video_window_destroy(win_window_info *window);
-static void draw_video_contents(win_window_info *window, HDC dc, int update);
+static void draw_video_contents(win_window_info *window, HDC dc, int update, running_machine *machine);
 
 static unsigned __stdcall thread_entry(void *param);
 static int complete_create(win_window_info *window);
@@ -716,7 +716,7 @@
 //  (main thread)
 //============================================================
 
-void winwindow_video_window_update(win_window_info *window)
+void winwindow_video_window_update(win_window_info *window, running_machine *machine)
 {
  int targetview, targetorient;
  render_layer_config targetlayerconfig;
@@ -775,7 +775,16 @@
  last_update_time = timeGetTime();
  mtlog_add("winwindow_video_window_update: PostMessage start");
  if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ {
+ HDC hdc = GetDC(window->hwnd);
+
+ mtlog_add("winwindow_video_update: video update begin");
+ window->primlist = primlist;
+ draw_video_contents(window, hdc, FALSE, machine);
+ mtlog_add("winwindow_video_update: video update end");
+
+ ReleaseDC(window->hwnd, hdc);
+ }
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
@@ -1215,7 +1224,8 @@
  {
  PAINTSTRUCT pstruct;
  HDC hdc = BeginPaint(wnd, &pstruct);
- draw_video_contents(window, hdc, TRUE);
+ if (hdc)
+ draw_video_contents(window, hdc, TRUE, NULL);
  if (win_has_menu(window))
  DrawMenuBar(window->hwnd);
  EndPaint(wnd, &pstruct);
@@ -1357,13 +1367,15 @@
  case WM_USER_REDRAW:
  {
  HDC hdc = GetDC(wnd);
+ if (hdc)
+ {
+ mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW begin");
+ window->primlist = (render_primitive_list *)lparam;
+ draw_video_contents(window, hdc, FALSE, NULL);
+ mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
 
- mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW begin");
- window->primlist = (render_primitive_list *)lparam;
- draw_video_contents(window, hdc, FALSE);
- mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
-
- ReleaseDC(wnd, hdc);
+ ReleaseDC(wnd, hdc);
+ }
  break;
  }
 
@@ -1409,7 +1421,7 @@
 //  (window thread)
 //============================================================
 
-static void draw_video_contents(win_window_info *window, HDC dc, int update)
+static void draw_video_contents(win_window_info *window, HDC dc, int update, running_machine *machine)
 {
  assert(GetCurrentThreadId() == window_threadid);
 
@@ -1433,7 +1445,7 @@
  // otherwise, render with our drawing system
  else
  {
- (*draw.window_draw)(window, dc, update);
+ (*draw.window_draw)(window, dc, update, machine);
  mtlog_add("draw_video_contents: drawing finished");
  }
  }
diff -Nru a/src/osd/windows/window.h b/src/osd/windows/window.h
--- a/src/osd/windows/window.h 2010-10-18 02:51:58.000000000 +0200
+++ b/src/osd/windows/window.h 2011-01-09 14:16:58.000000000 +0100
@@ -122,7 +122,7 @@
 
  int (*window_init)(win_window_info *window);
  render_primitive_list *(*window_get_primitives)(win_window_info *window);
- int (*window_draw)(win_window_info *window, HDC dc, int update);
+ int (*window_draw)(win_window_info *window, HDC dc, int update, running_machine *machine);
  void (*window_destroy)(win_window_info *window);
 };
 
@@ -149,7 +149,7 @@
 
 BOOL winwindow_has_focus(void);
 void winwindow_update_cursor_state(running_machine *machine);
-void winwindow_video_window_update(win_window_info *window);
+void winwindow_video_window_update(win_window_info *window, running_machine *machine);
 win_monitor_info *winwindow_video_window_monitor(win_window_info *window, const RECT *proposed);
 
 LRESULT CALLBACK winwindow_video_window_proc(HWND wnd, UINT message, WPARAM wparam, LPARAM lparam);

It's much more code, mainly because it needs that *machine param being passed down to the ddraw layer in order to poll the inputs there, something that is not designed to be used in that scope, so it's become rather dirty because of that. It's also repairing a bug with the last patch when draw_video_contents function could actually be called again from the windowproc while still being waiting from vblank, causing a null hdc.

This patch works when using syncrefresh 1, triplebuffer 0, throttle 0, multithreading 1. So instead of triplebuffer for vsynching+page flipping, we're directly blitting to the primary surface during vblank. Instead of using WaitForVerticalBlank I'm using GetVerticalBlankStatus, that tells us the vblank state without waiting, so I do a loop there to poll the input during the wait, and still can do it while using only two threads. I haven't put any sleep during that loop (should be done), but anyway the cpu usage does not go crazy.

Of course this works with single screen games, I guess that using this method to throttle with multiple screens would have unpredictable results. So think about this as experimental stuff.

That said, I notice no difference with this method and the default in Mame, so maybe they're already doing the best possible thing when polling inputs right after returning from the update video function. Maybe the Linux implementation can take any advantage of how that os works, I don't know. I've been messing these days with Mame source, only that small part of it, and I must say I'm amazed with it. Mame is a complex object, it takes days to get to understand just any of the modules, I believe there must be very few people, if any, that really have a full understanding of the whole thing in their heads.

UPDATE: I've added the {} that were missing after the 'while', so now should be doing what it was supposed to.
 

[bitbytebit]

This one patch is a variation of the previous one, to allow continuous poll of the input devices during waiting for vblank.

Code: [Select]

diff -Nru a/src/osd/windows/drawdd.c b/src/osd/windows/drawdd.c
--- a/src/osd/windows/drawdd.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/drawdd.c 2011-01-09 18:43:57.000000000 +0100
@@ -55,6 +55,7 @@
 // MAMEOS headers
 #include "winmain.h"
 #include "window.h"
+#include "input.h"
 #include "config.h"
 
 
@@ -179,7 +180,7 @@
 static int drawdd_window_init(win_window_info *window);
 static void drawdd_window_destroy(win_window_info *window);
 static render_primitive_list *drawdd_window_get_primitives(win_window_info *window);
-static int drawdd_window_draw(win_window_info *window, HDC dc, int update);
+static int drawdd_window_draw(win_window_info *window, HDC dc, int update, running_machine *machine);
 
 // surface management
 static int ddraw_create(win_window_info *window);
@@ -344,7 +345,7 @@
 //  drawdd_window_draw
 //============================================================
 
-static int drawdd_window_draw(win_window_info *window, HDC dc, int update)
+static int drawdd_window_draw(win_window_info *window, HDC dc, int update, running_machine *machine)
 {
  dd_info *dd = (dd_info *)window->drawdata;
  render_primitive *prim;
@@ -457,10 +458,12 @@
  if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X unlocking blit surface\n", (int)result);
 
  // sync to VBLANK
- if ((video_config.waitvsync || video_config.syncrefresh) && window->machine->video().throttled() && (!window->fullscreen || dd->back == NULL))
+ if ((video_config.waitvsync || video_config.syncrefresh))
  {
- result = IDirectDraw7_WaitForVerticalBlank(dd->ddraw, DDWAITVB_BLOCKBEGIN, NULL);
- if (result != DD_OK) mame_printf_verbose("DirectDraw: Error %08X waiting for VBLANK\n", (int)result);
+ BOOL lpbIsInVB;
+ while (IDirectDraw7_GetVerticalBlankStatus(dd->ddraw, &lpbIsInVB) == DD_OK && lpbIsInVB == FALSE)
+ {
+ winwindow_process_events(machine, TRUE);
+ wininput_poll(machine);
+ }
  }
 
  // complete the blitting
diff -Nru a/src/osd/windows/video.c b/src/osd/windows/video.c
--- a/src/osd/windows/video.c 2010-11-06 18:24:58.000000000 +0100
+++ b/src/osd/windows/video.c 2011-01-09 18:48:50.000000000 +0100
@@ -221,7 +221,7 @@
  // if we're not skipping this redraw, update all windows
  if (!skip_redraw)
  for (win_window_info *window = win_window_list; window != NULL; window = window->next)
- winwindow_video_window_update(window);
+ winwindow_video_window_update(window, &machine());
 
  // poll the joystick values here
  winwindow_process_events(&machine(), TRUE);
diff -Nru a/src/osd/windows/window.c b/src/osd/windows/window.c
--- a/src/osd/windows/window.c 2010-12-02 18:26:38.000000000 +0100
+++ b/src/osd/windows/window.c 2011-01-09 17:03:16.000000000 +0100
@@ -157,7 +157,7 @@
 
 static void winwindow_exit(running_machine &machine);
 static void winwindow_video_window_destroy(win_window_info *window);
-static void draw_video_contents(win_window_info *window, HDC dc, int update);
+static void draw_video_contents(win_window_info *window, HDC dc, int update, running_machine *machine);
 
 static unsigned __stdcall thread_entry(void *param);
 static int complete_create(win_window_info *window);
@@ -716,7 +716,7 @@
 //  (main thread)
 //============================================================
 
-void winwindow_video_window_update(win_window_info *window)
+void winwindow_video_window_update(win_window_info *window, running_machine *machine)
 {
  int targetview, targetorient;
  render_layer_config targetlayerconfig;
@@ -775,7 +775,16 @@
  last_update_time = timeGetTime();
  mtlog_add("winwindow_video_window_update: PostMessage start");
  if (multithreading_enabled)
- PostMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
+ {
+ HDC hdc = GetDC(window->hwnd);
+
+ mtlog_add("winwindow_video_update: video update begin");
+ window->primlist = primlist;
+ draw_video_contents(window, hdc, FALSE, machine);
+ mtlog_add("winwindow_video_update: video update end");
+
+ ReleaseDC(window->hwnd, hdc);
+ }
  else
  SendMessage(window->hwnd, WM_USER_REDRAW, 0, (LPARAM)primlist);
  mtlog_add("winwindow_video_window_update: PostMessage end");
@@ -1215,7 +1224,8 @@
  {
  PAINTSTRUCT pstruct;
  HDC hdc = BeginPaint(wnd, &pstruct);
- draw_video_contents(window, hdc, TRUE);
+ if (hdc)
+ draw_video_contents(window, hdc, TRUE, NULL);
  if (win_has_menu(window))
  DrawMenuBar(window->hwnd);
  EndPaint(wnd, &pstruct);
@@ -1357,13 +1367,15 @@
  case WM_USER_REDRAW:
  {
  HDC hdc = GetDC(wnd);
+ if (hdc)
+ {
+ mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW begin");
+ window->primlist = (render_primitive_list *)lparam;
+ draw_video_contents(window, hdc, FALSE, NULL);
+ mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
 
- mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW begin");
- window->primlist = (render_primitive_list *)lparam;
- draw_video_contents(window, hdc, FALSE);
- mtlog_add("winwindow_video_window_proc: WM_USER_REDRAW end");
-
- ReleaseDC(wnd, hdc);
+ ReleaseDC(wnd, hdc);
+ }
  break;
  }
 
@@ -1409,7 +1421,7 @@
 //  (window thread)
 //============================================================
 
-static void draw_video_contents(win_window_info *window, HDC dc, int update)
+static void draw_video_contents(win_window_info *window, HDC dc, int update, running_machine *machine)
 {
  assert(GetCurrentThreadId() == window_threadid);
 
@@ -1433,7 +1445,7 @@
  // otherwise, render with our drawing system
  else
  {
- (*draw.window_draw)(window, dc, update);
+ (*draw.window_draw)(window, dc, update, machine);
  mtlog_add("draw_video_contents: drawing finished");
  }
  }
diff -Nru a/src/osd/windows/window.h b/src/osd/windows/window.h
--- a/src/osd/windows/window.h 2010-10-18 02:51:58.000000000 +0200
+++ b/src/osd/windows/window.h 2011-01-09 14:16:58.000000000 +0100
@@ -122,7 +122,7 @@
 
  int (*window_init)(win_window_info *window);
  render_primitive_list *(*window_get_primitives)(win_window_info *window);
- int (*window_draw)(win_window_info *window, HDC dc, int update);
+ int (*window_draw)(win_window_info *window, HDC dc, int update, running_machine *machine);
  void (*window_destroy)(win_window_info *window);
 };
 
@@ -149,7 +149,7 @@
 
 BOOL winwindow_has_focus(void);
 void winwindow_update_cursor_state(running_machine *machine);
-void winwindow_video_window_update(win_window_info *window);
+void winwindow_video_window_update(win_window_info *window, running_machine *machine);
 win_monitor_info *winwindow_video_window_monitor(win_window_info *window, const RECT *proposed);
 
 LRESULT CALLBACK winwindow_video_window_proc(HWND wnd, UINT message, WPARAM wparam, LPARAM lparam);

It's much more code, mainly because it needs that *machine param being passed down to the ddraw layer in order to poll the inputs there, something that is not designed to be used in that scope, so it's become rather dirty because of that. It's also repairing a bug with the last patch when draw_video_contents function could actually be called again from the windowproc while still being waiting from vblank, causing a null hdc.

This patch works when using syncrefresh 1, triplebuffer 0, throttle 0, multithreading 1. So instead of triplebuffer for vsynching+page flipping, we're directly blitting to the primary surface during vblank. Instead of using WaitForVerticalBlank I'm using GetVerticalBlankStatus, that tells us the vblank state without waiting, so I do a loop there to poll the input during the wait, and still can do it while using only two threads. I haven't put any sleep during that loop (should be done), but anyway the cpu usage does not go crazy.

Of course this works with single screen games, I guess that using this method to throttle with multiple screens would have unpredictable results. So think about this as experimental stuff.

That said, I notice no difference with this method and the default in Mame, so maybe they're already doing the best possible thing when polling inputs right after returning from the update video function. Maybe the Linux implementation can take any advantage of how that os works, I don't know. I've been messing these days with Mame source, only that small part of it, and I must say I'm amazed with it. Mame is a complex object, it takes days to get to understand just any of the modules, I believe there must be very few people, if any, that really have a full understanding of the whole thing in their heads.

UPDATE: I've added the {} that were missing after the 'while', so now should be doing what it was supposed to.
 

Yeah that's interesting because on the SDL side for Linux the machine is brought into the input stuff already, I get the feeling in Linux SDL possibly the whole input thing is already having some advantage perhaps in how SDL input is done.  From what I can tell I think the thing I did in SDL which was pretty basic probably requires the more complicated way your doing it on the Windows side of things.  Also I saw and thought about the screen thing with more than one screen, even though only SDL 1.3 can do that for Linux, it already seems like the Linux side adapts to that case from what I can tell but guessing in the Windows side things are slightly trickier perhaps.  Could see possibly an advantage of another thread or a thread for each screen in the dual screen case, but I'm not sure if that really would be necessary.  It's definitely amazing looking at how mame works, and confusing a bit in the emulation side and I'm still tracing down the main execution of the machine/cpu's loop to really know where input and sound and video all are at during any given time.  I might be wrong, but seems like it'd be nice to have the 3 be somewhat separate and gathered by the UI from the emulation layer and have that emulation layer basically produce the video frames and audio samples, wait for input, and wait for the UI to pick each of them up through separate interfaces.  Since the timing of things are usually controlled by the throttle  stuff, and if that's off then the UI controls the timing through the vblank or triple  buffering I guess (still not sure how triple buffering times it really just by nature, guessing there's more to that and throttles in itself somewhere?).  Basically it would be interesting to have the emulation layer running waiting for input all the time, queing up audio samples and video frames or not queing but I guess having them ready and allow all three to be somewhat separate so the UI can pick them up anyway it wants in multiple threads or whatever it decides to do.  I think it's somewhat close to being that way now but sounds like the limitation is that the emulation layer really needs to be one single thread for efficiency and so we have to stop the emulation machine and wait every time we pass anything between the UI and it, else without throttle it would just go out of control and run as fast as it can without using the video frame as timing for the input (which then you've got audio which needs that timing too, so that's interesting, and I haven't fully understood yet where exactly the audio and video are timed together at all or it's just a byproduct of the single main thread waiting on the last video frame to flip/vblank to the screen). 

[dapsaille]

Hello,


 first = Thanks  ^^

 But ... (always but .... )

 i'm lost with windows version ...

 I've just reinstalled XP sp2 on a laptop connected to a 31khz lcd monitor for tests (will be in an egret 2 15khz rotatable monitor)

 I've generated modelines for crt_emudriver_9.3_1.2 with VMMAker.exe against mame 0.140u3 home made build.

 Modelines appears in the inf file of the driver.

 I've installed the drivers, rebooted, and tried to launch a vertical game in mame :

Code: [Select]

switchres rfjet --soft15khz
[] "rfjet" vertical 320x240@54.000 (1.333) --> 432x320@54.000 (1.331)

 Now i've got two problems ... as you can see it select 432x320 instead of 320x240 ....

switchres select the good resolution if i use  mo 2 :

Code: [Select]

D:\Mame>switchres.exe rfjet --soft15khz --mo 2
[] "rfjet" vertical 320x240@54.000 (1.333) --> 320x240@54.000 (1.333)

 But image is upside down and not usable .. i mean that it is like playing a vertical game on an horizontal monitor and with a mirror ...

 How can i get a "normal" mode with good resolution (remembre that i will use my monitor in vertical mode ^^) ?

 It seems too that i'm not using 15khz mode .. because my 31k lcd (not tri sync) can handle it ...

 Do i need to install soft15khz (Thanks SailorSat too for this beautifull tool) ?

 Could you please explain a little more how to make this interesting tool to work for brainless people like me ?

 Regards

EDIT= It may be related to VMMAKer.ini .... ?

 Here is a pastebin of this config file :

http://pastebin.com/4pwCbJiP

[Calamity]

Hi dapsaille,

First, it's not your fault you're confused. The VMMaker app was done to be used on its own for static mode lists + inis, so if you're going to use Switchres for dynamic modelines then it's better you don't create the modelines with VMMaker for now. Switchres has a pearl script for creating the mode list, but for a Windows user it may be easier for you to just install Soft-15Khz over my patched drivers, so that will replace the existing modes with its own ones. Then use a custom mode list to replace the default Soft-15Khz modelines with the ones you are going to need. I strongly recommend you to use the mode list I posted one or two pages ago.

Then, using that mode list and renaming or deleting Mame's .ini folder (important), use Switchres on it, and be sure to use the new options for vertical games on rotating monitors. I'm seeing your logs, and it seems the inis created by VMMaker are messing up Switchres command line optios, so make sure you delete or rename the .ini folder.

[dapsaille]

Hi dapsaille,

First, it's not your fault you're confused. The VMMaker app was done to be used on its own for static mode lists + inis, so if you're going to use Switchres for dynamic modelines then it's better you don't create the modelines with VMMaker for now. Switchres has a pearl script for creating the mode list, but for a Windows user it may be easier for you to just install Soft-15Khz over my patched drivers, so that will replace the existing modes with its own ones. Then use a custom mode list to replace the default Soft-15Khz modelines with the ones you are going to need. I strongly recommend you to use the mode list I posted one or two pages ago.

Then, using that mode list and renaming or deleting Mame's .ini folder (important), use Switchres on it, and be sure to use the new options for vertical games on rotating monitors. I'm seeing your logs, and it seems the inis created by VMMaker are messing up Switchres command line optios, so make sure you delete or rename the .ini folder.

 Thanks for your reply ..

 I've checked your modelist but i cannot find 320x240@56 .....
and if i use 320x240@60 i got horrible tearing for backgrounds in rfjet (and i'me sure that it's not present in the original pcb, i own it ^^)
I can see a modelines file generated by vmmaker ... can i use it contents as a usermodes.txt for soft15khz ?

 I must admit that if i can do that .. i don't understand the advantages of switchres  ....

 I'm trying what you say now .

 Thanks again

 I was thinking that switchres will extract

[Calamity]

You don't need the 320x240@56 anymore as it will be generated out of the 320x240@60 dummy modeline, tweaking it right before starting Mame. So using Switchres you can have infinite modelines.

[dapsaille]

You don't need the 320x240@56 anymore as it will be generated out of the 320x240@60 dummy modeline, tweaking it right before starting Mame. So using Switchres you can have infinite modelines.

 humm .. i like magic  ..

 so switchres extract the resolution informations from mame.exe itself ?

[bitbytebit]

Hi dapsaille,

First, it's not your fault you're confused. The VMMaker app was done to be used on its own for static mode lists + inis, so if you're going to use Switchres for dynamic modelines then it's better you don't create the modelines with VMMaker for now. Switchres has a pearl script for creating the mode list, but for a Windows user it may be easier for you to just install Soft-15Khz over my patched drivers, so that will replace the existing modes with its own ones. Then use a custom mode list to replace the default Soft-15Khz modelines with the ones you are going to need. I strongly recommend you to use the mode list I posted one or two pages ago.

Then, using that mode list and renaming or deleting Mame's .ini folder (important), use Switchres on it, and be sure to use the new options for vertical games on rotating monitors. I'm seeing your logs, and it seems the inis created by VMMaker are messing up Switchres command line optios, so make sure you delete or rename the .ini folder.

 Thanks for your reply ..

 I've checked your modelist but i cannot find 320x240@56 .....
and if i use 320x240@60 i got horrible tearing for backgrounds in rfjet (and i'me sure that it's not present in the original pcb, i own it ^^)
I can see a modelines file generated by vmmaker ... can i use it contents as a usermodes.txt for soft15khz ?

 I must admit that if i can do that .. i don't understand the advantages of switchres  ....

 I'm trying what you say now .

 Thanks again

 I was thinking that switchres will extract

Like Calamity says switchres can actually alter the modeline refresh rate, from 60 to 54, so that refresh rate actually doesn't matter it has.  It actually just uses the height and width and creates the rest of the modeline dynamically upon run (use -v -v options, more the more verbose, to see more info of what it's doing).

Also the key is that the 320x240 is only generated that way for a vertical game with the --mo 2 setting, since otherwise the 320 part is actually the height of the game, I think that combined with possibly the direction it's rotating (it uses -ror rotate right for mame) might be an issue.  

Basically doing what Calamity said, and running with the --mo 2 setting (and also trying --monitor cga for your 15khz arcade monitor, or --monitor generic, or --monitor h9110, or --monitor vga for the LCD screen) should be good, but of course the --mo 2 setting will rotate the image to the right and the 320x240 is in reference to the fact it's a vertical monitor.  Else it'll have to use 320 as the height and the wider width to make up for the horizontal monitor it think's it's on, or is on.  

[bitbytebit]

You don't need the 320x240@56 anymore as it will be generated out of the 320x240@60 dummy modeline, tweaking it right before starting Mame. So using Switchres you can have infinite modelines.

 humm .. i like magic  ..

 so switchres extract the resolution informations from mame.exe itself ?

Yep it looks up the xml info from mame directly, can mostly figure out if you've patched it with cabmame patches too and adjust for that.  The -v -v -v option will show you more details, and the mame command line it uses.

[dapsaille]

Hummm ...
ok with the help of -v -v -v -v -v -v -v (and from you two of course) i understand a little more how switchres works ...

 So .. here is THE big question ...
is there is any plan (possibility) to use a real 320x240 resolution for vertical games instead of 720x512 ?

Code: [Select]

D:\Mame>switchres rfjet --soft15khz -v -v -v
snip
......
Got Soft15khz registry modeline 720x512@60 - DALDTMCRTBCD720x512x0x60:
             "720x512@60" 15.850000 720 752 824 952 512 514 519 555 -HSync -VSyn
c interlace
Setup monitor limits min=184x108 max=0x608
Using interlace
Starting with Horizontal freq of 14.850 and Vertical refresh of 54.00
Increased horizontal frequency from 14.850 to 15.250
Using 12 lines padding
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Interlace | Virtualize | Vpad +12 l
ines | )
Setting registery video mode DALDTMCRTBCD720x512x0x60 with:
(60039/59854/60039) Modeline 14.150000 720 752 816 928 512 520 526 565 interlace

Opening  modes file for mode 720x512@54
Running Emulator: mame rfjet -resolution 720x512@60 -resolution0 720x512@60 -vid
eo ddraw -nocleanstretch -hwstretch -nochangeres -redraw auto -nothrottle -nomt
-syncrefresh -triplebuffer
Target refresh = 54.000000
Error creating DirectSound: 88780078
Average speed: 133.84% (8 seconds)
Setting registery video mode DALDTMCRTBCD720x512x0x60 with:
(59854/59854/59854) Modeline 15.850000 720 752 824 952 512 514 519 555 interlace

 Picture is OK but ... not a 320x240 (who talked about perfection ? ?)  


 Thanks for all your great work
(your gentoo ebuild seems interesting too ..... time to destroy another working mamecab  )


EDIT = don't worry abount dsound issue .. no drivers installed

[bitbytebit]

Hummm ...
ok with the help of -v -v -v -v -v -v -v (and from you two of course) i understand a little more how switchres works ...

 So .. here is THE big question ...
is there is any plan (possibility) to use a real 320x240 resolution for vertical games instead of 720x512 ?

Code: [Select]

D:\Mame>switchres rfjet --soft15khz -v -v -v
snip
......
Got Soft15khz registry modeline 720x512@60 - DALDTMCRTBCD720x512x0x60:
             "720x512@60" 15.850000 720 752 824 952 512 514 519 555 -HSync -VSyn
c interlace
Setup monitor limits min=184x108 max=0x608
Using interlace
Starting with Horizontal freq of 14.850 and Vertical refresh of 54.00
Increased horizontal frequency from 14.850 to 15.250
Using 12 lines padding
# 15.250Khz -> 15.700Khz: ( | Hfreq Change | Interlace | Virtualize | Vpad +12 l
ines | )
Setting registery video mode DALDTMCRTBCD720x512x0x60 with:
(60039/59854/60039) Modeline 14.150000 720 752 816 928 512 520 526 565 interlace

Opening  modes file for mode 720x512@54
Running Emulator: mame rfjet -resolution 720x512@60 -resolution0 720x512@60 -vid
eo ddraw -nocleanstretch -hwstretch -nochangeres -redraw auto -nothrottle -nomt
-syncrefresh -triplebuffer
Target refresh = 54.000000
Error creating DirectSound: 88780078
Average speed: 133.84% (8 seconds)
Setting registery video mode DALDTMCRTBCD720x512x0x60 with:
(59854/59854/59854) Modeline 15.850000 720 752 824 952 512 514 519 555 interlace

 Picture is OK but ... not a 320x240 (who talked about perfection ? ?)  


 Thanks for all your great work
(your gentoo ebuild seems interesting too ..... time to destroy another working mamecab  )


EDIT = don't worry abount dsound issue .. no drivers installed

It's actually about the monitor, you will get 320x240 with the --mo 2 setting because you'll be using a vertical monitor.  Default is --monitor cga, so on a CGA 15khz monitor you can't use more than 288 lines (vertical game, it wants 320 lines for height, too much), so it has to use interlacing and comes up with that 720x512 resolution.  Now using --monitor vga on your flatscreen should be better, and do the 320x240 fine.

Update:
So basically on your flatscreen to test,  "switchres rfjet --monitor vga -v --mo 0" will be needed, and you'll get the 432x320.  On your 15khz monitor you'll want to use  "switchres rfjet --monitor cga -v --mo 2" (default is cga type monitor) and you'll get 320x240 and it'll be correctly displayed vertically.  

[dapsaille]

Humm .. for now i'm only using my vga lcd monitor, not my 15khz monitor ...

 For exemple, if i use my original vertical pcb on my arcade monitor in horizontal position .... the resolution will be 320x240 like in mame, my monitor doesn't care if this is a vertical or horizontal game ..

 So why i cannot do the same with mame/switchres ?  

 I'm pretty sure that you've already answered me about this question but i must admit that my english knowledge is .... poor  

UPDATE too :

On your 15khz monitor you'll want to use  "switchres rfjet --monitor cga -v --mo 2" (default is cga type monitor) and you'll get 320x240 and it'll be correctly displayed vertically. 

 Be sure that i will do it tomorrow .. for now it's 01AM and my wife will strangle me with a jamma harness if i go to my egret 2 ^^

 Thanks.

[bitbytebit]

Humm .. for now i'm only using my vga lcd monitor, not my 15khz monitor ...

 For exemple, if i use my original vertical pcb on my arcade monitor in horizontal position .... the resolution will be 320x240 like in mame, my monitor doesn't care if this is a vertical or horizontal game ..

 So why i cannot do the same with mame/switchres ?  

 I'm pretty sure that you've already answered me about this question but i must admit that my english knowledge is .... poor  

UPDATE too :

On your 15khz monitor you'll want to use  "switchres rfjet --monitor cga -v --mo 2" (default is cga type monitor) and you'll get 320x240 and it'll be correctly displayed vertically. 

 Be sure that i will do it tomorrow .. for now it's 01AM and my wife will strangle me with a jamma harness if i go to my egret 2 ^^

 Thanks.

Sounds good, well not the strangle part , but I think they key is that you'll need to use the two different command lines for each setup and the vga flatscreen horizontal just isn't going to be perfect but you'll see with the second command and same setup on the vertical arcade monitor it should be close to perfect.  Definitely great to have you testing this too, the vertical monitor support is new so if there's anything needed, I'll make sure to fix it and make it work correctly.  I *think* it is good to go, but will be interesting to see how it goes for you on the vertical arcade monitor and if  there's anything else I need to do to make it work.

[dapsaille]

 Hello,

 i've juste tested like you said and i've got the same results as in my vnc session
(i must admit that i didn't trust that the results will be differents from a vnc session, my arcade monitor will not magically invert output from vga  )


 Good picture but not right resolution ...






Good resolution but ror applied .. ?






 Could it be possible to treat rfjet and other verticals roms as horizontal roms (but does it involve mame modifications) ?

 I've seen that in the second run (with mo 2) the mame commande line contain -ror ....

 I mean that for people like me who use a tate monitor, there is no difference about horitontal and vertical, we only rotate our monitors ..

 If i launch stock mame by default the picture is OK even in vga mode (except resolutions of course),
i need to do a 90degree rotation to the right with my head if i use an horizontal monitor to see the picture but ok for my vertical setup..
it is the expected results for my setup and it seems that mame or switchres WANT to treat this rom with a vertical condition who may be needed for vertical games on horizontal monitors but that don't seems to be needed for vertical monitors...
it may be the problem .. or not  

[Calamity]

Hi dapsaille,

Could it be that you've manually disabled the 'rotate' option in mame.ini?

The 'ror' param is there to do exactly what you need when no other rotation option has been modified. It's the method I was using with no problems. However, re-reading Mame's config.txt it seems it would be better not to use the 'ror' option in Switchres but the -norotate option instead:

-[no]rotate

   Rotate the game to match its normal state (horizontal/vertical). This
   ensures that both vertically and horizontally oriented games show up
   correctly without the need to rotate your monitor. If you want to keep
   the game displaying 'raw' on the screen the way it would have in the
   arcade, turn this option OFF. The default is ON (-rotate).

That may be the correct config for tate orientation.

[dapsaille]

Hi dapsaille,

Could it be that you've manually disabled the 'rotate' option in mame.ini?

The 'ror' param is there to do exactly what you need when no other rotation option has been modified. It's the method I was using with no problems. However, re-reading Mame's config.txt it seems it would be better not to use the 'ror' option in Switchres but the -norotate option instead:

-[no]rotate

   Rotate the game to match its normal state (horizontal/vertical). This
   ensures that both vertically and horizontally oriented games show up
   correctly without the need to rotate your monitor. If you want to keep
   the game displaying 'raw' on the screen the way it would have in the
   arcade, turn this option OFF. The default is ON (-rotate).

That may be the correct config for tate orientation.

 Calamity  .... thanks ^^

 It works perfectly with rotate 1 in mame.ini

 it is a real pleasure to retrieve exactly the same display as my pcb ....  

  Many thanks to you two for helping me ^^

 If i can do any test that you want (i've got 5 cabs, 2 are TATE) don't hesiTATE (huhuhu), and i will try the gentoo ebuild on one mamecab.

[bitbytebit]

Hi dapsaille,

Could it be that you've manually disabled the 'rotate' option in mame.ini?

The 'ror' param is there to do exactly what you need when no other rotation option has been modified. It's the method I was using with no problems. However, re-reading Mame's config.txt it seems it would be better not to use the 'ror' option in Switchres but the -norotate option instead:

-[no]rotate

   Rotate the game to match its normal state (horizontal/vertical). This
   ensures that both vertically and horizontally oriented games show up
   correctly without the need to rotate your monitor. If you want to keep
   the game displaying 'raw' on the screen the way it would have in the
   arcade, turn this option OFF. The default is ON (-rotate).

That may be the correct config for tate orientation.

 Calamity  .... thanks ^^

 It works perfectly with rotate 1 in mame.ini

 it is a real pleasure to retrieve exactly the same display as my pcb ....  

  Many thanks to you two for helping me ^^

 If i can do any test that you want (i've got 5 cabs, 2 are TATE) don't hesiTATE (huhuhu), and i will try the gentoo ebuild on one mamecab.

Ah great, so sounds like the -ror with -rotate basically are necessary, and I should add the -rotate option when the -ror is needed?  Had no clue about that -rotate option, and if turned off the -ror option doesn't work, odd but interesting .

[Calamity]

Ah great, so sounds like the -ror with -rotate basically are necessary, and I should add the -rotate option when the -ror is needed?  Had no clue about that -rotate option, and if turned off the -ror option doesn't work, odd but interesting .

It seems we can get rid of the the -ror param by just using -rotate / -norotate. So if we explicitly use those ones when dealing with vertical games, we can override the ones in Mame.ini. Then:

- For vertical games on horizontal monitor: -rotate
- For vertical games on rotating monitor: -norotate ( = -rotate + -ror)

[bitbytebit]

Ah great, so sounds like the -ror with -rotate basically are necessary, and I should add the -rotate option when the -ror is needed?  Had no clue about that -rotate option, and if turned off the -ror option doesn't work, odd but interesting .

It seems we can get rid of the the -ror param by just using -rotate / -norotate. So if we explicitly use those ones when dealing with vertical games, we can override the ones in Mame.ini. Then:

- For vertical games on horizontal monitor: -rotate
- For vertical games on rotating monitor: -norotate ( = -rotate + -ror)

What would horizontal games on a vertical monitor need, the -ror works for that but interesting that this rotate option takes the place of it, is it just -rotate for those too then?  Is it always rotating it right I'm guessing with -rotate, and never needs to rotate left since sounds like no one mounts  monitors that way?  So basically -rotate is -ror but overrides it and seems like a more universal option to say rotate or not to rotate.

Update:

Ok from what I can tell, basically for horizontal games on the vertical  monitor actually '-rotate -rol' does the same orientation as the -norotate does, so guessing -rol is necessary and the direction to actually do the rotation in that case.  Every other case seems to be able to use -rotate and -norotate except the horizontal game on a vertical monitor.

[bitbytebit]

I just uploaded compiled versions of SwitchRes 1.281-ec5b6ae which should be better about setting up the monitor orientation, please test to make sure I got it correct .  Also I added a few command line switches...

* --notriplebuffer - can avoid use of triple buffer and use waitvsync instead
* --threads         - use threads even with waitvsync on, only useful with patched mame (which I have windows builds up now for mess/mame 0141 with all cabmame/hiscore patches + threads patches to allow waitvsync and multithreading).
* Now the redraw option is only used in cases where it's twice the refresh rate, else it's off by default, auto seems to sometimes make mistakes.
* --noswitchres   - for those who want the command line setup wrapper features (LCD maybe), or just to test, basically avoid changing resolutions and use -noswitchres command line instead to mame without resolution args.

[Calamity]

Ok from what I can tell, basically for horizontal games on the vertical  monitor actually '-rotate -rol' does the same orientation as the -norotate does, so guessing -rol is necessary and the direction to actually do the rotation in that case.  Every other case seems to be able to use -rotate and -norotate except the horizontal game on a vertical monitor.

Yes, I believe so, after all that case (horizontal game on vertical monitor) is not a very common one but good to have support for it. On the ror / rol subject, rotation is documented in mame.xml using degrees, so that could be used to guess if the monitor was always rotated to the same direction or not, so 90º or 270º could refer to that (haven't tested that).

[dapsaille]

Could you please build with static linked library please ? ^^

 i don't have cygwin installed nor the knowledge to build under windows

[bitbytebit]

Could you please build with static linked library please ? ^^

 i don't have cygwin installed nor the knowledge to build under windows

It include the cygwin1.dll file which is the only one needed, so it's as static linked actually as it can be (cygwin doesn't allow static linking to that .dll file).  It just needs to be in the same directory switchres is in, or the windows system directory with other .dll files, and it should work like that.  So no need to install cygwin, that's just a runtime helper .dll included since it was compiled with cygwin.

[dapsaille]

switchres.exe v1.281 => 58Ko
switchres.exe v1.263 => 2056ko

   v1.281 complains about missing cygxml2-2.dll

 i wasn't talking about cygwin1.dll, i've got plenty in many folders on my win machine 

[bitbytebit]

switchres.exe v1.281 => 58Ko
switchres.exe v1.263 => 2056ko

   v1.281 complains about missing cygxml2-2.dll

 i wasn't talking about cygwin1.dll, i've got plenty in many folders on my win machine 

Oh oops, I'll fix that forgot the correct compile option, ha I should have seen how much smaller it was than usual.


Ok there's a new one up now with the fix, thanks for catching that, has been a week or since I compiled one and totally forgot about the way I was doing it.

[dapsaille]

Thanks ^^

 I will try this new version after dinner.

[SailorSat]

Somehow this seems to get very interesting lately
Have to spend more time reading this thread