ARM executables infoslots for Linux and Windows

[Dandelion Sprout 3]

So now that https://www.pcgamingwiki.com/wiki/Property:MacOS_ARM_app was created yesterday, I think it could be time to create such properties for Windows and Linux ARM games as well. I've worked pretty extensively in the past 3 or 4 days to create and fill up architecture support lists, e.g. (but not limited to) https://www.pcgamingwiki.com/wiki/List_of_OS_X_64-bit_games, so I wouldn't mind filling up more such lists.

Although Windows ARM games (e.g. Rayman Fiesta Run) are in the low two-digits, and Linux ARM games (e.g. 0 A.D.) can be counted on two hands (and may or may not also be divided between ARM32 and ARM64), it wouldn't surprise me if their numbers will increase slightly if game devs decide to add ARM support across all platforms and not just on macOS.

I do however notice that the macOS ARM API property has not been implemented into the architectures table, but is at the time of writing in the technical specs table. I presume that the architecture table could be modified as in this edited mockup in the attached image.

Edited November 20, 2020 by Dandelion Sprout
Critical grammar error

[Aemony 104]

The macOS (ARM) property was implemented as it was because it's not really feasible or easy attempting to implement it into the actual executable table because of the following reasons:

 

• The executable table contains horrendous underlying logic that is hard to work with that determines whether to show/hide columns in various scenarios. The column also interacts with variables set elsewhere (e.g. overall OS states set through the infobox, etc) which ends up causing the difficulty to increase exponentially.

 

• Each new column added eats into the Notes field's width of all rows, and with us limited to 820px at max for this table (it's the global max-width for all tables) the notes field can get a bit too small in the worst-case scenarios (all columns visible). This is further exacerbated by how all columns technically relies on the same single notes parameter...

 

• As you mentioned "ARM" can technically be divided between ARM32 and ARM64 meaning a proper solution would see implementation of both if we want to properly distinguish between the two.
   
  • I searched around yesterday trying to figure out if Apple's M1 supports apps in ARM32 or only in ARM64, which I sorta failed to come to a conclusion on. Technically the chip seems to support some ARM32 instructions, but I didn't manage to find a conclusive answer to whether macOS allows the use of those instructions or not.

 

• Another potential issue that arises is the fact that the row is currently called "macOS (OS X)". macOS 11 Big Sur which the Apple M1 chip requires is not "OS X" any longer (for once Apple actually left the 10 behind!), and so ARM support can be said to not apply for OS X at all.
   
  • Basically, much like the notes parameter, the name of that row currently jumbles it all together.
  • This could possibly be solved by renaming it to just "macOS" instead, but that's provided there aren't Mac OS "Classic" apps that have the PowerPC property set on them -- and it would still technically be suggesting macOS have PowerPC support...
  • The row would preferably attempt to (more convoluted logic) have different names depending on scenario, so it was called just "Mac OS X" (or OS X) if PPC and Intel 32-bit was the only columns set to true, and "macOS" if Intel 64-bit was set to true, or something... Basically a moving change to attempt to adhere to the actual name of the OS at the time of the game's release.
  • On another note, Apple's renaming of their OS and moving architectures as an PCGW template creator/editor is just... gah!

 

I know the current implementation of macOS (ARM) property isn't perfect -- I called it 'half-assed' multiple times yesterday on the Discord when I implemented it -- but it was the quickest way of adding support for a new important parameter that didn't force me to waste days trying to untangle the whole mess to arrive to a 'proper' solution that worked within the various limitations we have while still handling all different scenarios perfectly.

 

I might revisit the matter eventually, but right now the fact that I'm basically the only one that over the last year or so have been responsible for more in-depth complex changes to the PCGW templates means that unless someone else steps up and finds a working solution, it's all on me... And I'm currently both busy elsewhere but also tired of having another infuriating tangle with MediaWiki and the extensions that implements limited logic-based functionality unto it, as well as the limitations/requirements that PCGW enforces on the whole thing. Eventually, maybe, but I make no promises.

[Andytizer 265]

@Dandelion Sprout As Aemony mentioned we have a lack of manpower, so I invite anyone who has time to help create the Windows/Linux ARM properties. As a stopgap what you could do is create a manual table in say a new page like List of Windows ARM games. This will be a useful resource and once it is populated we can gauge the popularity and usefulness. Then, once the property is implemented we can port the manual list to the pages in proper templates.

Thanks @Aemony for implementing the macOS ARM property, it is a good implementation despite your self-depreciation, as the new Mac ARM is basically incompatible with macOS/OS X games that are x32 so ARM feels like a very different playform anyway. I've just got my MacBook Air M1 and would be interested in beefing up our support pages for this. Could we make a 'List of games that natively support macOS ARM'. Also I am struggling to figure out which games are Rosetta 2 and which are native M1. For example I refer to this Google Sheet I found online, but this lists World of Warcraft being the only natively supported game (beyond other iOS games) - is this really the only one?

[Aemony 104]

19 minutes ago, Andytizer said:

For example I refer to this Google Sheet I found online, but this lists World of Warcraft being the only natively supported game (beyond other iOS games) - is this really the only one?

From my understanding WoW is the only officially recognized one.

But it might not be accurate since, based on comments I’ve seen from regular app developers, it’s basically just a recompile of most projects that is needed.

A list can be created rather easily — it just needs to display pages in the games category that populates the new ARM property to true. Which right now is only WoW.

 

Also, you hit on an important aspect in terms of testing methodology... I don’t have a Mac myself, but I can imagine Apple doesn’t make it necessarily easy to spot whether Rosetta 2 or native is being used. Well, unless you /don’t/ have Rosetta 2 installed at which point (as I understand it) macOS will prompt to install it.