Talk:PS2 Classics Emulator Compatibility List

Changes 2021 july

I have some ideas for a few upgrades (practical and visual) related with the compatibility lists that affects several pages, are a lot of small details and i guess some of you will want to discusss them incase i missed something that coould be problematic or if you want to do some critic or suggestion. Later i will make a complete list of changes here to discuss them. I would like some agreement before starting doing the changes, if i dont see any feedback i will consider all you agrees with the changes--Sandungas (talk) 08:51, 16 July 2021 (UTC)

• I my honest opinion, it would be more important to remove all the wrong and double titles and to clean up the list instead of changing it by design. Roxanne (talk) - 16th July 2021 - 16:51 GMT+1
  • I agree that {{Unplayable}} needs another color font but I recommend to make it white like it is for {{ps2classics}}
    • The Flagonly edit is good but I don't understand the changings for your "Jumptoletter" edits.
      • {{untested}} won't help much since people tend to add templates only for Games/Regions they also tested.
• Im not sure what you mean, ive seen agrippa doing some changes related with the double titles and the style he is using is fine imo, i dont see any problem with it and i dont have any better idea to deal with it. The changes im proposing are unrelated with that, unless you want to propose some kind of rowspanning but that could be problematic for the sorting feature i added and confusing for wiki editors newcomers--Sandungas (talk) 16:31, 16 July 2021 (UTC)
  • {{unplayable}} and {{majorissues}} have the colors inverted with each other, and both uses a border that represents the state "pressed" because both are intended to represent something negative
    • Not sure if you mean the latest edits i made to the template {{jumptoletter}} or the whole purpose of it. Regarding the purpose, the initial goal was to clear-out the bottom of the tables. This way the wiki editor newcomers are going to find a lot of non-understandable stuff at top but the bottom of the table will be very simple. The first requirement was to use an argument to highlight the current page section but later i improved it a lot more because i realized it can be used in many other pages like: {{Template:PS2_Classics_Emulator_Compatibility_List}}, {{Glossary}} or other pages i could be missing and/or could be created in the future, also is intended to be used in all the other compatibility list pages for PS1, PSP, etc...
      • Let me try to show the problem first and try to think in reverse way, the question marks in the table cells are a problem, not only because they breaks the visual style, but mostly because doesnt represents anything at all, are exactly the same than keeping the cell empty, ive seen you made a template {{?}} to try to center the question mark a bit and give it a color but thats not enought imo because is just something visual, the root of the problem (not representing anything) is still there. I think the solution is to use the {{untested}} because it means that """The game was released for this region but nobody tested it""". In other words, is not intended to help the wiki editors, is a new requirement, everytime someone adds a new game he/she should take the effort to google and find for which regions was released and fill the table as a minimal with either {{untested}} or {{notavailable}}. Just to show you an example of what we can do with it, the other day i was checking for how many regions was published all the games from the # section and i know i could replace all the question marks from the # section by {{untested}} because i know the games was published for that regions, also note there was many notes at right that was telling "untested" and i had to add some more notes with the text "untested", and that was not practical, with the new template {{untested}} we could delete that notes with the texts "untested" at the right
• As I said I don't like those ideas personally but I'm the last one here to block any new ideas etc., especially not since I don't maintain at this wiki anymore on a regular basis. If you feel comfortable with it, go on but I had other views in this list. - Roxanne (talk) - 16th July 2021 - 21:16 GMT+1
  • Regarding the "untested thing", this is what I mean. First we need to "clean" every Title on the whole lists which I know is huuuuuge work to do. But still who is interested when wants to add a Game to check if that Game got released in other regions or not or even if so, who is interested to test a Game from all three versions. If you check the changes in it's list, then you will recognize that only a very small amount of edits contains new entries for a Game, which got tested for two or even all three regions. Every other edit only contains a edit or a new entry for only ONE region mostly.
    • Aah now I see the difference in "jumptoletter", but still don't like it, sorry.
      • Oh btw the ? template wasn't created by me. It already existed before on PS4 wiki for other purposes.

I have been cleaning up the list for weeks. First of all, I want to remove the double/triple entries of the same games. I am following the hints Roxanne has posted some years ago on the PSX-Place. But I have restricted the brackets to the different revisions of the game (for example, MGS 2 Substance). The names for the different regional releases (or written in Japanese script), I am putting as a smaller, italic font below the first one (someone has started doing that already on the list). If the game is made by a Japanese developer and released worldwide, I am putting the Japanese name in the notes section. Second of all, I want to get rid of all external links in the notes section, because we have got a link to the aldostools database here. Third of all, I want to remove every "None" in the notes section too (or such words, like a "working", "without problems", etc.). Regarding the changes, I am not sure if they are conspicuous enough to the reader. --Agrippa (talk) 01:07, 17 July 2021 (UTC)

