It's going to be a big problem, these images..

[Djidjey]

Good morning !

First, did you receive my donation? I was debited, but I have not heard back from you..

My project encounters a problem: Its large quantity of images (+/- 500 per character, we quickly go up to 5000/10000). Which means that on "normal" computers, my project takes about forty seconds to open, on the slowest computers, we can go up to 2 minutes, knowing that there is still only a 10th sprites!

Do you know of any alternatives to allow the project to launch without some images being read, while loading the images little by little?

Best regards

[GarboMuffin]

Your donation made it to the right place, don't worry. It is very appreciated.

I had to revert some optimizations that helped your project (lazy bitmap GPU upload) because they were causing some issues. When I have time, hopefully I can look into those

[Djidjey]

Hello,

I unfortunately think that optimizing the images will not change much due to their numbers which will exceed 5 digits. Is it possible to modify the Electron packager in order to cancel the loading of certain sprites (Boss, cinematics, ...) and add an extension to load the images in the RAM when the game needs them?

Have a great day

[GarboMuffin]

At that scale it sounds like the way forward will be breaking up the project into a bunch of smaller sprites that can loaded as needed, or reducing scope of your game. I'll put this issue on the weekend list.

Is your game designed in a way such that you could have the base game with only the menus and player sprite, and have each individual boss/enemy/whatever sprite loaded separately before starting levels? Currently you could make this work with custom JS, although unsandboxed extensions will probably provide a much better way do this in the future.

[Djidjey]

I translated your answer with google translate, so sorry if I messed up a few points.

Yes, the goal is that the main sprites are loaded when the program is running, and that the other sprites, such as player sprites (because there are also a lot of them), cutscenes, etc., are only loaded during loading time and for the duration of the game.

[GarboMuffin]

There wasn't much time this weekend to fit this in and my initial idea wasn't going to work without some very drastic changes, unfortunately

That said, I am pretty confident I can make this work a lot better. It's just going to take some time. Busier than ever.

[Djidjey]

I don't understand worries!

I have a small idea how to do this (with extensions), add a "Load sprite" block as well as a "don't load sprites" plugin. When the program starts, no sprite is loaded, and when I do for example "When flag pressed > load splash screen sprite", all the sprites, sounds and code of the splash screen are loaded and remain stored in RAM

This way, the game will be much more optimized, much faster to start, and much easier to code.

Tell me what you think about it! Have a good evening

[GarboMuffin]

Good news. I've had some time to prototype this. It's definitely possible. I have something locally that mostly sort of works. It's not ready yet though.

My little prototype has blocks like these:

Might add another block for controlling whether a certain sprite should be lazy loaded or not or it might end up being a more native part of the interface. The blocks will wait until the sprite or entire folder is loaded before continuing. Do you think those would be sufficient for you?

[Djidjey]

I came to re-read my last message, I meant "I understand, no worries!" instead of "I don't understand worries!"

What you have done is just amazing, even the donations I plan to give you cannot thank you enough.

I'll have to test that, and I'll let you know.

Once again thank you very much 💜

[GarboMuffin]

Following discussion in https://github.com/TurboWarp/packager/issues/566 we should also have an unload block.

[Djidjey]

Good morning ! It's just to ask where the development is, to know if it's progressing.. Nothing in a hurry! Take your time :)

[GarboMuffin]

I worked on the prototype a bit more. It seems to be almost usable now. Hope to have good news soon.

[Alestore]

Good news. I've had some time to prototype this. It's definitely possible. I have something locally that mostly sort of works. It's not ready yet though.

My little prototype has blocks like these:

Might add another block for controlling whether a certain sprite should be lazy loaded or not or it might end up being a more native part of the interface. The blocks will wait until the sprite or entire folder is loaded before continuing. Do you think those would be sufficient for you?

Could you also add a "wait until Sprite (or Sprite folder) loaded"? It would be really useful for making the loading screen perfect!

EDIT: Sorry, you said that the script won't continue before loading them. My bad.

[BlurryKnight]

This looks amazing :D Looking forward to it! Could you maybe add a variable that shows if ANYTHING is loading right now? To make stuff like an automated loading screen when things load

[BlurryKnight]

Oh by the way, would a block like "Set automation for this sprite to [visible only, scripts only, all, off]" be possible? So loading and unloading a sprite can be automated?

[GarboMuffin]

Merry Christmas everyone, I have a usable proof of concept now

