Currently, I've made a project that draws 1000+ tiles per second, which causes scratch to run on 4-6 FPS, and makes turbowarp run on 20 FPS. However, I want the project to run perfectly on scratch, and not dependent on turbowarp. The player in the project is dependent on a list, but there is a manual mechanic that requires the tiles to refresh in order for it to work. How do I optimize the FPS?

e

e

e

e

e

Share your project or the best anyone can do is make educated guesses. I suspect you have non-refresh loops running in forever loops or similar to have such a catastrophically slow frame rate.

umm…. you may want to use a different system, such as logging X and Y positions in a list individually, and for collision you should make a barrier script which is tile size x+hitboxsize x and y+hitboxsizey using collisions. I am very good at coding and have actually never taken classes or tutorials (if you count the griffpatch tutorial i did 2 years ago and failed making one ) but anyway, log costume, log x and y pos, evaluate closest, and also, big tip: make tiles that are just 4 of another small tile to increase fps, and your method (which looks… well don't 4+5+819+47+81+7) also you could make a simple script that makes a PATTERN of move x (n) and move y (n) which doesn't use tile logging and mapping.

if you need more help, just ask me what you need to be coded, because…. i better a cod becug i had've gooder bren.

oh yes and i am smart because rain world is a thing

That really shouldn't happen trivially unless you've done something wildly inefficient or fundamentally wrong. But we can't diagnose it without seeing the code.

say (something dumb)
switch costume to [dabbing v]

i think i'll just give you you best engine i know : https://scratch.mit.edu/projects/1010428929/

I forgot to explain why the code is way too inefficient, and that is because the engine is a year old and I’ve improved since. I changed the project little by little ever since, but I decided to finish it now, which leaves me here. Since the code is ancient, unnecessarily complicated, and probably took more than 100 hours in total to make, it’ll be a waste of time to start over.

If you still want to have a look at my overly complicated mess, here’s the link: https://scratch.mit.edu/projects/902050204/

e

e

e

e

e

I fail to see why you're refreshing the tiles, but if it is neccessary for any reason, could you perhaps split the tiles into smaller chunks and only refresh them in the chunks which something has changed? The program would likely be way less laggy if you don't do anything to the tiles which does not need updating.

I agree with @yadayadayadagoodbye regarding the redrawing every frame - why are you doing that?

Other than that, you'd save a massive amount of processing simply by storing x, y and c in separate lists. You could remove your lengthy parsing code entirely as it would simply become -

set [CX v] to (item (index) of [CSLIST v])
set [CY v] to (item (index) of [CYLIST v])
set [CT v] to (item (index) of [CYLIST v])

yadayadayadagoodbye wrote:

I fail to see why you're refreshing the tiles, but if it is neccessary for any reason, could you perhaps split the tiles into smaller chunks and only refresh them in the chunks which something has changed? The program would likely be way less laggy if you don't do anything to the tiles which does not need updating.

The reason I have to refresh the tiles every frame is due to another mechanic that uses pen. The level is set to 6, which is the level that does not use the mechanic. If you were to set it to the earlier levels, the mechanic would work. Anyways, if I set it to refresh only when the mechanic is being used, the mechanic glitches out for me. Refreshing in chunks is a good idea that would work without major changes to gameplay, so I may do that

e

e

e

e

e

RokCoder wrote:

I agree with @yadayadayadagoodbye regarding the redrawing every frame - why are you doing that?

Other than that, you'd save a massive amount of processing simply by storing x, y and c in separate lists. You could remove your lengthy parsing code entirely as it would simply become -

set [CX v] to (item (index) of [CSLIST v])
set [CY v] to (item (index) of [CYLIST v])
set [CT v] to (item (index) of [CYLIST v])

The reason is mentioned above for redrawing every frame.
Adding seperate lists is not a problem, but it would need even more decoding, or even encoding. However, the decoding code for showing current tiles is inefficient and I will fix it, which will probably save a lot of code. (398 blocks to about less than 110 blocks)

e

e

e

e

e

UserVeteran wrote:

RokCoder wrote:

I agree with @yadayadayadagoodbye regarding the redrawing every frame - why are you doing that?

Other than that, you'd save a massive amount of processing simply by storing x, y and c in separate lists. You could remove your lengthy parsing code entirely as it would simply become -

set [CX v] to (item (index) of [CSLIST v])
set [CY v] to (item (index) of [CYLIST v])
set [CT v] to (item (index) of [CYLIST v])

The reason is mentioned above for redrawing every frame.
Adding seperate lists is not a problem, but it would need even more decoding, or even encoding. However, the decoding code for showing current tiles is inefficient and I will fix it, which will probably save a lot of code. (398 blocks to about less than 110 blocks)

I'm curious why it would need more encoding/decoding?