No more native game resolutions in MAME?

[AndyWarne]

Not sure if this is true but I have heard that DirectDraw support will be removed from MAME.

As native, unscaled resolutions were never implemented in D3D, this means the end of native resolution support using ArcadeVGA or other solutions, in standard MAME.

This seems a little strange as the stated aim of MAME is to emulate the original game as closely as possible. Making scaling compulsory does not seem to fit in with this principle! No more perfect emulation with scanlines on a standard res monitor.

[adder]

hello Andy, there's some chat about this over at the mameworld forums in case you were wanting to discuss/get further insight with the devs about this matter

here:
http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=350392

[haynor666]

Actually there is quite easy hack to maintain pixel ratio 1:1. Source code can be obtained from cabmame.

[Howard_Casto]

Man the mame team is making some goofy decisions as of late.

I have no issue with them removing direct-draw, but a solution for scaling needs to be put in place before they remove it.  If there is a hack, perhaps it needs to be cleaned up and made an official option in mame?

[haynor666]

There is unevenstretch option but it doesn't do anything in windows, maybe it works in OpenGL or under Linux or Mac OS.

That's sad but integer stretch is not popular these days, most of people that have cabs prefer LCD monitors and using effects rather than CRT with perfect pixel aspect. Anyway in most cases groovymame is solution for this problem.

About that hack - http://mame32fx.altervista.org/forum/viewtopic.php?f=1&t=33&start=140#p1505
This source change was derrived from cabmame years ago but with some changes probably will work also in latest mame.

[keilmillerjr]

most of people that have cabs prefer LCD monitors and using effects rather than CRT with perfect pixel aspect.

LCD is east to set up with mame. CRT is not. But after buying a neo geo with a CRT, I will never go back to the future! Regardless of all the lcd effects and shaders, it can not be replacated on a lcd.

[Howard_Casto]

Wait they are removing 32 bit support ?!?  Removing direct-draw is questionable, but still has some logic behind it.  Removing 32bit support is insane!  If you buy a brand new state-of-the-art pc game it still uses a 32bit executable.  Why?  Because there are still a ton of people that run a 32bit os and many processors, while technically 64bit, have issues running programs in 64bit mode.  Shoot even stuff like photoshop and professional graphics suites have 32bit variants for the reasons I mentioned.

This isn't like back in the day when dos support was dropped because windows stopped supporting dos.  You can still get a 32bit version of windows 10. 

[haynor666]

They probably remove 32 bit support but this is not 100% certain.

BTW. Creating 32 bit version was necessary probably due some compability with old app. Also many people still using 7 or 8 32bit so upgrade will be also 32 bit. Something tells me that next windows will 64 bit only just like server systems are right now.

