johnparker007

That was actually one of the things I was to try next - which I did, unfortunately it didn't work out as planned, due to the 'mask' not really having enough information, but it may still do some of that 'blank pixel comparison' stuff yet, this is all experimental as always! However, with some tweaking, and following the histogram comparison with a qualifying difference comparison (simple RGB distance, no lateral shifting for this test), I did manage to get this automatic result of grouping the dreaded grainy Alphabet reel symbols I've a load more work yet - but to automatically derive the above groups, well let's just say I'm considering a trip to the offy for a couple of beers! I didn't think it could be this well on such uneven source symbols... I'm happy with the stray melon, this thing is just to reduce the work involved, a bit of human tweaking/inputting will be ok Maybe Sun pm when I next get some time... I think I need to clean up all this grotty test grouping code, into something a bit more scalable. Next steps, whether grouping a layout by the old way or this new way... is to automatically determine with a very high (doesn't have to be perfect) degree of accuracy which symbol(s) from each group is/are the 'unadorned' symbols (without 1, 2, 3 overlays etc). (Just notice the far left fruit reel is one that I edited, swapping the top Cherry with a Melon further down, when I was verifying a bug somewhere else... it would work the same without the edit)

I'm just seeing the 3,000 layouts that need all their reels 'symbolicating', and want to set up this second option for when the fuzzy compare fall short, like on the Alphabet one, so it will be a easier manual process... won't be spending too much longer on it, but it's slow work, as it's just experimental Once this is done, then there's still more - as then I want to have it make a best estimate of which image is most likely one of/the only 'base symbol' in the group without overlay numbers etc... and ideally to suggest subgroupings of the ones with symbols... then there will be best estimates for common base symbols to apply across the group (all overridable with dropdowns etc, but if it can get a lot of this right for me it will all go a lot easier Now have an improved system for estimating reel background color which fixes the broken mask on one of the '£' sign symbols. And also, have done a better version of grouping like symbols together (not perfect, I think I'm missing some recursion, but better): Now it's no longer mixing Melons with Cherries, but mixing Oranges instead! (though they are kinda closer) Along with the mixed yellows and alphabet symbols. Need to do something with more options for other areas (this is all hardcoded left 50% of image comparisons for now)...

I am already planning to do some combining Next idea when I get chance is to loosen up the histograms even more, so that then give results like this: So it has the oranges altogether, but some melons mixed with cherries etc. Then I also have realised there's a flaw in the overall processing of this, in that I take the first reel symbol, find all that loosely match, then they are 'unavailable' for other compares. E.g. on these loose settings, working down the first reel, it got to a cheery first, then matched some of the melons... leaving a melon stranded... but I suspect the stranded melon is a better match for the other melons than the cherry. SO I need to do some kind of initial pass, that compares every symbol with every other symbol, to better group the most like symbols together. So anyway, yeah with the loose histogram type result above, I think then I could do some partial mask comparisons or something like that to try derive proportional shapes, to break out the lemons from the pears etc. I'll keep going for a while longer on this stuff, as I do still see potential for a load of time saving if I can get this grouping working better for the more grainy reel scans, with there being ~3,000 text layouts to build That said, I'll cut it off at some point, don't want to spend crazy amounts of time on it! Still making progress though I think... In terms of it being too long to process, I'll probably do a mix of something that can just grind through and calculate for say all MPU4 layouts (over 700) while I'm at work. SO then the results of the calcs are all saved and can be pulled up quickly... plus perhaps ability to flag problem layouts that'll then get more passes at different settings etc. I'll worry about it later though, once I've kinda proved if it can work first Feeling optimistic still though!

