Arkanoid - Page 27

geogeo
:

Mais comment veux-tu que le compilo sache ce que tu veux faire ? Tu pourrais très bien vouloir additionner les 32 bits du registre !

Un Warning pourrais faire l'affaire.

geogeo :
Ah ok je pensais qu'il était possible de faire ça directement en traitant le code.

Mais enfin, réfléchis avant de dire n'importe quoi !
Ce n'est pas impossible d'émettre un warning devant ce genre de code, mais c'est débile.
Si un programmeur veut additionner les 32 bits de d0 avec a0, il utilisera move.l d0,a0, et il n'a pas à recevoir un quelconque warning à l'assemblage...

En tout cas ça n'existe pas et ça n'existera pas donc cherchons pas midi à quatorze heure.

kler ... geogeo, tu lames grave ...

Mais enfin, réfléchis avant de dire n'importe quoi !

Ce n'est pas impossible d'émettre un warning devant ce genre de code, mais c'est débile.

Pense aux bouffons comme moi qui ne repère pas ce genre d'erreur.

Si un programmeur veut additionner les 32 bits de d0 avec a0, il utilisera move.l d0,a0, et il n'a pas à recevoir un quelconque warning à l'assemblage...

Un warning que je sache n'annule pas la compilation. et les switchs existe.

En tout cas je fais gaffe maintenant et ma reflexion n'avais pas pour but de créer une querelle à la con!

Oulala c'est chaud la quand meme...

geogeo> Le problème, c'est que là, tu vois les choses selon ton contexte, où évidemment, tu aurais été content d'avoir un warning.
Mais si qq1 veut faire une addition sur 32 bits, il n'a pas à obtenir de warning à l'assemblage, même si ce n'est qu'un warning !
Si tu veux, pour te permettre de comprendre plus facilement, imagine la situation inverse : quelqu'un veut faire une addition sur 32 bits, mais écrit add.w, il faudrait là aussi que l'assembleur génère un warning, selon ta conception des choses. On ne va pas émettre un warning sur chaque instruction : "Attention, vous avez spécifié une opération sur 16 bits, est-ce vraiment ce que vous voulez faire ?" (et pareil pour chaque instruction sur 32 bits).
Rends toi compte qu'à chaque source assemblé, sur pratiquement chaque instruction il faudrait émettre un warning !

Hmm, est-ce que ça serait possible de faire comme PocketNES, à savoir, une frame sur deux, afficher une couleur différente pour chaque pixel de l'écran qui représente 2 pixels logiques ? (Si qq1 voit ce que je veux dire)

Effectivement, il peut faire des tables (les pixels affichés la première frame, et ceux la deuxième) mais de toutes façons c'est inutile car:
-trop lent horizontalement (ça aurait été valide verticalement, car on n'aurait eu que chaque ligne à traiter, mais là c'est chaque pixel)
-un blur par clignotement en niveaux de gris (qui eux-même utilisent déjà un clignotement) ça rendra plus moche qu'autre chose... à moins de bidouiller avec le FS et d'être VRAIMENT rapide dans sa routine. Autant oublier quoi.

lol je ne suis pas si bête que ça quand même, j'ai pas dit scruter toutes les instructions et emettre un warning sur chaque instruction, tu imagine une source avec 10000 lignes, et je ne te parle pas du nombres de warnings, y a de quoi devenir .

Je parle du cas suivant , tu entre en paramètre un short dans d4 par exemple, dans ton code à aucun moment tu n'as sauvé d4 et restauré et tout d'un coups te prend l'envie d'écrire sur les 16 bits de poids forts, là il y a forcémement un bug ou encore tu utilise d5 dans ton programme mais à aucun moment tu ne le sauve et tu le restaure donc encore un bug. Bien sûr comme Kevin vient de le dire il faudrait une machine virtuel qui execute ce code et qui à chaque étape vérifie le contenu du registre en fonction des paramètres passé par la fonction... Je pense quand même que ce scrutage ne demande pas l'affichage d'une multitude de warnings.

Ou encore tu as un paramètre sur 16bits dans d0 et tu lie les 32 bits.

'd3' might be used uninitialized in this function

geogeo> Mais tu n'as rien compris! Le programmeur peut très bien avoir un objectif précis:

| long une_fonction_étrange(long param1 asm("d1"), long param2 asm("d2"));
une_fonction_étrange:
  move.w %d1,%d0
  move.w %d2,%d1
  move.w %d0,%d2
  move.l %d1,%d0
  add.l %d2,%d0
  rts

Là, à aucun moment je n'ai sauvé et restauré d2 et l'envie m'a pris d'écrire sur les bits de poids fort. Est-ce que c'est pour autant une erreur ?

mais d2 n'est pas important puisque TIGCC ne l'utilise pas tel quel je parle de d3-d7/a2-a6

