A level in a currently unreleased game of mine features 8 sprites rotating clockwise constantly but their movements become twitchy, laggy and just completely unsmooth due to the lag which seems to be increased/caused by the player pressing the arrow keys to move. The player often dies purely from the game ruining lag.

What can anyone do about this? Just sit there and accept that your game is unplayable?

This is a very script heavy project but I don't believe this should be happening.
It seems like it wouldn't have happened on the old site.

Any and all help will be greatly appreciated.
Thanks in advance.

Do you use Firefox?

ProdigyZeta7 wrote:

Do you use Firefox?

Indeed I do.

acedannyk wrote:

ProdigyZeta7 wrote:

Do you use Firefox?

Indeed I do.

Have you tried every engine?

DotDash wrote:

acedannyk wrote:

ProdigyZeta7 wrote:

Do you use Firefox?

Indeed I do.

Have you tried every engine?

I haven't tried every browser, if that's what you mean.

What about the players? Many will experience the lag in its entirety because of their browser.

acedannyk wrote:

DotDash wrote:

acedannyk wrote:

ProdigyZeta7 wrote:

Do you use Firefox?

Indeed I do.

Have you tried every engine?

I haven't tried every browser, if that's what you mean.

What about the players? Many will experience the lag in its entirety because of their browser.

Well it also depends on your computer, I use the newest IMac with Chrome, and it runs 99.9% of the time smoothly.

DotDash wrote:

Well it also depends on your computer, I use the newest IMac with Chrome, and it runs 99.9% of the time smoothly.

That could possibly be the issue, I suppose.

Chrome is hugely worse.

It appears that holding down any button on the keyboard will cause ridiculous lag for the spinning sprites. Thus moving with the arrow keys is a big problem. Is… anything being done about this? Just my laptop or what?

acedannyk wrote:

Chrome is hugely worse.

It appears that holding down any button on the keyboard will cause ridiculous lag for the spinning sprites. Thus moving with the arrow keys is a big problem. Is… anything being done about this? Just my laptop or what?

Have you tried IE?

For keyboard-related lag problems, try switching off the key-repeat. On Mac/Linux it's just a case of going to the relevant system prefs setting. On Windows, the control panel gives the option to change the key-repeat rate (you can minimise it, which might help some), but I think to actually switch it off you need to go through a more obscure route. Take a look at this website for instructions:

http://ask-leo.com/how_do_i_turn_off_keyboard_repeat.html

Let us know if that helps (in particular, what difference it makes in the different browsers).

Also, I made a lag test project a while back: http://scratch.mit.edu/projects/10125047
Would be interested if you shared your findings (in its comments) for how it behaves under various situations on your system with different browsers.

Thanks!

I'm going to be bluntly honest with you, I don't want to look for any more work-arounds. I tried Chrome and Firefox, I tried it on my laptop and my desktop and every time the lag destroyed the game. I will not be delving into advanced and obscure settings, or trying other browsers for that matter, to try and work around this. At the end of the day, NO player will make an effort to work around it and rightly so - they shouldn't have to put up with this nonsense. This lag was never a problem on the old site and I don't understand why it's an issue now.

acedannyk wrote:

I'm going to be bluntly honest with you, I don't want to look for any more work-arounds. I tried Chrome and Firefox, I tried it on my laptop and my desktop and every time the lag destroyed the game. I will not be delving into advanced and obscure settings, or trying other browsers for that matter, to try and work around this. At the end of the day, NO player will make an effort to work around it and rightly so - they shouldn't have to put up with this nonsense. This lag was never a problem on the old site and I don't understand why it's an issue now.

There's always still my theory.

turkey3 wrote:

There's always still my theory.

Excellent observation but the ST will no doubt take an eternity before the lag issue is even close to solved. I want to be able to share my game now, after close to 2 months of development putting up with 2.0's wonderful array of problems.

acedannyk wrote:

I'm going to be bluntly honest with you, I don't want to look for any more work-arounds. I tried Chrome and Firefox, I tried it on my laptop and my desktop and every time the lag destroyed the game. I will not be delving into advanced and obscure settings, or trying other browsers for that matter, to try and work around this. At the end of the day, NO player will make an effort to work around it and rightly so - they shouldn't have to put up with this nonsense. This lag was never a problem on the old site and I don't understand why it's an issue now.

There may be possible workarounds that some players may use for your (or any other) game, but that's really not the point of using them, nor of the lag test project I wrote.

The point is to try to understand what's happening, to see what makes a difference, to investigate where the problems may lie. I know that the Scratch Team are well aware of the issue, and have been trying to investigate, but so far it's not clear what the source of problem really is. However, without specific information of tests under different situations from people who do suffer from this problem, that lack of clarity will remain, and the problem will never be fixed.

Providing your experience of the problem (preferably under different specific situations) is useful towards a solution.

Does that make sense?

DadOfMrLog wrote:

without specific information of tests under different situations from people who do suffer from this problem, that lack of clarity will remain, and the problem will never be fixed.

Providing your experience of the problem (preferably under different specific situations) is useful towards a solution.

Does the ST have an official thread for this?

acedannyk wrote:

Does the ST have an official thread for this?

I'd expect they have some internal place for discussion of issues, and this is likely in amongst them. I'll leave it for them to respond to that more specifically (if they feel the need to). There have certainly been numerous posts on the forums that have mentioned various problems with performance under certain situations (most recently the graphics effects becoming very slow, especially with recent update of the Chrome flash player).

The keyboard-induced lag problem has been mentioned several times in the forums, but is something that seems to be particularly tricky to pin down.

