PolySnd - Page 6

geogeo
a écrit : N'hésitez pas à me dire ce qui serait le mieux.

Euh... Franchement j'hésite parce qu'on va encore m'accuser de relancer une flamewar.
Mais puisque tu me le demandes: je pense que le mieux est de garder la version statique qui est compatible avec tous les programmes, _nostub ou kernel, et de laisser tomber la version dynamique.

Kernel: -Librairie indispensable pour le developpement de programme ou musqiues en kernel

Et librairie qui sera utilisée par très peu de programmeurs, la plupart optant pour la version statique qui est plus pratique.

-Gain de place en mémoire importante soit 2000 octets, en effet besoin de passer par PolySnd

Donc perte de place en total, une fois les comptes effectués.

-Utilisation je pense plus facile surtout en ASM.

Je ne pense pas.

-Peut exister des problèmes d'iincompatibilités entre les anciennes et futurs versions.

En effet.

Nostub: -Facilitée de programmation en C et ASM.

Oui.

-Intégration dans un jeux ou autre programme donc possibilitée de manier les fonctions de la librairies en fonction de ses besoins.

Oui.

-Perte en mémoire selon les fonctions utilisées...

Non. Aucune perte par rapport à la version dynamique, et gain selon les fonctions inutilisées.

-Aucun problèmes d'incompatibilté puisque la librairie est intégrée.

Oui.

Uther Lightbringer
a écrit : pour les problèmes d'incompatibilité il ne devrais pas y en avoir avec Preos si tu as défini des numéros de version

Les numéros de version ne peuvent que réduire légèrement le risque de problèmes. Ils ne peuvent pas du tout l'éliminer. Ce n'est qu'un workaround pour une erreur fatale de design (erreur qui est de partager le même exemplaire du code entre plusieurs programmes).

nEUrOne
a écrit : geageo: l'asm kernel est plus 'facile' à programmer que l'asm nostub ... y'a pas de libs pour le nostub .. que les ROM_CALLS pis des archives ...

Les archives sont des librairies (statiques). Et le kernel n'est pas du tout plus facile que le _nostub quel que soit le langage de programmation utilisé (C ou assembleur). L'absence des librairies dynamiques n'est pas plus un désavantage en assembleur qu'il ne l'est en C, et donc il n'en est pas un: les programmeurs C s'en passent très bien.

geogeo a écrit :
Est-ce que je pourrais avoir un exemple de librairie Nostub en ASM? Je sais que j'en demande beaucoup mais je n'est jamais fait de libaririe Nostub en ASM, là je parle de librairie Dynamique car en statique je sais comment faire.
Merci d'avance.

S'il te plaît, laisse tomber cette idée. Le code de chargement prendra à lui seul presque autant de place que PolySnd lui-même (au moins 1 KO, donc au moins 50% de la taille de la librairie). La librairie dynamique ne convient donc pas du tout, mais vraiment pas du tout.

KK: ne me dis pas que la programmation en asm kernel sans tigcc n'est pas très simple, avec toutes les libs existantes ... le panard pour les kernelleux !

Pour le nostub et le kernel en statique je ne vais pas hésiter mais pour une version dynamique je ne suis pas d'accord avec toi Kevin car pour les programmeur, elle sera très peu utilisé mais je pense quand même indispensable c'est pourquoi je ferait une version dynamique.

J'ai encore un petit problème et là je me tourne vers les programmeur de jeux. En effet le mode permettant de jouer de musiques en niveaux de gris avec des actions derrière et très limité je trouve car il y a peu de notes surtout dans la gamme des aigues.

http://perso.wanadoo.fr/tisofts/polysnd/polysnd2/polysnd2.9xz
http://perso.wanadoo.fr/tisofts/polysnd/polysnd2/test.9xz

Malheuresement je n'ai pas pu tester sur une HW1, si quelqu'un pourrais tester et me dire ce que ça donne et pourquoi pas enregistrer le son cela me permetterais d'avancer beaucoup.

A savoir que ça ne fonctionne pas sur VTI car il est assez ancien e emule mal l'hardware.


