johnparker007

Ok so it sounds like it's the videos! If you have a Monobehaviour per machine that is controlling the videosnap playback, perhaps you could implement a status... so you'd have something like: VideoSnapPlayer.cs public enum Status { Uninitialised, Initialising, Initialised, Playing, Stopped } So then you'd have a 'MachineManager.cs' or some such overall controller script, and each of your machines is registered (and potentially instantiated by) this machine manager. So then the loading screen would only disappear when the Machine Manager says that all of the machines are fully initialised, i.e: 1. Show Loading Screen 2. Load Scene 3. Initialise The Machines 4. All Machines Are Fully Initialised/Playing 5. Hide Loading Screen I'd probably go that route as a first attempt to solve your issue

Yeah this original Arcade Simulator is pretty much feature frozen as it is now, as I'm getting started on a suite of programs (Oasis) that will ultimately lead to the successor. Unfortunately the input system that was set up was a little basic, with no definable controls. However, some have had luck with running a program like Joy2Key, that allows mapping the inputs of your joystick to generate key presses. If you can get that set up, I believe the standard keys I set up were QAOP (Up/down/left/right) and Space/M/N/B for button 1/2/3/4. That is specifically for the video games. So if it's just the video games you want to control with the joystick, that might be a way...

When you say 'enter' the games room, do you mean you have a 3d environment, and when you walk through the door of your room containing the games, there is a pause? If so, then you'd want to use the Profiler tool, and you'll see a spike on the graph as you enter the room. You can then drill into it and see what functions are causing the pause/lag. Probably be loading some textures and/or instantiating some gameobjects... so you'll want to ensure you fully load/cache everything at level init.

Hi @MTR1 Apologies, I've had some issue with the webhosting... anyway I've updated the link in my sig, to a direct link to the Installer. This is the updated link: [ Arcade Simulator ] Pre-alpha installer: https://tinyurl.com/2kcrkprh

Not yet, but I'll be able to adapt one from this cabinet, as it has the similar metal trim: All the cabinet stuff is being redone anyway, so there's a bunch of work there either way. Since we're going full open source, the leading open source 3d modelling package is Blender (https://www.blender.org/). So before, I was building cabs from scratch in 3DS Max, or using @Spidy21982's models from Cinema4D, and importing them to 3DS Max for further adjustments, and then from 3DS Max importing to Unity. So now that 'final' 3d modelling package in the pipeline will be Blender, and the idea is that anyone will able to create the Oasis 3d cabinets, by using most likely .glTF format to export from Blender. So in the original ArcadeSim workflow for the cabinet above, it was: Cinema4d -> .obj -> 3DS Max -> .fbx -> Unity Editor import -> Arcade Sim The new workflow would look something more like: Cinema4d -> .obj -> Blender -> .glTF -> Oasis MachineEditor -> Oasis LayoutEditor -> Oasis ArcadeSimulator (though of course others may choose to develop their models direct in Blender skipping the C4d->.obj step, or in some other priliminary package like Maya, 3DS Max etc). The new workflow will be able to be fully completed by people other than me As that is the plan for everything ultimately, so I'm no longer needed to develop new machines/arcades for use. It will be quite a long time before I'm at that stage though, depending on personal health and also how much time I divert into improving the emulation in MAME...

