eli0s's Forum Posts

  • R0J0hound , I tried your javascript tests and I can confirm your results:

    Firefox: random spikes and some uncorrelated stuttered movement

    Chrome: Almost no spikes and a few occasional jumps in movement

    IE 11: no spikes but some stuttering detected.

    Those results above reflect my experience with actual C2 projects in the same browsers.

    Unfortunately I can't get my self to be accustomed with it. I don't mind this while I test and fool around trying to learn C2, but as a consumer, I would have been very disappointed playing a game that has sporadic jumps&drops in fluent movement. If this is something I have to swallow by accepting html5 as a gaming platform, I find my self agreeing with the camp that had raised the need for other exporting solutions so many times now, it's just not ready yet, it's unprofessional and sloppy to deliver something that has intrinsic flaws like this.

    Anyway, the original poster has a solid answer now, thank you again for the input R0J0, it's valuable and constructive to interact with you

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I don't really notice the lag, but then again my pc is dog slow with html5 as it is.

    So, if I understand you correctly, you don't notice the lag because even if it exists, the performance of html5 in your pc is already bad and you wouldn't be able to distinguished it?

    I am curious about these optimizations because I have stuttering issues even using 2 sprites, one for solid objects and one for the player with the platform behavior. I am talking about single frame square sprites.

    Some time ago, due to my frustration by this issue, I wanted to make a topic and post a video of this, but when I tried to screen capture the previewing capx, the screen capturing software really messed up the frame rate on the browser. So the issue sifted from the subtle and sporadic stuttering to an inaccurate representation of framerate drops.

    In short, I have no tools to document accurately this issue, other than writing in terrible English about it. But it is there and it's too evident for pleasurable experience, at least in tight platforming games, in my opinion.

  • R0J0hound , thanks for your input!

    I know nothing about the garbage collection process (I've read about it as been a problem in general on other topics though), but any word coming from the great R0J0 I' ll take for granted

    As for the background processes, I get that windows and all the junk I have installed on my system are taking their toll on my PC, but shouldn't this be as true for other games too? My rig is not in its prime any more, but it can still play most modern 3d titles on high settings, with no stutters or other noticeable frame drops.

    To be frank, being as ignorant as I am, I can't help wondering how it is possible for a 3d game engine to calculate and render all those polygons, huge textures, complicated shaders, real time lights/shadows and post effects, and at the same time run smoothly!? Of course there are geniuses behind those engines that optimize everything and squeeze every last redundant bit out of the game, but still, I would expect a 2d engine that doesn't have to deal with most of those things to deliver rock solid results on simple scenes, and I even hopped that its lack of third dimension would give it an edge on what it can display on the other two dimensions.

    I fear that this is all about choosing HTML5 as a target platform, although I have no technical knowledge to support it, nor that it really matters, C2 is what it is and does what it does.

  • Sonyika , I am not familiar with the webm format. I am guessing there are software that can convert to this type of file.

    A google search with the terms "convert to webm" gave many results, you can try and see if something works for you.

  • Well, I think zenox98 unintentionally linked an other topic. Here is the page from the manual for the video object https://www.scirra.com/manual/181/video

  • Here is an example capx. It has the necessary info inside.

  • onur (super hot has very interesting gameplay!)

    Elliott

    alvarop

    I don't think OP asked about time manipulation.

    —, you ask about if there is a way to change the image point on separate frames of a sprite at run time with events and actions? I don't believe there is.

    I am interested in seeing your example capx to understand how could this prove to be useful as a gameplay element though.

  • I guess "micro stutter" is an accurate description and I am afraid there isn't a way around it. This occasional jagged motion is very evident to some people, less noticeable to other (much to my surprise), in any case, it has been described in other topics and there hasn't been a clear explanation for the cause of it, nor for a solution.

    For me is extremely evident in platforming projects. I can get my self to get use to it while I am testing but, at the same time, I thing of the Mario brothers game on NES and how smooth its motion was... and that is puzzling me: on a modern platform like C2 these kinds of problems should have been ironed out by now. Yet, I see very few people bothered by this, or even noticing it.

  • You can unrar the capx file and then use a text editor to change a line in the caprog file.

    Change the <saved-with-version>18000</saved-with-version> into <saved-with-version>17800</saved-with-version> and it should work.

    I can't think anything else other than what I told you already.

  • VIKINGS , and you rightfully do so! My point is that if you have an object that C2 takes into account to do the scrolling calculations (either with the "Scroll to behavior", or the "scrollX" action), and you move this object between layers that have different parallax values, then C2 won't know by its self how not to jump around due to the layer's offsets.

    In your case, do you move the PlayerBox object between layers that have different parallax values?

    Have you checked your other objects for a forgotten "Scroll to behavior"?

    Or your code for a redundant "scrollX" action?

    And does my example above runs smoothly in your system?

    Come on, you have to help us out if you want to help you out

  • You are welcome

  • I don't get why you're having problems. The setup you describe is straight forward enough, there shouldn't be any problems. The sprite you are pinning is irrelevant and it shouldn't affect in any way the scrolling of the PlayerBox or the system scrollX action.

    Here is an example using both ways, apart from a tiny jump which is probably due to a missing tick between the group activation/deactivation, the scrolling is exactly the same.[attachment=0:3iasqmmm][/attachment:3iasqmmm]

    If this plays ok in your system then something else is causing the problem.

    Perhaps you have other objects with the Scroll to behavior forgotten somewhere? Or a redundant scrolX action hidden in your code? Maybe the PlayerBox is jumping from layer to layer and those layers have different parallax values?

    If it doesn't run smoothly, then it's your system that is having trouble maintain steady frame rates.

  • SteveKane , you can't avoid using every tick if you want smooth movement. In my example the every tick is included at the first condition, any event that is not a trigger (a trigger is displayed as a green little arrow on the left of the event) it's been calculated on every tick, unless its told otherwise. Even an empty condition is equal as like having the "on every tick" condition.

    You could use the "every x seconds" condition to skip ticks and have less calculations, but this will also affect the smoothness of the BGs movement. Here is the same example with the movement at every 0.1 of a second (so it is effectively doing only 1/6 of the original calculations). As you can see, it's like a stop motion, but perhaps I guess that this can actually be aesthetically desired.

  • This..?

  • Something like this?

    Please note that you might have to find a way to deal with the upside/down and vertical bricks, add Y comparisons to invert the detection that determines the impulse angle...