musiques en OGG

*.OGG est un format compressé de musiques, il serait intéressant que Panoramic puisse prendre en charge ce format car le jeux que je développe deviendrait becaup moins lourd (la musique pèse plus de 60% de la taille de mon fichier)

Merci de répondre a ma suggestion

The gamer

PANORAMIC pourrait très bien prendre en charge le format OGG, comme d'autres d'ailleurs, mais ...
... à condition d'utiliser quatre DLL, que tu devras fournir à chaque fois que tu fourniras ton jeu. Et ce que tu vas gagner en taille de fichier sonore, tu risques de le reperdre dans la taille des DLL...
Un peu comme inpout.dll qu'il faut fournir obligatoirement quand on fournit un logiciel fait avec PANORAMIC et qui utilise le port parallèle.

A moins que tu demandes à tes utilisateurs de les télécharger eux-mêmes et de les installer. Et alors là, tu n'imagines pas la difficulté que tu auras pour expliquer ça. La plupart des utilisateurs ne connaissent même pas le nom de l'Operating System qui est dans leur PC.

C'est pour simplifier cela que PANORAMIC n'utilise que des formats "natifs", que les API de Windows manipulent simplement pour le son (WAV, MP3), pour les graphiques (BMP, JPG) ou pour le texte (TXT).

Par contre, si tu me fournis le principe du codage OGG et les algorithmes d'écriture et de lecture de fichiers OGG, je les intègre dans PANORAMIC et on n'a plus besoin de DLL. Par "algorithme", je veux dire le codec Vorbis suffisamment détaillé pour qu'il n'y ait plus qu'à coder et non pas les listing en C++ des DLL, que j'ai déjà.

Eh bien,, Jack, le moins qu'on puisse dire, c'est que tu réagis vite et que tu fais des propositions immédiates et puissantes suite à une demande ponctuelle ! Alors que tu nous a dit récemment que tu souhaites de déplacer un peu ton activité sur ton nouveau "bébé", c'est encourageant pour nous autres Panoramiciens...

Dans ce contexte, et sans vouloir t'imposer quoi que ce soit, est-ce que tu as prévu quelque chose pour des suggestions plus anciennes comme de vrais sous-programmes avec paramètres formels par des commandes comme
CALL mon_sousprogramme(...)
avec
SUBROUTINE mon_sousprogramme(...)
...
END_SUB
l'utilisation de vraies fonctions comme
i$ = ma_fonction$(...)
i% = ma_fonction%(...)
i = ma_fonction(...)
avec
FUNCTION ma_fonction$(...)
...
END_FUNCTION
etc

ainsi que ta suggestion, déjà ancienne, d'avoir la possibilité de faire des plug-in ? Est-ce que dans l'état actuel des choses, c'est complètement hors propos, ou est-ce qu'on peut avoir un espoir raisonnable ?

Je suis en train de réaliser, comme d'autres d'ailleurs, un préprocesseur qui transforme un code contenant les commandes ci-dessus en code Panoramic pur, sans conflit de nommage des variables et labels, et sans avoir besoin de déclarer labels et variables au préalable - bénies soient les fonctions variable() et label() ! La structure est opérationnelle, j'essaie de réaliser maintenant un analyseur syntaxique d'une commande Panoramic en Panoramic pour pouvoir détecter les variables et labels à adapter à l'intérieur d'une commande, car je veux le faire sans avoir à utiliser un préfixe ou un identificatif spécial. Mais tout cela n'a évidemment pas de sens si tu peux nous ajouter ces commandes à Panoramic...

Bonjour,
@ Klaus,
J'avais compris que de ton côté, tu faisais tes propre recherche:

Citation :

Bon, je vois. De mon côté, je travaille aussi sur quelque chose de ce genre, mais ce n 'est pas encore montrable. Ce sera pour un peu plus tard..

Citation :

Je suis en train de réaliser, comme d'autres d'ailleurs, un préprocesseur qui transforme un code contenant les commandes ci-dessus en code Panoramic pur

Je voudrais savoir, si je reprends mon programme concernant mes derniers postes. Je sais par expérience que tu fais mieux que moi, et rassure toi, cela ne ma fais aucun complexe. Je n'ai ni le temps, parce que coder par ci , par là, on ne fait pas le même travail, et tu connais plein de chose que je ne connais pas. L'informatique n'est pas mon métier, et professionnellement, on ne m'a surtout pas encouragé pour qu'il le soit.
Mais si je continu une chose que tu reprends, je perds mon temps, et comme j'ai d'autres choses à faire, il faut que je sache.

