sdk

Play is hard Wrote:À trop se spécialiser, on meurt. Un grand nombre d'indés ont choisi l'option de la facilité en misant tout sur Unity (qui reste côté en bourse je le rappelle), et aujourd'hui ils font les surpris quand l'entreprise se réveille pour réclamer sa part du gâteau. Ce n'est pas moi qui vais les plaindre.

@adapted

Oui, Epic prend son pourcentage sur l'utilisation de Unreal Engine. De mémoire c'est 5% des revenus à partir du million généré sur les jeux utilisant leur moteur. Ça a peut-être évolué depuis de le temps, et notamment avec Unreal Engine 5 cependant.

Vous ne connaissez rien au monde du développement de jeu vidéo, rassurez moi ? Cet élitisme des "moteurs maisons" n'a rien à voir avec la situation actuelle. Si les développeurs utilisent majoritairement Unity, c'est qu'il y a une raison ! Le portage sur consoles, les SDK VR etc. L'option de facilité ? C'est honteux de lire des choses pareils. Les développeurs sont fainéants et c'est de leur faute, c'est ça qu'il faut retenir de votre message ?

La grande majorité des jeux sont développés sur Unity, la société Unity récupère déjà de l'argent.

Le développeur SpecterDev propose la v1.0.2 de PS5-IPV6-Kernel-Exploit. Au menu:

• Ajout de la prise en charge des firmwares 3.00, 3.20, 3.21, 4.02 et 4.51 (3.10 et 4.00 sont partiellement pris en charge)


• Maintenant, nettoie les fds après l'exploitation afin que les processus n'héritent pas inutilement d'un tas de ressources


• Correction de divers bogues dans le loader ELF où des lectures incomplètes pouvaient se produire


• Ajout de certains arguments de point d'entrée au loader ELF pour la lecture/écriture du noyau

Lien: https://github.com/Cryptogenic/PS5-4.03 ... /tag/v1.02

Il ne s’arrête pas là puisqu’il propose aussi un SDK PS5. Pour le moment, c’est un WIP !

Lien: https://github.com/PS5Dev/PS5SDK

Le développeur opa334 propose TrollInstaller2 pour les versions d'iOS et d'iPadOS de 14.0 à 15.4.1 (ou 15.5 bêtas 1 à 4). Pour le moment, il ne fonctionne que sur les appareils équipés de puce A12-A15 (arm64e).

Le processus d'installation nécessite soit un Mac, et l'utilisateur doit avoir accès à THEOS et au SDK iOS 14.5, soit un lien pour installer TrollStore via OTA sur tous les appareils arm64e pris en charge (14.0-15.5b4). Deux méthodes: une avec un IPA pré compilé et une pour compiler l’IPA.

Lien: https://github.com/opa334/TrollStore/

Cela s’ajoute à ce qui existait déjà et nécessite une actualisation de la démarche plus haut. Ceci est en cours…

Ne pas confondre. Le SDK utilisé des anciens jeux et celui pour les nouveaux et les prochains à venir.

Le kit de développement logiciel (SDK) est un ensemble d’outils de développement. Les jeux récents dits nouveaux seront construits avec le dernier SDK. Pour les anciens jeux, cela ne rentre pas dans la donne.

Pour ce qui concerne les updates des jeux, ce sera différent également et cela se basera sur la même condition. Mais beaucoup de mises à jour de jeu qui demandent le dernier firmware n’ont pas non plus le même SDK. Et cette condition de mise à jour est opérée par Nintendo. Donc, le patch sera opérationnel pour des jeux construits avec l’ancien SDK.

Je ne sais pas si l’outil NSC_Builder pourra y faire grand chose à ce niveau car lui s’occupe de patcher le firmware en fonction de la base sur laquelle il est construit.

En principe, si le jeu de base ne nécessite pas le dernier firmware (dernier SDK) alors ce dernier avec ses mises à jour et DLCs peuvent être patchés pour être exécutés sur un firmware inférieur (si on a les clés pour chiffrer/déchiffrer le contenu) car le SDK requis ne change pas normalement.

