Development Updates

[johnparker007]

1 hour ago, niallquinn said:

Does anybody else, watch these incredible videos, and just smile, with a lovely warm comfort feeling?

Can't wait to have a play with this.  I mean, having a mixed arcade, having a mpu4 arcade, having an £100 area, or £500 area, or loads of lotechs areas or whatever, it's superb it really is.

 

 

Thanks bud    It's such slow work but there will be a pre-Alpha tester release at 'some point' so people can finally have a play with the project so far.  There's still a lot to do to get to that stage, so I guess maybe tentatively a couple more months to have something people could try out... 

For instance I've spent all afternoon finishing up a part missing from my custom Delphi font scraper as it couldn't differentiate between I and l in the Delphi font (uppercase 'i' or lowercase 'L').  I now need that ability in order to re-add Coin mech support back to the optimised data layouts.  I swear hours just vanish!   

But, there's progress all the time, it'll get there   Hopefully get those coin mechs actually working again tomorrow...

[Tommy c]

19 hours ago, johnparker007 said:

Blackpool Funland carpet texture in action after some processing of the texture 


 

You better hope nobles didn't have that carpet copyrighted  awesome updates and progress again many thanks.

[johnparker007]

1 hour ago, Tommy c said:

You better hope nobles didn't have that carpet copyrighted  awesome updates and progress again many thanks.

I did notice there are letter 'N' in that carpet pattern (inside the smaller circles with a little crown on top), makes more sense now if it's Nobles!  

[johnparker007]

Have implemented the Coin/Note & Effect dropdowns in the data layouts which fixes the coin mechs issue. Have updated some Eclipse machines to the latest so they can be used.  Here's a vid of adding copies of the new machines in the editor to make a little corner of an arcade and testing a few  

