WebGL game Atlantis

Hello everyone!

It’s my first HTML5 game created by me and my friend (artist) with Haxe+OpenFL, powered by modified Away3D.
I must say that programming under Haxe and OpenFL gives me much more pleasure than flash :slight_smile:
This is casual zuma-style game written for facebook and some Russian social networks.
It is not finished yet, but playable (music and some features will be added soon).

So, facebook link is HERE, but note that to see the game you MUST be logged in to Facebook.

Or, if you don’t want to use Facebook, you can take a look at the “local test” version of this game THERE, but in this case game will not connect to our and facebook servers, so you will NOT be able to earn coins, save your progress, see your friends on the game location, etc.

It’s designed mainly for desktop browsers and landscape orientation, but still playable on modern phones throw browser or social applications (facebook mobile version is not ready yet, but you can try “local test” if you want).

I will be very grateful if you tell me about any problems that you may encounter on certain devices. For example, I still have no opportunity to test the game on MacOS.

Some information about quality settings:
5 - full resolution (except devicePixelRatio is bigger than 1), full sized textures and hardware anti-aliasing;
4 - same, but anti-aliasing is disabled (i want to note WebGL AA is switched “on the fly” :stuck_out_tongue_winking_eye:)
3 - 85% resolution, texture sizes reduced 2 times (512x512 -> 256x256)
2 - 70% resolution, texture sizes reduced 2 times
1 - 55% resolution, texture sizes reduced 4 times (512x512 -> 128x128)
0 - 40% resolution, texture sizes reduced 4 times, for slow machines…
I found that the game on my old laptop lags on “5” quality, but work pretty smooth on “4”, and for my cheap phone the best value is “2”, so game still looks pretty nice on small screen with this quality.

The aspect ratio of the internal 3D scene (not GUI) should always be in range 4:3 - 16:9 (it’s designed only for that range), however game aspect ratio is limited by 1:1 - 2:1 range (it looks not so ugly if internal scene just stretching a little).

Sorry for my english :slight_smile:

11 Likes

Great job! It looks very polished. I am excited to see a project like this running in Away3D :smiley:

2 Likes

I didn’t expect to waste so much time - I was searching for my own issue. Came across your post and WOW… sooo much polish! And it was fun! I think I played for 10 minutes when I really didn’t want to waste time too!

Congrats! Amazing job.

1 Like

I’m very impressed, wow.

I’m new to the community but not Flash and AIR and man, I would love to be able to do this type of 3D in the browser.

Do you have any pointers to Away3D that gets started with OpenFL?

It’s easy to start with Away3D and OpenFL :slight_smile: Just install Away3D to haxelib by following the instructions HERE and away3D-samples from HERE. There are many good samples for Away3D, just try and experiment with them :slight_smile:
For starters, this will be quite enough.

Note, that Away3D is designed to be universal 3D-framework (you can create just a website with simple 3D features, or a whole FPS on it), so since it is opensource and very friendly-designed, i found that it very useful to modificate framework for your own needs to optimize your game performance, when you get familiar with away3D internal algorithms.

The only problem I encountered is the lack of active support for 3D in OpenFL (in particular, Away3D), since there is not so many people here is using it. I also found some minor issues in OpenFL, which caused wrong behavior of Away3D sometimes, but it seems that I did not manage to interest anyone else here with it yet :smile: But, as i said before, since Away3D and OpenFL is really easy-to-understand(-and-fix), I even enjoyed troubleshooting, it didn’t cause any serious problems… and gave me a lot of experience and fun :sweat_smile:

1 Like

Yup that is some examples for sure.

So who is using Away3D? pardon my ignorance here. :slight_smile:

I am just curious as to the development state of it, since you are using it, I am asking.

Away3D was pretty popular on Flash some years ago and became quite a powerful project with it’s own community. So, it is complete mature framework, which latest version is available for OpenFL :heart_eyes: In my opinion, this is one of the best 3D frameworks (firstly, for flash & html5 platforms), which is quite flexible and allows you to get a good results in harmony with OpenFL, if you are not afraid to dig a little into it.

P.S. I found that write in English there is much harder for me, than working with Away3D :laughing: But experience is always great.

1 Like

I can understand just fine. Thanks for the information!

Is this the one?

I just added a patch now https://github.com/openfl/openfl/commit/7a16a79be0879eaa88ec25b49d688e56d314438e

