Development Updates

[johnparker007]

4 minutes ago, Altharic said:

Its a milestone albeit a comical one at the moment, the purchase and dumping of this means that Black Box once its been reviewed is completely preserved in MAME.

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!  

[SomeRandomGuy]

6 hours ago, johnparker007 said:

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!  

That's part of what MAME is all about nowadays, anything with a CPU in it is fair game Off the top of my head there's dumps for a digital scale, DVD players, some old Nokias (3310 included), bus ticket validators, a heart monitor, a bomb disposal robot, the list goes on and on...

[Altharic]

I was happy to donate to that doorbell and if needs must I would do again was fun seeing the idea come to fruition @johnparker007 did you go out of pocket doing it? 

[johnparker007]

35 minutes ago, SomeRandomGuy said:

That's part of what MAME is all about nowadays, anything with a CPU in it is fair game Off the top of my head there's dumps for a digital scale, DVD players, some old Nokias (3310 included), bus ticket validators, a heart monitor, a bomb disposal robot, the list goes on and on...

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

Edited October 28, 2022 by johnparker007

[johnparker007]

2 minutes ago, Altharic said:

I was happy to donate to that doorbell and if needs must I would do again was fun seeing the idea come to fruition @johnparker007 did you go out of pocket doing it? 

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!  

[Altharic]

I think this will be one of them 

Quote

TMS7041 - Reel MCU (4kb Internal ROM, Not Dumped)

JPM MPS

Edited October 28, 2022 by Altharic

[Altharic]

I have been on holiday hence my sporadic posts noticed more FME based changes.

Refactored MPU4 machine configuration

barcrest/mpu4.cpp, machine/ticket.cpp: Added proper coin hopper communications. [James Wallace]

As a result a lot more mpu4 boot and run without (as I see) errors such as jackpot key missing etc 

[SomeRandomGuy]

3 hours ago, johnparker007 said:

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...

Wow, didn't expect that, that's cool! Maybe one day GridRacer 3D will be added to the J2ME software list, once that becomes a thing . 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 .

3 hours ago, johnparker007 said:

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!  

3 hours ago, Altharic said:

I think this will be one of them 

JPM MPS

Yep there's quite a few techs using microcontrollers that would be really nice to have dumped. Though most of the time whatever the MCU does can probably be simulated without a dump, but in some cases it might not be 100% accurate. MPU5 for example has a load of them: there's the main processor, then there's the reel controller, mux board controller, program card PIC and finally the audio DSP . Fortunately there's also techs which don't have extra MCUs on them, or for sp.ACE the reel controllers are already dumped (one from ACE and one from PCP, seems there's multiple versions of the ACE one, though it shouldn't be a big deal for a tech that old).

[Altharic]

These are pretty cheap judging by ebay prices and mpu5 sadly if I bought these I would have no idea what to do to dump them I mean the reel board is under a tenner mux is £12.....

[johnparker007]

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.

Edited October 29, 2022 by johnparker007

[johnparker007]

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...

Edited October 29, 2022 by johnparker007

[serene02]

I remember being blown away by your mobile version of R-Type!!  Looks amazing!!

J

[johnparker007]

5 minutes ago, serene02 said:

I remember being blown away by your mobile version of R-Type!!  Looks amazing!!

J

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  )

Edited October 29, 2022 by johnparker007

[serene02]

I remember you telling me you got no source artwork or any help from Irem.   Did a superb job mate, really looked stunning

J

[johnparker007]

21 minutes ago, serene02 said:

I remember you telling me you got no source artwork or any help from Irem.   Did a superb job mate, really looked stunning

J

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  

Edited October 29, 2022 by johnparker007

[SomeRandomGuy]

22 hours ago, Altharic said:

These are pretty cheap judging by ebay prices and mpu5 sadly if I bought these I would have no idea what to do to dump them I mean the reel board is under a tenner mux is £12.....

They used Z8 and PIC microcontrollers, PICs can be decapped, don't know much about Z8's. MPU5 is still a ways off though, need to get MPU4 done first

12 hours ago, johnparker007 said:

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.

That was a fun read, I've seen similar stories about the J2ME development experience . Shame about the shafting, even their Wikipedia article mentions sketchy dealings going on. Seems to me like overall handhelds & mobile weren't seen as much by the industry back then, especially compared to the things it's up to nowadays. As to dumping phones, I think by the 2000s they got complex enough that you can extract most things through software, plus there's been quite a bit archived already for some of the manufacturers. Would be interesting to see somebody make an emulator for an actual phone as opposed to just the OS.

[GREDDIE]

On 28/10/2022 at 16:02, johnparker007 said:

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

Absolutely fascinating John, an amazing part of gaming history to be part of.  Can you get a mention on Wiki ?  You should try to get a reference for R-TYPE port if you haven't' already.  It's great to hear the back stories and about how you got the bike graphic for Gridracer and your girlfriend helping you on projects  I bet you have a lot of fond memories... be sure to post more snippets like this, I love it !   

[johnparker007]

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...

Edited November 5, 2022 by johnparker007

[johnparker007]

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:

Edited November 6, 2022 by johnparker007

[serene02]

Outstanding work mate

J

[Zippy]

47 minutes ago, johnparker007 said:

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:

Got Mr S1300i working its bollocks off, there is nothing like having two to three hundred reel bands offloaded on you to scan. What a fantastic machine and well worth the price I paid (brand new)

[johnparker007]

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.
 

Edited November 7, 2022 by johnparker007

[johnparker007]

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  

Edited November 8, 2022 by johnparker007

[johnparker007]

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  

Edited November 10, 2022 by johnparker007

[woodsy]

just picking my jaw up from the floor