(the £1 stake start button not working on one of the machines is a new issue to do with a clash between LED lamp and normal lamp, it's on my buglist for fixing at some point)

[johnparker007]

A little 'tech update' as I know some are interested in this side of things   

So having done some more stress testing, it's become clear than I need to write a custom 'occlusion-culling' system.

Occlusion culling is one of the tricks we use to save CPU/GPU time, by only updating and drawing things the user can currently see, for example here you can see lots of the world 'disappears' when it's not in the viewing cone:


That's how you run large complex worlds (or arcades!) without everything slowing to a crawl.

Unity game engine has a system for this, but it is entirely based on fixed levels that ship with the game, so it can't work for our use case, as we have a level editor so the user can make their own levels.  This also means I will have to do other custom stuff for lighting/shadows as again, none of it ships with the game, you can make any arcade you want.

So, here you can see a shot of a test arcade running - with task manager open, we see from the top row (Machine Renderer.exe) that I'm using a whopping 70% of CPU capacity, along with over 20% of the GPU capacity:

and in the bottom-left we see that I'm only getting 27FPS.

"Why is it so bad JP?"  I hear you ask    Well, if we look in the Arcade Editor at the test map, things become clearer:

So even though we can't see them in-game in that first screenshot above, there's a lot more machines hidden behind the machines we can see.

Even though they are obscured from view, every one of them is still being updated, drawn, running various code etc.  Which translates to a lot of CPU and GPU load.  It is very expensive at runtime to figure out what can and can't be seen, so we can't do it on-the-fly (or we'll have a horrible low framerate from all the calculations involved in deciding what to draw/update based on whether it can currently be seen).  

With that in mind, my plan is to pre-calculate what can and can't be seen from every point in the Arcade, whenever an Arcade design is saved in the Arcade Editor and save this as part of the arcade file.  This will be done by dividing the floor up into grid squares, say 50cm x 50cm and working out what can possibly be seen from each square.  By doing the expensive calculations once at the point the Arcade is saved from the Editor, when it doesn't matter that the computer is busy for a few seconds working it all out, we won't be killing the CPU when actually playing the arcade.  

For each square, I will work out what is visible at any point within the square, looking in all directions from that point.  And I'll break that into:

- is any part of any of the front glass panels with all the reels, lamps etc visible?
- is any part of the 3d model of the machine cabinet visible?

The reason for this is that all the machines that are facing away from us, we still want to draw the back/side of the cabinet if it's visible, but we don't want to draw/update all the expensive lamps as they're facing away from us and we can't see them.

And of course, if the entire cabinet is not visible from our current grid square, then we can skip most stuff associated with this machine.

Using the editor to mock up what would happen if we were stood in the arcade like in the screenshot at the start of this post - all the machines with boxes around them, I wouldn't update/draw the glass panels as they'd be hidden from view anyway:


And around 90% of those machines above, their entire cabinet would be hidden from view so I wouldn't draw that either.

Once this is all done, I believe it should solve the problem of high CPU/GPU load with lots of machines   So at runtime, in the arcade, I will check what square I'm in, get a list of what glasses/cabinets could possibly be seen from my square, and only draw/update those.

A chunky task to be sure, but it will make everything much smoother for large arcades  

Edited March 7, 2021 by johnparker007

[Reg]

Lovely update, thank you @johnparker007.

I remember when @Wizard used to go into great depth with me on some of the things he was working on and your post here brings back great memories.

Enjoyed what you have read and I hope that people who read this see how much work goes into these types of projects, thank you for sharing and also the continued development of your work here.

[johnparker007]

Another tech update on the occlusion culling system research  

So my initial thoughts were to fire lots of 'rays' (straight lines like from a laser pointer) from each test position, see what they hit around all 360 degrees and use that to build up lists of what machines I can see from each position.  So it would look something like this:



...(but continuing behind as well).  This is going to be pretty slow though, and since the rays spread out over distance, they are going miss some things.  In this example below, the machine in the middle behind the other two machines could easily be missed, if one ray hits the left machine, and the next ray hits the right machine, skipping over the machine in the middle:



And so then when you were stood in the arcade at that position, I wouldn't be drawing the middle machine at the back as it was missed by the rays, which isn't great...

So I'm now thinking about coming at it from the other direction (analysing what is drawn), which should be faster and eliminate the problem of these gaps  

Firstly, I knocked up a quick test arcade in the editor:



Then, using a shader, I've generated this somewhat mind-bending 360 degree rendering, from a position near the middle of the arcade:

So this is kind of like when you take a panoramic photo on your phone by slowly turning on the spot taking snaps, then it stiches them all together.

Apart from looking pretty crazy, it shows every machine that will be in view when stood on that spot, for any direction you are facing.

The 'next stage' (I'm kinda making this up as I go a bit!) is to get the machines rendering with no textures, just flat colour.  So in a really simple example, here is a close up part from the left side of the 360 image above:



And now here is a mockup of that same part, with each machine being rendered a different solid color:



So then, since I know which color I chose for each machine, I can scan through this 2d image (ignoring the floor and ceiling areas), and find all the different colors.  Then I'll know what machines have been drawn.  (Red is Smash n Grab, Pink is BarX etc).

In reality, the differences in color will be very tiny, so there'll be say 255 different shades of pure red for instance (and the system will support up to 255 or up to 65536 machines, though it'll go a bit faster with 1-255 machines).

I think there should be a fair bit of room for optimisations, so hooopefully (crosses fingers and toes), it won't add too much to the time when saving, certainly for very small arcades it should be fast.  If it's still slow for larger ones, there will perhaps end up being an option in the editor, to choose when to update the 'culling map', or to choose 'draft quality', for quick testing your arcade, that will be created much faster, albeit potentially with a few minor missing machine issues (where they are hidden between tiny cracks in the distance).

Certainly a learning curve all this, but being able to make your own large arcades is such a fun feature (and needs this system creating), - I will continue to work on this and hopefully get to a decent solution  

Edited March 8, 2021 by johnparker007

[Zippy]

You doing a ceiling too @johnparker007 that is crazy, any chance you can sling in a few naughty ones for me please

[johnparker007]

1 hour ago, Big J said:

You doing a ceiling too @johnparker007 that is crazy, any chance you can sling in a few naughty ones for me please

Well that all depends on what these 'naughty ones' are haha!  

[johnparker007]

Have made some good progress on this tonight, and it's now looking like some kind of abstract art piece!  Prints available from $999.99  

But there's valuable culling info in those flat colors to be had, hopefully this will end up working even though it's a bit crazy  


 

[Zippy]

14 minutes ago, johnparker007 said:

Well that all depends on what these 'naughty ones' are haha!  

Was going to do a dump on your post because you damn well know what I am talking about hahaha

Just out of curiosity as am thoroughly interested in your work (which is no secret) how many hours per time do you spend on it?

[johnparker007]

lol all I know about these 'naughty ones' is that they're apparently naughty! 

Hours per day depends, I'm usually putting in around 20-30 hours a week at present.  It was more like 40 hours, but on top of my day job it was starting to burn me out, so had to dial it back a bit  

[slasher]

Only thing I can work out would be maybe he wants a mirrored or pornographic ceiling?

Brilliant work. Reminds me of when I used to mod the java game trial bike pro. You'd get a pic then make the track all green for the game to recognise it lol

[Zippy]

@slasher you bastard hahaha

Sorry @johnparker007 It is the pervert in me lol. That is a lot of hours mate and believe I appreciate it just take care of yourself and watch the old health. Health and happiness always comes first.

[johnparker007]

Time for a tech update  

After a week's grafting, I am relieved  ...to see the first actual working test of the experimental occlusion mapping system.  It's working better than I'd expected, as this was all a bit of a gamble to be honest, it's totally custom stuff 

Right, so here is a test map in the editor:

... and here is the first working demo of the basics of it working.  It is very generous (to ensure we don't see machines 'popping in' as we go around corners), and there's other (much easier) stuff yet to add, to hide machines that are simply offscreen to the left/right/behind the camera.

This is the real meat though, this is determining machines that cannot possibly be visible (ie. 'occluded' by ones that are closer to us) and only drawing/updating the potentially visible ones.  If the arcade contained hundreds of machines, the system would cope just fine without killing the CPU... expect a larger demo soon  

So on the right, you can see what you'd see when playing the arcade.  On the left, you can see a debug overhead view, and you can notice a red line, that is the forward-looking direction of my camera.  You will see machines popping in and out of existence on the left (so saving CPU), but on the right, you cannot tell this is happening (as the one's being made invisible are safely behind machines that are blocking our view of them)  
 

 

Edited March 12, 2021 by johnparker007

[serene02]

Wow, amazing work on this

J

[johnparker007]

Got straight back on this when I woke up   So, here's a demo with a much larger test arcade, with culling that is slightly lower quality (you may see a missing machine if you peek through the very narrow 1cm gaps between machines) but 'bakes' much faster when saving from the editor.

Still quite a bit more to do on this task (you can see the reels are overly bouncy, this is because I still need to do more with CPU optimisation), but definitely working as planned.  Should be able to get more speed yet...  

I also will be starting work on the 'attract mode codec' and pooling (so if you have 100x BarX machines, they'll all read from the same recording, they currently load a copy each).  This codec will losslessly compress attract mode lamp (and alpha display) recordings - again reducing CPU load and also RAM required, whilst also massively speeding up load times (this latest test arcade took about 3+ minutes to load in!).

New test arcade in editor:

Overhead view on left showing latest culling system in action (arcade view on right):

New large test arcade running full screen with latest culling:

 

Edited March 13, 2021 by johnparker007

[serene02]

No way, this is insane !!!   When you do the attract more thing, say you have 3 of the same machine is it possible you could start the attract modes at different points so all machine aren’t synced with each other?   Obviously in the wild someone might play one machine taking it out of attract, so when it goes back into attract it will be out of sync.  

J

[johnparker007]

1 hour ago, A:E said:

No way, this is insane !!!   When you do the attract more thing, say you have 3 of the same machine is it possible you could start the attract modes at different points so all machine aren’t synced with each other?   Obviously in the wild someone might play one machine taking it out of attract, so when it goes back into attract it will be out of sync.  

J

Yes indeed mate   - that is how it used to work (back when I did an arcade full of Happy Hours on an earlier revision of all this stuff)... I just have that line commented out at present, I'll pop it back on for the next video when there are more optimisations done, hopefully have everything back up to a smooth 60 FPS again

[Ginge]

Don’t know if these pics of carpets are any good or can be used but they are from an arcade I was working in the other day 

[wearecity]

1 hour ago, Ginge said:

Don’t know if these pics of carpets are any good or can be used but they are from an arcade I was working in the other day 

Oh my eyes hurt. 

[johnparker007]

Thanks @Ginge I will have a bash at extracting when I'm next doing carpets!  I'm still learning so the one in the recent videos was easier to extract, these may be a little more challenging due to the way the repeat in the patterns is, but they are great patterns   

10 minutes ago, wearecity said:

Oh my eyes hurt. 

That's how you know they're the good arcade carpet patterns!  

[Tommy c]

Excellent updates again, cheers.

[R4D4]

Amazing, love the dev diary, thanks. Will the culling allow for a wider fov for the hopefully supported VR version?

[johnparker007]

3 hours ago, R4D4 said:

Amazing, love the dev diary, thanks. Will the culling allow for a wider fov for the hopefully supported VR version?

Thanks @R4D4   Yes, the culling will support wider FOV as required for VR.  VR support is planned, but desktop is the primary target, as not many people have VR headsets (yet), myself included.