johnparker007

If you've not changed any settings, this is usually that your PC setup is not quite powerful enough to run with the attract videos, as they are a demanding feature. In the ingame settings menu, one thing you could try is: Set the 'Pop-in Protection' and 'Distance/Resolution' sliders down to zero. Then exit to the frontend, and click Play to reload the arcade. Though usually if the PC is struggling, they will not work very well / cause performance issues. Best option in very likely to simply disable the 'Attract Videos' feature. In the future version of this software (Oasis), there will be an option to cycle through a few screenshots per machine instead of full video, but that is a very long way off.

Quoting so you get a notification, see above reply

This initial demo of Arcade Simulator requires the MFME software to run the fruit machines, available from this site. You'll need I think 4-5 'rep points' to download it, I've just given you another one. You'll need to download and install it, then within the MFME install folder run an update. Then when you next run Arcade Simulator, the fruit machines should work. Some of the newer ones can take a very long time to start up (minutes).

Haven't been looking at this project for a while (full WIP source code from link in my sig) - however I logged into the Mecca recently and saw that someone had tested that Ghostbusters test rom in their real Haunted House machine

I realised what this was whilst watching TV in bed I'd made the output sends (that transmit the button inputs from Oasis framework into MAME process) asynchronous, so they could arrive out of order, from back when I was having thread blocking issues before the Lua plugin strategy and was trying various stuff. I simply changed the output sends back to the standard synchronous behaviour, and now the inputs are 100% reliable, no stuck buttons issue

A little more work on the MAME/IO stuff - now using a plugin to process input commands, while simply reading state change output from console. MAME runs as a hidden child process of Oasis Layout Editor. Still some minor issue with 'debouncing' where a button can get stuck down in the emulation, I managed to get Hold 3 to stick later in the video... will need more work, but this technique seems good overall.

Hiya mate Yeah I got the -video none sussed out, though when it comes to games with actual video output (like all the video games, and some video fruits), I'll have to figure out/implement a bit more so I can get some kind of texture pointer or something. Also had it sending inputs, though was running into thread blocking issues with doing that whilst also pulling out the data for the lamps/reels etc. I could get around it via having MAME send it's output over the local network port, but it means end users needing to make a local firewall exception for mame process which is grotty (and still wouldn't solve a good way of getting video, which I think will need work in Mame source). So the next iteration is doing the lua plugin approach like BletchMAME project (worker_ui), working - it mentions various stuff about blocking in the plugin and the Qt c++ desktop app code, so he ran into the same issue, and managed to fix it with his plugin approach. I don't think I can use his approach for video though (he's pointing it at a different Hwnd/widget handle, it's all a bit windows specific and hacky, it works for the BletchMAME use case, but not really for cross platform Arcade Sim use case), we'll need something better for more control... Great news that you are looking at more fruit machine emulation, good work man! And once I have the basic non-video IO working without blocking thru Lua plugin, I'll get a couple of the older Blackbox / Mpu1/2 going for a demo that'll be running your drivers on the Mame backend (as this new approach can use the latest mame.exe)

For those that are interested in behind the scenes info on Arcade Sim/Oasis, providing a small update on this unfolding major crisis in the game engine industry (Unity Engine Install Fees). In lock-step with some other factors relating to my career, we will hopefully have the finalisation on which game engine Oasis/Arcade Sim will be built on around Jan-Feb 2024. The current shortlist to replace Unity Engine for all FME-related projects from me and any future collaborators (on Oasis and its related sub-projects such as the new Arcade Simulator) is Godot Engine, Unreal Engine or Flax Engine. This is subject to change before Q1 2024, but that's where we are currently. Of course this will slow things down compared to sticking with Unity, and yes, a project like Oasis/Arcade Sim wouldn't be actually affected by these Unity license/fee changes as they currently stand since it is free, but; Unity is no longer viable for me, as I will be continuing to use the same engine for my hobby projects as I do in my career, so that I'm continuing to develop complementary skills to literally pay my bills. Such a shame, but this is where the industry is at right now. This is also the sort of action that needs to happen (migrating even free projects with potential to become quite popular in the coming years), as a cautionary tale for any future execs who think they can pull something like this, and not destroy the game engine company they are working for. It's so frustratingly myopic and short-term share price focused, sigh... Here's another video by a prominent youtuber, continuing to cover the events as they have unfolded so far:

It will be interesting to see if that decline continues. Platforms like Unity exist because of developers, and game studios. The whole community is quite rightly completely up in arms at this barely legal bait-and-switch. While the effects won't be immediate, as studios large enough to be shafted by this, are also often complex enough that the Unity development pipeline cannot simply be changed (so we're kinda locked in for a good while). We're all eyeing Unreal and Godot (and there are a couple of other potential options) at this point for long term game engine/tech stack transition plans. So this will make Unity's profits go up in the short term... but long term they have put the final nail in the coffin (Unity has been rotting for the past 3-4 years). Unity will almost certainly wheel this back to something less shitty, but the damage has been irrevocably done. No new studio in their right mind is going to choose Unity as their tech stack, and existing studios are now considering the long term strategy to move away. It's the end of an era - Unity was and is a great engine, but the only thing constant is change I guess The guy who is now CEO of Unity, was previously CEO of EA - he was planning to have an in-app purchase when you reload your gun in Battlefield. He publicly called all Unity devs who don't want to heavily monetise their games via in-app purchases as 'fucking idiots' (his exact words)... and he's been selling off chunks of his Unity shares pretty much every month for the past year while buying none back. The whole thing is screwed!

