natho18

Effectivement. On peut aussi installer Bazzite ou CatchyOS qui supportent déjà les gpus nvidia et intel.
Et contrairement a ce qu'on pourrait penser, Bazzite n'est pas sous un sous Steam OS, de mon expérience c'est même supérieur.
Ma Legion Go S est venu avec Steam OS, j'ai fini par installer Bazzite.
De prime abord rien ne change, mais quand on bidouille Bazzite à plus à offrir.

La gestion de la luminosité est un plus,un filtre nuit serait bienvenu

Rosalina implémente déjà cette fonctionnalité.
Ouvre Rosalina (L + Down + Select) puis ouvre le sous menu "Screen filters", il te suffit alors de sélectionner le preset qui te plait.

Merci natho18 pour ces éclaircissement, tu as dit chapeau à celui qui a tout lu, j'ai envi de dire chapeau à toi d'avoir pris le temps de rédiger tout ce développement, écrit de manière propre et professionnel, avec un pseudo comme le tiens on te prend vite pour un kikou.

Sinon pour revenir au sujet, vous dites que l'interpréteur à besoin d'énormément de puissance pour alimenter toutes les manœuvres nécessaires n'est ce pas ? et bien vous avez l'air d'oublier que cette fois, nous avons entre les main une fucking PS4 PRO, n'en a t'elle pas assez sous le capot pour faire le café (comme dirait Benzaie) ?

Alors certes la ps4 pro et plus puissante, mais hélas une bonne partie de la puissance d'un cpu tient dans ses optimizations.
Surtout au niveau des accès mémoires.

Il faut savoir que les accès mémoires (ram) est ce qu'il y a de plus lent dans les machines actuelles et c'est le plus gros frein de nos jours.

Du coup, comme ce n'est pas un problème nouveau, les ingénieurs s'arrachent à trouver des combines pour les optimiser.

Parmi ces combines on va trouver:
-  une mémoire cache qui est très très rapide mais très limitée (généralement à quelques 2/4/16 mb)

- des accès non ordonnés (le cpu peut changer l'ordre d'accès de la mémoire pour les optimiser)
- la prédiction des accès mémoire et un pré-chargement de celle-ci

 

A savoir que ça c'est uniquement pour la partie donnée, mais les instructions (code du logiciel) sont elles aussi issues d'accès mémoire, et là, la prédiction et encore plus importante car ça permet de commencer le traitement d'opération qui viendront plus tard pour éviter des délais.

C'est assez technique et il y en a évidemment plein d'autres.

Sauf qu'on a un gros soucis: ces optimisations ne sont utiles que pour le language compris par le processeur, par conséquent, notre jeu émulé ne bénéficiera d'aucune de ces optimisations.
C'est donc un sacré bout de puissance en moins par rapport à la puissance brute qu'on pourrait avoir pour un jeu ps4 natif.

Mais c'est pas tout !

La ps3 elle aussi bénéficiait de ces combines pour optimiser l'execution du code natif ps3 sur la ps3.

Donc si on résume: 

 - On doit exécuter un code sans les optimisations du processeur de la ps4 (chute de puissance brute)
 - On perd les optimisations faites par le processeur de la ps3, ça veut dire qu'il nous faut encore plus de puissance !

 - Notre interpréteur qui doit traduire le langage va ajouter plus d'opération pour en faire une seule (imaginez une phrase qui passe de l'anglais en français, vous aurez plus de mots. C'est une image approximative, mais vous voyez l'idée)

Il nous faut donc un processeur beaucoup plus puissant que celui de la ps3 et qui ne soit pas trop lent en accès mémoire.

Une autre chose à savoir, c'est que la majorité de la puissance supplémentaire de la ps4 (et de la pro par extension) vient du gpu.
Le gpu est très performant ce qui permet d'afficher plus de chose à l'écran dans des délais plus court.

Donc une puissance brute bien plus élevée que sur la ps3.
 

C'est bien beau mais ça ne nous aide en rien. En tout cas pas pour une émulation 1:1, le surplus de puissance pourrait être utile pour forcer des résolutions plus importantes que la résolution native de la ps3 mais c'est tout.
Et pour ça il faut d'abord pouvoir émuler le jeu de manière correcte en 1:1.

 

En effet, les gpu reposent pratiquement tous sur le même principe, ainsi il est relativement facile d'adapter le rendering d'image au gpu de la ps4. Relativement car il faut quand même coder ce qui servira d'interface, régler les paramètres etc. mais dans l'absolu, ce n'est pas le plus compliqué.

Le plus compliqué c'est de 'traduire' le code de la ps3 vers la ps4, le tout dans des délais suffisamment court et ça, seul le cpu peut le faire avec les contraintes que l'on a vu plus haut.

