HoloCure Wiki talk:Style guide

Proposal: Change sprite size to 200%

Many other wikis for sprite-based games use 2x resolution, and I personally believe it's the sweetspot for size and readability. The current size of 600% is unwieldy and needs to be sized down for use in pretty much any context, which results in ugly blurred images if you don't know the exact size every single sprite needs to be scaled to for pixel-perfect resolutions. In cases where one might want to sprites to be bigger, such as the infoboxes for skills and items, the only real side effect of scaling down would be a little extra empty space in those boxes, which I think is a good trade-off for the convenience. Please let me know what you think; I've already uploaded all the character and outfit sprites at 200% for Outfits sections on their pages, and I think it looks very nice.

Bubbyboytoo81018 (talk) 12:33, 10 August 2023 (UTC)

Feel free to discuss the suggestion below. Once you have formed your opinion, please clearly state whether you are FOR or AGAINST the suggestion. Votes will be tallied on August 16th 12:00 (UTC), so we can make the decision before the new patch is released. Please sign your comments (using ~~~~). taQtaQ (talk) 13:58, 10 August 2023 (UTC)

I'll reiterate here what I mentioned to Bubbyboytoo on their message wall, and hope we'd get a couple more opinions on the matter. Foremost, the reason we upload the sprites larger than the original, is that the fandom/mediawiki software does that very poorly. The current 600% resizing, was not chosen for any particular reason other than that it happened to be the most commonly used.

As such, I do not think we need to be using 600% specifically, however, I do feel that 200%, putting most sprites in 50-70px height range, is a bit too small. And while downscaling an image through wiki also reduces the quality, it is much less noticeable compared to doing the opposite, which is why I would prefer to stick with the current policy, rather than going down to 200%, as it restricts us from displaying images larger. taQtaQ (talk) 18:04, 13 August 2023 (UTC)

Time to close the discussion. Tied with 1 for and 1 against, we will not be changing the current policy. Given that there was so little participation, we can reopen the discussion in the future if there is more interest, but for now we shall continue using 600% upscaling.

Revisiting the discussion on sprite sizes

The previous discussion was rather rushed in attempt to reach a conclusion before the new patch, so now that the matters have calmed down a bit and I've received similar feedback from more users, I think we could now discuss the matter a bit more throughly. Additionally, I'm looking to make a few clarifications regarding the image type suffixes. Overall, the following points are on the table:

1. Changing sprite size to 200%.
2. Should the same scale be used for all in-game images or only for animated sprites? If not, should we stick with current 600% standard?
3. Add the alternate outfits naming to style guide and the suffixes for enemy sprites and full-body portraits to the image type list.

Regarding on reaching the conclusion, I think voting is a fair way to resolve the discussion, but I'm looking for feedback on how we should do this in the future. So, I'm looking to leave the discussion open without putting a time limit on it for the time being. — taQtaQ (talk) 14:29, 19 September 2023 (UTC)

Padding or no padding for icons?

As someone who would like to, over time, rid this wiki from the previous one's growing pains, I've been eyeing earlier submissions of icons (items, weapons, etc.) that do not meet the current standard. However I couldn't help but notice that even among the ones that do, there are those that use padding and those that do not. This may feel extremely nitpicky but I feel it is important for the icons of normal & super versions of items and normal & awakened versions of weapons to align appropriately, both in their respective infoboxes and outside of them. I have the following observations/questions to make:

• Without padding, super versions of items are almost always larger due to the golden aura and sparkling effects around them, while that is not the case with padding, most of the time. Depending on alignment/scaling rules for images this can cause different versions to be offset up/down/left/right or appear zoomed in/out. An obvious example is this page where the icon for the regular version appears zoomed in, as it attempts to fill the icon container, in the Upgrades section. I do not know to what extent the submission for the super version being 800% instead of 600% influences this, if at all, unlike in the Infobox, where the issue is different. A significantly more subtle/nitpicky example can be found here, where while both images seem cropped, the super version occupies a full 150x132 (600% of 25x22) anyway.
• The standard size for icons seems to be either 25x22 or 25x20, which can become a problem when two versions of the same item come at different sizes. Idol Costume is one of them, where the regular version will result in a 150x120 image, while the super version in a 150x132 one. What happens under those situations, should one manually add to the canvas size so that both icons have the same dimensions? That's a potential can of worms there.
• Some icons seem to, for reasons arcane to me, refuse to scale or play along with certain browsers or screen/window sizes. The regular icon for Breastplate in the infobox behaves like that for me. While both the regular and super version of that icon are with padding intact and the same dimensions, the regular icon refuses to scale well in some browsers, often turning smaller instead of larger when I magnify the page or use responsive mode. Does it respond to scaling by displaying some sort of thumbnail stored therein? If someone knows what's up with that, it'd be nice to know, in order to be able to avoid whatever it is that's causing it.

