Development Updates

[slasher]

25 minutes ago, niallquinn said:

I always used to think "Who the fucks Des?"

I used to say the same! LOL!

[serene02]

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

J

[johnparker007]

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  

 

[slasher]

I think it stands for something like "Data Encryption Standard" but unsure if it's the same for fruit machines. Data Encryption Standard (DES) Machine which some say on power on seems a bit of a strange way to put it.

[johnparker007]

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.

[slasher]

Yes definitely something to do with ccTalk.

Not sure if I've got it right with regards what it stands for but this is 100%

[johnparker007]

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

[slasher]

Learn something new every day!

[niallquinn]

Goes back to 1974!  Wow.

[serene02]

Wonder if there are any S4 machines that had the same updated security updates that causes those to load as slow?

J

[johnparker007]

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  

 

[ruthless]

Is this rendering live?

What kind of specs for the client?

[Spidy21982]

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

[johnparker007]

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!  

Edited December 16, 2020 by johnparker007

[slasher]

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. 

[johnparker007]

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!  

[johnparker007]

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

 

Edited December 16, 2020 by johnparker007

[slasher]

Never seen a betcom start up so fast!

[andy-1]

Looks amazing.

[johnparker007]

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 

 

[johnparker007]

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

 

 

 

Edited December 20, 2020 by johnparker007

[slasher]

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

[serene02]

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

J

[johnparker007]

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

[johnparker007]

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!