How to split large backgrounds for performance

Hi, can anyone advise in this? I want to make pretty large (1920*1080) backgrounds as a single image, but it seems to be giving a performance hit. I can split into 4 small images and then set them up manually, but that just seems like a massive multiplication of assets and effort. Especially as I’ve only got a few levels now but am hoping to have rather a lot in the future. I’ve got a little JavaScript for Photoshop that will automatically cut up the large images
and save 4 separate, sequentiality numbered files. Is there a sensible way to set up my levels so I can minimise the workload and number of assets? I don’t know if some clever use of tilesets, or different instances with different animations might work. Also, I do need to be able to see the level in the editor, so an events solution that displays them correctly at runtime but not in the editor won’t work.

Hi Adam. I can share my experience with this, based on things I have tried.

I implemented a feature in my game (2D platformer) where the player will get a full-screen image when they examine certain things. So the player might examine a book on a shelf and they get a full-screen image of an open book and the text inside. The image is 1960 x 1120 - just slightly larger than 1080p. I have done it using a sprite object with 2 animations: 0 is empty and 1 is the image. It’s on the scene when the game loads and I just change the animation in an event i.e. I don’t create it or show it. It is always on the scene.

I haven’t split the image into pieces because it’s not going to be scrolling, unlike my main environments that I do chop into pieces of about 300 x 300 max (more on that further down).

I haven’t noticed a performance issue since I implemented this. The player can open and close the full-screen image and carry on with smooth scrolling afterwards. The image is about 150kb because I squeezed it down with a PNG optimizer.

I know it’s generally a no-no to have large images, as image guidance goes, but when it’s a relatively small filesize and it’s not animating or being created with an event, it seems to be absolutely fine. I’m not saying whether what I have done is a good way or not, but it’s working for me so far. My game, though, is for desktop PCs and not for mobile devices, and I imagine performance concerns with large images become much more pressing on mobile devices.

For scrolling levels, the cutting up of images in Photoshop and them putting them back together in GDevelop is time-consuming, for sure, but I get lovely smooth scrolling and no hitches by doing it that way. I have all the images in one object and change their animation on the scene to rebuild my artwork. I’d absolutely recommend this approach if you are not using tiles i.e. you are using a large piece of artwork for you level. It’s the difference between classic Mario (tiles) and Night in The Woods (large artwork). The latter approach gives you more creative flexibility, but does come with set-up drawbacks. I’d imagine, for example, dropping a large 4000 x 2000 image into GDevelop for a game level is going to cause issues unless you chop it up.

This thread might be of interest

And GDevelop wiki image guidance


Thanks Jason, I really appreciate it.

It sounds like what you are saying is that at 1080p the image size is unlikely to have an impact on performance, but that if I do want to chop images up (in the thread you linked to he was chopping them up to 32px square I think!), I’d need to do it manually, or maybe write some code to do it at runtime, but there’s not way to do it in editor.

If you’re using photoshop, there’s a slice tool. If not, you can use an online image slicer.

Thanks @kikiki but I already figured a way to do that. My issue is how to import and recombine in GDevelop, and if there’s an easier way than manually lining everything up. But it sounds like it might be a non-issue?

If you have a single, non-moving 1920x1080 image, slicing it up shouldn’t be an issue for most devices, but may have issues on older mobile devices (which had texture limits of 1024x1024).

If you have dozens-to-hundreds of 1920x1080, you will likely run into GPU memory issues on some computers. As far as slicing and placing them, it would be fully manual, yes.

Thanks @Silver-Streak thats very clear and at least I know what I’m looking at. I am planning quite a lot of these, so I’ll look at a good method for slicing. Maybe use the full image to lay out the level then slice and write something to lay out the images automatically at runtime? Anyway, that’s a way down the road. Thanks again for the clarity :slight_smile:

1 Like

Hi Adam. 32 x 32 is an extreme example, involving a very large level that CorianderGames had performance issues with. The thread is also a few years old. Perhaps changes to GDevelop since then will have had a positive impact on performance generally.

I cut my levels up into max 300 x 300 and my game runs fine. My largest level (so far) is 4260 wide, 1120 high. Please don’t spend weeks cutting your artwork into tiny pieces when you don’t need to :slight_smile:

1 Like