Mots-clé : c

Unity

Unity aide-mémoire

Fichiers
Chemin de base Application.persistentDataPath
Encrypter les données.
Trouvé ici. 		...

GameObjects dans l’éditeur : mémo
Faire une liste déroulante avec des items sur mesure.
Trouvé ici. 		public enum IngredientUnit {
    Spoon, Cup, Bowl, Piece
}
// Custom serializable class
[Serializable]
public class Ingredient
{
    public string name;
    public int amount = 1;
    public IngredientUnit unit;
}

Puis, dans n’importe quelle page, on peut ajouter une property de type Ingredient, et même un tableau d’Ingredient ainsi :

    public Ingredient potionResult;
    public Ingredient[] potionIngredients;

GameObjects : mémo
Taille Mesh Mesh m = obj.GetComponent<MeshFilter>().sharedMesh;
Debug.Log(m.bounds.size);
Taille Sprites var m = transform.GetComponent<Renderer>();
Debug.Log(m.bounds.size);

Assets et Objets
Pour comprendre comment gérer correctement les données dans Unity, il faut impérativement comprendre comment Unity identifie et sérialise les données.
Le premier point-clé est de faire la distinction entre les Assets et UnityEngine.Objects.

Un Asset est un fichier sur le disque, stocké dans le dossier Assets d’un projet Unity. Les textures, modèles 3D, ou encore clips audio sont des types d’Assets très courants. Quelques Assets contiennent des données au format natif de Unity, tels que les materiaux. D’autres Assets doivent être convertis en format natif, comme par exemple les fichiers FBX.

UnityEngine.Object, ou bien Object avec un ‘O‘majuscule, est un ensemble de données sérialisées qui décrivent une instance spécifique d’une ressource. Cela peut être n’importe quelle ressource utilisée par le Unity Engine, telle qu’un mesh, sprite, AudioClip ou AnimationClip. Tous les objets sont des sous-classes de la classe de base UnityEngine.Object.

Alors que la plupart des types Object sont built-in (= natifs), il y a deux types spéciaux.

  1. Un ScriptableObject fournit un système pratique pour les développeurs qui désirent définir leurs propre types de données. Ces types peuvent être nativement sérialisés et dé-sérialisés par Unity, et manipulés dans la fenêtre « inspecteur » de l’éditeur de Unity
  2. Un MonoBehaviour fournit un wrapper qui est lié à un MonoScript. Un MonoScript est un type de données interne que Unity utilise pour garder une référence à une class spécifique de script à l’intérieur d’un namespace et assembly spécifique. Un MonoScript ne contient pas réellement de code exécutable.

Il y a une relation one-to-many entre Asset et Object. Dit autrement, un fichier Asset peut contenir un ou plusieurs Object.

– Créer l’URL de logout :
url(r'^logout/$', LogoutView.as_view(), name='logout'),

– Créer la vue LogoutView
from django.contrib.auth import views

class LogoutView(views.LogoutView):

    def __init__(self):
        self.next_page = '/'

<form action="{% url 'login' %}" method="post" accept-charset="utf-8">
    {% csrf_token %}
    {% for field in form %}
        <label>{{ field.label }}</label>
        {% if field.errors %}
            {{ field.errors }}
        {% endif %}
        {{ field }}
    {% endfor %}
    <input type="hidden" name="next" value="{{ next }}" />
    <input class="button small" type="submit" value="Submit"/>
</form>

Références entre Object‘s
Tous les UnityEngine.Objects peuvent avoir des références vers d’autres UnityEngine.Objects. Ces derniers peuvent résider dans le même fichier Asset, ou peuvent être importé à partir d’autres fichiers Asset. Par exemple, un Object matériau a habituellement une ou plusieurs références vers des Object texture. Ces Object texture sont généralement importés à partir d’un ou plusieurs autres fichiers Asset (tels que des PNG‘s ou JPG‘s).
Lorsqu’elles sont sérialisées, ces références sont constituées en deux blocs de données : un File GUID et un Local ID.
Le File GUID identifie le fichier Asset. Un Local ID identifie chaque objet à l’intérieur d’un fichier Asset, car un fichier Asset peut contenir plusieurs objets.
L’identification et le système de référence peut être visualisé dans un éditeur de texte : créez un nouveau projet Unity et changez Editor Settings en cochant Visible Meta Files et Serialiaze Assets as text. Créez un nouveau matérieau, puis importez une texture dans le projet. Assignez le matériau à un cube dans la scène et sauvez cette dernière.
Avec un éditeur de texte, ouvrez le fichier .meta associé au matériau. Une ligne guid sera présente parmi les première lignes. Cette ligne définit le GUID du matériau. Pour trouver l’id local, ouvrez le fichier matériau dans un éditeur de texte. La première ligne qui ressemble à ‘--- !u! &2100000‘ correspond à l’id local.

Pourquoi des « File GUIDs » et des Local ID‘s ?
Pourquoi le principe des « File GUIDs » et des Local ID‘s est-il important  ? La réponse est : dans la stabilité et la possibilité d’avoir un workflow indépendant de la plateforme.

