PolySnd - Page 61

Une question, pour la comparaison "polysound <-> gameboy" (qui à mes yeux reste stupide, mais bon...). Il existe un format pour la game boy, il s'agit de fichiers .gbs, disponibles par exemple ici (lecteur disponible ici).

Pourquoi pas tenter une conversion de ce format vers polysound ? (au moins la banque de musique est énorme, en plus d'être parfaitement adaptée aux jeux, et parrait-il "proche du format polysound" du point de vue du fonctionnement)

Une question, pour la comparaison "polysound <-> gameboy" (qui à mes yeux reste stupide, mais bon...). Il existe un format pour la game boy, il s'agit de fichiers .gbs, disponibles par exemple ici (lecteur disponible ici).

Cette comparaison est stupide pour toi car du point de vue fonctionnement, PolySnd ne travail qu'avec que de simple fréquence, pas d'instruments ou d'échantillions. Et tu as raison de dire ça, mais j'ai pas dit que PolySnd avait un son identique à la Game Boy, j'ai juste dit que le son s'en rapproche, confère Mario Castle qui avec certain défaut, n'est pas loin de la version d'origine...

Je vais regarder les formats et réflechir à tout ça, mais ce que je propose déjà me semble déjà plus que suffisant (Librairie qui va devenir optmisé et qui consommera vraiment peut de ressources CPU, déjà j'ai gagné 50% depuis le début, convertisseur MIDI capable de presque tout convertir correctement et de changer certaines valeurs en fonctions de ses besoins (vitesse, taille, qualité audio), convertisseur WAV et un player assez sympa à utiliser et assez puissant.

Pourquoi pas tenter une conversion de ce format vers polysound ? (au moins la banque de musique est énorme, en plus d'être parfaitement adaptée aux jeux, et parrait-il "proche du format polysound" du point de vue du fonctionnement)

Je suis persuadé que le format Game Boy demande ceci (table d'échantillions par instruments, une gestion de cette table et un format plus complexe que tu le pense (gestion du volume et possibilité de mixer 2 échantillions....) si c'est le cas, je serais obliger de tout recoder la partie gestion de PolySnd et le travail est horrible à faire, j'attend de voir ce que donne PolySnd v2.0, si il a un assez bon succès, là je ferait une version 3 avec l'idée de Pollux et la possibilité de tout faire et de réellement joué des PolyNotes en MEME TEMPS.

Il ne me reste plus qu'à optmiser a fond PolySnd, le code me semble de moins en moins lisible et de moins en moins accessible. Et a traduire la documentation.
Les exemples sont bien au chaud et certain promette des surprise tant en taille quand qualité audio et en consommation CPU.

Merci Vertyos de toutes ses infos, je vais y jettais un coups d'oeils et conserver tout ça sur mon DD.

Euh c'est normal que le ./1800 soit différent sur la page 60 et sur la page 61? yAro...

euh c normal que le ./1800 soit différent sur la page 60 et sur la page 61?

yAro...

Ué je sais y'a un bug ds le recomptage d topics ds cette version au moment ou un topic est splitté .... c corrigé dans la v2.9 elle arrive en fin de semaine :]

Euh Vertyos, tu pense quoi de ce que j'ai diffusé comme musique et de leur qualité?

Toujours la même chose :
- dans l'absolu, c'est une vraie prouesse sur Ti,
- par rapport à la game boy, ça revient à comparer du midi et du mp3...

Une autre question, si PolySnd passe d'une consommation CPU à 10% en stéréo (pour l'instant je suis à 31, si la taille des midis fnt 600 octets en compression au lieu de 5 Ko et si la qualité et comparable à Mario Castle..., hésiterez-vous à mettre du son dans vos jeux et pourquoi?

Moi je pense qu'il ne faut pas hésiter, même si on met une option pour que le joueur puisse l'enlever.

geogeo
: Une autre question, si [ ... ] hésiterez-vous à mettre du son dans vos jeux et pourquoi?

Oui, parceque :
• Très peu (même pas 5% à mon avis) de gens ont de quoi entendre ce son,
• La qualité est très loin d'être assez bonne pour avoir quelque chose d'interessant comme des "vraies" musiques style game boy, des sons distinctibles, etc... (encore une fois c'est pas de ta faute, c'est simplement pas faisable sur Ti),
• 31% c'est BEAUCOUP trop de puissance (moi qui avait qq fps libres dans gbs pour faire un test de polysound, la c'est même pas la peine d'essayer),
• Les musiques (du moins les exemples disponibles sur ce topic) prennent énormément de place alors qu'elles ne durent que quelques secondes.

• Très peu (même pas 5% à mon avis) de gens ont de quoi entendre ce son,

Je comprend et je suis d'accord.

• La qualité est très loin d'être assez bonne pour avoir quelque chose d'interessant comme des "vraies" musiques style game boy, des sons distinctibles, etc... (encore une fois c'est pas de ta faute, c'est simplement pas faisable sur Ti),

Tu demande trop de perfections et je te répond que ce qui existe déjà est très satisfaisant et vraiment interessant pour moi dans des jeux. Chacun ses avis mais je ne pense pas offrir mieux que ce qui existe et réellement le son est de très bonne qualité, bien sûr faut pas comparer l'incomparable, la TI n'a pas de chipset audio et encore mois de microcontrolleur ou autre pouvant effectuer ce genre de tâche, tout est fait pas le processeur.

• 31% c'est BEAUCOUP trop de puissance (moi qui avait qq fps libres dans gbs pour faire un test de polysound, la c'est même pas la peine d'essayer),

C'est l'état actuelle des chose, je rappelle encore que 31% c'est la cosommation max de PolySnd en stéréo avec un MIDI avec énormément de PolyNotes et avec un tempo assez rapide. En régle général, pour l'instant je suis à moins de 10% en mono, encore et toujours consommation max. Avec les conseils de Pollux que je suis en train de mettre en oeuvre, je risque de gagner beaucoup, je vais pas me prononcer sur le gain gagné mais on verra bien.

Encore une fois 31% c'est une valeur indicatif et mis en hausse. Je suis passé de 77% à 31% et je pense quand même faire des efforts pour diminuer ce chiffre.

• Les musiques (du moins les exemples disponibles sur ce topic) prennent énormément de place alors qu'elles ne durent que quelques secondes.

Ce qui tu dit est harchie faux, Je rappel que la taille d'un MIDI est varaible et peux aller de 1 Ko à 5 Ko max pour 3 mins. Et je précise qu'il est possible de compresser et de gagner énormément, exemple je suis passé de 5 Ko pour Mario Castle, de 2 mins à 600 octets. Surtout qu'on joue une musique dans un programme donc on perd pas grand chose, juste comme une image en monochrome.

Je rappel encore que le format que j'ai adopté est le plus simple possible et économique, et surtout que c'est un peu à cause de ça que PolySnd v2.0 est limité au point de vue audio. Je ne pense pas travaillier sur une autre version complétement radical, utilisant la méthode de Pollux pour jouer réellement plusieurs notes en même temps voir combiner des échantillions (et la tu aura un son de Game Boy mais avec énormément de contrainte et au final inutilisable... je me lasse du son sur TI.

J'ai mis à dispositions des outils, pour l'instant le convertisseur MIDI et avec des réglages possible qui sont la pour diminuer la taille des données ou améliorer la qualité, personnelement je trouve qu'avec ce logiciel on peut facilement demander une musique dans la taille qu'on veut avec une qualité plus ou moins résonnable.
Maintenant chacun fait comme il veut et juge ce qui est bon de faire pour son programme.

geogeo
: Tu demande trop de perfections et je te répond que ce qui existe déjà est très satisfaisant et vraiment interessant pour moi dans des jeux. Chacun ses avis mais je ne pense pas offrir mieux que ce qui existe et réellement le son est de très bonne qualité, bien sûr faut pas comparer l'incomparable, la TI n'a pas de chipset audio et encore mois de microcontrolleur ou autre pouvant effectuer ce genre de tâche, tout est fait pas le processeur.

Quand je dit que je ne trouve pas la qualité interessant, "si" n'est pas une réponse... Pas la peine de chercher d'excuse je t'ai déjà dit que tu n'y étais pour rien, mais à cause du materiel la qualité sonore est mauvaise, inutile de prétendre le contraire.

C'est l'état actuelle des chose, je rappelle encore que 31% c'est la cosommation max de PolySnd en stéréo avec un MIDI avec énormément de PolyNotes et avec un tempo assez rapide. En régle général, pour l'instant je suis à moins de 10% en mono, encore et toujours consommation max. Avec les conseils de Pollux que je suis en train de mettre en oeuvre, je risque de gagner beaucoup, je vais pas me prononcer sur le gain gagné mais on verra bien.

Toi qui propose à tout bout de champ à des programmeurs d'integrer ta librairie pour des jeux, tu devrais savoir quand même que c'est ce qui demande le plus de puissance. Il est impensable de gacher 31% de la puissance d'un jeu évolué (FlashZBomberman, Kirby, etc...) pour mettre du son.

Ce qui tu dit est harchie faux, Je rappel que la taille d'un MIDI est varaible et peux aller de 1 Ko à 5 Ko max pour 3 mins.

1° C'est pas ce que j'ai vu sur ce topic
2° 5ko c'est beaucoup ! on est sur Ti je te rappelle...

Quand je dit que je ne trouve pas la qualité interessant, "si" n'est pas une réponse... Pas la peine de chercher d'excuse je t'ai déjà dit que tu n'y étais pour rien, mais à cause du materiel la qualité sonore est mauvaise, inutile de prétendre le contraire.

C'est ton avis.

Toi qui propose à tout bout de champ à des programmeurs d'integrer ta librairie pour des jeux, tu devrais savoir quand même que c'est ce qui demande le plus de puissance. Il est impensable de gacher 31% de la puissance d'un jeu évolué (FlashZBomberman, Kirby, etc...) pour mettre du son.

Je fait sans cesse des améliorations, depuis le début j'ai pensais à ça et j'ai crée des routines qui me semble plus économique et surtout rapide. Regarde la source de PolySnd et tu verras que je pense à la vitesse et que j'optimise sans arrêt. Bien sûr 31% c'est encore de trop, mais la seul façon de juger et de tester, après tu voit, surtout que ses valeurs ne me rassure pas car j'ai effectué un test sur le moteur de FAT Engine, dans une version pour Wolfeinstein 3D, à ce moment la PolySnd consommé 77% des ressources, valeur donné par mon programme de teste, le jeux tourné envrion 1,5 fois plus lent en stéréo, en mono, le jeu tourné à environ 1.2 fois plus lent., encore un autre cas, le jeu en noir et blanc, un tunnel, avec toujours une musique en stéréo, le jeu ne subit aucune accélération et déccélération quand il y a du son, encore plus surprenant, il n'y a aucune différence de vitesse avec ou sans son.
Encore un exemple dans mon jeu arkanoid, avec du son en stéréo la première balle met 11 sec à toucher un mur et sans son environ 9 sec.
Chacun fait comme il veut, mais j'ai surtout développé cette version dans l'optique d'être intégré dans des jeux, pas pour faire office d'une seule utilisation, donc le problème de vitesse j'ai essaye au mieux de diminuer la consommatione tje sais de quoi je parle, sans ça je n'irais pas saouler d'autre personnes pour m'aider. Surtout que j'ai appris l'ASM il y a moins d'un ans et j'ai encore de grosse lacunes dans ce domaine.

1° C'est pas ce que j'ai vu sur ce topic 2° 5ko c'est beaucoup ! on est sur Ti je te rappelle...

Pour toi c'est impensable de perdre 600 octets quand la musique n'ai pas joué et faire un buffer de 5 Ko quand elle est joué et donc perdre 5600 octets, surtout quelle est joué une seule fois et pas en permanence, donc ce buffer est retiré dès que la musique est terminé. En plus de ça la compression est instantané et ne demande pas une place folle a être intégré tout comme la librairie ou j'ai fait des efforts en taille de ce côté.
Je te trouve de mauvaise fois pour ça, faut pas exagérer, c'est pas énorme de perdre 5 Ko de plus dans son jeu, surtout que tu peux faire uune musique de très bonne qualité à 2 Ko voir moins. Surtout qu'il faut pas imaginer mettre du son sans certaines concessions...

Au final chacun fait comme il veut...

Moi personellement c'est un plus que j'envagerai pour puyo-puyo(un puzzle game style tetris) et legend of the holy sword (RPG tour a tour) car il ne necessiteront sans doute pas toute la puissance.
Le son est mauvais mais c'est enfin écoutable ce qui n'était pas vraiment le cas des autres libs sons.
Maintenant pour la date de sortie c'est absolument pas garanti car en ce moment je suis sur TIM dont la date de sortie n'est pas plus garantie. Je ferai peut-être un plug-in sonore mais bon l'interet reste limité.

Uther
: Le son est mauvais mais c'est enfin écoutable ce qui n'était pas vraiment le cas des autres libs sons.

C'est ce que j'aimerais bien faire comprendre à geogeo... Pour de la Ti, et UNIQUEMENT POUR DE LA TI c'est très bien. Sinon comme "son" en general c'est de la mauvaise qualité.

Oui mais ce que tu ne dis pas c'est que c'est assez bon pour être utilisable dans un jeu(a mon avid) même si c'est vrai que ce n'est pas niveau gameboy.

Oui mais ce que tu ne dis pas c'est que c'est assez bon pour être utilisable dans un jeu(a mon avid) même si c'est vrai que ce n'est pas niveau gameboy.

C'est ce que j'essaye de dire depuis le début.

Comment fonctionne ton algo de WAv dans ton interruption, Pollux??? Ca m'interesse vraiment!

de quoi, pour les wave compressés?

Non comment tu les joues?

Ben avec une interruption toute bête. Sauf que je ne fais pas des tests à la suite qui pourraient être réduits à un seul test avec un minimum de précalcul...

Ca je le sais bien.
Ca ne me donne pas comment son organisé tes données, de quelle qualité et taux d'échantillionage tu lis les WAV et surtout comment fonctionne la routine qui à pour but de lire les données et de faire changer l'état du port I/O???

Ben ça dépend de quel algo de wave tu parles, le 8/11 kHz ou le 16/22 kHz...

> comment fonctionne la routine qui à pour but de lire les données
la décompression?

> faire changer l'état du port I/O???
ben je teste s'il faut changer le canal gauche, si c'est le cas je fais un bchg dessus, idem pour le canal droit, où est le pb?

> comment fonctionne la routine qui à pour but de lire les données la décompression?

lol, je me fiche de ça, je veux juste savoir la qualité des wav que tu joue (1 bit, 4 bits...) leur taux d'échantillionage donc de 8 à 22 khz et surtout comment tu lis les données et comment c'est présenté?

1 bit.

> comment tu lis les données et comment c'est présenté?
c'est compressé



Bon plus sérieusement tu veux un lecteur de wave pour quoi? tu veux une compression? tu veux du 16 kHz ou du 8 kHz?

lol, on ce comprend pas, je veux pas que tu me sorte un programme made in Pollux et que tu fasse tout.
Je veux juste comprendre comment ça fonctionne sans la compression et être capable d'améliorer ma routine.

Donc c'est du 1 bit, donc ton programme qui renvoye les données met 8 état dans un octet.
Maintenant comment tu fait pour lire ses données, moi dès qu'un bit est à 1 le port I/O est à 3v et le bit à 0 port I/O à 0v.
Pour 16 khz je présume que tu lis 2 état dans la même interruption???

> je veux pas que tu me sorte un programme made in Pollux et que tu fasse tout.
Evidemment et puis ça tombe bien parce que moi non plus

> Pour 16 khz je présume que tu lis 2 état dans la même interruption???
Non, je t'ai déjà expliqué la méthode plusieurs fois, mais je vais me répéter : l'idée, sachant que $600017 est incrémenté 16000 fois par seconde, est d'éviter les interruptions inutiles. On calcule n = le nombre de 16000è de secondes qu'il va falloir attendre avant de devoir changer la valeur du port.

Si n>1, pas de pb puisqu'on fait move.b 257-n,$600017 et c bon.
Si n=1, problème : si on fait move.b 0,$600017, on obtient le même résultat que n = 257. Donc on ne peut pas jouer ce signal-là.

Donc on peut jouer n'importe quel wave à 16 kHz s'il ne contient pas 2 chgts d'état à la suite : c'est très contraignant pour un son stéréo, mais bcp moins pour un son mono. L'idéal est que ce soit le convertisseur qui s'occupe de ça.


Pour le format de données, un format primaire mais assez adapté à cette façon de procéder serait de stocker tout bêtement les valeurs de n, ou encore de 257-n, avec 2<=n<=256, et la valeur 0 serait réservée (par exemple pour représenter les valeurs de n supérieures à 257, ou pour terminer le morceau).

Si n>1, pas de pb puisqu'on fait move.b 257-n,$600017 et c bon.
Si n=1, problème : si on fait move.b 0,$600017, on obtient le même résultat que n = 257. Donc on ne peut pas jouer ce signal-là.
Donc on peut jouer n'importe quel wave à 16 kHz s'il ne contient pas 2 chgts d'état à la suite : c'est très contraignant pour un son stéréo, mais bcp moins pour un son mono. L'idéal est que ce soit le convertisseur qui s'occupe de ça.

J'avais compris mais comme le compteur 0x600017 est toujours à 0xFF, ton idée ne fonctionne pas et est impossible à réaliser.

Pour le format de données, un format primaire mais assez adapté à cette façon de procéder serait de stocker tout bêtement les valeurs de n, ou encore de 257-n, avec 2<=n<=256, et la valeur 0 serait réservée (par exemple pour représenter les valeurs de n supérieures à 257, ou pour terminer le morceau).

Donc tu procéde comme ça, je vais voir avec le convertisseur de brunis pour faire ça et voir si la qualité du son est mieux.

Reste juste une chose à te demander et je te saoul plus:
Comment tu lis les données, si bit à 1 le port I/O à 1 si bit à 0 port I/O à 0????

Justement, tu modifies 0x600017

Et pour les données, le mieux est à mon humble avis de faire bit à 1 : changement du port I/O, bit à 0 : port I/O tel quel. Mais l'idéal n'est pas de le faire en bitmap comme ça (sauf si tu compresses après), mais plutôt de faire un RLE comme je l'ai dit dans mon post précédent.

Justement, tu modifies 0x600017

Heu je crois que tu ne ma pas compris, si tu le modifie tu aura besoin d'incrémentation du compteur et donc l'interruption mettera plus de temps à ce déclencher, donc au final, tu réduit la vitesse de l'interruption, il est impossible de faire du 16 KHz sur HW2 et 22 KHz sur HW1.

Essaye tu comprenderas très rapidement.
On a du mal à ce comprendre.

Et pour les données, le mieux est à mon humble avis de faire bit à 1 : changement du port I/O, bit à 0 : port I/O tel quel. Mais l'idéal n'est pas de le faire en bitmap comme ça (sauf si tu compresses après), mais plutôt de faire un RLE comme je l'ai dit dans mon post précédent.

lol, donc ce que tu vient de me dire avec selon toi les données fournis par le convertisseur ne sont plus valable. Puisque après avoir effectué des testes, pour avoir du son avec tes données il faut procéder comme je fait.

Pour ton format RLE c'est assez stupide puisque on multiplie par 8 la taille des WAVs or comme tu le sais, rien que 4 secondes ça prend beaucoup de place même en 1 bit.
Pour terminer le morceau, je vois simple moi, entrer en arguments la taille en octet de la musique, un sizeof en C suffit puis de décrémenter un compteur et dès qu'il est à 0 on quitte, rien de plus simple, ta méthode me paraît être du gaspillage de mémoire, surtout 1 bit n'est pas négligeable. Tu va me dire que tu perd des resosurces CPU mais faut quand même un compromis entre mémoire et vitesse.