Personally C-7 get's it right. I get tired answering the same questions over and over again. However there are also other factors.

When I was a new user i asked more questions than I do now. When I grokked how C2 works I really spent a lot of time contributing. I found contributing helped me define my understanding more while opening up how other people create solutions.

however as I get older on the forums I see over and over again terrible forms of programming. I see less good ways and more bad ways.

Finally there are just down spikes for forum activity. Give a day or two then the regular flow will be back

Been asked, been answered never going to happen.

However we have been requesting modularity which would go tremendously farther than inside scripting. Although I don't disagree. Having IDE script modifications would be kinda nice, but honestly the behaviours are so robust most of the time it's not needed.

Well whew, with all this discussion going about; I'm going to commit my next project to public progress. And to make everything interesting the game will primarily developed targeting Tegra2 device using CrossWalk compile.

Let's put the mobile performance matter to the test. I will let everyone know what I'm doing, how I'm going about it. I will also listen to peoples suggestions for performance and design improvements.

I'll put up or use my previous website for this.

I'm intruiged by what your doing. Do you think WebRTC, WebGL/OpenGL, WebAudio will be supported?

To me those are the most defining hurdles of going to native. Many of the other parts I feel can be stripped or replaced. The DOM can go, XML parser can be replaced, JSON interpreter replaced, KeyValue Storage can use HASHMAPs all of those won't be too bad. But the keys are image rendering, full audio and communications.

So I'm very intriuged how and what is your renderer. What type of native program is being created. Is it Java, C++, OC.....

Yes I have a question. Your convert is a parse string based conversion. Are you using custom file based comparators?

How are you managing this?

Arima "I don't recall reading about this. How it would work?"

Well The real strength of C2 when it's been compacted to the C2runtime.js isn't the JS it's the API. After the code is "compiled" it's link to the C2 IDE is non existent. There is no reverse enginearing back to C2 EventSheet XML. In fact once "compiled" the result is no different in structure than most other programming languages.

Know that C2's other strength is that the api is mindblowing robust. Unity probably the words biggest engine has nothing on C2 behaviours and plugins. I don't stay and hold my belief that C2 HTML5 technology is great. I hold that C2 IDE and API are fantastic and that in given time Ashley is right; there won't be problems... but they linger for now.

However in the mean time JS code is just code and can be reversed engineered to another language. *cough* Java/C#. *cough*. It is doable. However I think after some thought when I brought the subject up. Is that while all the plugins are converted to compact effecient code and can be convereted without too much trouble. The break down is supporting all the other browser parts(DOM, WebGL, Canvas2D, WebSockets, WebRTC, AdvancedAudio, Controller, Keyboard, Touch, Vibrate, General Browser Features). Those browser parts don't convert to convertable code. Instead the "wrapper" would have to once again write all those browser parts and if your doing that you have practically built another browser.

The big benefit of such a task is the code truly won't be JS anymore it would OS machine compiled. C#Win8, java for Andoird, Objective C for iOS and Mac, C++ for Widnows/Linux.

...

you know what would really be super cool as I was just thinking about this. What if we/I/someone else created a gaming cloud based converter. let me explain the theory.

someone puts up a piece of working code. Identifies the language.

Then the converter attempts to start converting.

When the converter get's stuck; the converter then posts a help request. Posting what piece of code it got stuck on.

Then others can examine the problem and write a solution. This includes a slow way to flesh out the api.

When a solution is given the converter will take all solutions given in a period of time and test the performance. Keeping the fastest and or more memory effecient.

Now the effort of conversion would be a lot of work for 1 person or a group, but what about hundreds or thousands.. That would be a nifty idea. JS has not effect converters to another language. This would be a nifty experiment.

"Yes there is, I have no ability to code traditionally at all."

You got me there big time

huh, I forgot to hit the post button last night.*

Performance can be related to two problems.

A. poor graphical optimization(ie images too large)

B. poor code. Often I find that most mobile performance problems is poor code.

here is a suggestion. Unlink the layout from the event sheet. Run the layout. if your FPS jumps really high. Then your code needs work.