Well it's a bit better, so this is doing a masked histogram comparison using the new masks, on the dreaded Alphabet grainy scanned reels: I can't be too disappointed, I mean it's working a fair bit - I just thought it'd work better lol The results aren't really any better than using my previous 'lateral fuzzy compare' technique, shown here for reference: If anything the new masked histogram compare results are less useful to me (at least in their current state), since they get confused and mix all the yellow symbols together, so it's not going to save time during inputting/processing the reels, as I'll then be dicking around untangling all the yellow symbols into their respective groups. Hmmm definitely still in the research phase, as I don't want to go off making myself loads of manual work that might be able to be (more) automated. That said, this is only an issue on some 'problem' layouts - a lot of them group nearly perfectly under the lateral fuzzy compare technique... I guess it depends what else I can come up with for accurate grouping...

Well spent ages trying to use something to flood fill to generate masks, gave up in the end and rolled my own, needs a bit more work (there's a £ sign that's just a white rectangle due to needing to do a better average background picking), but generally working as proof of concept... so once I have that working, the plan is to hopefully be able to do 'masked' histogram comparisons, which should drive the accuracy up, hopefully by quite a bit... plus I can use the masks for some other comparison stuff:

So I've managed to get some initial testing of 'histogram comparisons' in - it's not working very well though lol I loosened it up quite a bit to get some matches. As I did anticipate, it mixes similar colored different symbols together, here we can see it's got lemons, bells, pears - all in the same group, as they're mainly that yellow color. I didn't anticipate it would still fail to group what appear to me to be very similar symbols: Why the plums aren't all together, and why there are multiple yellow groups, I do not understand yet. Am tired though, I will keep going on this next week, as I really thought I'd have more luck with this approach. It's loose enough that it's grouping melons with cherries, as the left side of the melon is red as is the cherry, and the top contains red/green... along with the £ symbol, as that also contains green. But then it fails to actually match other cherries. Somethings doesn't add up, I am confused Hopefully when I review the maths and code when I'm not tired, I'll see I've made a mistake somewhere. This is an example of one of those tasks that seems like it should be easy, but is actually pretty tricky... I'm sure there must be a way to group these symbols accurately!

So I've added a hard coded test of doing 'lateral fuzzy compares' and it does improve the groupings, but, for larger reel bands such as these ones, it's pretty slow - takes nearly a minute to figure this layout symbol set out (which somewhat defeats the object as it's meant to save me time transcribing them all ready to generate text based symbols). Before lateral fuzzy compares - Cherries in 4 groups: After lateral fuzzy compares - Cherries in 2 groups: So it is working better... but it's pretty slow on these , and it's still missing a cherry in this example. It is faster on lower resolution images with the lateral checks (Alphabet is 12 seconds), and improves Alphabet too - now it groups 100% of the lemons, still gets stuck on some others though and has things like melons in two groups: I think the next approach, as this doesn't quite seem to be getting the best results that feels like could be achieved, is going to be some kind of representative palette / histogram distribution analysis, as I will hopefully be able to get that much quicker if the maths etc can be worked out, and it may prove to be a bit more robust. So in the case of say this cherry, I could sample the left half: And then derive that the green is concentrated in the top area, a little brown just before we get down to the middle, and dark to light red in a curve over the lower 60% or so of height. And also do the same for the top half: (finding a lot more green and brown). I will keep all the code that made the improved but slower results above, I think it'll be about forming a few different options for dealing with these awkward layouts. So then if I can do a way of comparing these histograms in a 'loose' way, that might give me a faster (for high resolution reels) and more successful grouping (so all the symbols in Alphabet in single groups rather than the odd split groups I'm getting now). Alphabet is one of the harder ones though All the easy ones group correctly now pretty much.