• One tip from me I didn't listed in the PSX-Place Thread: When a Game is both released for PAL and NTSC but with different naming for both region, I always have chosen that region as a first where the Developer is also deployed and/or where the Game was released first. Bully is a good example here again since Rockstar Games is a American Developer, so I listed it on "B" and not on "C" for the PAL name. - Roxanne (talk) - 17th July 2021 - 12:45 GMT+1
  • I have been following this one accidentally, looks like. It is a good point to note too. I am not sure if the {{untested}} thing is needed. The "?" does the job for me. Changing the font colour of the {{Unplayable}} from black to white is a good idea.--Agrippa (talk) 12:35, 17 July 2021 (UTC)
• Take a look at what i did here with the new template {{jumptoletter}}, the previous revision of the page had the same block of text repeated one time for every section (it was not doing the highlight in red for the current section), so this edit is an improvement, and it can be made in a relativelly simple way (i used the search-and-replace feature of notepad++), an small detail consequence of it is the bottom of the tables looks more simple, and as a bonus i reduced the page size in -12312 characters. The other edit i made here is because the template was designed to be used in it, i wanted to show you the results, is not like a huge revolution because visually and practically looks almost identical for wiki readers--Sandungas (talk) 13:07, 17 July 2021 (UTC). I decided to update the PSP page too, it was tempting because it had some minor problems and was relativelly easy to do, im not going to do it with CFW2OFW Compatibility List yet because is too much crowded, and im not going to do it either with the PS2 Classics Emulator Compatibility List because is needed to add more settings in the table headers to achieve the "3D" border effects im using in the guinea pig tests, probably i would need to talk about that borders later, but by now keep attention at how i configured the width and text alignments in the table header, is actually solving a problem of incorrect syntax (hard to explain, but there are attributes overriding each others in a nonsensic way imo), the way im doing it in this edit is more simple and the result is the same, unless im missing something... this way with a simple {| class="wikitable mw-datatable" style="font-size:85%; width:100%;" is better--Sandungas (talk) 15:19, 17 July 2021 (UTC)
  • Aah now I get it. Ok this makes things easier, although I don't like the visual design now abd I prefered the older one but this is again only me I guess. - Roxanne (talk) - 17th July 2021 - 19:41 GMT+1
    • About what visual design are you all talking about? Do you mean that "guinea pig" table below?--Agrippa (talk) 22:52, 17 July 2021 (UTC)
    • I guess she means the location of the "back to top" link but i think we agree at this point that location can be considered a minor detail that doesnt matters much, actually at some point back in 2017 we was displaying it in the same way im proposing now, with the "back to top" located at the right of the "Z". Also think in it this way, https://www.psdevwiki.com/ps3/File:9s2YzIj.jpg from a practise point of view the old style had the row of letters and the "back to top" separated but very close to each other it was just a matter of moving the mouse a bit up or down so is not much diferent... but it makes sense to have all the "page navigation links" in the same bar with the new template {{jumptoletter}}, visually is fine, and is intuitive too--Sandungas (talk) 16:20, 19 July 2021 (UTC)
  • I was waiting for an agreement about using the template {{jumptoletter}} in the PS2 compatibility list but i cant wait indefinitelly, i been implementing it in the other compatibility lists for tests, works and looks fine so i did it for the PS2 compatiblity list too, now all the compatibility lists (ps3 domain) are using it, and one of the "legend" floating templates for PS1 (the other for PS2 is not using it yet) and i will make a new one for PSP to do some tests--Sandungas (talk) 12:40, 21 July 2021 (UTC)
• Initially i was thinking in doing most of the related changes im proposing (after convincing you) in a single edit or a couple at most, but i changed my mind about it, is better to do the changes in steps because this way is easyer to see why im doing every change, next thing im going to do is to "fix" the text alignments in {{ps2classic}}, {{playable}}, {{majorissues}}, {{minorissues}}, {{unplayable}}, {{notavailable}}. If you take a look at the code you are going to realize whoever that made them was trying to align the texts to center, but is not working because all texts are displayed aligned to left inside the table cells. What im going to do first is to use a guinea pig template named {{ps2classic}} where im going to fix that problem, to add 2 more features i imagined yesterday (i want to be able to use them also "inline" in between standard texts outside of tables, and maybe i will also include a "abbr" text to add more info hidden), and im going to add also the settings required to generate that cool "3D border" visual effect--Sandungas (talk) 13:13, 21 July 2021 (UTC). The new template PS2 Classic--Sandungas (talk) 17:26, 21 July 2021 (UTC)
• Agrippa, i dont like either the "None" texts at right of the tables (take a look at the PS1 compatibility list to see how it looks when used massivelly), but the problem we have is we need to dislpay something inside the "notes" table cell, otherway if we dont display anything it looks like nobody cared about that game, so what do you think about the new template {{worksfine}} ?, is just a test, feel free to change the texts, colors, whatever, consider it is your guinea pig. It needs to be something generic in many ways, if you have other ideas about what to do with it let me know--Sandungas (talk) 17:26, 21 July 2021 (UTC)
  • Ok, I am still a begineer when it comes to the Wiki, I do not want to discuss a code issues therefore. But I am fine with the "jump to letter" changes you made. They are very good in my opinion and they do look better indeed. About the other suggestions:

1. Yeah, the alignments have to be corrected to the center. And the Unplayable's font changed to white.
2. I am not a fan of the "3D border" effect. It is just not convincing me at all in that guinea pig table.
3. I do not think that we have to use a generic note that everything works fine. When the game is listed as a playable, it does mean to me that it works without a problem (as explained in the template at the top). When there is an issue, we add it into the notes column.
4. I have a mixed feelings about the new PS2 Classics template. While it is well done and cute, that violet background does affect the clarity of the list. I mean, that saturated green does show the game is very playable, because officially released by Sony.--Agrippa (talk) 23:06, 21 July 2021 (UTC)

• I just realized about a detail related with the location of the {{jumptoletter}} navigation bar. In few words, is going to be a lot more useful if we locate it at top-right corner of the tables (in the way im doing it in the guinea pig in this edit). The point is... try to do this sequence of actions: 1) Load the page for first time, so you are at most top 2) click in the link to the "T" section 3) Now try to click in other link of the navigation bar... oppps you need to move the mouse whell, damnit. The goal of locating the navigation bar at top-right corner is because we will have the bar always visible everytime we click in a new letter, so we can navigate the page by clicking multiple times in it without using the mouse whell (thats a great feature for lazy dogs). To be fair i have to say that the previous location of the "back to top" link at top-right corner was fulfilling that purpose (but i didnt realized about it so i was not taking it into consideration), and in some way i broke it when i moved the "back to top" link to bottom. But i was trying to be practical from the point of view of how the mediawiki markup/code was written, i was trying to simplify it, and what im suggesting now is also for practical reasons because i think is going to work great and is an improvement (in comparison with the previous table style used some weeks ago at top-right corner of the tables there was only a "back to top" link but no links to other page sections). Also, if we locate the navigation bar at top-right corner it makes redundat the other navigation bar located inside the Template:PS2 Classics Emulator Compatibility List. Think in it while taking a look at the page, if we relocate the navigation bar at top-right corners of the tables we are going to have the navigation bar from letter "#" visible since the first time we load the page. Btw roxanne, do you mind if i rename the template Template:PS2 Classics Emulator Compatibility List to Template:PS2CompatListLegend ?, im asking because we have 2 more in the collection of templates that are "children" of the compatibility lists, Template:PS2CompatListCounter and Template:PS2CompatListHeaders and im trying to follow a shorter naming convention--Sandungas (talk) 18:19, 26 July 2021 (UTC)
• Please take some time to consider the problem im trying to explain in this edit related with the new template {{available}} im proposing to solve it. If at some point someone starts trying to complete the "availability" of some page sections in the same way i did in this edit with the games from the # section (in other words, without doing any test, just by googling) you are going to realize is a bit frustrating because there is some info (the existence of an untested game game for a specific region) that cant be represented in the actual compatibility lists. I added a couple of tables at bottom with examples from "real world" cases where it can be seen that by adding only the {{notavailable}} is not good enought because it leaves some room for speculation (the options 1 or 2 from the "Notes" column are the kind of deductive process most readers are going to do) but if we add the {{available}} then there is no room for confusion and allows to remove the weird {{?}} (hint: the {{?}} doesnt means anything, are pointless). The only reason why i decided to use the {{?}} temporally was because are configured with the data-sort-value="8", i needed it as a test to check that the new sorting methods was working fine, but in long term all the {{?}} needs to be replaced by other tags, and one of the good consequences of what im proposing by using the new {{available}} is that we can replace all them right now without need to do any test, the only thing needed is... time, pacience and care to check for how many regions was published every game in this link ---> https://wiki.pcsx2.net/Category:Games or https://wiki.pcsx2.net/Complete_List_of_Games. You know... as a minimal we can replace every {{?}} by either a {{notavailable}} or a {{available}}--Sandungas (talk) 02:25, 29 July 2021 (UTC)
• As probably some of you noticed in my previous edits of the last days related with the compatibility lists i didn't changed any color of the "tags" that are actually in use, either in the tables themself of in the "legend". But now everything is ready to start implementing some changes that affects the colors. Long story short... i been playing around latelly with 4 different ways to applicate colors to the tags: "background color", "font color", "font shadow color", "border color". The only color changes im going to do now are the background color of the "PS2 classic" (background from green to blue), and the "notavailable" tag (background from lightgrey to darkgrey, and font to lightgrey), im going to update the hidden descriptions in the tags, update the "legend", implement also the new "counter", replace all the apparences of "official" by "ps2classic" and add some examples about how to use the new "available" in the compatibility list--Sandungas (talk) 20:53, 1 August 2021 (UTC)
  • As I said before, I am not a fan of the blue PS2 Classic tag. There is no need to introduce another "available" tag. There is a need to update the region exclusive games to lessen the amount of "?".--Agrippa (talk) 22:27, 1 August 2021 (UTC)
  • The "white logo/text on top of blue" is the design used by sony in the cardboard box of some PS1/PS2/PS3/PS4/PS5 bundles, and also in the PlayStation Store. In this case im using it to represent the store, i even added an icon with the white bag in the "tag" for the most noobs that doesnt understand what means the name "PS2 classic" and the cosequences of being labeled that way (it represents the best compatibility), in some of the experimental versions i was even adding a link to the official store just to be even more explicit but i remove it at some point because i thought it was excesive, anyway, i think the {{ps2classic}} represents very well that it was published in the store. The {{available}} is an improvement for the wiki reader because allows to give info to the reader that it was not posible to give before, is also intended to delete all the notes at right with the sentence "Untested", and in long short term is a {{?}} killer--Sandungas (talk) 02:10, 2 August 2021 (UTC)
    • The "available" tag is not obvious to the reader. It has to be named just "untested". Its background has to be little more brighter, the same as the "?" sign tag in my opinion. Similarly, the "notavailable" and "available" fonts are not clear to me. I think we have to change the meaning of the "playable" tag. It has to be like the PCSX2 one equivalent and as the name itself does suggest - playable from the start to finish. Now, it is described as a "Works perfect without any noticeable error." Unfortunately, very few games are playable perfectly without any noticeable error. And never will be. Even the Sony released PS2 Classics have got a imperfect workarounds, just like slowing down the game to get rid of the jitter. When it comes to the new template, I think adding a symetrical grey table at the bottom to include the resource links would improve a look in my opinion. Just like expanding the width to equal the list's headers below.--Agrippa (talk) 19:02, 2 August 2021 (UTC)
    • Well, the initial proposal was to name it "untested" but after the critics i decided to name it "available" to make more obvious that is a negation of the "notavailable" that already existed, the decission to name it "available" was also becaue is easyer to remember for wiki editors, anyway now it shows the text: "Available but untested", both names was popular (used here or in other compatibility lists), so the best solution was to include both, the colors used in "available" and "notavailable" are inverted, with this i mean... the background color of "notavailable" is the font color of "available" (and the other way around, the background color of "available" is the font color of "notavailable"). This creates an intuitive color relationship in between them, i dont mind the exact color tones other than needs to be greytones i will make some more tests here for you to see other greytones combinations but i like the actual "available" and "notavailable" colors because looks like bleached, i was not trying to achive that bleached effect, is just something that happened while trying to adjust them but thats a good visual effect because are like a group for "undefined compatibility".I dont see any description in the PCSX2 wiki about the "playable", i guess the "playable" description: "playable from the start to finish!" could be a bit better than "Works perfect without any noticeable error." but i dont like it either because i dont think including the word "playable" in a description of "playable" is gramatically correct, lol, i mean is like cheating, in a description we are not supposed to use the word we are describing, but im taking a look at https://rpcs3.net/compatibility and they are falling in the same fault :D. This is one of the times when i would really like someone native english speaker with some good redaction/resuming skills and tell us a nice description, short, explicit and very accurate, i dont have any special preference for that descriptions btw... the only restriction we have (consequence of the "hidden text" feature i implemented in the tags) is the first line of the descriptions needs to be 95 chars max... so feel free to play around with the "guinea pig legend" at bottom of this page (you or whoever that wants to suggest new descriptions) and overwrite them, dont worry about breaking it the table we can recover it from the page history. The area at bottom of the "legend" (where appears the links with the "resources" and "other compatibility lists") is not restricted in size like it was before, i mean... right now we just have 4 links but i would like some of you to suggest more links to add, there are no limits really if at some point we cummulate a lot of links it would be fine visually, links can be cummulated at bottom like an inverted pyramid, thats something we was not able to do before with a good look but now is ready incase is needed, also keep in mind we can use that same "legend" style in other compatibility lists that could require more links--Sandungas (talk) 01:31, 3 August 2021 (UTC)