I feel like I need to smoke a little something reading this first thing in the morning!

I am keeping a very close eye on these new 'Unity Install Fee' developments, as they relate to Oasis. Currently the plan is to build Oasis on Unity, however they have recently announced an insanely greedy plan that will potentially kill off lots of small studios (especially ones that create 'free to play' games, like mobile games with IAPs). In a lot of cases (i.e: commercial free-to-play games), the model one tries to achieve is many millions of users, but a very small 'ARPU' (average revenue per user). If Unity want say $0.15 per user, and you only actually earn $0.10 per user, you've now gone from a profitable game, to one that in reality costs you more than you receive! While this new 'Unity Install Fee' would not affect Oasis (since Oasis is free), I suspect this may signify the beginning of the end for the Unity game engine. Viable yet unpreferable (for a bunch of technical reasons I don't want to get into right now) alternatives are Unreal Engine, and Godot Engine. Unity is 'going public' soon (so people can buy shares in it on the stock market), and is also now being run by the a-hole who used to run EA, with all the lootboxes and other toxic cashgrab IAPs, so it's clear why they are driving this excellent game engine into the ground; ca$$$$h. Ugh, the enshitification of yet another great product, thanks modern capitalism. On the plus side, we already did the very 'game engine specific' proof of concept with the initial Arcade Simulator project (to prove we could run a massive arcade with 100s of machines on a modest spec PC)... so a lot of the upcoming near-term work in Oasis has to do with stuff that is fairly easy to port to another engine. Things like finishing up the MAME emulation IO, the Oasis Layout Editor project format, the 'safe screen scraper MFME extractor' system, the MAME layout export system, the machine+layout formats (for use in the new 2D and 3D Oasis modules like Arcade Sim v2, standalone machine player, etc) - these things are not so closely tied to Unity in the new Oasis project (they were very entwined with Unity in Arcade Sim, but the plan was already to decouple these formats with Oasis, so got a little lucky there). So as and when I can do bits and bobs of work on Oasis, it will be in those areas... and we'll see how this whole thing plays out! Here's a quick rough video a dev has made about this, I'm sure more will follow as this news (about Unity, not Oasis! ) goes mainstream:

One day in the future, it is planned ...very old proof-of-concept video:

Yeah it's confusing, since the DIPs are adjustable (in MFME) without the service door adjustment, but they are also inside the machine... I will work it into the Oasis UI design then, so the internal stuff like DIPs/SP keys require a door open (or a popup saying 'Opening service door to perform adjustments' when they are clicked on). I'm all about making things as easy to use as possible

