tunepunk's Forum Posts

  • A little update.

    Creating the whole map in Maya works, but exporting the whole map with textures included seems to be a bit tricky, as the whole map with buildings, rocks, plants and everything counts as one object, so the whole map has to use one massive baked texture, it seems. If don't do like this, editing the map in C2 is a pain, and i can't bake the Ambient occlusion shadows, which is pretty crucial for the feeling as I don't want a completely "flat" world with no contact shadows.

    So now I have to chose.

    1. Export all objects seperately with no baked shadows. (easiest but looks very flat, and tricky to place all objects in C2)

    2. Export objects separately with AO, (a LOT of work to place them precisely at where they would contact the ground)

    3. Export the whole map with one large texture map... Maybe i would need a texture size of 4096x4096. or even greater, so I don't know how well this would perform on Mobile, or if it will look good.

    No3, is probably my preferred option, but not sure how it will perform or look, so I have to try it.

  • +1

    Construct desperately needs a proper way to parent/child objects to other objects. It always boggled me why there is no such thing already. In C3 there is a new container option called wrap, which will let you EDIT sprites somewhat like you describe, everything scales according o the wrap. Why this wrap does not work in code is a mystery. Lol. Pretty useless option when it only works while editing, and not when modifying the container object with events. Rotating, moving or scaling the main container object in events does nothing to the "child" objects. *Sigh* except for create and destroy.

    If you rotate, move or scale the parent object every child should follow. Construct desperately needs an easy way to do this.

    But I don't think we will see this until skewing, perspective and other kind of deformations are also allowed on sprites. Maybe after runtime hopefully when some arbitrary 3d deformations are planned as well.

    I might add: .. or don't have time to develop using traditional coding, since the event system is way faster.

    Yeah that too. I think the main selling point of Construct is the event sheet. Everything else is secondary. That's why we are all here. From advanced users to beginners, it's comprehensible and easy to use, yet pretty flexible. Maybe not the most powerful, but it gets the job done quickly, without too much headaches. I've tried coding, using state machines and other methods, didn't even get near creating anything resembling a game. Lol..... For me the event sheet alone is Well worth a sub in my opinion. Without it I probably wouldn't be making any games at all.

    I don't think they are targeting "serious" developers. I'm assuming "serious" means indie or more professional?

    C2/C3 is clearly built for those who don't have any prior knowledge of coding but want to get started with games. How serious people are is not measured by their coding ability. C2\C3 is just a tool like any other, just specialized for those who don't know any traditional coding language.

    It's targeted to solo/duo/very small teams who want to do games without any prior coding knowledge. If you already had a coder in your team I'm pretty sure you would chose another tool unless you really looking for the ease of use of the event sheet.

    "Professionals" (if you meassure it in code ability) their javascript coders could be attracted if they felt that making their own plugins gave them enough flexibility, since construct is pretty much built around the event sheet with no other way to input code. So the attractiveness for professionals is probably more relying on what the SDK/runtime will allow you to do.

    Just look at plugins like Q3D and Babylon, all the rex and rojo plugins and others. A good coder can extend the use of C2 dramatically. The average Joe here, no. Most of us probably chose Construct, because we don't code, not because were not serious about our projects.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    If someone is still using CS6 for their artwork because they don't want subscription and don't need certain new features and don't want to be locked out, that's fine.

    So what's stopping them from still using C2 then? Nobody is forcing anyone to buy C3. C2 would be the equivalent of CS6. And C3 would be the equivalent of CC. C2 is still a viable option for people who don't want to pay subscriptions. Why do you have to use C3? If someone really need or want the features in c3 why not just pay up if they feel it's worth it, if not stick with c2.

    I'm have both Adobe CC, and Autodesk Maya subscriptions as well, because I feel the upgrade is worth it. I could still use older versions but I don't want to, because I wouldn't get the new features. I prefer to have a subscription with regular updates, fixes, new features, and extended support. Something I will never get on the older versions.

    If you don't continue pay subscription, you are locking yourself out. It's not Scirra. You can resub any time you want, or need to edit you projects. I don't see the big deal about this.

    Would I lock myself out from my Maya and After Effects projects? Yes.... I do that all the time, when I know I'm not going to use it for a while. But when I do need it again, I just resub and I can continue where I left off, and I automatically get the latest versions.

    ***Trigger warning***

    Reading through the thread again I just get the feeling people don't understand upkeep and the costs of continued development by moving c3 online and adding online build service, or is just ignorant, or stingy. Like there's a lot of people who want C3 to be an all you can eat buffet just like like C2 with a one time pay. If you fall in this category, please consider to continue to use C2 instead, it's free for life and one time pay. The rest of us who believe in future Scirra products and want to support new features, upgrades, bug fixes can show our support by subscribing.

    I already got about 3 years of free upgrades, support and bug fixes in C2 and I feel it's about time I chip in again. Even if I don't use C2/C3 daily or professionally I don't mind chipping in yearly, because I really enjoy using this software as my hobby, when I have time.

  • Photon cloud is very good. Try it out. Very easy to use

  • To me it sounds like the blend mode for the lights or some effect. Tried to disable layers with blend modes? you mentioned you have a huge black sprite covering. I would probably think it's something related to that. Have you tried enable use render cells on some layers?

  • Check the project settings if you are using point or linear sampling.

  • It's possible to make a 3D html5 game for mobile in construct with the plugin he mentioned. I'm doing that at the moment. But you need to be aware of the limitations of phone hardware, so you need to be smart when how you build your game. No complex shaders, no realtime shadows, not too many lights, etc.

    And also, you need find a way to work in the editor. Since Construct does not have a 3D viewport, it's a bit tricky to build your levels, but it's doable.

    "improve the engine significantly for serious developers such as storing object references, lists , SOL's, Arrays, in object variables, and building prefabs of objects in a general class based system rather than having to rely on the botched container and family features that always wind up requiring weird work arounds when structural changes have to be made. Instead we're encumbered with the overhead of storing UID's in other objects and having to a search over N objects every-time we want to make an object reference, so even building prefabs, constructors/destructors in events carries a severe overhead. The event engine/SOL system is great, it can be used for rapid prototyping and really quick development, but it needs improvements to actually be usable for performant code in a large game.

    Even as a hobbyist the subscription model doesn't really bother me. Take up any other hobby, and you usually have a club membership fee, gym card, renting place for your band to practice, etc. That they are going from a "free updates to for life" model, (which is a very stupid business model, in terms of securing income their continued development) to Yearly fee is a wise decision. But on a personal note, I would rather have that they would have some kind of IAP model, where you buy features, plugins, and behaviours based on your need. I think that's the way the free versions engines like unity stay afloat. Lots asset packs and plugins in store. Scirra's store selection isn't very big or great though. But considering that they made the decision to go for an online tool (which has running costs) the last thing you want is too many free or one time pay users, if they are not continuously buying assets or plugins either.

    Although I do agree on some points above. I absolutely love the Event Sheet way of working, but I also feel I have to rely too much on inefficient and weird workarounds in some cases, or third party plugins to do some simple things, like raycasting and tweening, custom SOL lists etc. I absolutely agree that they should consider spending more time on those kind of features you mentioned. I'm quite hopeful though that once C3 matures, and after new runtime they will have more time for that. I'm patient... i will support C3, but my main projects I will do in C2 until C3 matures, and get a bigger plugin library and more features.

  • Inserting and deleting elements from an array is O(n) since it uses contiguous storage and has to shunt along all the elements after the affected index. However adding and removing items from the end is fast, because there is nothing else to shunt along. If you can rearrange it to only modify the end it should be faster. Another technique is if you have a fixed size array you can cycle through the same set of elements without inserting/deleting anything (i.e. a circular buffer).

    Dictionaries have per-key storage which means nothing else needs to be modified to add and remove items. Arrays are usually faster if you need to iterate them or do lots of random access, but inserting/removing anywhere apart from the end is usually a pretty bad case for arrays.

    This is all standard computer science stuff, it's the same in pretty much every language.

    Thanks for the info Ashley. I did not know that adding to arrays att back would make that much of a difference. But in this case, where I constantly need to update a kind of custom (SOL) list of UID's it seems dictionary would be better, as in an array, i could be deleting an entry anywhere in the array... and whenever I delete an entry it has to update the the array.

    In this particular test I will be deleting any UID entry that is outside the radius of 50 pixels.

    I will make a mental note, that I should always add or delete stuff from an array from the back if possible.

  • I did some optimization tests to understand a bit more how to improve my performance on some projects. I couldn't figure out what was wrong so I made this test to see what it was.

    I wasn't looking for this but It seems arrays has a lot more overhead and way slower than for example Dictionary. Check out this example to see what I mean.

    Here's a link to test project.

    https://www.dropbox.com/s/yhikh6nqdsy10yk/array_overhead.c3p?dl=0

    Even a simple 1 dimensional array is much slower than dictionary. Does anyone know why this is the case?. It doesn't use more or less cpu, but seems to lag a bit compared to Dictionary.

  • I would think picking by instance variable would be the most efficient.

    I thought so too, but picking by instance you still have to check through all of the 5000 sprites for that instance variable. By loading all the previously picked in to an array or dictionary, you save your self a lot of work if you need to pick them again.

    Too bad you can't add or remove objects from families in runtime. That would be awesome.

    My next project is to see if I can keep a low/constant pick cost even with 10 times the amount of sprites, in this example.

    Picking CPU usage scales with amount of sprites you check through every tick, so I'm trying to figure out low cost ways of doing picking in large scale layouts with high object count. Smart way of shortlisting the picking.

  • Thanks for your help guys. Some nice solutions there. I wanted to try different ways of picking in a high sprite count environment 5000+ to see what was most efficient.

    Seems like dictionary and behaviors is the winner after all. In case anyone has something even more efficient.

    Here is a link to capx with some of my tests:

    http://tunepunk.com/share/scirra/pick-optimization.capx

    Ethan the plugin by rex was amazing. I might use this the future.

  • Is it possible to pick multiple objects by UID using a string, JSON or something similar instead of using a loop?

    And can I create a string of multiple UIDs, which I can use for picking? I'm trying to limit the amounts of loops I have.

    I don't want to use for each - then add them to an array.

    Then use for each X element of the array to pick them again, as I'm doing at the moment.

    Any ideas how to go about that, and is it possible?