johnparker007

The server(s) that serve the installer downloads/updates/multiplayer/online features I think I'll be writing/managing in Java (probably to mainly run on Amazon EC2 instances as pure java & Unity Asset Server instance). If creators wanted to release the layouts as standalone, that would be possible I think, but require a bunch of extra work to make this possible inside Arcade Sim to use them, and those then couldn't be used in shared arcades on Arcade Sim World, or even the local arcade designer (that works on the library). They also wouldn't update, and be completely unsupportable with updates to the Arcade sim client. So it would be possible with extra work I think, but break a bunch of different functionality, so mean they wouldn't be in the cloud library for people to use in shared arcade layouts/download, could break with updates to Arcade Sim etc. and also break Arcade Sim itself. Perhaps there could be a creators release area 'inside the client'? That's the only way I can envisage it working in any kind of maintainable way. So I'd be releasing/updating machines into the library so everything actually works and is maintainable. But there is an associated post from the creator in that area in the client, and they tell me a time/date when they want their post to go live - when the post goes live, the machine is then live in the library. Something like that could work, and could then be properly integrated into the system. EDIT: To clear up what is meant above by 'updates' to machines: as an example; currently the rendering is nowhere near finished, and all the components need tons of work. So if I make a rendering improvement that requires regeneration of the Vfd characters - that's all machines with Vfds needing an update. I add reel lamps - that's an update. I add a reflection to the glass - that's an update. I do work on the 3d modelled buttons - that's an update... you get the idea. Then when an update for Arcade Sim comes that contains the client-side aspect of these updates, that'd then need to be synced with the changed machine assets per machine that have also needed changes. So the machines will be out of date on a weekly to monthly basis... and I have so many improvements planned, this will be going on for a long time.

@Big J "Would it be possible to play two or even three machines on the same screen on your simulator @johnparker007, you may not of got that far but you know I can't help but give you the third degree lol?" Hmmm - I know there is a similar issue with the 'Party Time' type machines with the 3x slaves + top box. It requires a chunk of overhead (CPU and some GPU) to run an MFME instance and capture it - so for those my initial thinking is to just run a single slave that you'd stand (sit?) at. For 3x DES machines, I think that'd take around 50% of the CPU of my quad core i5 @ 4.7GHz just for the emulator. Then I have scraping overhead x3, plus the single simulator overhead - so even if this were programmed it'd require a high end PC. For running 3x old tech machines (MPU4 etc), the CPU demands will be much less. There's no reason why it wouldn't be possible, and I will factor that in when doing this big overhaul that's coming up soon (to transition to hybrid machines that can run either emulator). But it's not a high priority right now when there's so much else to do, and may e good to let computers get a bit faster on average as for DES machines it's going to kill anything that isn't a gaming rig tier CPU.

@Pook "...forgive me for not fully understanding the technical side of your work but is there a way for FME designers to convert their work themselves?" I made a comment about this further up the thread - the summary of which is that it is currently flakey at best at multiple stages, requires lots of manual steps, a knowledge of programming, Unity game engine, and the simulator internals. This will improve with time, but there's so much involved, with it in its current state... it's just all really complicated! So I can't see this being possible for a very long while yet, but I myself should be able to get faster and more accurate at the conversion process - but there's still so much programming to do there, the list of bugs is pretty long. The Sonic one the other night threw up some issues (similar to Indy), probably took me around 3 hours using my various semi-automated steps with various hacking/coding on the way. But sometimes they are quick, maybe even 1 hour. In the very long term, it may be possible to write a new extractor (I guess the second step in the process, that can be ran after various information is compiled to build a converter config), though this would likely cost me months and may fall down compared to current (flakey) extraction technique and then would be of no use anyway. Maybe it'll look more viable in ~6 months when I've done more on the project, but right now, the code that does the converting is in constant flux as is it's output. I'd be better equipped to see how much more viable it looks at that point. So I guess the TLDR of what was supposed to be a summary would be: "Not possible now, that may change in future, but I really can't say for sure, it depends on a lot of factors". And for completeness, here's my comments on this same question from earlier:

