Hi Mathijs90,

One way you might approach this is with a custom variable to represent the turning rate.

I'll call this variable "turnRate".

You can think of this variable as keeping track of the steering wheel position, with "0" meaning centered, positive numbers steering right-wards, and negative numbers steering left-wards.

The events that allow the player to control this variable should do the following:

When you hold RightArrow the turnRate value will gradually increase up to a cap value (e.g. +300),

and when you hold LeftArrow the turnRate value will gradually decrease down to a cap value (e.g. -300).

When you're not holding any keys, the turnRate value will gradually move towards 0.

To get the Car behavior to use this variable for steering, you'll first need to disable "Default Controls".

In the layout, select the car, and in the car's properties, in the section Behaviors > Car, find "Default Controls", and set it to "No".

This disables the automatic key bindings that control the car.

Don't worry, you can manually recreate these key bindings with events, using the car's "Simulate Control" action.

Recreate the key bindings for acceleration and breaking as follows:

UpArrow is held down: For Car: Simulate Control - Accelerate.

DownArrow is held down: For Car: Simulate Control - Break.

To link the turnRate variable to the car's steering create the following events:

Every tick: For Car: Set steer speed to turnRate.

Every tick: For Car: Simulate Control - Steer right.

It looks weird, but what's going on is that the car now always thinks it's steering to the right, but by the amount stored in the turnRate variable.

When turnRate is positive, the car will turn right.

When turnRate is negative the car will turn left. (a "negative" right turn)

And when turnRate is 0 the car will go straight.

As a final thought, you may want to make the turnRate return to 0 much faster than it gradually climbs away from 0, i.e. when turning left or right. Even though realistically, a human driver really would have to turn the steering wheel back to center manually, for a game, the controls will probably feel more responsive if the return to center occurs in a fraction of a second.

This rapid return to center should obviously take effect when a player is not holding a turning key, but it should also occur when a player is holding a turning key that is currently turning the wheels back to center. In that latter case, once the wheels get back to center, (and the key is now turning the wheels away from center), the steering can go back to being more gradual.

Hope that helps.

Hm...

I suspect one of two things is happening.

A: The ghost ship is not actually being updated inside the loop.

B: The ghost ship is being updated inside the loop, but to the same spot 100 times.

If the buggy ghost ship is always exactly on top of the real ship, then it's likely that it's situation "A".

If the buggy ghost ship is always exactly 1 time-step ahead of your real ship, then it may be situation "B".

The most likely cause of situation B is that, inside the loop, each loop iteration is setting the ghost.state to

updateFormula( RealShip.state ),

instead of updateFormula( Ghost.state ).

It's hard to say exactly without seeing the events though.

If you can post a screen grab of the events in question, I might be able to figure it out from that.

(In the event sheet, if you select a bunch of events and right-click on the very left edge of an event block, one of the menu options should be "Screenshot Selection.")

Hey again McDonald,

Sorry, my explanation, may have been a bit vague in places.

So, here's what should happen in a single tick:

[TICK START]

// First we advance the RealShip by one time-step.

Every tick: RealShip.state = updateFormula( RealShip.state )

// The ship's "state" information is its XY position, and XY velocity.

// Given the current "state", the "updateFormula" computes the new state for the next time-step.

// // I'm using updateFormula as a shorthand here, in your actual code it may be a block of two or more events.

// Now we prepare the ghost ship to execute a simulation of several future time steps.

// First we set the ghost ship to match the real ship's state, (XY position, and XY velocity).

Every tick: Ghost.state = RealShip.state

// Now we're ready to start the simulation.

// We'll run 100 iterations, and with each, the ghost will advance 1 time-step into the future.

// (Note that the tick has not ended yet.)

Loop from 1 to 100:

// We update the Ghost, just as we would update the real ship.

// Critically, we feed the Ghost's state to the updateFormula, and NOT the RealShip's state.

[sub] > (always): Ghost.state = updateFormula( Ghost.state )

[sub] > (always): Ghost spawns a dot object.

// The ghost has now plopped down 100 dots.

[TICK END]

Essentially, you'll be triggering the same time-advancing code that Construct would trigger each tick (frame-draw), but you're not waiting for Construct. You're manually triggering the code 100 times before the tick ends and the frame is drawn. You're just doing it with a ghost copy of your ship.

