johnparker007

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

Thanks for the offer, I will definitely be looking for help testing once it's at that stage - though the more I work on this, the more I realise I've got left to do... so quite a while away from doing any testing yet. That gaming PC spec of yours will be more than powerful enough!

It is live. This is an i5 overclocked to 4.7GHz, with a 6gb 1060 graphics card. It's a very early experimental prototype, so it's hard to say what the requirements will be for a release version at this stage. I'm hoping to ultimately implement a couple of things that will decrease system requirements (whilst still maintaining visual fidelity): - some form of streaming textures (like used in GTA5 etc), so that the very highest resolution will only be fetched for machines you are close to (otherwise we will run into a RAM wall when trying to place say 300 machines in a single arcade 'room'). It allows to have for example 12gb of fruit machine textures in a room, on a graphics card with say 1-2gb of RAM. Then they are buffered between system RAM and streamed from the hard disk. I believe with a custom solution I'd be able to completely avoid pop-in artifacts. - depending on what ends up happening with MFME source, a companion DLL hack that will extend MFME functionality and provide direct access to the internal memory state of lamps, displays, reels. Currently I'm pulling across as a screen capture and scraping pixels which isn't the most efficient way, and also adds a single frame delay. Thanks Hello from Sheffield, England!

Battled through a bit more and got a fudgy version of the turbo startup working on a (new, Scorpion 4) machine in the arcade finally

Just double checked - it's the encrypted ccTalk comms alright: https://innovative-technology.com/support/faq-2/item/107-cctalk-des What is ccTalk DES? ccTalk® DES In response to manufacturer and operator demands for a more secure method of communicating with peripherals (bank note validators, hoppers, coin mechs etc); DES has been implemented in ccTalk® communication protocol. Overview DES stands for Data Encryption Standard and was developed by IBM in 1974. It uses a shared key that is known by both the host (e.g. gaming cabinet) and the slave (e.g. bank note validator). In the ccTalk® implementation of DES, a 64-bit key has been used. And of interest: "Compared to the currently existing ccTalk® encryption standards, significant processing power is required to encrypt and decrypt messages. " So that's perhaps an explanation of some of the startup slowdown going from Scorp 4 to Scorp 5 ^^

Ah right, thanks - so it's just all that ccTalk kinda stuff, I remember the hoppers/coins being on it for that first DOND many moons ago. I guess as machines got newer they just put everything else on that data bus, so it got slower to init.

Sooo... what does DES stand for then? Thanks mate Taking a break now, as I've spent most of Sunday and Monday on this bloody turbo start stuff - I have to do it though, 40-50 seconds is so much longer than 2-3 seconds when you're just sat there waiting for a Scorpion 4 to load. I've now got it to the point where I have my own injector working in c++ (still injecting that same .dll that turbos until there's no turbo.txt file found). A few more nights on it and I should hopefully have it working 'properly' (i.e. automatically start/stop the turbo from the Arcade software at the correct time) with some machines. Fingers crossed for no more problems

It's worth a shot, though if the computer's lagging, it's probably already maxed out on the CPU... so you may not see any difference. Thanks man I think I'm about 10 workarounds deep at this point lol - it's one of those problems that's tantalisingly close to being solvable in a clean-ish way, but just keeps jumping back out of my grasp!

