Long Compile/Preview Time

New releases and general discussions.

Post » Sun Nov 18, 2012 1:57 am

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?
B
20
S
5
G
3
Posts: 65
Reputation: 3,764

Post » Sun Nov 18, 2012 6:58 am

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. :/Arima2012-11-18 07:00:14
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Post » Sun Nov 18, 2012 5:18 pm

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!
B
20
S
5
G
3
Posts: 65
Reputation: 3,764

Post » Sun Nov 18, 2012 7:34 pm

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.Arima2012-11-18 19:35:31
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Post » Tue Nov 20, 2012 11:35 pm

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.robit_studios2012-11-20 23:36:33
B
20
S
5
G
3
Posts: 65
Reputation: 3,764

Post » Wed Nov 21, 2012 2:16 am

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
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Post » Mon Dec 03, 2012 12:33 am

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.
B
20
S
5
G
3
Posts: 65
Reputation: 3,764

Post » Mon Dec 03, 2012 12:55 am

Np, glad it worked.
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Post » Tue Oct 22, 2013 3:45 pm

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?
B
20
S
5
G
3
Posts: 65
Reputation: 3,764

Post » Tue Oct 22, 2013 4:04 pm

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.
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 1 guest