egg-palettize: multi-group textures

Let’s say I have three eggs that are referencing the same texture. Each of these egg’s is assigned to a different group. Each of these groups has its own subdirectory defined in the txa file. Here is a sample txa file:

# define groups
:group group1 dir textures/group1
:group group2 dir textures/group2
:group group3 dir textures/group3

# assign eggs to groups
egg1.egg : group1
egg2.egg : group2
egg3.egg : group3

# this texture is referenced by all 3 eggs
texture.png : 64 64 omit

If I run egg-palettize on these eggs, 3 copies of texture.png are created, one in each of the output group directories. Is it possible for a texture to belong to several groups but not have a copy made for each group? Is it an implicit assumption of the egg-palettize system that groups don’t share textures? Would some kind of group hierarchy fix this?

Right, a group hierarchy would fix this.

The idea behind a “group” is to collect together all of the textures that you expect to load/download/provide in a certain context. If you have three different groups, and you do not establish a relationship between them, then you have created three unrelated groups, and a texture must be duplicated in each group in order to be available in each group’s context. You are saying that, at any time, the user might have all of the textures of “group1” available, or all of the textures of “group2” available, or “group3”, but they are not necessarily available at the same time.

However, if you establish a relationship between the groups, for instance by saying that whenever the textures of “group2” are available, you can assume that the textures of “group1” will also be available, then egg-palettize will not need to duplicate a texture to put it in both group2 and group1–it will just put it in the group1 directory, since it knows the group1 directory will be available when the group2 context is required.

You can do this with syntax like this:

This whole concept of a group is largely to support phased downloads such as the way Toontown downloads the first part of the game, and then lets you begin to play while it continues to download the rest of the game in the background. It is also sensible to use it to collect together textures that are all in the same scene, and must therefore be loaded into texture memory together; this makes it easier to manage texture memory effectively when your entire game does not fit into texture memory at once.

In either case, it’s usually a good idea to structure your groups hierarchically, so that there is one group at the top that is always available and always loaded into texture memory. All of the textures that are common to multiple scenes will be placed here. The extent to which this can be divided up depends on the extent to which you are willing to structure your texture groups.


Thanks for the quick response, David. Does the ‘with’ syntax replace the ‘on’ and ‘includes’ keywords for defining group interactions. Our last merge with the panda code base was over a month ago. I am curious if the help output from egg-palettize -H has been updated accordingly.

Oops, no, that was my mistake. The (very) old syntax was ‘with’; the correct syntax now is ‘on’, as in:

:group group1 dir textures/group1
:group group2 on group1 dir textures/group2
:group group3 on group2 dir textures/group3

I had written the previous answer without having access to a Panda tree, and I was remembering the original syntax. We replaced ‘with’ with ‘on’ and ‘includes’ more recently. In general, I’d recommend using ‘on’ and avoiding ‘includes’, although I believe the two are intended to be natural converses of each other.