johnparker007

Yes I'll try that newly built MAME exe tonight with some of the WIP layouts - they should all boot now instead of crashing back to DOS with that exception - I'll post up a few screenshots of them

Haha good to know ta, looks like I can dodge setting Git up for a bit longer then

I guess I'll finally have to get around to setting up Git on this PC so I can sync and build a copy ahead of the official release, I use Perforce for all my source control stuff...

Re the MAME 'too many textures' bug - thankfully I've just received a notification, that the arbitrary limit has just been increased x5 by Olivier to unblock me That is a relief!

Thankfully I've just received a notification, that the arbitrary limit has just been increase x5 by Olivier to unblock me That is a relief!

Worst case scenario, if the max textures can't be increased - I just have to ditch all the work that's been done making these lamps, and just go back to very basic solid colored rectangles, that would be rather disappointing though. At the end of the day, long term I think people will be using Arcade Sim to play cross-platform MAME-driven fruit machines anyway (much like people use Visual Pinball to play MAME-driven pinball machines), rather than the minimal MAME internal layouts - they're more of a help to us developers/testers - so we can playtest a machine just using MAME.exe and the ROM, with no external factors to cloud the test results (and of course for conceptual preservation of the machines).

No, as there are other rendlay issues, but Cuavas is resistant to certain things being changed on the layout system... so it's currently more a case of seeing what Cuavas feels about this one (as the layout system was perhaps not envisioned to do more complex layouts like I've been generating).

Ok cool ta - he's not replied on that thread, but I'll work on other parts of this project for now and perhaps head back to Arcade Simulator work when I get truly blocked, as until the MAME bug is fixed, most of the new layouts don't actually boot!

A 'new' layout WIP to MAME: One of the few that doesn't crash MAME with an error... I've asked the MAME guys if I/they can fix this by doubling a capacity for textures, so waiting to see if we can increase the value in MAME source to support the new style layouts - I'll keep plugging away on other areas, but it'll be good to get this MAME issue resolved...

I don't know if you saw, but I did put a post on the MAME dev thread on github, regarding the maximum allowable number of texture instances - with the current SVG lamp rendering, I do keep hitting this on most layouts: Fatal error: render_texture::get_scaled: Too many live texture instances! I've not got MAME synced, but I suspect there's some arbitrary limit constant somewhere, that really needs to be double what is currently is - though I'm not sure if Cuavas will be of the same opinion, as he did complain I was trying to do too much with the artwork system! It's due to the lamps now being drawn completely differently with groups, variables, layered svg - seems to be needing more textures, I think because the base buttons are not all a consistent size, as often happens, so then it must premake more textures, rather than reusing the same size button texture over and over - I just got lucky with the first couple of test layouts I made (had more consistently sized lamps, so I didn't see the error), but as I scaled up, I'm getting the error on most layouts... Old lamps: New Lamps:

There certainly aren't intentions not too At present standard MPU5 machines aren't running in MAME, so I think they would be focussed on first, as that would also probably solve some general MPU5 emulation issues... so they will not be for quite a long time I don't think... the main focus at the mo is on the older techs.

I've asked on that discussion thread that Cuavas, David and James are on, if the limit could be doubled. I'm hoping they will come through for me! Though Cuavas has already scolded me since I'm already trying to do stuff with the internal layouts that's beyond the original scope So I suspect he will say, 'ditch the fancy lamps, just use plain rectangles'...

Ah good to know, I thought all the Impacts had layouts after the recent Impact driver work, but I've not had time to carefully go through them, I just tried a few and they had layouts, so I assumed they got a second round of mfme2mame conversions - right I'll extract Impact platform next then, since MPU4 needs that extra chr stuff scraping first...

The Characteriser stuff only affects MPU4, the issue with MAME crashing with 'too many live texture instances' is just due to the custom lamp/shading render technique going over hard limit (these new layouts with layered svg lamps are the most advanced thing done so far I think, and the MAME render system is pretty basic), not related to tech. I think most Impact machines have layouts now, James used mfme2mame to fill in some I missed on the initial run.

Been working on the layout generation stuff still, got it generating some now from these autoselected/autoscraped layouts. This new progress has highlighted more bugs to deal with and other issues... up to generating ~10 MPU4 layouts so far before a critical failure: I've realised I need to do yet more with the MPU4 scraping, as I need to scrape the Characteriser lamp tables, so that where it is wrong in the MFME layout, I can correct the lamp numbers to work with the correct Characteriser lamp table in MAME (otherwise the lamps are scrambled). So I'll start scraping some other platforms tomorrow until I can get time to implement that for MPU4, since apart from the Characteriser, the scraping side is generally complete for what's needed for these MAME internal layouts. Another slight show-stopper, is that due to how MAME's internal layout renderer works, my fancy new shaded, rounded corner lamps may have to go (sob, I spent ages getting them looking nice!)... I might look into working out the layouts that are likely to cause issues, to then make them fall back to the old minimal solid rectangles... not sure yet, as then the layouts would be randomly inconsistent on the lamp/button shading, which might be worse. The test layouts I developed it on, while they had plenty of lamps, the lamps were a consistent size... but, for each lamp of a different size, MAME has to generate an internal texture, so a simple layout such as this has broken it, purely due to it needing to make more textures for varying sized components: So running that in MAME results in this While the array size of this could be increased (in MAME source), I don't think Cauvas will be on board with that, due to the increased memory hit on constrained ports of MAME. So this layout (hacked a little to render for demo purposes): Would instead have much more basic lamps/button shading, like this (the original 2016 mfme2mame layout): Bit of a shame, but at the end of the day, the purpose of it is just to get functional layouts in MAME for all the games, I think most people will be playing them in Arcade Simulator rather than these text layouts anyway! But they are important to have, so then it's easy to work in emu dev in MAME, and be able to properly play the machine... ah well, gotta keep on keeping on, this was always going to be a massive job lol