Et je résume grossièrement car c’est plus complexe que cela et mes connaissances ne sont pas aussi précises. Ce kit, dans son évolution, sera utilisé pour des nouveaux jeux. Et ce ne sera pas sa seule mise à jour ^^

On a de la visibilité là dessus ? S'il y a eu modification du sdk cet été, ça pourrait expliquer que les "gros jeux" dont le développement a débuté avant cette evolution fonctionnent sans problème tandis que certains "petits jeux", dans doute adaptés en quelques jours, plantent désormais ?

Cela changera lorsque le sdk évoluera et que les jeux le demanderont.

En réponse à la question 1, aucun problème avec les boot0/1 sur les modèles non patchés. Cela concerne plutôt les modèles Mariko. Et comme tu l’indiques, tu as fait la mise à jour et tu n’as pas de problème. Lorsqu’il y a corruption des boot, c’est qu’il y a eu mauvaise manipulation derrière. D’ailleurs le mode autoRCM fonctionne comme une corruption du boot pour résumer grossièrement.

Pour la question 2, j’ai déjà répondu trop souvent à cette question. Il y a beaucoup de sujets sur le forum Switch pour trouver des éléments de réponses. Le port cartouche se met à jour en 12.x.x mais pas seulement puisque c’est 4 eFuses LOTUS qui sont grillés depuis (4.0.0/9.0.0/11.0.0/12.0.0). Et il n’existe aucun moyen de contourner cela avec SX OS. Seul Hekate, avec son patch NoGC le permet. Donc oui, laisser la sysNAND dans une version inférieure et ne mettre qu’à jour l’emuNAND n'empêchera pas de mettre à jour le port cartouche via SX OS. D’ailleurs, je ne vois pas l’interêt de faire cela sur des modèles non patchés si on utilise Atmosphère/Hekate et pour SX OS, le tout, c’est de laisser HOS en 11.0.0 max.

Actuellement et tant que le SDK n’évoluera pas, les jeux pourront être patchés pour être utilisés avec SX OS s’ils demandent une mise à jour firmware. Cela se fait avec NSC_Builder.
https://gamergen.com/forums/underground ... 39808.html

Maintenant, si le but est de passer sous Atmosphère/Hekate, il faut rendre compatible l’emuNAND en procédant à une opération de migration. Il n’y a pas de tutoriel sur le forum car les possibilités sont nombreuses. Voir du côté de GBATemps ou autre pour une démarche détaillée.
D’autres ont recommencé à zéro mais cela implique de faire un dump de ses sauvegardes avant et de conserver les données de sa SD sur PC pour ne pas tout perdre. A chacun de voir.

Ce choix t’appartient.

Le hack SX OS n’est plus suivi et il reste opérationnel pour HOS 11.0.0 max. pour le moment, la compatibilité des jeux restent opérationnels. Ce ne sera plus le cas lorsque le SDK évoluera.

Le hack via Atmosphère/Hekate est suivi et sera toujours opérationnel car il reste dans les aspects légaux pour cela.

Et comme dit plus haut, il restera des contraintes en fonction de ce que l’on souhaite via SX OS.

Comme indiqué plus haut, la mise à jour du jeu opérée ne sera effective que sur la NAND où tu l’installes, là pour toi, c’est la sysNAND. Si tu voulais que ce soit l’emuNAND, il aurait fallut l’installer sur cette dernière. Mais comme SX OS n’est pas compatible 12.0.2, le CFW ne fonctionnera plus. D’où le fait d’essayer de faire un superXCi via NSC_Builder qui englobe le jeu et la mise à jour et éventuellement des DLC. Et à l’issu, vérifier si une mise à jour est toujours demandée. SysNAND et emuNAND sont déliées. L’emuNAND est ta NAND système émulée sur ta SD.

C’est le problème qui va devenir fréquent avec SX OS par la suite car beaucoup de jeux vont avoir des mises à jour qui demanderont un firmware récent. Et le patch, pour beaucoup, sera impossible car le SDK va changer également. Si tu veux absolument cette mise à jour, soit tu testes avec un superXCi, soit tu utilises Atmosphère/Hekate.