M.A.C.E. Tower Defense

@imagodespira
Laser probabaly good at the begining, but the more waves passes, the better to have more Rockets instead :) Upgraded rockets can do all the job

Btw, fight-balance and whole game logic as always in your with Frank games are of top level. Really quality stuff.

Take a look how on x5000 with RadeonRX looks like end of the level 30 with quite a loot of enimies and action on the screen with no slowdowns:

COOL ;)

fight-balance in such games is Frank´s work. I never reached Level 26 ;) Swamp Defense 2 is the easyer TD and this is hard enough for me.

@imagodespira
Now stuck in level32, and i think now there is key to re-play all the levels again, to reach 5000$, and buy this "more money for dead enimies", as starting from level 32 is cleary not enough money to continue killing bastards :)

Last tower defence game I played was Defence Grid and had a great time with it. Bought MACE Tower Defence couple of weeks ago and tried it out today: I love it! It looked like my type of the game and I was not wrong, thanks EntwicklerX duo, don't stop doing what you do best!

@imagodespira
Quote:

Level 35 passed , what a mess, take a look at latest minute:



And the last one is level 70, i imagine what will be there :)

@kas1e

Holy moly!

@Kas1e ;) Very cool!

Kas1e spoiled nearly the whole game (so I did not watch your videos since I want to discover the levels by myself :) ).

I bought it today (15 bucks given). I made a news here : https://amiga-ng.org/article.php?sid=1297

A a simple video (I'm not very good since I was all new to the game) : https://video.amiga-ng.org/w/uwyeUyEKvbQDgRRS6PC52T

@imagodespira

I bought M.A.C.E. Tower Defense for Android and Spencer, Super Star Blast and Pyramid Quest for Switch.

I'm playing Pyramid Quest now and like it very much, cause it reminds me of Montezuma's Revenge, which I loved to play on my C64.

Really nice games. Keep them coming!

Pyramid Quest on AmigaOS 4 would be great

@emeck: Thanks for playing our games. And Yes Pyramdi Quest has its roots in Montezuma´s Revenge. This was and is my favourite game on my Atari 130XE (my first computer ever!).

@K-L: We try. But from current perspective it is too much for our systems. We use much polygons and animations with bones which slows down our systems. We hoped for GART Support but it does not work. If we have time, we will reduce some objects and settings and hope to get it work in an acceptable way (performance + visuals). But Frank say it is a bigg problem ;)

@imagodespira

Quote:
We do have GART support, and it most certainly does work. However, it doesn't have as big an impact on performance as hoped, and it cannot be used on the Sam460 due to lack of memory coherency. I tried to get it working on the Sam460 using manual CPU cache flushing, but couldn't get it working there reliably. GART is working on the X1000, X5000, & A1222.

Hans

... Maybe i misundersund Matthew´s Email:

"You shouldn’t expect much more performance unless GART is implemented by Hyperion in the old graphics library. Hans has already added GART support in our drivers."

... So, it will never be faster than that we have now? We try our best but newer games never will work on our systems well. I hoped there is a bit "more" we can get ;)

@imagodespira

Quote:
I'm not sure where Matthew gets that idea from. I doubt that the graphics.library matters much for 3D games.

Quote:
I'm sure it can be faster, although we'll always be hampered by the endianness conversion that we have to do when transferring data to/from the GPU.

I suspect that there's a bottleneck somewhere that's holding things back. We just haven't found it yet. Then there are things such as bitmap/texture tiling that improve VRAM bandwidth usage efficiency.

Hans

@Hans: Thanks for the explanation. I think we are all happy to read such deeper insights ;)

@Hans
Quote:

Imho we need to go usual easy route : create a bunch of test cases , preferable cross-platform ones, and start testing on all different computers and OSes. I.e. tests to copy data, small, big, tests to read/write from/to GPU, etc, etc, everything. But they should be not low-level amigaos specific, but something really cross-platform, so we can compare with all other computers/oses, to see, what exactly and where we loose that much.