A bit more progress with the ReelId tool... I now have it going straight to a 'fuzzy partial match', first on the left half, then on the top half, and also tag any exact duplicates found (and hide them from this view). So now, machines like this are looking a lot better: In the case of the Oranges, you can see it is now coping with grouping both symbols with a block of text across the whole bottom half, and ones with a an overlay in a circle over to the right side. Adders and Ladders, which was the first test machine for this new work: The number reel, you can see it has made some mistakes (grouping 6 & 1, and also grouping 3 & 2). This is fine, I'm planning to have per layout configs, for this initial automation, so the default setting would be to fuzzy group 16/24 stop reels, but not fuzzy group 12 stop reels, as they're usually number reels rather than standard symbol reels (and so this fuzzy grouping makes zero sense). Still plenty more fuzzy coding improvements to be done though... for instance here, you can see that it has not fully grouped all the cherries, there is a stray one further down... also it has not done the lemons fully, there are a couple of stragglers at the bottom: I'm going to do some more tests in Gimp, as I think in some (hopefully most) of these cases, it's just that the original layout artist may have misaligned the base fruit symbol by a pixel or two - so I will run more 'lateral fuzzy passes', so I can for instance also do a fuzzy search with the source fruit shifted up/down/left/right by 1-2 pixels... might snap a few more into groups that it's missing, and shouldn't add any more error to the results, only successful groupings Interestingly it managed to do these, as I have loosened up the fuzzy compare ratio for these 'top half' and 'left half' checks, I guess due to the translucent nature of the central overlays: Also working ok with larger symbols, just as long as it get get a cleanish laft half or top half: And some chunkier number overlays: And also works with larger (higher resolution reel bands): Lots more to go, but definitely seems to be heading in the right direction

Tech update So I'm looking into this idea of 'fuzzy matching' areas of reel symbols with tolerance. A good example is Alphabet - it appears to have reels from scans or something, so the tool can't identify matching base symbols as matching (before it even gets into groups) - note the cherries marked below, incorrectly repeating in the Unique column - all look the same, but they are not exactly the same So I've done some tests in Gimp, here are a couple of the cherries, with an image showing the 'difference' (so if there's a similar pixel on both, it appears as dark): Source cherries A & B, then difference: A: B: Difference: So, then I tried some other similar-ish (but actually different) symbols: Bell+Lemon: + Difference: Plum+Grapes: + Difference: So I think this should work I'll initially try sort out the difference stuff, and then also I think a rough outline of non-background area needs to be detected per symbol. Again, these are bad grainy ones (picked on purpose to be probably the hardest), so it's a case of getting some average pixels from a configurable corner, and then coding a 'flood fill' that will fill all pixels within some threshold, say around 25-35%. So we'd go from this: ...to this: So then for each of the symbol images being compared, I'll have a good idea which pixels actually matter on each (so on the above image, the purple pixels will be ignored for the subsequent analyses). So then, probably taking the middle range, that will allow for counting up how many pixels went above a dark grey on the 'difference' image. Then using that middle range value compared to this count, will give a ratio. So if the ratio is low, we can conclude that the images are similar enough that they are the same symbol, and if the ratio is high, it means that the images are different enough that they are different symbols. In theory (lol should work, but might turn out not to be so simple ), that will then correctly identify the 'unique' symbols, even though they are slightly different due to scanning grain/misalignment etc. From there, the next stage (seen in previous post above) that groups symbols based on matching left portion and/or top portion will also be able to do these fuzzy comparisons. It'll take the computer a bit longer run the numbers per layout as I go through them, perhaps 5-10 seconds or so, since this won't be fancy optimised code at first, but then I'll hopefully be back to where I was above, but with more reliable unique symbol identification, and also more reliable symbol grouping. Right, a load of coding now to try make this new version of the system

A bit more progress - a bit hacked together, but looks promising - so this is to autogroup the symbols as much as possible (so a Cherry with a (2) goes with a Cherry with a (1) on etc). Here's a couple of cherry-picked ones that worked: ...and here's one that didn't, this may need more fuzzy image matching, which is planned, or may just be a bug (it's later and am tired!): So it's trying to do an exact pixel match on just the left half of the image with this technique, so either there's some minor pixel differences or I've got a bug lurking As the yellow bars (and all others) should be grouped onto rows as it should ignore the Andy Capp overlays on the right... Edit: I don't think it is a bug, since here we can see it's grouped most of the stars except just one, so there must be subtle pixel differences. So I think this will require more work, in doing a 'fuzzy' match of these partial image sections, so then if it's 'fairly' close, it'll still be able to match and group them.

