johnparker007

It'll get there, the wheels turn very slowly in MAME-land, they've got a bit stuck with that commit due to samples I believe, really crappy for code contributors like @SomeRandomGuy though Haze has been saying to be more lenient on FME wrt MAME standards, but Cuavas runs such a tight ship, it can cause discouragement unfortunately...

For sure, this will be a long project that I'll work on as I can. But I think it's the best way... so once I've got the bones in so it can build 3d cabinets/layouts into some optimised form the Unity-based Arcade Simulator/Machine Simulator can load... there's lots of potential that way (I'll also of be doing support via dedicated apps in the suite for 'importing' MFME layouts, and building MAME layouts ) ...once it's running arcades, I might get lucky and pick up a game coder or two who want to get involved which will speed things along... On my previous UI post, I've been researching, and I now think the best solution for the non-Unity apps in the Oasis suite is an open-source UI system: https://www.avaloniaui.net/. Allows for cross-platform in the future...

Hmm on reflection, while I was originally gonna go all Unity for editors and tools (for the easy cross-platform goodness)... having had a look at how involved recreating a UI like that is, I'm now thinking these will be Windows apps, built in C# and .NET, and they will have the ability to embed a Unity process renderer (such as a 3d machine renderer in the Layout Editor) within that interface. So rather than the previous video, the interface will actually look a bit more like MFME As it'll just be Windows stuff - here's an example of something I knocked up before using that: So the UI for the tools, they will look and handle much more like the standard Windows interface (and will only run on Windows for now).

Built out the basic base applications for Oasis Hub, Layout Editor, MFME Extractor, MAME Builder, using the Arcade Sim icon design approach (a bit like the Adobe Creative Suite approach to icons). Here are the four apps with their icons on the taskbar: Started developing the Window/UI system, also added in a performance monitor, and a debugging console: As this is open source, I am having build/adapt things from other copyright-free systems, and roll my own. Will be continuing with the Window system, with draggable resizing, minimise/maximise/unmaximise/restore next, plus design better icons for the topright window buttons, these are placeholder...

I've not been up to doing much at all in the way of coding recently, hopefully slowly on the mend though And as such, I've been starting planning the next step in the 'Arcade Simulator' journey... Taking Arcade Simulator as our proof of concept (that we can run a large multiplayer arcade in realtime on a consumer PC with fruit machines and video games) - I think the plan should now be to build this into a fully open source project (hosted on github), that will be broken up into sub-projects. Just some initial thoughts on how this will be structured: This will be a large slow project! But at least we have now seen from Arcade Simulator that it is all actually possible, I honestly didn't know currents PCs were yet fast enough to run all those machines, back when I started it all As there will be separation between the 'apps', this will hopefully make it a bit more accessible for coders, for instance someone might be keen to work on the machine library app, but not be comfortable with 3d game coding, so that now won't be an issue. Also, this new project will be taking on the hard issues, such as people not being able to convert a fruit machine layout of their own from MFME format to something that can ultimately run in the arcade. I will still be using the existing 'MFME window scraping' technique for the extractor, as it does work, but I will add in various safeguards to try make it as safe as possible, things like: - scrape a layout a little slower - if a human generated mouse/keyboard input is detected, abort scraping - continuous 'window focus' watchdog strategies to detect desyncing during scraping - a warning popup to be ok'd that shows at start of every extraction; "This is experimental, while safeguards have been implemented, there is the potential for data loss, use at your own risk!" It will all take a long time to set all this up, and port the existing Arcade Sim systems into OASIS (especially assets that are licenced on a 'per seat' basis - in some cases I may be able to work with those asset creators on a solution to allow for use in open source, otherwise we need to roll our own)... but, the idea is that the project will ultimately no longer hinge on me doing it all! As now we have the working proof of concept in Arcade Sim, it makes most sense long term to build a future-proof platform - so if I were to meet an untimely demise in the future (RIP Chris) - the project could continue to grow and develop. The name OASIS came from the book Ready Player One "This is the Oasis. It's a place where the limits of reality are your own imagination. You can do anything, go anywhere. Like the Vacation Planet. Surf a 50-foot monster wave in Hawaii, you can ski down the Pyramids, you can climb Mount Everest with Batman. Check out this place. It's a casino the size of a planet! You can lose your money there, you can get married, you can get divorced, you can...you can go in there. People come to the Oasis for all the things they can do, but they stay because of all the things they can be: tall, beautiful, scary, a different sex, a different species, live action, cartoon, it's all your call. Yeah, that's me...well, that's my avatar, at least until I feel like changing it. Except for eating, sleeping and bathroom breaks, whatever people want to do, they do it in the Oasis. And since everyone is here, this is where we meet each other. This is where we make friends." - Wade Watts talking about the OASIS

I got asked about this a while back on the Mecca, from a few different owners of these machines, e.g: "it has a gamble block at £10 with a double/nothing style gamble .its pretty frustrating at times and I'm certain that allowing the gamble upto the £100 jp would make it a far better machine." I am only on MPU3/4 with this right now though (as I can fix the checksum to make work on real machines etc), just curious if these games can be made more fun with a little rom patcheroo or two...

Interesting Unfortunately I'm just working on MPU3/4 at the mo, since I've got techniques to fix their checksums after hacking them (otherwise the hacks are kinda useless as they won't boot). Just generally tinkering!

Just been having a play with an idea to make the MPU3 'clubbers' a bit more exciting. Here I've done a couple of ROM hacks to make the reel spins much faster, and also the 'skill stops' (I'm sure they are actually fixed predetermined stops lol) much faster. At around 0:50 in the video, I have a gamble, and you can see it going up on the alpha display, when I hit Double... until I get to £4.80. At that point the gamble sequence continues, but I no longer have the flashing start button to continue gambling, so I have to collect some of the win. Is this the infamous 'Gamble block' people have mentioned to me before? Apparently there were these blocks to stop you gambling up to say £100... but also in early ROMs that are not dumped, these blocks didn't exist, and were only introduced later. So yeah, is this definitely the 'gamble block'? I may try to figure out how to remove it if so...

Yep that works too, though if a new updated DX layout comes out, it wouldn't then work for the user immediately, you would have ongoing maintenance of that FML hash -> rom name lookup table. Both workable approaches anyway, should be a great feature

The CRC stuff was pretty old, for more recent projects I've done I've generated a SHA1 hash (for interoperability with MAME, and 'effectively' zero risk of a collision which would mean a misidentification could occur), but of the actual ROM file contents itself, rather than just the filename character string... so then it doesn't matter what the rom file is named as (that is referenced in the .gam file); you are only comparing the actual raw file byte data for a match (not the filename). If you choose to go SHA1 route, you'll also be able to do more stuff, like figure out from a MAME rom zip (named any random thing) which internal MAME rom name it is, and then have the video game themes/cabs etc indexed off that, so they'll be able to be automatically downloaded/installed. Good luck with it all! Edit: I think you said before you're coding FruitBar in c++, so you could use something like this: https://github.com/clibs/sha1 ...so once you have the example working of say: SHA1_CTX sha; uint8_t output[41]; char *buf = "abc"; ...instead read the entire ROM file byte data into a byte array pointed at by char *buf All fun and games lol

Sounds good man! I've done the ROM CRC trick before for an FME project, so then it'll usually work on a few different revisions of the layout, since the ROMs are still the same (I'm sure you'll already know this, but just in case - the ROM filenames used by the layout are stored in the .gam files in text, so you can just grab those ROM text rows to get the filenames).

Looks good man Out of interest were you thinking about a way so that once a 3d machine has been 'skinned', that skin could upload to server... and then other users could download that skin? So if they have a Toastbusters layout set up in your launcher, they could right click it, and choose 'get skin', and choose it, rather than having to build it themselves. Ultimately you could even have it recognise the ROMs (from within the .gam file), by having the ROM file CRCs uploaded... so then any layout using the same Toastbusters ROM could auto-download the correct 3d skin without any user intervention. Dif is hosting Arcade Sim for no cost, via a file server setup, I'd imagine they would extend you a similar setup if you went down that road. Apologies if this is already the plan haha! Looking cool anyway

"the flashing displays will be an interesting one to overcome" @appstrader Indeed I guess there's two main approaches with the flashing lights/segment displays etc on fruit machines: (a) record video of each machine running its attract mode flashing lamps etc in MFME, and then map the polygonal areas of the video to the rectangular textures for the quads representing the rectangular glass panels on your models or (b) go the ArcadeSim route, and fully reconstruct the layouts so the lamps/segment displays etc are all rendered in code and updateable (via data captured running from a 'data layout' in MFME via image scraping, to provide an attract mode recording of the pure data) I suspect for your use case, option (a) would be better, as option (b) requires that you build a full 3d model of each individual fruit machine including lamps, displays etc just to add it. With option (a), it's certainly much more straightforward to add new machines. Though, I'm a bit hungover to be fair haha, and there could be a whole other approach I've completely missed Look forward to seeing how you go about implementing the feature. If you decide to go the route of option (b), I'm happy to share some code that would help you with that approach, but it does get fairly complicated and tedious - I only did it since I had to anyway to make the machines playable from live rom emulation... if they only had to do fixed attract modes, I'd have been more considering option (a) for minimal time investment to add new machines! Good luck with this new wave of FruitBar2 dev

Doing ok ta, and hope you are good too man Keep up the good work, the 3d cab system looks like a really promising feature!

@appstrader nice work on the 3d cabinet renderer! If you'd like the fruit machine models (and Electrocoin Goliath video game cab) in ArcadeSim I could provide the .fbx's for you - we'll have to check if @Spidy21982 is cool with that first..? ...as most of the new versions of cabinets are his great work. Looking forward to seeing FruitBar continue to evolve

Nice game this, they knew their target demographic I have been dabbling with an idea of doing a 'blocky' shoot'em up for the Speccy on and off for a few years. I'd made a 8x4 Atari 2600 background style system that avoided colorclash, but moved to this new technique provided by a coder Denis, allows avoiding color clash and plenty of sprites, game will prob be done in like 10 years lol, got to code in z80 assembler for maximum speed, so it's a bit of a ballache to write...

Awesome thanks @Ploggy! I checked my permissions sheet, and I have you down as 'Pending - messaged Oct 2021' I've saved this to the sheet along with the link you provided in case those fruit emu layouts are newer than the ones here in the legacy section- thanks for all the layouts!

A couple of 2p oldies from that era that stand out; Always Eight, Rat Race. You might like JPM Rollercoaster, same era as Indiana Jones.

Your layouts are great, always good lighting levels

I think your rep points can take a few whippys lol

Hiya - currently it would not work with a home build, as the inputs wouldn't be set up in the layouts, plus the hoppers and coin mech wouldn't work. It does however already support portrait rendering on a vertically-oriented monitor - I believe this 'just works' from what I remember (provided monitor is set to vertical orientation within Windows).. I'm not working on dev right now due to health, but I will likely continue dev in the future at some point... though the cabinet support is a real low priority compared to tons of other stuff, so it'll likely be years away before I do the PACdrive-type stuff. Though I will look at solutions that support more stuff that MFME currently supports like segment alpha displays and DMDs when I do get to it. I've added an section to the task backlog: AS: Cabinet support - Input remapping for cab buttons - Write emulator-agnostic PACdrive-type system for lamps, alphas, DMDs, LEDs etc

Haha no other exclusive forums going on No work being done at the moment as I'm ill. Not even getting my day job done at the moment, so just need to get properly better first before any further MAME/ArcadeSim coding could resume.