johnparker007

The original 'old' Arcade Sim code is intentionally not on github btw, as it was somewhat a proof-of-concept, so I don't feel it's a good/constructive idea to put it on there. It's reasonably well-coded to be fair, but we don't want a bunch of Arcade Sim clones floating around at this early stage The new Oasis version [of Arcade Sim and associated projects] is all about the whole community being able to build the 3d machines and the layouts (for at least fruit+video games initially); in Arcade Sim I had to build everything myself in the internal format to make stuff work, and the community could only play those machines I built, so it was both a lot of work for me, but of course unsustainable as a scene project everyone can share effort in (and also boringly passive for those creative scene members). It wasn't an oversight as such, more that I needed to figure out if it was even possible to run full arcades with 100s of machines, with many onscreen at once. Fortunately, as we can see from Arcade Sim v1, it totally is doable! The current offerings (mainly New Retro Arcade Neon, and also a new project Arcade Time Capsule which looks very nice) have severe limitations (in my opinion) in terms of fully custom arcades (no vision for truly custom arcade layouts, no true multiplayer, no fruit machines, no pinball, no coin pushers, no indoor minigolf, no pool etc etc), and also they intentionally don't pack the machines close as a workaround to deal with performance issues (unlike Arcade Sim v1 which can run closely packed machines as per a real arcade without issue, as it was built from the ground up to handle that). These performance architectural implementations translate to potentially running native on mobile phones, (non-tethered) VR headsets etc. I have reached out already and had great dialog with the author of the new Time Capsule project, it sounds like we can work out some 3d model sharing in the future, as the creator is also a good 3d artist and has created a bunch of great authentic video game cabinets for his project (which would look great in Oasis). Apologies, got side-tracked with waffling lol, but that is the vision anyway And while I'm working slow right now, things should pick up, and once we get to a certain level, we should get to the 'MAME model' where other coders come and also work on it, rather than just me (and it is already being built from the ground up to facilitate 2d layout artist contributions, much like MFME).

If you've not seen it, and you like the fruit machines, you might be interested in Arcade Simulator:

I did a very similar thing when I was getting into virtual pinball cabinets, a sturdy cardboard box with buttons installed is a great way to start these virtual cabinet projects It's the emulation hardware equivalent of measure twice, cut once - good luck with your project

The tool isn't compiled into an .exe, just the source code project... I only developed it far enough to make some custom sound ROMs (ya know to prove it was doable, as is often the way with my projects lol ). What platform are you looking to make a custom sound ROM for? I think I only coded ADPCM format so far, that covers MPU4 and some other less common techs, but I don't quite remember. I was going to sort out some interleaved stuff (maybe sc4/5?) but I didn't get round to that yet. I've just tested a build and it's very not finished - I can load and patch sounds, but not save them back to a compiled ROM. Here's the build, but someone needs to do more on the code probably, unfortunately we are severely short of programmers in the FME scene, and I'm struggling for both health and time at the mo... when I'm up to it, I really need to keep chipping away at Oasis project. Sorry that's probably not much use for the moment! I'm sure I'll get to it one day, but not right now Debug_SoundRomEditor.zip Edit: full source code for this tool as it stands is in my forum sig below.

I see 'Fuzion Design' in the background, I think it's @thealteredemu's work, good find!

I only see roms for a JPM version and an ACE version in a recent ROM collection from @Geddy, also none in MAME. Looks like a Reflex sc 4/5/6...

