Colludium's Forum Posts

  • Ruskul, i agree fully. The problem we have is the multiple choice physics leaves us with a "one size, fits nobody" solution. Since cocoonjs support has been deprecated, let's remove its physics option as well. That should free up the normal and emscripted box2d to add the large number of missing features. Hurrah!

  • —, I tried this a couple of weeks ago on my laptop and its performance was almost identical to box2d web (and asm.js - Ashley and I disagree on the latter's performance hike).

  • Bullet + bounce off solid sounds like a good option. Fingers crossed....

  • Sorry, dude, I don't know of any way to optimize it to make it work in C2. Using Corona SDK I could get a couple of hundred physics objects all bouncing around at 60 fps on my samsung s2, so I think your only option would be either to go native or to wait a few years...

  • I think thats quite a difficult thing to do unless you dont mind having some really wierd shaped asteroids. Maybe reach out to Colludium who might share his physics object connecting secrets

    Thanks for the vote of confidence!

    CrudeMik, I'll help if I can - I will ask some questions as we go... The most important question is do you really need to use physics for this? The native box2d web, asm.js and also r0j0's chipmunk physics are all very good at letting you create simple joined shapes with a few objects linked using distance joints or limited revolute joints. But, as soon as you exceed about 10 connected objects then you almost invariably end up in a land of joint fighting and exploding object groups!

    IMO, up to 50 objects might be possible using C2 in zero gravity, but there would be serious limitations to how that group could interact with other objects in the layout; the fewer the better for consistent behavior. As soon as something bumps into a large group like that then the you run the risk of everything falling apart (a problem that is exacerbated on older hardware - it's worth seriously considering allowing the behavior to appear to slow down with an fps drop rather than let it compensate - fixed time steps rather than framerate independent could be the way to go).

    All of this is probably not just a limitation of c2 and probably applies to most other 2d game physics engines. My Dynamic Sketch Book game joins objects of low mass and low restitution by using lots of distance joints - I found that limited revolute joints were too prone to fighting, and I also found that external interactions with the new group were not good (prone to cause the group to explode). Zero gravity is less stressful on a large group, so you might get away with it if you're careful.

    It's also worth considering if you could get the same effect by making all of the asteroids immovable physics objects and just have everything else in the layout move around them... Then you could have amazingly complex shapes with no interaction problems!

  • I can only think that maybe it's worth trying cocoonjs physics. Then again, if you only have one physics object, why use physics at all? Unless you mean one movable object and a few fixed objects for it to bump into, which ups the object count. I gave up trying physics on mobile after doing some perf tests to compare Corona SDK (lua - native) with wrapped JavaScript on a Samsung S2 - there was no comparison...

    So, to answer your question, is there a way to emulate physics behaviour for your one object (make it fall - use bullet behaviour or just move it using events)?

  • ....Paster...

    How did I forget to mention this?!

    I would also like a way to adjust the rgb on a sprite NOT using webgl.

  • May I suggest you try the 'How do I forum' for these types of questions. For this problem, just search the tutorials for how to use web fonts - that's the solution you need (although, IMO, sprite fonts are better).

  • Full Box2d Web physics, instead of the current physics setup which is limited like a demo version.

    Spritefont+ made native.

    A Tween behavior like LiteTween.

    The tilemap object could do with a scaling option in the editor (for hi res upscaling), but that's just me....

    There's not much else I think is deficient with the current C2 setup - most limitations I encounter are to do with my imagination rather than the power of the engine.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Since one of the many strengths of C2 is the wide selection of 3rd party plugins that are available, I would consider it a weakness if C3 will be able to open old C2 projects but not any C2 3rd party plugins. What would be the point? I am not aware of any serious game creators on the forum here who doesn't use 3rd party plugins in their C2 games - I would be happy to be proven wrong - so no 3rd party plugin compatibility would essentially make C3 a completely new editor.... In which case, why let any C2 compatibility hold it back?

    I am not saying that ensuring backwards compatibility should be a primary focus for C3 at all. Although C2 doesn't quite feel finished yet so I hope that there's more work yet to be done to C2 before it gets shelved with CC.

  • Thanks hyem, I really appreciate it! I look back at it now and think that there are so many things I would do differently - I might make another version one day....

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Thanks! I'm better at making benchmarks than I am at making games... Something to do with my real job LOL...

    I hope that Ashley is quietly looking into this but I suspect that the case is closed - just from his words to me in the bug report where he all but dismissed these findings. It's quite clear that, on my hardware (i7, 16Gb, 6Gb vram - no slouch ) that r196.2 performs worse than r195 - worse both in terms of number of physics objects that can be handled and worse in terms of the frequency of frame drops that occur when the engine is stressed. The performance hike for asm.js that's been reported has not been duplicated by anyone other than Ashley, that I'm aware of.

    Some fundamental changes were recently made to the physics engine and, although there is evidence that the performance is slightly worse, I think we're just going to have to learn to live with it because the aspiration is to ultimately use only asm.js. Personally, I would rather we had a full native implementation of box2d web rather than have this effort focus on implementing 'improvements' like this.

    As far as I understand it, non-physics collisions are handled differently than the normal c2-optimized collision checking.

  • You do not have permission to view this post