GameSalad

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Optimizing Art and Preventing Crashes with Preloading

ShineHouseGamesShineHouseGames Posts: 100Member, PRO
edited July 2015 in Working with GS (Mac)

Regarding Preload Art, to check or not to check—that is the question.

The issue is, with multiple actors that each contain hundreds of images for animations, the frame rate slows too significantly if not preloaded. Unfortunately however, if preload art is selected, the game invariably crashes.

My question then is, how may I reconcile this? Are any of you initializing an actor's artwork after the game's startup but before the animation is called? (Maybe running the animation with 0 alpha?)

Comments

  • ShineHouseGamesShineHouseGames Posts: 100Member, PRO

    Bump

  • HopscotchHopscotch Posts: 2,782Member, PRO

    @ShineHouseGames, what dimensions are the individual frames of the animation? Does the game not crash when preload is off?

  • ShineHouseGamesShineHouseGames Posts: 100Member, PRO
    edited July 2015

    @Hopscotch said:
    ShineHouseGames, what dimensions are the individual frames of the animation? Does the game not crash when preload is off?

    The animation is pretty heavy on the processor, but I just wanted to see if someone managed to load assets with their own "load-when-optimal" setup.

    Have you ever heard of someone doing that?

  • The_Gamesalad_GuruThe_Gamesalad_Guru Posts: 9,913Member

    Are you using the animate behavior? @socks has a method for doing it without the behavior.

  • ShineHouseGamesShineHouseGames Posts: 100Member, PRO
    edited July 2015

    I actually used his method originally, but it had some greater lag with it.

    Again, the animation works great when it's preloaded. I'll test out an alternate loading method (i.e. running through the animation with 0 alpha before it actually plays) to see if that has some effect. I'll keep you posted.

  • The_Gamesalad_GuruThe_Gamesalad_Guru Posts: 9,913Member

    Have you thought about reducing the number of frames?

  • FrantoFranto Posts: 779Member
    edited July 2015

    A solution to his would be to let the level load first by turning off preload on all actors, BUT, when the level actually loads, have a white screen with the words "loading" covering the entire screen and at top of the layer so the player can't see behind it, while you have an actor off screen display all images within itself for that level, causing them to be loaded and getting the lag out of the way, once they finish playing all the animations, have a boolean trigger the "fake" loading screen to disappear, and theoretically, you should have a fully loaded level with NO lag any animations that occur since that single actor has already loaded everything while a white screen with the words "loading" distracted the player. You could replace the white image with an illustrated background or designs or something, with the words loading somewhere on it.

    From what I heard, the reason animation lags when not preloaded, is because when the actor first appears and uses those images for the first time, it loads them in that very moment, causing the extra lag from loading the assets for the first time in the level. Any animations of the same images afterwards should not lag.

    Preloading loads everything before the level starts. In my case, this causes the game to take up to 60 seconds to load and just shows a black screen and loading wheel, when I tested a level with most images not preloaded, it reduces the load time to about 20 to 30 seconds.

    That is why I theorize that, if I made an actor that displayed all images of the level within itself and then triggers an attribute afterward before letting the player take control, it will lead to smooth gameplay, AT least with my assets and their sizes.

    If your assets are just too big, they will lag regardless.

    Another reason your game could be lagging is "display text" active, and "timers" can lead to immense lag. When I removed nearly all those things, the game played very smoothly, even with the high res images. I almost switched to using low res pixel art had that not solved the problem.

    Did anybody think of the actor displaying all images for that level trick before? Then again, GS might implement something like that into the system, which is why I haven't actually tried it out yet. {And it might be a hassle to set up.} BUT, it's the only workaround I can think of.

    But hopefully, GS implements something like that into the system? :o

    EDIT: I might try this technique out in a week, it might be the most "interesting" way to optimally load a game without having the player stare at a black screen for a minute.

    I forgot to mention @ShineHouseGames my game use to crash too due to trying to load too many heavy images. Once I reduced it enough, instead of crashing, it just took up to a minute to load with preload still on. There is probably a threshhold where after a certain point, Gamesalad crashes.

    Speaking of loading and performance, I was trying out this game that I was thinking should be heavy on the processor, after 10 minutes of playing, I noticed my android device was extremely hot on one end, perhaps the GS threshhold is required, to keep the device from overheating.

  • ShineHouseGamesShineHouseGames Posts: 100Member, PRO

    @Franto,

    Mate, thank you for such a detailed response. This is quite exactly what I was looking for and, if it does work, would be quite effective in solving my game's loading issues.

    @Franto said:
    ...while you have an actor off screen display all images within itself for that level, causing them to be loaded and getting the lag out of the way.

    How would you specifically display all the images within one actor? Would you individually change self.image to each respective image within the scene, or is there some better way?

  • FrantoFranto Posts: 779Member

    @ShineHouseGames That's the hard part. I'm trying to think or find a very easy and efficient way to do this. Perhaps all images involved in a level's architecture would share Socks naming convention that plays animations, but just for that level. Enemy actors or actors that universally appear through out the game would need an actor to display their graphics before triggering an attribute and destroying itself. That way, you only use these "display" actors for the levels they are in.

    The hard and messy way to do it would be to use the animate behavior and just drag all the images for that level/enemy group into it, and set the animation speed to maximum. Then make it trigger with a self.time rule that is at least a little longer than the time it takes to display all the images.

Sign In or Register to comment.