[Development Updates]

31 minutes ago, slasher said:

Microsoft will make things bloody awkward!

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

[Development Updates]

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.
 

 

[Development Updates]

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

[Development Updates]

59 minutes ago, A:E said:

Wow, so impressive John.  I love these tech updates, thanks for sharing

J

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!  

[Development Updates]

1 hour ago, slasher said:

All very interesting stuff mate. Great idea to use the cheat engine as well.

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

[Development Updates]

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

 

 

 

[Development Updates]

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 

 

[Development Updates]

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

 

[Development Updates]

7 minutes ago, slasher said:

Looking great. My "gaming" pc with a ryzen 7 and GeForce 2060, 16gb ram is finally complete, so if you want to do any testing on that, I won't be putting anything much on the Windows partition. I've also a couple of Lenovo x240 laptops of a lot lower spec if you want to try those too. 

Of course I realise it's way before the testing phase but the offer still stands even 6 months down the line. 

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!  

[Development Updates]

6 hours ago, ruthless said:

Is this rendering live?

What kind of specs for the client?

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.

1 hour ago, Spidy21982 said:

This is so amazing. I'm worthless. Greetings from germany.

Thanks   Hello from Sheffield, England!  

[Development Updates]

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  

 

[Development Updates]

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

[Development Updates]

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.

[Development Updates]

2 hours ago, slasher said:

I used to say the same! LOL!

Sooo... what does DES stand for then?  
 

41 minutes ago, A:E said:

Excellent work on all this.  I love how you won’t be beaten by anything..  legend

J

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  

 

[Development Updates]

1 hour ago, slasher said:

Makes me wonder if cheat engine could be used to speed up laggy reels on S5 machines on lower spec computers.

As usual, great work - I like it how you go "fuck you, this ain't working, let's do a workaround"

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!

[Development Updates]

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!

 

[Development Updates]

25 minutes ago, A:E said:

Wow...   fast boot enabled

Yeah, Scorp5 boot times are hideously slow.  I often wondered if this was purposely done to stop people plugging machines .   

J

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  

[Development Updates]

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

 

 

 

[Development Updates]

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  

 

[Development Updates]

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  

 

[Development Updates]

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.

 

[Development Updates]

59 minutes ago, slasher said:

Of course let me know if there's anything I can do to help even if it's just web stuff again 

Thank you, that is very much appreciated mate  

[Development Updates]

1 hour ago, slasher said:

Looking great as usual mate.

Have you checked it with a flexi reel (something like DOND perfect deal perhaps?) And a disk real (barcrest mega zone) or are they to come later as they're not really that common?

Not trying to piss on your cornflakes or anything but thought to be worth a mention

Flexi reels sound like something new, don't remember those from mfme2mame... and disk reels - I haven't implemented those yet... so both those reel types won't currently work with this basic implementation.

In a nutshell, it's like you say; they're not that common, so they can wait until later  

The plan is to implement all reel types (Horizontals, disk reels, band reels, and this new flexi reel) in a later pass of the reels.  But for now, I just wanted to get enough basic reel functionality going to get a bunch of 'standard' machines playable (hence the placeholder 'treat horizontal reels as verticals' workaround), so I can move onto the next step towards the online arcade  

Next steps are currently planned to be: getting a UI system in for the menus, then basic MFME lifecycle stuff (quite a big job), so I can walk around and engage/disengage with different machines (in full screen with MFME always hidden).  Once that's working 'well enough', I can start looking at the server stuff (to keep database of machine RAMs for upload/download, and player total In/Out per machine session, along with some other bits and bobs).

Thanks for the heads-up on flexi reels, I look forward to figuring them out when the time comes  

[Development Updates]

Turns out I had more stuff to do with the reels than I thought, but now they are finally at the 'done enough' stage   There were issues with horizontal reels, and some mis-scaling of some vertical single symbol reels.  Horizontal reels I now have working, though I'm displaying them as vertical reels (so they move up/down for now, but the number is still correct so they are perfectly playable).

Here's some gameplay on Wok 'n' Roll, which I've never played before, as is probably clear from the video!  But it shows the horizontal number reel working correctly (as a vertical reel).

There's also 4 other machines with their reels correctly converted from the same latest code (the off machine's reels aren't aligned to winlines etc since they aren't hooked up to anything).

 

[Development Updates]

More reel improvements - number reel working correctly, plus redone some fudgy ratios with more accurate maths, so closer to the approx reel diameters to match the reel windows now wrt symbols on reel and symbols visible (calced via s=rθ for those interested!  ).  There's still a bit more to do on this pass of the reels (better scraping of visible reel window, to deal with rounded / arched / irregular reel windows)... then I'll park that feature for the mo, as it's 'good enough for now'. 

Then, I think I'll be moving onto MFME lifecycle management; so that'll be about walking up to the 3 machines in attract mode, pressing Enter to 'interact' with whichever is the main machine currently in view - at which point, it'll load up MFME, and do some hacks to keep MFME hidden behind, but accepting keypresses.  Also, perhaps move the player into a fixed playing position.  Once say Escape is pressed, then it'll 'disengage' from the machine, so basically kill the MFME process, and return the player to normal walking around controls.  So it'll be possible to play two different machines in the same video.  Unfortunately no snapshot load/save in MFME as it currently stands, so we will need to wait for the machines to do their full 1 minute+ boot up process, does seem to be quite long on these newer machines (I think the older machines are quicker).