Surtout sans amertume, peux-tu donner une info sur ce que tu prépares, ou peut-on se greffer sur ton projet pour associer autre chose?

Eh bien, c'est simple: je poursuis mon idée d'avoir de vrais sous-programmes et fonctions, avec des paramètres formels et des déclarations dim et label à l'intérieur qui ne seraient "visibles" qu'à l'extérieur.

Plusieurs problèmes se posent, et tu les connais aussi bien que moi:
- toute variable déclarée par un dim est visible partout, quelque soit l'endroit où elle est déclarée
- tout label déclaré par une commande label est utilisable partout, de la même manière.
- si un label est déclaré une fois avec la commande label, et si le label est créé à deux endroits sous la forme "label:", seul le premier sera atteint par un goto ou gosub, le second est ignoré mais ne provoque pas d'erreur en compilation

Alors, j'ai défini des méta-commandes de la manière suivante:

définition d'un sous-programme:
SUBROUTINE mon_sousprogramme(p1t,p2t,...)
...
END_SUB

Les paramètres formels sont donnés avec leur type t:
$ = string
% = entier
(absent) = flottant
reprenant ainsi la typologie de Panoramic.

appel d'un sous-programme:
CALL mon_sousprogramme(p1,p2,...)

Les paramètres de l'appel peuvent être des expressions retournant de l'entier, du flottant ou des strings, en fonction du type des paramètres formels dans la méta-commande SUBROUTINE.

définition d'une fonction:
FUNCTION ma_fonctionT(p1t,p2t,...)
...
END_FUNCTION

La fonction retourne un résultat qui représente une valeur en fonction de son type T:
$ = string
% = entier
(absent) = flottant
reprenant ainsi la typologie de Panoramic.

Les paramètres formels sont donnés avec leur type t:
$ = string
% = entier
(absent) = flottant
reprenant ainsi la typologie de Panoramic.

appel d'une fonction:
comme n'importe quelle fonction, mes fonctions peuvent être appelées à l'intérieur d'une expression arithmétique, logique ou de string. Exemples:
i% = ma_fonction%("arrondi",prix*tva/100)
print "Contact: "+ma_fonction$(nom$,17)+" "+ma_fonction$(prenom$,17)
f = 3*ma_fonction(17.5,5,i%)
etc.

Les paramètres de l'appel peuvent être des expressions retournant de l'entier, du flottant ou des strings, en fonction du type des paramètres formels dans la méta-commande FUNCTION.

Le nombre de paramètres formels n'est pas limité. Les paramètres sont tous passés "par valeur" et non par référence: on peut modifier la valeur d'un paramètre à l'intérieur d'un sous-programme ou d'une fonction, mais cette modification n'est pas visible à l'extérieur.

On peut avoir des commandes classiques dim et label à l'intérieur d'un sous-programme ou d'une fonction, mais le préprocesseur génère des noms dérivés du nom indiqué, du nom du sous-programme ou de la fonction et du niveau de "localité" (profondeur d'imbrication des définitions de sous-programmes ou de fonctions), évitant ainsi les conflits de nommage.

Dans tous les cas, nul besoin de faire une commande label ou dim au début du programme pour pouvoir s'en servir - les méta-commandes génèrent automatiquement la structure nécessaire.

Etat de réalisation:
- les commandes SUBROUTINE, END_SUB, FUNCTION, END_FUNCTION et CALL sont terminées - elles génèrent le code correct et qui est exécutable sans problème.
- les commandes dim et label à l'intérieur d'un sous-programme ou d'une fonction sont interceptées et génèrent des noms modifiés selon la règle énoncée ci-dessus. Tout cela fonctionne.

Reste à faire:
- adapter les instructions à l'intérieur d'un sous-programme ou d'une fonction, afin de remplacer les noms des labels et/ou variables par les noms modifiés en cas de besoin (pour les labels ou variables définis à l'intérieur, ou pour des paramètres formels)
- reconnaître l'utilisation de fonctions déclarées par FUNCTION à l'intérieur d'une instruction, mais alors dans tout le programme, afin de générer le code nécessaire à l'appel de la fonction.

Pour cela, je réfléchis sur un analyseur syntaxique d'une instruction Panoramic, afin d'isoler les noms des variables et labels. Pour le moment, je sais reconnaître si une instruction contient une commande Panoramic - reste à décoder ses paramètres. Pour cela, il faut déjà que je fasse l'analyseur d'une "expression" (numérique, logique ou string), car les paramètres aux commandes sont des suites d'expressions.