Thanks, that's great info I may build that into the Oasis UI (so to adjust the SP keys, there's a service door switch above with an info/tooltip, so it's simple to use but realistic)... good stuff

I notice that in MFME, the stake/prize/% values can often not be changed, they are populated presumably from the ROM but then ghosted out: ...but, in MAME, they can be changed, and on rebooting, the startup message shows the new values are live: Same game (Capt Scarlet - Ace - JPM Impact hardware), I adjusted from the default of 98% to a value of 70%, and on reboot the new value is live. What's the deal here? I thought the stake/% 'keys' are things like those 9 D pin dongles, and if you plug in different ones, it adjusts the values... so why does MFME prevent this from being adjusted? I suspect I'm missing something... (I ask as planning to in the future build these adjustments into Oasis, but wondering if some ROMs should actually prevent these adjustments for true preservation of the original hardware behaviour - i.e: is this a mistake in MAME to allow these to be adjusted, that we need to fix?).

Done a little more hacky testing, this renders basic 2d reels, synced with the emulation. Kept MAME window visible so I can press keys in MAME for the moment to drive the emulation (play the machine). Ultimately MAME will be a hidden child process and Oasis will be passing inputs through:

Another little update to Oasis Layout Editor - a bunch of hardcoded bits, but this now shows proof of concept of the new way of interfacing to read component states from MAME: There is no 'screen-scraping' taking place here to flash the lamps in the editor, and so also no need for 'data layouts' (previous MAME/MFME work for Arcade Sim has all relied on the hideousness that is screen scraping data layouts). I'm instead pulling a component data feed direct from MAME. Need to suss out how to get the MAME.exe running as a totally hidden child process - good to see the idea works anyway, this new technique of reading the lamps etc has not been done before

Robin_Hood_NumberReelWorking.zip

I have reordered the reel symbols to match Pot of Gold, and copied settings, and amazingly that now works! Weird, I'll have to look into this more at some point, seems like it shouldn't make any difference, but for some odd reason it does. Hmmm I'm not feeling super great, so I'm not on top of my game - doesn't seem like it should have mattered though (the changed between original and this). Here is is anyway, number reel now works between new games:

Checked the DX of Pot of Gold and the number reel works correctly. Will transfer all settings over and check on Robin Hood...

Not sure of any other layouts with 6 symbol reels offhand, but I think it's most likely an emulation issue rather than a layout config issue unfortunately...

Not sure, there's something iffy going on for sure (I could see without matching exactly your layout)... I can see it behaving inconsistently between layout loads, I've replicated your screenshot of your layout setup, and done a video: Here, 2 on number reel moves 5 spaces: https://youtu.be/DEnLg05g-4M?si=xLVLsI5PTe0r7bZ6&t=13 Here, 2 on number reel moves 6 spaces: https://youtu.be/DEnLg05g-4M?si=xLVLsI5PTe0r7bZ6&t=170 (there's lots more inconsistencies, these links just to save time for reviewing the difference) Perhaps it could be configured to work correctly in MFME between relaunches of the layout, but I'm still leaning towards a bug in the reel controller emulation - would love to be wrong though, since we can't fix the latter! Here's a zip of that updated layout to exactly match your screenshot: Robin_Hood_(Ace)_NumberReelBug.zip

Some are from when I did the initial 2016 run: Once I've finally developed the Oasis layout editor including MFME importing and MAME exporting, others can build/convert the classics to internal MAME layouts, to help with development over there (for instance with this reel controller bug, if it is one).

Are you sure this woks correctly? After closing MFME then reloading? I made a 6 symbol reel, and still see the issue - can be configured, but upon restarting MFME and reloading, the number is wrong again. I think it still might be a bug in the reel controller emulation code... RobinHood(Ace)-numberReelBug.zip I've attached the layout to try...

Ah nice one, so not reel controller emulation bug, that's a relief!