Je propose de créer 2 modes pour jouer du son:

Mode 1:
-Son de basse qualité car 50 notes
-Possibilitée de jouer en tâche de fond
-Incorporation des niveaux de gris
-Int5 à 8Khz
-Envoye des informations en permanence sur la musiques...

Mode 2:
-Son haute qualité car plus de 4000 notes
-Impossible de jouer du son en tâche de fond
-Peut être utilisable avec des niveaux de gris
-Peut être besin d'utiliser l'int5
-Impossible de récuper des informations

Le mode1 je pense sera surtout utiliser dans le jeu lui même en background, par contre le mode2 utilisé dans les écran fixe donc les écrans d'accueil...

nEUrOne a écrit :
KK: ne me dis pas que la programmation en asm kernel sans tigcc n'est pas très simple, avec toutes les libs existantes ... le panard pour les kernelleux !

Pas plus simple que la programmation en assembleur _nostub avec TIGCCLIB. Et la programmation sans TIGCC est obsolète.

Je viens de finir la librairie, j'ai tout programmé donc il me reste encore à faire le header en C. Mais j'hésite beaucoup pour incorporer 2 modes? Donnez moi votre avis a fin de voir si c'est vraiment utile.

Je voudrais savoir aussi comment créer un prototype correcte en C d'une fonction en ASM qui entre des valeurs via la pile et qui sort une adresse via a0 ou un nombre via d0?

Je sais que je demande des choses assez simple mais la doc de TIGCC est un peu flou sur ce sujet et donc je voudrais faire ça de façon optimale.

geogeo
a écrit : Je voudrais savoir aussi comment créer un prototype correcte en C d'une fonction en ASM qui entre des valeurs via la pile et qui sort une adresse via a0 ou un nombre via d0?

La valeur de retour est de toute façon dans a0 pour une adresse ou dans d0 pour un nombre, donc il n'y a rien de particulier à déclarer pour signaler cela. Pour les paramètres qui sont passés sur la pile, c'est le standard, mais pour permettre aux utilisateurs de ta librairie de compiler leurs programmes avec l'option -mregparm, tu dois préciser __attribute__((stkparm)) dans tes prototypes.

Merci beaucoup Kevin.

Voilà j'ai un problème avec les fonctions qui sorte une valeurs via d0, la valeurs retournée est fausse en C!!!

