Is there a way to compress a tilesource in memory?

I have a tilesource which is 56kb (as a compressed PNG.) However, it measures 512x512 pixels. I would ideally like to expand this to be quite large. The tiles themselves consist of essentially only two colors but each tile is 64x64. Is there any way to compress this texture or perhaps only load a certain section of it at a time? Here’s a screenshot of the asset I’m trying to compress:

I am planning to make a map like this, but I would like to reveal only tiles the player has seen, and also overlay some icons on top of the map. I know Defold doesn’t support vector graphics, but maybe there’s a way work around this constraint somehow?

1 Like

I understand that when the sprites are executed, the compressed space in the file is released in the same way in the memory, although I am not sure if this always happens, at least when I render a 3D model this happens with its textures.

1 Like

Yes, you can use the texture compression feature and for this specific tilesource apply compression and maybe even set a max texture size.

This is not supported. You would need to use multiple textures or tilesources and load them dynamically using a collection proxy or collection factory.

2 Likes

Thanks, I found the texture profiles feature. I didn’t realize this could be setup per file! That’s great. I’ll use this to compress the map texture to save memory :smiley:

EDIT: I see messages like “WARNING:RESOURCE: Unable to create resource: /_generated_21cdeee8.texturec” but there’s no indication of which resource is unable to compress. I’m using RGB etc1, best, and Webp as the settings based on reading the article. Do you know if this combo of settings would require square textures? That might be the issue. I believe I remember reading Atlases automatically generate as square textures by default but I have some particle fx graphics which might not be perfect squares.

EDIT2: I’m also wondering, does Defold use a library like https://github.com/facebook/fresco or https://github.com/bumptech/glide to re-use bitmap memory? Maybe this could improve Android performance or allow for more assets in the game as a whole (although not concurrently.)

1 Like

It’s a bit unfortunate that the atlas name isn’t shown in that error message.

Atlases generate square textures, yes. The images inside the atlas doesn’t have to be square.

No, we don’t use anything like that. It’s not very portable to the other platforms.
Are you having problems with your Android performance?

Slightly, the game runs fine on the phone I use day to day. However performance on my last smartphone (a Moto G5 Plus) is fairly slow. From profiling:

desktopprofile.pdf (913.6 KB)

I’m seeing that unfortunately the major source of lag is due to the amount of engine usage. This is in a fairly large level with a lot of entities. In smaller maps memory is roughly 40% of this and there aren’t any performance issues. Also I’m noting that “Engine.SoftwareVsync” is taking up almost 10 ms per frame of time, even though I have Vsync disabled and a framecap of 60 set. I’m not sure why that is.

I’m guessing frustum culling would probably help a bit. Also, I know that the AI code I’ve written is likely a high demander (although I tested a map with roughly 100 enemies on my phone and it surprisingly runs smoother than this certain map which is large in dimension and contains many 3D models.) That leads me to suspect that the off-screen rendering is the source of the lag.

Yes, frustum culling will help, but it’s not on our nearest roadmap.

In this case I suggest start looking at the number of draw calls (111) first.
I think there are a lot of savings to be had there.

1 Like

For reusing models though, we really want instancing. Otherwise each model will get a separate draw call.
For very simple models, it might actually be faster/cheaper to use world space vertices (i.e. the models will be batched into a baked vertex buffer).
Worth a try.

1 Like

Thanks so much for the suggestion! I set the static colliding decor objects in the map to World space vertex and now draw calls are roughly 60-70 per frame! :smiley: It’s running much smoother now.

EDIT: I’m guessing instancing will help in cases like this? :stuck_out_tongue:

2 Likes

Yes, when using the same model/uniforms, with only different transforms, instancing is the preferred way.

I’m glad it helped!

60-70 draw calls are still a fairly big number, so it seems like there are more gains to be had…

3 Likes

I’ll keep investigating. Do you know if euler-z rotation and world vertex space would cause any issues or extra draw calls? I am rotating some objects to create more interesting strategic variety in some levels. Also, the projectiles my enemies shoot and the enemies themselves rotate to face direction of movement.

1 Like