• Im playing around with a new visual effect that looks pretty nice, it looks so good that im convinced of doing it but i want to advise you before the change, in short... i want to replace the background color of the tags by a gradient of 2 colors, this is mostly a reminder of how to do it, and also allows you to see how is going to look. Try to edit the "ps2classic" template, replace all apaprences of background:#0070D0; by background-image:linear-gradient(#0090f0 0%, #0070d0 33%, #0070d0 66%, #0050b0 100%);, click in "show preview" (and dont save the changes, let me do it later). I dont really want to change the current background colors but as you can see is needed to modify them a bit because instead of using a single color now is going to be needed to use (at least) 2, for the "color start" and the "color end" of the gradient (and i guess both should be a bit different than the one we was using). Btw, this allows to achieve a different "3D effect" of what i was trying before with the borders and outline settings that was more problematic. I need to make some experiments with all this effects to see if i can use a combination of them... anyway, it seems we are moving on to the next experimental level. My original goal of the first versions of the guinea pig table was to use some kind of 3D effects to represent different compatibilities, and it seems this degrades of colors allows to do it in a non-problematic way :) --Sandungas (talk) 12:48, 13 September 2021 (UTC)
• Im going to enable the 3D effects in the default "table mode" of all the 8 compatibility tags, but also im going to drop the feature to align them to left/right by using syntax {{tagname|left}} or {{tagname|right}}. When i edit wiki and i need to modify something i use to "superseed" the previous version (always adding but never removing), the fact is the tags was originally intended to be able to configure his horizontal alignment inside tables to left/right/center (but the feature was broken)... so one of the first things i did was to "fix" that feature of the tags, is working fine but as far i see this custom alignment is not used in any wiki page, and personally i dont see any circunstances where it could be handy... sooo in the practise is mostly pointless but the "logic" used in the tag templates to identify when is used the parameter "left" or "right" is tricky, by removing the support to align them left/right inside the tables im going to simplify them a lot--Sandungas (talk) 14:53, 11 October 2021 (UTC). And im going to swap the background colors of {{available}} and {{notavailable}}. The logic i was trying to follow before is the darkest gray color represented the worst compatibility (so "notavailable" needed a background color darker than "available"), but now i think the most intuitive rule to follow is "the absence of color is the worst" (in other words, the gray tones with a high tendence to white are worst). In some way this is was agrippa was suggesting to do when he was insisting in using a extremelly bright gray tone for "notavaiable", at that point i increased the brighness of both (because in some way i agreeded with him, i wanted both to be very bright gray tones) but now i think it was not enought, the best solution is to swap them--Sandungas (talk) 16:12, 11 October 2021 (UTC)