Voilà où j'en suis. Techniquement, je l'ai intégré dans mon outil de mise en forme d'un source, comme de façon interne, je déplie déjà le programme Panoramic en entrée entièrement, afin de pouvoir calculer l'indentation. Je fais donc tout ce travail sur la partie "déplié" ce qui permet de ne travailler que sur une seule instruction à la fois. Mais je suis encore loin du compte.

J'ai suivi avec intérêt ce que tu fais, et j'ai hésité longtemps pour adopter une démarche similaire. Ton idée de préfixer les variables par un caractère afin de mieux les isoler m'a longtemps poursuivi, et je l'ai finalement abandonné pour une raison précise: il ne suffit en aucun cas de chercher la présence de ce caractère, même si on peut le paramétrer, pour repérer une variable dont le nom doit être adapté. Ce caractère, quel qu'il soit, peut très bien figurer dans une constante string, et on ne sait pas, alors, s'il faut transformer ce qui suit ou si le contenu du string est à prendre tel quel. J'ai donc choisi d'aborder le problème par l'autre côté: repérer les noms, détecter le niveau de localité et remplacer le nom en fonction de cela. Mais la tâche est ardue...

Autre chose: pour le moment, j'ignore complètement les #INCLUDE alors que toi, tu les traites...

Donc, globalement, je suis beaucoup plus loin du compte que toi, et ton programme montrera certainement des résultats exploitables bientôt, alors que le mien ne sera sûrement pas utilisable avant deux ou trois mois, SI j'arrive à résoudre le problème de reconnaissance des expressions.

D'où ma question à Jack, dont je rappelle le sens: j'avais en effet demandé, à plusieurs reprises et avec des approches s'affinant au fur et à mesure, de pouvoir utiliser des sous-programmes et fonctions du type décrit ci-dessus. Jack à même répondu que c'était une idée intéressante et à creuser, et à aucun moment, il a dit que ce serait incompatible avec l'architecture de Panoramic. Et comme je vois qu'il réagit rapidement, spontanément, à une demande somme toute très particulière et qui émane d'un seul Panoramicien (ce qui ne représente en aucun cas un jugement de vameur !), je me suis dit que je pourrais relancer la discussion sur le sujet des sous-programmes et fonctions qui avait l'ai d'intéresser un certain nombre d'entre nous. Si Jack accepte d'ajouter cette possibilité à Panoramic, ce n'est évidemment pas la peine que je réinvente la ficelle à couper le beurre ! Mon programme n'a d'intérêt que si Jack dit que c'est impossible ou d'il ne veut pas le faire.

Merci pour toutes ces précisions.

Je savais qu'en montrant la possibilité d'intercepter les lignes basics pour faire ses propres codes, je serait rapidement repris sur le principe. Et je l'ai rapidement compris, lorsque j'ai vu que tu n'intervenais pas sur mon poste. Là j'ai pensé que tu envisageais quelque chose, parce qu'en lançant l'idée tu ne pouvais pas resté indifférent, et que tes idées allaient prendre le dessus.

Mon problème à ce moment là était de savoir comment on allait faire? Si j'attaque un système avec mes mots clés, et que quelqu'un d'autre allait faire de même, où on accorde ses violons, ou l'un d'entre nous devait laisser tomber. On va se faire concurrence. Je vois mal faire un programme qui soit intercepté, et en même temps être intercepté par un autre préprocesseur. C'est un choix ou un autre. Te voila partie sur de bonnes bases, qui de toute façon seront meilleurs que les miennes, d'autant que tu as d'autre langage pour t'aider dans la tâche. Je me suis dis, si je commence à faire quelques mots clés, et après? faut-il que je fasse à la demande? chacun d'entre nous fabrique t'il les siens? Quoiqu'il en soit, une seule méthode est valable, et dans le cas présent je ne pense quelle puisse être complémentaire.
Je suis capable d'aller très loin pour faire un code, malheureusement, rapidement lorsque je commence, je m'aperçois que je dois trouver un raccourci pour continuer. J'ai pratiquement dû laisser le plaisir de côté pour rester présent avec la réalité d'un mec qui n'a pas de moyen.

Je ne vois pas à quoi cela sert de continuer ma méthode si dans deux/trois mois c'est abandonné.

A toi l'honneur, Klaus, tu es plus capable que moi.