Some more early WIP screenshot of the tool, now showing the reel images, and got a first stage grouping, a simple 'exact match'. A couple of examples: Very clear one where no overlays on the symbols, number reels, so on the right, marked in purple box, you can see just the 'Unique Exactly matching' symbols (across all the reels): And then a little more 'messy', here's Andy Capp - where there is an overlay symbol/text, the reel is counted again in the simple first pass of grouping (I have plans to allow further grouping, by detecting overlay symbol data to exclude from comparison): A few more:

Tech update A early WIP screenshot of the Reel Id tool I've been developing... It's just for internal use by me, so the UI will remain somewhat janky I did try using a prebuilt AI to identify the fruit symbols, and it was terrible - so I'm continuing the path of developing a quickly configurable expert system approach, that can use various tweakable hueristics, along with manual overrides for the edge cases - this will be better anyway I think, as there won't be a neural network black box to deal with, far less headaches. The first test machine is to be Adders & Ladders, as is tradition ...it's a very simple one to get super basic symbol id working, i.e: there is only a single type of symbol overlay, and five main symbols, all different in color (red/blue/yellow/purple/green). As these reel images are from scans, the symbols are not digitally identical, so will be good for developing the threshold stuff too, so like in this profile, it'll group main symbols by general color/shape/area... some subtraction... so that it would then be able to end up with a list of symbolic representations, by specific strategies, like: Yellow TripleBar (*) Green SingleBar Purple DoubleBar Red Seven (*) Yellow TripleBar Purple DoubleBar Blue Seven etc... The MAME layout builder can then use these generated symbolic representations to build very basic (but far better than my old mfme2mamev1 simple text) reel symbols, e.g: I think I worked out I have over 200,000 reel symbols to transcribe across the ~3,000 layouts, so doing it manually (like I did in mfme2mamev1 with some tweaks), is not really viable... also, this may feed into the win tables that are shown on layouts, e.g: These currently aren't generated into the MAME internal layouts, but they could be as an extension of this tech...

