johnparker007

WIP tech update - made a good bit of progress on the segment alpha 'fast' renderer - like the recent renderers, this runs on the GPU (leaving the CPU free and not bogged down with any rendering). Partway through the work so there are currently issues: display reversed (reads from right to left), no decimal points, space characters are coming out as ! characters... Vid

Zzzz's caught - much better! If you wanted to know if they'd be legible in a recording made for a youtube review, then they'd be fine I'm sure

I'm tired - not sure what you mean bud..? If you mean how will they look when being played, if you capture the gameplay footage, should look like earlier videos of gameplay I've recorded... probably not parsing this sentence very well cos I'm knackered! lol sorry mate It's probably a while yet as doing all the other pre-alpha tasks on my checklist before I can work on various converter features/improvements, then there will be machines with the bearded one I'm sure

It's all a bit hacked together but it's alive (in attract mode) - working fast renderer for the dot alphas It looks 'grainy' and a bit distorted, which I fully expected - I may be able to improve a little, but I'll not spend much time on it, as I need to write a third attempt using yet another technique, but that can wait til later as these are usable for now. Here's a video wandering around looking at them from different angles/distances. Really good to finally see a row of machines doing all the elements of their attracts at once (lamps / 7 segments / dot alphas) with no major performance hit (also I need to implement 'master brightness' recording/playback/control, I got away with it here as this machine doesn't appear to do a lot of dot alpha fade effects)

I've been searching for a Artura for the ZX Spectrum for a couple of years... well on and off, gave up after the first year of not finding it, just had a look and it's on eBay for £33.. but I have no eBay account - pm-ing you @serene02 in search of a quick favour

I have this rare Saturn dev disc You can do things with it Probably worth a few quid... Edit: Looked on ebay, it's as rare as hen's teeth - they've got it listed at £700 - jeez, may have to look at flogging this - I'd be happy with half that!

I've put the dot alpha 'fast' renderer I was working on to one side, as it has a couple of issues. I've done a new approach (again a very fast purely GPU-based renderer) - it has minor issues, but coming together Just filled each display with random on/off dots for now as a test - next job will be getting the attract mode recorder recording the displays and playing them back through the new renderer. (And then some fettling to get it looking good enough for the pre-alpha)

Thanks mate Your new gaming laptop should be fine for running this - I'm doing a bunch of optimisations, so it shouldn't require a monster PC to run when we get to pre-alpha release.

Thanks bud and thanks for your help already on getting this server sorted out!

Tech update - have started work on making the new fast renderer for the dot matrix alpha displays I was going to do the segment alphas next, but I pretty much know how I'm going to do those, whereas this required figuring out some new stuff, so though best to tackle the unknown first. This first stage has gone ok, so again this is rendering the off dots/on dots to show the letter 'J' entirely on the graphics card, leaving the CPU free to do other things. Here's a vid showing the sliders/general look: Next will be getting it working in my 'universe' scene and drawing many thousands of them at 60fps to check all is good... then it'll be onto getting it to actually work on the machines, and recording/playing back in attract mode...

- seven segments now working, and attract mode records/plays back the seven segment states - testing improvements to lit lamp texture rendering - also improved seven segment rendering And now time to ring BT to book in this gigabit fibre connection, for self-hosting all the various server stuff we'll need...

Indeed mate, that checklist I posted a bit back, I'm sticking to - once the main components are in place alongside the base functionality for patch updates etc, it should be Arcade SIm for all, just gonna keep plugging away

Thanks @Big J Since posting that vid I've got the 7 segments looking a lot better (again down to mipmapping issues as @JimmytheNugg pointed out earlier with a keen eye )... I should be able to get the default mipmapping all a lot better, it's just not working as it should at the mo because of the custom stuff I'm doing to get things onscreen so fast. All these little bits of progress are a buzz to me too, I never thought I'd get the rendering this tight, but over the course of the project, I've had to buckle in and learn stuff outside the comfort zone to achieve necessary milestones, like full-screen with no emulators visible, and running on modest hardware. I remember getting it so I could send input to MFME (and MAME) running hidden in the background - both those jobs were really tricky to figure out! A lot of this stuff just hasn't been tackled before, so I'm having to think on my feet quite a bit This new fast renderer stuff is a relief to have coming together, I really didn't want it to need a full-on gaming PC just to play it, and this is the solution to that... also been getting some background stuff looked at, in terms of servers... I'm lucky enough to have BT Full Fibre in my area - so I'm thinking now I can perhaps upgrade to that, then run all the various server stuff from a dedicated server PC at my house. Rather than paying every month for 'cloud' services, which would have meant doing more tin-rattling than I'd like. Be good for the website and patch updates, and I may also be able to do all the multiplayer/voice chat/game streaming further down the line (so you can stand next to your mate, watching them play, and have a voice chat over your headset...) - I suspect I'll be hassling @slasher for a bit of advice along the way with all that stuff, as he's a web wizard, I've not done a ton of web stuff... This is certainly become the most interesting project I've ever come up with/worked on, so it's all good Let's hope that hangover's not too bad tomorrow so I can get some more progress on my renderers...

A bit more progress I've added in a 'workaround' fix for now to fix the very blurry buttons we were seeing on the JPM vogues, plus other general lamp blurriness issues. I've got the attract mode to record lamp brightnesses - so that machines like this JPM one that use varying lamp brightnesses during their attracts will now show that properly. The big one - have done some refactoring of the new rendering system, and got the seven segment displays drawing in the arcade at the correct positions/scales. They're all just drawing with all segments on for now, I'll be getting the attract mode recording/playing back their content as one of the next jobs

The 'layout' mipmapping is a work in progress at present... currently I have workaround in to 'fix' the blurry buttons (see new vids in next post). There is also currently no anisotropic filtering on the layout images, this is something I'll be looking at down the line (as it's really improved the floor/walls/ceiling). This will also improve the appearance (sharpen up mipmapped textures viewed from angle/in distance). Also, the normal mipmapping stuff is getting confused due to the way I'm bypassing a lot of Unity's rendering system and running the rendering code directly on the GPU with manual atlassing (that has some disproportionate scaling in from my 'perspective panel' conversion process)... all can probably be improved more, though for now, it's just getting everything drawing again with these custom shaders/instanced indirect draw calls. Another thing to bear in mind is that for arcade with say 300 fruit machines in, that would exceed the available RAM for a lot of users - so I'm planning to use some form of mipmap streaming / virtual texture streaming to handle that (the same way GTA 5 has a massive world, but streams things in as they're needed). I'm planning to have various graphics setting exposed to the user, so things that can be changed at runtime will also be available in there, so you'll be able to pull up that menu and have a tinker, and hopefully achieve the look you want - though I'll of course aim to have the default looking good. Enjoy your wake 'n' bake, I often do the same when I wake up with a hangover from the weekend beers

Just realised I was doing the 'off segments' the same color as the background which was wrong, here's what they look like with brighter off segments

Have done further work on the new seven-segment display shader/renderer - here's 50,000 in a cloud, randomly changing which segments are lit, and also the overall segment color, for every display, every frame GPU is very comfortably drawing them all via the same technique as the new lamp renderer, so I think this one is now good to actually port over to the machine rendering (to replace the old slow system, these also look nicer). Means I need to get the attract modes recording the seven segment displays for testing, along with the segment alpha displays (which I'll probably move onto next).

