johnparker007

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.

Thank you, that is very much appreciated mate

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

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

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

Not thought too far on that, though I should hopefully be able to come up with something to stop it being too easy to cheat If someone is really determined they could still cheat in certain ways though even if I add counter measures, hackers gonna hack (I'll not detail how one would accomplish that here though, we'll rely on a little 'security by obscurity' ) You can't at present, but I will be adding that in at some point further down the line, I did similar in mfme2mame (clickable buttons) so it's definitely doable

Still a lot to do with reels, but definitely getting there with the latest test These reels are being driven from the new reel pixels on the generated data layout (so each reel has a pixel, whose brightness determines the position). There's plenty of bugs and unfinished bits, like the number reel on the feature board is showing the wrong numbers... and still not finished up the autoscaling yet so reel scales are slightly wrong... but it should all be sortable

Quick tech update Took a break from the batch conversion stuff, to do some work on the reel conversion. There are some fudged ratios for now (and so the scales are a bit off) until I can work out the maths (or just generate a lookup table to avoid that hassle )... but the reel placement and scale is still much improved now... and I think I should be able to sort out the remaining issues with another night or two on it. After that's done, I suspect I'll move onto adding, then reading, reels from the data layout (generated data layout only contains lamps at present). Then that should allow me to play one of these 3d machines and have the reels spin

Sorry mate, they've had to go on! Just remembered I could pretty quickly knock up another 3 machine demo (as I had the converter config files set up for Eastern Promise and Fiddle A Fortune from testing something the other day). All the data layouts here were auto-generated (but I did then have to manually record their attract mode loops, so that's the next thing to automate).

I didn't make the manual data layouts in the end, and just pressed on with coding the converter to generate these automatically. Turned out to be more painful than I thought, but that's often the case! There's plenty more to do (reels, vfds, alphanumerics etc) as this just places a compact scrapable lamp matrix for now, but it's a good start Anyway, here's the first machine that has it's data layout generated by the converter. I still had to record the attract mode anim manually, so that's the next big task (generating attract mode recordings as part of the automated conversion process).

Just another tech update After spending the whole day reorganising stuff and writing new bits, I've finally got the office PC synced up and acting as a 'build machine'. So I'm on my bedroom PC typing this, meanwhile the office PC is chugging away rebuilding those 6 machines from last night's video. This is really handy, so I can make converter changes then rebuild the machine collection overnight (or something like a machine every 30 mins at present). It also means I can have machines building in the evenings while I'm working on new stuff for the Converter in the bedroom (I can't do anything on a PC when it's building the machines). I'll probably make the last 3 manual data layouts (lamps only) I'll be doing tomorrow for the 3 new machines... as then I need to figure out how to best generate the data layouts automatically per machine, to save my time as the collection grows (Data layouts are alternative layouts that contain just the bare minimum to relay to the 3d renderer what's going on with the lamps, reels, vfds etc)... a big old job again, but everything that can be automated, must be automated to keep my time free to work on development. Tons of work at every turn, but nice to have that separate build machine set up now I also learnt today that Perforce absolutely hates '£' characters in filenames and breaks... so that was a couple of hours writing scripts to auto-fix all that including inside .gam files etc (plus removing spaces from filenames), they're absolutely everywhere in these fruit machine layout downloads!

Been doing more work on batch automation (of the conversion of the layouts) There's 6 machines setup for conversion now, the new ones have their lamps off at present, as after I've sorted out the reels, the plan is to look at automating the 'data layouts' that are minimal layouts that just provide data to the renderer.

I've seen that project, it's pretty cool! Regards set up, I'll probably get it packaged into an opensource Windows installer - so it should just be download > run > play