Jump to content
Skye

Multiple BAMs in a single PVRZ

Recommended Posts

Is it possible to have multiple BAM files reuse the same PVRZ file? Looking at existing MOS####.PVRZ files, they all seem to function as texture atlases (sort of), cramming a bunch of different images inside them. I've started using PVRZ-based BAMs in certain cases to make my life easier and to increase image quality, but NearInfinity only allows you to select the index for the MOS file, at least as far as I can tell. Although there a great many indices to choose from, so clashes with other mods are unlikely, I would still prefer it if I could put all my spell icons into one PVRZ for instance.

Share this post


Link to post

By the file format specs this is certainly possible, and as you point out Beamdog did this with vanilla EE resources.  However, AFAIK there is no automated way for modders to achieve the same result.  I can think of a couple hack style workarounds to do it, but they wouldn't be elegant or efficient...

Share this post


Link to post

I've taken the time to look at the specification of BAM v2 files and it seems like a rather simple matter to change the coordinates and size of the data blocks. I'll ask Ken to write us a patch function to automate this process. We've also noticed that there are now TP2 actions that allow you to find an appropriate PVRZ index and update your BAM resources, which will prevent any potential clashes.

Share this post


Link to post

You definitely can have multiple BAMs referencing the same MOSXXX.pvrz file. I did it with NearInfinity.

In the Bam Converter, all frames you add will end up in the pvrz files (even the ones that are not used in this particular BAM). If you put the resources in the frames tab in the exact same order, it will always produce the same pvrz file.

So if for example you have file1.png and file2.png and want to create two BAMs that will use only one pvrz file, you add both png in the converter, select only the first frame in the cycles tab, choose an index and create file1.BAM. You then do the same (same pngs, same index) but this time select the second frame in the cycles tab and create file2.BAM. It will overwrite the MOSXXX.pvrz file but with the same content. Now both your files should reference the same pvrz file but with different coordinates and size.

Edited by lefreut

Share this post


Link to post

Sounds like a roundabout way of going about it, but it might be easier than doing it by script. I'll give it a shot, thanks.

Share this post


Link to post

Can anyone tell me what the point of the INSTALL_PVRZ action is? Is there relevant metadata written within the zipped PVR files? And why do you need to tell it what the original index was? I thought the page was defined by the filename.

I'm just curious as to how this differs from simply copying the file to override with the correct page number in the filename.

Share this post


Link to post
4 hours ago, Skye said:

Can anyone tell me what the point of the INSTALL_PVRZ action is? Is there relevant metadata written within the zipped PVR files? And why do you need to tell it what the original index was? I thought the page was defined by the filename.

I'm just curious as to how this differs from simply copying the file to override with the correct page number in the filename.

PVRZ files are compressed graphics textures.  For BAM V2 files, the BAM frames are subtextures that have been bin-packed into a single large texture that is a PVRZ file.  The PVRZ files are accompanied by the actual BAM/TIS/MOS files that contain pointers into the PVRZ files of where to load the subtextures from the larger graphic.  If you rename a PVRZ file to use an unused name, the pointers within the corresponding BAM (etc.) files also need to be updated.

Share this post


Link to post

Yes, I understand that, but INSTALL_PVRZ only modifies MOS####.PVRZ files as far as I can tell. You have to update the BAMs with UPDATE_PVRZ_INDICES, which makes sense, but then it should only be a matter of copying the PVRZ file to override with the correct name, so I don't see what the point of that action is.

The documentation states: "This function copies the specified PVRZ file into the target folder and updates the PVRZ index."

So how is that different from just doing COPY ~MOS1234.PVRZ~ ~override/MOS%new_index%.PVRZ~?

Share this post


Link to post

Looking at the source code, from what I can tell, it only makes a difference if your BAMs use multiple PVRZ pages. You can then foreach through all of your PVRZs and update their indices to the new block indices that you got from UPDATE_PVRZ_INDICES. So for small images, like spell icon BAMs, you're probably better off copying them by hand to reduce the amount of unnecessary code.

Share this post


Link to post

So, I did test my theory and it turned out to be true. I also needed to update the BAM indices manually since argent's functions don't really support image resources that use the same PVRZ page. Doing so does have the added perk of being able to name your PVRZ files whatever you want though, which makes things a bit easier to work with.

LAF FIND_FREE_PVRZ_INDEX RET large_pvrz_index = free_index END
COPY ~project/pvrz/icons_large.pvrz~ ~override/MOS%large_pvrz_index%.pvrz~

COPY ~project/bam/mybam01.bam~ ~override~
  READ_LONG 0x001c data_offset
  WRITE_LONG data_offset large_pvrz_index

Something like that works just fine. Of course, if the BAM file were to have multiple data blocks or PVRZ pages, one would need to do a bit more work.

Share this post


Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...