Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

mamesick

Premium Members
  • Content Count

    105
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by mamesick

  1. mamesick

    ARCADE 0.212

    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.
  2. mamesick

    ARCADE 0.212

    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.
  3. mamesick

    ARCADE 0.212

    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.
  4. mamesick

    ARCADE 0.211

    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......
  5. mamesick

    ARCADE 0.211

    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.
  6. mamesick

    ARCADE 0.211

    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.
  7. mamesick

    ARCADE 0.211

    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.
  8. mamesick

    ARCADE 0.211

    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.
  9. mamesick

    ARCADE 0.211

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

    ARCADE 0.211

    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....
  11. mamesick

    ARCADE 0.211

    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?
  12. mamesick

    ARCADE 0.211

    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.
  13. mamesick

    ARCADE 0.211

    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.
  14. mamesick

    ARCADE 0.211

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

    ARCADE 0.206

    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.
  16. mamesick

    ARCADE 0.205

    It won't happen. Too much bad things happened when I was the mantainer of MAMEUIFX and the haters are still there. So feel free to leave if you wish. It's an hobby, not a paid job.
  17. mamesick

    ARCADE 0.205

    Revert modified drivers to original state is actually not a good practice, the update to new standards can be easily done with programs like WinMerge or others side-by-side diff tools. Though I don't want to criticize, I perfectly know how much time-consuming is keep alive ARCADE. Another change that seems gone away is the correct refresh rate for CAVE.CPP games, it's reverted back to the 271.5 divisor, instead of 272.0. SSV.CPP resolutions as already pointed out by haynor666 are reverted too. IIRC there are 23 resolution changes for that file, maybe I'll do the job by myself and upload the updated file on my mediafire account.
  18. I haven't understood how the new mechanism works too but this should work for example for thunderx.cpp subdevice<screen_device>("screen")->set_visarea(14*8, (64-14)*8-1, 2*8, 30*8-1); You must put this in the derived machine_config you want to modify. In thunderx.cpp for example you should find SCONTRA(CONFIG) in the derived machine_configs and add the line. In this way you can also change refresh rate and so on. Hope this helps.
  19. mamesick

    ARCADE 0.204

    Just did some tests on my side here, the new patch is fine. I don't see any real breakage in games that uses this CPU.
  20. mamesick

    ARCADE 0.204

    The fix for darkseal and vaportra is no more valid. The function that is commented out is now declared internally in the H6280 CPU core and is always enabled. So those extra lines listed in 202 diff are useless now. In file h6280.cpp infact there is: void h6280_device::internal_map(address_map &map) { map(0x1fe800, 0x1fe80f).mirror(0x3f0).rw(FUNC(h6280_device::io_buffer_r), FUNC(h6280_device::psg_w)); map(0x1fec00, 0x1fec01).mirror(0x3fe).rw(FUNC(h6280_device::timer_r), FUNC(h6280_device::timer_w)); map(0x1ff000, 0x1ff000).mirror(0x3ff).rw(FUNC(h6280_device::port_r), FUNC(h6280_device::port_w)); map(0x1ff400, 0x1ff403).mirror(0x3fc).rw(FUNC(h6280_device::irq_status_r), FUNC(h6280_device::irq_status_w)); } So the only way to enable again the fix would be comment out the line here but with the serious risk to break a lot of other games that uses the same audio CPU. Robbbert should remove both VAPORTRA.CPP and DARKSEAL.CPP files from his source. The code there is no more valid.
  21. mamesick

    ARCADE 0.198

    Remove that useless NPLAYERS.INI because all you need is MULTIPLAYER.INI as Robbbert already told you.
  22. Nobody fixed these bugs yet in the daily builds. I posted here for Robbbert, it will be up to him decide what to do. For reasons I cannot (and don't want) to explain, I don't contribute to the official MAME Development.
  23. http://mametesters.org/view.php?id=7075 http://mametesters.org/view.php?id=6970 http://mametesters.org/view.php?id=6932
  24. Linked an M72.cpp file which contains the fixes for the MAMETesters bug listed in topic title. They are very simple and small changes, easy to be mantained if you'll decide to not submit them to the official tree. http://www.mediafire.com/file/bn8ebnpgqlmbnmc/m72.7z/file
×
×
  • Create New...