12-31-2002, 08:48 PM
|
#1
|
|
Silly Necro
Join Date: Dec 2002
Server: Tribunal
Posts: 233
|
Memory saving idea
I don't know if anyone has come up with this idea yet, but I have not seen it, so I am just gona through it out for someone with real XML skills. Since you can not manipulate various slots without the parent window being open, what would keep you from having a 1x1 parent window? That way you could have one window do everything and save a bit of memory in the process. That would let you have inventory, hotbutton and equipment slots open..but I have no idea about the spell bar. This a good idea, or am I just spinning my wheels?
__________________
Boonzy 57 Necromancer <Nobility of Norrath>
Goil Ngears 31 Gnome Mage
Jobana 47 Warrior
Threefour 24 Monk
|
|
|
|
12-31-2002, 09:50 PM
|
#2
|
|
A Shissar Disciple
Join Date: Jul 2002
Server: Tholuxe Paells
Posts: 135
|
Not quite sure what your talking about. If you were to make the spell window un see able you wouldn't be able to switch spells and if done to hotkey window you couldn't switch anything.
__________________
Hunter Neiloch Forever
65 Epic Ranger
"Dont screw with someone with a lot of free time"
|
|
|
|
|
01-02-2003, 01:17 PM
|
#3
|
|
Grimling Code Editor
Join Date: Sep 2002
Server: Xev
Posts: 507
|
When we speak of "parent windows" there are 2 issues.
First is that the control / element can only function within its originat window. This applies to things like the auto-equip area in Inventory. You can move it elsewhere and SEE it, but it wont work because EQ just dont know how to handle it. The code for handling it is "hard-coded" to the parent window.
Second is that there are some controls / elements that you can be moved to a different window, but will not be active unless that parent window is open. An example of this is Bank Inventory Slots - these 8 slots have EQTypes. And so you can see them at any time, however, they are ONLY enabled when the Bank Window is open. Here's the big restriction - most special function windows limit you to only have one open a time and tied to some object/NPC in the playing world. For instance, I cannot be banking and try to trade. I have to first close the bank window and then start the trade, at which point I can't open the bank window while trading. The ability to open these windows is based not on player commands but on events in the world. (i.e. Pressing "I" opens inventory - to open bank window you must click on a banker). So this is what limits having certain windows open.
Now, as far as having some stuff down to 1x1 pixel - it depends on how you code the window. Unfortunatly, the validation process includes checking to see that all the "default" elements of an XML file are included. So you can't just eliminate a button from the XML code because you dont' want to use or show it. You have to be tricky and position it so that it is displayed outside the window area or sized to a 0x0 button. Therefore, custom UI's will always take more "overhead" memory space. However, the custom UI's can improve performance better then the DEFAULT UI by making better usage or eliminating cycling amimations that would otherwise be processor intensive, such as the Class animation being replaced with a single frame image.
|
|
|
|
|
01-02-2003, 03:35 PM
|
#4
|
|
Silly Necro
Join Date: Dec 2002
Server: Tribunal
Posts: 233
|
Good explanation. I guess my idea is like my colin, stinky and full of holes =P Oh well, back to the drawing board.
|
|
|
|
|
08-25-2004, 02:18 PM
|
#5
|
|
A Snow Griffin
Join Date: Dec 2002
Posts: 54
|
not to bad of an idea in one way
The container slots can be put into another window to have them all (bag 1 -10) show at one time but you have to make sure the slot actually exist or when it was closed or you zone all that are in unreal slots will disappear.To me it sounds like a glitch problem rather than an idea they wanted to have.
But if your really careful and was doing trade skills with a inventory container (sowing jewelry cooking) then you could build a trade window (not tradeskill window) that made it easier to move items between containers (for new items). Or if you use the tradeskill window then you can still use it to keep up with where the items were going *shrug*.
|
|
|
|
|
04-03-2007, 05:43 AM
|
#6
|
|
A Predatory Creeper
Join Date: Dec 2002
Server: Bertoxxulous
Posts: 251
|
Moving everything to one window wouldn't save memory at all. Your still handling the same features, just in a different spot. Consider this for memory usage:
Each texture used is loaded into memory Once. If it's use multiple times that's the CPU/GPU job to replicate it on the screen. Memory copy of the image is basically just a stencil, it don't even store a color image, it's stores an image with the color pallete stored separately (this is to save memory when you have multiple things using the same color pallete).
To further bog your memory down, EQ loads every image (TextureInfo) into memory unless there is a duplicate somewhere. Even if they are not shown, it's in memory just waiting to be used even if it's never used.
If you want to cut down on memory usage, cut down on the number of images used in the UI, can cut them completely out of the UI. Which would probably cause a UI to break every patch seeing as how much you'd have to change in the XMLs.
Only UI part I know that can cause serious memory issues is Target Rings, I'll explain how below:
Say you had Animated target rings which used 24 frames of animation and were full detail 2048x512 textures. Obviously at such suicidal amounts this would be someone who care not about performance but only about maximum prettiness.
That's 2048 * 512 = 1,048,576 pixels per image.
1,048,576 * 24 = 25,165,824 pixels total for just 1 con color.
25, 165, 824 / 1024 / 1024 = 24MB. (This is without compression at full detail).
Now there are 7 con colors.
24MB * 7 = 168MB without any compression or detail loss. This would crash a low end computer for even thinking about loading it.
This is being generous too, I only allowed in my calculations for a 2bit(white or black, 0 or 1) color, EQ uses 32bit ARGB (0 to 255, 0 to 255, 0 to 255, 0 to 255). At 32bit ARGB that same 1 image would easily be 7 to 14mb instead of 1mb.
Now a more realistic example using again 24 frames per con color.
192kb or 196,608 bytes being 1 compressed 512x512 images with plenty of colors and optimized color tables to reduce file sizes, other worlds, your average 512x512 RLE Compressed TGA out of Photoshop.
196,608 * 24 = 4,718,592 - One con color
4,718,592 * 7 = 33,030,144 - All 7 con colors
31.5MB Total
You can see from that example it's the images loaded into memory and not the amount shown on the screen that affect memory. Memory isn't what causes EQ lag if you were thinking that, it is only a small factor of many. The greatest factors being CPU usage and Render calls to the GPU.
__________________
 
"Computers are like Air Conditioners, they stop working properly when you open Windows." |
|
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
Linear Mode