Anyway, I know I'm delving into royally nitpicky territory here, and don't expect some sort of radical change to come from this, but I feel leaving this here may amount to something at some point.--Tziouv (talk) 11:17, 4 October 2024 (UTC)

EDIT: Third point turned out to be a css issue. Second point seems mostly moot after testing, as along as the icons share the same center, any differences should be too marginal to warrant canvas resizing, but you never know. --Tziouv (talk) 19:02, 4 October 2024 (UTC)

I have removed the CSS rule that restricted the icon size in the infobox, so that shouldn't be an issue anymore. Then, to briefly reiterate on the background, our policy has been to use cropped images because that works better with sprites, which can come in largely varying sizes. However, this is not really an issue with icons that are designed to fit in a same sized space, so I would be in favor of uploading them with the original padding.

As for the small discrepancy in sizes with normal and super icons, I don't think it matters. The width, which is the same for both, is the larger value and determines how the image fits to the containers and all containers that display an icon center the image in the container. I tried uploading a new version of normal Nurse's Horn with only the padding from exporting the file to demonstrate this. This is of course assuming that all super icons' sizes increase symmetrically (1px both up and down), so unless there are icons which size increases only in one direction, there shouldn't be a need to add extra padding to make the images the same size vertically.

Also, given that we need to do a consistency pass to the icons, I'd also like to briefly discuss the upload size. Should we continue with 6x or is maybe some other multiple like 4x or 8x better? Currently, only infoboxes display them in the uploaded size (600%, 800% or 256x256px, whichever the uploader used), but otherwise it is not necessary for them to be larger than 3x which is what skillboxes use (although that isn't completely set in stone either, but I think it is fine atm). So, I'd like to hear thoughts on that as well. –Taqx2 (talk) 19:13, 4 October 2024 (UTC)

I uploaded a couple for testing and it seems alright. From what I can tell, the 600% size seems to be of relevance only to the infoboxes and we could get away with smaller for everything else. If file size is an issue, the removal of image metadata is easy to do through sites like Jimpl. A bit extreme but hey. --Tziouv (talk) 19:31, 4 October 2024 (UTC)

Calendar Date format

I noticed that there does not seem to be a particular directive regarding how calendar dates should be written. Under ISO_8601#Calendar_dates, ideally we'd write all date references in the format YYYY-MM-DD (year-month-day), but I've seen YYYY-MM-DD, YYYY/MM/DD, and even the American format of Month-Day-Year (which is just incomprehensible to most non-Americans). As such I suggest officially setting YYYY-MM-DD as the style standard and unifying all instances (outside of talk pages, to be clear). - JackyHF (talk) 04:10, 3 December 2024 (UTC)

I think ISO 8601 should be the standard for infoboxes and other templates. But outside templates, I feel it's a bit janky and would prefer that we use either "DD Month YYYY" or "Month DD, YYYY" in article text. Also, there is an option to use #formatdate parser function for templates, which adapts the display format based on user preferences.–Taqx2 (talk) 12:25, 3 December 2024 (UTC)

So "technical data -> YYYY-MM-DD" (info boxes, reference citations) and "informal text -> DD Month YYYY" (or data format function). Yeah, I guess that could work. How would the parser function have to be implemented, exactly? - JackyHF (talk) 15:44, 3 December 2024 (UTC)

Yes. You can read about formatdate (or dateformat, they are the same) from here. But in short, if the user has defined a date format in their Preferences it will be displayed as that, otherwise it can be set to convert the given date to some default format, like ISO 8601. {{PatchInfo}} template on changelog pages, already uses it, so you can check that for an example on how it would be used. (It has the default set to DMY, though.) –Taqx2 (talk) 14:37, 4 December 2024 (UTC)

Icon Cropping

Menu/UI icons (character, weapon, special, skill, etc.) should be upsized to 600% of the original image size and uploaded in .png format. The original padding should be preserved. (This guarantees the outline of the "Super" and "Awakened" versions to match with the basic icon when resized.)

This should probably be amended to something like:

Menu/UI icons (character, skill, special, weapon, etc.) should be upsized to 600% of the original image size and uploaded in .png format. The original padding should be preserved. (This guarantees the outline of the "Super" and "Awakened" versions to match with the basic icon when resized.)
* Note: Character (face) icons are an exception as they need to have their padding removed.

When I extracted the icons, the character ones had lots of empty space to the sides and the bottom, which unlike the other icon types isn't useful for the wiki.-JackyHF (talk) 03:05, 26 December 2024 (UTC)

Good catch, done –Taqx2 (talk) 12:09, 26 December 2024 (UTC)