C’est triste à dire, mais plusieurs studios semblent avoir construit des versions Linux natives uniquement parce que « C’était une option en plus dans le framework » ou « Pour faire notre comm’ » mais visiblement sans trop tester derrière.
On se retrouve avec des blagues comme XCOM 2 qui fonctionnait mieux sous Linux en passant par la version Windows + Proton plutôt que la version native, cette dernière étant atrocement consommatrice (notamment à cause de sa consommation mémoire).
La rétrocompatibilité peut être assez délicate aussi.
Après je conçois que l’écosystème Linux, de par sa multiplicité, n’aide pas les tests. Les prérequis logiciels sont aussi plus difficiles à exprimer que sous Windows, sauf si on veut forcer une poignée de distributions spécifiques.
CD Project expliquait que pour The Witcher 2 (qui avait une version Linux native), ils s’étaient pris un max de rapports de bugs parce que d’une part les configurations très hétéroclites, et d’autre part l’habitude du linuxien moyen à créer un rapport de bug.
L’effet kiss cool, c’est que la simple gestion de ces rapports de bugs dépassait l’intérêt qu’ils avaient eu à créer cette version native. Je ne sais pas si dans l’état actuel (notamment le bien meilleur support par défaut des cartes graphiques) le problème serait toujours le même. Par contre, Proton est devenu assez bon pour que dans beaucoup de cas il suffit pour le studio de déporter le support sur cet outil, sans à faire de version native… et ça ne ressemble pas à une bonne solution vue d’ici.
Mon expérience, c'est que les versions Linux sont plus difficiles à gérer sous Linux que les versions Windows.
À chaque fois que j'ai un jeu Linux un peu ancien, je sais que je n'aurai pas les bonnes versions des bibliothèques et que ça va être une galère pas possible à gérer les dépendances. Avec les versions Windows, ben, autant ça va être sûrement moins optimisés, autant je n'aurais pas ces problèmes.
D’une part, ça marche mieux sous Windows tout simplement parce que c’est beaucoup plus testé.
D’autre part, les utilisateurs Windows qui ont des bugs ont tendance à juste les ignorer, ou à se plaindre n’importe où sans vraiment attendre de réponse (et de toutes façons sans trop de donner de détails utiles) ; alors que les utilisateurs Linux vont plus avoir tendance à te faire du rapport de bug plus détaillé et qui va (au moins moralement) appeler à une réponse.
Après je conçois que l’écosystème Linux, de par sa multiplicité, n’aide pas les tests. Les prérequis logiciels sont aussi plus difficiles à exprimer que sous Windows, sauf si on veut forcer une poignée de distributions spécifiques.
Les éditeurs gagneraient certainement à ouvrir plus leur code et à garder les données proprio s'ils le souhaitent.
Ou s'ils ont vraiment une partie du code qu'ils veulent ultra secrète, à ne garder que ça en binaire fermé et sans dépendance.
Mais techniquement c'est relativement complexe à mettre en place (Si c'est un framework) et cela ne résoudrait pas forcément le fond du problème si le core contient trop de truc sensible…, il faut aussi fédérer une communauté de développeurs…
Le plus simple est de maintenir une distribution populaire, je pense Debian (base très largement diffusée).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par barmic 🦦 .
Évalué à 2 (+0/-0).
Dernière modification le 10 septembre 2024 à 13:34.
Je pense que la partie importante c'était pas le nombre mais le fait qu'il s'agisse d'une liste éditorisée, sinon tu peux dire que tous les paquets inclus dans debian et ayant le tag game sont des jeux natifs linux
# « A une version Linux native » ≠ « A une version Linux fonctionnelle », hélas :(
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10 (+9/-0). Dernière modification le 02 septembre 2024 à 11:01.
C’est triste à dire, mais plusieurs studios semblent avoir construit des versions Linux natives uniquement parce que « C’était une option en plus dans le framework » ou « Pour faire notre comm’ » mais visiblement sans trop tester derrière.
On se retrouve avec des blagues comme XCOM 2 qui fonctionnait mieux sous Linux en passant par la version Windows + Proton plutôt que la version native, cette dernière étant atrocement consommatrice (notamment à cause de sa consommation mémoire).
La rétrocompatibilité peut être assez délicate aussi.
Après je conçois que l’écosystème Linux, de par sa multiplicité, n’aide pas les tests. Les prérequis logiciels sont aussi plus difficiles à exprimer que sous Windows, sauf si on veut forcer une poignée de distributions spécifiques.
CD Project expliquait que pour The Witcher 2 (qui avait une version Linux native), ils s’étaient pris un max de rapports de bugs parce que d’une part les configurations très hétéroclites, et d’autre part l’habitude du linuxien moyen à créer un rapport de bug.
L’effet kiss cool, c’est que la simple gestion de ces rapports de bugs dépassait l’intérêt qu’ils avaient eu à créer cette version native. Je ne sais pas si dans l’état actuel (notamment le bien meilleur support par défaut des cartes graphiques) le problème serait toujours le même. Par contre, Proton est devenu assez bon pour que dans beaucoup de cas il suffit pour le studio de déporter le support sur cet outil, sans à faire de version native… et ça ne ressemble pas à une bonne solution vue d’ici.
La connaissance libre : https://zestedesavoir.com
[^] # Re: « A une version Linux native » ≠ « A une version Linux fonctionnelle », hélas :(
Posté par lejocelyn (site web personnel) . Évalué à 8 (+6/-0).
Mon expérience, c'est que les versions Linux sont plus difficiles à gérer sous Linux que les versions Windows.
À chaque fois que j'ai un jeu Linux un peu ancien, je sais que je n'aurai pas les bonnes versions des bibliothèques et que ça va être une galère pas possible à gérer les dépendances. Avec les versions Windows, ben, autant ça va être sûrement moins optimisés, autant je n'aurais pas ces problèmes.
Oui, je trouve ça triste aussi :(
[^] # Re: « A une version Linux native » ≠ « A une version Linux fonctionnelle », hélas :(
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+3/-2).
Donc les versions Windows marchent mieux, car les utilisateurs se plaignent moins ???
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « A une version Linux native » ≠ « A une version Linux fonctionnelle », hélas :(
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Ouais, ça fait un peu "on fait de la merde mais on préfère ne pas savoir".
[^] # Re: « A une version Linux native » ≠ « A une version Linux fonctionnelle », hélas :(
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Non, il n’y a pas de lien de causalité.
D’une part, ça marche mieux sous Windows tout simplement parce que c’est beaucoup plus testé.
D’autre part, les utilisateurs Windows qui ont des bugs ont tendance à juste les ignorer, ou à se plaindre n’importe où sans vraiment attendre de réponse (et de toutes façons sans trop de donner de détails utiles) ; alors que les utilisateurs Linux vont plus avoir tendance à te faire du rapport de bug plus détaillé et qui va (au moins moralement) appeler à une réponse.
La connaissance libre : https://zestedesavoir.com
[^] # Re: « A une version Linux native » ≠ « A une version Linux fonctionnelle », hélas :(
Posté par Maclag . Évalué à 4 (+1/-0).
Les éditeurs gagneraient certainement à ouvrir plus leur code et à garder les données proprio s'ils le souhaitent.
Ou s'ils ont vraiment une partie du code qu'ils veulent ultra secrète, à ne garder que ça en binaire fermé et sans dépendance.
[^] # Re: « A une version Linux native » ≠ « A une version Linux fonctionnelle », hélas :(
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
L'inverse de Open-core :D
Mais techniquement c'est relativement complexe à mettre en place (Si c'est un framework) et cela ne résoudrait pas forcément le fond du problème si le core contient trop de truc sensible…, il faut aussi fédérer une communauté de développeurs…
Le plus simple est de maintenir une distribution populaire, je pense Debian (base très largement diffusée).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# C'est facile de trouver des jeux commerciaux natifs Linux
Posté par Yth (Mastodon) . Évalué à 2 (+0/-0).
Par exemple ici il y en a environ 1500, soit environ un quart du catalogue complet :
https://www.gog.com/fr/games?systems=linux&hideDLCs=true
Certains tournent avec dosbox (qu'importe l'OS), une poignée avec scummvm, et apparemment quelques-uns avec wine, mais la plupart sont natifs.
Sur Steam, c'est plus difficile de savoir, la plate-forme avec le plus de référence est Linux, mais impossible de trier entre natif ou Proton.
[^] # Re: C'est facile de trouver des jeux commerciaux natifs Linux
Posté par barmic 🦦 . Évalué à 2 (+0/-0). Dernière modification le 10 septembre 2024 à 13:34.
Je pense que la partie importante c'était pas le nombre mais le fait qu'il s'agisse d'une liste éditorisée, sinon tu peux dire que tous les paquets inclus dans debian et ayant le tag game sont des jeux natifs linux
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.