Tech update Seven segment shader - initial test: This is a first approach to a seven segment display shader. It works by having the 8 segments split across two images, with a segment in each channel (so red, green, blue, alpha, with two images gives 8x segments). In these images previews, alpha is shown in white: The shader can then create any possible drawn segment by combining the various channels (red/green/blue/alpha) of the two images, plus set a base background color. As per the lamp shader, this runs entirely on the graphics card, meaning the CPU has to do no work to draw these. I'm not 100% sure this is the fastest way for this new shader, another option we have in reserve is creating a simple texture atlas (also known as a sprite sheet), and having every possible combination of segments. For 256 possible combinations (8 segments x 8 segments), at a resolution of 256x256 per pre-rendered segment, it would require a 4k texture (4096/256 == 16, 16x16 == 256 possible segment configurations). Nice to have an option in reserve since all this recent shading programming is new to me This approach is probably even faster, but requires far more memory per texture atlas, so if I wanted 3 variations on the 3 main styles of display, that'd be 9x4k textures, which is a significantly wasteful, when that texture memory could be better spent on backglass/lamp textures. Next stage is creating a test scene to really push this, and render say 10,000 segment displays randomly changing, driven by the same direct GPU call system as the new lamp renderer - and check that CPU/GPU usage is definitely about the same between drawing and not drawing. If that tests ok, then I can start on getting them in for real Ultimately it means that all the machines in attract mode will then show their seven segment animations etc (with more work on the attract mode recording/playback system), and when playing machines they will use this renderer (machines are currently unplayable until work is done to refactor stuff so they can use the new renderers).

