Mode 7 sur TI! - Page 2

Ce n'est pas toutes les lignes qui sont à 1/2, mais celles les plus près:

les lignes du bas font deux pixels d'épaisseur. C'est la démo la plus récente que j'aie, mais ce n'est pas la première fois que Nerick en a une plus récente que moi...

Et donc, je ne sais pas s'il a changé de tactique depuis...

PS: Double-K, il utilise le mode Kernel depuis le temps où les gris n'étaient pas certains, il préférait les laisser aux libs... De plus, aux dernières nouvelles, il n'utilisait pas TI-GCC, mais toujours notepad et A68k, donc il ne pouvait pas trop utiliser les gris de TIGCCLIB...
Tu me diras peut-être qu'il est dépassé mais c'est un vrai programmeur Asm...

Pen^2
:

Link
: la démo la plus récente était un programme Kernel

ahhhh !!! c'est un bon gars.

Link :
PS: Double-K, il utilise le mode Kernel depuis le temps où les gris n'étaient pas certains, il préférait les laisser aux libs...

Ces temps sont passés, donc il peut rechanger maintenant, au lieu de rester avec ce mode obsolète.

De plus, aux dernières nouvelles, il n'utilisait pas TI-GCC, mais toujours notepad et A68k,

Arrrgh!!!
Pourquoi pas utiliser TIGCC IDE?
Et vu qu'il n'utilise pas TIGCC, je suis presque sûr qu'il a aussi une version préhistorique et boguée de A68k, et absolument sûr qu'il a un linker totalement préhistorique. Je ne comprends pas pourquoi il y en a qui travaillent volontairement avec des outils dépassés et bogués!

donc il ne pouvait pas trop utiliser les gris de TIGCCLIB...

On peut très bien les utiliser en assembleur, il suffit de télécharger TIGCC! Je ne vois pas le problème.

Tu me diras peut-être qu'il est dépassé

Ben, évidemment! Je le dis parce qu'il l'est!

mais c'est un vrai programmeur Asm...

On peut être un "vrai programmeur ASM" et utiliser TIGCC. L'un n'empêche pas l'autre. Les gris de TIGCCLIB sont codés en assembleur, donc ce n'est pas parce qu'on les utilise que ce n'est plus de l'assembleur à 100%. J'ai fait beaucoup de programmes 100% ASM avec TIGCC.

Donc en gros, c'est à peu près comme la demo de Pollux, non ?

Kevin> beuu eeeh hoo, pas d'attaque personnelle !

Tu es tellement prévisible que ça en devient lassant Kevin

non rien, je croyais avoir trouvé un bug.

Donc en gros, c'est à peu près comme la demo de Pollux, non ?

En plus rapide
(et aussi un peu moins beau, qd même )

il tournait à combien le tien déjà ?

10 fps.

En fait je viens de me rendre compte de l'arnaque : son moteur n'affiche qu'une colonne sur 2 ! Bref, en gros les deux moteurs doivent avoir la même vitesse (le sien reste encore légèrement plus rapide, mais il y a aussi une résolution verticale un peu moins bonne, ce qui fait que c'est grosso modo pareil).

Ca m'aurait étonné qu'il ait pu faire un moteur 3x plus rapide que le mien sans faire de pré-rotation des sprites...

l'arnaque

ah oui, en effet
Je pensais (sans avoir regardé) que l'aspect un peu trop *carré* venait de son algo de projection.
Remarque l'idée n'est pas mauvaise, ça ne rend pas trop mal quand meme (mais c'est vrai que c'est moins joli que le tien).
Le truc évidamment c'est que là on comparait des choses pas comparables

oui il y a evidemment une perte de precision par rapport au rendu qu'on obtient avec le tien, mais vu ce qu'on gagne en vitesse, ca vaut largement le coup

Bah, ouais, si vous voulez je peux tenter de modifier Formula 0 pour diviser la résolution par 4 Pour le coup ça devrait être ultra-fluide...

c'est sympa tout ca, mais moi je sais toujours pas comment faire ! Je demande pas grand chose, juste les bases, si vous faites ca en C

Si tu sais faire des rotations et du zoom, tu ne devrais pas avoir trop de pb.

