Notes de version pour SFML 1.6

Voici un résumé de ce qui reste à effectuer, des problèmes actuellement connus ainsi que quelques informations techniques afin de tirer le meilleur partir du portage pour Mac OS X.

À faire :
    - la gestion des joysticks

Problèmes connus :
    - certaines touches ne sont pas indépendantes de la configuration du clavier (voici les touches que vous pouvez utiliser sans risque : '*+,-./:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ ). Seuls les événements sf::Event::KeyPressed et sf::Event::KeyReleased sont concernés par ce problème, pas les événements sf::Event::TextEntered.
    - les touches Control, Option (Alt), Shift et Command ne produisent pas d'événement de répétition lorsqu'elles sont maintenues enfoncées
    - étant donné qu'un clavier Mac est différent de celui d'un PC, certains codes sf::Key ne sont pas utilisés, et d'autres sont manquants
    - l'anticrénélage OpenGL est désactivé

Notes techniques :

Les touches Control, Option [...] :
Mac OS X avertit l'application uniquement lorsque l'état d'une de ces touches particulières est modifié, pas lorsqu'elles sont maintenues enfoncées. De plus, ces touches sont considérées comme des "modifiers" et ne doivent donc pas être utilisées seules comme raccourci pour déclencher une action (ex: Control + E convient mais pas Control tout seul).

Indépendance vis à vis des configurations de claviers :
Lorsque SFML obtient un événement clavier, elle obtient un code correspondant à cette touche. Cependant ce code représente la touche elle-même, et non pas ce qui est imprimé sur votre clavier, donc des claviers anglais et français produiront — en considérant que vous pressez la touche placée exactement au même endroit – le même code, quelque soit la configuration de clavier que vous utilisez. Afin de contourner en partie le problème, certaines touches sont devinées à partir du champ "text" de l'événement et non pas à partir du code de la touche. Ce n'est pas une solution pleinement satisfaisante mais je n'ai trouvé aucune meilleure solution jusqu'à ce jour (davantage de recherches me sont nécessaires). Si vous voulez être sûr que l'événement reçu est bien le caractère que vous voulez, vous devriez uniquement utiliser les événements sf::TextEntered (non concernés par le problème).
Notez qu'étant donné que le code représente les touches du clavier anglais, les utilisateurs anglophones n'ont pas à se préoccuper de ce problème.

Le chargement des ressources :
1. Lorsqu'une application SFML est lancée, elle désigne le dossier Resources (<votre application.app>/Contents/Resources) comme étant le répertoire actuel de travail. Si votre logiciel n'est pas une application paquet, SFML désignera le dossier contenant votre programme comme étant le répertoire de travail. Par conséquent, si vous souhaitez charger des ressources, vous pouvez utiliser sans risque des adresses relatives aux dossiers indiqués ci-dessus.

2. La désignation du répertoire de travail est effectuée au moment du chargement du programme avant d'entrer dans la fonction main(). Cependant, si vous définissez des variables globales (comme par exemple des objets de type sf::Image) et que vous essayez de charger l'image au moment de la construction de l'objet (donc par l'intermédiaire du constructeur), rien ne vous garantie que le répertoire de travail est déjà valide. Vous devez donc charger toutes vos ressources après être entré dans la fonction main().

Les attributs du contexte OpenGL :
SFML utilises le partage de contexte OpenGL afin d'éviter de charger plusieurs fois la même ressource, même si vous avez plusieurs fenêtres SFML. Cela permet d'économiser à la fois de la mémoire et tu temps de traitement, mais cela implique aussi une restriction importante (qui semble être propre à Mac OS X) : les contextes partagés doivent avoir des attributs compatibles. Un point sur lequel je vais m'attarger est le niveau d'anticrénélage : vous ne pouvez pas utilisez différents contextes partagés entre eux avec un niveau d'anticrénélage différent. Il faut noter que SFML définit un contexte globale partagé, donc si je choisis de ne pas utiliser d'anticrénélage pour ce contexte, l'anticrénélage ne pourra être utilisé pour aucun autre contexte OpenGL (et fenêtre SFML). D'un autre côté, je pourrais définir 2 (ou n'importe quelle autre valeur) niveaux d'anticrénélage, mais tous les autres contextes seraient obligés d'utiliser aussi le même niveau de lissage. Étant donné que l'anticrénélage n'est pas une opération légère pour l'unité de calcul graphique, il a été désactivé. Écarter cette fonctionnalité me semble être une meilleure solution que forcer l'utiliser à l'utiliser.
En ce qui concerne les autres attributs, il semblerait qu'ils puissent être différents. Je ne les ai pas tous testés mais j'ai pu constater que certains étaient automatiquement modifiés à cause de valeurs choisies trop hautes.

OpenAL :
Vous pouvez remarquer la présence du framework OpenAL dans l'archive, mais vous savez aussi peut-être que Mac OS X inclut déjà OpenAL (voir /Système/Bibliothèque/Frameworks). Ce framework a été ajouté au paquet afin de corriger des problèmes causés par celui présent par défaut. En conséquence, il est inutile de fournir ce framework si vous n'avez pas l'intention de distribuer votre application pour Mac OS X 10.4 ou si vous utilisez la version 64 bits de SFML (qui ne supporte pas Mac OS X 10.4).

Pour toutes les questions, rendez-vous sur le forum SFML : http://www.sfml-dev.org/forum-fr/