SoldjahBoy's Forum Posts

  • This is a long-standing issue with the platform behavior; nothing to do with using dt in events.

    There has been a number of threads about it already, like this one:

    There's one solution by JohnnySix at the bottom of that thread. Last time I implemented/tested it was 2 years ago so I dunno how well it works now but it's worth a shot.

    Ah, good to know... I assumed he wasn't using behaviour driven control for his jumping. Well that's a bummer... :/

    ~Sol

  • No problem

    ~Sol

  • Yes when you use instances of the same object, any behaviour or instance variable you add to it will be used by all instances of that same object... but they can be set and controlled PER instance

    You're welcome! Glad that worked

    ~Sol

  • [Tilemap is on layer 0]

    --- Disable solid

    That should work^

    ~Sol

  • ^ This is rediculous, it DOES matter if you use Unity, C#, Stencyl, or BuildBox, etc. You've Been Brainwashed!!!

    Only a fool would make a statement like this. C2 has terrible limitations that make it almost impossible to export anything worthy onto Mobile.

    The process itself is a nightmarish headache!!!

    I just got BuildBox and it's a million times better as far as exporting goes, with REAL NATIVE EXPORT!

    Be careful what you say to others, they just might believe you..

    Brainwashed? Fool? Okay...

    It's not C2's fault that the available wrappers (which are essentially software driven emulation) don't stack up well against a "native" application.

    I can build a game in C2 (using NWjs), and have zero issues with performance - and build the same game in Processing or C# and guess what? It's exactly the same! I can add the same 10,000 sprites to my game in any language, and make them do the exact same stuff, and get the exact same results!

    I think you're not only getting confused with how software works in general, you're lumping together wrappers and purpose driven code in the same basket... Sure BuildBox might have a better exporter for a given platform, that doesn't make it superior to C2 in the way the code or objects are handled on a hardware scale. All that means is that the BuildBox exporter is better than using something like Cocoon. Do you know the difference between a wrapper and native?

    I also SPECIFICALLY SAID "if you're pushing the hardware limits of your device... it won't matter what you make it in"

    So do you think if you have capped your fill rate on your GPU that another language will help? Do you think if you have maxxed out your processor by using too many loops or complex mathematics, that another language will be superior?

    Now, are you done with childish insults that were unwarranted, not to mention incorrect?

    damjancd

    If your game is fairly minimalist, then I have no idea what could be causing the issue apart from specifics that may be related to Cocoon. I'm not exactly sure what else to suggest apart from waiting for Ashley to get back to you about your project file. Sorry bud. :/

    ~Sol

  • If I can get my kids to settle down to bed here soon, I'll try to make a quick example for you

    *EDIT*

    Here we go... using the standard C2 "platformer" template, I quickly made the last few events on the event sheet so it records which platform you touch last.

    It only records static platforms, but you could make it do any platform, or maybe just a specific platform or "checkpoint".

    DOWNLOAD CAPX

    ~Sol

  • Using deltatime would fix your issue.

    Relying on X seconds, it will vary based on framerate and system power as you have discovered.

    Applying deltatime to your jumping, and controls in general - you should notice a perfectly measurable jump no matter what the system specs are.

    Built in behaviours already use deltatime, but if you're modifying the default behaviours or not using them at all, you may need to apply deltatime to those modifications or to your custom movements across the board.

    ~Sol

  • I set my preview browser to nwjs so it just pops open its own little window that i can put beside c2 and refer to both at once. It's less cumbersome than having it launch in a browser tab.

    ~Sol

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You probably won't notice any major performance impact unless you have a LOT of stuff going on already.

    You will need to create a miniature "stress-test" perhaps... so make like 1000 of your sprite objects at runtime using a loop (just for testing) and try the different effects to see which one works faster/slower.

    You can make an FPS and CPU counter on your project as well to help see visually the difference. Just make a text box object and every tick set the text to;

    "FPS: "&fps&"CPU LOAD: "&round(cpuutilisation * 100)

    This will give you a nice FPS counter and a rough approximation of CPU load.

    ~Sol

  • Are you using LERP like in the example events?

    LERP will smoothy scale/move/angle things based on the way it is used.

    If you wanted to resize something smoothy, you could use something like;

    (Let's assume your sprite is 100px wide)

    [EVERY TICK]

    --- Set width of Sprite to lerp(sprite.width,desired.width,amount)

    ***Sprite.Width will be the current width of the sprite (in this case 100)

    ***The desired width would be something greater than 100, say 200

    ***The amount is a number between 0 and 1.

    So your action would look actually like; lerp(sprite.width,200,0.5)

    The way lerp "amount" works is imagine 0 is the starting point and 1 is the end point. If you wanted to resize your object by half of the original width to the desired width (in our exmaple here we are using 100 and 200 - but you wanted it to be 150) the amount to lerp by would be 0.5.

    If you apply lerp "every tick" it would do the lerp "amount" every tick... so in the first tick if you used 0.5 your sprite would go from 100 to 150, and the next tick it would go from 150 to 175 (because theres 50px left to 200, so it does half of that again).

    Once lerp gets "close enough" it will snap to the final point (but it has to be VERY close on the float value - several thousandths of one pixel away).

    I hope this explains a bit better how the "smoothness" works.

    ~Sol

  • You can detect which platform your player has landed on by having an invisible sprite under him, or by using overlap at offset.

    You can then have an instance variable for each platform that gets set to "1" as he lands on it - and set all others to "0" (use a for each platform loop).

    Then when you respawn, create the player at the platform that has the instance variable set to 1.

    Hope that made sense.

    ~Sol

  • IT works like most things... you would need a set of variables to tell the game who's turn it is, etc.

    Global Variable - PlayerTurn = 1

    [PlayerTurn=1]

    [Press move right]

    ---- player 1 moves right

    [Player 1 dies]

    --- set PlayerTurn=2

    [PlayerTurn=2]

    [Press move right]

    ---- player 2 moves right

    [Player 2 dies]

    --- set PlayerTurn=1

    The same would be done for picking how many players you want;

    Global Variable - NumPlayers=0

    [Click button for one player]

    --- set NumPlayers=1

    [Click button for two player]

    --- set NumPlayers=2

    You would use your NumPlayers variable setting to help conditions with the first set of pseudo events I wrote up there^

    [Player 1 dies]

    [NumPlayers=2]

    --- set PlayerTurn=2

    [else]

    --- set PlayerTurn=1

    --- respawn player

    ~Sol

  • I don't have an iOS device so I can't say for sure... but typically any game that uses high resolution graphics and/or lots of action is going to cause high CPU/GPU load and subsequently heat the device up a bit (since it's working so hard).

    I don't know why you'd be having issues with WebGL either, but it's been at least 2 years since I've used Cocoon for anything (and I've never used phonegap or XDX - they weren't around back then) so I don't know :/

    Without knowing more about how your game works it's going to be really hard to say - but using another application to build your game probably won't change that if you're pushing hardware limits for the device. It won't matter if you use C2, Unity, C#, Stencyl, BuildBox, or a hammer and nails...

    ~Sol

  • That's a very broad request... it's usually better if you have at least some aspect of your game done - than ask about specific things you can't get to function the way you want. Asking someone to explain how to make an entire game is like asking your mechanic for step by step instructions on how to diagnose and fix your car.

    Nobody will help if you do that.

    Have you made anything at all so far?

    ~Sol

  • Voted as well. Ignore the generic mudslappers that say it looks like Fez. Apparently none of these people have ever seen an 8bit game before...

    ~Sol