Option to Remove the Circle Image on Skill CD

[S-r-ex]

Now, if you meant "storage" then tell the PS3 kids to get bigger hard drives.

By 3.2 the low capacity release PS3's are already screwed unless updated. Mind that the PS3 has a meager 256MB of both system and graphics memory. That wasn't much a decade ago, and still isn't much. This option might just be the drop that spills over.

[Niwashi]

Now, if you meant "storage" then tell the PS3 kids to get bigger hard drives.

By 3.2 the low capacity release PS3's are already screwed unless updated. Mind that the PS3 has a meager 256MB of both system and graphics memory. That wasn't much a decade ago, and still isn't much. This option might just be the drop that spills over.

Sanosuke's point was that this option can't be the drop that spills over because it doesn't add even a drop. There is no extra memory requirement by offering multiple options of how to display something, because regardless of how many other options a player could have chosen from, only the one they actually do choose will get loaded into memory. Hiroshi Minagawa's claim that "due to memory restrictions, we cannot hold data for two types of animation" is total baloney because the machine's memory wouldn't be holding data on both types of animation, it would only hold one or the other.

Both types would be held within the application's data files, of course, so there could be a slight increase in hard drive storage space, but the storage of an extra cooldown animation would be pretty trivial compared to the amount of other new stuff that's continually added and loaded into everyone's system regardless of which pieces of it they're actively using. And in any case, hard drive space isn't a major limiting factor on any of the platforms the game runs on since they all allow for hard drive upgrades. (PS3, for instance, which is where the memory limitations are so stringent, can use a hard drive of over two terabytes, roughly a hundred times the size of FFXIV.)

[Nutz]

Sanosuke's point was that this option can't be the drop that spills over because it doesn't add even a drop. There is no extra memory requirement by offering multiple options of how to display something, because regardless of how many other options a player could have chosen from, only the one they actually do choose will get loaded into memory. Hiroshi Minagawa's claim that "due to memory restrictions, we cannot hold data for two types of animation" is total baloney because the machine's memory wouldn't be holding data on both types of animation, it would only hold one or the other.

I'd love to tell you that you're right about that because it seems so sensible, however, he explained exactly why that is not the case. It may seem to be poor implementation, and perhaps it is, but the implementation that they are using according to the dev post is an entire packet of hotbar images all loaded at once such that every conceivable icon that could be on a hotbar (and as such any recast animations) are all held in memory at once. He mentioned that there are some exceptions, presumably for icons that change (MNK's chakra perhaps) or for whatever reason don't need to be in memory and for which some display lag would be acceptable. Something that would be called every couple of seconds at least in battle doesn't qualify.

I can't tell you why the recast animation can't stand alone outside of the packet of other hotbar icons or anything, just that the dev post specifically said that it can't and I have to believe he knows something that I don't.

On another note, I do wish they had just put a 0% saturation filter over the icon while it was on cooldown. The circles do obscure the image enough that if you're at all confused about the icon or placement on your hotbar you'll have (more) problems. I experienced this yesterday coming back from a fairly long break from the game. I was wrestling with muscle memory telling me one thing but visually being unable to confirm what certain icons were (without hovering over them to read). A minor annoyance that will probably pass, but I think there would be better ways of indicating something is on cooldown (even to the last millisecond) than obscuring the image this much.

I sympathize though. I'd like grayscale images for abilities that are on cooldown and other people may think that's a terrible idea.

[Sicno]

I'd love to tell you that you're right about that because it seems so sensible, however, he explained exactly why that is not the case. It may seem to be poor implementation, and perhaps it is, but the implementation that they are using according to the dev post is an entire packet of hotbar images all loaded at once such that every conceivable icon that could be on a hotbar (and as such any recast animations) are all held in memory at once. He mentioned that there are some exceptions, presumably for icons that change (MNK's chakra perhaps) or for whatever reason don't need to be in memory and for which some display lag would be acceptable. Something that would be called every couple of seconds at least in battle doesn't qualify.

But that's the thing, you don't have to do the replacement every time something is cast. You do the replacement in memory JUST the moment the setting is changed and then keep THAT in memory.

Edit: Or worst case scenario, have it be one of those changes that applies on next restart. At least it would give us a usable alternative.

[Niwashi]

he explained exactly why that is not the case. It may seem to be poor implementation, and perhaps it is, but the implementation that they are using according to the dev post is an entire packet of hotbar images all loaded at once such that every conceivable icon that could be on a hotbar (and as such any recast animations) are all held in memory at once.

He did explain how it's all animated together and not as an icon in the background with an overlay recast timer on top of it. So, for instance, if they have a 1% increment in their recast animation, it would mean they actually load 100 different images of each skill icon and keep all 100 in memory, switching between them according to the current cooldown state. But that still doesn't account for why they couldn't have a packet of 100 images for animation type A and another packet of a different 100 images for animation type B, and then use whichever fits the user's settings. The system would still only be alternating between images in one set or the other, not both, so would only need to load one of the possible sets. (If anything, that should make offering multiple options even easier, since they're each just a set of animation images, processed the same way regardless of which set is displayed.)

A more valid point of his post was the part that it would take programming, QA, etc resources, but he tried to inflate that into sounding as though it were something excessive when he was simply describing what every change in the game takes, including this change they did just make. Once you exclude the spin factor, his post came out to saying it doesn't give us options because for that they'd have to put the option in. Basically, they just didn't bother.