Did a little more tonight, now have the vertical reel scaling calculation figured I think (close as it needs to be for this Import Preview anyway): Also got a new 'MFME' menu in, starting to move MFME stuff to that - so this will be for the MPU4 lamp correcting function (to fix wrong lamp numbers in MFME layouts where they've been mapped to match wrong characteriser lamp column value)... think this will be the next task, so I can get Nickelodeon lamps correct:

I moved to a different layout (MPU4 Nickelodeon) to get some more standard reels to check work so far before thinking about some generic basic reel lamps for the MFME Import Preview window... revealed various other things to do/issues: Segment displays not working - this is an emulation issue to fix in MAME (just down to config I think) Reels show too many symbols - this is a problem with the scaling work I did using the Andy Capp reels, so I have more to do there to derive approximately similar scales to the reels shown in MFME Lamps scrambled - I do have a fix for this, the MFME layout is actually the one that is wrong So the 8x Chr lamp values are set wrong, and then the lamps were adjusted by trial and error until they worked. As we are now using the correct MAME lamp values for emulation, the MFME lamps appear scrambled. Fortunately I already wrote a 'MFME lamp number fixer' function in my earlier work in Arcade Sim, so I'll have to port that across and then the imported MFME layout will get its lamp numbers remapped to the correct ones No blended lamps - I just haven't done those yet, but I will add to the list of things to make the MFME Import Preview more accurate So yeah, tried a new machine just to check reels and revealed a pile of issues haha

More prettying up of the MFME Import window in the Layout Editor - more correct reel scaling, and reel overlay images: Technically not necessary to make this stuff look that accurate, as this is just to store imported MFME layout so when a layout artist (or someone working on converting layouts to 3d machines) saves a Layout Editor 'project file', this can be stored along with the actual 3d Oasis views of the full panels and individual panels. That said, it's bothersome if it looks scruffy, it should kinda resemble the imported MFME layout! So I'll prob also do reel lamps, and maybe even the odd 'fake perspective' vertical 2d reel scaling effect that MFME does (so symbols at top/bottom be squished vertically to approximate a 3d effect)... just so things look vaguely correct, for this Import preview view

Just WIP stuff at the mo

All bare bones and buggy, but have now successfully importing (and running) an MFME layout in the Layout Editor, extracted using the 'MFME Tools' standalone Oasis component (previous tests had been done using an old Arcade Sim extract I already had lying around).

Made quite a bit of progress with the Oasis MfmeTools layout extractor. Now extracts basic background/reel/lamp images, along with data

High quality direct tape-to-tape machines became a valuable resource (for the higher frequency speedloaders)!

Oh yeah, you can't beat a bit of tape pirating! Then once we got to the Amiga years, and it was all disks, BBSs and X-Copy

A little hacked in for initial test, first successful scrape of the delphi font characters from a text box with the new scraper etc under MfmeTools

Smidge more progress Not got my Delphi pixel font scraper in from Arcade Sim converter yet, but have got useful debug output set up of my new capture system in MfmeTools - so for the previous post where I was monitoring component numbers, it's just monitoring for changed pixels, now I can output the current capture area (a simple test of the red value; <128 black, >128 white)... Here is the initial component number in the test Andy Capp layout (161) - if you squint you can make it out ...and here is the final (first) component number when we've clicked all the way back until no more pixels changing: It's a bit grainy, as the 'Z Order' number on the Properties window in MFME is in an aliased font, but that is not the case for most other test that will be processed by the delphi pixel font scraper to be ported in next. Example of the aliased Z Order: 0 text: Now I have this handy debug output, it should be much less painful to try get everything aligned with my new scraper, since I'm not working blind The source comparison image I use for scraping ASCII Delphi font characters:

Antivirus software can be a bit of a pain! This won't affect standard users of Oasis when that is done, since it doesn't need these dll's to run the fruity machine emulation. It will still be an issue for advanced users who want to convert MFME layouts into Oasis layouts themselves (as they'll need to install the MfmeTools add-on to extract the MFME layouts), but this will be a small number of users interested in that side of things.

How to fix: - Open Windows Defender - select the Virus & Threat Protection tab: - scroll down in the Window and click Manage Settings: - click Add Or Remove Exclusions (you may need to scroll down to see this option: - Click the '+ Add an Exclusion' button, and select 'Folder' from the dropdown list: - Choose the Arcade Simulator folder, on my machine this looks like this (on your machine the username will not be 'John!') Now you should be able to use machines running via MFME (the fruit machines) again!

Ok - this is NOT recommended! But I've already found the exact problem and a fix. So each time Arcade Sim starts up it rewrites two files 'DllInject' and 'Speedhack2.dll' if it sees either of them are not present. I store them reversed to get past virus checkers during the download stage, then write an 'unreversed' copy to disk so it is seen as safe. Recently then it would seem that now Windows Defender is classifying 'DllInject.exe' as malware, and deleting it the moment it is written to the disk by ArcadeSim during startup. So by disabling 'Real Time Protection' in Windows Defender, then fully relaunching ArcadeSim, this means the DllInject.exe file can be written, without Windows Defender deleting it... and so then the fruit machines work correctly again I will now check if I can add the ArcadeSim directory as an 'Ignore' folder to WIndows Defender, as that is a much safer way to fix this... gimme 5 mins...

Ah right, have just checked and the same issue is present over here. It appears that ArcadeSim is unable to start the'hack dll' I wrote to inject functionality into MFME. I wonder if it's to do with Windows antivirus having changed and it now sees the dll injection as a potential threat: Thanks for the info, I suspect it's something Windows antivirus has started doing. I'm a bit under the weather for coding at the mo, hopefully I can figure a workaround fix, so we can keep ArcadeSim working to tide us over until Oasis... I'll look into it hopefully soonish, fingers crossed I can find a simple fix, without needing to try build an ArcadeSim update, since the codebase it pretty much 'retired'... would like it to keep working though for the next 1-2 years if poss!

I did spot that one recently Should be good for playing MAME internal classic layouts that require simultaneous button holds (nudging reels up, holding cancel to slow skill stops etc)

A little bit hacky, but more progress on the MfmeTools Extractor. Usually when right-clicking the left side of the layout to pull up the Properties window, we land straight on the first component (the background). This isn't always the case though, sometimes there might be a component like a checkbox there. So we must get back to the first component... I've added a large 'dummy test' lamp on the left of this Andy Capp layout I'm testing with, so we can test getting back to the first component. Here is the new window scraping code getting its first use, watching the component number change while clicking left, until it sees it has successfully reached the first component:

Sounds gnarly mate Even if the code was still present in the original asm source, but the (forced mini streak) routine was no longer called , the compiler would exclude it so it would be gone from the binary you get from the ROM (in these early asm production environments it was common to comment out the call but leave the code due to early/no source control).