Pour déclarer la fonction je fait ceci:
extern unsigned short GetTempo (void);
asm ("GetTempo:
jsr polysnd2__0009
rts");

Et je l'affcihe tout simplement avec printf_xy (0,0,"%d", GetTempo());

A savoir que lorsque je programme en ASM la valeur retournée est correcte.

C'est %u qu'il faut mettre pour afficher un unsigned short, pas %d. Et puis ton code est affreux! Mets:

#define GetTempo polysnd2__0009
extern unsigned short GetTempo (void);

Ah en effet c'est mieux comme ça.

Je sort les grandes questions: Que pensez vous du son sur les TI? Voyez vous une grande utilitée? Est-ce que vous aurez envie d'inclure du son dans un de vos programme? Quelles serait pour vous les logiciels utile incorporant du son? Trouvez vous utile une librairie de son?

Merci de bien vouloir répondre à ses questions car je me demande de plus en plus l'intêret de développer une librairie dont personne n'utilisera.

Pour moi le son est vraiment secondaire vu la qualité et le fait qu'on ne peut l'utiliser sans un bidouillage, que ce n'est pas prévu au départ par la TI et qu'il n'y a pas de standard qui se démarque vraiment.
Ceci dit polysound me parait sur la bonne voie pour améliorer ca, s'il est vraiment efficace j'inclurai du son dans mon prochain jeu, en option bien sur pour ne pas alourdir pour ceux qui n'ont pas d'écouteur.

même r^éponse, en gros.

> La programmation sans TIGCC est obsolète.
En effet. Il n'existe aucun compilateur / assembleur potable autre que GCC de TIGCC, A68k et as de TIGCC.

geogeo: même réponse, en gros. Sauf que je n'ai pas de jeux où je mettrai de la musique...

même chose à priori, si je fais un jeux, et que ta lib est au point, pkoi ne pas ajouter un peu de son

XDanger> a68k a été intégré à tigcc mais existait bien avant...

Pour moi le son n'est pas indispensable non plus... à la limite j'attend de voir ce que peut donner un jeu avec le son pour me faire une idée

Merci pour toute ses informations mais j'aurais préférer plus de reactions.
Ne croyait pas que le son ralentie les jeux de façon significatif ce sera de l'ordre de 5 fps max. Pour la qualitée, elle est plus qu'acceptable en plus sur 2 voies.

Je me lance dans un programme de demonstration de son et je veut en faire un jeux mais simple.



Je sais ce n'ai pas au point de vue des graphisme mais je voudrais en faire un jeux autre qu'un casse brique, à savoir que je veut qu'il représente du son dans un jeux. Quel type de jeux me conseilleriez vous?

un tit shoot tout simple, ac des sons pour les explosions, tir des différentes armes, musique de fond etc ... ce serait l'idéal ^^

Non je ne veut pas changer le principe qui est au dessus avec la bille mais l'adapter pour en faire un jeu.

un casse brique, c assez simple à coder, et ça peut utiliser le son pr les colisions, et autres...

Dans ce cas alors je vais mis mettre mais pour un casse brique il faut que je créer un matrice pour gérer les collsions et de préférence de quelle taille seront les brique car la bille est assez grosse donc pas des briques trop petites.

bah en longueur à peu près la taille du truc qui fait rebondir (dsl je sais pas comment appeller ça ^^ )

Oui la barre qui ai en bas! Je pense faire des brique de 16x8? et donc parfait pour les collision avec la bille. Mais pour gérer les brqiue je pense faire des niveaux avec des octets qui repréente la brique et ainsi pouvoir savoir ou elles se trouve. Désolé mais c'est la première fois que je fait un jeux et donc je ne sais pas si c'est la meilleurs méthode?

pour les briques et autre, ça dépend de pas mal de choses...
vitesse de la balle
taille de la balle
taille de la raquette
power-ups ?
quantité de briques
...

Ximoon
a écrit : XDanger> a68k a été intégré à tigcc mais existait bien avant...

Oui, mais les versions antérieures à l'intégration à TIGCC sont toutes boguées. Regarde les changements entre 2.71.F2 (dernière version disponible en binaire séparément) et 2.71.F3i (la version livrée avec TIGCC 0.94 SP4).

Bah j'ai toujours utilisé la 0.71.f2 et je n'ai pas vraiment à m'en plaindre. Je ne crache pas sur tout le travail que tu as fait dessus, mais je tenais juste à souligner l'inexactitude partisane du post de XDanger

Pour sauvegarder les zones ou ce trouve les briques, comment je dois procéder? Dois-je créer une matrice qui sauvegarderas chaque zones de chaque brique et quand une brique à était touché, je met la zone?

par exemple

il existe plusieurs solutions, surement...
matrice de briques, liste chainée de balles (enfin, sur TI...)
et après, tu peux rajouter des petis monstres volants, ...

Je vais pensé à tout ça. Alors ça vous tente un jeux de casse brique avec du son?
Pour la gestion de collision de brique j'ai pensé à une matrice de brique. A oui est-ce que les float c'est vraiment très très lent?

Pour la bille je vais la diminuer et la barre serat paramètrable via des powers up...
Je viens de rajouter en 1 heures, la gestion de vie et de niveaux que j'affiche...

Par contre ce qui me chagrine c'est que ça fait 12 ko déjà mais ya le fond qui fait du 4ko donc...

Mais pour vous c'est interessant un jeux de brique comme ça ou ça à était déjà fait et pour la taille c'est beaucoup trop pour l'instant? A savoir que j'hésite à le mettre en nostub ou kernel, vous en pensez quoi?

_nostub évidemment. Le kernel n'apporte strictement rien, et c'est un style de programmation dépassé.