En fait, quelles sont les librairies qui permettent des rotations ? (zoom, je sais qu'il y a extgraph)

aucune ou alors p-ê genlib

et je doute fortement des performances du zoom d'extgraph

Ok merci... Mais alors, vous programmez vous même vos routines d'affichage ? (pour des jeux avec le moteur mode 7)

Vark
: et je doute fortement des performances du zoom d'extgraph

Effectivement, la routine actuelle est plutôt mauvaise. J'ai réécrit une routine en C elle aussi qui est plus de 2 fois plus rapide...
Elle sera probablement intégrée à la prochaine version dextgraph, ou à une future version, parce que là on repousse tout le temps la sortie de la v2...

orage :
Ok merci... Mais alors, vous programmez vous même vos routines d'affichage ? (pour des jeux avec le moteur mode 7)

Bah tout d'abord la plupart des quelques "jeux" utilisant le mode 7 ne sont que des démos et oui, leurs auteurs ont fait eux même les moteurs

Mci et ben, respect

Pas mal le mode7 à Pollux... très bien même!
Personnellement, je suis incapable de coder une routine de rotation (même en C) qui puisse terminer un blit de 16 par 16 avant que les piles soient mortes. Ou bien ma routine d'aggrandissement... Ok elle utilisait les réels, mais bon c'était plus une routine de (lent) défilement vertical qu'une routine d'aggrandissement (^{bon j'utilisais ScrRectFill pour chaque pixel...}), alors quand je vois des moteurs du genre celui de Pollux...
Mais peut-on trouver des algos rapides sur internet, ou bien faut-il être un dieu en maths pour ça? (perso je ne trouve rien mais la recherche sur google n'est pas mon fort)

Brunni :
Pas mal le mode7 à Pollux... très bien même!
Personnellement, je suis incapable de coder une routine de rotation (même en C) qui puisse terminer un blit de 16 par 16 avant que les piles soient mortes. Ou bien ma routine d'aggrandissement... Ok elle utilisait les réels, mais bon c'était plus une routine de (lent) défilement vertical qu'une routine d'aggrandissement (^{bon j'utilisais ScrRectFill pour chaque pixel...}), alors quand je vois des moteurs du genre celui de Pollux... Mais peut-on trouver des algos rapides sur internet, ou bien faut-il être un dieu en maths pour ça? (perso je ne trouve rien mais la recherche sur google n'est pas mon fort)

c'est bizarre, j'allais poser la meme question...

Y'a de la doc sur le net, oui, mais après entre l'algo et l'implémentation...

Perso j'ai rien cherché sur le net (et j'ai dû bien faire puisque y a pas mal de gens qui m'ont demandé si j'avais pas de tuto sur le mode 7 ).

Niveau maths, ben y a pas besoin d'être un dieu, et heureusement En fait le truc qu'il faut bien comprendre c'est que tu ne pars pas d'un pixel de la source pour arriver à un pixel de la destination (comme le sous-entend Brunni avec son ScrRectFill), parce que sinon tu vas avoir des gros problèmes : ça va très certainement être tout moche parce que quand tu vas afficher ces pixels, soit il va y en avoir trop (pixels "loin" de la caméra), soit pas assez (pixels proches, et on va devoir faire un truc bizarre pour remplir correctement l'espace entre les pixels, j'ose même pas y penser ). C'est bien plus efficace de partir d'un pixel de la destination pour arriver à un pixel de la source : comme ça, tu affiches pile ce qu'il faut. Mathématiquement, ça veut juste dire (et d'ailleurs Kevin Kofler l'a expliqué des tonnes de fois) que tu prends la projection inverse puis la rotation (inverse, mais ça ça change rien) au lieu de prendre la rotation directe puis la projection directe.

Et après l'optimisation, c'est juste (comme pour toute optimisation) éliminer tous les tests/opérations/lectures/écritures redondantes, rien de bien sorcier.

partir de la source pour arriver à la destinatoin, c'est ce que j'avais essayé de faire pour un rotozoom en basic... Je te dis pas combien c'était moche... Puis Alk est venu, et en bon cousin, il m'a expliquer qu'il fallait partir de la destination pour remonter à la source...

ya un truc, que je suis pas,la. Normalement, ca s'affiche pas scanline (et ca se voit bien sur les jeux de super nintendo). Alors pourquoi travailler pixel par pixel? on prend une ligne entiere, on travaille dessus et on l'affiche! c'est quand meme moins gourmand!

faut bien calculer les pixels de la ligne nan?

Tu peux d'abord décrire l'image pixel par pixel. Et ensuite si tu regardes la tête de ce que tu dois dessiner, tu te rends compte effectivement que pleins de termes dans tes équations ne dépendent que de la ligne que tu affiches et pas de la colonne, oui.

Personne n'a parlé d'afficher pixel par pixel, hein.