As for working with player controls, when the simulation is updating the ghost ship, you can have each loop iteration update the ghost as if the player is continuously holding down the same controls that were used when updating the real ship.

Hope that helps out.

Variation

As an alternative variant of the above approach, you could conceivably run the simulation with your real ship, and not even bother using a ghost ship.

You would need to store the state of the real ship after its update, but before starting the simulation, so that you could recall the real ship back to its proper pre-sim state, before executing any remaining code in the tick.

Thus, even if during the simulation the real ship collides with a lethal object, you'll still be inside the sim loop, and none of your collision handling or ship-exploding code will be running yet. So as long as you put the real ship back, by the time your collision handling code runs, it will never know the ship "time traveled" into a future hazard.

... And witnessed its own death! D:

Also, dang it R0J0hound, how are you always using a newer version of construct than me.

I swear, I learn about C2 updates from clicking on your examples.

I probably need to enable beta updates, huh.

Hey McDonald,

One way you might approach it, is to run a loop every tick, to simulate the next several frames of motion updates on a "ghost" copy of your ship, dropping dots or particles as it goes, to draw the predicted orbital path.

How it would work

Suppose you have your "real" ship, and you have event code that describes how its position and velocity will be updated each tick (C2 frame). I'll call this event code the "update formula".

So, on a tick, you update the "real" ship position and velocity by running the update formula on it, once.

Now, suppose you also have a "ghost" ship. (The ghost ship will be invisible to the player.)

Right after you update the "real" ship's position and velocity, you set the ghost ship to the same position and velocity.

Now you run a loop with 100 iterations,

and in that loop, on each iteration you update the "ghost" ship, by running the update formula on it, and then you place a dot object at the ghost's current location.

Result

Each time you go through a loop iteration, you step the ghost forwards in time, exactly as if the real ship were continuing frame-by-frame on its trajectory.

At the end of the loop's 100 iterations, you have 100 dots tracing a predicted trajectory 100 frames into the future.

Pros & Cons

As a possible concern, depending on the complexity of the update formula, and the specs of the platform you're targeting with this game, this loop could be a rather intensive spot in your code, though on a typical computer I think it shouldn't be a problem at all.

That said, this method has the advantage of using the same update code you've already created for the "real" ship, and as a result, it will be an accurate simulation of the real ship's future motion, not including player control input, of course. :)

Optimizations

If you need to use fewer objects, you can always place a dot every other loop iteration, or every 5th iteration, etc.

Or you could use a canvas object and paste dots (or trace lines) directly into it, which has the advantage of using 1 dot object no matter how many iterations you do.

Thanks for the replies everyone.

And thanks for the suggestion ASHLEY. I'm going to try doing a kind of running average over time of the frame rate I think. When directly using 1/dt with no temporal averaging, I tend to get some sudden single-tick spikes where 1/dt = 1000+, which throws off the max frame rate a little. :)

I think as long as the game isn't running stably at a strangely low fps, it should work for guessing the monitor refresh rate decently.

Thanks again. :)

Thanks for the reply Kyatric,

I was afraid that the monitor refresh rate might have been hidden beyond reach from within a browser.

Hey Somebody, you might be able to get some optimization by placing large amounts of run every tick code inside a group that runs every other tick, or every forth tick, in effect making some of the more intensive code run at around 30 to 15 fps. It would probably depend on the code though.

As for the frame cap, I may be wrong, but it looks to me like C2's frame draw rate and event sheet tick rate can both increase beyond 60 Hz, to match monitor refresh rates greater than 60 Hz. Though the monitor refresh rate must be set before the game is launched. I don't know if this is normal behavior, but it seems to work on my system pretty much the way I'd expect.

I recently reworked the movement and animation math in one of my games to make it frame rate independent, specifically so it would run correctly at both 60 Hz (for my older monitor), and 144 Hz (for my newer monitor).

Beyond 60, so far I've only tried 85, 120, and 144 Hz refresh rates, though I mainly work with C2 at 60 and 144. In each case, it seems that C2 is forced to run events and draw frames at a rate matching the monitor refresh rate.

Again, I could be misinterpreting what I'm seeing, but just now as a simple test, with my monitor set to 144 Hz, I created a sprite, gave it the "Drag and drop" behavior and then dragged it around the layout in a preview.