Guinea pig tables

In the first "Prototype 1" table below i was trying to use the border settings to create some visual 3D effects (specially "inset" and "outset"... and also "groove" and "ridge" that are a bit meh), the problem is the border is displayed outside of the table cell (it overlaps the separation lines and each other cells), because by default the wikitables are using the seting "border-collapse:collapse", you can take a look at how it works here
Long story short... to bypass that collapsing of the borders the first trick i used was to do a "border-collapse:separate" in the wikitable and some more settings and tricks derivated from it. The biggest problem was that the table displays the lines in between cells with 2 pixel thickness (this looks bad and is not a standard wikitable)

Prototype 1 (this is not a standard wikitable and the 3D effects was meh)

# · A · B · C · D · E · F · G · H · I · J · K · L · M · N · O · P · Q · R · S · T · U · V · W · X · Y · Z · Back to top

Game Name	PAL-EU	NTSC-U/C	NTSC-J	Compatibility Notes
{{ps2classic}}	PS2 Classic	PS2 Classic	PS2 Classics
{{playable}}	Playable	Playable	Playable	Works fine
{{minorissues}}	Minor Issues	Minor Issues	Minor Issues
{{majorissues}}	Major Issues	Major Issues	Major Issues
{{unplayable}}	Unplayable	Unplayable	Unplayable
{{available}}	Available (but untested)	Available	?
{{notavailable}}	Not Available	Not Available	Not Available

