Lorsque la société Firelight a sorti leur outil pour jouer de la musique, je n’y croyais pas tellement il était puissant. Maintenant preuve est faite : plusieurs millions de développeurs s’en servent à travers le monde (et ça n’est pas exagéré), et plusieurs dizaines de millions de joueurs, et des milliers de professionnels, utilisent fmod sans le savoir.
A l’époque, il y avait les entêtes (headers) destinés au C, mais aussi les entêtes (headers) destinés à Delphi. Ensuite, ils se sont aperçu que seul le C était vraiment rentable, voire certains outils, même si ça me fait mal de le dire, de Microsoft. Donc ils ont arrêté le suivi des entêtes (headers) en Pascal Objet, destinés à Delphi.
J’ai donc pris mon courage à deux mains, et vim, et j’ai converti, via quelques bonnes macros, tous les entêtes en C du tout dernier fmod en date, la librairie.
Pour les quelques appels de fonction que j’ai fait, ça fonctionne parfaitement.
Bien sûr, sur plusieurs milliers de lignes, il y a peut être des erreurs de conversion, donc si vous voulez appeler des fonctions et que ça ne réussit pas, faites comme moi : lisez attentivement la documentation, puis regardez les anciens entêtes (headers) destinés à Delphi, et comparez avec ma traduction : peut-être y a-t-il une correction, ou une évolution du code à faire. Si c’est le cas, ce serait très gentil de m’écrire et/ou de laisser un message ici décrivant la modification à apporter.
Si vous êtes intéréssé pour télécharger :
un programme d’exemple qui lit un mp3
les nouveaux en-têtes en Pascal
avec les anciens en-têtes (au cas ou les nouveaux ne fonctionneraient pas)
Alors cliquez ici.
NB : L’exécutable ne fonctionnera pas parce que le nom du fichier MP3, et de la librairie, sont codés en dur. Il vous suffit juste de changer ça pour voir que ça fonctionne.
Bien évidemment c’est sous licence LGPL.
Pour preuve, ci-suit la réponse de la société.
2011/5/17 Firelight Technologies Support
Hi Olivier,
We would be ok if you hosted them on your site – we probably wouldnt put it on ours any more because of the small interest of pascal these days.
————— Original Message —————
From: Olivier Pons
Sent: 17/05/2011 5:15 AM
To: support@fmod.org
Subject: About Pascal headers.
Hi,
It seems you’ve stopped to write Pascal headers.
I’ve translated all your header files into Pascal object and it works pretty
well.
I’ve followed your whole design :
– fmod.pas
– fmod_codec.inc.pas
– fmod_dsp.inc.pas
– fmod_memoryinfo.inc.pas
May I ask you two possibilities :
– either you release them as « no guarantee behind » (sorry for my English,
but I’m pretty sure you understand the kind of license I’m talking about)
– or I release them as freeware on my website (type « olivier pons » i’m #2
after the facebook) http://olivierpons.fr/
Thank you again, the quality of your job is simply amazing.
Je développe en Delphi depuis plusieurs années et je me suis remis à la base de données il y a peu.
Donc je fais un petit mémo expliquant ce que j’ai compris, en espérant que cela fera gagner du temps à ceux qui n’y arrivent pas, et en sautant les étapes de l’aide Delphi, qui, quoique très précise et détaillée, aurait tendance dans un premier temps à plus nous embrouiller qu’autre chose.
Dans une application « orientée base de données », il faut tout d’abord afficher les données. Il y a les composants de données, qui commencent tous par TDB (TDBGrid, TDBEdit, TDBMemo etc.). On prend le composant, on le dépose sur la fiche. On a une « DBGrid1 » qui s’affiche.
Ensuite, il faut aller chercher les données qu’on veut afficher. Une « source de données ». En Anglais, un composant « TDataSource ». On prend le composant, on le pose sur la fiche, on initialise la propriété « DataSource » de notre « DBGrid1 » à « DataSource1 ».
Ensuite, ce composant « source de données » doit aller chercher les données quelque part. Mais où ? Eh bien chez un « serveur de données ». Pour cela il nous faut un objet appelé le client. Ça peut paraitre bizarre, mais on l’appelle « client » parce que c’est lui qui ira demander des informations à un serveur de données. C’est le client de données du serveur de données. Donc un client d’ensemble de données, en Anglais : « TClientDataSet ». On prend un composant « TClientDataSet », on le pose sur la fiche, et on initialise la propriété « DataSet » de « DataSource1 » à « ClientDataSet1 ».
Ce fameux Client, lui, doit donc se connecter à un serveur de données. C’est intéréssant dans la mesure ou ce fameux serveur peut être « hors » de l’application, sur un autre ordinateur, mais faisons simple : on va supposer que ce serveur est directement intégré à l’application. On utilise donc un composant fournisseur de données, en Anglais : « TDataSetProvider ». On prend un composant « TDataSetProvider », on le pose sur la fiche, et on initialise la propriété « ProviderName » de « ClientDataSet1 » à « DataSetProvider1 ».
On y est presque !
Il reste le côté purement physique, c’est à dire l’objet réel qui ira lire les informations. Nous allons prendre un objet TTable. (Il y a les objet TIBTable pour Interbase, TMyTable pour MySQL, TSQLTable pour dbExpress, bref, plein de tables dont on se sert de la même manière que TTable). On prend un composant « TTable, on le pose sur la fiche, et on initialise la propriété « DataSet » de « DataSetProvider1 » à « Table1 ».
Voilà l’image résultat :
Voilà le trajet des informations :
Lorsque la grille de données voudra lire des informations pour les afficher, la demande suivra ce trajet :
L’intérêt d’avoir autant de composants c’est qu’on peut faire deux applications : le client qui affiche les données, et le serveur, qu’on peut mettre sur un autre ordinateur.
Il est possible de « couper » directement la route et de ne faire qu’un lien direct entre DataSource1 et Table1. (Le propriété DataSource1.DataSet = « Table1 »). Mais ce ne sera pas du tout évolutif. A éviter donc.
