PolySnd - Page 12

ça ne devrait pas...
cela dit, il fo voir le code asm produit

vous voulait que je le diffuse, je demande ça avant que l'on me critique sur le fai que je mette des sources trop longues.

heu...
de toute façon, je connais pas assez l'asm pr dire
attend donc un autre avis que le mien

je m'ai un lien internet sur mon site. A savoir que j'ai viré le décord donc on arrive à 8ko pour le jeux.

http://perso.wanadoo.fr/tisofts/polysnd/Arkanoid.s

Laisse tomber... Je n'ai pas envie de me plonger là-dedans.
Il faudrait que tu mettes la source C, le code ASM produit (avec les indications de correspondance entre les lignes de C si possible, il y a un switch qui fait ça, mais je ne sais plus lequel).
Et si possible les deux versions (celle que tu trouves lente et l'autre).

pour le switch
projet > option
il faut activer les infos de debugguage

geogeo
a écrit : Mais réellment est-ce que d'accéder à une structure comme je viens de le précisé au dessus c'est lent?

Non.


Et je ne vois pas pourquoi vous voulez absolument lui conseiller de tout réafficher, la solution qu'il utilise actuellement est meilleure. Tout réafficher est la solution de facilité. La sauvegarde du fond est beaucoup moins barbare.

Sa technique est tout sauf optimale. La la barbarie c'est de tout faire comme il le fait... Et on te rappelle que niveau programmation graphique il y a des gens qui sont peut-être beaucoup plus capables de donner des conseils que toi Kevin

clair... la technique de tout effacer est, ici, beaucoup plus rapide (pas à mettre en oeuvre, bien que ce soit vrai aussi, mais surtout à l'execution...).

Disons que ce qui est vrai pour la programmation PC ne l'est pas forcément pour la programmation TI (on n'a pas sous TI de réelle sous traitance entre le proc central et les unités périphériques - c'est le 68k qui gère tout ou presque).
Edit PC -> TI

effacer l'ecran entier a de fortes chances d'etres bcp plus rapide que d'effacer juste des petits morceaux, faire des getpsrites et autres
meme si ca fait tout redessiner.

ca a l'avantage de supprimer les bugs graphiques qui etaient present sur au moins un shot plus haut
ca permet une plus gde souplesse
et plus tu affiche de trucs en mouvement a l'ecran, plus le gain est important

Disons que ce qui est vrai pour la programmation PC ne l'est pas forcément pour la programmation PC

Ca a des avantages bien entendus de tout réafficher mais ce qui ralentie le plus dans mon cas ce n'est pas d'afficher les balles, les raquettes mais d'afiche le niveaux car ma méthode pour l'instant et de lire une matrice et chaque chiffre je fait correspondre un sprite donc il faut lire la matrice et ça prend du temps donc si il y a une autre méthode pour afficher un niveaux mais qui accélere l'affichage je suis partant!

A savoir que je ne programme pas du tout comme ça sur PC, sur PC je fait moins attention, mais ce n'ai pas le cas sur TI donc j'optimise mon code.

Ce problème de vitesse je ne pense pas qu'il vient de la façon dont j'ai fait le code mais plutôt de la méthode...

lutot qu'une matrice de numero de sprites, utile une matrice de pointeur sur tes spriteset ainsi, tu fais
spritePut(x, y, mat[i][j]);
deja, ca fait quelques instructions en moins, je suppose
(mais les pointeurs prennent 4 octets au lieu de 1 ou 2 pour les chiffres)

tu utilise quoi pr determiner le sprite par rapport au nombre ?
(il y a peut-etre moyen d'optimiser par la...)

Ximoon a écrit :
Sa technique est tout sauf optimale. La la barbarie c'est de tout faire comme il le fait... Et on te rappelle que niveau programmation graphique il y a des gens qui sont peut-être beaucoup plus capables de donner des conseils que toi Kevin

Arrête de raconter n'importe quoi! Je ne dis pas ça au hasard. Ma remarque s'appuie sur des exemples concrets. http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=79.topic. Je cite:

Scott Noveck:
[...] When background saving is convenient -- here it's easy to implement because we have so few sprites, the sprites are the same size, and they're word width so we can just grab longwords; see my original background saving routine -- it is immensely faster than copying our main buffers to intermediate buffers, drawing the ball there, and drawing the intermediate buffers to the screen. I'm a bit miffed that you took out my background-saving routine, actually; I was very proud of how well that worked :-)
[...]

TRgenius: OK, using the background save and restore, the speed is much faster :-)

S'il y a une chose que je déteste, ce sont les gens qui croient savoir plus que moi alors que ce qu'ils racontent est du n'importe quoi pur et net.

dans mon cas, tout effacer et tout redessiner etait plus rapide, pr la fois ou g compare
(cela dit j'avais pas mal e graphs...)

ds tous les cas ou il y a un minimum d'objets à afficher, tout effacer EST plus rapide...

scrolling multi-niveaux, et plein de trucs par dessus powa

Bon ..
Alors d'une part, tout reaficher n'est pas forcement plus rapide, c'est une methode utilisé pour les jeux assez poussés graphiquement.
XLib recommende fortement cette methode car comme d'autre lib elle peut se le permettre...
Il est evident que pour des routines lentes qui ne sont pas programmées pour une utilisation intensif, il faut revenir à la programmation basic qui est plus du bricolage qu'autre chose.
Reafficher a toutes les frames à des avantages... comme les annimation etc...
Et puis les methodes de bricolage, j'aimerai bien les voir avec un scrolling differentiel... le gas il doit bien s'amuser
En bref ce genre de methode peux s'employer dans le cas ou il n'y a pas de scroll differentiel, il n'y a pas d'animation, il y a peu d'objet a afficher...
Or avec la methode de tout reafficher, on atteint largement les 70 fps avec une lib comme gen ou XLib..
Donc oui cette methode est mauvaise, c'est une methode de debutant etc.

Quand a la vitesse, la methode de triple swap buffering apporte un gain qui je pense peut etre important, en ne gasopillant que 3840 octets ( vive thibeau! ).

Je ne sais pas si vous vous rappelez d'une démo que j'avais sorti (XShipper), en utilsant la méthode de redessiner a chaque fois, avec un fond d'écran et des scrolls (2 ou 3 vitesses différentes, je ne sais plus), je l'ai benché à 120fps sur v200 ...

KK, je sais que cette vitesse est inutile (je suis le premier à le reconnaître) mais ça permet de faire des animations supplémentaires etc.

pour dire que .. la methode bricolo, elle permet de gagner de la vitesse pour des petits progs, mais pour ces petits prog, avec de bonnes lib on a deja un fps plus que largement suffisant!

Sauf que geogeo, il n'a pas plusieurs plan scroll, même pas 1. Donc il n'y a que peu de parties de l'image qui sont changées d'une frame sur l'autre, donc la technique qu'il utilise actuellement doit sûrement être la plus efficace.

C'est sûr jackiechan...

bein disons que dans ce cas la ca sert a rien, car le fps doit etre sup a 100

même, dans ce cas, il n'a pas besoin du tout de XLib, mais plutot d'une bonne utilisation des ROM_CALLs ..

Kevin Kofler a écrit :
Arrête de raconter n'importe quoi! Je ne dis pas ça au hasard. Ma remarque s'appuie sur des exemples concrets. http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=79.topic. Je cite:


S'il y a une chose que je déteste, ce sont les gens qui croient savoir plus que moi alors que ce qu'ils racontent est du n'importe quoi pur et net.

Sauf que je sais très bien de quoi je parle. Tu as déjà expérimenté la programmation graphique au lieu de lire ce que les autes racontent? La théorie c'est bien mais c'est dans la pratique que l'on se rend compte de ce qui se passe réellement .

Et tu oublies la phrase clef: "When background saving is convenient -- here it's easy to implement because we have so few sprites, the sprites are the same size, and they're word width so we can just grab longwords"
Bon ça fait beaucoup de conditions pour pouvoir appliquer cette méthode .

En plus je trouve ça d'un manque d'élégance flagrant, lourd à mettre en oeuvre, ça consomme plus de mémoire, dans la plupart des cas ça peut être lent (le "peut être" est bien sûr destiné à ne pas heurter ta sensibilité ).

edit: ça fait trop sévère là, avec 1 ou 2 smileys ça ira mieux

c'est vrai que je ne trouve pas ça élégant du tout, cette technique.

eet il est difficile de penser a tous les cas de figure...
un bug graphie arrive vite... et une fois qu'il est la, bonne chance pour qu'il disparaisse

Ximoon a écrit :
En plus je trouve ça d'un manque d'élégance flagrant, lourd à mettre en oeuvre, ça consomme plus de mémoire, dans la plupart des cas ça peut être lent (le "peut être" est bien sûr destiné à ne pas heurter ta sensibilité ).

Pour moi, le manque d'élégance flagrant, c'est de tout réafficher à chaque fois. C'est une méthode naïve et bourrine. La sauvegarde des zones réellement modifiées seulement est une solution plus élaborée.

Plus élaborée et moins efficace.

Je te propose quelque chose : va faire un jeu un minimum complexe avec ta méthode, moi j'en fais un en réaffichant tout, et on voit qui s'en tire le mieux
C'est honnête non ?