EQInterface Forums - Saving Texture Space - Loading Common Window Elements in A Higher Context?

08-08-2003, 05:51 PM

darkgrue

A Gray Wolf

Join Date: Aug 2003

Posts: 4

Saving Texture Space - Loading Common Window Elements in A Higher Context?

Well, I started playing around with SIDL, and created my own UI mods for the player, target, and group elements, based upon grpwindow-squares(loy fixed).zip by dedara. Basically, I fixed the code to remove errors in it, then extended the style to the player and target windows to make a matched set.

As you can see, I'm also using t.king's spell icons to spice up the rather plain look of the otherwise default UI.

As I was finishing up, I considered that I am essentially loading three 256x256 32bpp TGA files to construct the gauge elements and backgrounds. In fact, the gauges are identical across all three windows, only the background frames are unique - and there's still a lot of real estate left in those TGA files. Being able to load them in a parent context and have the children windows load the common elements and their own background image from a single TGA file should reduce overhead, I'm just not sure that the schema allows inheritance like that. There doesn't seem to be a good discussion of declarations and what contexts they operate in that I understand yet... The documentation that Sony provided for the SIDL syntax seems... incomplete... at best.

Do I want to declare TextureInfo, StaticAnimation, and Ui2DAnimation in a higher context, say in a EQUI.xml file inside my custom UI directory, then include the default EQUI? Something like:

Quote:

<?xml version = "1.0"?>
<XML ID = "EQInterfaceDefinitionLanguage">
<Composite>
<Include>../default/EQUI.xml</Include>
<Include>EQUI_MyUIMod.xml</Include>
</Composite>
<Schema xmlns = "EverQuestData" xmlns:dt = "EverQuestDataTypes" />

<TextureInfo item="MyUIMod_textures.tga">
<Size>
<CX>256</CX>
<CY>256</CY>
</Size>
</TextureInfo>
<Ui2DAnimation item="TargetBackground">
<Frames>

...

</XML>

Will this work? If it would, is it worth the effort? I'm guessing that I'd probably be reducing the (already pretty modest) texture overhead of the mod by about 66% by ditching 2 of the 3 files (and not redeclaring the gauge elements for each window as separate entities. Is it worth the effort to restructure it?

On a similar track, what sort of settings should I be using in Photoshop when saving the TGA files out? I have an option of generating 16, 24, or 32 bpp files, and the additional option of using RLE compression. I've been using 32 bpp files, no compression up to this point, which work, but is it more efficient/advisable, or possible, to use other settings?

08-08-2003, 10:47 PM	#2
Kuvasie A Tempest Toad Join Date: Oct 2002 Server: Luclin Posts: 466	Yes, it does work. You only need to define/declare tga files, gauges or any element once in the entire UI. EQ will look through your custom ui folder to find what it needs, then it will look through the default if it has to. I am not sure how much overhead this saves. I have wondered the same thing myself. Kuv __________________ Kuvasie ~ Sherry

08-09-2003, 04:42 PM	#3
darkgrue A Gray Wolf Join Date: Aug 2003 Posts: 4	Thanks Kuvasie, it does indeed work. =) Spent a few hours this afternoon restructuring it. Once I'm happy with it (and I've finished documenting it), I'll upload it. No clue as to how to figure out if there is any objective improvement. I considered looking at the memory usage reported by the Task Manager, but since the zone contents are always changing, chances are that number's not going to be accurate. Oh well, it's cleaner code at any rate. Anyone able to offer any guidance re: what options to save TGA files under in Photoshop?

08-09-2003, 05:14 PM	#4
*Dolby* Lord Dolby of Veeshan Join Date: Jul 2002 Server: Veeshan Posts: 2,397	There is a program called fraps that will display the FPS of any DirectX game. I've used it on Everquest awhile ago.

08-09-2003, 05:45 PM	#5
Kuvasie A Tempest Toad Join Date: Oct 2002 Server: Luclin Posts: 466	You are welcome Darkgrue and thanks Dolby. I have wondered about fraps. I think I will try it when I get home Kuv

08-10-2003, 04:53 PM	#6
darkgrue A Gray Wolf Join Date: Aug 2003 Posts: 4	Fraps is a good way to check the effects of overall video settings. But, it only shows FPS benchmarks (although it also does scrren caps and AVIs, too which is pretty nice). I doubt that it will show the difference in texture memory use (if indeed there is any) here though. Just facing into the middle of the Bazaar will have a significant impact over FPS than the memory savings gained by avoiding loading 2 more 256K-ish TGAs would represent - unless you were already tight on texture memory and the cache started thrashing... I suppose if one made some huge test TGAs and started playing with how they were loaded and animations instatiated you could nail it down, but truth be told I'm not feeling that ambitious. =P

