New TGC product: AGK Studio(=AGK3?) + discounts for early adopters..

Started by Rick Nasher, February 04, 2019, 23:10:49

Previous topic - Next topic

Pingus

@Derron,

Yes I had a look at Goddot. Too complicated for my skills (although I agree it looks good).

I also tried to compile samples for Android with BmaxNG a while ago and never get something working on my phone while it was a smooth as butter with AGK.
Anyway I'm running a business, I can only work with a commercialy based engine.

I sent you a PM in case you want to have a look at my AGK test.

Qube

Quote@Qube,

I'm not sure the calculated fps is usefull. On my PC it shows a constant 60, even if obviously the code stuck regulary when a lot of matches are done when you restart a new random board (watch the small gems moving). If on your PC the gem is always moving smoothly at constant speed then yes there is something odd with my rig (which run most VR games without issue ;))
Please send me your code update with the fps min/max.
PM sent :) - Yes the gem always moves at a constant speed and hasn't blipped once.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Pingus

Thanks Qube,

That's really odd. From what I see you disabled the vsynch, hence no limit to the fps and app running faster.
But that does not change that there is a lot of stutter when a lot of matches are made at the beginning, even if the displayed average fps is ~600
It seems that you are working on Mac isnt' it ?

Qube

I was just seeing how fast it ran overall to see if there was anything really obvious.

I do note that in parts it's going over the same for / next loop multiple times. Even changing something like the below will give a big per cycle speed increase :

I've not bug tested but a real simple optimisation here is not to repeat the same loop over again when it can be done in one pass.


    //X Matches
for i2 = 1 to rows - 1
for i = 2 to columns-1
if board[i,i2].color = board[i-1,i2].color and board[i,i2].color = board[i+1,i2].color
match=match+1
matches[match,1] = board[i-1,i2].currentgem
matches[match,2] = board[i,i2].currentgem
matches[match,3] = board[i+1,i2].currentgem
endif
if board[i,i2].color = board[i,i2-1].color and board[i,i2].color = board[i,i2+1].color
match=match+1
matches[match,1] = board[i,i2-1].currentgem
matches[match,2] = board[i,i2].currentgem
matches[match,3] = board[i,i2+1].currentgem
endif
next i
    next i2
   
    ////Y Matches
    //for i2 = 2 to rows-1
//for i = 1 to columns
//if board[i,i2].color = board[i,i2-1].color and board[i,i2].color = board[i,i2+1].color
//match=match+1
//matches[match,1] = board[i,i2-1].currentgem
//matches[match,2] = board[i,i2].currentgem
//matches[match,3] = board[i,i2+1].currentgem
//endif
//next i
    //next i2
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Pingus

Yes that's right, that double loop can be replaced by one.

It works the same. There is no visible difference performance wise but it is always satisfying to remove a useless loop :)

blinkok

It may be that the first loop changes the board (i-1) which then needs to be checked again by the second loop

As was mentioned before, i think working from the affected tiles outward rather than a blanket check would bring about the greatest improvement

Qube

Having looked over this again it's not the best way to do it for massive boards. Problem is even if a handful of gems move the whole board gets checked each and every time. It's a big time sucker which leads to 1000+ worth of gems being checked when they don't need to be.

Ideally moving gems should be sent to a type array and then when they've stopped falling you check those and recursively build out from there for actions on matching gems. A bit harder to code but much more performant for larger boards. Why loop a 1000+ times when only a handful of gems have moved?. At the moment the code loops over 1000 gems for actions and then loops over it again for drawing them.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Pingus

QuoteA bit harder to code but much more performant for larger boards.

Probably a bit more than 'a bit'. I agree that there may be ways to reduce the loop amount, at the price of greatly increasing the code complexity, hence increasing complexity when time comes to add more features or simply debug.
There is an 'advantage' to that full parse : the execution time is somehow always the same; An algorythm that focus first on changes and grow its checking over several frames could work but could also leads to unpredictable cases with possibly big stutters occcuring from time to time.
Personally, as long as a compiled language can handle all this loops in less than few ms, I do not see the point to bother yet.

