mamesick

I guess that the support for saving overclock has been dropped out during the recent big change in internal UI code made by an official MAME Developer. I don't know if Robert will be able (or better will have the time) to re-implement it.

All is working fine now. About the values in PLUGIN.INI, those are the default values, read by the core in the \plugins\ directory. Each plugin has its own directory with a plugin.json file that contains a value for "START" which is true or false. This becomes 1 or 0 in the INI file. You can edit manually the file to enable or not a plugin before startup but at the exit the PLUGIN.INI file will be saved again with default values, so user changes will be lost. This because the saving routine will read again the \plugin\ directory and will store again the default values in the .json files. Weird. This happens here too. It's something that probably needs investigation. Though plugins can be enabled directly in the core in "Miscellaneous II" section of Default Game Options and will stay stored forever until user will change them again. So maybe this solution is the best one and PLUGIN.INI support could be dropped out.

Looks like there is a bug in PLUGIN.INI creation at startup.... Fresh install, PLUGIN.INI is created but it is empty. And so it is when you exit the emulator. It is saved again but it's an empty file. In WINUI_OPTS.CPP around line 1849: while (iter.next(pluginpath)) { opts.scan_directory(pluginpath,false); } Looking at how it is used in CLIFRONT.CPP should be: while (iter.next(pluginpath)) { osd_subst_env(pluginpath, pluginpath); opts.scan_directory(pluginpath, true); } I don't know if it is correct fix, but I used the code above in my source and PLUGIN.INI is correctly created.

CAVE and SSV are already included. CPS1 patch has been removed. It's up to Robert decide to re-implement it or not. Personally, I find that underclock hack too outdated, it's 15 years that is floating around......

Those patches don't seem to be too much invasive for Arcade source code. I also have some doubts they will be implemented soon. If it's destiny that this project will end, fine. I sincerely cannot take the whole job again in my hands. Yes, we'll see.

This is great from you. CPS1 error was probably the CPU speed hack for SF2T, the famous underclock to have correct speed. I encountered in your source, yes, but probably I have forgotten to update/remove it. I don't think it's a big loss. Though if you want to re-implement it or not, I'm fine with your decision. Maybe I've been too harsh in one of my previous post, though don't forget that I'm still around. If you need help or are too busy to keep your source updated, simply try to ask. I cannot assure I will be always available, but I'll try to do my best and I'm sure others here think the same. Reverting all features is not the best way to proceed, until there's no other choice.

I have a bad feeling that your caching code in GAME_OPTS.H is the cause of the crash. I haven't it included in my source, I don't need it for the moment because my personal build support only around 160 source files in ARCADE.FLT so my startup is in practice immediate, no need to cache all the emulation flags and so on. I support only the drivers with games I play, shame to me... Seriously, I'd like to help more than this but it's too hot here and I cannot start a SYMBOLS build to debug the crash. It would take too much time and my PC and my two HDDs overheat easily. When it crashes? Immediately after the splash screen, during the building of folders or later on? I'm curious.

I still have to check all the WINUI code but surely there's no JPEG support, screenshots are loaded differently (why in Arcade check for "system" name?), treeview folders are not ordered alphabetically but there's a "logic" order.... Just to name a few.

Here we go with MOPTIONS.CPP http://www.mediafire.com/file/sp7zp260wmni81e/moptions.cpp/file Obviously it must go in \FRONTEND\UI\ folder

Sorry the file MOPTIONS.CPP is not included in the package. I will upload tomorrow now i am away from home. It contains the color codes....

Ok, the updating job seems done. http://www.mediafire.com/file/p33g8p8pcnwefn2/ARCADE.7z/file The source, except for the \SCRIPTS\ directory (I don't know why all those files are there) is in sync with this commit: https://github.com/mamedev/mame/commit/f122bb805a2d9a14257d3de804d804ec56694a39 No time to compile, but all should work. WINUI is updated and fixed, all ARTWORK options are gone from the core and a small fix was needed by GAME_OPTS.H to compile properly. UI files are all updated, the color codes are still alive. \DRIVERS\ and \VIDEO\ are updated too, TAITO_F3 is back and so the RASTER_HACK for NEOGEO.CPP. All core files are updated. It's mandatory that if exists, \INI\UI.INI have to be deleted before start the emulator. I'll leave to you Robert the fun to check some DRIVERS changes I implemented and ported to your source. If you don't like them, you can simply revert/remove them. Mostly are resolution fixes. Let me know if there are issues with the source as soon as possible. Side note: this black scheme for the forum is really eyes-unfriendly. Would not be possible use a light scheme?

My local source is updated and works fine. Color codes must be moved from UI.H to MOPTIONS.CPP in HEX format. The only thing users will need is to delete /INI/UI.INI before starts the emulator. WINUI compiles fine, a couple of fixes are needed though. My local source code is different in some ways from current ARCADE 0.211 one, I never implemented some of your changes. If I'll have time, I'll try to sync my changes with yours, so some features will not go away. This could require some days, we'll see what will happen.

I could help too, I have here in my local source fixes/hacks that seems are gone away in ARCADE. I have no time to check all of them, but I'm pretty sure that for example CAVE.CPP Refresh rate is lost, SSV resolutions changes idem..... Didn't checked NeoGeo, but it seems the raster-hack is gone too. I could mantain the hacks regularly, maybe with a delay of one/two days from official release. Though if there's no interest and the new development policy is "I DON'T CARE, I MUST RELEASE IT" simply to have more time to dedicate to the MESS side of the project, let us know Robert. We all know that you are also a MAME Developer, so there's nothing wrong with it, but I don't like to see the ARCADE project "abandoned" or "bastardized" simply for that reason. TAITO_F3.CPP hacks were very simple to update to CAM900 changes, it was only a matter of renaming a couple of variables, but it seems you have been too lazy to have a look and do the job. My opinion, nothing personal or against you.

That's not true. M_GAME is still valid. The diff posted by Haynor666 compiles without problem with current GIT. Please re-implement it.

IIRC that neogeo raster hack was implemented upon request to "fix" some gfx glitches that happens on real hardware. The sengoku2 check can go away, yes, but the rest should stay, mostly the "screen().update_partial(scanline + 1);" is important because fixes the position of the raster beam in a lot of games like for example Zed Blade and golf games. The check if raster irq is enabled (m_neogeo_raster_hack) could go away too but in this case the glitches mentioned above will appear again, mostly noticeables in Shock Troopers 2nd Squad intro. It's up to you, Robert, there's no problem at all if you want to remove the code, I simply explained what it does.