Development Updates

[johnparker007]

Another tech update, have done more improvement work on the culling system. 

- it now doesn't update/draw machines lamps/reels etc if they are facing away from the camera
- changed grid resolution down to 50cm, these seems about the right balance between time to 'bake' the map when first using the arcade, and not showing too many extra machines (due to 'neighbour-based' system I have in there).
- other misc performance improvements

In this picture, you can see the machines with pink stars in front of them have their glass panels disabled (due to facing away from the camera), only drawing the cabinet model itself:

And in this video, showing the latest version of the occlusion system, I keep the task manager visible on top to show CPU/GPU usage (it's the top MachineRenderer row, haven't renamed this to Arcade Simulator yet), and also in bottom left, you can see the FPS (a nice solid 60FPS  ):

I think next up is writing the attract mode codec along with a general overhaul on how all that works, so that hopefully I can get a performance boost there.  Also it will massively speed up loading, currently it takes something like 3-4 minutes to load the arcade in the above video! ... so a much-needed improvement  

Edited March 14, 2021 by johnparker007

[johnparker007]

Some general optimisation work before I start the codec stuff has yielded some more performance gains  ...a screengrab from a more demanding area in the recent walk around video, CPU usage at ~44%:

And standing in that same spot with the new optimisations, CPU usage now at ~30%:

In less demanding areas, the performance gain is more like ~4-8%.  Nice to get some performances gains before I actually start the codec/lamps overhaul!  ...which should hopefully yield some significant gains on top of these ones   

[serene02]

Great work dude

J

[appstrader]

On 14/03/2021 at 16:54, johnparker007 said:

Some general optimisation work before I start the codec stuff has yielded some more performance gains  ...a screengrab from a more demanding area in the recent walk around video, CPU usage at ~44%:

And standing in that same spot with the new optimisations, CPU usage now at ~30%:

In less demanding areas, the performance gain is more like ~4-8%.  Nice to get some performances gains before I actually start the codec/lamps overhaul!  ...which should hopefully yield some significant gains on top of these ones   

I have been looking for something to max out this 8 core laptop...

Anytime you want to have someone to test a few things give me a shout !

 

[johnparker007]

1 hour ago, appstrader said:

I have been looking for something to max out this 8 core laptop...

Anytime you want to have someone to test a few things give me a shout !

 

Thanks for the offer - sounds like your laptop will run it with ease!  There'll be a pre-alpha release for initial testing at 'some point', still a lot more work to do yet...  

[depdawg]

I tried out my Rift S VR headset last night and was in an app called Big Screen, which is like a virtual cinema. It also lets you see your computer screen. So I thought I'd fire up MFME to see what it was like, and put the game in borderless mode. It was surprisingly good. There was a 3d element to the layouts on some of the games, which made it feel quite realistic.

I think there is more focus from Oculus on the development of games on their Quest 2, which is their mobile headset as there are a few new games that are Quest only, missing the PC attached Rift S. Which got me thinking. @johnparker007 as your arcade relies on MFME for the emulation I guess this would mean the future planned VR version will need to be tied to the PC platform only? The good news is the Quest 2 can be attached to a PC with an additional  accessory cable, so anybody with a quest 2 can still access MFME via a PC.

Having had a taster I can't wait to see your VR arcades...in time!

 

 

[Mazza500]

Never got on with VR, tried a whole bunch of headsets but just found the quality too low for my liking. Tried the Oculus Rift, Oculus Rift S and supposedly the best Samsung Odyssey Plus. 

Quest 2 doesn't actually need that high of a spec pc to be able to run compared to a Rift S so will be good for anyone wanting to try it out when the time comes. 

• CPU: Intel i5-4590 / AMD Ryzen 5 1500X or greater
• RAM: 8 GB
• OS: Windows 10
• VIDEO CARD: NVIDIA GeForce GTX 970 / AMD Radeon 400 Series
• https://support.oculus.com/444256562873335/  (GPU Compatibility) 

Looking forward to further updates and the pre-alpha. I have a i9 10900k and a rtx 2080ti so can't wait to max everything out in 4k. 

[johnparker007]

MAME will be also supported, and MAME does fruit machines, so I (or someone else) may put the work in there getting MAME fruit machine support up from where it was - I did some work there years back, had a few older techs working ok, plus a demo Scorpion 4 + ccTalk (running a DOND in door closed)... and more recently Haze/agemame were doing some tinkering with JPM techs. 

