MAME news

[Robert]

The release of 0.227 has been delayed. https://www.mamedev.org/?p=489

Most of that post is incomprehensible technical jargon to the average person, so let's make it simple.

A change to the memory system was installed about 2 weeks ago, without any testing. It was therefore no surprise to find that many systems, particularly arcade ones, now crash at start. Or, if they started up, the graphics are bad, or the game doesn't work. Nobody knows how the new memory model works, but the logical approaches that should work no longer do, so it's now guesswork. Therefore it will take a long time to fix, or even identify many of the regressions.

This also means that HBMAME cannot be kept up to date, as the new memory system breaks Neo-Geo. HBMAME is therefore on hold.

MAMEDEV have released new tools for compiling - https://www.mamedev.org/tools/

In December, MAME will move to C++17. At this it is unknown what effects this may have, but it's possible that XP or 32-bit might no longer work. Another major change alluded to in the first link is that variables which by default are initialised to zero will be left at their random values, which could cause weird regressions. It's not sure when this will be done, but probably by Christmas.

Now for some good news....

Major work has been done on WinUI (this is MESSUI and MAMEUI). All known bugs have been fixed. Many new adjustments have been added. Support for BGFX, OpenGL and GLSL shaders has been added. You can select plugins. The GLSL shaders that are part of the ARCADE64 package will be also supplied for all the other builds too.

WinUI is no longer considered a development system, but as a production system. This means that the debugger controls have been removed. If a game had the debugger enabled, it will be deactivated at start, so the game runs normally.

Some parts of WinUI have been deprecated. This means those parts are no longer supported, and will be removed soon, when convenient. Those parts are:

- verbose.log and winui.log : These are leftover parts of the debugging environment, and are known to cause slowdowns

- shortcut keys. These are a relic of a bygone age. Use your mouse.

- inbuilt help. This hasn't been updated for about 20 years. Modern windows doesn't have any offline help, so WinUI will follow. All help text and files will be removed.

- manufacturer cleanup. WinUI attempts to adjust the manufacturer names to overcome the variations on a theme from MAME. This will be removed, and the cleanup will need to be done in MAME instead.

--

ARCADE64 has not yet received the upgrades, but it is planned. The M1FX button and option will be removed. One change that has been done is that the GLSL folder and support have been removed. The shader files now reside in the HLSL folder, the same as is done in WinUI. Note that ARCADE64 currently requires the shaders to be in the HLSL folder, where WinUI allows the shaders to be anywhere (although the HLSL folder is recommended). If you use ARCADE64 with shaders, you'll have to move the shaders from the GLSL folder to the HLSL folder.

For those of you with 4k screens who are wondering when proper support will be added, all I can say is that I don't have a 4k screen, and have no plans on getting one. Further, I have no idea what programming is needed to add the support. However, https://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=350549&page=0&view=collapsed#Post388272 is supposed to work.

[Robert]

Update... the change to C++17 just happened. It's not known yet how that affects us.

[Robert]

The C++17 conversion was a complete success. Apart from a few minor errors all our builds compiled and ran perfectly well on Windows 10. This is what happens when proper testing is done - the implementation is painless.

 

[Agard]

Glad to hear all went well. Thanks for info

[StHiryu]

Thanks for the work of all involved. Will see if the new mame exes can work on Xp. Also I will check some old bugs in the winui, most of them related to the "record to avi oputput" feature.

[Robert]

Nobody has reported issues with that. First I've heard of it.

[StHiryu]

5 hours ago, Robert said:

Nobody has reported issues with that. First I've heard of it.

Yes I've said some releases ago. Anyway will try again when 227 comes out and post here.

[StHiryu]

-Done some testing about mentioned bug. Here is what I've found with a fresh and naked MameUI 0.226:

1-Launch one rom (outrun) and play. A outrun.ini is generated at the ini folder.

2-Create an arcade.ini with the following:

#
# CORE CONFIGURATION OPTIONS
#
readconfig                1
writeconfig               0

3-Launch outrun again. The outrun.ini file is not created anymore. This should be the desired behaviour.

4-All The File, Play ... options from the WinGui at the top left generates again an outrun.ini in the ini folder, even with the arcade.ini with writeconfig               0 (Right click on the game, Play and Record input..., makes the outrun.ini appears again too)

5-If you run the command from cmd --> Mameui64.exe outrun -aviwrite outrun.avi, the outrun.ini is not created.

So it seems somehow those options from the GUI ignore the writeconfig               0 at arcade.ini

[Robert]

If you change any settings for a game, they have to be saved somewhere so that MAME can pick them up when you run the game. Real frontends send a long string of command-line options, but since MAMEUI is actually joined to MAME, the settings get saved in the ini file instead.

writeconfig is only for MAME, not MAMEUI. So, if you were playing the game, and you used the tab menu to change something, it won't get saved unless writeconfig is 1. But changing something in the MAMEUI properties will save it every time.

[StHiryu]

That's the point, nothing is saved or changed. The only difference is using the Run GAME and the File, Play ... options. In the first case no game ini is created, in the second case the ini is always generated again and again.