Texture Pages: Size or count?

T

Tronco

Guest
I'm sorry if it's an old question, but i'm having trouble finding a real clear answer.

I'm aware of how texture pages and texture swaps work, i flush texture everytime and everything works good with very low texture swaps, i've got only one question:

It's better to have create a lot of small texture pages or to have few but big ones and use all the "space" avaible in a texture page?

Let's say i have 20 levels and every level has it's own exclusive tileset, enemies and resources, but the resources are not enough to fill one entire 2024x2024 texture page.

Should i create a small texture page for every level and use that or should i "stack" a bunch of levels in one big texture page, making a bigger file, and use it even if it contains sprites that i don't need in that level?
 

CMAllen

Member
More pages means more texture swaps and reduced performance. Fewer pages means fewer texture swaps and better performance -- if the system running the game supports texture pages of that size. GMS2 does a better job with texture swaps than GMS1.4, but there's still a performance impact from every texture swap your game performs. So, the answer is 'it depends.' You want to balance page size and count against the way they're used in your game. In your specific example, if everything your game uses in a given level (or multiple levels) can fit onto a single texture page, use one texture page. There's still going to be some texture swaps, because I'm sure there are assets that are shared across all levels (such as UI elements, player sprites, etc) and you don't want to duplicate graphic assets across every level's texture page.
 

TsukaYuriko

☄️
Forum Staff
Moderator
Some general info:

The bigger your texture pages, the lower your game's compatibility with older devices.
The smaller your texture pages, the higher your game's compatibility with older devices.

The more texture swaps you have, the lower your game's performance.
The less texture swaps you have, the higher your game's performance.

The more sprites that will be drawn after another are on the same texture page, the less texture page swaps.
The more sprites that will be drawn after another are on different texture pages, the more texture page swaps.
Essentially, make sure that your draw order consists of, say, first drawing things on texture page A, then B, then C, then D... and avoid drawing from, say, page A, then B, then A again or similar scenarios.

The general consensus that you should keep one stage's (or any other imaginary game chunk's) graphics on one texture page and another stage's graphics on another stems from how texture pages are loaded into video memory on most platforms - they won't be loaded until you draw something that's located on them, then they stay in memory until you flush them out (and they need to be loaded again). As memory usage is often a concern on mobile platforms, this approach will ensure that the amount of concurrently loaded texture pages will be kept to a minimum as long as you flush them after every imaginary game chunk.
The exception to this is the Windows export, as Windows games will keep all texture pages loaded at all times.

Texture page count by itself does not matter. If you're not drawing anything that's located on a texture page, it will not affect your game's performance.
The exception here is Windows, because all texture pages are always loaded into memory. Depending on how much empty space is on your texture pages, this may lead to increased memory load compared to saving that empty space by placing other sprites from other texture pages there and potentially saving space elsewhere.


To answer your question directly:

On Windows, there's not much of a difference.
On other platforms, average memory usage will be higher if you pack multiple stages' resources into one texture page.
 
I

icuurd12b42

Guest
from my experience the cost of a swap is the same no matter the size up to 2048x2048. For windows the target max swap should be about 30. for android the max should be about 8

If you make the page 4kx4k or 8kx8k the cost of the swap will significantly be higher.... so even if it would lower the swap count by half it could actually lag the game more
 
T

Tronco

Guest
The exception here is Windows, because all texture pages are always loaded into memory. Depending on how much empty space is on your texture pages, this may lead to increased memory load compared to saving that empty space by placing other sprites from other texture pages there and potentially saving space elsewhere.
I wasn't aware of that, so on Windows this always happens even if i check the "Create textures on demand" and i flush everytime?

So are you suggesting that under Windows is better to fill all the empty spaces and having a larger texture page where i get Stage 1 + Stage 2 for example?

I'm aware of texture swaps and general behaviour and i'm already very careful. On runtime, my game uses only two texture pages: the one containing all the common elements, like the player sprites, the HUD, etc..., and the other one containing all stage sprites and backgrounds, so there is only one swap with careful drawing.

My game is in low resolution pixel art so in a 2k texture page i've got plenty of room (by the way i need them that big because of an activable HD backgroud overlay, of course i've got it in a separate texture page), and that's my question, if it's better to fill all the empty spaces inside a texture page and cram more stages in one texture page or if it's better to have a separate texture page for every stage.