I do know from experience that it tends to happen more if you have numerous intensive operations going on within each ‘frame’ of your game (e.g. custom blocks with no screen refresh; checking if touching - esp. touching a colour; sprites/clones that change something about their looks all the time - costume/size/effect/rotation/etc. - even if hidden, or even if the ‘new’ setting is the same as the current one).


It's always important in any programming language to investigate what is particularly intensive and find ways to avoid / work around it - you simply can't expect to be able to do intensive operations all the time and get away without some form of performance impact. (For example, working out all the operations to rotate the points/lines/fills/bitmaps/etc. of a vector costume is really quite computationally demanding!)

Despite the fact that Scratch is meant to make things as simple as possible for new programmers, it's still not possible to avoid such a fundamental issue when it comes to making good-looking games.

In fact because of the very nature of the way that Scratch works- that it's so easy to add all sorts of effects and things - it actually makes it easier to produce badly optimised games! It's rather unfortunate that's the case, and I see a lot of Scratchers fall into performance traps - I've only discovered them myself the hard way…

Often, just having in mind some of these performance ‘traps’, while putting together scripts (and it's not hard to see a different approach to some of them), is enough to help make a game do much less work during each ‘frame’ (which itself actually reduces the keyboard lag problem a lot). Even without the keyboard issue, it can turn a slightly ‘choppy’ project into one that's pretty smooth. Occasionally, it's even more dramatic.


Looking at your latest project I can see several places where you could take a different approach that would probably help performance quite significantly. If you want, I can take you through them…? Let me know, anyway!


EDIT: I wonder if it's worth me making a new topic: “How to improve your project performance”, or something like that…?

I'm sure learning more about these methods of optimising performance would be very helpful for a lot us, including myself. You could certainly make a thread devoted to it if you wanted to. I fear the issue I have (8 detailed vector sprites rotating constantly) may be, uh… past the point of optimisation, you know?

It's certainly a bit of a challenge to have so much going on in a game and keep within the scratch 1/30second frame speed (once you take longer than that per frame, the infamous keyboard lag can start to become an issue…)

But I can give you one big hint straight away that could make a pretty significant difference to your games if you implement it in the places where you're doing this: when you hide your sprites, don't have them carry on changing. -At the moment, you have various ‘forever’ loops in various sprites, and within them you have the sprites' costumes (or something else about the costume) changing all the time.

But that's all still happening even when they are not visible - and Scratch is still going through all the calculations ready to show the new/changed costume on the screen, and even in the case when the costume has not actually changed (which I consider to be something of a bug in Scratch - that could really do with being fixed…) - one example: those buttons, which are constantly running the “switch costume” blocks (but only actually having a different costume when the mouse flips between ‘over’ and ‘not-over’ the sprite), and it's happening even when hidden.

Two simple ways to fix such things… first, for those buttons that change costume, instead of “if touching mouse-pointer” use “wait until touching mouse-pointer” - then switch to “lit” - then use “wait until not touching mouse-pointer” - then switch to “Normal”. That way the costume change only happens when the mouse pointer moves on or off the sprite.

Second (and this applies more generally - in particular, to your razor sprites), at the moment your loops start from green-flag and keep going all the time, continually changing costume and things (e.g. rotating all your razors all the time). Instead, only have them start when they receive the broadcasts for the levels they are on. Then when they receive the broadcasts for the levels they are *not* on (where they currently only ‘hide’), also have them ‘stop all scripts in this sprite’. This will mean those sprites are no longer doing anything when hidden, but will show and start running again on the appropriate levels.

One way you can see how much work is happening behind the scenes is to run the game while in the editor - you see loads of costume changes happening (e.g. your lasers, your pipe flames, etc.) even though most of them are hidden.

OK, unfortunately, it's rather tedious, and will take a bit of time, to go through and make all these changes for a more ‘mature’ game with so many sprites and levels as you have already in there - but if you keep these techniques in mind as you create scripts in future, then I don't think it's really that much harder to make games which will perform better.

Anyway, hopefully, you get the idea from those examples - I expect you'll have a better idea of places in your scripts where you do similar things, so can sort them out yourself. I think you'll find that your games (which are looking good, BTW!) become noticeably smoother once you've hunted through and made such changes.

Let me know if you have any questions about those. And I'd be interested to know how much difference it makes if you do try out those changes…

(Phew, that was a bit of a marathon post!)

Thanks a great deal for the tips. However I should probably say the game I was focusing on was one I released publicly just a few hours ago. I made use of some scripts to try and minimise things happening with sprites when it isn't its level (ie. time to shine) but it's nothing close to perfect. I made it so that all scripts are ended for sprites if the level is past their designated one (ie. a sprite in level 6 ceases to operate when the player reaches level 7).

Once again, not perfect but it was an effort I suppose.

acedannyk wrote:

Thanks a great deal for the tips. However I should probably say the game I was focusing on was one I released publicly just a few hours ago. I made use of some scripts to try and minimise things happening with sprites when it isn't its level (ie. time to shine) but it's nothing close to perfect. I made it so that all scripts are ended for sprites if the level is past their designated one (ie. a sprite in level 6 ceases to operate when the player reaches level 7).

Once again, not perfect but it was an effort I suppose.

I assume you mean Clockwork? It looks a very nice game but yes does suffer from lag. DOML is correct though and you do tend to use lots of events that enter forever loops which is just wastefull of cpu cycles. For example your score system. Each numeric sprite (that's four of them) is looping around a forever loop just to maintain a score. You should just do a broadcast to update the score when the score changes.