C'est quand-même dommage que tu le sentes comme ça. A aucun moment, je n'ai voulu faire concurrence à qui que ce soit. De plus, du est déjà nettement plus avancé que moi, sans parler su problème des INCLUDE que tu sais gérer, et pas moi.

De toutes les manières, les deux programmes n'ont pas exactement le même objectif. Je pense plutôt qu'ils peuvent se fertiliser l'un l'autre. Et pour les moyens utilisés, je fais tout cela uniquement en Panoramic, exactement comme mon IDE. Je n'utilise aucune DLL pour ce projet ni aucun module dans un autre langage.

D'ailleurs, je fais cela sous forme d'un défi intellectuel pour moi, et si j'en parle sur le forum, c'est surtout pour susciter des commentaires, suggestions et critiques constructives afin de faire avancer ma réflexion. Je n'ai en aucun cas l'ambition de concevoir un outil qui serait la solution pour tous. Je ne suis pas si prétentieux - j'essaye simplement de me faire plaisir en m'attaquant à un problème intellectuel. Et je suis certain qu'il y a de la place pour tous et pour les programmes de tous.

Seulement, et cela dépend de Jack, je ne vais pas continuer dans cette voie si Jack accepte d'intégrer cette fonctionnalité dans Panoramic. Il y a quand-même plus passionnant à faire que de réécrire des fonctions existantes de Panoramic. Mais j'espère bien que Jack réalisera des commandes du type de celles indiquées dans mon post précédent, car je pense que c'est dans la droite ligne de la philosophie de Panoramic - avoir un usage "panoramique", pour tous types de programmes et programmeurs. C'est bien pour ça que les univers 2d et 3d existent - pour ceux qui s'intéressent au jeu, mais pas seulement, mais aussi des instructions qui servent à des application différentes (gestion, contrôle du système, documentation,...) et mon intérêt personnel se trouve plutôt là. J'espère donc que Jack maintiendra cette volonté d'ouvrir Panoramic panoramiquement...

Je suis désolé que tu penses qu'il s'agit d'une mauvaise concurrence.
J'étais certain qu'en ouvrant la voie sur un principe de codage, et qu'on constatant que cela pouvait apporter de nouvelles possibilités en basic, l'idée pouvait allait être reprise d'une manière ou une autre.

J'en étais certain. Je m'interdis de faire un blocage d'idée, seulement: tu es beaucoup plus disponible que moi, tu attends comme moi des améliorations à Panoramic, et comme moi tu sais que Jack a une limite dans ses possibilités. Tu as un forum. De temps en temps je me dis qu'il faudrait que je me lance, mais honnêtement cela ne m'intéresse pas, et cela m'oblige à une contrainte supplémentaire, et ça c'est problème. Quant tu te lances dans quelque chose, tu vas plus loin que moi, et là vu mes méthodes de travail, je ne peux pas te battre.