Well I'll chime in on a few commentaries.

Chrome could fine as a wrapper export. The issue is that there are non required bits and there is some structure that needs to be removed. For any browser to work as a wrapper some one needs to go into the source and remove parts of the load. Here is what needs to be removed to start

DOM

requestAnimationFrame

C2 would perform a lot better if both of those were removed. Instead JS runtime needs direct access calls to GPU image buffer rather than having to wait for a valid hertz speed request.

I already suggested letting the community develop a wrapper from an abstraction layer for us to create native wrappers. It was vetoed. Also if anyone wants to create a C2JS converter to another language there really isn't any reason you can't. Accept what it is right now. Complaints aren't going to change.

As for power. If your supporting older hardware don't. You may have older hardware(as i do); however that doesn't mean you should support it. It's callous, but the truth is that mobile CPU/GPU techonology is advancing at a faster rate than desktop. Next year or two will stabilize this. Next year you will have mobile chips that perform PS3 level performance. If that's the case why are you supporting iphone4. The most common iOS version is 7+ at this time. If you know that then you know none of the A4 chips can run iOS7. You can classify all A4 chips and there equivelent Android counterparts as already obsolete. Stop supporting that generation of chips.

Arima

I don't agree with you that all images are LOADED into the game memory upon the game start. Watching the memory profile for the game drastically changes on Layout to Layout. What C2 does is DOWNLOAD all the assets locally and LOADS them into memory at run time. JS does have a Garbage collector as does Java. Java runs Android and there really isn't a problem. it's not a memory management problem. However CJS sucks for memory management and does suffer your statement of loading everything. However CJS is the exception not the norm.

As an answer to performance. I have a game tested day 1 running on my A5 chip iOS device and runs at a smooth 60fps with Spriter working out the tweening animation. My program calls angle 3 times a tick and includes very poor mathematical operations constantly working floating point precision math. I personally gave up with the idea of supporting hardware from 2012 or earlier. Especially with the Tegra 6 and equivelant chips due late 2014 or early 2015.

Personally I think C2 weakest link is that a large multitude of games possibly well more than 50% have a logic FPS at 30. Where as C2 mandatory runs at 60Fps. If your device doesn't run the game at 60fps then the game suffers. I know no matter how much Ash says other wise; it just does. If we could set the logic fps30 properly then even when your game seriously dips or your logic is poor your games would suffer less. But that's not going to happen.

Anyways I'm going to be starting a new game soon where I will be keeping a devlog. The focus of the game will be MP on tablet devices(sorry no phone) of 7"+. I will be keeping progressive updates and let everyone know how performance will be.

Nope. Cookies are local storage set by servers script. However JS can create cookies locally.

http://en.wikipedia.org/wiki/HTTP_cookie

I suspect WebStorage starts with the most common database storage type and then falls back to local cookies.

colin Jones

I wish I had it. I saw the plugin briedly before Cordova had the big website change. Ater that I haven't found the plugin again. However if you email the creator of Sticky Stick for the Ouya I'm sure he can help.

My game hit the developer doldrum because i've been hit by technological limbo on Spriter for over a year. I had thought Character Maps would only take a few months after the first plugin release. not so. But with Character Maps coming around the corner odds are I will pick it up and polish off the game and release.

PhoenixNightly

Dictionary is a Key/Value data storage. The storage system interface is the same as WebStorage, but Dictionary is all in memory. Also the benefit of Dictionary is that you can do Dictionary.asJson and store an entire Dictionary. However Dictionary also works the same as WebStorage Session which is also temporary.

So Dictionary is great for data chunk loading and saving. I use it a lot. When you figure out how to embed a normal JSON string into a C2 Data JSON you can load single level JSON strings into C2. Very convenient.

Custom variables and variable comparison to create an SOL.

Craete a Family with your Sprite.

Add variable to Family called master, set the default to 0.

set your Family var master to 1 for the sprite that is the master.

then

compare Family.master =1

Pint Sprite to Family

and there you go. easy peasy