To my post with source I forgot to mention that this source still needs work to adapt it to LCD. Originally was created for CRT with no intention for keeping aspect ratio (You don't care about this on TV or arcade monitor with aspect 4:3). To fix this some part of ddraw code must be implemented into this patch:

Code: [Select]

-//============================================================
//  compute_blit_surface_size
//============================================================

void renderer_dd::compute_blit_surface_size()
{
   INT32 newwidth, newheight;
   int xscale, yscale;
   RECT client;

   // start with the minimum size
   window().target()->compute_minimum_size(newwidth, newheight);

   // get the window's client rectangle
   GetClientRect(window().m_hwnd, &client);

   // hardware stretch case: apply prescale
   if (video_config.hwstretch)
   {
      int prescale = (window().prescale() < 1) ? 1 : window().prescale();

      // clamp the prescale to something smaller than the target bounds
      xscale = prescale;
      while (xscale > 1 && newwidth * xscale > rect_width(&client))
         xscale--;
      yscale = prescale;
      while (yscale > 1 && newheight * yscale > rect_height(&client))
         yscale--;
   }

   // non stretch case
   else
   {
      INT32 target_width = rect_width(&client);
      INT32 target_height = rect_height(&client);
      float desired_aspect = 1.0f;

      // compute the appropriate visible area if we're trying to keepaspect
      if (video_config.keepaspect)
      {
         osd_monitor_info *monitor = window().winwindow_video_window_monitor(NULL);
         window().target()->compute_visible_area(target_width, target_height, monitor->aspect(), window().target()->orientation(), target_width, target_height);
         desired_aspect = (float)target_width / (float)target_height;
      }

      // compute maximum integral scaling to fit the window
      xscale = (target_width + 2) / newwidth;
      yscale = (target_height + 2) / newheight;

      // try a little harder to keep the aspect ratio if desired
      if (video_config.keepaspect)
      {
         // if we could stretch more in the X direction, and that makes a better fit, bump the xscale
         while (newwidth * (xscale + 1) <= rect_width(&client) &&
            better_mode(newwidth * xscale, newheight * yscale, newwidth * (xscale + 1), newheight * yscale, desired_aspect))
            xscale++;

         // if we could stretch more in the Y direction, and that makes a better fit, bump the yscale
         while (newheight * (yscale + 1) <= rect_height(&client) &&
            better_mode(newwidth * xscale, newheight * yscale, newwidth * xscale, newheight * (yscale + 1), desired_aspect))
            yscale++;

         // now that we've maxed out, see if backing off the maximally stretched one makes a better fit
         if (rect_width(&client) - newwidth * xscale < rect_height(&client) - newheight * yscale)
         {
            while (xscale > 1 && better_mode(newwidth * xscale, newheight * yscale, newwidth * (xscale - 1), newheight * yscale, desired_aspect))
               xscale--;
         }
         else
         {
            while (yscale > 1 && better_mode(newwidth * xscale, newheight * yscale, newwidth * xscale, newheight * (yscale - 1), desired_aspect))
               yscale--;
         }
      }
   }

   // ensure at least a scale factor of 1
   if (xscale == 0) xscale = 1;
   if (yscale == 0) yscale = 1;

   // apply the final scale
   newwidth *= xscale;
   newheight *= yscale;
   if (newwidth != blitwidth || newheight != blitheight)
   {
      // force some updates
      update_outer_rects();
      osd_printf_verbose("DirectDraw: New blit size = %dx%d\n", newwidth, newheight);
   }
   blitwidth = newwidth;
   blitheight = newheight;
}
EDIT. This looks bad - http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=350078&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1455665999

[Haze]

If you buy a brand new state-of-the-art pc game it still uses a 32bit executable.

from what I've seen an increasing number are shipping without one, it's one of major bits of legacy cruft that needs to go away, and the industry does seem to be catching on to that (about 10 years too late, but still)

this is fairly logical, most games are developed with consoles in mind as the primary target, those are 64-bit, 8GB Ram at this point in time, 32-bit is rarely tested and the 32-bit RAM limit does get hit.

[Howard_Casto]

I get what you are saying but my point is it hasn't went away.  If the next version of windows is 64bit only then fine, drop it, but you wait until 32bit is no longer an option.  Right now it decidedly is and I honestly don't see that changing any time soon.  Windows hasn't had any major compatibility changes since XP, and there were only minor compatibility issues between 98se and xp, so if they drop 32 bit support that's 15+ years of apps that they just kill and people aren't going to be real happy about that. 

[B2K24]

Some people haven't changed any of their hardware since XP. It doesn't mean the project should cater to them.

If I walk into Best Buy right now I can't buy any laptop or desktop that's 32-bit. Everything is 64-bit and has been for a very long time now.

[Haze]

I get what you are saying but my point is it hasn't went away.  If the next version of windows is 64bit only then fine, drop it, but you wait until 32bit is no longer an option.  Right now it decidedly is and I honestly don't see that changing any time soon.  Windows hasn't had any major compatibility changes since XP, and there were only minor compatibility issues between 98se and xp, so if they drop 32 bit support that's 15+ years of apps that they just kill and people aren't going to be real happy about that.

The only place I've seen 32-bit Win10 is on old machines tho, unlike with W7, every single new W10 machine I've seen has been 64-bit. 

I think 32-bit is only really maintained to keep business happy.  For any kind of gaming related machine, especially going forward, you're looking at 64-bit being the majority.  MAME already heavily benefits from 64-bit.

For years people have moaned that MAME hasn't moved with the times, once we start getting 3D acceleration etc. in 64-bit will the the least of your worries as to take advantage of any of that you're really going to need some good hardware.

Also, even with us bending over backwards to cater for the older hardware crowds the general attitude from people on older hardware has been to while, moan and recommend old versions anyway, making a lot of that effort feel rather pointless.

[AndyWarne]

Getting back to the stretch issue, the code to do this would be very simple, ie find the best available screen resolution and then add equal top/bottom/side borders to the displayed image so that it matches the screen resolution rather then stretching the game image. There is already a hack which can do this.

Does anyone know who is responsible for video in Mame these days? I know who it used to be but I dont think he is involved any more.

I dont hold out much hope though, I have been banging on about native resolution support in D3D for around 5-6 years to avoid DirectDraw issues but they have never done it.

[haynor666]

The easiest way would be create account on github and push your code (the best would be use ddraw scalling code because code from cabmame does not care about aspect ratio - not too good for LCDs) to mame rep.
Someone will probably get interest in it.