Ensuite, le développement de fonctions continues, demande une continuité sur un principe, et je vois mal si plusieurs principes s'opposent comment les concilier.
Regarde: je retire les dims (les labels je l'ai déporté dans le temps), pour les remettre une fois le programme reconstruit. Si toi aussi tu fais la même chose, cela devient ridicule de faire deux fois le même travail. Ensuite si je faire un préprocesseur pour relire les lignes du programme, et que toi aussi tu le fais de ton côté, je me pose la question pour l'association des deux. Pour ce qui est des includes, tu connais une solution, et elle n'est pas compliquée, c'est celle que j'utilise, donc je de côté là il n'y a pas de soucis.

J'ai commencé le principe, mais tu as dis ceci entre autre:

Citation :

Mais je me pose tout-de-même une question. C'est quand-même la cavalerie lourde que de faire un pré-processeur pour pouvoir exécuter un programme Panoramic.

Donc j'ai ouvert la voie, en pensant que je serais vite rattrapé.

Je pense que pour faire des fonctions continu, il faut un site, ou alors une rubrique à part. Donc n'est pas peur, fonces et ne t'occupes pas de moi. Cela dit je regarde qu'en même pour améliorer mes fonctions, et je les mettrais tout de même sur le forum. Mais si tu prends la relève avec un autre principe, les fonctions générés avant seront caduc à la sortie de ton programme, ou alors si tu sais comment tu vas procéder, comment je dois présenter de mon côté pour que cela s'intègre. Et puis, qui dit qu'il n'y a pas quelqu'un d'autre sur cette idée?

J'avoue qu'on est un peu loin de OGG, m'en excuse pour l'auteur.

On est en effet très loin du titre "musique en OGG".
Je disais seulement à The Gamer que c'était théoriquement possible, mais que cela nécessitait à l'utilisation plusieurs DLL à distribuer.

C'est la demande d'une seule personne parmi des quantités d'autres demandes. Toutes les demandes ont un intérêt pour moi car je voudrais que PANORAMIC soit utilisé dans un grand nombre de domaines.
Cependant, je pense que le développement de sous-programmes avec des passages de paramètres, les fonctions et l'utilisation de variables locales est une priorité car c'est une grosse lacune.
Alors pour répondre à Karl: oui, je vais bientôt coder:
- les fonctions définies par l'utilisateur,
- l'appel de sous-programmes avec passage de paramètres,
- les variables locales.

Je termine d'abord ce qui est en cours:
- l'objet système CONTAINER qui, comme son nom l'indique peut contenir d'autre objets et possède un caption.
- l'objet système IMAGE qui permet de faire une saisie d'écran, de l'enregistrer dans un fichier, ou de recopier une image sur l'écran, et de s'en servir comme texture d'un SPRITE ou d'un OBJET 3D.
- OFF_CLOSE pour rimer avec OFF_CLICK, OFF_CHANGE, OFF_KEY_UP et OFF_KEY_DOWN.

Puis je code les variables locales, les fonctions définies par l'utilisateur et l'appel de procédure avec passage de paramètres.

Ouah, ça, c'est ce que j'appelle "une réponse qui donne de l'espor" ! Super ! Maintenant, on sait où on va sur le moyen et lon terme, et les fonctions annoncée pour le plus proche sont toutes utiles et intéressantes ! Merci, Jack, pour ces précisions, et pardon si tu as eu l'impression que je te bousculais. Ce n'était certes pas mon intention.

Ça vaut rien que je mette un drapeau. Maintenant il n'y a plus que des endormies.

Oui vive jack

Sinon pour en revenir à l'OGG, comme le mp3 est plus répandu, pourquoi panoramic ne gèrerait-il pas que le MP3 ?
Cela ne sert à rien à mon humble avis de gérer la plupart des formats, vu qu'un utilisateur peut toujours convertir un fichier ogg (par exemple) en mp3 grace aux nombreux utilitaires gratuits du net.

le but du format ogg était de rendre les logiciels moins lourds a diffuser mais la réponse de jack m'a convaincu que cela n'est finalement pas une si bonne affaire (en plus, je ne connais rien aux fichiers .dll ).

Cependant, je pense que de nouvelles fonctions au niveau du son seraient les biens venues comme mettre une lecture en pause ou encore arrêter un son (ont peut le faire en employant la commande file_load mais je trouve cette dernière est peu adaptée pour le jeu que je développe et elle contribue beaucoup a son ralentissement)

tres tres long PS important:

Mon jeu Exo-traquer marchait très bien lorsque je l'ai présenté il y a longtemps mais en fait je me suis aperçut que s'il ne marchait pas avec les autres membres du forum c'était a cause de la complexité de l'algorithme (le fait qu'il ne soit pas bien structuré du tout) qu'il ne tournait pas sur les autres ordinateurs (voir sujet ICI).
En fait, le problème vient que je l'ai développé sur un ordinateur cadencé a 2*3.6GHz et qu'il pouvait facilement exécuter mon programme contrairement a la majorité des ordinateurs que j'ai chez moi qui font environ 3 Ghz. Je me suis donc mis tout de suite a simplifier mon algorithme (et j'y travaille encore) et aujourd'hui je parvient a exécuter 10 sec mon jeu sur un ordi a 3GHz avant le plantage du jeu. C'est pour cela que la version actuelle d'exo traquer tarde a sortir. MAIS LES VACANCES DE NOËL TOMBENT A PIC POUR GEEKER UN PEU PLUS


je reprend l'image si sa ne vous dérange pas :

Citation :

oui, je vais bientôt coder:
- les fonctions définies par l'utilisateur,
- l'appel de sous-programmes avec passage de paramètres,
- les variables locales.

alors ça, ce sera un grand pas pour Panoramic !

Le drapeau, c'est un concurrent de l'Union Jack ?

En tous cas, il y a bien une union pour jack

Par contre il y a les fichier MIDI (*.mid) que Panoramic prend en charge...

Ils ne prennent pas beaucoup de place et puis une musique de 5 minutes est d'environ 60 Ko.