Worried about increasing preview times.

From what I understand, it is what is on desktop (veiwable) so shouldn't be a problem.

They don't show all 100,000 frames at once

That's good. A typical animation in this type of game might have 30 frames, and that's for each direction. With 8 directions, that's about 240 frames for one animation. The main character is going to have probably going to end up with just under 2,000 frames. The enemies won't have as many because they won't be able to do as much, but still a bit. Then, factor in an extensive HUD and environment graphics, this is why I start get worried when I hear anything about limits.

But if it's like you say, then it shouldn't be an issue. Each layout is only going to have the character plus 1 to 3 enemies since I'm going with smaller levels (each room will have doors and lead to other rooms on a separate layout). All in all, probably 50 to 100 rooms altogether when I get done. I'm building a full castle.

Was snooping around temp files in appdata\local\mygame and noticed that there are thousands of 1-150kb files being created in \cache each time I preview. One file per image frame, it seems. That...doesn't sound good...? On my SSD too...great.

Well, I finally broke down and made a second version of my project that has minimal animation frames. I also deleted some objects that probably won't be in the full game. I got the preview times under 10 seconds.

The downside is that I can no longer enjoy full animations, so there will still be things I want to use my full project for.

As my main project goes on, there will be more animations and level graphics. I figure load times will easily get over a minute.

So, having a second version that can load fast will help for testing or tweaking. On the other hand, it means I have to copy things back and forth, and keep both up to date.

Tokinsom

With modern SSD's the support hardware will likely give out before the flash cells will, unless you are running a server on them.

DrewMelton

If what Tokinsom is saying is true -- and why wouldn't it be -- then previewing to an ssd would speed things up immensely. Probably in the range of a 6-8x improvement.

SSD's can read/write small files extremely fast; that's their biggest advantage over traditional hdd's, and why programs and OS's start so fast on them.

Ashley

Would there be any way of adding a feature where we could specify where preview files are generated? That way users with their OS on a HDD could preview to an SSD without having to migrate their whole OS.

TiAm - you'd be crazy to have a HDD and SSD and not put the OS on the SSD.

Ashley

Agreed. I guess it's what you'd call an 'edge case'.

TiAm - you'd be crazy to have a HDD and SSD and not put the OS on the SSD.

People actually do that ?!??? Wouldn't that be similar to owning a car and a truck, but using the car to move all your furniture?

— no its really better to have TWO ssds; one for the OS and one for everything else

People actually do that ?!??? Wouldn't that be similar to owning a car and a truck, but using the car to move all your furniture?

Ha, nice analogy

Is it perhaps possible to have an extra preview option ?

A preview where it tries to reuse previously exported image sheets.

I would imagine this could be very handy where people only tweaked some logic settings/events.

Perhaps the image editor could make some sort of a time stamp when the last image is edited/updated in the project, and if the time stamp was unchanged since last preview, reuse the previously exported images.

If that would work, it could significantly reduce preview loading times for those with large amounts of frames/images in their projects.

The only time where my previews became annoyingly long, is when I used lots of decently sized images for animations and all the sprite sheets require exporting each preview run.