We're talking about a huge game in terms of graphical contents, so at the moment i have, for example, 20 small texture pages, one for every stage, 1 big texture page with all the common elements and some smaller texture page with menus, cutscenes, etc... It makes a total count of 30 or more texture page. Am i doing right or it's better to keep the count down and cram everything in less texture pages? (As i said, swaps are not an issue because i've designed the drawing pipeline to get only one texture swap in runtime during gameplay)
 

Gradius

Member
> The exception here is Windows, because all texture pages are always loaded into memory.

If you're working with Studio 2 this behaviour can be switched off in the settings. Though generally you're likely to have enough memory to not really need to do so.
 

obscene

Member
Even 1.4 has the option to turn this off... just check Textures on Demand in the global game settings.

On another note...
I've not measured performance based on texture page file size but it's worth noting that the graphics themselves add to the file size of a texture page, not just the pixel size. I would be curious of a texture swaps of a 0.5 MB texture page is faster than a 1.0MB texture page but no idea how I'd measure it accurately. Does file size matter, or does pixel size matter... or do both... when talking about swap time.
 

CMAllen

Member
Even 1.4 has the option to turn this off... just check Textures on Demand in the global game settings.

On another note...
I've not measured performance based on texture page file size but it's worth noting that the graphics themselves add to the file size of a texture page, not just the pixel size. I would be curious of a texture swaps of a 0.5 MB texture page is faster than a 1.0MB texture page but no idea how I'd measure it accurately. Does file size matter, or does pixel size matter... or do both... when talking about swap time.
I suspect there's probably some optimal size for texture pages based on a given graphics card's bandwidth...but as you might imagine, given that each card is going to have its own bandwidth, it's not a uniform value that you can easily capture and utilize.
 

TsukaYuriko

☄️
Forum Staff
Moderator
> The exception here is Windows, because all texture pages are always loaded into memory.

If you're working with Studio 2 this behaviour can be switched off in the settings. Though generally you're likely to have enough memory to not really need to do so.
Even 1.4 has the option to turn this off... just check Textures on Demand in the global game settings.
Again, the manual (= my source) is out of date... second time this has happened today. :rolleyes:

https://docs.yoyogames.com/source/dadiospice/002_reference/drawing/draw_texture_flush.html

It is worth noting that this function works on all target platforms except for Windows (YYC and standard), since the Directx graphics pipeline handles things differently, meaning that all textures will always be loaded into memory on start-up for these targets. If you are making a cross platform game, then you can leave this function in your code for the Windows target as it will not give any error, but rather silently fail.
Granted, the Studio 2 manual doesn't contain this. It also doesn't contain any hints that it can be turned off, though - which is highly confusing when you've already gotten used to this being the case through years of using GM:S 1.x. :/

Reported... Nocturne will hate me tomorrow. :D
 
Z

zendraw

Guest
you shuld make TP`s for GUI, world enemies player etc. it depends
if your game is level based and that level will consist only of certain enemies then you wuld make the like this
-GUI -all levels
-Player -all levels

-Level1 world -level 1
-Level1 enemies -level 1

-Level2 world -level 2
-Level2 enemies -level 2
etc.

so you wuld have around 7 swaps at all times during gameplay. and if you can truly load only what TP`s you need, then you simply unload the current level TP`s and load for the next level. so it doesnt really matter how meny TP`s you have as long as you load only what you need. you can even go ahead and replace GUI TP for Menu TP and store GUI elements in the Player TP so -1 swap.
 
Z

zmads

Guest
Some general info:

The bigger your texture pages, the lower your game's compatibility with older devices.
The smaller your texture pages, the higher your game's compatibility with older devices.

The more texture swaps you have, the lower your game's performance.
The less texture swaps you have, the higher your game's performance.

The more sprites that will be drawn after another are on the same texture page, the less texture page swaps.
The more sprites that will be drawn after another are on different texture pages, the more texture page swaps.
Essentially, make sure that your draw order consists of, say, first drawing things on texture page A, then B, then C, then D... and avoid drawing from, say, page A, then B, then A again or similar scenarios.

The general consensus that you should keep one stage's (or any other imaginary game chunk's) graphics on one texture page and another stage's graphics on another stems from how texture pages are loaded into video memory on most platforms - they won't be loaded until you draw something that's located on them, then they stay in memory until you flush them out (and they need to be loaded again). As memory usage is often a concern on mobile platforms, this approach will ensure that the amount of concurrently loaded texture pages will be kept to a minimum as long as you flush them after every imaginary game chunk.
The exception to this is the Windows export, as Windows games will keep all texture pages loaded at all times.

Texture page count by itself does not matter. If you're not drawing anything that's located on a texture page, it will not affect your game's performance.
The exception here is Windows, because all texture pages are always loaded into memory. Depending on how much empty space is on your texture pages, this may lead to increased memory load compared to saving that empty space by placing other sprites from other texture pages there and potentially saving space elsewhere.


To answer your question directly:

On Windows, there's not much of a difference.
On other platforms, average memory usage will be higher if you pack multiple stages' resources into one texture page.
Disconsider this post, I have read the rest of the topic and got my answer.
---------------------------------------------------------------------
For curiosity, if I make a game with a lot of graphics for Windows, let's say with 100 pages with a 2k size. This will heavily impact the performance and there's nothing I could do about?
 
