Tylermon's Recent Forum Activity

  • My results.

    Colludium Also, I would love the capX

    Currently your project does not support 120hz / 144hz displays. Had to manually put them at 60hz.

    Chrome version: 38.0.2125.111 (Official Build 290379) m

  • I personally don't know many instances where I need 1200+ objects constantly being created every second.

    That's what you are describing. Your 20+objects a tick is 1200+ objects a second being created and similarly destroyed only to be created again.

    I would still be interested to see said 20 a tick improved. But I also want to see how that performs realistically. Creating worst case scenario projects isn't helping with making real games.

    We are not talking about using 1200+ objects. This is creating and destroying this many, objects on top of trying to use them on top of any other game logic.

    The OP was about a single sprite moving and seeming jittery/stuttering. This new scenario is one of insanity in my opinion, a non issue. I would love to see objects rendered more smoothly though.

  • Ashley

    Obviously, you understand how the internals of C2 work better than us. But, maybe you could take a look at this example capx and see if you see a difference in performance between forced object recycling and normal create/destroy operations. Click to toggle between modes.

    https://www.dropbox.com/s/s2v4h18r172v4 ... .capx?dl=0

    P.S. GeometriX: I modded your capx for this.

    I would almost say it is an issue of the browsers trying too hard to find and delete objects on their own. It gets so concerned with locating/destroying objects and cant keep up with the game itself. (Non-recycled has 2000 objects vs 5000 recycled)

    Like I said earlier, the way the game works, only 1 thing really works at a time. So if the browser is focusing on figuring out what it should remove, vs us telling what to remove or even re-use it is going to slow things down.

    I also don't think that has much to do with the Jittery movement. Garbage collection might help performance for objects off screen, but rarely should be a real issue.

    If you need 2000+ objects all being animated off screen....you might be doing something wrong. Dynamic content creation would greatly limit how many objects you need.

    I am fairly certain the issue comes with refresh rates/v-sync as Ashley was saying.

    Locking movement at or below refresh rate removes all jittery movement.

    This is for both aero and non aero browsing.

    when I set my system to 144hz (144fps) the jittery movement can hardly be seen.

    60hz and 60 fps, again looks smooth.

    If I try to go above the refresh with movement, jittering is seen, more so at lower refresh than higher. Thats why I was making a big deal about the frames needing proper interpolation, tv's often do this. And in animation, getting smooth animations greatly comes from proper interpolation.

    I'm willing to bet, a project that has invisible sprites as the actual game and "real" positions with visible sprites interpolating to those invisible sprites will get that "smooth" effect people here want.

    I have to really really stress though, a square is much easier to see a jitter to movement than a fully animated player in an actual game environment.

    in "real world" uses, this "issue" is not so much an issue as people are making it out to be.

    Some1 feel free to yell at me if none of that makes any sense. I'm really tired today haha. And admittedly my brain is like bleghhh and spit forth thoughts. Enjoy <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

  • Poking around, it looks like construct 2 uses

    requestAnimationFrame

    and

    setTimeout

    Like Dalal said, this causes problems. Browsers can do only one thing at a time, and with javascript this eventually leads to this stuttering.

    The solution? As far as I can tell is to use CSS for animations.

    found this example online.

    http://www.html5rocks.com/en/tutorials/ ... e-raf.html (The way it looks like Construct 2 animates using requestAnimationFrame)

    http://www.html5rocks.com/en/tutorials/ ... imple.html (The same animation using css)

    Edit:

    Also reading about GSAP

    http://greensock.com/gsap

    Looks fairly promising.

    As for if this necessarily will help with smooth animations I cant say. I feel a square box is rather different than an animated character/object changing frames.

    Part of the issue also falls to device vertical sync and fps. I took the example from page 1, changed speed to always match fps. And obviously there was 0 jittering.

    The problem is it moved slower than I like.

    There could be an internal issue within construct and how it draws frames, because it does not match the refresh rate. (Everything takes place logically as if 60fps I believe?)

    Digging around, it looked like this is due to that setTimeout code I was talking about. It looks like it is set to 16ms (60fps) which obviously is bad. Static frame rate/refresh/logic has these issues. A dynamic system would always look smooth. Able to adjust with fps drops and rises.

    I could be wrong about how construct is animating things. But It would probably be better if it animated based on dt rather than using the timeout.

    The people with high refresh devices don't see nearly as much jitter because they refresh so fast it compensates for any fps variance.

    Ahhhhh screw it. Everything I know and keep reading about game/film/web animation and why it looks "jerky/jittery" all comes back to interpolation. If you interpolate between delta time and desired speed things should look smooth(er). I think the issue comes from while speed might be interpolated etc, the animation frames themselves are not. The draw calls themselves should interpolate what we see, I don't think it does.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Actually, lerping the positions graphically would not help that much, as the lerping would jitter as well, and would be an insane amount of work just to work around bugs that will be fixed eventually (#reallife, you cannot rely on hack tricks, bugs must be fixed, as doing hacks tricks is the worst you could do actually for anyone involved).

    Same for the loader, it will make the player wait an empirical amount of time, when this jitter will be fixed, it will be there, making people wait for no reason (well, I guess the jit compilation would benefit from that even later so it is not that problematic if done well.)

    How would keeping not help? Wouldn't it smooth the movement so to speak?

    As for loading, I was under the impression many people see the most littering at a layout change or project start. A load/pause would allow all resources to fully load hopefully reducing jitter.

    But I agree completely. Movement and animations should looks smooth without having to find ways to "fix" it.

    But I wonder what might be broken. I know personally I don't have any perceivable jitter. I also have a rather powerful computer CPU and gpu wise....which doesn't help with trying to find performance or visual stuttering haha.

  • Sorry for the double post. Editing is not very reasonable on my phone right now.

    But I forgot to mention for start up jerkiness people should have a loading screen/pause a layout momentarily on start up/ layout change.

  • So you're suggesting I record the positions of my objects during a sample bit of gameplay, then re-animate them using that database? That's a really clever idea. The problem in my use case is the sheer number of objects (around 1000-2000 onscreen) I'd need to track...logging all that data would be bound to induce some slowdown.

    BTW, I tested your link, and I saw much what I expected: after a breif 'settling down' period, IE produced the smoothest result...virtually no jank. Chrome had a much lower cpu usage than IE, but it's jank did not 'settle down' after awhile. Firefox, needless to say, janked the worst.

    ....third time writing this. My power, Internet, and cable are out. And my phone is being special....

    Because my power is out, the server went down. Meaning you probably were hosting the game for yourself and would need a second browser tab to see the movement I was trying to describe.

    I do have an idea. I noticed people on 120hz+ seem to have little to no issues.

    60hz should still look smooth though.

    So I thought, maybe the game logic is running faster than the rendered frames! For instance, the game is changing an objects position logically like 90 times a second....but visually a solid 60. This would have what should be smooth movement look jittery.

    Same if the internal side of things runs slower,

    Maybe a way d time or something works?

    I could be way off. But hopefully that makes sense and maybe inspires new ideas.

    I think that would explain why the high refresh monitors also look much smoother. Aside from the benifits of higher refresh of course.

  • Personally working on a multiplayer project. I had about 70 events. Now I am in the 50's

    Really trying to focus on optimizing and streamlining what I have. Keeping server and client code clean. And minimal.

    It has been challenging keeping track of what the server should do, and what the players should do. Especially as I begin adding more complex features.

    Still looks messy and I want to get things more concise before I move forward. If not for performance, then for my own sanity haha.

  • You could always lerp the image locations with the actual logical locations.

    Visuals only need to be close enough to actual locations to be believing.

    This also gives you fine control over the logic, while maintaining fine control over visuals as well.

    Personally I am working on a multiplayer project, I get a constant 120fps even with many connections. And things looks smooth for every player.

    I guess my heads been in keep visuals and logic separate and out of player control for security and best gameplay reasons. And this way of thinking to keep everything separate has been working nicely.

    If people want to give things a try, the project reports cpu load as well as frame rate.

    Would help seeing which people still get choppy visuals...and I can test my project at the same time haha.

    https://dl.dropboxusercontent.com/u/583 ... index.html

    Not sure how dropbox will handle a multiplayer server....but here is a try <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

    As a reference. On dropbox I am getting 120fps and 0.04 cpu usage. Looks smooth.

    Also, people testing games...keep the game on your primary monitor. I found that multiple monitors...with browsers for some reason perform rather crappy if not on monitor 1.

  • title isnt a lie. there is a free gtx 970.

    Im not forcing any1 to have a go at winning.

    Sorry if a few people were confused.

    I did say :

    "Great card. And if you win, free is a really great price haha."

    I think by now we all should know everything has a price in some way shape or form.

  • Title says it all.

    Probably one of the best cards on the market right now. Currently zotac is giving away their newest overclocked edition for free.

    All you do is like a facebook page/follow their twitter.

    http://splur.gy/r/vd8n3/r/2Qx5DCR48dV

    Great card. And if you win, free is a really great price haha.

  • you could possibly lerp it also. This would help start and end camera motion in a smoother manner.

Tylermon's avatar

Tylermon

Member since 26 Nov, 2013

None one is following Tylermon yet!

Connect with Tylermon

Trophy Case

  • 11-Year Club
  • RTFM Read the fabulous manual
  • Email Verified

Progress

13/44
How to earn trophies