That's all a very long way off though    So yeah, for now, running fruit machines in the arcade is going to be Windows only, using the MFME Windows exe.

Edited March 16, 2021 by johnparker007

[Reg]

@johnparker007 some of those shots looks brilliant on the post from Sunday !  You can almost imagine being there.

[johnparker007]

Another tech update (a lot of these at the mo, as I'm trying to optimise performance with various experiments!).

So I did the provisional work on the codec, enough to perform a small test, and it had very little effect on CPU load / GPU load, rather than making things significantly faster.  Still needs doing, but I've put it to one side for now, to keep focus on getting the performance up.

I am now looking at other techniques to get increased performance;

Texture Atlassing, Runtime Static Batching, Mesh Combining, GPU Instancing. 

I'm hopeful that some combination of these techniques will yield good results, though it's mostly stuff I'm only vaguely familiar with, so a learning curve and some tests required  

It's all down to having the arcades created from a level editor at runtime (rather than fixed arcades prepared by me in advance), it means all the stuff Unity has built in to optimise for CPU/GPU is gone - so we have to roll our own solutions... the custom occlusion mapping system worked really well though, so I'm optimistic for now  

[niallquinn]

On 16/03/2021 at 17:23, Reg said:

@johnparker007 some of those shots looks brilliant on the post from Sunday !  You can almost imagine being there.

I know, it's mental isn't it.

Already forewarned work I mean need a week off work for it......................

Great stuff.

 

 

[johnparker007]

Time for another tech update   

Have spent the past few days working on R&D for the new lamp drawing optimisation, and a plan is starting to come together.

So the individual lamp textures will now be assembled into Texture Atlases, one per machine - here's the atlas of Happy Hour I'm using for tests:

And then I am also working on a shader, that allows for GPU Instancing.  I won't get into the heavy details, suffice to say it gives performance improvements   I have a demo, where I've hand-set this to draw the small Happy Hour logo from the top-right of the atlas above, and made it draw lots of them, to simulate the effect of drawing lots of lamps in the arcade:

Zooming out on the above:

In the zoomed in view above, you'll notice that the different Happy Hour logos have varying levels of transparency.  This is being randomly changed every frame by my test program, to simulated flashing all the lamps on the machines.

In the demo above, I can switch between normal drawing, or drawing with the new GPU Instanced mode - so it allows me to compare how much faster the new way is (ie. is it worth me rewriting loads of stuff to properly implement this new approach in the simulator).

Here are the results:

This is an amazing result for the GPU, and a worthwhile result on the CPU side  

With the new system, it should take the graphics card around 10% of the time it currently takes to specifically draw all the lamps (in other words, the new system is around 10x faster on the graphics card at drawing lots of lamps).  The CPU savings are much less, but still fairly substantial.

So the plan going forward is generally: making machines use the large Texture Atlas images, continuing on this shader so I can show different parts of the large atlas image alongside different transparency (transparency already working shown above).  Then I have to overhaul the machine building/rendering to use this new system.  Once it's all done and properly implemented, the graphics card requirements should be far less than they were, and the CPU requirements will be a little less too, which is all good   

Edited March 20, 2021 by johnparker007

[Jolt-Z]

This project looks quite neat. Wonder how it would handle classic layouts though?

[johnparker007]

15 minutes ago, Jolt-Z said:

This project looks quite neat. Wonder how it would handle classic layouts though?

I'm not really considering them at this point as the project is more about realistic looking arcades, though it would be possible - here is an example of a classic layout I converted to MAME from an old converter project:

But I really wouldn't expect this any time soon, as my time is very limited, so I have to choose things to work on wisely!  

[johnparker007]

Another tech update on the new lamp rendering system - I've made a lot of progress, and  got the machines I originally had converted to the new system.  Somewhat disappointingly I'm not seeing gains in the areas where I thought I would see them;   CPU has reduced very slightly, but GPU has actually gone up quite a bit.  System memory has reduced quite a bit. A little confused but it's late and I'm tired, maybe I'll be able to figure that out tomorrow  

Also, all this work was required anyway really to allow for 'texture streaming', which will mean that someone with less GPU RAM can still play an arcade with a lot of unique machines, as it streams lower resolution copies of the texture 'sheets' for the machines in the distance... Some blurring is noticeable, this will be addressed with the texture streaming, and setting up better bias.

[bullionbars2011]

This looks fantastic and alot of time and effort have been put into this will be looking forward to have a go on this 

Thankyou!

[johnparker007]

Still not sure why my GPU went up after all the work on GPU instancing, which is annoying, but I'll have to leave that for now, as the system that's in place... I've done a new quick test this morning, to try not drawing the cabinets, and that yields significant GPU savings... so I think the next step is going to be using Runtime Static Batching at the start of the level, to try optimise cabinet drawing.  Hopefully this will give me some savings. 

I'll start with having all the cabinets entirely made from say a single brown wood texture (so I can batch them) - then if I get the desired savings, I'll start on the longer task of making them draw with different colors/textures/effects from a single master material, whilst still keeping the savings.


 

[Retrofruit]

Some incredible work going on here

[niallquinn]

It's that realistic, I can feel the blazing head coming off all those machines!

 

[niallquinn]

Heat I meant to say!!!!

 

 

[slasher]

Machines that give head. That could be interesting 

[johnparker007]

It's yet another optimisation R&D tech update  There's likely a few weeks of this stuff to do, it's starting to come together a bit more now though  

Have identified more problem areas, and hopefully come up with solutions to some of them... also various settings tweaking.  My editor and arcade scenes with lots of stuff disabled now run more efficiently, as I've ironed out some issues.  Lots of stuff is turned off at present, but I have strategies for the cabinets, and seven segment displays, segment alpha displays... the alpha dot displays are tricker to optimise, I think I'll be needing to make a custom shader for those. And I maybe have something to tweak the lamps performance a little (along with the codec which will should also give a little CPU with more work on it).

Now  roughly average 12% CPU usage, 7% GPU usage walking around the in test arcade (with lots of stuff turned off) .  Also nice to see 60FPS in the Arcade Editor, that thing was running slower and slower!  

Also, the load times are far less insane now, it's dropped from around 3-4 minutes to load into the test arcade, down to a few seconds.

 

Edited March 24, 2021 by johnparker007

[johnparker007]

Another mini-update - I've been looking into having different quality solutions to the blurry textures at a distance that will come from the 'streaming' system (to allow for an arcade with lots of unique machines to be rendered, while the total texture memory required for those machines could be say 5gb, far more than in an average graphics card).  There are some texture resampling approaches, that can be changed at runtime (either by me autodetecting which graphics settings to use, plus allowing the user to manually override to their preference).

Here is an example of '16x Anisotropic' filtering on the carpet, to fix blurriness in the distance whilst still using mipmap scaled textures, 1x on left half, 16x on right half (you'll need to zoom in to exactly 100% see the effect as it would appear ingame on your screen):

The plan is that all the textures will be using mipmaps, then some form of filtering, depending on the power of the PC it's running on (no filtering > bilinear filtering > trilinear filtering > anisotropic filtering 4x > 8x > 16x).

Edited March 25, 2021 by johnparker007

[Retrofruit]

7 hours ago, johnparker007 said:

Another mini-update - I've been looking into having different quality solutions to the blurry textures at a distance that will come from the 'streaming' system (to allow for an arcade with lots of unique machines to be rendered, while the total texture memory required for those machines could be say 5gb, far more than in an average graphics card).  There are some texture resampling approaches, that can be changed at runtime (either by me autodetecting which graphics settings to use, plus allowing the user to manually override to their preference).

Here is an example of '16x Anisotropic' filtering on the carpet, to fix blurriness in the distance whilst still using mipmap scaled textures, 1x on left half, 16x on right half (you'll need to zoom in to exactly 100% see the effect as it would appear ingame on your screen):

The plan is that all the textures will be using mipmaps, then some form of filtering, depending on the power of the PC it's running on (no filtering > bilinear filtering > trilinear filtering > anisotropic filtering 4x > 8x > 16x).

Very interesting effect. Are the floor levels actually different between the two sides or does the blurring on the left give the impression that the room in the distance is lower on that side? The right side gives the impression particularly towards the end that it is actually an incline but when I cover the left side the right side then looks more consistent with the foreground.

[johnparker007]

They're just screengrabs I pasted together in the paint package to show the side by side effect, so that's just my shabby photoshop skills   (It's just to show blur reduction whilst still using mipmaps for rendering).