you can pin hearing object to the sprite of your player, then use it. also make sure it's on same layer, and collisions enabled.

Ashley

imagine this situation - tommorow crosswalk team announces that they are closing their project. what do you do? leave people off with a crosswalk that has loads of bugs / works imperfectly? switch over to some other third party software that will probably get rejected / closed in some other time? instead if you really think about

pushing your software into something that will be used over a long time, doing your own exporters / plugins is a must do (if you ask me). maybe it won't be perfect, but you have a number of developers that are "waiting" for something to get fixed by some third party, instead of relying on a software that they bought and their devs (you), thus being sure that issues will be resolved fast.

also, what i meant before - audio + multiplay + graphics + physics is all you need for a fully developed game. all wrapper needs to wrap is that. main functionality that some OS uses to run the game. all the other stuff doesn't need any wrapping / could be used as external JS (ads, social networking plugins, and so on..)

add effect brightness to both layouts.

then add 2 global variables - brightness and transition

on first layout on layout started - set brightness variable to 100 and transition to 0

on first layout when you want to change layouts instead set this:

set variable transition to 1

make an event that does this:

if transition = 1

subtract from brightness 1

set effect brightness param 0 to brightness (variable)

(subevent)

if(brightness=0) - > go to layout 2

and on layout 2 - set variable brightness = 0 on start

if ( transition = 1 )

brightness +1

set effect brightnes param 0 to brightness (Variable)

(subevent)

if(brightness=100) transition = 0

something like this should work, around 1-2 sec fade, depending on your fps.

AI as a real thing doesn't really exist, especially not in games. what you see there is scripted behaviour. loads of IFs - scripted behaviour - you can learn by time what pc does and beat it everytime.

there's a possibility of adding fuzziness (check fuzzy logic) - where PC could choose sometimes differently then what was anticipated.

the "realest" AI would be neural networking (which you can't really use in C2) - when you got loads of neurons which have their weight and neural links coeficients which multiply and choose the results - therefore loads of possibilities and different reactions + learning - you can update those coef. and weights - making a neural network work better, make pc learn what you do. but this one is a complex model which isn't really yet used on any game (at least i think).

so mostly what you can do is a expert system - check bayes networks or fuzzy logic or just make a loads of ifs where some of them execute if random (0.100) ends up under some X that you put, or random that ends up < random (0,100) etc.. there's loads of possibilities

oh, how do you spawn your stuff on your top down shooter?

even so.. once you hit background 5 (5th section) - you are probably changing somewhere those sections - spawn boss.

also there's an option to make a variable global with number starting from 1, and increasing on each change of section. once that variable hits 5, spawn boss.

first off, you should stop cluttering forum with posts that have their place - crosswalk performance, you could have asked the same question there and get an answer.

now to answer your question - not sure if crosswalk is open source - if it is, it might be possible, but if it's not, they probably have that code somewhere inside, so you can't really fix it. best option would be if someone made a whole pure webgl non browser wrapper that would include all the features from all the other systems that support it.

also memory management + threading + audio + webrtc + multiplayer + webstorage + loads of stuff - if you think you can do it.. be my guest ;D

i think that the problem is both ways - in c2 developers and exporter developers (crosswalk/cocoonJS or whoever).

as goes for c2 devs - we work in an environment that has only events and no real programming, which on export creates two JS files and a bunch of XML from which we can't tell much if things go "as planned", therefore we must focus on massively optimizing the game in our event sheets, setting each sprites/elements/items properties correctly, makin' the game work flawlessly. also there's a lot of code that could be probably better optimized, but it's out of our scope since our env. doesnt' allow us to do so.

on the other hand - we have c2 / crosswalk /etc developers who work pretty hard on fixing bugs and stuff, delivering us new features and performance optimization, but in all their tries there always ends up some code that could be optimized better, fixed, and more, which leaves us hanging around not being able to do so ourselves (if you are in programming lands like me)

the point is - if scirra would waste a year for their nonbrowserwrapper just to bring us better performance, better, well everything i think it would be worth it and they could develop a standard in between all of these other wrappers. even at the cost of employin' a few new devs to help with that. gles.js just shows us that it could be done, pretty quickly and nicely. including other features is just "useless" - you need networking - audio - graphics and maybe physics as separate thing - and you got everything you need for your 2D game.

almost done with the only level there ever will be (for now)....

you will need pretty good PC to play this because of loads of particles, even my 980M gets cramped sometimes.

i was wondering if anyone tried this - http://tmtg.net/glesjs/

it's almost a native webGL renderer for mobile phones, someone might take it over and develop, because it has like 90% less overhead opposed to chromium based crosswalk and supports a couple of features, but also gives massive performance.

Ashley - what do you think about this one?

tried linear sampling?

for every x seconds

- repeat random (y times)

- spawn (create) object (or family of objects - will pick randomly from family) at layer nameOfLayer, x (random 0, layout.width), y (random 0,layout.height)

sorry for late calling, was busy with job and had some pc trouble with SQL mang. studio and visual studio, had to reinstall pc and stuff.

anyway development is going nicely - loging in and registering is working nicely, now i'm going to hit the big parts - adding mods, removing and download/installing.

also i will include a parser that will parse through your files and fill relevant data. soon more to come, hopefully i will have working examples in a couple of days (week or two).