Long Compile/Preview Time

I'm working on a game that is fairly large (exploration platformer), using high resolution graphics. I'm trying to be as efficient as possible (keeping textures in power of 2s, loading large textures at run-time etc.) So far .Cap file is 32MB. I would say the game has about 200 unique objects. I have no problems with loading/saving the game or using CC editors.

However, every time I preview the game (layout or all) i have to wait exactly 2 minutes before the game is ready.

I can handle the 2 minute wait, even though it gets frustrating when fixing bugs. However since only about 1/4 of the content is in the game I'm worried about how long this preview time is going to get and the game continues to grow. Like I said, nothing else about CC runs slow, just the preview.

Is this normal? Is there anything I can do to speed it up? Are there any best-practices to help prevent this in the first place?

That's one of the many reasons I tell people to use c2. My game, loot pursuit, takes somewhere around 3-5 minutes to preview. CC caches the graphics after the first preview, which speeds it up a little for consecutive previews as long as all you changed was code.

Having big images in particular makes it take a lot longer to preview. I reduced the preview time in my game quite a bit by loading large background images at runtime instead via the sprite's 'load frame from file' action.

Edit: oh, you already are loading them at runtime. Sorry, but I don't know any other tricks to speed up preview time. :/

I was afraid of that. :(

Well I may have a decent solution. I stripped down a version of my game to include only the parts it needs to run (basically removed all tiles and background pieces that don't interact with the game). It now previews in 20 seconds. I'm going to code parts of my game in this stripped down version (like a boss fight for example). And then once it's working, re-create the objects and events in the full game. That should help speed up the process. I've heard that I shouldn't directly copy/paste events and objects from different .CAPs but even re-coding the events would be faster than waiting 2 mins for every preview.

Also, another question. Is it possible to load an entire animation for a sprite at run-time? It seems I can only ever get it to load 1 frame at a time. Thanks again for your help!

I guess that's one way to do it! I suppose you could also leave the objects in so you can code them, but delete the animation frames instead, or reduce them to 2x2 pixel placeholders.

Correct, don't copy and paste between .caps.

To load an entire animation at runtime, iirc you need to first set the sprite's animation frame, then load the image for each image in the animation.

Arima,

I tried your method of loading animations with no success and also couldn't find anything about it in the forums.

This is what I tried:

http://gyazo.com/f6f41a4c4f0795815a7b0a956f881284

*edit* and that event was originally set for "Start of Layout"

It seems like it can only have 1 frame loaded at a time. Any other advice on how to do this would be appreciated.

Are you sure the file paths are right? Try having the images in the same directory as the .cap file, and this code should work:

(Have a sprite with 2 animation frames in the layout)

System: Start of layout

• Sprite: Set animation frame to 1
• Sprite: Load frame from apppath & "file1.png"
• Sprite: Set animation frame to 2
• Sprite: Load frame from apppath & "file2.png"

System: Every 500 milliseconds

(this and the next event are subevents)Sprite: Animation frame Equal to 1

• Sprite: Set animation frame to 2

System: Else

• Sprite: Set animation frame to 1

Hey, Sorry I didn't reply sooner. (this was the first chance I've had to try your suggestions). It worked! My problem was that I had not already created the extra (blank) frames in the Sprite object. Thanks again for your time.

Np, glad it worked.

I'm resurrecting this old thread. I've been struggling with long compile/preview times for awhile now and I finally made a breakthrough that is both good and bad. I'm hoping I can solicit some advice on how to mitigate some of the bad.

First, let me explain:

I discovered that my long preview time (which affects the final exe's startup time) is a combination (and compounding) of two things: A lot of events and a lot of layouts. Now that seems self-explanatory, but it's a little more complex that that. It seems that what's happening is that even though each layout is referencing the same event sheet includes, it's compiling those events for EVERY layout - even though they are referencing the same events.

Here's how I know: I didn't touch the events at all. I simply made another blank event sheet. Then I made every layout (except for 1) use the blank event sheet. My preview time went from almost 3 Mins to 20 Secs!! (and this is with about 50 layouts and 5000+ events) This discovery is HUGE for me. It's going to make developing the game so much easier as I can simply turn on the real event sheet for whatever layout(s) I'm currently working on.

However, this doesn't do anything to fix the final build's startup load time (which will have to have the real event sheets turned on for each layout). So, outside of creating a level editor (which is something I may end up doing) I'm not sure what I can do to fix this.

If there was a way to add event sheet includes at runtime it would probably be the easiest solution but I don't know of any way to do that. Would something like that be possible in Python?

Does anyone have any suggestions?

You are correct, I recall Ashley stating that an include in CC just pastes a copy of the events when compiling, meaning it compiles multiple copies of the included event sheet. I don't have any other ideas how to improve things, though.

robit_studios

Hmm, the game shouldn't be compiling after it's exported though, does it take a while to open the exported EXE too then?

Also, I don't believe there is a way to load event sheets sadly, but you could use Python scripts to do things (this is going to sacrifice in-game performance vs. the startup performance though).

The level editor seems the best way to go, as you could use one layout to load all the objects. If you'd like to see a way of loading all objects (and even graphics) from files you can grab the engine source to my Alpha version of I Had Hope (extra plugins needed are also on the download page): http://ihadhope.blogspot.ca/p/download.html

As an extra option, you could make a mini "loading game/exe" that runs and when the other game opens you can close the loading game (I know of opening files from CC, not sure how to handle the closing though).

Hope that helps!

I don't know what's happening as the EXE loads, but, not only is the export time significantly reduced, but the EXE load time goes from about 53 seconds to 3 seconds.

Also the EXE file size went from 88MB to 38MB.

Again, I did not remove any anything. I simply pointed all the layouts to a blank event sheet.

I really wish I could find a solution for this - it seems too simple.

Jayjay thanks for the link to your level editor - i'll check it out.

Arima I didn't know that was what was happening until today. It seems like a fairly inefficient way to do things. I guess that's why they started over with C2.

It's an architectural flaw in Classic. Including an event sheet literally means "copy and paste the entire event sheet's events here". So if you have 100 levels each including a common sheet, the common sheet is exported 100 times in duplicate. So if the common sheet has 500 events, in this case it exports (and generates on every preview) 50,000 events.

There is no chance of this being fixed in Classic, but it's fixed in C2, where we have a proper include system where an include references the same sheet rather than duplicating it. This keeps previews, exports and load times fast.

Ashley Thanks for taking the time to respond, even though it's disappointing to hear. I'm a big fan of C2 - I've been a supporter from early on but it was still too fresh in development when I started my game a year and a half ago. Switching over now would be difficult to justify.

Do you think there's any way, using Python, to get a layout to choose which sheet it's referencing at runtime? If it's an architectural flaw, there's probably not, though.

Looks like my best solution will be a level editor and just have one layout that runs everything - it's a lot of work, but it'd still be a lot easier than porting everything to C2.