Last edited by a moderator:

CMAllen

Member
Disconsider this post, I have read the rest of the topic and got my answer.
---------------------------------------------------------------------
For curiosity, if I make a game with a lot of graphics for Windows, let's say with 100 pages with a 2k size. This will heavily impact the performance and there's nothing I could do about?
If you're refering to the Windows platform page loading design, it could. You might even cause it to crash on startup if the game has to load all those texture pages into VRAM to start. If it only has to load them into RAM, it'll start, but it will take a long time to load and the game will be edging up on the maximum allowable memory footprint (approximately 1.6gb of the ~2gb max allowed). I think. I'm pretty sure that GMS only supports 32bit memory address space.
 

obscene

Member
All you gotta do is enable textures on demand. Then you can have a zillion (literally) texture pages and it won't be an issue. What will happen is that when you go to draw something from them, they will load causing 1 - 5ms lag time. You avoid this by preloading what you are going to need before entering a room / level / etc by drawing one image from each group. What I do is I have an object that is created between levels. First it flushes memory, then I give it a list of the textures I need, it draws a sprite from each all behind the scenes while the player is just seeing a black screen and loading bar. Only what I need for a level is in memory at any given time.
 

kupo15

Member
Seeing these posts makes me even more certain yoyo should do a tech blog on the subject :)

For curiosity, if I make a game with a lot of graphics for Windows, let's say with 100 pages with a 2k size. This will heavily impact the performance and there's nothing I could do about?
It all depends. If you need to swap between all 100 during your game, yes. If you only need like up to 20 then no it won't.
Whether or not your game will run out of memory with that many pages depends on how much of those 2k pages are filled up. You don't need to be using all 100 pages at one time to run out of memory either since all those pages are compressed in the wad file. Even then I'm not sure how much memory 100 2k full pages takes up, someone with knowledge can chime in

If you're refering to the Windows platform page loading design, it could. You might even cause it to crash on startup if the game has to load all those texture pages into VRAM to start. If it only has to load them into RAM, it'll start, but it will take a long time to load and the game will be edging up on the maximum allowable memory footprint (approximately 1.6gb of the ~2gb max allowed). I think. I'm pretty sure that GMS only supports 32bit memory address space.
I think that is for gms1.x but I believe gms2 is a 64bit app so it can handle much more...essentially at that point it would depend on how much ram your user has

All you gotta do is enable textures on demand. Then you can have a zillion (literally) texture pages and it won't be an issue.
Not true unforunately :( Even with this and even if you never use a single texture page you still have a memory limit because all textures are loaded in the wad file thus are taking up memory. Until GM allows us to create multiple wad files to pull from (which they said they are interested in doing) there is still a memory limit of some kind
 

CMAllen

Member
I think that is for gms1.x but I believe gms2 is a 64bit app so it can handle much more...essentially at that point it would depend on how much ram your user has
I don't think I've seen a definitive answer on that aspect, but I'd definitely like to find one.
 

obscene

Member
Not true unforunately :( Even with this and even if you never use a single texture page you still have a memory limit because all textures are loaded in the wad file thus are taking up memory. Until GM allows us to create multiple wad files to pull from (which they said they are interested in doing) there is still a memory limit of some kind
I just did a test on my game's title screen...

RAM usage WITHOUT textures on demand: 350.1MB
RAM usage WITH textures on demand: 308.2MB
Savings: 42MB

Filesize of all texture pages: 47.7 MB
Filesize of texture pages loaded at title screen: 5.6MB
Difference: 42MB

Just sayin!
 
T

Tronco

Guest
I've not measured performance based on texture page file size but it's worth noting that the graphics themselves add to the file size of a texture page, not just the pixel size. I would be curious of a texture swaps of a 0.5 MB texture page is faster than a 1.0MB texture page but no idea how I'd measure it accurately. Does file size matter, or does pixel size matter... or do both... when talking about swap time.
That's EXACTLY what i'm asking :D number of texture swaps is not an issue to me, everything is designed to minimize texture swaps during gameplay. I want to find out if it's better to have for example:

30 texture pages 100kb each
vs
3 texture pages 1mb each

When compiling maybe it's slower to compile 30 texture pages? Is there any strange behaviour under Windows that makes fewer but bigger TP faster than more but smaller TP?
 

kupo15

Member
I just did a test on my game's title screen...

RAM usage WITHOUT textures on demand: 350.1MB
RAM usage WITH textures on demand: 308.2MB
Savings: 42MB

Filesize of all texture pages: 47.7 MB
Filesize of texture pages loaded at title screen: 5.6MB
Difference: 42MB

Just sayin!
Interesting. That confirms that the textures are still in ram even if they aren't being used. Maybe the smaller size of the on demand is from the compression?
 
Top