Bitmaps sous TIGCC - Page 2

mais comment font les gens pour les gros projets? link statique + compression, c'est ça?

oui

Si tu as un probleme pour lancer SMA sur V200, n'hesites pas en parler la :
sections/184-28-sos-t3-jeux-fr

à Martial: la doc sur le mode kernel c'est sur le site de T3, c'est bien ça?, je pense que oui... je fouine....

AMS ça veut dire quoi au juste? Contrairement à un grand nombre de personne et comme tout bon technicien qui se respecte, je n'aime pas utiliser des acronymes dont je ne connais pas le sens

Si je comprends bien, il y a 2 types de programmation qui s'opposent: kernel et "AMS" native. Tous deux sont bons.
Ma cible pour BubbleBobble sera la v200 et la 89T (j'en achèterais une quand j'aurais du blé, un jour à la fois). Donc, pour ces 2 machines, je dois éviter le mode kernel si je comprends bien? pardonnez mon objectivité

Quels sont vos conseils d'experts avisés pour mon projet en tant que tout petit scarabée TI? J'ai tout à réapprendre

boulifb :
Donc, pour ces 2 machines, je dois éviter le mode kernel si je comprends bien?

Tu es libre de programmer en mode kernel ou nostub

AMS = Advanced Mathematics Software , c'est l'OS de la TI (actuellement version 3.01)

tu peux tout à fait utiliser le mode kernel, il n'y a pas de raison
les deux modes ont leurs avantages, souvent je programme en nostub mais j'aime bien programmer en kernel, certaines fonctionnalités sont très agréables à utiliser.
par contre, évite de cibler uniquement V200 et 89T, il y a d'autres calc http://ti-fr.com/?act=66&art=8

commence par quelques programmes simples pour t'habituer à al programmation (C ou ASM ?), mais sinon j'ia pas trop d'idées de conseils

Doc Kernel: Telecharges preos 1.0.2 version developpeur.
AMS: Advanced Mathematics Software. Nom de l'OS de texas instruments pour les calcs TI. Un autre OS tourne aussi sur TI (PedroM).