Yes, this is the one.
There is also remembered issue in AGALConverter, which (as I can see now) goes from HERE. It was bad idea to allocate length of 128 for each array of vector constants. The problem raises when you are using skeletal animation with AGAL (for example, common simple AWD animation in Away3D). The animator transmits to AGAL several matrices (for each bone) in the form of an VECTOR_4_ARRAY, in AGAL it looks like one big array of Vector4 with max length of 128, but after conversion it becomes a several separated arrays of Vector4 for each matrix, each of them with length of 128:

uniform vec4 vc13[128];
uniform vec4 vc14[128];
uniform vec4 vc15[128];

The problem is especially nasty because some desktop browsers do not follow the strict limitations of webgl and works fine with it, like mine… So at first I did not notice the problem, until some my friends reported that in their browsers my game is crashed with “Too many uniforms” error.
It took me quite a lot of time until I found the reason of this crashes, thanks to the fact that mobile browsers follows the limitations and the game didn’t work on all mobile devices i have test it.

I don’t know the correct (elegant) way to fix it, but for most cases it’s quite enough to count vector arrays and then split the limit of 128 to all of them (for current shader program, of course), like this:

… else if (entry.usage == RegisterUsage.VECTOR_4_ARRAY)
{
sb.add(entry.name + “[” + Std.int(128 / arraysCount) + “]”);

where arraysCount increases each time when adding new register to the map:

if (usage == RegisterUsage.VECTOR_4_ARRAY)
arraysCount++;

I wonder if AGAL has a way of numbering how long the array is expected to be… perhaps it has to do with the register number? If a VECTOR_4_ARRAY has a register number of 4 and the next register is 8 then it should be an array with a count of 4?

Away3D uses code like this:

dp4 vt2.x, va0, vc[va3.x+13]
dp4 vt2.y, va0, vc[va3.x+14]
dp4 vt2.z, va0, vc[va3.x+15]
mov vt2.w, va0.w
mul vt2, vt2, va4.x
mov vt3, vt2
dp4 vt2.x, va0, vc[va3.y+13]
dp4 vt2.y, va0, vc[va3.y+14]
dp4 vt2.z, va0, vc[va3.y+15]
mov vt2.w, va0.w
mul vt2, vt2, va4.y
add vt3, vt3, vt2
dp4 vt2.x, va0, vc[va3.z+13]
dp4 vt2.y, va0, vc[va3.z+14]
dp4 vt2.z, va0, vc[va3.z+15]

so after conversion it defines like this (with my splitting):

uniform vec4 vc13[42];
uniform vec4 vc14[42];
uniform vec4 vc15[42];

I can’t see easy way to know the length of this arrays there :frowning:
In this case, array length equals count of skeleton bones (not the matrix size). So, vc13, vc14 and vc15 is a parts of one big AGAL array with length of 128(-13, to be precise), and so, splitting looks quite suitable in this particular case…

Reading Adobe’s documentation I get the feeling that they would pick a hard-coded number for each value. The matrix of profiles clearly supports 8 or 16 or 32 or 200 (etc) of each parameter type. I wonder if we just need a lower limit?

I wonder if 32 or 64 would match Flash’s behavior and stay within reasonable limits?

I think a lower limit would not be a universal (i mean - less universal) solution, cause some programs can use many small arrays with (+13, +14 etc.) values, so in GLSL we can get something like this

uniform vec4 vc13[32];
uniform vec4 vc14[32];
uniform vec4 vc15[32];
uniform vec4 vc16[32];
uniform vec4 vc17[32];
uniform vec4 vc18[32];

and “Too many uniforms” again. Moreover, with splitting in this particular case i can use 42 skeleton bones (with 2 joints per vertex), limit of 32 would be a bad limitation in this case.

AGAL limitation is 128 vector constants, no matter is it vector array or single vectors. 128 in total. The problem is in converting to GLSL uniforms, we do not have the opportunity to know how these constants will be used. Or maybe i missing something…
That’s why Away uses “13, 14, 15…” - it’s offset after single vectors. They are included in this “One Big Array” of constants :slight_smile: vc13 = vc[13] in AGAL, and there is no other types, only single vector. Converter splits it to many single GLSL uniforms with different types, like vectors, matrices, arrays… So, the length of this arrays is a mystery (as i see), we only know that summ of all the constants (vcN) is 128 for one shader

Do you mind doing a pull request? I’m okay with the change