[EDIT] J'ai fais une erreur j'ai parlé de d2 alors que j'aurais dû parler d'un autre registre supérieur à d2.

tu entre en paramètre un short dans d2 par exemple, dans ton code à aucun moment tu n'as sauvé d2 et restauré et tout d'un coups te prend l'envie d'écrire sur les 16 bits de poids forts

^^
Et pour d3-d7/a2-a6 c'est la même chose. sauvegarder ces registres dans les fonctions c'est une convention de TIGCC. Si tu fais un prog. en assembleur, tu n'as aucune obligation de la respecter ! Et tu crois vraiment que l'assembleur peut distinguer un label à l'intérieur d'une fonction d'un label qui est le début d'une fonction ? Ce n'est pas possible...

je parle pas de l'assembleur je parle d'une machine virtuel executant le code rien de plus et où chaque adresses des fonctions est connus. Mais ça demande une communication entrele compilateur C, l'assembleur et la machine virtuel!

Hmm, oué, mais ça ne m'ôtera aps de la tête l'idée que détécter des erreurs dans un code en assembleur par un programme est impossible. Y'a qu'à voir: même quand tu est celui qui a écrit la fonction, tu galères pour trouver le bug, et pourtant, tu sais à quoi sert chaque instruction... Alors peut-être que pour des fonctions et des programmes compilés exclusivement en C, c'est possible, mais pour ce qui est du reste... Je doute fort que ça soit possible. Le seul truc qui serait faisable (avec un émulateur fait pour bien sûr) serait de sauvegarder les 10 (ou +) dernières actions pour chaque registre. Comme ça, à la limite, si une instruction comme move.w (%a0),%d1 faisait une "Address Error", on pourrait déterminer l'emplacement de l'instruction fautive (et encore...)

geogeo :
lol je ne suis pas si bête que ça quand même, j'ai pas dit scruter toutes les instructions et emettre un warning sur chaque instruction, tu imagine une source avec 10000 lignes, et je ne te parle pas du nombres de warnings, y a de quoi devenir .

Mais si on fait ça pour add, pourquoi ne pas le faire sur toutes les autres instructions d'opérations logiques et arithmétiques ?
Réfléchis vraiment.

Je parle du cas suivant , tu entre en paramètre un short dans d4 par exemple, dans ton code à aucun moment tu n'as sauvé d4 et restauré et tout d'un coups te prend l'envie d'écrire sur les 16 bits de poids forts, là il y a forcémement un bug ou encore tu utilise d5 dans ton programme mais à aucun moment tu ne le sauve et tu le restaure donc encore un bug. Bien sûr comme Kevin vient de le dire il faudrait une machine virtuel qui execute ce code et qui à chaque étape vérifie le contenu du registre en fonction des paramètres passé par la fonction... Je pense quand même que ce scrutage ne demande pas l'affichage d'une multitude de warnings.