@Reg "...if it autogenerates the assets based on machines being plugged into it, you'll likely get 100's of layouts done very quickly by the community. Then for working with MAME, you have so much already done." Unfortunately there's still a lot of manual work involved, and lots of layouts currently don't work for a variety of reasons. The initial layout extraction process is also super flakey and can do bad things (like literally start selecting files on the desktop and moving them around / deleting them! Plus a recent memory leak, now fixed, meant it irreversibly corrupted a Perforce server running on my machine - it's pretty dangerous!). And a strong knowledge of Unity game engine and the internals of the simulator are required - so for the medium term at least, I have to make the 3d machines using the layouts myself as a manual process, and there's just no way around that, it's a big technical obstacle (much I'd love it to be a nice magic one-click solution that spits out the 3d machines!). @slasher "The other reason I believe it's being done is because it's easier to focus on the same part for both MFME and MAME, rather than do it for MFME and have to re visit later. At present, the MAME side is playing catch up to what's already been implemented for MFME. " This is mainly true, I am having to reimplement stuff that looks the same in the videos (as the previous MFME machines) but is radically different under the hood. Once I have MAME scraping/input roughly on a par with MFME scraping/input, I could then think about how I might best approach the overhaul to generate the 'hybrid' machines I mentioned earlier. So then you'd have a machine like Indiana Jones, and you could bring up the options menu while it's running, and switch emulators. The machine would reboot, but now it would be running on the other emulator (whilst preserving machine RAM). I think with the videos I put up make things look simpler than they are Bear in mind these are cherry picked recordings to show things working, rather than a lot of the time when things go horribly wrong ...so I can see why it would be a logical jump to assume you can pop raw MFME layouts in and get functioning 3d machines out... but I think to satisfy all involved, particularly @Reg, I will move up the 'hybrid machine ' generation work to earlier than planned. This will take a lot of work, but then the machines can be played using either emulator (providing MFME is installed). I'll keep on fixing MAME scraping/input issues for now, until it's vaguely stable, and then start thinking about how the hybrid machines can work.

This does need to work 'out of the box', so the base emulator is now MAME. It's a really complex project, and now I have to support two fruit machine emulation platforms, I have to make all that actually work. At some point I need to look at further work on some form of hybrid machine that supports both emulators from the same instance of the machine - otherwise it's having two copies of the same machine, one for MFME and one for MAME - which is not the way to go. This has all taken a ton of time so far, I work 40+hrs per week on day job, then work on this, and also eat and sleep - there's not much time for anything else! If I won the lottery, I would be able to work on this fulltime and we get progress quicker, but this is as fast as I can go... So for now, I'll keep on with the plan of contacting layout artists to ask if they'd give their blessing to their layouts being used in the creation of Arcade Sim machines, I hope that satisfies everyone's concerns?

Thank you @vectra666, much appreciated - I'm going to send out DMs to layout creators over this week, I'll cross you off my list!

@johnparker007 you may of already mentioned it in this thread or elsewhere but a quick question, can't MAME just be the sole engine without any assist from MFME? Sorry if you have to possibly repeat yourself. It's a good question as it can be confusing what's actually going on when watching the WIP videos. Currently the machines I'm working on (JPMs and early MPU4s) all use MAME, there is no MFME at all. The idea is that if someone has MFME installed, Arcade Sim will detect that, then it will be possible to change which emulator machines use, and also there will be additional newer machines available (that don't run correctly in MAME yet, such as Scorp 5 / MPU5).

I'll make a note and send out some DMs in the next week or so to the talented designers on here. Plan is to have credits in the HUD as the machine is highlighted (it already does this, it's up in the top left), plus more detailed credits and the original layout release notes in each machines info page in the library.

Re layouts - I am planning to reach out to all you fine layout designers to seek permission to use the layouts as the bases for the 3d machines in the simulator. There's some that will likely be 'orphaned' layouts - for instance the Smash 'n' Grab layout is over 11 years old, by 'Fruitworks/ Realizm'. What is the policy on the old layouts, if the original authors are no longer active? If they are unavailable for use it'd be good to know, as then I will have (yet another) project, to write something that can use an old layout and try to 'autogenerate' a new layout from new photos - mapping/scaling the graphics so they are aligned, making a 'new' layout based on the old one.