Comment faire un affichage 100% proportionnel quelle que soit la résolution de l’écran ?
En fait, d’après ce que j’ai compris, il faut comprendre qu’on ne « devrait » pas toucher à la taille de la fenêtre de l’application : c’est l’utilisateur qui la fixe : téléphone mobile, portrait ou paysage, ou écran 4k voire 8k, l’application doit s’adapter et devrait même être redimensionnable.
L’idée que j’ai retirée de mon expérience, qui est peut-être un peu différente de la réalité « Unity », est la suivante :

  • Il faut créer un Canvas et lui dire de rester proportionnel à l’écran. Comme cela, même sur les écrans géants, il s’adaptera ;
  • Dans ce Canvas, il faut créer un « référent » qui servira de conteneur à tout le reste. Ce conteneur, il faut lui dire de « remplir » son parent (donc de remplir le Canvas) selon une échelle à

Pourquoi ne pas faire ces deux opérations dans le Canvas ? (1) dire de rester proportionnel + (2) dire de « remplir » le parent Parce que le Canvas connaît et gère le composant Canvas Scaler, et le « référent » (qui sera un Pourquoi ne pas faire ces deux opérations dans le Canvas ? Parce que le Canvas connaît et gère le composant Canvas Scaler et que le « référent », ou « conteneur », connaît et gère le composant Aspect Ratio Fitter)

vim : exemple concret de conversion de fichier C en fichier Pascal

Voici un aperçu des petites choses possibles avec les macros vim.
J’avais un énorme fichier include (fichier fmod.h) à convertir en Pascal, afin de pouvoir accéder à l’extraordinaire librairie de fmod. Pour information, cette librairie est gratuite et redistribuable en tant que telle si votre produit est gratuit et ne vous rapporte rien. Donc profitez en c’est une librairie aussi simple d’utilisation que puissante et stable.

Je vous explique juste le principe de base, avec un exemple concret, et vous verrez qu’il vous suffit de faire pareil pour les quelques autres conversions, et vous gagnerez quelques minutes, voire comme dans mon cas, quelques heures de travail (que vous auriez inévitablement perdues avec un autre éditeur) :

Voici un exemple de déclaration C :

typedef FMOD_RESULT
  (F_CALLBACK *FMOD_FILE_OPENCALLBACK)
    (const char *name, int unicode,
      unsigned int *filesize, void **handle, void **userdata);

La fonction finale déclarée en Pascal doit être ainsi :

FMOD_FILE_OPENCALLBACK =
  function (
    const name:Pchar; unicode:Integer;
    var filesize: Cardinal; handle:Pointer;
    userdata:Pointer):FMOD_RESULT;

Je vais vous expliquer les premiers pas : il faut convertir ces paramètres :
void **handle, void **userdata)
en :
handle:Pointer; userdata:Pointer)

Le principe des macros avec les expressions régulières est très simple, je vais la construire pas à pas :

– Va chercher la première chaine qui est void ** :
void \*\*\
Notez bien que comme les étoiles * sont des caractères d’expression régulière, il faut mettre un antislash \ pour qu’elles ne soient pas interprétées.

– Va chercher la première chaine qui est void ** et qui est suivie d’une chaine composée de au moins un caractère minuscule comprise entre a et z :
void \*\*\([a-z]\+\)
Au même titre que les étoiles *, et les antislashes \, les parenthèses () sont des caractères d’expression régulière, il faut mettre un antislash \ pour qu’elles ne soient pas interprétées.
Oui je le concède ça rend la lecture un peu difficile. Mais le temps gagné en vaut la chandelle croyez moi.
– Va chercher la première chaine qui est void ** et qui est suivie d’une chaine composée de au moins un caractère minuscule comprise entre a et z, et qui se termine par une virgule :
void \*\*\([a-z]\+\)\(,\{1\}\)
Ici aussi notez le \{1\} : ici, les crochets \{\} sont des caractères d’expression régulière donc il ne faudrait pas mettre d’antislash, mais comme il sont dans une expression qu’on recherche, il les faut. Bref, essayez une fois avec, une fois sans, et l’un des deux fonctionnera !

Expression finale :

Remplace toutes les chaines de type void **[caractères de a à z], par [caractères de a à z]: Pointer;  :
:%s/void \*\*\([a-z]\+\)\(,\{1\}\)/\1: Pointer;/g

Ainsi :
void **handle,
donnera :
handle: Pointer;.

Mais (et c’est là où c’est génial) :
void **autrenomdevariable,
donnera :
autrenomdevariable: Pointer;.

Et cela s’appliquera sur tout le fichier, quel que soit le nom de la variable.

Ensuite, il vous suffit de vous concocter toute votre séance de petites macros, et de les mettre dans un fichier.
Puis vous appelez :

vim -s macro_vim.cmd [nom du fichier]

et vim jouera la macro dessus.

Librairie gd et gdImageStringFT() : la libération à faire

Il n’est précisé nulle part, que lorsque vous utilisez des fonctions d’écriture telle que gdImageStringFT(), il faut toujours appeler gdFontCacheShutdown() à la fin du programme pour libérer les allocations faites. C’est valgrind qui m’a montré que ce n’était pas correctement libéré. Vive valgrind !