It's a known issue, it's on the Known Issues sheet, linked in my sig

Now have the 'border' MFME component scraping set up, that I'd somehow missed... along with some other things, to help me put layouts to one side that won't currently scrape without disrupting the overall flow, since there's a lot of scraping to get through. Going to restart the scrapes for MPU4 since that's where I first started seeing warnings that I was missing border components... Example of new Border component in Dennis The Menace MPU4 extract:

Great work as always mate Hobby time is a struggle with real life and jobs, we make progress though in the end! Thanks for the build and ROMs - with that exe including blackbox, I should be able to romident the 7x mfme blackbox layouts with their MAME names. Started on the MPU4 scraping, but hit some bugs that I need to fix, then restarting early next week during the days... next big job alongside this is some semi-automated reel symbol identification (I think a back of the envelope calc suggested over 200,000 reel symbols across the 3,000 layouts, so I need to develop some tools to automate it a bit!).

That's great, thanks @Altharic

A little update, have been working on more for setting up the batch extracting of the auto chosen layouts for MAME internals which seems just about ready now, and also now setting up the config scraping, have set up MPU4 so far, rest should be a lot quicker now I've done one page - it is this additional data needed per layout: (which differs by tech - will be useful for batch tweaking MAME drivers per game to have the correct 'traits'). I'm about ready to start the next stage of the extracting during the days at least while I'm working on the other PC The scraper is fragile and needs baby-sitting, it has a fundamental crashing issue that I've not been able to solve - I didn't anticipate I'd be attempt to batch scrape 3000 layouts, so I'll have to see how painful it goes! This will be getting underway tomorrow am... Already done the extracts for SRU - though I couldn't progress as I don't have the revised MAME romsets, same for Blackbox (though I suspect I have another rom ident issue to sort out like we saw with the MPU5 roms). Perhaps @SomeRandomGuy could hook me up with the new MAME roms for those two techs please? I do have the MPU4 roms however, and that seems the biggest one to try work out the kinks as best as can be with the scraping tech as it stands, since from my graph above it looks to have 774 layouts total to be extracted, a popular tech Alongside limited graphical extraction (I'm skipping lamp & background images to save time as they're not needed for these MAME internal layouts, only the reels), this is the current json file that is generated for a layout for those interested - I suspect this will stay on zero downloads, it's heavy reading lol Chase_The_Ace_Cards_(Empire)_[C01_8jp].zip

MPU5 looking a bit better now @wolf676 I think some of the MPU5 Roms may have been patched to run in MFME... I was just checking the first rom, and getting very few additional matches. Then I compared the two (MAME vs MFME layout rom), and found some altered bytes, that looks very much like a cheeky patch I then had it test against all four parts and got a lot more matches Since MPU5 and Scorpion 5 are the newest supported platforms, it makes sense there's a higher proportion missing from those.

I did have it on checking further in my Art folder, it's from an old 3d MAME frontend (a little bit like an early Arcade Sim!).

I did already have a feature in the backlog related to this: "Camera X/Y/Z/angle controls somewhere like Visual Pinball has? Kinda nice for fine tuning the camera position to just where I like it." I have added a an idea for another feature, that'll be a much easier to use 'set it and forget it' option, in the settings menu: (bool) Ensure all panels fully in frame or for more user control: (bool) Ensure topmost panel fully in frame (bool) Ensure topmost panel fully in frame (bool) Ensure leftmost panel fully in frame (bool) Ensure rightmost panel fully in frame This will be used for machines such as the Streak in casino cab, so the user can be stoody further away when playing so as to seeing the entire topbox and/or belly glass. One a 3 player party time, could be used to ensure some/all of the left/right side machines are visible. I think this idea will be more useful, so you'd simply turn on the setting Ensure all panels fully in frame, and then machines would always have play camera so that you'd see the top of that topbox and the whole belly glass. It would mean you would be stood further back for casino cab machines like The Streak, 3 player Partytime etc, and the buttons etc would be a little smaller so it all fits on screen. Yes those cabs are pretty similar, I'll perhaps adapt the existing model to make some of those others that are very similar And ta for the model, we should be ok as Spidy has made some already (though I've downloaded a copy for safekeeping, might come in handy for proportion checking), they'll be developed in Arcade Sim models at a later stage

Currently working on MAME stuff, there's a lot of steps involved in this, will ultimately be used to drive the emulation in Arcade Sim with various advantages. When it's finally done from my end, I'll be looking at getting mame to work with AS then back to JPM Electra machines.

Absolutely, as it should be - I plan to do that using @wolf676's tools above as part of the process of getting all the unmatched ROMs added to the relevant MAME drivers as new games/variants