johnparker007

@slasher In doing some research into dot alphas (looking at Dad's Oliver's Twist layout compared to youtube video), I've seen one of those Vega color-cycling note acceptors in action: Am I right in thinking that basically this gets fed with a 'lamp on' signal, just like the standard ones, and instead of showing solid lamp (thru red plastic bezel) - it color cycles? So the color-cycling isn't ROM controlled from the game ROM, the game ROM just tells the acceptor to 'light up'? If so, then this can be easily supported in the 3d arcade - if there's the signal for it to be lit, instead of a steady color, I'll just run the pulsing color-cycle I have another another query please, as you know your fruit machine hardware ...so on this layout for instance, there is zero space between the 'dots' of the 'MFME Dot Alpha' dot matrix display: ... and on this machine (Pieces of Eight), there are gaps between the individual dots: Now, I think this is perhaps just due to MFME not scaling displays, so layout artists are doing this as a workaround to best fit the display to their background image? So is that the case - are all these displays actually identical? Or do some have large gaps between the individual dots, and others have absolutely no gap between the individual dots? Thanks for any insight

Had a quick check, and balancing the pseudo-lighting of the machine glasses should be fine This is a thing I noticed before, each machine has different lighting levels of the unlit glass (and indeed the lamps). One of the new machines (Pots of Luck) was particularly bright, so I've put it next to the darkest machine to show the issue (and how I will ultimately auto-fix this inconsistency). So in code, I will get all the unlit glasses (and potentially the lamps) to a baseline unlit and lit brightness. Then when they are matched, there will also be an overall control... so each user can have their arcade darkly lit (how they look best in my opinion!), or if they prefer they could have it very brightly lit - it'll be like a 'dimmer switch'

Since I've spent most of the weekend working on FME dev - I've got my 'fast re-conversion' system done. So now when I need to roll out a change/improvement to the existing machines, it doesn't need to recreate the entire machine from scratch in order to add a Dot Matrix display or whatever the change is. It finds the existing work from the previous conversion, and reuses it (unless I override the settings to force a rebuild of a certain area, such as reels for example). Needed to get it done, so I can start adding dot matrix displays, fixing reel bugs (the number reel is wrong in the below video for some reason, haven't investigated yet). And then I can re-generate all the machines in around 1/10th the time it took before the system As a test, I've converted another new machine (and then re-converted it a couple of times), everything seems to be working (apart from the wrong number reel, but that's a separate issue I'm sure). New machine is 'Pots of Luck'.

Good to know, ta Vecs Without the MFME source it'll probably be a massive pain for me to implement - so it's going on the very low priority pile for now! I will support the 'standard' ones that don't color cycle when I get to that bit

Ha colour cycling eh - I didn't know they did that Thanks for the info - I was only aware of the old NV10/11 ones that just do a lamp on/off (and then I guess the red plastic is what makes it look red). Had a quick google, I see this youtube video shows different colours on a Vega: and different brightness levels: Bright Dimmer: It'll all be fine from the 3d side. Does MFME emulate these color cycling note acceptors? If so, is there a layout that shows one in action? It's all pretty low priority for the moment, but I am planning to get everything looking as good/accurate as possible when the time is right

Both those features are yet to be implemented, but definitely on the roadmap The Seven Segment displays are probably going to be done after I get the Dot Alpha displays in. The 3d coin slot/not acceptor lamps will be a little later, maybe done around the time I get to doing the 3d button system (all buttons are just flat at the mo).

Ah good to know thanks it'll be cleaner to just have them all set to the same volume, from MFME. The dot alphas will hopefully be along within a week or two, once I've done some more stuff to speed up the re-conversion process.