I did half-start a tool (a modern Windows tool with a GUI) for doing this, worked on a few techs, more were to follow, but I've been under the weather, plus a bunch of other FME projects require my attention these days! Here's a demo of someone using a rom created by the tool (so the feature board music normally isn't the official Ghostbusters, but a short loop of similar synth Ghostbusters music): The source code is here (all my projects going forward are open source so all code is always available). If someone has the time and a basic knownledge of coding etc, they could expand this to cover most/all techs, and also improve the UI etc: [ Sound ROM Editor ] Source code: https://github.com/johnparker007/SoundRomEditor

I have just tried the 'Unpack Blended Lamps' operation on the high resolution Indiana Jones layout; it reported unpacking I believe 10x blended lamps. Then running the 10x sped up attract mode, it seems to have made some improvement to the stutter when viewing in non-Edit (DirectX shim scaled) mode. In Edit mode (no DirectX scaling), it runs at full speed as in the previous test. So Unpack Blended Lamps can help, but for severe slowdown, I'd also recommend doing stategies like the one outlined above, to reduce the net volume of blended pixels to be rendered. Another technique that I believe may be workable and help is; where you have your overlapping blended lamps, such as the 'Jones' in my tutorial above, you can also make one of the blended overlay lamps non-blended - so this would entail as one suggested workflow, capture the lamp in its On state rendering on the layout (all other lamps in Off state, acquire transparent pixels by layer subtraction against the background image). Then by placing that single no-longer-blended lamp at the lowest z order (Send to back), the other overlaid Blended lamps can blend with it, and I think the appearance should be identical, whilst drawing one less blended lamp.

Hiya mate I did have a brief look into this MFME render issue before, I've just done a quick vid demo of @Pook's Indiana Jones layout, showing the issue. Basically, if you have a lot of blended lamp overall 'area', I think that's where you see more problems. Internally, MFME still runs a CPU based Delphi graphics buffer to put its graphics together. There is then some kind of shim on the end, that makes that into a DirectX texture (when in normal mode). This DirectX shim is not in place during Edit mode (as the layout is not scaled in the same way). I've sped up MFME here with cheat engine (rather than try get jackpots), and you can see, it has slowdown to 1-2FPS when in normal mode (layout scaled to window via the DirectX shim code), but when in Edit mode, the DirectX shim is not in action, and you can see it then has no slowdown at all. Also, at the end of the video I click and delete what I think are probably the main 'blended' lamps on the layout, and then you can see that it no longer has the slowdown when running scaled down by the DirectX shim. You could perhaps arrange your layout in somewhat elaborate ways to work around it 'a bit', depending if you have large blank areas on your alpha lamp, so for example, this particular 'Jones' lamp, could be broken into 2x lamps (both mapped to the same original lamp number): That way it might save some CPU/GPU time, since the overall pixel area is smaller. As another example from that layout, this would prob save some render time from the DirectX shim approach, by splitting this lamp into 3x lamps, again with the aim of not processing all those completely empty pixels: There's some other tricks that would probably help too, but I've got to head off to the shop That or simply avoid blended lamps of course! Hope that helps to understand what's going on...

Here's some Dr Who Timelord roms, maybe one of these will be the ones you need Dr Who Time Lord (Bellfruit) [Rom].zip

If you are handy with photoshop then it's 100% doable If you can get your phone (assuming phone camera), 100% steady by rigging up some makeshift tripod, could just be wedged on the step of a stepladder or whatever you have to hand, that could make things easier, since the on and off photos would perfectly match up, then no 'jumping lamps'. Then if you have it in photoshop so you can turn on/off the top layer, then that will simulate what it'll look like when all the lamps flash on/off in the emulator (without needing to go through all the work of actually cutting things out etc). If it looks good there, then it'll look good when built into a layout. Might want to also set up manual focus/exposure etc for when you take the pics, otherwise the lamps on may confuse the light sensor on the camera. Glass scans and high resolution photos are always very welcome, if you'd be up for sharing them before they get processed into a layout There's some on the Community Drive (http://tinyurl.com/yckze665) that need fish eye correction fixing, so improved images would be amazing Fisheye images: https://drive.google.com/drive/folders/1038UcG9kCB6ziec0WPMmwaI-3YkuNBbf?usp=sharing

Still well under trhe weather, but hopefully on the mend soon, so in the meantime had a little mini-tinker ; Updated MX app cion to MT; set up initial fields and options for this new combined MFME Tools module (for both Extraction and Injection of layouts). Once I'm back in the zone, I will comment the convertinmg/porting/improving of the extraction code from the system side of AS over to this new Oasis module...

Bit under the weather again, but hopefully on the mend soon So a small tech update: the original 'MFME Extractor' Windows-only optional module of the Oasis suite, is now to become 'MFME Tools'. This MFME Tools module will contain the components of 'Extractor' and a new component; 'Injector'. What this means is that in addition to being able to extract MFME layouts (using the copy of MFME v20.1 on the user's system), this will also be able to export/inject a 2d rendering of an Oasis layout back to MFME. Effects such as the realtime lighting of the 2d cabinet I think will be possible, though there is the issue of MFME slowdown when a lot of blended lamps are drawn at once. I'm hoping it will lead to a workflow where even as existing 2d fake-perspective layouts are extracted then imported from MFME->Oasis, the lighting can be remastered along with the cabinet... and so then a 3d rendering of the cabinet would be displayed in 2d in the injected (i.e. exported) MFME layout. This will allow continued support for MFME users where a layout has been created natively on Oasis, and the layout will also have time-consuming elements like live light reflections etc reflected in the parts of the 2d rendered cabinet, as rendered natively in 3d. Seems bonkers I know, but it's a logical extension as I'm figuring out the project architecture in terms of the Windows-only elements for layout artists to input/output work to/from MFME. The Oasis Layout Editor module will use these components in the background, so it will be as simple as using the relevant UI in Oasis LE. It'll also be usable in a 'standalone' mode, for those that may wish to build other things from this, for instance alternative MFME frontends like @appstrader's FruitBar (so in that example, he'd be able to build real animated lamp on/off attracts into the frontend by having full raw dumps of the layouts as .png and .json data etc). Just a window for start as I am under the weather, but this is where all the ArcadeSim MFME IO systems will be ported to: To be continued, once I'm back up and at 'em - the first stage will be refactoring the MFME extraction system that ArcadeSim uses... Note that a user just wishing to play layouts in Oasis, either standalone or in 'AS2', will not need to download the optional MFME Tools module, this will only be of use to Layout Artists, and perhaps also layout converter scene members who will oversee converting MFME layouts to Oasis, along with enhancing them with the highest resolution source art we have etc.

Sure - but if he wanted to support multitouch touchscreen layout input in his android wrapper, he'd need to do some work such that the multitouch touch id/up/down/move data is processed in the wrapper, and then the relevant control is triggered in MAME. I could write such a system, but it's kinda a waste of my FME dev time really, since Oasis android port will do all this anyway, but running under a completely different paradigm. I've given him a couple of pointers, but I wouldn't expect him to write such an implementation, since it's a lot of work for something he wasn't even aware was not working lol He could do a quicker hack for a non-multitouch tap system - so when the wrapper receives a new touch down, it sets the relative MAME mouse pointer to that position... but that wouldn't support multitouch so a bunch of games would still be missing functionality... plus MAME is likely never going to look as good as the next version of the 3d machine rendering that'll be going in Oasis, so prob just best to hold out for Oasis android really, to get proper multitouch plus fancy 3d graphics/lighting/reflections

I have checked this, and unfortunately it's of no use for playing fruit machines really, as there's an orange 'mouse pointer' that you move around by dragging your finger on the touchscreen - you can't simply tap on flashing buttons to press them. And something like nudging up with holding a nudge up button, while tapping hold buttons would be impossible. Fun project he's doing, but still probably going to need to wait for Oasis android port to play the machines in an enjoyable fashion...

So this isn't a change to 'core MAME', but the MAME4droid spinoff project to run MAME locally on android has been updated, so now it should be possible to play the MAME layouts using the touchscreen. From the dev on the MAME4droid project: I tried the issue you mentioned and at the time implemented an option in Mame4droid settings, input, mouse, always gaming touch mode (you have to enable) that makes the virtual mouse always enabled. In that way I tested the rom that you told me and I was able to interact with the layout. Enjoy fruit machines on the go without spend money. https://github.com/seleuco/MAME4droid-2024/issues/1#issuecomment-1950293891 Oasis for android won't be affected by this since it will be doing its own input pass through, but that could be years away as the priority is Windows, then Mac + Linux... but after doing Linux, it won't be a much work to play standalone 3d Oasis machines on android, with the various fancy rendering etc. But in the meantime, MAME4droid should allow for some basic 2d fruities on the go

I must admit I have never run it, or in fact jpemu or the other old one bfemulator... only seen mfme/mame running fruities. Bit under the weather at the mo, but hopefully be back up and at em in the next couple of weeks, and I'll get back to chipping away at the Oasis project

Bots (aka random save states) and real other players planned for Oasis version of AS

If I play a machine for a bit in the arcade and it's not paying out big, I leave it, that way I've usually got plenty that are ready One day Oasis will be there with multiplayer which will share the save states via a server, and then they'll be as others left them

There is a lot of work to do building the Layout Editor. This will allow for importing extracted MFME layouts to be converted to native Oasis layouts (to work in 3d machines like in Arcade Sim). The 'extraction' will be performed by the MFME Extractor, which is already somewhat done, but will be rewritten with a focus on improved robustness as it's a flakey process. There will also be a feature to generate MAME layouts - this will mainly be used for creating/improving internal text-only layouts, that are built into the MAME.exe itself. This will indirectly help out with getting the emulation improved in MAME. Using the same UI framework I'm building for the Layout Editor, will be a second application that will be the Cabinet Editor. This will allow for importing 3d models in a generic format such as .fbx, to be converted to native Oasis cabinets (again to work as part of 3d machines like in ArcadeSim, housing the Oasis layouts). The Machine Player will allow playing these 3d machines in a single machine mode initially, and also have VR support, along with various visual effect options (like Bloom etc). Once this is all fairly solid, I will start development of the Oasis version of Arcade Simulator (I guess you could think of that as 'Arcade Sim 2'), to allow for the Arcade Sim experience with multiple Oasis machines... and that will ultimately get things that weren't in Arcade Sim 1, such as multiplayer, VR etc. Also there'll be lots of surrounding work, things not thought of yet etc. The key purpose of all this is that using the tools in the Oasis suite of FME software, the community will be able to convert existing MFME layouts, build new layouts, create new 3d cabinets, and build fully integrated machines that then work in the new Arcade Simulator... all without needing to touch any programming. The full source code is open source, hosted live here: https://github.com/johnparker007/Oasis This probably represents years of work, but I think it's what we need to take the scene to the next level, now we've seen the proof-of-concept the original Arcade Simulator represents

Made a start on the scrolling and zooming functionality

Thanks so much for all of this amazing art you have contributed, just incredible man!

The blue 'global active tab' indicator now implemented and working Here's a screenshot of me typing 1000 into the Reel X Position field, and you can see it's not done the previous annoying behaviour of inserting 3x £1 coins from the the zero key presses! So now keyboard input can be filtered to the tab with the blue marker (of which there is only ever one).