@nails I think @serene02 covered it well up above, for the fruit machine side, it's pretty much what he said (for now, I have other FME features/enhancements in the concept stage, that may or may not be possible - for instance 'insta-boot' so the machines have zero startup time to get to their previous state). There is also planned video games, coin pushers, other arcade machines support... but that will be much later on... I appreciate that bud, I'm in early stages of rewriting all the rendering to be much faster, so you'll all have to hang in there for quite a while yet before I can get to a suitable pre-alpha state, where it can go out. Realistically, I think we're looking at 2-3 months at least for pre-alpha, it's just a really big project (for one coder). Currently you can't actually even play the machines with the new lamp renderer, only walk around And nothing else is being rendered, except reels/cabinets which may get to stay as they are as they've already had some efficiency enhancements not posted on here (for instance, I am now performing runtime mesh combining on the cabinets... there are more minor optimisations to be had, but not required for pre-alpha) I know it must be slightly frustrating, as you've seen videos where the machines 'work' - but with the new rendering system, it's kinda all-or-nothing, it's a large and complex change to develop, then integrate. Those earlier videos were showing it can be done, and more a proof-of-concept, now I'm focussing on getting it done without it maxxing out a gaming PC; on the builds from a couple of weeks ago, when I had a lot of machines onscreen at the same time, my PC fans would all reeeally spin fast at CPU ~65%, GPU ~40% ...with the new stuff at CPU ~10%, GPU ~20%, the PC is nice and quiet and not sounding like it's about to take off, which is always a good sign I've actually made a start on the new 7 segment (really 8 including the 'dot' segment, one of those legacy terms that stuck I guess ) renderer, and done a quick workaround fix for the blurry buttons/lamps with new renderer (proper fix will also save RAM but is a big job). I'll pop up a tech update soonish, probably once I've got the new 7 segment renderer working well enough in a test scene... well I say it singular, I'll be looking to render like 100,000 of them to make sure it's got the speedy goodness. For a bit of roadmap info in this meandering post (it's Friday night, I've had a few cans after work )... I guess currently for pre-alpha, I'm thinking in no specific order: * Build entirely GPU based rendering subsystems for: ....- 7 segment displays ....- segment alpha displays ....- dot alpha displays * get machines working in play mode as well as attract mode with the new rendering systems, and fully remove the legacy slow systems (which will mean the overlapping lamps look initially worse than they were before on the old slow lamp renderer) * resolve issues with the new lamp rendering causing heavy glitches/failure to 'light' on overlapping lamps, this may be a complex one to solve, but I have some ideas * Learn how to do 'anchoring' then redo all the UI so far plus any new UI needed. Currently the UI only works in your desktop resolution is 1920x1080 - any other resolution it corrupts, buttons/text are pushed offscreen etc * More work on the attract mode player (render data recorder), this will be required, as more refactoring is needed so I can develop some kind of high-level shared machine render pipeline, so the inactive machines and the single engaged machine are all driving the renderers through a unified (much faster) system * Installer/updater could be good, I've not looked into what's involved here * General bugfixes of medium-high impact issues * The thing to find MFME.exe on your system and pull it into the install folder - this will also currently mess up your history, so you'll see "_DATA_LAYOUT.fml" as your last played machines, among other potential problems. But probably fine for pre-alpha, it's only for the adventurous Later I may be able to solve these issues with more dll injection (the same as how the 'turbo startup' system take some control over MFME's internal processes) * Probably a ton of other things I haven't anticipated So TL:DR is hang in there guys, it's going to take a while yet

Should be straightforward to change the ROMs the data layout is using to exploitable ones with a quick bit of tinkering in the Arcade Sim directories (when using MFME for the fruit emulation), if you want to change away from the ones the machine ships with... For MAME this would require more changes for my side, but I think people using MAME to do their fruit machine emulation would be the very casual fruit machine users and not bothered about different ROM versions... long term, I could perhaps get some nice UI in to handle all this so you can switch inside Arcade Sim itself (for both MAME/MFME)... though all that's a rabbit hole, with swapping out the prize decals etc... (If there end up being the multiplayer leaderboard/shared arcade features, I'll be doing various steps so that ROM swapping and other naughtiness won't be possible while playing in 'competitive mode').

Not had chance to work on this for a bit due to real life stuff, but back on tonight Tech update: Done a bit more on developing the structure to contain the new 'fast' renderers for things like lamps (already done with minor graphical issues), but also seven segment displays, dot alphas, 14/16 seg alphas... The new structure has been applied to the base machine, so that now I can run all the 'test machines' I was using earlier, with the fast lamps renderer, to check for issues. As expected, graphical problems with overlapping lamps, particularly bad on Indy, Must have quite a few overlaps or something else going on... Here's a shot of the old test arcade that I kept a copy of, from before I started the recent optimisation work: Couple of weeks back - CPU 68.4%, GPU 32.3% And restored that backed up arcade tonight and took screengrab stood in the exact same spot to compare: Tonight - CPU 10.4%, GPU 18.7% So nearly halved the GPU usage, and taken CPU usage down to less than a sixth of what it was. So worth the time and pain I think I will need to sort out the overlapping lamp issue, I've a couple of ideas for that. Also have another new issue with blurred lamp images on the buttons (and some lamps) - this is due to mip-mapping which has all gotten more complex with how the atlases are scaled for the shader - this will need sorting out when I can come up with a plan for how to best do that. Quick vid showing the machines from the old test arcade all running the new lamp renderer for their attracts, along with the 'overlap flicker' / blurry button lamps issue on some lamps:

Hiya mate Don't think there's a discord channel, though I think a few guys do youtube videos showcasing layouts being emulated. Glad you're enjoying the new FME tech experiments - welcome to the forum

If that BTC fall carries on the way it has been these last couple of weeks, that hopefully might lead to a bunch of used mining cards coming up on ebay

I have thought about those ramp/decays before - should be pretty straightforward - I guess once the user options menu(s) are in, there could be a lamp ramp/decay setting per tech. As you say, the LEDs era techs should have none, then for other eras they should vary. I remember do some checks on a 60FPS youtube video showing some even older machines (like a Nudge Up Double Deluxe or something) and the lamps appeared to ramp/decay even slower than 90s/2000s era machine - perhaps something to do with the lamp matrix on those... definitely planned for mate In terms of assets, I was planning to have those as 'props', I would have to package them up for future releases in advance, then they could also have options, so a lava lamp could have a color slider, and intensity slider, so it 'casts light' in the same way the colored room lamps do. And I know there's some low key demand for a kitchen sink in there somewhere lol I think they did something similar in that Neon Retro Arcade - I'll have to be careful though, distributing music is a bit dodgy - perhaps it could be linked to existing youtube/spotify playlists instead to play in background, with a user option to point to their own local dirs... I think that would probably be ok for the machines, but if you enable the colored room lights it might struggle a little - since most of the rendering heavy lifting is now (intentionally) offloaded to the graphics card - 3080 would of course be able to run anything you throw at it - but with the mining they are like rocking horse droppings!

Second mini tech update - as I've got loads to do today, so I am of course hungover and procrastinating instead I've made a bit more progress on this blended lamp experiment. Like the new fast lamp renderer, this runs completely on the graphics card (zero CPU cost). This technique could potentially be expanded on for reel lamps... The advantage of running things directly on the GPU means generally lower system requirements (as even slow graphics cards are much faster at doing graphics stuff than CPUs). 3 blended lamps with brightness controls, plus a workaround for some (not all yet) of the glitches: