MAMEdev
MFME extraction, etc #2
Replies: 34 comments 80 replies
-
|
Thanks for this, and apologies @cuavas, @james-wallace-ghub - I was thinking we need something for general MAME fruit machine discussion, this is perfect :) As an update - I am fully committed to the 'flakey but already working' approach on my MFME layout/config extractor again now (to much risk/work/complexity in the FML decoding approach). I spent last night doing the majority of the remaining Lamp component base info (thus far I've been just extracting enough to drive the Arcade Sim 'DX' machines, as it was all still in the experimental phase). Plan is:
I'll post the odd update as I pass key milestones, now we have a forum for this :) |
Beta Was this translation helpful? Give feedback.
-
|
As you’ve probably noticed, I’ve been slowly converting layouts to use loops to generate and place the numeric lamp/button labels in the debug views. It saves thousands of lines in the layout files, and makes a checked out source tree a bit smaller. I have about 200 left to do for my current round. It’s fairly automated with vim scripting, but I still check the changes, so it’s boring work. As you guys are already no doubt aware, the reel components in layouts (inherited from AGEMAME) have been deprecated. They were problematic in multiple ways. They performed incredibly poorly (you could see the slowdown when the reels do their initial spin on start), they generate insane numbers of textures, and you’re limited to using fixed-size bitmap tiles. Being able to show a window on any element is more flexible (it can cater to things other than reels), and it performs a whole lot better. I migrated a couple of layouts to eliminate deprecated reel elements, but it’s going to be quite a while before they’re all done. There are some other people interested in helping out with it, but I’ve been putting off describing the process because I wanted to get the rest of the debug view cleanup done first. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry I've been a bit busy so am still just on the first step in my plan above (implement complete scraping for MFME components). I migrated a couple of layouts to eliminate deprecated reel elements If you could let me know the name of one of these layouts for reference of how to do the new style of reels please, for when I get to writing the XML generation code that would be great (I checked a few layouts from different platforms, but they all still have the old 'reel' components). I'm a little wary now though, as I don't want to generate new layouts overwriting what's already been worked on by others after my original commits! Also I did lose the original work on the old codebase that generated those 'debug views', I wasn't sure if they were still desired, they seemed like they might handy back when I working on this stuff before. I could look at writing that again (using the new compact loops) if they're still handy for developing the emulation side. I guess best plan is I'll just generate layouts for the fruit machine platforms that didn't get done last time; MPU4(a load of MPU4 did actually get done, but didn't end up in the MAME codebase)... and then there are other platforms that weren't available before; Scorpion 5, Proconn spring to mind, other new ones. |
Beta Was this translation helpful? Give feedback.
-
|
I would use the loops anywhere you can. I know if it's automated that stuff doesn't matter as much, but if people are going to be making their own layouts in the 'DX' style, they might as well have the best practice examples in the codebase to work from, to the point that I'm probably going to pull down the old AGEMAME ones for Dr Who as they're not particularly fit for purpose any more. |
Beta Was this translation helpful? Give feedback.
-
|
I do rather like the debug views – they’re handy for seeing what’s being tickled, or doing comparisons when you refactor something. It would be nice if the buttons were hooked up rather than all being TODO, though. The lamp matrix grid technically contains the same information, but it’s in an incomprehensible form. |
Beta Was this translation helpful? Give feedback.
-
|
I guess it's just because I'm deep in them that they make vague sense to me. If the debug views work for others then I'm fine with them. To some extent I wonder whether the base view should be more along those lines for things like, say, the MPU4 Test Unit ROMs where essentially they hook up to a box full of test lights, reels etc. |
Beta Was this translation helpful? Give feedback.
-
|
I'll bear in mind once the 'classic' layouts stuff is working, that a per-tech per-game debug view would be welcome :) Just had a look to remind myself:
I think the colours on the lamp matrix showed what was referenced (tickled) ; green for lamps, yellow for lamps that are also buttons... dark blue might be reel lamps... unfortunately the original code I did to make these 'debug layouts' is lost, but I can maybe find further visual improvements when I make them again. I think the lower right 8x8 matrix is showing the buttons, where yellow ones are referenced, and they may also light up (sc4 is broken now so unsure). And off course as cuavas says, these were intended to be hooked up so they would be 'clickable', sounds like I didn't finish that part on the first attempt back around 2015. Also as James says, it would be better perhaps if the shared base layout for a platform like MPU4 etc, was then based of a more generic version of one of the debug layouts above. So it wouldn't have the shading to show what is referenced, but still more useful that the current ones, especially once the input matrix is set up for clickable. Still real life stuff going on at the mo, but when I do get time to work on emu dev, I'm now fully on this new MAME layout generation rewrite (using the other Arcade Sim project to drive most of it) - so please bear with me :) |
Beta Was this translation helpful? Give feedback.
-
|
The Here’s an example of a new, relatively simple layout using scroll windows to implement reels: https://github.com/mamedev/mame/blob/445293464e4aa99320493f1a93d8caeff72a1a68/src/mame/layout/j_lc.lay This commit converts reel components for one layout: mamedev/mame@24a5f43 Essentially:
With the
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks very much for the examples of new reels and the detailed explanation, this all looks nice and straightforward and should be fine to build into the new 'mfme2mame' xml generator :) |
Beta Was this translation helpful? Give feedback.
-
|
@johnparker007 I saw you mentioned about your doing screen scraping/remote control of MFME. Just FYI that you do not need to do this with MAME (any more), @npwoods (Bletch) has a good example of how to remote control a MAME interface with Lua over at https://github.com/npwoods/bletchmame . Most (all?) MAME frontends have yet to catch up. |
Beta Was this translation helpful? Give feedback.
-
|
I did see this before when looking at ways to use MAME with Unity... I'll have to actually have a proper look into it! I did roll my own Lua control thing for sending input to a non-focused MAME window behind the Unity full screen window, here's an old video of that in action, running a JPM Impact fruit machine (Lua to send input, window-scraping a 'data layout to get lamp/Vfd states): |
Beta Was this translation helpful? Give feedback.
-
|
Please don’t discuss or link to libretro/Retroarch here. It’s a parasitic project with an incredibly toxic leader. Their behaviour has directly lead to emulation projects being abandoned (DuckStation, Reicast) or going closed source (ReDream). The so-called MAME2003+ project is one of the biggest steps backwards for emulation. They’re also happy to violate the terms of the GPL. |
Beta Was this translation helpful? Give feedback.
-
|
Ah ok, sorry I didn't realise all this, ta for the heads up. Sounds like more reasons to investigate the BletchMAME approach if that is an 'approved' approach for MAME under Unity, see if they solved the debounce issue I was seeing with Lua input control - I was probably doing it wrong, it was just a first attempt :) |
Beta Was this translation helpful? Give feedback.
-
|
(@stilett0 sorry my reply to your comment has been partially redacted, so it is now incomplete) |
Beta Was this translation helpful? Give feedback.
-
|
@davidhaywood just to let you know I've finally got some free time again, so I've now finished up the first stage of scraping the components (used in the test MPU4 Adders & Ladders MFME layout). This gives me graphical assets along with a large human-readable json file containing a dump of all the extracted data: CLASSICClassicAddersAndLadders(Barcrest).zip So now I'll move onto implementing a new version of the MAME .lay xml builder. I might be able to salvage some stuff from the old one written in C, but I may just start from scratch, and do it cleaner... Once I've got it generating something I'll post another update with a MAME screenshot :) I may be doing some improvements, I'm considering putting a white border around clickable buttons, something like this mockup on the £1 button, so they are visually different to lamps: |
Beta Was this translation helpful? Give feedback.
-
|
I've got the first working output - just basic lamps, some issue to fix :) So this is porting and rewriting the old mfme2mame code that wasn't lost, into Arcade Simulator codebase, just focussing on what's needed to make the 'internal' non-graphical layouts for now, and potentially remaking those debug views. I will keep chipping away, and post another screenshot once I've got more components in and bugs fixed... |
Beta Was this translation helpful? Give feedback.
-
You know you can also use Lua script to do all sorts of stuff in layouts. |
Beta Was this translation helpful? Give feedback.
-
|
I’d kind of prefer if people didn’t go too crazy with Unicode emoji in internal layouts:
|
Beta Was this translation helpful? Give feedback.
-
I did see that mentioned in the now expanded layout docs on skimming through them again recently - using Lua to do fancier stuff (last time I read these docs was back in 2016!). The reason I suggested we might want to expand the < led7seg > was that it's a common use case, in that I remember having to make the < rect > workaround back in the day. Here's an example from the existing layouts with 6 of these lamp-driven 7segs (literally the first MPS-platform machine I loaded up to check for this, Add A Note): Also I see: Layout scripting requires the layout plugin to be enabled. ...so I'll stick with the original workaround approach for the moment (and perhaps improve the appearance), as using Lua in the layout isn't going to work (for the typical user). |
Beta Was this translation helpful? Give feedback.
-
Ah ok I see - right, I will ditch the unicode fruit symbols idea, thanks for the heads up :) Having had a taste of seeing those colored fruit symbols instead of the old text, they do look so much better (and clearer when playing)... though I'm concerned that if I made 'SVG fruit art', that would impose too much bloat on the layouts? I guess there'd be something like 4-12 unique symbols on average per layout, that's a very rough guess (some machines like this one pictured below have a lots of fruits, some just have 3-4 like melon/7/bar). I found an example SVG melon from the net: I've had a play with the < group > stuff, and it seems like there's a bug/omitted functionality - in that the < yscroll > tag doesn't work when referencing groups, which I believe are needed to reuse elements (such as the SVG reel symbols). The View Element still renders, but it doesn't decrease the window visibility, and so no scrolling takes place when linked to an sreel. E.g:
So in the View section, the first two of these (referencing groups) appear to ignore the yscroll, only the third works, which is not referencing a group: Here's a functional test layout showing the above, I was testing on j6indy, but any fruit will do :) (of course the SVG reels could be made to work by copy/pasting lots of duplicate copies of repeated SVG data into the element instead of using groups, but that would add insane amounts of bloat :) ) |
Beta Was this translation helpful? Give feedback.
-
|
There is a LUA script example for generating 7seg displays from lamp lines - I did it for Double Take (v4dbltak) |
Beta Was this translation helpful? Give feedback.
-
Extending the built-in components is the road to hell. It’s better to keep them simple. We’re not going to complicate them.
It’s one setting to change to turn on a plugin – you can get there from the main menu pretty easily. You’d be shocked how many “typical users” turn on the high score, autofire and input macro plugins straight away. I really don’t want to pander to users who can’t flip a setting in a menu.
Why are people so obsessed with using transforms to rotate things by 45° when the SVG code would be more readable using plain paths? I really don’t understand this.
You‘re not understanding what a group element actually does or how scrolling words.
But I think you’re trying to jam too much stuff into the internal layouts. Consider that in an external layout, you can supply SVG, PNG, JPEG or BMP files for reel graphics. If you want to de-duplicate the symbols in an external layout, you can just draw the same images in multiple elements (remember an element can contain multiple components). For internal layouts it‘s probably better to just use text for the reel symbols so people know what they are. |
Beta Was this translation helpful? Give feedback.
-
|
Ok thanks for the info and feedback, I will stick with all text for the internal layouts, no SVG reel symbols. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that sounds best to me. Maybe a generic set of symbols that can be referenced would be fine for some cases, but text is fine. We will eventually need things like rotatable elements, as for some of the ones using 'wheels' it's fundamental to how they play (overlaying a spinning wheel so that only certain game specific parts of the wheel are visible through them, eg 2/3/4 points on the wheel) In that case text might be a bit awkward, as typically the symbols used are ones that have to look fine flipped / rotated so that they make sense wherever they're in view; text doesn't work so well there. For cases like that maybe a generic set of symbols (not font / unicode based) would come in handy, but we can't even rotate textures / groups etc. right now (Vas is aware of this already, and I believe it's on his TODO list) At the moment some of these cases are faked simply putting extra copies of the reels in the view at different positions, but that doesn't really reflect that they're a single rotating wheel. https://www.youtube.com/watch?v=Fjy2kQhslOM&t=210s JPM Big 50 (we currently use a duplicate of the reel in the view) |
Beta Was this translation helpful? Give feedback.
-
|
btw, if any games ONLY have 'deluxe' MFME layouts, it might still be handy to be able to convert what's there, even if it just ends up being a bunch of generic tags we have to turn back into real text to get something useful - at the very least we get something with lamps in reasonable positions for further tweaking though. |
Beta Was this translation helpful? Give feedback.
-
|
I have a note to look at doing something like that with the DX layouts that have no classic, when all the classics are rebuilt. I'll do full extracts at that stage, so I can probably get reasonable colours set up for those lamps too, by analysing the image data and perhaps then mapping to a limited palette. when confidence is high. |
Beta Was this translation helpful? Give feedback.
-
|
@davidhaywood Making a bit more headway with this new .lay builder :) I'm expecting the .lay files to be about 33-50% of their original size with the new approaches using groups and params (plus going to write a custom xml writer, so I can do clearer human-like formatting of various parts, which will also shave off a bunch of wasted returns+tabs). One of the next things I'm planning to look at that wasn't present in the original one is to detect how many rows of text is rendered in MFME, as it would rely on its own text wrapping rather than having 'hard returns' in a lot of layouts. So then in the generated .lay it would render as: FEATURE instead of all being squashed up on the same line like it is currently (that plus the MAME font I have forced to very small right now, this is still all WIP) - should hopefully make the layouts a bit more legible when it's done (although my line breaks may not perfectly match MFME for something like XXX Y ZZZ). |
Beta Was this translation helpful? Give feedback.
-
|
@davidhaywood @james-wallace-ghub Hey guys :) I've been following the conversation you were having on mamedev/mame#10015 ... re: "the layout now specifies if the 7seg is inverted. I guess this makes sense, if they used different component types which inverted the signal or something. kinda feels like we're missing a level of abstraction somewhere, but as it's mostly guesswork based on behavior, it should be ok for now." I'm sure you already know, but just in case - in MFME, the emulator appears to be able to detect/model this without any additional game-specific configuration (i.e. within layout, as that also has a lot of per-game hardware settings, much like MAME's per-game drivers). Here's a screenshot showing the layout properties page for an LED on Andy's Big Time, plus the overall hardware config page... no option anywhere to manually invert 7 seg displays:
Apologies if this is superfluous information :) It does suggest though that it's (somehow) possible to have these work at the emulation level, without a per game manual adjustment. Easier said than done of course :) But it does appear to be derivable. I have been continuing to work on the layout builder, another (very rough) WIP screenshot: |
Beta Was this translation helpful? Give feedback.
-
|
hmm yeah, definitely not 2 then, I'll put it back to what it was |
Beta Was this translation helpful? Give feedback.
-
|
I don't suppose anyone has a photo of any of the hopper drive boards? I'm still trying to work through this stuff, and while there are things I can impute from debug analysis and a bit of program checking, there's some things that make no sense. |
Beta Was this translation helpful? Give feedback.
-
|
I do not... however, is the hopper board easy to get access to, and/or remove, in order to take a photograph of it? There's a couple of machine owner people on MPU Mecca site I could ask nicely, to see if they'd could take some 'usable' quality photos if that would help? Also, this is probably not relevant, or perhaps too janky to be of use, but I see lots of MPU4 vaguely related hopper code on the old leaked copy of MFME source code, addresses and hopper commands and the like. Could anything useful be gleaned from this stuff? If so I have a VDI with it building/running in, or can zip up the source... though I'm sure you guys already referenced this for some of the MAME stuff way back when (during 'the troubles'). |
Beta Was this translation helpful? Give feedback.
-
|
the MFME way of doing it is basically 'everything in-line' and the same style hacks being used here, rather than everything going through the right channels. Sometimes I'm kinda amazed that software worked at all. |
Beta Was this translation helpful? Give feedback.
-
|
That hopper code... I did look at it and the problem is that everything is based on that one central timer - strictly speaking the DUART emulation there isn't a DUART at all, just a structure for hanging the inputs off. And that means on the hardware level, it just plain ignores stuff we would want to do. I need to go back into the ticket dispenser/hopper code and write some output handlers for it that might help a little, but hopefully there's enough there now to at least sort some of this out. |
Beta Was this translation helpful? Give feedback.
-
|
fwiw, looking at the layouts we already have the one for 'Alphabet' is mostly correct, but it looks like that game doesn't use a standard '3 lamps per reel' setup. I'm guessing the layout generator assumed reel lamps were always a standard mapping? |
Beta Was this translation helpful? Give feedback.
-
|
My plan is to also regenerate all the existing layouts with the new generator, not just missing ones - and checking for errors/differences between the new ones and the old ones as I go (so I don't nuke any actual layout content change work that has been done since my initial commits) - so all these original layouts should be replaced when I'm done, with the new improved ones. I do have a concern when there's often just a single number or two changed, for instance: j6indy6.lay (Layouts for Indiana Jones with the £6 jackpot and the £8 jackpot). I think that's going to cause insane bloat if I could come up with a way to generate those with minimal manual work. Some machines would end up with 3x nearly identical layouts, or even more (£4.80 / £6 / £8 / £10 variants of a single machine etc). Would it be better to stick to one layout per game for now, accepting the Jackpot decals wont match all the ROM variants/DIP configs, until it's possible to do something like a 'base class' version of a layout (or view)? Then one approach could be that the child .lay has something to show it extends the parent layout (<include "j6indy/lay/> for example), and then does something like override named element/groups etc? So it could override a named element that it a text element showing "£6", with "£8" etc. Another way could be to extend Views, so just override specific group/element refs from the base View there, so one .lay would have parent View for £6, and tiny child Views for £8/£10. There's probably a better way to do this, just throwing out a couple of ideas. Just a thought for future anyway, I read above there's a big TODO list somewhere for the layout system :) So for now, I'm thinking just one .lay per game, if that sounds sensible? |
Beta Was this translation helpful? Give feedback.
-
|
Ultimately, that's where I wanted to go, different stake/prize combos in the same file, or at least some sort of import feature so it wasn't mass duplication, but that was way out of my range to bring in. |
Beta Was this translation helpful? Give feedback.
-
|
If/when such an import feature is ever made, I will update the fruit layout generator, and in theory can simply click one button and it'll regenerate all the fruit machine layouts with the required changes/improvements. It'd also be nice so all the layouts can also share a common header for generic svg elements like the reel lamp effect, rounded corner images, that kind of thing (rather than redefining the same common svgs in every layout). I'm keeping this all properly backed up this time round as part of Arcade Sim, so I should be ready to rebuild everything as and when things change with the Artwork system. |
Beta Was this translation helpful? Give feedback.
-
|
The layout format is sadly rather inflexible, it would be nice to have a concept of fragments and variables that could replace strings based on layout selection, but it isn't possible AFAIK, so copy paste is the only way to go for now. I'd rather see options available for every game that reflect the possible configurations of that set (so for ones that get the stake/jackpot from the keys, that will mean multiple layout views in each layout) One of the things that I find sad with MFME is that they only focused on a single set for each game, and really didn't care about the others. I'd rather MAME avoids falling into that trap, and instead ensures all different versions are available with appropriate internal art at least. |
Beta Was this translation helpful? Give feedback.
-
Ok - well I'll initially do straight converts to start us off once I get to that stage (still a couple of weeks of stuff to do yet I reckon, before moving onto other machine layouts). We'll have to work out how best to do this... as it'd be good for the generator to be able to generate them all, so I'll configure for each base layout which text strings represent changeable stakes and what those values are, or something like that. I'm aiming to keep it so that the layouts don't need manual changes after generation, so then if I think of new improvements etc I can regenerate and the diffs to source should just be those improvements. Once it diverges it's going to mean I can't continue to refactor/optimise/improve the layouts as the additional manual diffs will make it really painful... |
Beta Was this translation helpful? Give feedback.
-
|
Testing layout stuff with Adders & Ladders, I got this 'TOKEN REFILL' error message: At that point, the start button flashes and the machine is unresponsive. I suspect it's down to the tubes being emulated correctly, and so the machine sees the token tube as empty, after enough has been paid out. I believe in MFME, the tubes are 'hacked' so they always return that they are full, so this message doesn't appear after extended play. I'm not sure what the plan for this is with MAME..? Currently it's realistic, but does also break everything when a tube becomes empty :) |
Beta Was this translation helpful? Give feedback.
-
|
Ok, pressing 'R' does being up the TOKEN REFILL error. I'm a little confused but even if I delete the NVRAM, it still 'remembers' and shows the TOKEN REFILL error. That must somehow be saved elsewhere - very odd, or very simple and I'm missing something, I am knackered :) Video showing repro on my machine: So for me I'm seeing:
I'm not sure how it's doing this lol :) Edit: Ah apologies - ignore all that, when pressing R that is saved m4addr.cfg. So probably I simply inadvertently pressed R when playtesting the layout, and that caused this. |
Beta Was this translation helpful? Give feedback.
-
|
I had that save state mapped to the 'R' key on my keyboard. That is also the key to toggle the Refill switch. So upon loading a save state with the R key, it also processes the same R keypress as an input to the machine. When toggling the Refill switch while it's on the Feature Restart / Respin skillstop (which is where that save state directly begins), the machine isn't monitoring it. So once you land on Respin, the code kicks in and checks it, and the error is displayed. So it's not a bug with the emulation :) (though potentially a bug in MAME, perhaps it shouldn't process the keypress entered into the UI to load the save state, as also a machine input, until the next key down). |
Beta Was this translation helpful? Give feedback.
-
|
yeah, pressing R will then expect some other sequence where you refill the machine. I'm not sure what that sequence is (probably some other sensor?) one of the reasons I'd like the layouts to all be mouse driven with clickable artwork is that it minimizes the chance of accidentally hitting one of the admin keys |
Beta Was this translation helpful? Give feedback.
-
|
and yeah MAME UI keys falling through to the emulation is a big issue with a lot of systems, it causes problems on some computers when trying to change discs too. |
Beta Was this translation helpful? Give feedback.
-
|
Ah ok cool, so long as it's logged as a known issue, that's all good :) |
Beta Was this translation helpful? Give feedback.
-
|
Just checking in - I'm still on the layout builder, taking longer than anticipated, as is often the way with these things :) Finally got the 'soft return' word wrap stuff working, so now the text is better distributed on the lamps/buttons/labels etc where the layout relies on that (for instance in this test Adders & Ladders). Just put in 'frames' which gives some outlines for areas on layouts that have them. I'm probably still a few weeks away from scaling up to more MPU4 layouts, bear with me... |
Beta Was this translation helpful? Give feedback.
-
|
@davidhaywood I'm moving to a new layout with different reel symbols, so I can develop something for parsing reel symbols from text files/earlier versions of the .lay files. This was always going to be an issue - so was just wondering; how did you go about unscrambling the lamps themselves to make your test Classic Adders & Ladders MPU4 layout work correctly (once you'd given it the correct 8x lamp column Chr values)? Was it just a case of careful trial and error per lamp, or did you figure out any kind of magic way to determine the old lamp number -> new lamp number mappings? MPU4 Graffiti layout, showing incorrect lamps: 0x00, 0x60, 0x40, 0x60, 0x20, 0x40, 0x40, 0x20 (MAME driver correct lamp chr values) I'm guessing it was just working each lamp out manually, but thought I'd best check! :) - in which case, I guess I'd initially just generate them with these wrong lamps where they occur, perhaps someone can be tempted into working them all out in the source MFME layouts, so I can then rebuild them for MAME. |
Beta Was this translation helpful? Give feedback.
-
|
The lamp descrambles were done manually, yes. Since a lot of games share characterizers, there was a lot of cross-referencing done too, eg. the "tri98" style ones are basically trusted, so if another game used a different chr but also had sets using tri98, the scramble was done to match a known working decode. There are a handful of games where I'm not 100% confident as there was nothing to cross-reference with, but even in those cases I'd say I was 95% sure based on lamp use. |
Beta Was this translation helpful? Give feedback.
-
|
It's great work all the Chr 8x lamp value derivation you did :) I can confirm that the Classic Adders & Ladders 8x lamp chr values are correct, as I've used them in a real machine (through making a patched ROM so the real machine can run without the Chr chip, instead retrieving its 8x decode values from a new routine added to an empty area of the ROM). I have also had verification that Blue Moon 8x lamp values from your work are correct on real hardware. (Both Classic Adders & Ladders and Blue Moon were games where the MFME layout had incorrect 8x lamp values, so my initial ROM patches had lamp issue on real hardware, until you figured out the 8x lamp decodes from the protection patterns). But, when you had done them for Classic Adders & Ladders, you must have then had an additional step where you worked out the lamp numbers to actually make the layout work correctly with the fixed 8x lamp values. So I will need to do that step, or find some patient MFME folks to do that step, for each of the affected layouts - otherwise those new MPU4 layouts I provide will in some cases initially have the lamps scrambled (due to the MFME layout being built with incorrect 8x lamp chr values). I'm guessing that's still preferable to no layout though, so I'll just carry on for now, and they can be dealt with at some later stage... at least the other platforms don't engage in the lamp scrambling, so it'll just be some MPU4 layouts that have the issue :) |
Beta Was this translation helpful? Give feedback.
-
|
well for Classic Adders and Ladders, yes, I went over the layout and manually fixed the lamp values. Basically each scramble value acts as a 'xor' on each row. I knew what the old layout expected, and was previously being provided, and I knew the difference in the values in my lamp values compared to the old ones. From there I created a table of what the 'old' lamp number in the layout was, vs. what it should be. I search+replaced each of the lamp values that would need changing, so "lamp64" was renamed "lampxxxx68" for example. After doing all the renames I then removed the 'xxxx' part. basically if you want to hand-fix the layouts to work you need to know the (incorrect) CHR lamp table values MFME used and the (correct) CHR lamp table MAME uses. I guess it would be cleaner if this could be built into the conversion process, but for Classic AL it was done by hand. |
Beta Was this translation helpful? Give feedback.
-
|
expanding upon this... If you look at the default debug layout in MAME it is arranged like this each of those 8 rows is controlled by a different value in the table so in the case of the adders and ladders table despite some of the lamp tables having more bits set (I assume these were read from hardware or something) the game code only uses 4 bits in each byte for swapping the lamp data a value of 0x40 swaps like so (using the first row as an example) which is a XOR of 64 (xor any value with 64) to get new lamp value a value of 0x20 swaps like so which is a XOR of 32 (xor any value with 32) to get new lamp value a value of 0x10 swaps like so which is a XOR of 16 (xor any value with 16) to get new lamp value and a value of 0x08 swaps like so which is a XOR of 8 (xor any value with 8) to get new lamp value combinations of bits combine the XOR values, so 0x48 would be 64 + 8, a xor of 72 as I said, other bits can be ignored, so if 0x04, 0x02, 0x01 or 0x80 are set in the table they appear to have no effect on the lamp scramble (unless they're used for extended lamps, but I'm not seeing that, as I said, I assume in cases where those are set it's because the table was read from hardware, and those bits are set but not used by the lamp scramble) so basically, to convert from incorrect MFME lamping to correct MAME lamping work you need to use the above information to remove the incorrect MFME scramble from the lamp numbers in the layout, and replace it with the correct arrangement, so that when the game writes the descrambled data (as it's the CPU reading the table, and doing the descramble) the correct lamps are triggered. I did notice some MFME layouts were trying to do all the lamp descrambling in the layout, rather than having a correct table for the CPU to use. That approach actually falls apart completely in cases where games only go through the lamp scramble function for SOME lamps, and write others directly. (a few do that for clear effects) If you're still in doubt, just list the ones I need to manually fix when you convert them. |
Beta Was this translation helpful? Give feedback.
-
|
Ah wow that is great news - that it can be automated with the data I have available here :) Thanks for this detailed explanation of the process and the XORs - I do indeed plan on building this into the Layout Builder as an optional stage, since it can be fully automated - really a relief, as I'm not sure people would be queueing up over on the MFME forums to do this by hand, since from their perspective the existing layouts 'work' (even though not properly, as you say for hardcoded clear effects etc - I certainly saw some subtle lamp issues with the original Adders that were fixed once I manually remade it with the correct 8x lamp values from your MAME characteriser code). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks again for the help with the remapping process :) I've got some finishing up to do, but it looks like it's all working ok - MPU4 Graffiti after the automated lamp remapping applied: |
Beta Was this translation helpful? Give feedback.
-
|
Just checking in with another update :) The work is going slowly due to lack of time (the noisy neighbours on both sides of my terraced house have got the better of me, so now I'm balancing full time job + building false interior walls both sides of house to block the noise, so FME dev is getting a smaller slice of time than is ideal), but still progressing... Been doing work on more reel symbol layers, and also got JPM input/reel alignment working, here's a couple more test layouts: MPU4 Graffiti with fruit symbols/overlays: MPU4 Sunset Boulevard with boxed symbols: JPM Impact Big Bucks - some symbols have a red background stripe layer, buttons/coins/reels working (minor issue with hold 2/3 lamps to figure out): |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Ah well, in this example I noticed with Sunset Boulevard - I've just double-checked and and also some of the actual button inputs are also different... so I think it would need to be treated as two separate layouts - I've attached (these are bloated non-optimised debug layouts, not ready for the codebase!) Once you get holds on m4sunset you'll notice the Hi button flashes, and acts as a hold button, while Hold1 does not flash or function as a hold button... on m4sunsetd all works correctly (both the layouts in the zip above are the same layout just named differently for quick testing). Perhaps it was housed in a different cabinet or something... |
Beta Was this translation helpful? Give feedback.
-
|
probably different cabinet types then. there were also sets market as Sunset Boulevard that turned out to be oki type, eg. m4sunseta (although could just be another game mislabeled, there was plenty of that) anyway m4sunsete is BS__ 1.1 (the oki types are B25 1.2 fwiw) Maybe BSx sets and SBx sets are different cabinet types, maybe SBx is some kind of showcase? maybe they're just different games? If m4sunsetk (SB 1.1) is the same lamp setup as m4sunsetd (SBU 2.0) then we probably have 2 cabinet types. (or the game was popular enough to be rebuilt from scratch and reissued as a new machine without moving to a new platform?) the bootleg m4sunsetc is OSB 0.2 in this case, which is a different code again, but being a bootleg could be a hacked code. There are other machines where we've seen 'new', 'super' or 'mk II' versions, which would have clearly had different artwork, and maybe extra cases, so could be one of those cases. |
Beta Was this translation helpful? Give feedback.
-
|
I've done a quick test :) So I've only generated a single layout, as I only have 1 single source MFME Classic layout (which uses the m4sunsetd roms). Using that layout with those other romset you listed: m4sunset - Lamps & Buttons not matching m4sunsetd (2p play) If m4sunsetk (SB 1.1) is the same lamp setup as m4sunsetd (SBU 2.0) These lamp setups do match the above statement. Note that the button mappings are also different (so the Hi button flashes instead of Hold 3, and to actually hold reel 3, I need to click the Hi button). It's like you mentioned before though - often in MFME land, the most fun to play ROM version is the one on the highest stake with lowest jackpot, as you get a lot more action in the same number of spins... and so a 20p play Sunset Boulevard MFME layout exists, but not a 5p or 2p, as they're a grind to play. So these at some point would need fixing up (by making a copy of the m4sunsetd MFME layout, fixing buttons +lamps to work with the 'other' type of rom, then building a second Sunset Boulevard MAME layout from that. Gah, there's a lot more to this even when I've got it generating the optimised layouts from the source MFME layouts then! Ah well, I'll keep chipping away as I get bits of free time... :) |
Beta Was this translation helpful? Give feedback.
-
|
glad to see you're still chipping away, my progress has kinda stalled until the branch gets merged in, but I'm sure we'll get there in the end |
Beta Was this translation helpful? Give feedback.
-
|
I was originally going to use the existing workflow I have for Arcade Sim as that's how I've been working on the extracting of these layouts... but it's just not scalable... each of the folders here pretty much represents the number of 'base' machine layouts (ignoring custom stake/prize variants) needed for MAME (as this time round going to make those initial playable 'textless' layouts too where only a DX is available). ~3,000 really is a lot to configure :) Though some of the hardware platforms aren't set up in MAME yet... so some of that 3,000 will come later. I'm making a bunch more tooling and helpers to try automate/speed up the overall process to something more feasible. I'll still be able to focus on platforms we need first once this is built (Initially MPU4, then JPM SRU, MPU1, and the potentially upcoming 'BLACKBOX')... but it'll take a while to build this stuff. But overall I'm certain it'll save me a ton of time, as I really want to get all fruit machines in MAME with a 'new style' layout. Will there be any issue with ultimately having the ~3,000 .lay files in the MAME source? After optimisation (not yet done) I believe the individual layouts will be 50% of the size of the original MFME2MAME layouts I did, maybe even smaller... but there will be a lot more layouts, as I'll be filling in gaps with the initial 'textless DX conversions'... but it'd be good to know before I embark on this quest! :) |
Beta Was this translation helpful? Give feedback.
-
|
I took the liberty of asking about Bell Fruit Flat Chassis at the Mecca someone posted a pic of one of the boards https://www.fruitemu.co.uk/ib/topic/25725-bell-fruit-flat-chassis/#comment-374855 |
Beta Was this translation helpful? Give feedback.
-
|
That brings back memories, I remember repairing those. The triacs which drove the payslides had 240V on their tabs, dangerous times! I don't recall the other electronic tech he posted though. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @james-wallace-ghub and @mamehaze :) I'd been ill so away from the scene for a while. I have been back to slowly plugging away on some FME-related stuff though :) It's not ready yet, but I thought a preview would be good. So the new project is a suite of programs (Oasis suite) to allow others to work on this stuff that I was doing all manually/with coding before. So there is a split out tool in progress, that takes care of extracting layouts from MFME to an open JSON structure with accompanying BMP images: ...in conjunction with that I'm working on a Layout Editor:
...and this will have the MAME .lay builder ported/upgraded into it. So the layout is firstly Extracted from MFME, then Imported into Layout Editor, and then can be Exported to MAME .lay format. The Layout Editor will also allow for creating layouts from scratch, so will be generally useful for MAME internal layouts outside of just fruit machine layouts. It also runs MAME as a child process and can render the emulation/send input to MAME (via Lua), so this will be helpful if creating new layouts to test lamps/buttons etc: All a work in progress for now, but thought it was worth an update :) Sorry I abandoned the last big attempt at this - but lots of that work is finding its way into this new work, so not a complete write off! And this way, it won't actually need specifically me, others will be able to help, with labelling reel text symbols etc (some people have indicated they'll be down to help with that sort of stuff from over on Dif forum. The repo is here, and I'll update again once we're at the stage of outputting MAME .lay files, as I'm prioritising that over all the 3d stuff it will do later. |
Beta Was this translation helpful? Give feedback.
-
|
It does feel to me that the lay creation is the stumbling block here, so something cleaner than the existing setup is a good move. I think trying to find a good route to do this is something that has been beyond me, so I'm keen to see where this goes. |
Beta Was this translation helpful? Give feedback.
-
|
I've looked at the MFME .fml files and they're compressed using a Delphi library called "EasyCompression" program mfme_decoder;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils, EasyCompression;
const
levelValue: array [0 .. 3] of TECLCompressionLevel = (eclNone, zlibFastest,
zlibNormal, zlibMax);
var
fs: TECLFileStream;
s: string;
begin
try
fs := TECLFileStream.Create(ParamStr(1), fmOpenReadWrite, '00908434');
s := ParamStr(1) + '.dec';
fs.SaveToFile(s);
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;Sadly they are still not really readable, it's a binary format I haven't understood yet. |
Beta Was this translation helpful? Give feedback.
-
|
That's great work. If I can find a Delphi compiler I might have a play with this, unless you've a precompiled version available ? Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Never trust random exe files downloaded from the internet: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for that. |
Beta Was this translation helpful? Give feedback.
-
|
I tried with |
Beta Was this translation helpful? Give feedback.
-
|
The key seems to be calculated dynamically, I suppose more research is needed.
I did not that the cleartext .gam file was in memory the entire time, the key is probably calculated from that somehow |
Beta Was this translation helpful? Give feedback.
-
|
I did do a very 'long-winded' approach for this, using window scraping and remote control of mouse/keyboard to load and extract the layout from a running MFME.exe instance: https://github.com/johnparker007/Oasis/tree/main/WindowsNetProjects/MfmeTools If someone took the time to completely decode the MFME layout structure so it could end up being a command line tool that outputs a layout like my program (json + images) without the messy screen scraping etc or even needing MFME at all, that would be much nicer :) |
Beta Was this translation helpful? Give feedback.
-
|
I saw your previous work on it but yeah, I want to avoid running MFME at all. |
Beta Was this translation helpful? Give feedback.
-
|
Well if you pull it off, that would be super cool! :) And I'd update my tool to use your system if that's cool with you. I don't like the screen scraping stuff, it was just something I already had half working, so it was quickest way to get it up and running. But it is super janky lol :) |
Beta Was this translation helpful? Give feedback.
-
|
MFME will load a fml file without having a gam file so that can't be used for the password. |
Beta Was this translation helpful? Give feedback.
-
|
No, there doesn't seem to be one, there is only the AACS header from the library. Maybe it's the filesize in hex. |
Beta Was this translation helpful? Give feedback.
-
|
A renamed fml still loads ok, so it's not the name.
…On Sun, 30 Nov 2025 at 19:16, stonedDiscord ***@***.***> wrote:
No, there doesn't seem to be one, there is only the AACS header from the
library. Can you test loading a fml file that has been renamed?
—
Reply to this email directly, view it on GitHub
<#2 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXSXQJ3KTMVZ2ALXHZZPKIT37M7BZAVCNFSM6AAAAACNRXSSWGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJRHAYTSMI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Just to add, as might be related; each time you save even the same completely empty new layout, the fml grows a few bytes with each subsequent save... 
Could perhaps be using the crc/md5 then with some internal algo to gen the password... unsure what it adds each new save. |
Beta Was this translation helpful? Give feedback.
-
|
Adding a few zeroes to the end does nothing, adding a bunch of them prevents the layout from loading - pretty sure it's in the size. |
Beta Was this translation helpful? Give feedback.
-
I tried that and it fails for me even if I had only one 00 |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't look like its the size. |
Beta Was this translation helpful? Give feedback.
-
|
I think this time I figured it out for some of the files: program mfme_decoder;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils, System.Classes, EasyCompression;
const
levelValue: array [0 .. 9] of TECLCompressionLevel = (eclNone, zlibFastest,
zlibNormal, zlibMax, bzipFastest, bzipNormal, bzipMax, ppmFastest,
ppmNormal, ppmMax);
var
fs: TECLFileStream;
inputFile, outputFile: string;
last4Bytes: Cardinal;
passwordInt: Integer;
const
XOR_CONST = $00C59A00;
{$R-}
{$Q-}
function mixer(a1, a2: Integer): Integer;
var
i: Integer;
x, v4: Cardinal;
addr: Cardinal;
begin
Result := a2;
addr := Cardinal(a1);
for i := 0 to 99 do
begin
x := addr xor Cardinal(Result);
v4 := (x shr 24) or (x shl 24) or (x and $00FFFF00);
Result := (v4 shl 3) or (v4 shr 29);
end;
end;
begin
try
if ParamCount < 1 then
begin
Writeln('Usage: mfme_decoder <inputfile>');
Exit;
end;
inputFile := ParamStr(1);
outputFile := ChangeFileExt(inputFile, '_decoded.dat');
var
fsIn := TFileStream.Create(inputFile, fmOpenRead or fmShareDenyNone);
try
fsIn.Seek(-4, soFromEnd);
fsIn.ReadBuffer(last4Bytes, 4);
finally
fsIn.Free;
end;
Writeln('Bytes: ', last4Bytes);
passwordInt := mixer(XOR_CONST, Integer(last4Bytes));
var
passwordStr := LowerCase(IntToHex(passwordInt));
Writeln('Password: ', passwordStr);
try
fs := TECLFileStream.Create(inputFile, fmOpenRead, passwordStr);
fs.SaveToFile(outputFile);
Writeln('File decoded to: ', outputFile);
finally
fs.Free;
end;
except
on E: Exception do
begin
Writeln(E.ClassName, ': ', E.Message);
Writeln('Trying alt password');
fs := TECLFileStream.Create(inputFile, fmOpenRead, 'b67de657');
fs.SaveToFile(outputFile);
Writeln('File decoded to: ', outputFile);
end;
end;
end.The last 4 bytes are the password but run through a XOR mixer 100 times. |
Beta Was this translation helpful? Give feedback.
-
|
Nice work :) I do kinda of bear some responsibility for this, as Chris changed his save format directly after my original 'mfme2mame' project! So I'm guessing the alt password (b67de657) is just a placeholder, pending further investigation... impressive stuff. |
Beta Was this translation helpful? Give feedback.
-
|
I created my own fml file and it seemed fairly structured and semi-meaningful but other fmls looked completely different but I eventually found some similarities. The images are stored as bitmap files with a control header before them. Easiest way to find them is look for the font name, "Tahoma" was used on the fml I looked at. Sometimes you get some extra 'tags' between the images, no idea what they do. Somewhere in all that is the number of "on" images as you can have images which aren't allocated to a lamp so aren't in the 12*4 table. That's all I've got |
Beta Was this translation helpful? Give feedback.
-
|
Nice work, that's some impressive progress! :) |
Beta Was this translation helpful? Give feedback.
-
|
Had some time while waiting for other stuff to happen. Need to keep editing the layout and changing flags one at a time and see what changes to workout what all the bits actually do so it won't be a quick job. |
Beta Was this translation helpful? Give feedback.
-
|
It's deffo a good start, with lamps being the most common component :) Hopefully @stonedDiscord can make use of it in his quest! I did look into this a bit back, but since I already had my clunky-but-functional solution kinda working, I just carried on down that route, and now have all the component scraping mostly done I think (and then import them into the layout editor)... though if there was a way to reliably import from any version of an MFME .fml, that would be loads cleaner :) |
Beta Was this translation helpful? Give feedback.
-
|
Also @stonedDiscord - if you do decide to do a deep dive and decode all the possible MFME components from the various versions of .fml, here is the relatively comprehensive structure data for each of the components, may be of use setting up your own - good luck :) |
Beta Was this translation helpful? Give feedback.
-
|
For now I'm most interested in the element positions, this alone would make manual layout creation much easier. So parsing the fml to get parameters 01-04 is what I'm going for right now. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
A continuation of mamedev/mame#9632 (comment) , so we don't pollute the PR system any more.
Beta Was this translation helpful? Give feedback.
All reactions