Bump, because I think this is an important feature!

Hey all,

I'm running into some places in my game where having Pin be relative to scaling would be hugely helpful. Check out the attached capx to see what I mean.

In fact, this probably almost counts as a bug report, since I'd say this would be expected behaviour in a behaviour like Pin.

(And yes, I know that in this case it's trivial to do it manually, however my situation is a lot more complex!)

This would technically be a breaking change, so it might be best to make it an optional feature. In fact, in my specific case it would be awesome if we could toggle it on/off at runtime.

Anyone agree this would be useful?

Colludium

My thought process behind giving the car actual wheels as opposed to just making it a box, was that it would be much easier to get realistic driving naturally. This way, the driving physics work just like they do in real life without any weirdness behind the scenes. You can also do things like adjusting the friction coefficients for the tires etc.

Why would you apply velocity rather than use forces? You say it won't kill the physics behaviour, but it certainly won't play nice - there's really no reason to *not* use forces as far as I can see.

In terms of 'why use physics at all', it's definitely a valid question, but if you've seen how bad the car movement felt when running into anything (i.e. it would come to a dead stop when just skimming a wall), then you'd be able to see why I suggested the move to physics. I'd be open to seeing a counterexample, but physics just seems more intuitive, and quick to get up and running, which is key!

I've been reading this very interesting article about javascript/HTML5, specifically performance on mobiles.

Why Mobile Web Apps Are Slow

There's definitely a lot of food for thought here. I'll be the first to say that I don't know a lot about this whole area (not even enough to agree/disagree with what the author is saying), but it's definitely something that should concern anyone using/developing C2, especially when Scirra has stated that C3 will be based on HTML5/js.

Some of the main points of the article:

-JS is 5x slower than native code

-JS is unlikely to get much faster in the forseeable future

-Garbage Collection is exponentially slower when less than 6x the memory footprint of the app is available

-You simply cannot write fast mobile code without thinking about memory management

My thoughts: in an engine like C2, it's a lot to ask for users to perform proper memory management. So in that way, C2's goals align well with JS's goals. However, the limitations of this for mobile development are very worrying.

What does everyone else think?

I wonder if perhaps a new expression for speed would be a good idea.

Something that would have dt applied, but be simplified to pixels per second, like say speed().

I think that would definitely just complicate things. The current method of using dt appropriately is perfectly fine, so long as the programmer knows how to use it properly. For someone without a math/programming background it can be a hard concept to wrap your head around though, so more education would always be nice. Perhaps even include a section about dt in the Beginner's Tutorial?

It's really interesting that this is different, yet so close. I always did have a weird feeling when doing lerp(0,1,x*dt), and in fact I've mostly migrated away from doing lerp like that in my code, since in a lot of cases, it *is* bad practice, as some people have brought up. I don't agree that it's always bad practice, however, as it provides very pleasing effects when used on things like camera movement, etc.

Anyway, Ashley I'd love to see a blog post on this!

Oh, man, yeah, 'every X seconds' should never be used with dt. It uses it internally. So you're actually checking the timer for 60 * dt * dt !

So... The consensus is that the code should be working, assuming that dt has been used correctly everywhere?

I'd like to give this thread a bump. This feature would help immensely with lag spikes which are unfortunately a pretty common occurrence for a lot of C2 games.

I've been talking with Aurel who just released The Next Penelope on Steam. Apparently certain streaming softwares kill the FPS on the game, and without a low dt cap the game goes out of control, whereas simply slowing down the gameplay would be far better. (the setting timescale relative to fps is a very messy solution, specifically in that case)

Problem Description

It's almost identical to the problem way back in r158, which we solved here. In fact, I was able to use the very same capx to reproduce the issue. (one uploaded has slightly different instructions as it seems to need a little bit more specific circumstances to reproduce predictably.)

This was not present in r192, the version I was using before updating to r195. So the problem was reintroduced somewhere inbetween those releases.

Description of Capx

Press buttons to save, load etc

Steps to Reproduce Bug

[Described in Capx]

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

Win8 64bit

Construct 2 Version ID

r195

OK, seems most people here haven't experienced this problem before

What you're most likely experiencing is a Fillrate bottleneck. Basically, a GPU can only draw at maximum a certain number of pixels every second. On desktop PC's this number is usually in the hundreds of millions [citation needed] but at 1080p with a few layers of full-screen graphics, you can run into the problem very quickly.

For example:

1920 * 1080 ~ 2,000,000 pixels

2,000,000 * 60fps = 120,000,000

Now multiply that by how many fullscreen graphics you have, layers with shaders or 'force own texture' on, etc.

The solution to this is either to reduce the amount of fullscreen graphics, or just choose a lower window size and set fullscreen scaling to low quality.

Just use webfonts, yeah. Basically, even if you DL the webfont and C2 says it's not supported, that's not actually true. Just use a 'placeholder' font in the editor, and load the webfont at runtime.

Well it's good to hear that the sound issue isn't Airscape's fault... guess that's one problem down, haha