(Deleted post as was reply to @slasher's deleted post)

The MFME stuff is still just about working, I'm trying to keep both sets of logic as I go in the code. It's all needing a large refactor - currently I can generate a machine as an MFME machine or a MAME machine. What I think I ultimately need is a hybrid machine, so then when the arcade is running, the user can go into a machines options to override the emulator it uses on the fly (or have a global 'prefer MFME' option). This all needs more planning/design when I get to that stage - it's significantly more complicated supporting two emulators for the same machines. Currently targeting MAME for all these machines as that's the thing I need to get working first as it's now the base emulator... I also have various work to do in MAME (get Scorpion 4 working, fix some MPU4/other tech issues that I can, longer term get ccTalk / DES / Scorp 5 working / improve other techs). Ultimately there will be MFME functionality too (along with it's additional machine techs), but it's going to be MAME for quite a while yet as there's so much to do. Slowly making progress though

New Vogue conversion WIP - Sonic... - Minor graphical glitch with the first two hold buttons visible in early part of vid. - 'Freezing' issue recently seen on Bonanza happens again here at end of vid - turns out it's not MAME but something to do with how Arcade Sim is sending button states.

A little tech update - I've been looking into fixing MPU4 characteriser loading in MAME. This is by no means done, but here is a ROM (Andy Capp) that previously had the dreaded 'scrambled lamps' (where it was using a fallback cheat to get just the protection part working which works on most older MPU4s). So by patching in the .chr saved from Pook's layout with the matching ROM (shows AND K during boot), here we can see the lamps are now working correctly in MAME Have to work out how to clean this code up so it's fit to go in the MAME codebase and doesn't break existing ROMs, as they're all using 'semi-generic' chrs which would never have worked anyway, so I'll have to sort that out (plus code was missing to patch the dynamically loaded data in). There are probably quite a few other things like this I can work on to get MPU4 compatibility up, so I can then use the fixed machines in arcade sim

That was my first thought looking at the feature board, looks very Indy-like!

Added new Vogue 'Bonanza' Seemed to play perfect, then locked when I tried to bang in a load of £1 coins back to back. Gameplay vid:

Mapped some of the non-button-based coin mechs. Pot Of Gold is being a pain lol, as there's a £ sign in the MFME definition and my scraper is failing as it's non-ASCII, will have to tackle that one later So here's a vid showing Give Us A Break and Big Bucks (but no Pot of Gold yet) successfully coining up

Just watched back the vid, I see I missed it about 1 minute in! ...and this is why I don't have big bucks

Added coin slots panel to JPM Vogues, hooked up the Indy ones (that work internally as buttons). Next up will be some work to get the other 3 Vogues with their coin panels, and working (they operate differently internally).

After a few failed approaches, managed to get a nice clean system in for automapping the input from arcade sim into MAME for the different techs. Here's a quick vid of testing Big Bucks with the new input system stuff: Also tracked down a memory leak that was chewing though a gig of ram every few minutes while the machines ran Next up is doing the JPM coin slots/input as it's handled differently to MPU4...

I've done a bit more (slightly fudgy for now but working) on managing the window focus/visibility. So now in this vid, MAME is reliably repeatedly starting up (with turbo starts), without any visible window popups. Various code around this stuff needs some cleaning up, but definitely shows it can work, which is a relief

Done a bit more on the emulator/focus control stuff for MAME Have got it 100% stable, so the machines actually work every time now - which is a necessity really There's still a brief black flash of the MAME window at machine startup, which I may live with for now, I think I can find a way to improve it further but it may require a significant overhaul of some stuff, which will eat up some time. I've also done an initial implementation of the 'turbo startup' feature as was done with MFME. So now the machine boots running as fast as possible, until criteria are met (just waiting for a specific lamp to be lit for now seems to work fine), at which point we know the machine has fully booted to a playable state, then we restore the speed to normal. Brief vid showing this on a couple of machines here:

Started work on the focus control and related stuff for MAME Main issues are: very unreliable at present (only 1 out of 3 attempts worked in this video), and also some popups are briefly visible. Have a couple of plans for dealing with the briefly visible popups, not sure why it's being unreliable at the moment though. Here's a quick vid of launching MAME via the proper full screen arcade sim client:

Saw that Big Bucks has same parameters and was already part done for MFME, so made that into a WIP MAME machine, and did a playtest (again playing with the MAME window focused with the weird MAME keys)

Coming back to this after some beer Found another machine that has pretty much identical parameters to Indy, that I'd already converted for MFME; Give Us A Break:

I was on VPForums for a while - I did a little hacking around with the source, but only uploaded one patch build (that allowed you to load VP layouts that needed more GPU memory then was available, feature was later done properly by the dev team, so it's no longer an issue). And part built a VP cab about 10 years back, but drifted away, due to lack of time. Amazing the progress in that scene