Donc une fois de plus, la super puissance de la ps4, qui réside pour beaucoup dans le gpu n'est pas exploitable. :/ 

C'est quand même honteux qu'il n'y ai pas de vrai rétro compatibilité sur PS4...

Le truc c'est que c'est pas une volonté de Sony de ne pas proposer de rétro-compatibilité mais une incompatibilité matérielle.

La ps3 utilisait une architecture propriétaire développée juste pour la ps3.
C'est d'ailleurs pour ça que les ps3 hormis la fat ne proposait pas de rétrocompatibilité directe avec la ps2, l'executable est différent.

Pour simplifier, le processeur de la ps3, ne parle pas le même language que la ps2, et celui de la ps4 ne parle le même language que la ps3.

Du coup pour faire une rétrocompatibilité, tu as 2 solutions:
- Inclure un processeur compatible
- Utiliser un interpréteur 

La première avait était tenté sur la toute première génération de ps3 pour rétrocompatibilité ps2, mais vite abandonné à cause du surcoût, les consommateurs préférant payer 200€ de moins pour avoir juste les jeux current gen (+ de 90% du moins).
Surtout si on trouve encore la précédente console à très bon prix via les occasions.

La seconde pose plusieurs problèmes dont un majeur: la vitesse.
En effet, un interpréteur est une émulation logicielle et donc extrêmement lente (en comparant la solution hardware versus logicielle).
Il te faut beaucoup plus de puissance avec un interpréteur car il faut compenser le temps perdu par la traduction en augmentant la vitesse de calcul du cpu.
A cela s'ajoute des approximations du fait qu'il n'est pas certain que ton architecture actuelle te propose les mêmes options que l'architecture cible, ou que celles-ci opèrent de la même manière.

Du coup la encore, tu vas perdre du temps à assurer que le résultat d'une opération soit le même que sur l'architecture cible.

En bref, l'émulation c'est bien plus compliqué qu'il n'y parait, et plus la cible de l'émulation est puissante et plus c'est compliqué. (Car oui, un interpréteur est un émulateur.)

Alors tu vas me dire que des émulateurs existent en homebrew et que c'est vache de la part de Sony de pas en créer un.
Oui, sauf qu'on oublie plusieurs points majeurs:
- Un homebrew qui marche pas ou mal, c'est embêtant mais c'est "attendu", on va pas embêter le dev pour un fix
- Une application officielle qui ne fonctionne pas et c'est l'image de Sony qui en prend un coup, avec le support client submergé de mécontent (légitime)

Du coup, pour les grandes entreprises, c'est plus intéressant de ne pas proposer une fonctionnalité que de proposer un truc expérimental qui fonctionnera peut-être mais dont on n'est pas sur.
Sony peut pas dire à ses clients: testez et si ça marche tant mieux, sinon tant pis.

Mais si on regarde bien, Sony propose des émulateurs, ils s'assurent juste de proposer ceux qui fonctionnent correctement.
Comme les jeux ps1 classic, psp classic, ps2 classic.

Ils reposent tous sur un émulateur mais ne sont disponible que si on est sur qu'ils fonctionnent à 100% une fois émulé.
D'où le catalogue réduit par rapport au catalogue original de ces consoles.

Après, je suis d'accord sur le fait que la rétrocompatibilité est une chose importante et sony l'a compris aussi.
D'ou le fait qu'ils utilisent à présent une architecture similaire à celle d'un pc sur la ps4. C'est sur d'être quelque-chose de maintenable dans le temps.