Déjà, ce n'est pas le rôle d'un assembleur de faire ce genre de vérifications (qui sont quand même tordues, parce qu'on peut difficilement prévoir correctement ce que le programmeur voulait faire)
onction: add.l d1,d0 rts

Ensuite, si j'ai une fonction :; Additionne deux nombres, d0=nombre1 et d1=nombre2
; résultat dans d0
; détruit d0 et d1
F

Comment veux tu que dans ce genre de cas l'assembleur sache si tu veux ou non faire une addition sur 32 bits et donc émettre un warning ?
C'est impossible, et ce n'est pas parce que le warning n'empêche pas de créer l'exécutable qu'il faut en mettre autant qu'on veut.

D'autant plus qu'en asm on peut faire facilement des fonctions très tordues, des brachements aléatoires et du code auto modifiant... c'est vraiment n'importequoi cette histoire de warning.
D'ailleurs je ne suis pas sûr que ça serve vraiment à quelquechose de continuer là dessus...

D'ailleurs je ne suis pas sûr que ça serve vraiment à quelquechose de continuer là dessus...

Enfin!

En tout cas le langage veut ça et on voir clairement que c'est impossible!

Les bugs sont corrigé et c'est le principal mais en lancant ce débât j'avais juste pour but de voir clairement qu'il n'était pas possible de vérifier un programme en assembleur!

GoldenCrystal :
geogeo> Mais tu n'as rien compris! Le programmeur peut très bien avoir un objectif précis:

| long une_fonction_étrange(long param1 asm("d1"), long param2 asm("d2"));
une_fonction_étrange:
  move.w %d1,%d0
  move.w %d2,%d1
  move.w %d0,%d2
  move.l %d1,%d0
  add.l %d2,%d0
  rts

Là, à aucun moment je n'ai sauvé et restauré d2 et l'envie m'a pris d'écrire sur les bits de poids fort. Est-ce que c'est pour autant une erreur ?

Non, parce qu'ici toutes tes valeurs sont initialisées. (%d1 et %d2 sont initialisés par le caller lors du passage par registres.)

GoldenCrystal :
sauvegarder ces registres dans les fonctions c'est une convention de TIGCC.

C'est plutôt une convention de AMS. TIGCC fait ce que AMS lui demande (%d2 serait par défaut callee-saved, pas caller-saved, dans GCC).

geogeo
: je parle pas de l'assembleur je parle d'une machine virtuel executant le code rien de plus et où chaque adresses des fonctions est connus. Mais ça demande une communication entrele compilateur C, l'assembleur et la machine virtuel!

Et surtout ça demande que la machine virtuelle passe par le bon endroit du code.
Et encore, pour détecter qu'un registre est utilisé non-initialisé, c'est dur, parce qu'il peut avoir été initialisé à un endroit plus avant dans le programme, mais on ne peut pas vraiment détecter si cette initialisation a un rapport avec la fonction dans laquelle on est ou si elle est du n'importe-quoi. Spécifier des prototypes devant tous les labels correspondant à une fonction, qui disent à la machine virtuelle de mettre tout ce qui n'est pas spécifié comme étant un argument par le prototype en l'état "non-initialisé", pourrait être une solution.

Ximoon
: D'autant plus qu'en asm on peut faire facilement des fonctions très tordues, des brachements aléatoires et du code auto modifiant... c'est vraiment n'importequoi cette histoire de warning.

Ce style de saletés mérite un warning pour sa seule apparition. Par exemple, tu vas faire boguer les optimisations du linker si tu fais n'importe quoi avec du code auto-modifiant.

bah voyons
on peut même plus coder efficacement en asm maintenant
il est beau le linker tiens

Ça dépend de ce que tu veux faire avec ton code automodifiant.
Si tu fais un move x:l,%d0 et que tu veux remplacer soit l'opcode move ...:l,%d0, soit l'adresse x par autre chose, ben si le linker optimise en move x(%PC),%d0, ça sera râté. (Cela dit, 0:l marche très bien comme placeholder pour une adresse.)

mouais
de toutes façons on s'en rend vite compte

geogeo
:

D'ailleurs je ne suis pas sûr que ça serve vraiment à quelquechose de continuer là dessus...

Enfin!

En tout cas le langage veut ça et on voir clairement que c'est impossible!
Les bugs sont corrigé et c'est le principal mais en lancant ce débât j'avais juste pour but de voir clairement qu'il n'était pas possible de vérifier un programme en assembleur!

N'importe quoi, quelle mauvaise foi !
Heureusement que Ximoon est intervenu, il t'a sauvé...

non non t'inquiete pas Sasume on a tous vu geogeo passer pour un boulet une fois de plus

OK j'avoue avoir fait le boulet là mais ça serait bien de revenir au sujet.

Ben revenons au sujet. J'ai essayé de voir ce que donnerait une routine de rétrécissement de l'écran et c'est difficile d'obtenir une vitesse convenable (sauf...)
Alors, il vaut mieux que ton programme soit rapide, parce que même la routine de rétrécissement de l'écran la plus rapide risquerait de réduire le fps à 20 (30 au mieux)

Le jeu tourne à 70 fps et en moyen le jeu tourne à cette vitesse, min il descend à 40 fps et max à 85 fps voir 90 fps.

J'ai appliqué les 2 modes d'écrans pour la TI92+ à savoir scrolling verticale où rétrécissement de la zone de jeu.
En tout cas sur TI89 si on effectue un rétrécissement suivant la largeur je ferais un FrameSkip de 1 minimum. En tout cas je pense ajouter une fonction qui suivant le fps réglera le jeu...

Si jamais tu arrives à avoir une routine de rétrécissement potable, je serai curieux de voir ta méthode (pour savoir si c'est une de celles auquelles j'ai pensé)

On verra bien, pour l'instant je ne travail pas là dessus j'essaye de rendre le jeu jouable à 100% car casser toutes les briques sans passer au niveau suivant c'est assez déroutant.

Une animation du jeu assez grosse:
Bon le scrolling est à revoir surtout que j'ai pas encore mis la possibilité de ce concentrer sur la raquette quand il y a plusieurs billes, on le vois très bien dans le screen.

Le screen montre aussi les 2 possibilités de réglages d'écrans sur TI92+ ainsi que quelques bonus...
Quand le compteur à droite est à 500 le jeu tourne à 75 fps.

http://perso.wanadoo.fr/tisofts/arkanoid/screens/screen_7.gif

[EDIT] GoldenCrystal> Tu parle de la routine de rétrécissement pour TI89 soit passer de 224x200 pixels à 160x100 pixels?
J'ai ma petite idée reste à l'essayer.