Darkmourn

I am redoing the graphics on the UI I started maintaining, because after probably countless updates by unknown people before me it has grown pixelated and just plain ugly in my eyes. Gradients don't match up from one piece placed right next to another, greyscale has been infested with random greens and pinks, etc.

So to make it easier I have opened all the relevant graphic files and pasted them into one Photoshop drawing. Since I am making it span a 1680 x 1050 resolution screen, my canvas size is 2048 x 512. My original intention was to paste the pieces back into their original files, but since I have moved a few things and would basically have to recheck every location anyway, it occurred to me that maybe I could just leave the main parts all in one file. I realize this might make it more difficult for someone else to mod my UI, and if someone changes a lot of the images it would probably create a lot of extraneous loading with that large image file, but it will greatly increase the speed at which I can modify/update.

So my question is, does anyone know if it will affect system performance and/or UI load times by having one 2048 x 512 image referenced many times by multiple .xml files, as opposed to a bunch of smaller ones referenced fewer times each?

My thought is that it probably won't matter much since the image file will most likely get cached anyway, but I figured I would ask before I went through the painstaking process of adjusting each reference in the .xml files.

Thanks in advance for you assistance.

Inokis

If you want to do it this way, you'll have to make some choices.

Buttons typically cannot be moved to different windows. You'll be forced to either hide the leftover button elements or make cutouts in your graphics for where you can lock the downsized buttons to emulate a complete UI.

Theres also the matter of the Target Indicator. This cannot be moved to different windows and retain its function. Again, you can try nesting the target window with a graphic that emulates part of the UI and appears seamless.

Its up to you how you do it. IMO its just as easy to make seameless sep windows as it is to make one giant graphic. Either way you do it you're going to have to customize items to fit together.

__________________

Darkmourn

Sorry if I wasn't clear. I still intend to have multiple different .xml files, same as before. Each one will reference a part of the single image file is all, instead of a different image all together. If that still isn't clear, let's say that my hotbutton file references from 0,0 to 400,400. My player window then might reference 401,0 to 600, 400. Next piece 601, 0 to 1000, 400, etc. Does that make it more clear? I'll still have an individual target window, player window, group window, etc. so all the buttons that have to be in each one to work will still work. I just won't be sending it to look in player.tga, target.tga, they will all reference bigpic.tga.

myxiplx

I thought EQ had a 256x256 limit? It certainly used to for graphics, even SoE's loading screens are actually made up of several pieces stiched together.

In terms of performance, I don't know, but if you want to make your UI easy to maintain, and easy for people to add to or borrow pieces from it's probably better to ship with many separate files.

I try to keep each .xml file relatively self contained, and code to avoid clashes with anyone else's mods. That means I can't rely on any other piece being there, which is what you'll be relying on if your pieces share graphics like this.

What I'm doing now is using this naming convention:

XML file: EQUI_PlayerWindow.xml
Graphics: EQUI_PlayerWindow_Myxiplx_Gauges.tga
Variables & Pieces: myx_player_current_mana

That guarantees the item names won't clash with any other XML. It makes the graphics for each piece easy to identify, and makes it possible to chop and change pieces at will.

It also means that when soe patch something you're not worried about possible repercussions of that. Changes are pretty isolated and it's possible for people to revert to default items if they need to.

Darkmourn

There definitely is no 256 x 256 limit, as my UI currently uses .dds files of 512 x 256 (created well before I took over maintaining it). It appears that Sony themselves only use 256 x 256 though, for whatever that is worth.

I get what you are saying, and I see both sides of the issue, but I almost want to try it now to see what happens. As I mentioned, this UI was created well before I ever thought about touching it, so the naming conventions and such aren't as neat and clean as what you suggested, and I honestly don't want to go back and change every one of them. To me, it almost seems easier for me to put everything into one image, instead of, for example, my buffslot images being in with the pet window graphic just because there was extra room. I didn't create it that way, that's just how it got to me. And as you more or less pointed out, it is counterintuitive to think to look in the pet window image for buffslot graphics. But again, that's how it already is.

So my thought was, I make one large image, paste everything custom into it (minus stuff that I'm never going to touch and already have their own locations like the window_piecesXX files), and just reference that. That way, if someone really wants to make a new pet window for example, they just create their own image and reference it in the .xml, not even caring where mine was. But it won't stop them from doing whatever they want whether it is part of a larger image, or a single small image unto itself.

The only real disadvantage I can see to having one large image is performance, and since Sony has everything in 256 x 256 chunks, that would seem to indicate it is the case. However, we all know that Sony sometimes does things for entirely different reasons than what we think, so unless someone has already tried it and can tell me, I'll probably give it a shot and see how it goes.

Thank you for your input however, it is greatly appreciated, trust me.

myxiplx

In that case I think it should work fine. Reading your post again I can see why you're doing it - it'll be much easier to get everything consistent working in one file.

A couple of suggestions if you're interested:

Document the graphics file - group controls together and put borders around the group so it's obvious which pieces go together. Add text labels to make it even clearer - doesn't have to be anything huge, just 'gauges', 'inventory', 'spells', etc will make maintaining it a lot easier. Loading a file that big and not having a clue what pieces do what would be a nightmare.

You'll only be opening the image once to save memory, so you want to have your <TextureInfo> item in one of the first XML files that loads. The first four are animations, templates, character create and buffwindow. I try to avoid editing the animations or templates files, character create is probably easier to leave alone too, so I'd stick the <TextureInfo> line loading the graphic in the buffwindow file.

Then, because that's not loading from any standard place, in any XML file that makes use of it I'd be tempted to add a comment to the top, to remind you and anyone else updating the UI where the graphic is actually loaded.

Other than that, good luck with it, and let me know how it works. If I'd known last week that graphics that size work it would have saved me a ton of hassle creating a larger gauge lol.

shillingworth

I would highly suggest you restrict yourself to 512x512 files at the maximum. The reason behind this is that the graphics card is what determines your maximum texture size on any given PC. Any graphics card capable of running EQ can support a 512x512 texture, for some of the lower end cards, that's their highest. What happens when a texture is to large to fit in video ram, it simply is replaced by black.

The only part of the entire usage of that texture that matters as far as performance is concerned is the TextureInfo. The Ui2DAnimation elements are drawn by order of texture, if texture5 is loaded and there are 200 animations that reference it, those 200 will be drawn before that texture is unloaded. The drawing calls in DirectX take a source rectangle, and destination rectangle to draw from an image, so all your X, Y, CX, CY in animations are just telling DirectX where that boxes Upper Left corner is, and how big it is.

Of course you can't see this with your eyes looking at the screen, it happens really freaking fast because of that behavior.

__________________

Darkmourn

Ah ok, that's the sort of info I was looking for, and was obviously unaware of. And I'm sure it would have worked just fine on my card, but others would have been complaining of black and I'd have no idea why. Thank you for the information, that's exactly what I needed to know.

Of course, it figures that I had already begun work on placing all of the correct locations based on the large one I did

shillingworth

Heh, it's always on the box, in very small fine print.

Desideratus

If you want to be able to service 8 year old video cards (say 16MB Voodoos, that kind of thing) then you have to stick with 256*256 maximum (of course for long thin bits you could use 64*1024 to keep the number of elements down ...)

Which is exactly why Sony restrict themselves that way, of course. Otherwise they wouldn't stitch together the splash screens, the maps and book backgrounds the way they do ... who wants the hassle?