How to make code run faster when using a lot of lists?

[sirders]

Thank you so much for your help. I'll look into hyper blocks.

The (i) = (spawnNum) check is necessary otherwise the objects include their own hitbox as colliding with another. I copied your for (i) = length of objectData script and it didn't work initially since the enemies were constantly colliding with themselves, but with the the extra if (i) ≠ (spawnNum) check, it works. However, it slows things down a little since it always has to check this.

I'd prefer to use the for each ((item)) in [list] block because I assume that's faster, but I'm not sure how I could implement the spawnNum check into that since it relies on the (i).

[ego-lay_atman-bay]

I'm guessing you're using clones, right? If so, you can set a sprite local variable to the object info, and put that same list inside the (objectData) list.

Now, with this method, you need to make sure not to replace the item in (objectData), or set (my data), because this solution is going to use linked lists.

Now that we have a reference to the object's data, we can filter the (objectData) list and keep all the items that are not identical to (my data) (checking if they're identical checks for the reference in memory, not whether each item is the same).

While yes, this does mean we loop over the list twice, the first time to keep the current object's data out of the list, then second time is where we actually check for collision, it's not in vain though. I'm pretty sure keep does run much faster than the for loop, so it may not cause more lag.

If it does cause more lag, then you could try keeping the check in the main loop. Now, if you still want to use the for ((item)) in [list] block, you can still keep track of the index.

Basically you just gotta do a lot of testing with different methods to find the one that works for you. The great thing about the linked list method, is that you can delete items from (objectData), and you don't have to decrease (spawnNum) if the deleted object was above the current object.

Oh, and if the objects are clones of the same sprite, I think I have some ideas on how to speed things up even more.

[qw23]

Some additional remarks:

• it strikes me that touching enemy? uses variables (objectData, spawnNum) that are not in the block's argument list - or actually: there is no argument list. It may not hurt execution speed, but it's something you'd usually want to avoid so as to prevent error, especially in multi-process environments;
• I'm almost sure you can optimize the calculations further by systematically employing hyperization of + and - operators; (perhaps best if objectData is transposed using columns of);
• you could replace the if-block with report [the composite condition]; it's not really faster, but it looks better;
• why not place report false inside the warp cavity?
• if you want to measure execution times, you can use blocks such as
  .

[sirders]

Yes, the objects are clones of the same sprite. If you have some ideas on how to speed that up, maybe you could also speed up the way I'm displaying tiles. All the tiles are also clones of the same sprite. I haven't mentioned it because I thought it'd be too hard to tackle, but the way I'm displaying the tiles is causing most of the lag.

I'm cloning them in a 16 x 13 grid, plus one more which acts as a brush for editing levels, for a total of 209 tiles. The way it works is it reads a list called tileGrid and they set their costume and properties based on that. When tiles goes off screen, they loop to the other side. Also the tile costumes are 32 x 32 pixels.

All tile collisions are actually based on the tileGrid list, so I can delete all the clones and play on an invisible level. The clones are only for visual.

Upon deleting the tile clones, the frame rate improves significantly, reaching 50-80 fps, even with a few objects on-screen. It's not until around 9 objects are on screen when the fps drops to 10-20.

There are probably several better strategies to display the tiles but I'm not sure what.

Again, thanks for your help

[ego-lay_atman-bay]

What is the code you use to display the blocks? If that's what's lagging, then maybe there's something that you can do to optimize it.

Of course clones in snap are just slow in general, so you could try stamping the blocks in their position all in one sprite, rather than using a bunch of clones.

[mr_owlssssnap2]

Okay took me a while to find it, but this is a screenshot I took on an eaglercraft server late 2022-early 2023

[sirders]

The stamps look blurry so I'm avoiding them for now. When the game is finished I might give the player the option to choose between stamps or clones. Though I'm not sure how much faster stamps would be since the one tile that's stamping the whole screen would have to check the tileGrid list 208 times per frame.

As for the code displaying the blocks, a lot of it comes from this griffpatch series:

However, I've added a lot of my own code and that's probably causing a lot of the lag. I think I'll ask for help on optimizing how the tiles are displayed in a separate discussion post when an early version of the game releases, (which I estimate will probably be in 3 to 6 days). If you happen to know of any other Snap! games that use a tile grid system, linking them here would likely help.

[ego-lay_atman-bay]

@sirders

As for the code displaying the blocks, a lot of it comes from this griffpatch series:

Oh yeah, I've watched that, so I know how it works.

@sirders

Though I'm not sure how much faster stamps would be since the one tile that's stamping the whole screen would have to check the tileGrid list 208 times per frame.

Believe me, snap is way faster at reading data from lists hundreds of times, than rendering clones. Seriously, stamping would probably be a whole lot faster, as snap doesn't need to run code for 208 clones, it only needs to run it for 1.

The only issue I can think of is, you'd have to store the current state, and animation state in the list, which the sprite stamping the blocks would have to read in order to allow for you to hit a block, and the block to be able to be offset from the grid.

@sirders

The stamps look blurry so I'm avoiding them for now.

Yeah, that's the biggest problem. The only other solution I can think of, is merging all the block costumes into one large costume, and displaying that instead of stamping, but that's very complicated, and unnecessary (also I'm not sure how much performance that would gain).

[sonic123cdmania]

HOLY CRAP!
For what @ego-lay_atman-bay said,

@ego-lay_atman-bay

is merging all the block costumes into one large costume, and displaying that instead of stamping, but that's very complicated, and unnecessary (also I'm not sure how much performance that would gain).

Yeah, I agree. Complicated? Check. Unnecessary? Check. Should it be done? Well, that depends.