Thought I'd give a little tech update on the potential new feature of the 'turbo startup' for those interested in that sort of thing I've been working flat out on this feature, turns out it's a lot harder to do properly than I thought (and is driving me slightly mad!). But now I've seen how fast those scorpion 4 era machines can start (0-3s instead of 40-50s), I really want to get it working. It's a whole load of very unfamiliar territory, coding-wise. Originally to test, I used the built-in speedhack tool in CheatEngine. Then I progressed onto making my own 'injectable DLL', which worked but would hang the machine when setting back to non-turbo speed. That was down to time going backwards for a frame, which the emulator didn't like! So I've got a workaround in that fixes that now. I'm struggling with communicating with the injected DLL (from the Arcade software) once it's inside MFME process, so for now I've make another workaround of just having an empty text file called turbo.txt (which is created before loading up a machine in its layout folder). The injected DLL starts, looks to see if the file is there, and if it is, it 'turbos' MFME, and checks 10 times a second if the file is still there. Once the file is not there, it then drops back to normal speed. It's a bit of a kludge, but works perfectly well (as can be seen in the video below). I'm currently using an existing command line launcher to inject the DLL (you can see in the video below I switch to a DOS prompt to run a command to call it). I've tried a lot, and I cannot figure out a step in the process of injecting via native c# (which Unity uses). I can't use the command line injector as is, as it's 'unsigned code' so Windows pops up a full screen warning each time I call it from Unity. So the next plan is to make another DLL, and port across working C code to perform the Injection (like how it is possible from the command line), then make that DLL usable from Unity as a 'managed DLL', which is a little more standard that some of the crazy hacking stuff I've been having to do/learn to try pull this off. If I can get it working so the Arcade calls the managed DLL, which then Injects my custom 'turbo' DLL into MFME - then, per machine, I just have to configure some criteria to delete the turbo.txt file the moment the machine has finished starting up (much like the 'auto camera director' feature I tested before... so I could watch for a certain lamp coming on, or a "0.00" string on the alpha-numeric display etc). At that point, we will have machines starting as fast as they possibly can, and going to normal speed the moment they've finished initialised It has been driving me absolutely crackers trying to figure out a way to make this work, but I'm cautiously optimistic that this latest plan could be it!

It is weird, you'd think with newer hardware (Scorpion 4 -> Scorpion 5), that the boot times would actually be quicker, with faster CPUs etc. They both appear to do very similar jobs, controlling lamps/reels/alpha displays etc... maybe you're onto something with that theory ...unless there's more sophisticated security features that take a while, or more self tests. It's annoying for sure, but at least it'll be less annoying if I can get this hack properly implemented

I was noticing it takes a very long time to the machines to initialise, and I'm impatient ...plus it's not great for the online arcade experience. Anyway, so I've been doing some R&D (well the research side, I haven't actually made the proper system yet) - to speed up those initialise times with some good old fashioned hacking Excluding the time to load the layout (which I should also be able to speed up once my data layouts are generated from scratch with no image resources), these are the speed up results on my PC (which runs at a fairly fast speed of 4.7ghz): So on the older techs (Scorpion 4 and earlier), the machines will get to their playable state near-instantly, on the latest techs (Scorpion 5 etc) the times are around half to third (on a ~4.7ghz CPU) Here's a quick video of Monopoly Road to Riches (Scorpion 4), first showing normal startup (approx 42s), then turbo startup (approx 3s):

Bit of a long gameplay video here, been working on various things... - attract modes look scrambled on all machines (except Happy Hour as the recording was write protected), this is due to new converter feature, so it can now record these automatically as part of the conversion process (saving me time/hassle). Will fix the new scrambled lamps bug soon. - 'MFME lifecycle' system working well so far, on each of these I'm pressing enter to launch, escape to return (then the machine returns to displaying attract mode recording) - new machines being played: Fiddle 'A' Fortune, and Eastern Promise. - all machines playable (except Happy Hour, once I turned volume up, I realised it wasn't starting due to a RAM error) - plus other misc stuff. There's a big pause somewhere in the video, that's because someone from work rang and needed a code for the underground car park, so I had to deal with that! Next, planning to work on getting those automated attract mode recordings unscrambled, along with more on MFME lifecycle (full screen windows client, keeping MFME always hidden behind but still operable). I'll prob do another video when those things are implemented, as it'll all look a bit more ship-shape

Beginnings of HUD rendering, plus a little progress on MFME lifecycle work. Here I'm pressing enter when viewing Wok 'n' Roll / Fiddle 'a' Fortune and it's loading the correct data layout under an MFME instance. Then when I press Escape, it kills the 'engaged' machine instance, and goes back to viewing mode to continue exploring the arcade

Bit of a rough WIP update video, emulator lifecycle management is going to take more time to develop than I initially thought... but, I have started with getting a decent UI system in, which you see some of the elements of here, so thought it was worth a quick vid It's a weird vid, the mouse pointer is invisible and the camera moves when suing the UI, this won't be the case with more emulator lifecycle stuff done - but I do really like the look of the new UI ...I initially started making one of my own, and it looked 'adequate', so I spent £20 and bought this one that I can adapt. I like the style of it, clean and modern.