After some experiments i found different ways to create 3D effects inside the cells, so is not needed to use the trick to uncollapse the table, it works in a standard wikitable, also the 3D effects are way better, im using 2 shadows in black & white with different displacement, and the shadows merges with the background using alpha, this simplifyes the color adjustments a lot, and visually it creates perfect gradient of colors, im also using an additional "outline" effect with a displacement to improve the 3D effects a bit more

Prototype 2 (this is a standard wikitable)

# · A · B · C · D · E · F · G · H · I · J · K · L · M · N · O · P · Q · R · S · T · U · V · W · X · Y · Z · Back to top

Game Name	PAL‐EU	NTSC‐U	NTSC‐J	Compatibility Notes
Get The Party Started	PS2 Classic	Playable	Minor Issues	Good compatibility tags have a "3D bump" effect (goes outside the screen)
Get The Party Started	Major Issues	Unplayable		Bad compatibility tags have a "3D hollow" effect (goes inside the screen)
Get The Party Started	Available (but untested)	Not Available		Undefined compatibiity are flat (different than the others)

Changes 2023 may

Post-expand include size 2,097,152 bytes exceeded

We have exceeded the page size, it still loads fine in web browsers but there are 3 warnings advising of this problem:

• In standard page view mode, at bottom of PS2 Classics Emulator Compatibility List --> "Pages where template include size is exceeded"
• In edit page mode, at top of PS2 Classics Emulator Compatibility List --> "Warning: Template include size is too large. Some templates will not be included."
• In edit page mode, at bottom of PS2 Classics Emulator Compatibility List --> "Post-expand include size 2,097,152/2,097,152 bytes"