GaborD

"It's more complicated to implement" is not a disqualifier but rather a motivator.
Solving these things and coming up with the best solutions is the fun part of game dev. :)

That said, if you feel a different engine is a better fit for the project, switch to it and don't look back (until the next project).
In my opinion the engine should always be chosen after the initial planning/draft-design phase and for the specific needs of a project and the devs.
Just don't say it's because AGK can't do it or is too slow for it, that's not fair. It can do it easily.

Qube

QuotePersonally, as long as a compiled language can handle all this loops in less than few ms, I do not see the point to bother yet.
I'm with you on that, I'm the original brute force coder for any and all routines ;D - On the flip side I enjoy coding in AGK so I had to think differently for more heavy logic based routines. I love coming up with faster solutions as I like the challenge.

Sure a pure compiled language can brute force all the routines that you have at the moment but add a few more brute force layers and then the compiled language will suffer as 1000's upon 1000's of array cycles is going to kill frame rate. Don't forget that not everyone has i7 CPU's so especially for a match-3 game ( casual market who don't have high end kit ) you need to optimise rather than brute force.

In a nutshell use what tool works best for you for the project you're working on :)
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

MikeHart

Plus never forget that you can outsource heavy computations to a plugin coded in C++ or whatever can create a compatible DLL for you.

Derron

BlitzMaxNG can create DLLs - just did it the last weeks. So for you - being used to the BlitzMax language - it is a viable option.


Nonetheless I am _very_ interested in a new thread about match 3 - and how to approach a more or less "object oriented approach" to the whole thing. With OO I am talking about grids, properties, objects in lists ... and to a more or less intelligent way of handling the whole thing - including bonus objects including delayed effects (remove blocks after 1 second).
There are surely multiple approaches to this particular thing. The basic ideas should be translateable in various programming languages.


bye
Ron

Qube

Quote from: Derron link=topic=5229.msquote author=Derron link=topic=5229.msg22861#msg22861 date=1549705686]
Nonetheless I am _very_ interested in a new thread about match 3 - and how to approach a more or less "object oriented approach" to the whole thing. With OO I am talking about grids, properties, objects in lists ... and to a more or less intelligent way of handling the whole thing - including bonus objects including delayed effects (remove blocks after 1 second).
There are surely multiple approaches to this particular thing. The basic ideas should be translateable in various programming languages.
Sounds like a good idea and something I'd be interested in :) not sure if I could comit much time during the current comp but definitely up for it.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Xerra

Quote from: Qube on February 09, 2019, 11:37:55
Sounds like a good idea and something I'd be interested in :) not sure if I could comit much time during the current comp but definitely up for it.

God no. Discussion is all good but actually having a crack at it before this competition ends. No way. Still think that it would make quite a good theme for the next compo.
M2 Pro Mac mini - 16GB 512 SSD
ACER Nitro 5 15.6" Gaming Laptop - Intel® Core™ i7, RTX 3050, 1 TB SSD
Vic 20 - 3.5k 1mhz 6502

Latest game - https://xerra.itch.io/Gridrunner
Blog: http://xerra.co.uk
Itch.IO: https://xerra.itch.io/

Derron

I did not wanted to see a complete game or so - just ideas on how to approach such stuff. How do you handle "blocks animation" or other stuff - in a static game you could simply store everything in a integer-array/grid. Numbers indicate the color and "0" means "there is none". But then you need to handle animation, special effects (non visual - eg. a wave destroying other blocks), ...
People use different approaches to such ideas - eg "scene independence" (each scene has to be "playable" on its own without requiring data of other scenes).

Discussing such stuff can be interesting for other gameplays too as each gameplay leads to a limit of some ones approach - somewhen at least. So some approaches do not suit well to certain game types.


bye
Ron