Un autre petit nouveau :) - Page 1

Bonjour tout le monde,
Je suis un ptit nouveau dans la programmation sur Ti.

Je possède une Ti92+ depuis bientot plus d'un an, et après avoir été impressioné par les performances de Sonic ou autre Fat, je me suis décidé à programmer sur ma ti
J'ai donc télécharger le kit TIGCC avec l'IDE* et fais quelques tests.

J'ai lus quelques tuts sur la gestion des graphismes, mais j'ai toujours quelques pb ...
Principalement des scintillements, donc j'ai testé en faisant du "double-buffering", mais j'ai l'impression que cela fait chuter les performances (je me demande toujours comment certains jeux tournent a plus de 15 fps...).
Comme je ne connais que peu de choses en ce qui concerne la programmation sur Ti (en plus, le C, c'est pas ma tasse de thé ), principalement côté graphisme, pourriez-vous me donner vos impressions, astuces techniques, expériences etc... sur le sujet ?

Le premier jeu que je voudrais programmer est un shoot'em up, non pas comme Phoenix ou Solar Striker, mais plus proche de rRootage (un excellent jeu pour pc, un truc de malade ). Donc l'aspect graphique est peu important, juste qu'il faut gérer une grosse quantités de sprites et que le jeu soit plutot rapide

*concernant l'IDE, j'ai recompilé les sources en ajoutant une petite fonctionnalité: une fenêtre de style "complétion du code", qui recense tous les symboles de l'aide de TIGCC (la liste est faites a partir des fichiers hsf), et les fonctions dans le source en cours (grace à la méthode GetFunctions, ou kkc comme ca).
De plus, la liste des paramètres de la fonction sous le curseur est affiché sous forme "d'hint" lorsque l'utilisateur appuie sur "(". Si y'en a que ca interesse...

Voila
@+, Fred

MOAAA :
Le premier jeu que je voudrais programmer est un shoot'em up, non pas comme Phoenix ou Solar Striker, mais plus proche de rRootage (un excellent jeu pour pc, un truc de malade ). Donc l'aspect graphique est peu important, juste qu'il faut gérer une grosse quantités de sprites et que le jeu soit plutot rapide

Bon, dans ce cas, je pense effectivement que le double-buffering soit une mauvaise idée. Phoenix n'en utilise pas non plus à ma connaissance. L'important pour éviter les scintillements est que le temps pendant lequel les sprites sont affichés soit nettement supérieur au temps pendant lequel ils sont effacés. Évite aussi de tout effacer à chaque fois, n'efface que ce que tu es en train de redessiner. Si tu veux tout redessiner, tu peux effacer et redessiner par morceaux plutôt que l'écran entier. Ça devrait te permettre de satisfaire l'inéquation temps de visibilité >> temps de non-visibilité.

*concernant l'IDE, j'ai recompilé les sources en ajoutant une petite fonctionnalité: une fenêtre de style "complétion du code", qui recense tous les symboles de l'aide de TIGCC (la liste est faites a partir des fichiers hsf), et les fonctions dans le source en cours (grace à la méthode GetFunctions, ou kkc comme ca). De plus, la liste des paramètres de la fonction sous le curseur est affiché sous forme "d'hint" lorsque l'utilisateur appuie sur "(". Si y'en a que ca interesse...

Oui!!! C'est excellent comme fonctionnalité!
Si tu es d'accord pour qu'on diffuse ça sous la GPL avec tout le reste, envoie un patch (c'est-à-dire soit les fichiers source que tu as modifiés ou rajoutés, soit (de préférence) un fichier de différences généré par GNU diff) à Sebastian s'il te plaît.

Bienvenue

en faisant du "double-buffering", mais j'ai l'impression que cela fait chuter les performances

Theoriquement ça ne doit pas tellement (du tout ?) se sentir. Quel est ton algo ?

pourriez-vous me donner vos impressions, astuces techniques, expériences etc... sur le sujet ?

Heu, ça n'est pas facile de répondre à une question ouverte quand elle est aussi vaste. Tu n'aurrais pas plutot des questions un peu plus ciblées ?

Le premier jeu que je voudrais programmer est un shoot'em up

cool
Tu n'as pas un screen shot de l'original (je ne connais pô )

concernant l'IDE[...]

ça me parrait TRES interessant comme fonctionnalité. Je pense que les auteurs devraient apprecier



PS : si tu ne souhaites pas trop t'attarder aux routines graphiques, le plus simple est d'utiliser des bibliotheques.
Il y en a des dynamiques et des statiques :
Genlib ( http://www.timetoteam.fr.st ),

Xlib ( http://xteam.sourceforge.net/index.php ),

Graphx ( http://alineasofts.free.fr/index.php?rubrique=Accueil ),

TinyX ( http://xteam.sourceforge.net/index.php (le meme site que pour Xlib)),

Extgraph ( http://tict.ticalc.org ).

Très bien ces libs, y'en a une préférée?
Si possible qui utilise peu de mémoire, parce que je pense en réservé une grosse partie pour le point de vue technique (mon idée est de stocker les niveaux sous formes de script. des scripts "pseudo-compiler" [du p-code koi] pour être rapide, l'interpreteur aura besoin d'une certaine quantité de ressource (mémoire et temps de calcul), parce que les niveaux sont vraiment très complexe).

Concernant le jeu original: http://www.asahi-net.or.jp/~cs8k-cyu/windows/rr_e.html :
Comme le montre le screenshot, le jeu est très riche en sprite, et l'animation impressionante (d'après ce que j'ai vu sur le site de l'auteur, il utilises des algos de génétiques pour s'occuper de tout ca Bulletsmorph, pas question de faire tourner ca sur ma ptit ti )

>Heu, ça n'est pas facile de répondre à une question ouverte quand elle est aussi vaste. Tu n'aurrais pas plutot des questions un peu plus ciblées ?
Ben comme je ne sais pas trop encore me débrouiller sur ma TI, je ne sais pas trop comment expliquer
Pour les graphismes apparement, certaines libs ont l'air de bien s'occuper de tout ca, je vais y jeter un coup d'oeil , mais après vient l'animation: comment gérer le temps, j'ai testé "surchargeant" l'interruption 5, ya d'autre méthodes ?

Pour la fenêtre de complétion du code: je vais recoder en "propre", mais sur quelles sources se baser ? Pour l'instant j'utilise celle de la 0.94, j'ai testé une fois la 0.95 mais j'ai des violation d'accès [je n'ai pris que ce que je trouvait sur le site de TIGCC].
Enfin, je ne connais pas GnuDiff (je ne connais pas "très clairement" gnu tout court aussi ), et j'utilise une unité de la jvcl (JvHtControls), pour donner une mise en forme

MOAAA
: Pour la fenêtre de complétion du code: je vais recoder en "propre", mais sur quelles sources se baser ? Pour l'instant j'utilise celle de la 0.94, j'ai testé une fois la 0.95 mais j'ai des violation d'accès [je n'ai pris que ce que je trouvait sur le site de TIGCC].

De préférence la plus récente, c'est-à-dire 0.95 bêta 4.

Enfin, je ne connais pas GnuDiff (je ne connais pas "très clairement" gnu tout court aussi ),

Il y a un portage Win32 là: http://gnuwin32.sourceforge.net/packages/diffutils.htm. (Il y en a aussi d'autres.)
L'intérêt est de pouvoir appliquer le patch automatiquement, avec GNU patch, même si des trucs ont changé ailleurs dans le fichier.

et j'utilise une unité de la jvcl (JvHtControls), pour donner une mise en forme

Bon, c'est sous licence MPL, donc c'est open-source, donc je pense qu'on peut utiliser ça (à voir avec Sebastian), mais il faudra que Sebastian mette une exception de licence pour permettre de distribuer la combinaison (parce qu'en principe la GPL et la MPL ne sont pas compatibles). Je viens de lui en parler.

Et d'ailleurs, même si c'est "sale", à mon avis, ça n'a pas vraiment d'importance tant que ça fonctionne!

C'est pas ce que tu dis à PpHd quand il fait quelque chose que tu trouves "sale", m'enfin passons

Très bien ces libs, y'en a une préférée?

en gros :
Genlib, Xlib et GraphX sont des bibliotheques graphiques qui sont vraiment faites pour la programmation de jeux. (des jeux dans le genre de ceux de la megadrive par exemple)
Genlib et Xlib sont plus rapides que GraphX, mais GraphX est moins gourmande en memoire.
Tinyx, c'est Xlib mais qui n'utilise pas trop de memoire, je crois.
Extgraph, c'est plus en ensemble de fonctions graphiques réunies dans une bibliotheque statique (mais il parait que la version 2 n'est pas mal (pas encore sortie je crois))

Tinyx est une lib pour afficher du texte il me semble.
ExtGraph 2 est légèrement plus rapide que la dernière version releasée (1.02), légèrement moins rapide que les autres lib, mais moins gourmande en mémoire, les fonctions de la version 2 sont dispos ici : http://pub26.ezboard.com/ftichessteamhqfrm13.showMessage?topicID=445.topic

[PUB]
Et une librairie de son existe aussi.
http://perso.wanadoo.fr/tisofts

Et oui on parle beaucoups des librairies graphique mais pas de librairie de son.
[/PUB]

TinyX est une lib faite pour les apps qui demandent des affichages rapides ou alors des petits jeux sympa... elle est pas trop gourmande enfin, on peut pas non plus faire un truc assez rapide et qui bouffe pas de ram ... enfin vala (pis TinyX doit se télécharger sur mon site pke je sais mm pas quelle version est sur le site xteam ... deja que csur mon site )

Pour faire un jeu comme ca, je te conseillerai GenLib ou XLib (surtotu si tu comptes faire un jeu assez complet avec pas mal d'anim etc.)
Le problème avec XLib c'est que c'est mort ! C'est dommage ... si tu veux voir une petite démo de shoot*** cherche XShipper fait avec XLib le code doit etre dispo normalement...

Bref, je te conseille GenLib en programmant kernel

J'ai cherché tinylib, mais je tombe que sur des 404, tu peux corriger ca ?

Moi, je te conseille ExtGraph 2. Une prerelease est disponible là: http://pub26.ezboard.com/ftichessteamhqfrm13.showMessage?topicID=445.topic.

Moi, je te conseille GraphX ou XLib (ou encore Genlib, mais elle ne fait pas vraiment dans la légèreté). ExtGraph peut être utile, mais l'intérêt d'ExtGraph c'est que tu peux te contenter d'utiliser une seule routine d'ExtGraph dans ton projet si tu en as besoin et que les autres libs ne le font pas, donc fait plutôt ton projet principalement avec GraphX/XLib puis certaines routines d'Extgraph au besoin. C'est plus difficile d'utiliser des fonctions de GraphX si ce ne sont pas ses routines de gris à elles, alors que ExtGraph peut utiliser les routines de GraphX.

Pour le framework graphique (c'est à dire routines de niveaux de gris etc.), je te conseille de rester avec le standard: TIGCCLIB. Et ExtGraph est la seule qui s'intègre correctement avec ça, les autres t'obligent à utiliser leur framework non-standard et généralement moins flexible que TIGCCLIB. Par exemple, TIGCCLIB permet le single-buffering et le double-buffering, au choix.

ExtGraph est la seule qui s'intègre correctement avec ça, les autres t'obligent à utiliser leur framework non-standard et généralement moins flexible que TIGCCLIB

Comprendre : avec les routines de gray de TIGCCLIB, tu seras forcé d'utiliser ExtGraph.

Les formats des autres routines de grays permettent souvent des gains de vitesse, tout en restant compatible avec ExtGraph.

j'ai regardé extgraph, dans mon cas c'est suffisant...
mais, quand je programme sur mon pc, si le code est pas optimisé en terme de vitesse, a moins que la fonction soit executée 500000x en boucle, et encore, ca n'as pas trop d'importance, un pc est tellement rapide
mais est-ce que sur la ti, grapiller le moindre temps sur un tout pitit calcul est important ?
quand j'ai lu qu'elle avait un processeur 68k comme la megadrive(je suis à l'ouest ? ), je me disais que ca devait pas poser de probleme, mais à l'utilisation, on remarque que ca "gère" pas tout [et la je me suis dis, la megadrive, ya tout une flopée de chipset qui l'allège des calculs ^^]

Pour l'histoire de l'IDE:
* Sebastian a confirmé que le composant JVCL sous licence MPL n'est pas un problème.
* Ça serait bien si ton truc était prêt à temps pour TIGCC 0.95 final, donc le plus vite possible.
* Pour le passage de TIGCC 0.94 à 0.95, avec GNU diff (http://gnuwin32.sourceforge.net/packages/diffutils.htm) et GNU patch (http://gnuwin32.sourceforge.net/packages/patch.htm), ça ne devrait pas être un problème. Tu fais un diff de tes modifications par rapport à TIGCC 0.94, tu patches la bêta 0.95 avec ça et tu corriges les "rejects" (ou si tu n'y arrives pas, tu nous envoies le diff par rapport à la 0.94 et on s'en occupe pour toi).

MOAAA
: mais est-ce que sur la ti, grapiller le moindre temps sur un tout pitit calcul est important ?

Ça dépend: si c'est un calcul que tu effectues une fois, non. Si c'est un calcul que tu effectues dans une boucle exécutée 100 fois, peut-être. Si c'est un calcul que tu effectues des milliers de fois par seconde, oui!

Bref, qu'un calcul fait une seule fois par frame soit lent, ça passe. Dans une routine de sprites, ça commence à devenir critique. Si c'est un calcul long pour chaque pixel, ça ne passe carrément plus!

Mais n'oublie pas que sur une calculatrice, la taille du code est aussi très critique (et TIGCC IDE active par défaut l'optimisation en taille, pas en vitesse). Une perte de quelques octets peut déjà faire que ton jeu ne tient plus dans une mémoire archive qui contient aussi d'autres fichiers, par exemple. Et un code plus petit signifie aussi un temps de décompression/chargement plus court. (Cela est valable aussi sur PC, d'ailleurs.)