This means the current total size of the included templates is bigger than 2,097,152 characters (i dont know how much big, probably just a bit more) The wiki loads the templates in order "from top to bottom", and when it hits the limit of 2,097,152 it doesnt loads any more templates As a consequence, there is a Template:Games located at most bottom of PS2 Classics Emulator Compatibility List not loaded... and eventually if the page size continues increasing (either because some wiki editors adds more games or increases the texts inside the "notes" cells) the problem could spread and could affect other templates
Im used to this problem because it happened months ago and it was tricky to fix it because there are many templates involved and many different ways to do it (some are less destructive than others) Is a long story and i dont want to write a wall of text, so i suggest you to take a look at all my wiki edits in between 2021-12-22 and 2021-12-24 (it took me a couple of days to realize what was happening by doing some experiments) and read the comments of my edits where i was mentioning the exact amounts of "Post-expand include size" of PS1 Classics Emulator Compatibility List before and after the edits in the other templates loaded by it. Also check the history of my edits in Template:Notes, Template:Works, and the PS1 Classics Emulator Compatibility List itself along that week because are related with each others
The template currently named Template:Works was originally integrated inside Template:Notes, i splitted it and i used it as a guinea pig because is used hundred of times in the PS1 Classics Emulator Compatibility List When i splitted it the "Post-expand include size" of PS1 Classics Emulator Compatibility List was reduced a lot, but also i removed all the "if-else" and other logic statements and "optimized" it as most possible to reduce the "Post-expand include size" of the PS1 Classics Emulator Compatibility List from 1,967,755 (at date 2021-12-22) down to 1,343,200 (at date 2021-12-24)
Long story short... thats the 2 different ways i know to fix this problem, either by splitting templates (removing logic statements) or by small optimizations intended to reduce the amount of bytes in the template. And now is needed to do something similar in some of the other templates, but the decision of "where to cut" is not so easy because there are many different ways to do it, in general you can figure personally i like every single detail of all that templates because i made them so i consider them "features" and disabling features doesn't makes me much happy but i know there are some details that can be optimized or simplifyed
In the last days i been reviewing the templates i made considering this 2 options (splitting or optimizing) and i think splitting could be counterproductive, and i found some visual effects i used in the tags that to be honest was "extras" barelly visibles and a bit pointless, so im going to start by optimizing the 8 compatibility tags. I consider this is a destructive process because im going to remove subtle visual features so is like a downgrade, but is needed, and the resulting "Post-expand include size" after this optimizations is unknown, we will see later if is needed to do some more butchery--Sandungas (talk) 09:23, 29 May 2023 (CEST)

Changelog

• 2023-05-30 Removed outline effects in 6 tags [Table and Inline Modes] and 2 tags [Inline Mode]. Results in Post-expand include size 1,951,611/2,097,152 bytes
• 2023-05-30 Replaced " font-weight:bold;" (18 chars) by '''''' (6 chars). Background and font RGB color notation reduced from 24 chars to 12 chars in the 8 tags [Table and Inline Modes]. Results in 1,845,663/2,097,152 bytes
• 2023-05-30 All the edits today in • • • • • • • • . Results in Post-expand include size 1,747,531/2,097,152 bytes
• 2023-06-07 After a bunch of optimizations to the 8 compatibility tags i reduced the Post-expand include size to 1,265,353/2,097,152 bytes, are a lot of edits so im not going to resume here what i did, i left lot of comments in my edits trying to expain what/why i did it, if someone have some feedback let me know. But im not satistyed with the size reduction, i still have some ideas to reduce it even more but there is something i need to explain before the next step. Many months ago, when i added the "3D bump" effects in the tags i was trying to reduce the width of the 3 region table columns to the minimal posible to reduce the "wasted space" and i made a deal with myself of 100px, considering all the tags needs to have the same width, the longest tag is the "ps1classic", and the width of the wikitable header cells for the 3 regions are carefully adjusted to the longest tag... well... a couple of days ago i tryed it again and the reduction is ridiculous (it felt like a dejavu, falling in the same trap twice), but the real reason is not only because the "ps1classic" tag (with the store icon) but also because the text "NTSC-U/C" in one of the table headers, so what im going to do is to remove the store icon from the "ps1classic" and "ps2classic" tags, and replace the text "NTSC-U/C" by "NTSC-U" (same lenght than PAL-EU and NTSC-J) in the table headers. In my tests it seems this changes are going to reduce the width of every region column from 100px to 85px or so (15px width reduction * 3 columns = 45 pixels recovered in total) and also is going to reduce the Post-expand include size of the compatibility lists a bit more
• 2023-06-15 The implementation of the wiki dark skin (most specifically, some additions to the 8 tags code) made me stop with the optimizations for a time, i will return to it later on, as far i remember after the implementation of the {{altnames}} and before the dark skin changes the Post-expand include size was around 1,280,000 --Sandungas (talk) 05:51, 15 June 2023 (CEST)
• 2023-07-02 Very good news, the small edit i did today in Template:notavailable reduced the post expand included size of the PS2 compatibility list in around 100.000 bytes. This is a lot specially considering that specific tag needs to be cleaned up a bit more (is needed to remove the padding settings), and the same tricks are going to be applyed to all the 8 compatibility tags later --Sandungas
• 202-07-03 Current Post-expand include size after the new compatibility-tag class has been fully implemented: 1,244,274/2,097,152 bytes --Sandungas

Header cells width insensitive to the presence of sorting arrows