Le fait que Microsoft propose une bonne rétrocompatibilité sur ses consoles et basé sur le choix d'une architecture commune, simplement plus évolué avec une plus grande puissance et plus de fonctionnalités.
Du coup la rétrocompatibilité peut être faite avec moins de travail (il suffit de donner à l'application les paramètres qu'elle attend et d'interfacer le tout avec le système).

Voilà pour la raison derrière la non-rétro compatibilité, chapeau si vous avez tout lu.
Je tiens à préciser au cas ou ce serait mal interprété que ce post n'est pas là pour défendre Sony et la non retro-compatibilité, mais seulement pour expliquer l'envers du décor et essayer d'apporter des informations pertinentes au problème.

Je suis moi-même déçu de ne pas pouvoir jouer à mes Battlefield Bad Company 1 & 2 sur ps4, pas même via ps now. (Hagard avec ses camionausores et le gars en kiffe sur l'opératrice !!!   )

@jbam: et bien si figure toi.

En effet, l'overclock utilise les fonctions disponible par le système de la Switch elle-même. Ce n'est pas un hack qui le permet. (Check switchbrew PCV service pour en savoir plus)
Il s'agit en fait du même concept que sur N3DS ou le système peut fonctionner soit en 268MHz ou en 804MHz.

Certaines applications et jeux utilisent le mode qui leur permettent de mieux fonctionner, en essayant au maximum d'être utilisable dans le mode normal pour éviter de flinguer l'autonomie de la console.

Le terme overclock n'est pas adapté ou mal compris dans cette situation.

Hmm, l'overclocking utilisé ici est absolument sans danger pour la console.
Il faut savoir que les CortexA57 sont prévu pour être utilisés à ~1900MHz et les CortexA53 à ~1300MHz.

Il est tout à fait possible de limiter logiciellement la fréquence pour diverses raisons (telle que l'économie d'énergie pour plus d'autonomie), et c'est ce qui est fait par le système de la switch.

Ainsi, tout comme on peut la downclocker, on peut aussi l'utiliser avec les fréquences officiellement supportées par le matériel.

Ici l'overclock en question s'agit donc simplement de retirer une limite logicielle du système, et non pas d'overclocker le matériel à des fréquences plus élevées que celles officiellement supportées par le matériel.

C'est donc une opération sans risque et dont le seul inconvénient se répercutera sur l'autonomie de la console quand 'l'overclock' sera actif.

Effectivement, la chaleur pourra aussi être augmentée, mais rien de dramatique, on parle de quelque dégrés ce qui ne représente rien.

J'ajouterai que dans le pire des cas, tout cpu intègre des sondes afin de controller la température et s'assurer qu'elle soit dans les paramètres acceptable, ainsi il n'y a aucun risque d’abîmer le matériel.

Vous êtes carrément à l'ouest et l'article est mal tourné, son départ n'a rien a voir avec le leak.
Le leak à simplement permit de release tout ce qu'il avait de coté, et ceci fait il a achevé son travail et ne compte pas en faire d'autre (a part peut être pour le GPU).

Sinon, concernant le développement privé, vous n'y êtes pas du tout.
Le fait qu'ils aient tout gardé privé jusqu'à aujourd'hui à plusieurs raisons :

• Le contrôle des failles:
  • Ceux travaillant sur la scène Nintendo aiment avoir des hacks qui puissent supporter l'intégralités des firmwares et si possible les nouveaux aussi.
    Publier une faille, c'est permettre à Nintendo de la boucher avant qu'ils aient pu en tirer l'intégralité des infos / tests nécessaires
    On peut penser qu'ils en profite pendant des mois solo, mais en fait c'est juste que c'est très long comme travail le hack. C'est un peu comme devoir construire une mine dans le noir, et y aller tous les jours pour en récupérer les minerais à l'aveugle aussi. Parfois vous tombez bien, souvent vous choperez seulement des cailloux.
• Certains accords:
  • Vous ne vous en rendez peut-être pas compte, mais avoir des failles dans un système c'est assez dangereux de manière générale. Par conséquent et depuis toujours, les hackers (non console) ont toujours averti les companies de failles qu'ils auraient découvertes avant de les publier. Généralement et en fonction de la gravité de la faille, le délai et de 1-6mois avant que la faille ne soit publiée, pour laisser à l'entreprise le temps de la boucher.
    C'est ce qu'il s'est passé ici avec le Tegra. La faille dans le bootrom ne touche pas que la switch mais d'autres appareils et la faille à été transmise afin qu'elle soit fixée si possible par NVidia.
    Durant ce temps, la faille devait être conservée privée pour éviter des attaques sur des périphériques tiers.
•  La sécurité de la faille:
  • Un code à la va vite pour tester par son dev, n'est pas sécurisé. Le dev sait exactement ce qu'il doit faire et ne va pas bricker sa console.
    Un néophyte utilisant l'exploit sans même savoir ce que le code fait, peut bricker sa console.
    Combien on pari que l'utilisateur ayant brické sa console râlera contre le développeur ?
• Le fait qu'il n'y ait rien à proposer avec:
  • Aujourd'hui vous avez les failles/exploits, et alors ? Qu'est-ce que ça a changé pour vous ? Vous ne pouvez toujours rien faire avec.
    En tant que dev, c'est toujours plus valorisant de fournir avec un travail, de quoi l'exploiter, comme un homebrew, un cfw. N'importe quoi qui vous permette de l'utiliser.

Bref, y'a pas de complot ou autre ici, seulement une bande de passionnés faisant des recherches dans le but de s'améliorer et d'en apprendre toujours un peu plus, et si ça débouche sur l'ouverture d'un système avec un accès au développement facilité c'est bonus.

Ceux qui parlent d'égo devrait réfléchir 2 minutes, certe avoir le support des gens fait plaisir et motive le dev à continuer son travail mais c'est tout.
On parle quand même de plusieurs centaines d'heures de travail non rémunérées (pendant des mois), souvent prises sur les heures de sommeil car ils ont aussi une vrai vie et de vrai factures à payer, et à ce stade l'amour virtuel que twitter te donne n'est pas une raison suffisante pour continuer. Seule la passion l'est.

J'ajouterai aussi que parfois afin de complètement hacker un système les devs déboursent des sous de leur poches sans rien demander à personne et que ce ne sont pas toujours des petites sommes (plusieurs milliers de dollars pour le cloud qui a permis de bruteforcer les clés bootrom de la 3DS par example).
Où est l'égo ici ?

Certains confondent la fierté qu'on peut avoir pour son travail/oeuvre et un égo mal-placé qui souhaite absolument être sous les acclamations.

Bref, un petit pavé mais qui j'espère, permettra à certain de se rendre compte que le hacking n'est pas aussi facile que tout le monde pense. Et qu'il y a pas mal d'à coté.

Tu as juste Luma dans la 3DS. Mais sinon il te faut le boot.firm, godmode9 & Decrypt9 + le ctrtransfert sur la carte SD.

Okay, arrête de poser 100 questions dont les réponses peuvent être facilement trouvable soit par une recherche soit simplement en lisant un minimum le site que je t'ai linké.

Luma3DS est un cfw, tout comme CakesFW est un cfw. Peu importe le cfw tu auras aujourd'hui besoin de B9S pour lancer un cfw sur 3DS quelqu'il soit.

Je te redirige maintenant sur le lien posté plus haut, et si tu souhaites plus d'infos (ou quelqu'un qui te tienne par la main), fait un nouveau sujet section 3DS sur le forum afin de laisser cette news propre.

On ne peut que lui dire merci pour tout son travail car il a apporté pas mal à la communauté dès la création de son cfw (qui était le second sur N3DS après Reinand si ma mémoire est bonne), avec notamment cakebrah etc.

Bref, très bon taff de sa part qui à permis de faire évoluer la scène, aujourd'hui de nouvelles alternatives apportées par d'autres qui sont toujours impliqués sur la 3DS sont certes là mais on peut dire merci car c'est le genre de boulot qui prend énormément de temps (plusieurs mois), bien plus que de simplement le télécharger et l'installer.

Je terminerai en disant que c'est vraiment sympa de sa part de proposer une version qui fonctionne avec les dernières nouveautés en terme de point d'entrée (B9S) avant de partir alors qu'il aurait pu juste laisser le projet en l'état.
Même si ce ne sera certes pas utilisé par la majorité, ceux qui souhaiteraient continuer avec celui-ci pourront toujours le faire.

C'est ce qu'il dit, rien ne prouve que ses fichiers sont effacés sont être backup avant !

Donc logiciel à bannir sur tout bon site qui ce respecte !

Hmm, si, le code du serveur (qui tourne sur un Pi hein, c'est pas une ferme de serveur le truc).

Après les gens qui utilisent cette application sont bannis, donc il n'y a aucune utilité à récuperer des LocalFriendCodes bannis.

Quand aux autres fichiers, ils n'ont aucune utilité sans la console même.

M'enfin chacun est libre de penser ce qu'il veut, de l'utiliser ou pas, je relate simplement les faits.
Cette application ne vole rien, la communication a été mal faite par l'équipe et ils y a eu des assomptions de faites.

Après, il n'y a pas de miracle, les techniques anti ban sont connues et limitées dans le temps, cette application ne fait qu'automatiser le processus, ni plus ni moins.

​Et puis, on parle d'une console de jeu, le mieux qu'il y ait a volé sont les sauvegardes de jeu.
C'est pas un téléphone avec des codes bancaires, des réseaux sociaux et toute la vie privée du mec.
Le mieux qu'on pourrait avoir c'est deviner un peu le proprio si le mii est ressemblant. x)
Tout ce que je dit, c'est que oui il faut faire gaffe aux infos envoyées, applications etc, mais il faut parfois relativiser et considérer l'ampleur du truc.
 

Pas la peine de s'affoler avec ça, les fichiers récupérés ne l'ont été que pour implémenter un système de sécurité et empêcher un brick des utilisateurs.
A savoir aussi que ces fichiers ne sont pas conservés sur le serveur.

Même si le procédé est douteux, il n'y a rien de dangereux ni de malicieux.

Bref, c'est une histoire qui à fait beaucoup de bruit pour pas grand chose... Comme d'habitude.

 

Je crois d'ailleurs que le code source est désormais accessible, ou tout du moins tous les "grands" de la scène l'ont reçu et ont pu confirmer les dires du dev de l'app.

@evilmanes: voilà un tutoriel 

Voici un guide qui explique certaines fonctionnalités de CTRPF: Guide

Certaines choses peuvent être légèrement différentes puisque le guide à été écrit sur une ancienne version de CTRPF.
Le guide sera bientôt mis à jour.