encore une chtite question - Page 3

au fait, je me damandais opur dessiner à l'écran, si ce nétait pas meiux de le faire moi-même à la main, ou est-ce que la routine de graphlib est assez optimisée pour un cas comme celui-ci?

"Pour un cas comme celui-ci", la rouine de graphlib est suffisante, je pense.
Mais à mon avis elle n'est pas pessimisée, cette routine, donc ce n'est pas sûr que tu puisses faire beaucoup mieux en la recodant.
Sinon, tu peux quand même essayer de faire tes propres routines, pour le fun

Ce code est affreux! Le nombre de libcalls inutiles...

jsr graphlib::fill

http://tigcc.ticalc.org/doc/graph.html#ScrRectFill (visiblement, tu n'as même pas lu mon message)

jsr graphlib::horiz

http://tigcc.ticalc.org/doc/graph.html#DrawLine

jsr graphlib::scrtomem

jsr graphlib::memtoscr

http://tigcc.ticalc.org/doc/mem.html#memcpy
Et tu peux optimiser les 2 copies en un seul memmove (donc 2 fois plus rapide): http://tigcc.ticalc.org/doc/mem.html#memmove.

(Je précise que les fonctions ci-dessus sont carrément obsolètes ("deprecated"), vu qu'elles ont un équivalent dans AMS lui-même!)

Et tu peux aussi te passer de graphlib::put_sprite et userlib::random en utilisant TIGCCLIB et ExtGraph, qui sont parfaitement utilisables en assembleur. Ça a l'avantage que tu n'es plus dépendant de grosses librairies comme graphlib ou userlib dont 90% des fonctions sont obsolètes.

tu peux très bien continuer à utiliser graphlib, ça permet de coder facilement en assembleur sur calculatrice.
La programmation kernel n'est pas complètement la même que la programmation nostub, et il vaut mieux tester les deux avant de se laisser imposer qqc

Flanker
: tu peux très bien continuer à utiliser graphlib, ça permet de coder facilement en assembleur sur calculatrice.

Je ne vois pas en quoi utiliser des libcalls est plus facile qu'utiliser des ROM_CALLs qui font exactement la même chose!

Kevin Kofler :
Ce code est affreux! Le nombre de libcalls inutiles...

jsr graphlib::fill

http://tigcc.ticalc.org/doc/graph.html#ScrRectFill (visiblement, tu n'as même pas lu mon message)

jsr graphlib::horiz

http://tigcc.ticalc.org/doc/graph.html#DrawLine

jsr graphlib::scrtomem

jsr graphlib::memtoscr

http://tigcc.ticalc.org/doc/mem.html#memcpy
Et tu peux optimiser les 2 copies en un seul memmove (donc 2 fois plus rapide): http://tigcc.ticalc.org/doc/mem.html#memmove.

->Est-ce sur que des rom_calls en C sont plus rapides que des appels à des libs en asm??? (dsl Kevin, j'avais bien lu ton message, mais je voudrais la réponse à cette question avant...)

->Je n'ai trouvé dans aucun tuto la syntaxe autorisée pour les noms de variables et de labels, quelle est-elle?

->y a-t-il un rom_call équivalent à find_pixel de util, pour tester si le vaisseau touche le bord noir?

->à propos de fin_pixel, que signifie précisément le mot "offset"?

A nouveau merci d'avance pour vos réponses, et merci également pour toute l'aide que vous m'avez déjà apportée

Les ROM_CALLs graphiques sont en général assez lents malheureusement.
Enfin, si tu n'as pas besoin d'une vitesse extraordinaire, tu peux les utiliser quand même...

Find_pixel : http://tigcc.ticalc.org/doc/graph.html#GetPix

offset = décalage, valeur à ajouter un à pointeur (dans ton cas, il doit s'agir de la valeur à ajouter à l'adresse de l'écran pour pointer sur l'octet conenant le pixel don tu veux connaître l'état).

>Ah oui, c'est vrai qu'en mode kernel les paramètre se passent souvent par les registres
En nostub aussi maintenant

ok merci Sasume

[pour kevin]
j'ai dl ExtGraph, et après avoir lu la doc, ça me botte à fond, donc je vais m'y mettre, c'est ok
[/pour kevin]

Pour la défense d'Extgraph, j'ai été agréablement surprit par la deuxième version
J'ai même fait un jeu avec, ça tourne très bien, 50~60 fps. (par contre mieux vaut prévenir que guérir : non Kevin ce n'est pas une occasion pour pretexter qu'Extgraph est "mieux", c'est toujours aussi faux qu'avant, et l'inverse l'est aussi)

Oui, et en ASM, c'est peut-être plus pratique d'utiliser la version 2.x parce que les paramètres sont passés par les registres.
Par contre, il n'y a pas de doc (mais la doc de la version 1.02 devrait suffir).

nounoun
: ->Est-ce sur que des rom_calls en C sont plus rapides que des appels à des libs en asm??? (dsl Kevin, j'avais bien lu ton message, mais je voudrais la réponse à cette question avant...)

Si la librairie traîte les fonctions obsolètes comme il faut, elle ne fait qu'appeler le ROM_CALL correspondant, donc on perd encore plus de temps que si tu appelles le ROM_CALL directement. Si elle fait autre chose, c'est un gaspillage de place. (Je vais envoyer des patches à PpHd pour ça, on va voir s'il les accepte. )

->Je n'ai trouvé dans aucun tuto la syntaxe autorisée pour les noms de variables et de labels, quelle est-elle?

Combinaison de lettres, d'underscores et de chiffres, commençant par une lettre (les identifiants commençant par un underscore sont réservés par TIGCC, ceux commençant par un chiffre sont carrément rejetés).

Les fonctions de graphlib sont plus rapides que celles correspondates d'ams.

Les fonctions de graphlib sont obsolètes et devraient se limiter à établir la compatibilité antérieure en appelant leur remplacement dans AMS.

Je peux toujours faire graphlib et graphlib-small. Lib powa

lol ça finira donc jamais cette guéguerre

impossible de alcer un seul lien du post de Kevin...

ticalc.org est down en ce moment. Je n'y peux rien. Réessaye à un autre moment.

k merci, j'éspère que ça ne durera pas

Toujours down.
J'ai vérifié: le nom de domaine fonctionne, j'ai bien une IP, elle est routé correctement jusqu'à Sollentuna (donc la petite ville où se trouve le serveur) et ça s'arrête là. Apparemment, c'est bien la machine qui a un problème.
D'ailleurs, petite curiosité: un des 3 DNS de ticalc.org est ns.ti.com. (Les 2 autres sont sur sollentuna.net.) Bref, le site est inofficiel, TI refuse de mettre des liens dessus depuis l'histoire du matériel inapproprié, mais TI les a apparemment dans leur DNS.

ticalc.org remarche.

Confirmé.

J'ai la version 1.02 de ExtGraph (trouvée sur ticalc), mais ou trouver la 2ème version???

Et au fait Kevin, comment lancer le Wizard de tigcc, impossible de le trouver, amors que l'option "enable wizard" est cochée???
Avant ça se faisait tout seul, mais maintenant plus rien....

sur le site de la tict: http://tict.ticalc.org

merci!

Au fait, je ne suis pas bon en graphisme, car je ne fais que des programmes utilitaires et des programmes de calculs topographiques (cf mon métier lol). Que signifie "image transparente", ça fait plusieurs fois que je vois ça. C'est un mode d'affichage?

Afficher une image en transparence, ça veut dire que tu sacrifie une des couleurs de l'image (generalement le blanc ou le noir), qui sera considérée comme "transparente" (cad qu'on verra le fond derrière), alors que les 3 autres seront opaques.

nounoun :
Et au fait Kevin, comment lancer le Wizard de tigcc, impossible de le trouver, amors que l'option "enable wizard" est cochée??? Avant ça se faisait tout seul, mais maintenant plus rien....

1. Le "template wizard" n'est que pour les programmes C, pas pour les programmes assembleur.
2. Le "template wizard" n'existe plus sous TIGCC 0.95. L'option a d'ailleurs été supprimée dans les dernières bêtas. Il a été remplace par un règlage global des options dans les options du projet ("program options"). L'utilisation de #define dans les sources pour règler les options est dépréciée parce qu'elle est souvent source d'inconsistence des options entre les différents fichiers. Et puis c'est mieux quand toutes les options sont règlées au même endroit.

Pas plus facile de regarder directemnt sur l'écran plutôt que d'utiliser GetPixel ??
Sinon, essaie quand même de passer à des versions de libs plus récentes - graphlib et userlib, par ex, que j'utilisais il y a plus de 5 ans... -

Sinon, le addq marche sur autre chose que des registres ??
De toute façon, essaie d'expliciter le plus souvent possible les .b, .w, .l ainsi que la fonction ASM exacte que tu veux - même chose pour les bsr, bne, ... -

Sinon, le btst est la fonction que tu devrais utiliser pour le point que j'ai abordé au début de ce post...