There are lot of details to comment about this but the resume of the story is that i been struggling with this trying different tricks since years ago, but some months ago i figured a new trick that seems to be failproof for all screen resolutions and solves the problem for once, the payback is the header height is going to increase a few pixels and the "active" area for clicking in the arrow is going to have an smaller height
The root of the problem is... the presence of the wikitable arrows (enabled by class="sortable" and dependant of web browser script features enabled) doesnt allows to optimize the cell/column width
The reason why im saying this is because the arrows (images) "expands" the cell width dinamicaly (when the page loads you are going to see how the arrows does a "pop up" effect and changes the column widths) and the width of the arrow doesnt counts into the total cell width (are like an addon but we dont have control of its width)
The only way i found to prevent that "pop up" effect is by seting "background-position", this allows to "unlink" the arrow from the cell (removes the "pop up" efect) and allows to relocate the arrow image to any position... but this adjustment is dependant of web browsers and OS's, is not posible to do an accurate failproof adjustment either
The solution im going to use is based in the fact that all wikitables displays the arrows only one time per column and are always located in the last header row (if you start the wikitable with 2 header rows the arrows will be located in the second header row)
I used the trick in Template:CELL_pad_layout_90nm and some other wikitables (click in edit to see how im relocating the arrows in the second header row and hiding some borders to create a visual effect "merging" some header cells vertically)
Im going to copy the PS2 compatibility list header here for experiments, this will need some time because i want to reduce the widths to the minimal (for me every wasted pixel recovered is a treasure, my precious), and i also want to ask derf to make some modifications related with the new class="compatibility-tag" (more about this request later)--Sandungas (talk) 05:51, 15 June 2023 (CEST)
The current solution uses 2 header rows and relocates the sorting arrows to the second row (visually joined together in a single header row by hiding some horizontal borders). This makes the widths of the top header row static to allow for an accurate control of the column widths and as a consequence an optimal usage of the horizontal space available in the page. The only problem remaining is the hidden borders are not completly hidden in android/chrome while using the dark-skin, but this seems to be a problem related with the dark skin only--Sandungas

This section is striked to indicate that eventually will be deleted because the problem was solved. The remaining problem related with the (not completly) hidden borders while using the dark-skin is affecting many other wikitables (im sure about it because i used to do it since many time ago) so it seems to be something generic and is better to talk about it in Dark Mode Suggestions --Sandungas

compatibility-tag class

• Derf as far i understood in this edit you excluded the class"compatibility-tag" from the dark-skin changes (to protect its colors), i like the idea and i want to take advantage of the existence of that new class by adding to it some more properties that are common for the compatibility tags, if you add them in the class i will be able to remove them from the 8 tags and i have the hope the "post expanded include size" of the PS2 compatibility list is going to be reduced a lot (not completly sure about it). The most important thing of this test though is that i want to remove the horizontal padding because i need to do some tests with the compatibility list header widths, the new header style above is almost ready, the only thing missing is to reduce the horizontal paddings (in the 8 tags, and in the region header cells) --Sandungas (talk) 09:16, 17 June 2023 (CEST)

.compatibility-tag {
    text-align: center; /* default: left */
    font-weight: bold; /* default: normal */
    white-space: nowrap; /* default: wrap */
    padding: 0em; /* default: 0.2em 0.4em */
    cursor: help; /* default: auto */
}

Inverted arrows ?

Im not sure if is just me but it looks like the sorting arrows are inverted in all tables (it seems to be a general problem). In my oppinion the "arrow down" icon (associated to a text that tells "sort descending") should order the numbers from 0 (at most top),1,2,3,4,5,6,7,8,up to 9 (at most bottom)... but is doing the opposite. This is relativelly easy to correct for the 8 compatbility tags by inverting he "data-sort-value" given to them that can be seen at the most left column of this table. Im tempted to do it as a temporal fix, but i think it would be better to fix it globally for all the wikitables (by inverting the code that loads the arrow icons), what do you think ? --Sandungas (talk) 10:50, 22 June 2023 (CEST)

Sort	Tag	Text
0	PSone Classic	A
0	PS2 Classic	A
1	Playable	B
2	Minor Issues	C
3	Major Issues	D
4	Unplayable	E
5	reserved	F
6	reserved	G
7	reserved	H
8	Available	I
9	Not Available	J

• Had the CSS for them switched. Fixed now! Derf (talk) 06:46, 2 July 2023 (CEST)
  • I see in your edits that you are right, there was something inverted, but right now the white arrows are not displayed, and it seems you misunderstood me. What distubs me a lot (to the point that i wonder is this is a custom edit made many years ago for some weird reason) is the up/down black arrows (the defauts shown in vector skin) seems to be inverted too --Sandungas

Compatibility tags cursors and tooltips

