1
Audio / Re: Problème SoundBuffer
« le: Avril 17, 2020, 12:52:56 am »
Parfait !
Merci beaucoup et désolé pour le dérangement occasionné ! ^^
Merci beaucoup et désolé pour le dérangement occasionné ! ^^
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
Pages: [1]
2
Audio / Re: Problème SoundBuffer
« le: Avril 16, 2020, 06:14:44 pm »
Merci pour la réponse rapide ! 
Pour la durée de connexion, je n'avais pas réalisé que je pouvais définir moi-même la durée de connexion (c'est la première fois que je vois ça, c'est pas mal pour désaturer le serveur :O )
Mon ordre de dépendance est bon alors ! Me voilà rassuré ! J'espère que ces questions de dépendance ne m'attraperont plus la jambe au moins jusqu'à la mise à jour de mon matériel informatique dans 40 ans ! x)
Je l'avais lu en plein, je te rassure, mais lors de mes testes, mettre le dll en compagnie du .exe ne changeait rien.
La situation s'est débloquée une fois que j'ai compris que c'était justement la ligne de code (celle qui réclamait et imposait d'avoir ce .dll à côté du .exe pour être acceptée) qui bloquait sourdement la nouvelle compilation du projet.
Résultat : il faut retirer cette ligne de code qui nécessite openal32.dll, compiler le projet une première fois, mettre le dll avec l'exe dans bin/release et debug, puis seulement ajouter la ligne de code pour recompiler à nouveau.
Mon erreur semble de n'avoir jamais songé à placer le openal32.dll avec l'.exe AVANT d'en avoir l'usage. Je le saurais pour l'avenir ! x)
Mais dans ce cas, est-ce que cela signifie qu'avant même de commencer à coder et les appeler dans le code, je dois joindre les .dll que je dois prévoir associer ?
Et pour mes ressources (image, son, ...), il faut que je les mette toutes en compagnie de cet exécutable avec les noms de dossier similaire à ceux déterminés dans le projet C::B ? °_-
Pour la durée de connexion, je n'avais pas réalisé que je pouvais définir moi-même la durée de connexion (c'est la première fois que je vois ça, c'est pas mal pour désaturer le serveur :O )
Mon ordre de dépendance est bon alors ! Me voilà rassuré !
J'espère que ces questions de dépendance ne m'attraperont plus la jambe au moins jusqu'à la mise à jour de mon matériel informatique dans 40 ans ! x)Je l'avais lu en plein, je te rassure, mais lors de mes testes, mettre le dll en compagnie du .exe ne changeait rien.
La situation s'est débloquée une fois que j'ai compris que c'était justement la ligne de code (celle qui réclamait et imposait d'avoir ce .dll à côté du .exe pour être acceptée) qui bloquait sourdement la nouvelle compilation du projet.
Résultat : il faut retirer cette ligne de code qui nécessite openal32.dll, compiler le projet une première fois, mettre le dll avec l'exe dans bin/release et debug, puis seulement ajouter la ligne de code pour recompiler à nouveau.
Mon erreur semble de n'avoir jamais songé à placer le openal32.dll avec l'.exe AVANT d'en avoir l'usage. Je le saurais pour l'avenir ! x)
Mais dans ce cas, est-ce que cela signifie qu'avant même de commencer à coder et les appeler dans le code, je dois joindre les .dll que je dois prévoir associer ?
Et pour mes ressources (image, son, ...), il faut que je les mette toutes en compagnie de cet exécutable avec les noms de dossier similaire à ceux déterminés dans le projet C::B ? °_-
3
Audio / Problème SoundBuffer
« le: Avril 16, 2020, 02:54:36 pm »
Bonjour tous le monde,
je me dépêche car j'ai cru voir que je n'avais que 60 minutes de Login !
Ainsi donc, j'ai un problème avec la partie Audio de la SFML.
Je suis actuellement sous Code::blocks 17.12, avec la SFML 2.5.0, OS Window10.
J'ai installé cette dernière en version "Statique" directement dans le "compiler setting" de Code::Block (et non uniquement sur le projet en court).
J'ai suivi le tuto d'installation du site SFML à la lettre et j'affiche le rond vert sans problème.
Ayant dans l'idée que c'était bon pour l'usage, j'ai suivi mon cours de formation C++ / SFML (création de fenêtre, gestion des sprites, gestion des collisions, ...) et tout s'est déroulé sans accro jusqu'à l'intégration des SoundBuffer.
j'ai bien pensé à mettre "#include <Audio.hpp>" et j'ai respecter les directives mon tuto mais un message d'erreur à émerger :
- "C:\SFML250\lib\libvorbis.a(block.o):block.c|| undefined reference to `oggpack_writeinit'|"
Ayant fait une recherche sur Google, j'ai lu que c'était à cause d'un mauvais ordre dans l'agencement des dépendances. Voici donc l'ordre de ma "Linker Setting" qui m'a donné ce message d'erreur :
- sfml-graphics-s-d
- sfml-graphics-s
- sfml-window-s-d
- sfml-window-s
- sfml-audio-s-d
- sfml-audio-s
- sfml-network-s-d
- sfml-network-s
- sfml-system-s-d
- sfml-system-s
- freetype
- gdi32
- ogg
-vorbis
-vorbisfile
-vorbisenc
- flac
- openal32
- opengl32
- ws2_32
- winmm
(il s'agit de l'ordre littéral, du haut vers le bas. Comme si j'avais screener mon écran).
Ayant lu que mon ordre n'étant probablement pas le bon, j'ai suivi l'ordre EXACTE [des premiers en face de sfml-graphics-s mis en haut de la liste, puis ordonné en descendant, décalant les doublons (opengl32) vers sa position la plus basse dans la liste montré sur le site] affiché sur le site SFML de mise en place des dépendances : https://www.sfml-dev.org/tutorials/2.5/start-cb-fr.php
Malheureusement, suite à cette réorganistion de l'ordre des dépendances, un nouveau message d'erreur à émergé :
- "Impossible d'exécuter le code, car openal32.dll est introuvable. La réinstallation du programme peut corriger ce problème."
Me voilà donc un brin démuni.
=> Sauriez m'afficher un screen de votre "Linker Setting" avec tous les modules et toutes les dépendances organisées -pour un SFML_STATIC- de la plus parfaite des manières ? * - *
Je lu aussi qu'il était nécessaire -même avec une création SFML static- de fourrer le openal32.dll dans ... un dossier, quelque part dans mon projet, mais j'avoue ne pas avoir compris où avec précision Je précise que google ne m'a pas aidé à mieux comprendre de ce côté là et copier / coller ce .dll partout serait peu fiable et ordonné.
Si vous utilisez le module sfml-audio (que ce soit dynamiquement ou statiquement), vous devez aussi copier la DLL de bibliothèque externe dont il dépend, qui est OpenAL32.dll.
Ces fichiers se trouvent également dans <installation-de-sfml/bin>.
Sauriez m'orienter avec la plus grande précision ?
Note Annexe : Code::blocks semble être passé en version 20.03, sauriez-vous me dire s'il vaut mieux que je passe sous celle-ci ou si je devrais rester sous la C::B v17 tant que la SFML n'a pas été officialisée sur la C::B v20 ?
je me dépêche car j'ai cru voir que je n'avais que 60 minutes de Login !
Ainsi donc, j'ai un problème avec la partie Audio de la SFML.
Je suis actuellement sous Code::blocks 17.12, avec la SFML 2.5.0, OS Window10.
J'ai installé cette dernière en version "Statique" directement dans le "compiler setting" de Code::Block (et non uniquement sur le projet en court).
J'ai suivi le tuto d'installation du site SFML à la lettre et j'affiche le rond vert sans problème.
Ayant dans l'idée que c'était bon pour l'usage, j'ai suivi mon cours de formation C++ / SFML (création de fenêtre, gestion des sprites, gestion des collisions, ...) et tout s'est déroulé sans accro jusqu'à l'intégration des SoundBuffer.
j'ai bien pensé à mettre "#include <Audio.hpp>" et j'ai respecter les directives mon tuto mais un message d'erreur à émerger :
- "C:\SFML250\lib\libvorbis.a(block.o):block.c|| undefined reference to `oggpack_writeinit'|"
Ayant fait une recherche sur Google, j'ai lu que c'était à cause d'un mauvais ordre dans l'agencement des dépendances. Voici donc l'ordre de ma "Linker Setting" qui m'a donné ce message d'erreur :
- sfml-graphics-s-d
- sfml-graphics-s
- sfml-window-s-d
- sfml-window-s
- sfml-audio-s-d
- sfml-audio-s
- sfml-network-s-d
- sfml-network-s
- sfml-system-s-d
- sfml-system-s
- freetype
- gdi32
- ogg
-vorbis
-vorbisfile
-vorbisenc
- flac
- openal32
- opengl32
- ws2_32
- winmm
(il s'agit de l'ordre littéral, du haut vers le bas. Comme si j'avais screener mon écran).
Ayant lu que mon ordre n'étant probablement pas le bon, j'ai suivi l'ordre EXACTE [des premiers en face de sfml-graphics-s mis en haut de la liste, puis ordonné en descendant, décalant les doublons (opengl32) vers sa position la plus basse dans la liste montré sur le site] affiché sur le site SFML de mise en place des dépendances : https://www.sfml-dev.org/tutorials/2.5/start-cb-fr.php
Malheureusement, suite à cette réorganistion de l'ordre des dépendances, un nouveau message d'erreur à émergé :
- "Impossible d'exécuter le code, car openal32.dll est introuvable. La réinstallation du programme peut corriger ce problème."
Me voilà donc un brin démuni.
=> Sauriez m'afficher un screen de votre "Linker Setting" avec tous les modules et toutes les dépendances organisées -pour un SFML_STATIC- de la plus parfaite des manières ? * - *
Je lu aussi qu'il était nécessaire -même avec une création SFML static- de fourrer le openal32.dll dans ... un dossier, quelque part dans mon projet, mais j'avoue ne pas avoir compris où avec précision Je précise que google ne m'a pas aidé à mieux comprendre de ce côté là et copier / coller ce .dll partout serait peu fiable et ordonné.
Si vous utilisez le module sfml-audio (que ce soit dynamiquement ou statiquement), vous devez aussi copier la DLL de bibliothèque externe dont il dépend, qui est OpenAL32.dll.
Ces fichiers se trouvent également dans <installation-de-sfml/bin>.
Sauriez m'orienter avec la plus grande précision ?
Note Annexe : Code::blocks semble être passé en version 20.03, sauriez-vous me dire s'il vaut mieux que je passe sous celle-ci ou si je devrais rester sous la C::B v17 tant que la SFML n'a pas été officialisée sur la C::B v20 ?
Pages: [1]