russpuppy

Thansk for the fetchapp link. I'll use that myself. At the moment I'm using by devlog site as my store site. More exposure the better. Good fortune. I hope in the long run it pays well enough

I find that lot's of dev's use 1 object per game button, 1 object per bullet type, 1 object per enemy.... so on etc. In the end they have around 200 objects and at any one time they may have 50 different objects.

Where as if all the buttons, bullets... small stuff were in 1 Sprite used as an atlas using animations and frames. that would be better.

As for more robust stuff. Well if you have a player with 5 different animation types and many frames per animation. It might be easier for development reasons to to just have the player have there own entire object.

I have been enlightd towards mobile development. Even older hardware say an iPhone4 should be limited to 25apx draw calls. So of course if each of your objects on the screen is there own object then your going to hit and pass that fast.

TiAm

That's really interesting and that shouldn't be happening. Ashley mentioned before that a Sprite should be rendered as a whole. Though I have a question. Did that include Z-sorting and layers? I would assume z-sorting and layering would increase draw call in any circumstance.

All right so I did a simple render test. With unique but stable results. These are done with 1 sprite object. 10 objects are created providing creation allowed. Creation is allowed fps < 30 up to 100 time. The reason I chose this was because of how GPU handles rendering dips and how often and when they become extensive. This doesn't mean a MAX limit.

1. Performance is better if your UV size or in our case Texture sizes stick to the power of 2(2,4,8,16,32,64,128..)

2. On Preview (rounding to nearest 500)

1 Frame displayed on the object. Made it 11,500 after 10 tests.

Random Frame on object. 6000 after 10 tests.

3 On export

1 Frame displayed on object. Didn't test because this is about atlas testing on export.

Random Frame on object 9500 after 10 tests

Interestingly enough that on Export the performance increase by %45 where the GPU had less troubles.

However other factors I found out. When given the unreasonable usage of just constantly creating objects. C2 CPU will become over burden rather quickly. I suspect this has to do with the JS storage object. But it's not important because your not going to have 5000 objects on the screen. but it's interesting to know that C2 CPU usage will hit 100% before the GPU hit's limits.

So with this information. It might be best to actually create games based on the idea of an Atlas sprite object. Of course these will only count for sprites that live on the same layer.

My question is now answered. It is best to use Atlases as much as viably possible. So all widgets, small objects should share 1 object. And let robust stuff have there own sprites.

I appreciate everyone's input. I wouldn't mind Ashley's thoughts on the entire subject to.

That seems to be the case. Going to have to do some kind of active performance test. I don't actually have a performance problem as of now. I'm just thinking that if this is the case where the export atlas can get better performance. Then that would have considerable changes in how the game should be structurally designed. Making a large change to fewer atlases later would be a big job. Where as designing around this from the start would save a lot of effort.

Well time to work on a test

R0J0hound

Thanks that clears a lot up. So I suppose then the part that could use some final clarification.

" However on export C2 creates texture atlas' of the frames if it can, so then it may take only one call. To be more exact about a draw call, it is only done once per frame in webgl. Everything else is just sending info to webgl to use when the frame is drawn."

So because C2 creates a texture atlas. Could or does this happen. Can the export receive better performance improvements if the atlas was larger. I'm wondering because would it be better to design a single sprite as an atlas sprite and then use invisible game objects to handle game logic.

I do get your point. If the sprite breaks the image into more memory blocks then that's more calls. Where as if the sprite were to drawn with more advanced UV coordinates off using a larger memory coordinates could reduce draw calls could improve performance.

Fimbul

In regards to levels. R0j0hound made a plugin that does a good job of saving a Layout's object. While C2 can export a scene to JSON I found the result file to overkill. So using R0j0 plugin you can use C2 as a level edit, run the level, and get the the plugin string export to save to file.

Aphrodite also has a good solution too. Also if your using Tiles you can use Tiled. The SDK isn't impenatrble. I've used to make a photon multoplayer client.

Also the SDK allows you to render to game world. So you could render special information like pathing trails if anyone were to write a node based path system. The SDK also let's the dev to implement various Inspector options, values and so on. However, it would be really nice that the SDK let have more GUI control in the editor. Like new windows, rendering options to create say curve based value control. Ways of putting in the editor colour control for editor functionality.

I'm just arguing on the point that there is a block to making big games. In fact this thread inspired and a the gajillion zillion down load thread inspired me to devlog on my mini multiplayer online game. The link is in my sig. Because let's see if we are really bound. Although you should check out Penelope and Our Darker Purpose,

Ashley or anyone who can effectively answer this question.

There was a discussion not to long ago about cloned objects, rendering he "same" image when they are different memory references. So I wanted to know some more technical question in regards to C2 rendering logic and a single sprite object with multiple instances.

I admit I could be fuzzy on this. So please bear with me

At the render time when C2 renders the object. The image is moved to the render pipeline. If there are numerous same instance of the Object then C2/WebGL makes 1 render call based on fill rate. So 1 call draws numerous images on the screen.

Now what if it's 1 sprite object, but with numerous frames or numerous animations. When rendering the 1 sprite object, but has numerous instances set at different frames; are all the frames image put into the pipe line. If so does WebGL/C2 only make 1 render call still because it's only 1 sprite object even though it is multiple instances set at different frames?

Katala

Well if Functions and Array were simlar primitives in C2 then that would be over all beneficial.

Instead of Array.ValueAt(0,0,0) or even worse if your using instance arrays

Compare Array.id = "arrayname" to get a specific array in an SOL to use.

you can just use

array[0,0,0] in your expressions. which is the way all programming languages access array data.

or

array[0,1,1] = some data

same with Functions

instead of

Function.call("functin name", p0,p1,p2)

it would be

functionname(p0, p1, p2)

In expressions the variable name is in expressions list. This makes using variable names impossible to use if you spell them wrong. The expression won't let you exit unless the var name is correct. Where as Functions require you to use a "string" paramater. So it's possible to use the wrong string name. Also when you change a variable name the change is caries over through the rest of C2. Where as in Function that's not the case. If you change a Function calling name you need to go manually change it everywhere.

This would also lead to better scoping of functions.

I constantly get logged out after apx 20-30minutes

Yes it's possible. Data and rendering are not linked. The MP Plugin is a global object so connection remains between C2 layouts.

CocoonJS as of 1.3 should have full AJAX support now. CrossWalk is just Chrome so that should be good to go.

You can either roll you own which there is a tutorial supporting or you can go with Clay.io.

Great for asking, but if I may offer some points.

I find some questions asked to Ludie having nothing to do with Ludie at all. As an example 9Patch is a way of rendering sprites. Ludie only provides sprite rendering. it's up to us to figure that out. If 9Patch isn't working it's Ashley who needs to fix that.

As for Audio it would have been better to ask about Web Audio rather than the current bugs. The current Audio system only uses the standard HTML tag style of playing. Where as the Web Audio version supported memory control of the audio for more robust features.

as for ads. That's an AJAX thing. They say they support AJAX calls as far a I know. However they need to support it in there plugin, which they don't seem keen on doing.

Now the big thing to hear is the Plugin feature. If this is the way it goes this could be fantastic for us. If we have an Audio bug, maybe we can build the bindings to the native layer and use WebAudio api calls. We want WebRTC on iOS and Android with CJS. We can use the WebRTC standard calls to Android and iOS native libraries. We don't need to wait for Ludie to do them.

It's a lot of work, but some one will get it done. I think what we can from this is that while they aren't going much forward on their own. The Plugin system if indeed allows us access to lower level libraries could be a massive benefit.