The cursor property specifies the mouse icon to be displayed when pointing over an element. By default wikitables are configured as "cursor:auto", this means the cursor changes in between "cursor:text" (a vertical bar, when the mouse is over a text), or "cursor:default" (the diagonal arrow icon for everything else).This auto feature is an small annoyance because we dont need the cursor to change to the vertical bar (to select text) when movinig the mouse over a compatibility tag, the easyest way to disable it (and make the cursor static) is by overriding the default "cursor:auto" by anything else, and the most convenient are either "cursor:default" or "cursor:help"
The compatibility tags can be used in 2 different modes: table mode with syntax {{ps2classic}} or inline mode with syntax {{ps2classic|whatever}}
The tooltip (a text displayed only when you move the mouse over the tag) is preconfigured in table mode, but in inline mode the tooltip can be customized (in the example before it will display "whatever"). One of the reasons why i added this custom tooltip feature is because i wanted to "hide" some texts inside the compatibility tags used in PS2_Official_Configs, but in the practise i dont think it was a very good idea because most wiki readers are not even going to figure there is a tooltip text "hidden" inside the tags, it also overcomplicates a bit the usage and the tag templates format. The other reason is because i found a bug/flaw (call it whatever but i dont think this was intended) where mediawiki doesnt displays any tooltip if you use syntax {{ps2classic| }} (passing an "non breaking space" as argument), this trick allows to use the inline tag without tooltip, is used in al the compatibility list counters, in some inline tags in the "notes" at the most right column of the PS1 compatiblity list, and maybe somewhere else that i dont remember
Currently the cursor in table mode is confugured to "cursor:help" to display a question mark icon (in the same way the tooltip text is also preconfigured for table mode), but for inline mode is confugured to "cursor:default" because the tooltip text could not exist (doesnt makes sense to display a question mark icon if there is no tooltip text)
Well... i want to simplify all this by removing the custom tooltip feature for inline mode in all the 8 tags, so the cursor and the tooltip in inline mode will be the same than in table mode (the question mark icon, and it will load the preconfigured text tooltip)
Also... the syntax {{ps2classic|whatever}} or {{ps2classic| }} are going to be outdated (the tag will be displayed fine but the custom tooltip text is not going to be displayed), so it will be needed to update some pages that was using it to move that texts outside of the tag
I also think at some point is going to be a good idea to split the 8 tag templates "by mode" (inline or table), in other words, moving the code responsible to display the inline tag to its dedicated template, because this is going to reduce the "post expand include size" of the compatibility lists, lets say... this would be an optimization for efficiency and the payvback is we will have 16 compatibility tags instead of 8
The new syntax for the tags would be {{ps2classic}} -> {{ps2classicinline}}... or... {{playable}} -> {{playableinline}}. To summarize it... the table mode syntax doesnt changes, and the inline mode will not require to pass any argument to the template, the new names for inline mode are simple and easy to remember
I dont want to split the tag templates yet (i have some more ideas to experiment) but i want to start using the new syntax for inline mode, so in the meantime im going to create 8 redirections for them --Sandungas (talk) 10:05, 23 June 2023 (CEST)

• Couldn't we just have a CSS rule for .compatibility-tag to set the cursor to be the same in all cases? I think it'd be less work and be less confusing for users if we try and keep only 8 tags. Derf (talk) 07:08, 2 July 2023 (CEST)
  • Is a bit tricky to explain because i had to consider many details when the tags was originally designed and how im "nerfing" them now, but lets say... some months ago it was posible to use the tags in 3 different ways: {{ps2classic}} (table mode with the tooltip text loaded from Template:tagtexts and the cursor:help), {{ps2classic|customText}} (inline mode with the tooltip text passed as an argument and the cursor:default), and {{ps2classic| }} (inline mode without tooltip and the cursor:default), i added this features because i thought eventually could be handy, and i knew there was some other pages where i could start using them. But the fact is nobody used this features other than me, there are other alternative ways to do it, and after realizing about the problems of the "post expanded included size" of the whole compatibility list it was not worthy to increase the complexity of the tags, so right now there are only 2 modes {{ps2classic}} or {{ps2classicinline}}, there is no need to pass arguments to them and the cursor is set to cursor:help in all them as well as the tooltip automatically loaded from Template:tagtexts
    This decission is also related with the fact that when you created the compatibility-tag class, the first thing that came to my head was to move all the common properties from the 8 tag templates to it: nowrap, bold, center, padding... and a common cursor:help for all them (the cursor type was related with the presence of the tooltip text, but is not anymore)
    This allows to remove up to 5 properties from each tag template, im going to check right now if everything works fine and do a big cleanup of the 8 tags and the ps2 legend latest experiments --Sandungas
    • The compatibility-tag class seems to be active, at least is working partially, but the padding 0em is not loaded correctly, not sure why, can you figure it ?, the only experiment i can figure we could try is to replace the "padding: 0em" by "padding: 0em 0em" (just because the code we are overriding is "0.2em 0.4em" specifying two meassure units) or by "padding: 0px" (just trying to change the meassure units) --Sandungas
      • I added `!important`, looks like it works now. Derf (talk) 06:27, 3 July 2023 (CEST)
        • Yes it did work, i updated the ps2 legend and the 8 tags accordingly --Sandungas

This section is striked to indicate that eventually will be deleted because the problem was solved (the stuff related with the different tag display modes, and the variable cursors and tooltips), derf if you was concerned about the tag code splitting i suggested feel free to continue the talk, but dont get scared because i dont want to do any radical change yet, we will have time to talk about this later --Sandungas