By default sprites are treated the same as normal Scratch. The bottom block can be used to mark the current sprite as lazy loadable the next time the project runs similar to how the "set drag mode" block works. When the project loads, lazy sprites only load their first costume, are hidden, and their scripts won't run.

The top two blocks can be used to load sprites. The blocks wait until costumes and sounds finish loading. Note that for folders, not all sprites will necessarily load at the same time for now. When a sprite loads, its green flag event handlers are automatically run and it will be able to receive things like broadcasts.

If you open a lazy loaded sprite in the editor, it'll make you load it before you can edit it.

This is still rather shaky and I really don't like how the code looks or functions. It has absolutely no automated tests. You could very likely experience data loss if you touch it in the wrong way. Make backups and be careful. At this stage it's best that you just test if these blocks would work in your games. I do not recommend that you start trying to use these in your final projects quite yet.

Once you've read all that, consider testing it: https://experiments.turbowarp.org/lazy-sprites/editor

If feedback here is good, might be able to get this into staging as soon as 7 days from now.

[Alestore]

The work you have done is absolutely amazing. I'm going to donate something this month because you really are amazing. I will try lazy loading on a backup of my game that already has loading screens ready today or maybe tomorrow. Thanks, and Merry Christmas. 🎄🎁

[Alestore]

@GarboMuffin What about UNloading blocks? Have you figured out how to implement that? You're doing an awesome work so take your time, just wanted to know about this :)

[Djidjey]

Hello, Merry Christmas ! do you have a desktop version of this "test" version containing the lazy feature? Above all, I develop via the application.

[GarboMuffin]

Hi all,

To put it bluntly I did forget about this for a while. But I will be trying to get this in very soon -- I've been thinking about some of the harder parts of this (unloading) and am pretty sure it should be straightforward. I've got a list for the weekend (trying very hard to keep make sure those are unobstructed) and this is right at the top.

I will remind readers that https://experiments.turbowarp.org/lazy-sprites/editor does still exist and still works. Has anyone actually tried this on any projects? Just to see if the loading is lazy enough for you and if the given blocks are viable for your project.

Thanks for your patience

[Alestore]

Hi all,

To put it bluntly I did forget about this for a while. But I will be trying to get this in very soon -- I've been thinking about some of the harder parts of this (unloading) and am pretty sure it should be straightforward. I've got a list for the weekend (trying very hard to keep make sure those are unobstructed) and this is right at the top.

I will remind readers that https://experiments.turbowarp.org/lazy-sprites/editor does still exist and still works. Has anyone actually tried this on any projects? Just to see if the loading is lazy enough for you and if the given blocks are viable for your project.

Thanks for your patience

Hi, I'm going to test the experiment very soon this week and I will share all my thoughts on that. I think this is a major and sustainable priority for developing big projects on TurboWarp.

[Djidjey]

After some testing, I can confirm that Lazy Loading works. In any case, I didn't have too many problems, on the contrary, it brought optimizations to my game (even if it ended on an Out Of memory, the fault of its too large number of calculations)

If I change my sprites to .png instead of .svg, will the game gain performance? I remember a conversation where you told me that the loading time and performance will be 2x better.

thank you for your work

[Djidjey]

Sometimes, it open without any issue. And sometimes, i have this.

[Djidjey]

Hello. i will send you the game converted as a .exe. When you will start it, go to "mode histoire", then, go to "TestZone : Vs.Cyaneps". The start will automaticly start. You can use " Z Q S D" to move around, "space" to shoot and [Look at the mail, i cannot say the thing here. i know some of my players read these conv, looking for spoils]. Normally, after some times, the game will crash. So can you try adding LazyLoading and the optimisation and looking for if its crashing ? (The things to not LazyLoading is gonna be sended to you in the mail)

Also, can you please tell me what i have to change for optimizing my game ?

Thank you and have a great day

[Alestore]

Hi I just wanted to know if this extension is still in the works as I haven't heard of it in quite some time.

I would like to help if possible as I really care a lot and this would allow you to create really great games and projects with TurboWarp.

One of the suggestions I made a while ago was adding an "unload this Sprite" block, in such a way as to save RAM for other Sprites to load.

@GarboMuffin please let us know something about it, no pressure! Just wanted to know something :)

[GarboMuffin]

One thing that's become apparent is the original approach in the lazy-sprites experiment just isn't going to work now that we have all these extensions, and it was a bit silly in the first place (designed around a very bad set of constraints. sprites were only like 90% lazy loaded, for example)

I have a new idea for how to do this as well as much more insight about what problems I need to design for. should have a brand new experiment in a few days here

It will not be in desktop 1.9.0