Added a couple of new machines (Snakes & Ladders and Trail Blazer) to test out the new (much faster) MFME text scraper - everything seems to have come out in the right place so working well (Trail Blazer - the sound is very quiet, I actually thought it didn't have sound when I was recording. I will perhaps be able to code something to fix this issue of different volume levels between different machines...)

Not getting as much time to focus on this project at present, but still tinkering along with small bits So the new MFME text scraper is just about working now (full ASCII character set)... testing it on this reel component, the approx 12 numerical text fields I scrape so far - old system took around 4 seconds, new system takes like 1/60th of a second. Very satisfying speed increase (it all adds up when there's usually at least 200 components per layout) Will be continuing to finish this up and refactor some of the 'data entry' stuff to share some coordinates... then onto image caching, for more speed ups to the conversion process (which is currently torturously slow).

Had a nice relaxing Xmas/New Year thanks, hope you had a good one too!

Just a tech update, started tinkering again after a nice long programming break over the holidays So before I roll out the dot alphas from the recent videos properly, I want to speed up the generation/regeneration of the 3d machines from the layouts (so I can move into getting ~50 unique machines in the arcade from the current 5 test machines). Main plan is to implement screen scraping of the delphi font, then also have an option to not save out/process any images that already exist (from previous conversion run). Those two features should take processing of a pre-processed machine down to 4-5 mins from like 35-45 mins. I did some provisional rough test scraper code for the numbers, handcopying, much like making the old ZX Spectrum character graphics from my childhood That seemed to work fine, so I've now grabbed all the characters and worked out their dividers: Fortunately Delphi uses ancient font rendering techniques, so there's no font smoothing and no dynamic kerning (so it's easier to scrape). So once I can program this, it'll allow for grabbing any text from the MFME UI very quickly (compared to the current approach of sending various keypresses with delays to grab text to the copy buffer, one field at a time).

Just a fun update on that display, as I've had a festive amount of seasonal grog I realised it was all set up to do gameplay with zero changes required, so here's that new WIP alpha display in some gameplay action:

Looking forward to seeing them in action once I've done the rest of the work on implementing the test demo from the vid! Sorry man, I know it's an amateur ale, but I can only deal with weak stuff these days, and John Smith's is 3.6% I do treat myself to (local) Bradfield Brewery ales once in a while... some of those real ales get up to like 6% and I start going loopy!

Yeah the Betcom alpha coding isn't too fancy, just one fade after 'PRESENTS' - I noticed Monopoly did a few more effects (vertical scroll on if I remember correctly), and I think Flamin' 400 used some custom graphics, rather than just standard character set. Since I'm back to window capturing the data layouts now I've got it working much faster, we get all those fancy effects 'for free' as the excellent MFME has done all the work already Thanks man, and the session cans for today are John Smith's Extra Smooth

As is the way of Xmas day, it's 11:40am and I'm cracking open my first can Cheers!

Still a bunch of things to do (this has all been somewhat manually set up, and doesn't take the colors/settings from MFME yet)... but it's showing signs of life in this first test Merry Xmas everyone!

Begun work on the alphanumeric dot display

lol it's all changed now anyway! Since my last post, I did some more work on this at 6am before I started my dayjob (because I'm insane and obsessive about hobby projects! ). I had a new idea to try - which worked, so I've found a faaaar more efficient way to do my screen capture, so the performance is almost as good as all the direct memory stuff I've been looking into. So now, I don't have to do all that extra work with direct memory capture and can carry on from where I was, which is great Next feature will probably be getting the alphanumeric dot displays going (including the fade effects)...

Tech update - MFME memory reading research continues (Apologies in advance, this stuff is getting more technical than the usual updates while I'm working out all the hacking stuff) I've since found the raw pixel information for the Dot Matrix Alpha displays, so that should allow for pixel perfect rendering of the alpha displays (including flash, scroll, custom UDG characters)... though not alpha fades, though I'm sure I'll be able to track that byte down. Also experimenting with lamp reading - this time in such a way that I can find the lamps each time. Every time you boot MFME (or any Windows process on a modern version of Windows), the memory layout is shuffled around a bit, due to a security feature called ASLR. It's there to stop casual hackers having an easy way to be able to get access to a specific part of memory each time a program runs. There is a way to get around this however So I've been researching static pointers, and pointer chains, and have managed (just in CheatEngine for the moment), to get a 'dynamic' link to the address of the byte that shows the DirectX alpha value of the Collect/Cancel lamp of Eastern Fortune (I can use this information for rendering lamps). It works if I keep relaunching MFME and still gets the value, even though it's moving around each time I relaunch Next step is using that pointer chain in code, to get that one test button being driven directly by the MFME memory instead of the slow window capture technique I currently use. A load more to do after that (to descramble the lamps to match, I believe they're currently in the order they were originally added to the layout), but I believe all this new memory reading work will make getting the realtime data an order of magnitude faster than the current system, so highly worth it since I'm past proof-of-concept stage now, and trying to get a solid foundation in.

Another tech update I've got the new keyboard stuff basically working, so now the Arcade window has focus, and fakes the keys that are pressed/released through to the MFME window that is unfocused behind (before I was doing bad things to make that work). Also - I've done a little more on this direct memory reading, which I'm hoping I can eventually get working enough (and automated in terms of finding the addresses). The advantage is a very large performance boost, compared to the current system which screen captures the MFME window at 60FPS, then reads pixels from the texture of the captured data layout to determine lamps and reel positions etc. In this vid you can see a test where I'm rendering the contents of the alphanumeric display. A lot to do yet, for instance once I play some credits, it uses a different memory page (I think) so then the display is blank. Plus, when there are stutters, I think that's probably where codes are being send to control stuff like fading the display up/down, flashing etc. EDIT: Since posting this, I've found that I was reading from the emulated program RAM for the alpha-numeric display contents. Having checked some other machines, this doesn't look to be usable, as for instance Monopoly Millionaire's Row is programmed in a different way, so doesn't have the raw text stored in the same way. Still good to have memory reading working though I will see if I can find the MFME display component byte/pixel data instead, as that method would work across all machines, and get custom character support for free. I've always got the dreaded slow screen capture technique as a fall back if I can't find a way...

Thanks mate I'll keep sharing the tech updates - they're not as glamorous as the occasional 'eye candy' videos of the arcade in action, but these little tech milestones are probably more exciting to me!

Cheat engine's a very handy little tool for trying various things out If I can figure out how to get fast memory read access into MFME from the Arcade software, I'll be writing my own 'cheat engine' type thing, so when I'm creating the 3d machines from the 2d layouts, it'll go through and automatically get the addresses of everything (or I'll work out some other way of calculating them).

These are just some tech updates for those interested in that side of things So I've been battling with trying to improve the input control of MFME from the 3D Arcade. My most recent improvements used a very grotty process of actually selecting the MFME window so it's active and in front while playing the machine, and then forcing the 3d arcade window to always be drawn on top. It's a hideous solution, for instance if the user needs to Alt-Tab away to check their email, that wouldn't work (unless I did more patches on top... it's all just very messy! I investigated 4 different ways of trying to control MFME with it truly unfocused in the background, and all 4 failed. I was starting to lose hope, as I'd spent at least 20 hours by this point, with not a glimmer of hope... then... success! Here we have MFME, in the background and unfocussed, being 'played' by my simple test program (fakes pressing/releasing space bar into the MFME process every 4 seconds): Also been working on some other stuff, that could ultimately lead to not requiring me to do 'window capture' of the data layout, which would greatly improve performance on lower end PCs... though it's in the early stages, and I may not be able to make it all work. Here's some videos of me reading dot alpha display content, lamp brightness, and reel position directly from the RAM (no expensive screen capture):

Got a slightly kludgy but working version of the full screen system (with MFME hidden behind). It's not ideal in terms of robustness, but I may not spend any more time on it for the moment, as if I could extend my work on the dll injection hack that allows me to do the 'turbo startups', I may be able to do it in a different (better) way. This is always there as a functional fallback I moved that status HUD up to the top left as well, for an unobstructed view of the machine you're playing. Monopoly Millionaire's Row didn't start up for some reason in this vid, but it's no big deal, could be any number of reasons, and I'm too tired to investigate

Just another (pretty much final for now!) update on the 'turbo startup' feature. After quite a stressful few days working out how best to hack MFME to do this in a vaguely clean way, I think we're there Have cleaned up a bunch of code, and also implemented the basic version of the 'auto-detect' feature. So for each machine, it knows a lamp to watch, when that lamp goes on, it knows the machine has booted to a playable state and disables the turbo. Have set up for the five working machines, quick vid here of each one starting up. The real impressive ones are the older Scorpion 4 era and earlier machines (they go from ~45 seconds to ~3 seconds or even less)- the Scorpion 5 era machines still take a while to startup even with the turbo (about a third to a half of their normal time).