MAME once again proving itself to be an an invaluable historical record As it was a legit port on behalf of Irem, I was essentially authorised to source any R-Type material I could find: - Sprites/Tiles: MAME pure copies for high res, 75%/50% scale versions for lower res phones by me and Leda (my supportive talented GF at the time) - Actual tile maps: manually rebuilt from captured MAME footage (made more sense than figuring out the internal format, didn't take that long) - pseudo-MIDI music: I did not write these midi covers! I can't remember whether they were conversions of found Nes/Snes/Amiga mods - I definitely ripped the best sources I could find from somewhere and enhanced for Midi. There were no sound effects for technical/budget reasons - HUD gfx - these were provided by Matt Hyden, who was a cool guy. I think at heart Steve was also a cool guy, certainly passionate about constrained platform games, but unfortunately he'd learnt some successful but unethical biz practices! (short changing devs) In the words of Edith Piaf, despite making very little paper; Non, je ne regrette rien

Oh this old thing Made a bunch of compromises due to platform limitations, but I think I captured the essence (if I do say so myself )

I just DM'd this to someone, thought this info would be useful here, along with some additional info: DM text In terms of the last 3 months, the quick catch-up is that I've been working on the rendering/interaction of fruit machines in MAME, along with some very talented developers who are working on base emulation. This is all with Arcade Simulator improvement in mind from my perspective, while also preserving an open source copy of the fruit machine emulation code (as MFME source is essentially lost). Once the MAME emulation stuff is done from my side , the next step is building a second arcade accessible from the menu, and on that arcade, new features will start to come through such as 'instant start up', so even a modern Scorpion 4/5/MPU5 etc would be playable in a second or less , the wallet features will be developed for that, and also a natural 'online multiplayer' is planned, so you would be in the same arcade as others, and see their avatars walking around, and be able to engage in voice/text chats, and also see a near realtime rendering of their fruit machine as they play it... along with many other features planned. Current work: The current plan is to mostly automate the identification of reel symbols and I guess 'adornments', so it's e.g: turning a Cherry with a 3 on on it, into a symbolic textual/db representation. This will form part of the new mfme2mamev2 drive, so that current/future driver coders (and all end users) will have a decent quality click playable version of the machine built right into MAME itself (I may get involved with some of that work too, such as ccTalk/DES implementation). I am hoping with the 'ReelId' system in development, that the MAME work from my side might be completed in 3-4 months, as I'm of course very much looking forward to getting back into AS dev There may be some initial architectural jobs, but the next user-facing AS development is planned to be the addition of the JPM Electra cabinet along with all good quality DX's housed in it...

BTW if you still happen to have any Nokia SDKs and such laying around somewhere then it would be cool if they ended up on archive.org if not already there, don't want that stuff to be lost to time I have a couple of old backups of the Gyrox source and perhaps biz emails on CDRW in the attic... It was a very long time ago, but I suspect I don't have any SDK downloads on there - hopefully they haven't been lost to time... Compared to the other phone manufacturers in the early years, Nokia were a thing of beauty; they used to have a very active dev forum, whereas with say Sharp, they (at the time) used to have a top J2ME handset (in Europe) the GX10, but no documentation... and if you did a System.gc() at the wrong time/place, it would simply reset the entire handset there were a bunch of gotchas like that at the time you could only really learn through testing, or if you were very lucky, an internet forum post. It was a real wild west, depending on who had written the KVM, there was a pretty small crew of KVM writers back in the day, it was crazy. I remember SonyEriccson started off super terrible, it was infamously bad to try support..... then something happened (almost certainly a new freelance KVM coder, as they along with other manufacturers were slowly realizing that J2ME performance was a selling point, like megapixels, and just had a capex cost), and they went from the worst to rivalling/beating Nokia devices for J2ME performance. Motorola had a similar journey; they had crazily bad 'runtime stack management', so the memory fragmentation from the J2ME 'heap' memory would build up fast, so you could build a graphically rich game (but multiload) that'd run ok for one gameplay loop, but then it would die being unable to allocate memory (flat memory model worked, but didn't suit multiloads)... this was on the famous V3 aka RAZR, very sexy slim flip-phone, it was a very nice looking device compared to the clunkers of the day, I think the 'solution' in the end for those Motos was just to have very limited GFX RAM usage via hardly any gfx, so you'd delay the heap recycle limit crash for as long as possible, it was all so insanely mercurial back then lol, almost like the ZX Spectrum days (I was too young to be involved at the time, but have a 'fair' understanding now, though I realised it's a very limited number of people playing Speccy stuff these days, so I switched back to FME for hobby dev). Typing this, I remember there were certain handsets recognised as 'reference' devices in the fledgling industry(obvs it/s worth many billions now, I didn't manage to cash in on the growth unfortunately lol), e.g: Nokia 3510i, Nokia 7210, Sharp GX10, SonyEricsson K800i, (these were very good for the time), Sharp GX20+, Motorola V3, Samsung D600... quite a few more, on a per manufacturer basis - so you'd make your game work on the ref devices, then pass over builds per handset family, and the content aggregators (that us indie devs released through, to get onto the WAP portals), would take those builds and have a compatibility list, of 'like' devices similarly/same screen resolution/KVM/softkey code. I should write this up somewhere, as I've seen hardly any mention of this in the modern day of the net, so it could end up lost - where I work now (Distinctive Games) after some N64 dalliances, went on to do some solid games initially in the monochrome J2ME era (before my time in the industry)... I spent (I think I can now say,. NDAs must've expired) a lot of time devving iterations of FIFA J"ME working with EA (yes that EA, the evil microtransaction guys now lol) - a great learning curve though; there were very specific optimisation strategies developed that only work for certain KVMs (which was another wild west, the majority of gaming handsets planet-wide ran J2ME KVMs written in the relevant assembler (it wasn't all nice AMR 7 back in those days!) by a very small (4-5) handful of people. Man, I'm hungover, but that is a lot of text lol - I've got more tales like this, it was a smallish 'scene' globally... I failed to get rich out of it unfortunately, but definitely happy to have been involved (even earning probably at best min wages via my own game company!), having been too unknowledgeable to be involved with the earlier eras. But JP, I hear you cry, surely you made bank doing the original R-Type port for Irem via Elite (yes that Elite); nope, got pretty much robbed by Steve Wilcox, the original MD of Elite, a lot of people did around then and even back in the Speccy days; Elite's model was to pay devs far less than their dues after the source/binary was delivered, then threaten to sue on some aspect of abstract code delivery law upon request of payment. Sad but true... This is a really long post ...but one more thought is that I have kept a box of old handsets from when I ran Gyrox (prob 30-40 devices).... the chips are probably very complex to extract (compared to say the TMS1000 doorbell) but I will continue to hold onto that box, and be happy to give them up for ripping once hobbyist chip extraction is at that level.

No it's all cool - I suspect in the future some other fruit machine boards/chips might come up need similar doing, thanks for the contribution!

Once they get up to Nokia 3510i, 7210 onwards, I will have to dig out the 'ROMs' of my old first mobile game 'GridRacer 3d'! Some screenshots here (from a slightly later Nokia s60), clearly I did all the graphics by how crummy they are I did that perspective road effect on the title screen picture using Deluxe Paint on an Amiga emulator believe it or not, I think I stole the bike from an Gamecube XG3 screenshot and modified it... It was perhaps the first 3d game though... Found these from an ancient website that still seems to be up: http://www.zgroup-mobile.com/published_games/racing/gridracer3d/gridrace3dr.html

Oh for sure, it's all super cool - it's just such an abstract thing to end up in MAME haha, if you'd have told me MAME would've been emulating doorbells 10 years back, I would have been skeptical to say the least!

I think we can all agree, the emulation of a doorbell is a great step forward in the world of FME!

There is a emulator launcher frontend called FruitBar by @appstrader that has some MFME/fruit machine-specific features

Amazing work with Blackbox! A real milestone And ta very much for these builds - super handy for allowing me to dodge git setup for a bit longer (to be fair my Arcade Sim dev PC is BSODing like one every few days, so I prob need to reinstall anyway), I will try them tonight, hopefully they will completely fix the 'too many live textures' issue (I'm sure they will).

Hey don't put yourself out dude I've got plenty of work to keep me going, now I've got that mame.exe that's been upped to 100, so lots are working that weren't. Lots of config window scraping to set up, and then rescraping the techs I did to pick up those configs, and onto new ones. Set up the Chr lamp table scraping last night, so going to be rescraping MPU4 today/tomorrow to pick those up. Thanks again for looking at this stuff

Glad to hear some might use them for other than debugging/testing! Actually, while I should get git/MAME synced/building, I don't need to be able to compile it for ages yet, so if I could kick that can down the road So if you could compile a new exe please, but with it doubled from the new value, so: static constexpr int MAX_TEXTURE_SCALES = 200; ...that would be super handy, thanks man (As I'm sure 200 will be enough...) This font in MAME needs some editing, I've not looked where it came from at all, but on scrolling through those WIP screenshots above, I noticed that consistently, the lower case i, and the lower case l (L), appear to be half the width they should be, so they are very narrow everywhere: ... where there's i or l, like in Bu lli on, etc... hopefully shouldn't be too bad to fix... Ta again for the build, saves me a job, since I don't need to be set up building MAME over here until near the end of this little(ish) project

Well that does fix most of them, but a few still actually still have the error, I would've though 5x would've been fine! Well this can be looked into further, here's some working ones anyway, there's a couple of 'textless DX' conversions too (that will get text manually populated later).