jayderyu's Forum Posts

  • "From what I understand, draw calls are made only for visible objects ... So I can make the logic of my game using more invisible objects and use only 1 sprite with all the animations for the visuals."

    Yes. but that's what you were asking at the top. Which is better.

    A. Better for performance

    B. Better for object type management

  • Top one. It's worse to manage, however it's mandatory for performance. Each different sprite object is a different packed draw call. WebGL draws in batches based on the texturemap created by C2. Each Sprite get's a different texturemap. If for any reason you go from map A, to map B then the system needs to unload mapA then load mapB. Now that's fine. however what happens if your doing lot's of different layering with different texture maps. That means WebGL will go from

    ABABABABABAB

    which means 12 draw calls here. that's low of course, but think abuot many objects like bullets.

    where as if you use a single sprite then you just get

    AAAAAAAAAAAAA

    that's one draw call.

    of course if you layer properly you can do

    AAAAAABBBBBB

    and run on 2 draw calls. But now management of layering is on you

    Of course you need watch things like 2048x2048 is the max texture size in the safe zone of devices.

    top one is better

  • I never said difficult, I said "heavy" and that's in regards to base overhead. However it's un-intuitive, not impossible.

    This blog is awesome to know the nitty gritty <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">, I got the function call methods from your blog and plugins as you had already managed to do so; so using your basics just saved me time.

    http://c2plugins.blogspot.tw/2014/02/reuse-ace.html

    However I did make a mistake. It's Call or Bind, and no need to use both.

    Also it should be. My error, i was workign off memory. I started building a SDK lib to make life easier, and didn't recall the exact method.

    prototype.function.call( memoryobject, params)

  • It's doable now, but it's more heavy stuff. The process requires

    get prototype object

    get memory object

    prototype.call( object.function, params ).bind( prototype )

    you also need to get the memory instance here and there as it seems just grabbing the object once will fail on a different function.

    where as to use the system as a standard sdk

    object = getObject

    object.function( params )

    Guess we will see what comes about in 6+ months.

  • I have a plugin that does what you ask. however since there is no IDE way to inject code into the original runtime.js, this leaves all extra code running on the VM. And the VM is slow. Also even if you did use code. The C2 API isn't built for ease of use. The sdk is just clunky. In the mean time your pretty much going to have to use the SDK if you want your code to run optimally.

    newt

    To be honest the SDK is a heavy weight to implement, with little beneficial returns. It's not "hard", it's just intuitive, restrictive, overloaded with "add" functions. Where as usual Plugin design don't require such heavy use of adds or definitions. They often just need to fill out abstract function names and light registration. There are definitely better ways to handle the entire SDK system. However you are right. Due to having no way to get code in properly(post export code insertion only). There is no other viable method to get code running.

  • I'm a Unity programmer for the company I work for

    I use C2 for my company and my projects(which doesn't get much tie do to the company I work for and family)

    To put it simply.

    For 99% of the 2D games I would make. I would use C2. I can create A Unity 2D game in about 1/3 the time.

    Having said that. I agree with another opinion here. Going to the SDK is a pain. The SDK is ironmaiden bound in limitations, and that means dangerous to use with lots' of spikes, and it's heavy. very heavy. it's not very clean to use and due to the limits code sharing(store or other wise) is annoying to implement into other projects.

    I like Unity, but I prefer C2. The ES system and the C2 api are astounding and to me outweigh the negatives.

  • Somebody

    To a lesser extent you could do this. Threading would be of good use for procedural terrain generation. Background rendering to it's own CTX canvas then sending it over at say 30fps. There is use, but as you point out non of it on the logic layer.

    Might be an interesting test at some point.

  • Jayjay

    I just want to add something to your list. It's good in the order, but I want add this because a lot of people tend to gravitate using Unity or GameMaker as C2 optional alternative.

    Unity

    Exported Game

    OpenGL/DX

    Unity libraries that don't always meet C# standards(we have had basic classes of C# not work on mobile)

    Unity Player

    OS

    Drivers

    Hardware

    unity Player is I found anywhere from 5mb to 15mb in size. It's packaged with all Unity games. Unity does not seem to output a pure game code system.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • anty21ro

    It would be easy to just throw in other ideas from other engines. That wasn't really the goal to remake another engine. The idea is to get to the founding root of the IDE so that people can make any tools they need. If these tools 1:1 reflect other engines such as UDK then that's fantastic. We know the core design can do what's wanted. The industry has refined a lot of tools at this point.

    However saying that there are a few features that are insanely good for work flow that are from other engines. Such as file journaling for auto updating, prefabs which focuses on maintaning good design optmizations and allows complex objects and others from both UDK, Anarchy and Unity. However they are far and few between. Mostly was to keep to the current C2 architect and re-work the design system to make making games easier, and easier to maintain higher performance games rather than falling into the massive, but invisible poor performance pits(ie every enemy type has it's sprite, every button is it's own sprite, every bullet is ist's own sprite.....).

    As for Legends, that's a lot of custom tools at UbiSoft. And the idea is to allow C3 users to create tools as such, not for Scirra to make the tools themselves.

  • Can you provide a capx that is suffering performance problems

    Can you provide an exact model of your phone. Your phone GPU maybe black listed... which is an annoying problem.

    I haven't played IB3, but I did play 1, but I know in IB1 there are usually only about 3-5 moving objects at any one time. So most of the overhead is put to GPU rendering. So as long as your GPU isn't black listed there usually isn't too bad a problem. Or maybe the phone is old and just can't handle the browser overhead.

  • Everade

    That's in the documentation as a Prefab, it's the only Unity term used. It's also appropriate as it's the for word for "Prefabrication".

    Prefabs are a wanted feature, and personally I feel better than just Adding more Sprite types.

    I know what Ashley says, but there are two key points

    1. The core run time is going to remain the same. So limitations in the rumtime will effect final features.

    2. Best is subjective to what Ashley sees as the best and right way to game design. However some times those views aren't industry standards, and inefficient game design. As examples, Sprite Object instead of Sprite Behavior(which uses image atlases). Behaviors attached to every single instance of type, where as behaviors are best attached on a per game object.

    So all we can do is see how C3 turns out. I'm hoping for the best, and I'm hoping C3 will be the best. But that requires flexibility and responsibility for the SDK community developers, rather than Scirra determining the best way to handle everything.

  • 1. node webkit, nothing more and nothing more is to come by the Scirra team.

    2. It's getting better, but personally I think R0j0hounds chipmunk plugin is better.

    3. Every product will have disatisfied users.

  • kmsravindra

    I have not have had a performance issue with C2 on mobile as of yet. However I have seen many projects developed poorly; including in ways that would hit Unity. However to be fair the intuitive way C2 promotes development is poor performance. That's why a number of suggestions in the C3 architecture offer a different development model that would allow for easier to development good performance apps.

    Azu

    Sorry. The doc isn't a feature request list. it's a low level architecture request. Suggestions and design models that would allow for improvement in game development; not so much exporting. that's why the request is for custom primitive objects and not for the curve object itself.

  • kmsravindra

    I am also working on a second game that makes heavy use of Spline paths for pathfinding and movement. So I'm so totally into your request. I made a path node capx, but without the edit time tools for easy creation it's a pain to work with. I have a runt time editor that make it's easy, but integration into existing capx is not very fun.

  • umm. nope. Unlike traditional programming where return prematuraly exits. You best bet is to follow the other function design.

    function()

    if{ do stuff }

    if{do stuff}

    function end

    make sure anything you want to do is in a conditional statement and let the function run it's course.