Then we can think what/where/etc.

Those examples from Irrlich Engine is kind of OK too, and they do show in some examples really strange slow downs in compare with shity 15 years old PCs, which can't be explained by any hardware limitations but only by software implementations (kernel come to mind as well).

But then, irrlicht's examples mean also GL4ES + Ogles2 , so we have too much layers between which can be blamed for.

But how else if not opengl wrote cross-platform tests ? Even directly ogles2 will mean layer with ogles2 + nova , so again, something between.

We need to find out who is guilty much : kernel, drivers, 3d libs, or what. At least we can rule out gl4es because Amiboing guys do use OGLES2 directly, without GL4ES.


Maybe asking Frank to wrote some tests which should be fast and they not can help with find the issue ?

Let's not forget the most obvious bottleneck:
unoptimized shaders in the game itself.
E.g. I analyzed Spencer shaders and there's huge optimization potential!

Don´t forget that we have to go a path wich works for our work we have to live from and Amiga related stuff.
It should work with a decent/realistic amount of optimization. Maybe it is not your goal, but we want to finish and release :)

Anyway. In our newer games we have much more polygons, we have much more objects and in Pyramid Quest we also use bones for manipulating the mesh to get smooth animations. This breaks the frame rate down. Some shader tweaking don´t brings us 60 frames instead of 6.

@Daniel
Yeah, while micro-optmisation is surely possible with shaders optimisation, there still some strange big difference in speed in case with some irrlicht examples. That what i mean:

Irrlicht engine have bunch of examples, and 4 of them are strangely give very low framerates. When all of them raise speed, then in all other games we have more speed too.


Firstly, i do compare them with software rendering, so, pure CPU rendering, all of them use SDL1 driver (so no direct X11 or Win32 drivers), and all versions of everything the same.

So:



What we see there, is that in terms of software rendering (so, kernel, pure 2D drivers, etc), we a little bit bettter than AMD e360 1.6ghz with HD 6300m. And 3-4 times slower than more or less modern icore_i5 2.7ghz.

But ok, that expected due to all known problems that our hardware had limitations and stuff, so , it's ok that it's a little bit better than old 1.6ghz AMD. Of course, speaking of hope it should be at least 30-40% faster (as have better memory, etc than 1.6ghz amd), but ok. Still, its not worse, it's even a little bit better.

That mean, that we do have in terms of kernel and 2d drivers "ok" speed. Sure, with a little bit area of improvements, and maybe things a little bit changed already in last year (that bench mark were done 6 months ago), but still, more or less expected as it is.


Now, we add at top of it Nova, GL4ES and OGLES2. And, we again, for first expect that it will be in all the tests kind of the same (at minimum) as old 1.6ghz AMD with just shity HD 6300m, but of course, as it RadeonRX we do hope for more, and we are, in many examples, but not in some of them. Check this out:




Most of examples are very fast, and even faster than on icore 2.7ghz, but some, slower than in AMD 1.6ghz with that shit-card HD6300m (while, even in software rendering, they faster on our side).

I mean those examples: 02.Quake3Map , 16.Quake3MapShader and 18.SplitScreen. They all share the same problem with speed which we need to find out IMHO. The should be at least twice faster at minimum, but checking other examples differences, they can be probabaly and 4 times faster too.

As most of examples on pair (and even a bit better) than even on icore2.7 with inbluid intel card, we kind of expect with RadeonRX those examples be at least 2 times faster than with AMD 1.6ghz (remember that with software mode, they already faster a little bit on our side, meaning that it's not kernel probably slow things down or graphics.library or 2d drivers, but all our top layers like gl4es, nova, ogles2 and co. Which one is unknown of course :(

@imagodespira

Quote:
Are you using the GPU to do the bone calculations? Or are you doing them on the CPU, and then streaming them to the GPU?

Hans