08-24-2003, 08:19 AM	#7
Sylphan A Predatory Creeper Join Date: Aug 2002 Posts: 254	Consider the consequences of combining them though. If the textures are all defined in EQUI_Animations then people can't install your mod along with other mods (especially custom cursors) that must modify EQUI_Animations. Or your mod will need to be updated whenever EQUI_Animations is updated. If you put the textures all in the group window but use them in the player window as well, people won't be able to mix and match. Using your player window without also using your group window won't be possible. There are other ways to save texture memory too. For instance, I figure I saved half a megabyte by editing EQUI_Animations to remove the class animations (which are usually shown in the inventory window). The objective improvement, even on a very old machine that can barely run EQ, was almost nil. And now... I don't like the overlay of numbers onto my hotbuttons. So I won't need to load window_pieces06 or window_pieces07 at all. This is remarkably easy to do... the UI should run fine if I just plain ignore the changes to EQUI_HotButtonWnd and EQUI_Animations in the next patch. Since I already added a shared platinum slot to my bank windows weeks ago, and never modified the journal or options windows, I won't even need to upload a new version of my UI after the patch.

08-27-2003, 11:46 PM

darkgrue

A Gray Wolf

Join Date: Aug 2003

Posts: 4

Quote:

Consider the consequences of combining them though. If the textures are all defined in EQUI_Animations then people can't install your mod along with other mods (especially custom cursors) that must modify EQUI_Animations. Or your mod will need to be updated whenever EQUI_Animations is updated.

What makes you think I'm loading them in EQUI_Animations? There's nothing that requires that all animations be defined there, as far as I can tell. That would be contrary to the entire point of restructuring the mod, as you rightly say. The idea is to modify (actually you replace the Default UI files) as few of the default files as possible, as that's what generates the biggest problems when a patch breaks your UI - rolling the changes from the Default UI into the mod.

Instead, what I am doing is defining a new EQUI.xml file in my mod's directory:

Quote:

<?xml version = "1.0"?>
<XML ID="EQInterfaceDefinitionLanguage">
<Composite>
<Include>../default/EQUI.xml</Include>
<Include>EQUI_tessilUI.xml</Include>
</Composite>
<Schema xmlns="EverQuestData" xmlns:dt="EverQuestDataTypes"/>
</XML>

The EQUI_tessilUI.xml file contains the new animation definitions which are global to the mod (i.e. those that are common to the player, target, and group windows).

Quote:

If you put the textures all in the group window but use them in the player window as well, people won't be able to mix and match. Using your player window without also using your group window won't be possible.

That's true. But that's not what I'm doing. And if the SIDL interface actually honored inheritance properly, you wouldn't really be able to do that anyway, since in your example the player window shouldn't be a child of the group window, and wouldn't have access to local definitions in the group window. But, from what I can understand, a lot of stuff ends up global, so so much for scope. =P

You can see what I did in the snippet below:

Quote:

<?xml version = "1.0"?>
<XML ID="EQInterfaceDefinitionLanguage">
<Schema xmlns="EverQuestData" xmlns:dt="EverQuestDataTypes"/>

<TextureInfo item="custom_window_pieces01.tga">
<Size>
<CX>256</CX>
<CY>256</CY>
</Size>
</TextureInfo>

...remainder snipped

I placed all the common interface elements that I added or changed into a file called custom_window_pieces01.tga, which should be a "unique" name. It's doubtful that any future UI patch by Sony will collide with it (although an enterprising UI modder may have chosen the same name for a component of their own mod). However, even that being the case, changing the name of the file, and the references within the XML files is a moment's work with a good programmer's editor able to search and replace across multiple files (I like jEdit - it's able to do exactly that, and with the appropriate plugins, it understands XML syntax just fine).

Below the portion I snipped are the Ui2DAnimation elements that are common to the three windows. Elements that are unique to each window are defined in the window's respective XML file, but they still reference the same custom_window_pieces01.tga. It's a 256x256 TGA, and there was plenty of room. Even if someone wanted only one or two of the windows I modded (all you'd have to do to "un-mod" a window would be to delete that window's XML file from the mod's directory). Removing a window from the mod won't damage the functionality of the other windows.

Quote:

There are other ways to save texture memory too. For instance, I figure I saved half a megabyte by editing EQUI_Animations to remove the class animations (which are usually shown in the inventory window). The objective improvement, even on a very old machine that can barely run EQ, was almost nil.

Yeah, that's what it comes down to. As elegant as the path I took was (at least, I think it's elegant), it seems that the net impact to the game's performance is swamped by other considerations over which we, as UI tweaker/designers, don't have control over (such as a pathetic rendering engine).

At any rate, source code is worth 1,000 words. Or at least 29K Bytes... ;=)

I've submitted this mod to EQ Interface: tessilUI; anyone who's interested in the details only needs to refer to the XML files. I can't claim what I've done is innovative, I just really pieced together other people's work and ideas into something that suits what I was looking for.