UnityNativeScripting
1.0.0
Une bibliothèque pour permettre l'écriture de scripts d'unité dans le code natif: C, C ++, assemblage.
Ce projet vise à vous donner une alternative viable à C #. Les scripts en C ++ ne sont pas bons pour toutes les parties de chaque projet, mais c'est maintenant une option.
Changer une ligne de code C # vous oblige à faire une nouvelle construction du jeu. Les temps de construction Android typiques ont tendance à durer au moins 10 minutes car l'IL2CPP doit fonctionner, puis une énorme quantité de C ++ doit être compilée.
En utilisant C ++, nous pouvons compiler le jeu en tant que plugin C ++ en environ 1 seconde, échanger le plugin dans l'APK, puis installer et exécuter immédiatement le jeu. C'est un énorme coup de pouce de la productivité!
C ++ compile beaucoup plus rapidement que C #. Des versions incrémentielles lorsque un seul fichier change - les constructions les plus courantes - peuvent être 15x plus rapides qu'avec C #. Une compilation plus rapide s'ajoute au fil du temps aux gains de productivité. Les temps d'itération plus rapides facilitent le fait de rester dans le "flux" de la programmation.
Le collecteur des ordures d'Unity est obligatoire et a beaucoup de problèmes. Il est lent, fonctionne sur le fil principal, recueille toutes les ordures à la fois, fragmente le tas et ne rétrécit jamais le tas. Ainsi, votre jeu connaîtra des "atteintes à cadre" et finalement vous manquerez de mémoire et de vous écraser.
Une quantité importante d'efforts est nécessaire pour contourner le GC et le code résultant est difficile à maintenir et à ralentir. Cela comprend des techniques comme les pools d'objets, qui font essentiellement du manuel de gestion de la mémoire. Vous devez également éviter les types de valeurs de boxe comme int pour gérer des types comme object , ne pas utiliser foreach Loops dans certaines situations et divers autres gotchas.
C ++ n'a pas de collecteur de déchets et de fonctions requis et des fonctions de gestion de mémoire automatique en option via des types de "pointeur intelligent" comme Shared_ptr. Il offre d'excellentes alternatives au collecteur de déchets primitif d'Unity.
Bien que l'utilisation de certaines API .NET impliquera toujours la création de déchets, le problème est contenu uniquement à ces API plutôt que d'être un problème omniprésent pour tout votre code.
En utilisant C ++ directement, vous obtenez un contrôle complet sur le code que le CPU exécutera. Il est beaucoup plus facile de générer du code optimal avec un compilateur C ++ qu'avec un compilateur C #, IL2CPP et enfin un compilateur C ++. Découpez l'homme du milieu et vous pouvez profiter de l'intrinssique ou de l'assemblage du compilateur pour écrire directement du code machine en utilisant des fonctionnalités puissantes CPU telles que le cryptage SIMD et matériel AES pour des gains de performances massifs.
C ++ est une langue beaucoup plus grande que C # et certains développeurs préféreront avoir plus d'outils à leur disposition. Voici quelques différences:
Alors qu'IL2CPP se transforme déjà C # en C ++, il génère beaucoup de frais généraux. Il y a beaucoup de surprises si vous lisez le C ++ généré. Par exemple, il y a des frais généraux pour toute fonction utilisant une variable statique et deux pointeurs supplémentaires sont stockés au début de chaque classe. Il en va de même pour toutes sortes de fonctionnalités telles que sizeof() , des contrôles nuls obligatoires, etc. Au lieu de cela, vous pouvez écrire C ++ directement et ne pas avoir besoin de contourner IL2CPP.
C ++ est le langage standard des jeux vidéo ainsi que de nombreux autres domaines. En programmation en C ++, vous pouvez plus facilement transférer vos compétences et votre code vers et depuis des projets non uniques. Par exemple, vous pouvez éviter le verrouillage en utilisant la même langue (C ++) que vous utiliseriez dans les moteurs Unreal ou Lumberyard.
GameObject go;
Transform transform = go.GetTransform();
Vector3 position(1.0f, 2.0f, 3.0f);
transform.SetPosition(position);
MonoBehaviour en C ++ void MyScript::Start()
{
String message("MyScript has started");
Debug::Log(message);
}
#if TARGET_OS_ANDROID )Le cœur de ce projet est un générateur de code. Il génère le code C # et C ++ appelé "liaisons" qui mettent C # API disponible pour le code de jeu C ++. Il prend en charge un large éventail de fonctionnalités linguistiques:
classstructenumAction )decimalget et set comme obj.x )get et set comme obj[x] )add et remove les délégués)int à object et visa versa)out et refNotez que le générateur de code ne prend pas encore en charge:
Array , string et object (par exemple GetHashCode )params implicites (aka "var args") Pour configurer le générateur de code, ouvrez Unity/Assets/NativeScriptTypes.json et remarquez les exemples existants. Ajoutez à ce fichier pour exposer plus d'API C # à partir de DLL Unity, .NET ou personnalisés à votre code C ++.
Pour exécuter le générateur de code, choisissez NativeScript > Generate Bindings à partir de l'éditeur Unity.
Presque tous les projets verront une victoire en performance nette en réduisant la collecte des ordures, en éliminant les frais généraux IL2CPP et en accédant à l'intrinssique et à l'assemblage du compilateur. Les appels de C ++ en C # ne subissent qu'une pénalité de performance mineure. Dans le cas rare que presque tous vos code sont des appels vers .NET API, vous pouvez subir une perte de performances nette.
Article de tests et de références
Article d'optimisations
Lorsque le script en C ++, C # est utilisé uniquement comme une couche "de liaison" afin que l'unité puisse appeler les fonctions C ++ et les fonctions C ++ peuvent appeler l'API Unity. Un générateur de code est utilisé pour générer la plupart de ces liaisons en fonction des besoins de votre projet.
Tout votre code, plus quelques liaisons, existera dans un seul plugin C ++ "natif". Lorsque vous modifiez votre code C ++, vous construirez ce plugin, puis jouez au jeu dans l'éditeur ou dans une version déployée (par exemple sur un appareil Android). Il n'y aura pas de code C # pour l'unité à compiler à moins d'exécuter le générateur de code, ce qui est rare.
Le flux de travail C # standard ressemble à ceci:
Avec C ++, le flux de travail ressemble à ceci:
Unity/Assets dans le répertoire Assets de votre projet UnityNativeScriptTypes.json et spécifiez les parties des API Unity, .NET et DLL personnalisées auxquelles vous souhaitez accéder à partir de C ++.Unity/Assets/CppSource/Game/Game.cpp et Unity/Assets/CppSource/Game/Game.h pour créer votre jeu. Un exemple de code est fourni, mais n'hésitez pas à le supprimer. Vous pouvez ajouter plus de fichiers C ++ Source ( .cpp ) et en-tête ( .h ) à mesure que votre jeu se développe./Applications/Utilitiescd /path/to/your/build/directorycmake -G MyGenerator -DCMAKE_TOOLCHAIN_FILE=/path/to/your/project/CppSource/iOS.cmake /path/to/your/project/CppSource . Remplacez MyGenerator par le générateur de votre choix. Pour voir les options, exécutez cmake --help et regardez la liste en bas. Les choix courants incluent "Unix MakeFiles" à construire à partir de la ligne de commande ou "Xcode" pour utiliser l'IDE d'Apple.make Si vous choisissez Unix Makefiles en tant que générateur ou ouvrez NativeScript.xcodeproj et cliquez sur Product > Build si vous choisissez Xcode. /Applications/Utilitiescd /path/to/your/build/directorycmake -G "MyGenerator" -DEDITOR=TRUE /path/to/your/project/CppSource . Remplacez MyGenerator par le générateur de votre choix. Pour voir les options, exécutez cmake --help et regardez la liste en bas. Les choix courants incluent "Unix MakeFiles" à construire à partir de la ligne de commande ou "Xcode" pour utiliser l'IDE d'Apple. Retirer -DEDITOR=TRUE pour les constructions autonomes.make Si vous choisissez Unix Makefiles en tant que générateur ou ouvrez NativeScript.xcodeproj et cliquez sur Product > Build si vous choisissez Xcode. cd /path/to/your/build/directorycmake -G "Visual Studio VERSION YEAR Win64" -DEDITOR=TRUE /path/to/your/project/CppSource . Remplacez VERSION et YEAR par la version de Visual Studio que vous souhaitez utiliser. Pour voir les options, exécutez cmake --help et regardez la liste en bas. Par exemple, utilisez "Visual Studio 15 2017 Win64" pour Visual Studio 2017. Toute version, y compris la communauté, fonctionne très bien. Retirer -DEDITOR=TRUE pour les constructions autonomes. Si vous utilisez Visual Studio 2019, exécutez cmake -G "Visual Studio 16" -A "x64" -DEDITOR=TRUE /path/to/your/project/CppSource à la place.NativeScript.sln et cliquez sur Build > Build Solution . cd /path/to/your/build/directorycmake -G "MyGenerator" -DEDITOR=TRUE /path/to/your/project/CppSource . Remplacez MyGenerator par le générateur de votre choix. Pour voir les options, exécutez cmake --help et regardez la liste en bas. Le choix le plus courant est "Unix MakeFiles" à construire à partir de la ligne de commande, mais il existe également des options IDE. Retirer -DEDITOR=TRUE pour les constructions autonomes.make si vous choisissez Unix Makefiles comme générateur. cd /path/to/your/build/directorycmake -G MyGenerator -DANDROID_NDK=/path/to/android/ndk /path/to/your/project/CppSource . Remplacez MyGenerator par le générateur de votre choix. Pour voir les options, exécutez cmake --help et regardez la liste en bas. Pour créer une version pour toute plate-forme autre que Android, omettez la partie -DANDROID_NDK=/path/to/android/ndk .make si vous choisissez Unix Makefiles comme générateur. Pour mettre à jour une nouvelle version de ce projet, écrasez le répertoire Assets/NativeScript de votre projet Unity avec le répertoire Unity/Assets/NativeScript de ce projet et réinstaller le générateur de code.
Articles de l'auteur décrivant le développement de ce projet.
Jackson Dunstan
N'hésitez pas à se nourrir et à envoyer des demandes de traction ou simplement soumettre un problème pour les fonctionnalités ou les corrections de bogues.
Tout le code est un MIT sous licence, ce qui signifie qu'il peut généralement être facilement utilisé dans les applications commerciales et non commerciales.
Toute l'écriture est licenciée CC par 4.0, ce qui signifie qu'elle peut être utilisée tant que l'attribution est donnée.
