Rhindon's Recent Forum Activity

  • Ah, sorry. Don't know how I missed it but I had overlooked tht report button. I'll keep that in mind if there's a "next time". Thank you, all.

  • WHAT are you two going on about?

    Ashley sorry to ask, but can you assist, please?

  • Awesome! I think that makes sense. I found instance 3 more suitable but I may rest the 4th after all.

    Thank you as always for your help!

  • In your demo, can you break down what's happening in your fourth instance, please?

    If it was translated to English, how would it be read? LOL

  • Thank you so much! I'll try out your suggestion!

  • I'm working on a top-down racing game.

    OBJECTS:

    • Car
    • Camera
    • Camera_Target

    The Camera_Target (henceforth: Target) is pinned to the Car at a distance in front of the Car. The Camera is always trying to follow and reach the Target. So as the Car moves about, the Target is always in motion, too. The Camera thus seeks to "catch up".

    Presently, I'm using the action for the Camera: lerp(Self.X, Target.X, 0.075) [same for the Y value].

    I've also tested using lerp(Self.X, Target.X, 1-dt^0.075)

    Now, this works...but the problem I have is that there is the occasional "jerkiness" or "jolt" as the Camera approaches its target coordinates of the moving Target object (this is especially more noticeable when using 1-dt*0.075).

    The effect I'm going for is a smooth transitional movement of the Camera that ultimately eases into position just ahead of the Car in whatever direction, even when the Car turns suddenly or quickly. I do realize that there is the recent addition of the Tween behavior but that doesn't work well "every tick", and I haven't found any other better solution.

    Can anyone assist in addressing the "jolt" issue, please?

  • Ashley and Taximan - EXCELLENT info/reminders!! Thank you for that very much. I'll surely keep that in mind.

  • You could ask me since I'm doing this storage.googleapis.com/strawberrypunchbenchmark/index.html and it spawns thousands of sprites with x, y and z values and acceleration and drag for 3D movement for every single individual character with a bunch of sprites layered on each character for character customization

    That is absolutely amazing!

  • Oh yeah, I do turn off collisions when necessary. My projects haven't been yet so demanding that I've noticed any difference however.

  • Thank you, plinkie! I'll review those later today.

  • Gooood day, ladies and digital-men!

    I'm planning a game set in a large-scale "sandbox-style" city with roads and buildings and everything in-between (except the kitchen sink...that might break the game...all that plumbing...).

    There will be very little changing of layouts - ultimately, I want the game to take place in one giant city. (Although, literally as I was just typing that, an idea occurred to me on how I could change layouts and yet still keep the semblance of a large city...more on that later.)

    My #1 concern is CPU/GPU overhead. Obviously, the more the computer has to compute, the more bogged down it's going to potentially get. Ashley & Co have been working miracles and wonders to make everything work as efficiently as possible so my concerns may not be all that warranted as they might have been had I tried this game on, say, C2. Still, I think it's important for me to begin keeping this detail amongst the top of my priorities.

    Here are some things I know of or I think I know of that will help to keep CPU usage down...

    - Keep related objects in folders. Objects that are directly associated with each other (ie: containers, objects pinned to another, etc) should all go into a folder. For reasons I cannot articulate, this just makes it easier for the computer to reference, drawn, manipulate, whatever every tick.

    - When dealing with road objects, specifically long road sections, having the road pieces stretch via height or length will obviously reduce the number of objects needed to be drawn on-screen (and less to track overall). I am, however, unaware of the use of a 9patch vs sprite vs tiled background will be of any benefit in terms of CPU usage.

    - Effects, WebGL, particle objects, etc, tend to be a bit more demanding on CPU/GPU. I should use these sparingly, even with the improvements to C3 runtime. ...... At least, this is my understanding. I fully welcome correction.

    - Objects off-screen are not readily drawn. So I don't need to tell C3 to draw objects as invisible when off-screen because they're literally NOT drawn given that you can't even see them anyway.

    That's all that comes to mind at the moment.

    Any and all suggestions would be greatly appreciated.

    Also, please go easy on me on technical jargon. I've been using C3 for a while, but some of the terms and such for more "professional" level of game design is still rather foreign to me. I may need to ask questions for clarification in order to make sure I know I understand what you're explaining.

    Also, my friend, SycrosD4, is teaming up with me and is very new to C3. He'll be handling the art-side of things and I'm sure he'll appreciate the info, too.

    Thank you everyone for your help and input!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Great info!! Thank you! I'll work on plugging these in soon.

Rhindon's avatar

Rhindon

Early Adopter

Member since 8 Jan, 2013

Twitter
Rhindon has 2 followers

Connect with Rhindon

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • x2
    Coach One of your tutorials has over 1,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

18/44
How to earn trophies