In the Node Webkit preview, I got a C2 frame update matching every draw update of the windows hardware mouse pointer. Albeit with a one frame delay, because it's the hardware pointer after all, but I appear to be getting 144 updates per second from C2 none the less. That is, the sprite steps exactly the same distance as the hardware pointer with every C2 frame draw. If the mouse pointer was updating at 144 Hz, and C2 was updating at 60 Hz, then the sprite would be getting updated less often, and would need to step over a larger distance to keep up with the mouse pointer.

In the Chrome preview, I got pretty much the same thing. 144 Hz.

In the Firefox preview, I got a choppy mess with very little matchup between C2 frame draws and hardware pointer updates. The frame rate repeatedly went well below 60 fps, but that's pretty much what I always get from Firefox. Maybe I have Firefox configured wrong, or maybe it just doesn't like HTML5, either way C2 seems fine on every other browser, so I don't think it's an issue with C2.

Okay, I actually just went back and added an FPS read-out to that test, via "every second, set text to 1 / dt".

Node Webkit and Chrome show an average of almost exactly 144, and Firefox is closer to 90 on average, but fluctuated wildly, going as low as 20 fps every few seconds.

On the off chance my system specs are important, I have Win 7, a pretty good Nvidia card, and variable refresh monitor with a max of 144 Hz. I can provide more detail if needed. Though other than the monitor refresh rate, I'm not sure what might be especially important.

Is it possible to get the refresh rate of the monitor?

From what I've seen C2's tick rate seems to match the monitor refresh rate.

I'm building a real-time scrolling FPS graph, and I would like the max value on the graph to be the monitor refresh rate.

Often the refresh rate will be 60, but there are also 120, and 144 Hz monitors (among others), and it would be nice if the graph could automatically adjust its max, to match the monitor refresh rate, when started.

I know I might be able to guess the refresh rate by tracking the average frame rate, but I'm hoping to avoid that kind of solution if possible.

What if any command line options should I use with the new, separately downloaded, version of Node Webkit?

In the last version of C2 that came with a bundled Node Webkit version, after exporting my game to an exe, I used two command line options that helped with performance and compatibility on several systems.

--disable-threaded-compositing

This fixed a Webkit issue that caused regular freezing and hitching that would stall a game for between 1 and 10 seconds, which would happen a few times a minute for as long as the game was running.

--ignore-gpu-blacklist

This allowed my games to run on Windows XP, in cases where the default exported game would show up as a blank screen.

Ever since upgrading to the newer version of C2 for which Node Webkit is downloaded separately, using "--disable-threaded-compositing" results in a solid white screen.

Just wondering if that means Webkit solved the problems I mentioned above, and the command options are no longer needed, or if I need different options now, or if I need to change some settings in C2.

Any thoughts or suggestions are welcome. :)

Awesome thanks — :)

I figured it might be some kind of optimization.

Hi all, :)

After updating Construct 2 to r190, several of my projects no longer show certain WebGL effects during runtime preview.

I haven't investigated this very much yet, but so far this seems to occur in situations where I'm using an empty layer with an effect to post-process the underlying scene.

It seems like, as of r190, a layer with an effect applied to it won't render unless there is also an object on that layer.

Is that maybe what's going on?

If so, it's not necessarily a problem. I'm just trying to figure out what I need to do to get everything back to the way it looked pre-r190.

So far, I'm just putting an invisible stub object on every post-process layer to make sure it renders.

Thanks for the replies Rayek and — Embedding developer info is a good suggestion. I honestly wasn't expecting game jam entries to make it that far. Also thanks for the tutorial link, valdarko.

Thanks for the Whois suggestion — I'll look into that.

And, thanks for the DMCA info Ashley and —

You guys are awesome. I really appreciate all the suggestions and advice. :)

Weird update:

When trying to get back to the AtomicGamer page, I inadvertently came across PlayerAttack.com, which also has a copy of one of my games, and it looks like they may have copied it directly from AtomicGamer. It's exactly the same outdated version found on AtomicGamer. Likewise, a third party on AtomicGamer had added a few lines of their own description to my game, and that third party description was copied word-for-word by PlayerAttack.com. PlayerAttack seems to differ from AtomicGamer in that they put my game behind embedded video commercials, instead of charging for download acceleration, like AtomicGamer.

Thanks for the advice —

I think I may contact GameJolt soon and see if they have any suggestions.

Hey A0Nasser, :)

I created distributions of my game for HTML5, Windows, OSX, Linux32, and Linux64. The Windows version is the one that was copied.