>Donc, pour ces 2 machines, je dois éviter le mode kernel si je comprends bien? pardonnez mon objectivité
Pourquoi ? Ca marche tres bien sur ces machines ? Au contraire les programmes en mode kernel n'ont eu besoin d'aucun
changement pour fonctionner sur ces machines (grace a la couche d'emulation).

Au pasage, si tu crois Kevin Kofler, il te dira que le kernel c'est le mal, et te donneras tout un tas
d'arguments a l'aparence tres convaincante (En gros, il oublie tout ce qui le gene dans son
argumentation).

>Quels sont vos conseils d'experts avisés pour mon projet en tant que tout petit scarabée TI? J'ai tout à réapprendre
Familiarise toi avec la plateforme.
Sinon tu preferes des infos hardwares ou graphiques ?
Tu peux lire la doc de genlib: technic/archives/Doc/genlib.html
qui offres pas mal d'infos.
Tu peux aussi voir Grib et le TileMap Engine de sasume ( http://perso.wanadoo.fr/jackiechan68k/ )

J'aimerais bien savoir où trouver des infos sur l'algorithmique des jeux 2D à l'ancienne. Comme beaucoup d'entre-vous s'y connaissent, peut-être que vous pouvez me guider?

#31, #32: certes, mais ça fonctionne très bien.

#33: peut-être plus pour longtemps...

#36: en effet, les différences entre 89/89T et 92+/V200 sont inexistantes pour la plupart des programmes.
Faire des programmes compatibles on-calc entre tous ces modèles est un autre débat: ça embête un poil moins l'utilisateur (mais toutes les calculettes sont maintenant vendues avec des links, cela nuance cet argument), mais ça donne du code plus gros / beaucoup plus gros (lire: ~55 KB estimés au lieu de ~45 KB sur TI-Chess; ça double la taille de Matches, XtraKeys). Ce qui est le plus inefficace en compatibilité on-calc, ce sont les tests de touches à bas niveau (keytest/_rowread).

#37: s'il ne va pas sur un endroit où est Kevin, il va avoir du mal à le croire...

précise quels algo tu aimerais connaître.

Quelques exemples:
Shooters (vertical scrollers): Phoenix / Phoenix Platinum, Venus, Krypton I.
Platform games (sidescrollers): Duke68k.
Autres: ExciteBike 68k, Ice Hockey 68k.

Il y a eu une discussion dans la partie Software qui contient une liste intéressante des meilleurs programmes.

Lionel Debroux :
Faire des programmes compatibles on-calc entre tous ces modèles est un autre débat: ça embête un poil moins l'utilisateur (mais toutes les calculettes sont maintenant vendues avec des links, cela nuance cet argument), mais ça donne du code plus gros / beaucoup plus gros (lire: ~55 KB estimés au lieu de ~45 KB sur TI-Chess; ça double la taille de Matches, XtraKeys). Ce qui est le plus inefficace en compatibilité on-calc, ce sont les tests de touches à bas niveau (keytest/_rowread).

ça dépend des programmes, et Xtrakeys est vraiment un mauvais exemple, codé avec les pieds. C'est simple de faire un programme qui soit 3 fois plus petit et qui marche sur toutes les calcs

Oue. Mais tout ce que j'ai fait, je l'ai fait en asm 68k.

En gros, l'algorithmique est simple:
1. la map est constituee de deux cartes : une pour les decors (voir 2 ou plus - cf SMA), et une pour les collisions (pour detecter la nature et agir en consequence : mur, pente, courbe, pic, vie, ennemie a faire apparaitre, etc).
2. Tu te deplaces sur la map : ton perso agit en interaction avec la carte des collisions.
3. En se deplacant sur la map, la bordure de la map fait apparaitre de nouveaux ennemis, que l'on rajoute dans la liste des ennemis courants.
4. On trouve tous les ennemis (deplacement, ia + collision avec le decore et le perso principal). La collision se fait general a l'aide de rectangle englobant. On verifie egalement si l'ennemi n'est pas trop loin du personnage, et dans ce cas, on l'enleve de la liste.

Je ne sais pas si c'est utile ce que j'ai dit.

Bien sûr que ça dépend des programmes. Mais vu les targets qu'il donne, il aura déjà LCD_WIDTH / LCD_HEIGHT un peu partout, qui sont moyennement inefficaces en compatible on-calc. S'il utilise les tests de touches à bas niveau, alors là... Voir ce qui arrive à Ice Hockey 68k (plusieurs KB) par simple décochage d'un type de modèle, sans même supprimer les tableaux de chaînes, fussent-ils optimisés, qui diffèrent entre les modèles.
Un autre exemple flagrant de programme codé n'importe comment par Kevin est l'horrible - mais fort heureusement inutile, non seulement parce qu'on ne désinstalle habituellement pas h220xTSR, mais aussi parce qu'HW2/3Patch étant plus puissant, il faudrait l'utiliser à la place - unin2tsr. Il n'y a aucune chance que GTC fasse aussi mauvais (sauf en compilation sans optimisation, évidemment, mais tout compilateur ferait pareil), puisque la pessimization relève d'une CSE assez élémentaire. Pourtant, GTC -> poubelle

à jfp: je cherche des algos de pour le projet BubbleBobble. Un jeu de plateforme. Il utilise visiblement des algos de tracking (les enemies vont vers le joueur), les mouvements (saut etc.).
Après analyse des sprites, il semble que pour les bulles (par exemple) ils n'ont mit que la moitié du voire le quart du sprite et ils flippent les mosaïques (logique)

à pphd: j'avais en tête d'utiliser une map qui décrit le décor complet et d'utiliser des surfaces pour différentes utilisations:
- une surface qui pointe sur l'écran et qui affiche partiellement la map (donc scrolling) et les scores
- une surface pour la map,
- une surface qui gère le status du jeu (vie, score etc).

les sprites sont affichés directement sur la surface qui pointe sur l'écran.
Ce que tu as dit n'est pas inutile. comme j'ai déjà indiqué je ne m'y connais pas ne programmation de jeux 2D comme au bon vieux temps

une boucle prcipale gère l'affichage du tout (scrolling etc.), le changement des coordonnées de chacun des sprites et des collisions.

c'est en gros ce que j'ai en tête...

> Après analyse des sprites, il semble que pour les bulles (par exemple) ils n'ont mit que la moitié du voire le quart du sprite et ils flippent les mosaïques (logique)
Logique, mais assez inefficace, surtout si les bulles ne font pas 16x16 ou 32x32...

ah? et pour quoi ça?

Après analyse des sprites, il semble que pour les bulles (par exemple) ils n'ont mit que la moitié du voire le quart du sprite et ils flippent les mosaïques (logique)

Logique, et efficace de maniere materielle. Mais de maniere soft (comme sur ti), il faut mieux eviter.
Car le flipping de tiles a un coup non nul.

les mouvements (saut etc.).

Tu geres les positions X, Y et VitesseX et VitesseY en fixed 16:16.
Tu geres la gravite (a regler): A chaque fois tu fais un Vy+= gravity
sauf s'il est sur une surface stable.
Le saut, c'est Vy=-MACHIN
LE rebond, c'est Vy = abs(Vy) < 1 ? 0 else -Vy*2/3

algos de tracking (les enemies vont vers le joueur)

Y'at-til des obstacles ?

Qu'appelles-tu surface ?

Une bulle 16x16 / 32x32 veut dire un quart de bulle 8x8 / 16x16, et c'est facile de faire des opérations sur des opérandes de 8, 16 ou 32 bits, puisque ce sont des instructions du processeur. On peut flipper bit à bit, sans LUT, et là, c'est cher en temps. Si on met une LUT, c'est plus rapide, mais c'est cher en place, d'autant plus qu'elle est grosse. ExtGraph utilise un compromis: LUT d'éléments de 4 bits.
Des bulles 8x8 aussi seraient faciles à faire à partir d'un quart de bulle.

A noter qu'afficher un sprite 16x16 ne coute que 2x le temps d'afficher un sprite 8x8.

#50: si les routines utilisent le même algorithme, oui. Ce n'est plus le cas dans ExtGraph, mais la différence est quand même relativement faible (+~10% vitesse sur 8 ou 9 shiftings sur 16).
[EDIT2: edit cross avec #52]

Je sais. Mais c'est plus 2x que 4x.

#53: ça. on copie les tiles dans une sorte de buffer comme les surfaces sous DirectDraw, c'est pareil...

Faire une surface pour la map est deconseille si la map est grosse (ie plus de 2x en horizontal et vertical le buffer de l'ecran).
Un "Plane" est plus adapte (Cf doc de genlib ou TileMap Engine).

La surface qui affiche sur l'ecran s'appelle un DScreen sous genlib.
La surface qui affiche les scores s'appelle un Window sous genlib (mais c'est monochrome).

ok, je vais étudier tout cela.... ça va prendre du temps

je vois que les 2 librairies sont fortement dédiées aux jeux