[THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Modérateurs : Papy.G, fneck, Carl
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Pourtant le nom est bien écrit gros partout
Bon ok ok, pas de "P" a Thomson ! C'est noté pour moi.
Bon ok ok, pas de "P" a Thomson ! C'est noté pour moi.
-
- Messages : 2367
- Inscription : 06 avr. 2009 12:07
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
CMOC est assez sympa. Parmi les fonctionnalités non supportées, le seul point qui mériterait amélioration sur Thomson je pense c'est l'arithmetique sur flottants. D'une part, parce que les floats ne sont supportés par CMOC que dans l'environnement COCO Basic et d'autre part parce que les double ne sont pas supportes du tout, alors que sur Thomson, il y a tout ce qu'il faut en BASIC ou dans l'extra-moniteur sur les machines de derniere generation.
Les autres fonctionnalités manquantes, c'est globalement supportable.
Les autres fonctionnalités manquantes, c'est globalement supportable.
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Merci.
C'est une bonne nouvelle car j'utilise pas de float en general dans mes jeux.
C'est une bonne nouvelle car j'utilise pas de float en general dans mes jeux.
-
- Messages : 2367
- Inscription : 06 avr. 2009 12:07
-
- Messages : 7988
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
j'ai vu que gcc6809 et cmoc sont installables sous Ubuntu et j'ai fait quelques tests..
Avec CMOC: cmoc --no-relocate -O2 -S t.c
Avec gcc6809: /usr/bin/m6809-unknown-gcc -O3 -fomit-frame-pointer t.c -S
Celui de CMOC peut-être beaucoup amélioré
Code : Tout sélectionner
int count_ones(int x)
{
int n = 0;
while(x)
{
++n;
x &= -x;
}
return n;
}
Code : Tout sélectionner
_count_ones EQU *
PSHS U
LEAU ,S
LEAS -2,S
* Formal parameters and locals:
* x: int; 2 bytes at 4,U
* n: int; 2 bytes at -2,U
* Line t.c:3: init of variable n
CLRA
CLRB
STD -2,U variable n
* Line t.c:4: while
BRA L00003 jump to while condition
L00002 EQU * while body
LEAX -2,U variable n, declared at t.c:3
LDD ,X
ADDD #1
STD ,X
* Line t.c:7: assignment: &=
LDD 4,U variable x, declared at t.c:1
COMA
COMB
ADDD #1
PSHS B,A
LEAX 4,U
LDD ,S++
ANDA ,X
ANDB 1,X
STD ,X
L00003 EQU * while condition at t.c:4
LDD 4,U variable x, declared at t.c:1
* optim: loadCmpZeroBeqOrBne
BNE L00002
* optim: branchToNextLocation
* Useless label L00004 removed
* Line t.c:9: return with value
LDD -2,U variable n, declared at t.c:3
* optim: branchToNextLocation
* Useless label L00001 removed
LEAS ,U
PULS U,PC
* END FUNCTION count_ones(): defined at t.c:1
Code : Tout sélectionner
_count_ones:
pshs y,u
leay ,x
ldx #0
cmpy #0 ;cmphi:
beq L2
L3:
leax 1,x
tfr y,d
nega
negb
sbca #0
tfr d,u
tfr y,d
pshs u
anda ,s+
andb ,s+
tfr d,y
cmpy #0 ;cmphi:
bne L3
L2:
puls y,u,pc
- "CLRA; CLRB" doit être remplacé par "LDD #0"
- le -x est réalisé par (~x)+1L'ensemble serait plus rapide et plus court avec
Code : Tout sélectionner
LDD 4,U variable x, declared at t.c:1 COMA COMB ADDD #1
Code : Tout sélectionner
LDD #0 SUBD 4,U
- "LDD ,S++" est plus couteux que "PULS D"
- je ne pige pas le passage par X danset pareil plus loin. Ca bloque un registre et c'est plus lent que de faire
Code : Tout sélectionner
LEAX -2,U variable n, declared at t.c:3 LDD ,X ADDD #1 STD ,X
Note un vrai bon compilo minimiserait les accès mémoire et ferait:Code : Tout sélectionner
LDD -2,U ADDD #1 STD -2,U
Code : Tout sélectionner
INC -1,U BNE L0 INC -2,U L0:
- remplacer les 'cmpy #0; (bne|beq)" par "leay ,y; (bne|beq)"
- et surtout c'est quoi ce mic-mac autour du "tfr d,u + pshs u" au lieu de faire "pshs d" tout court ?
- enfin pourquoi l'argument est passé dans X au lieu de D. Pour le coup, ici travailler sur D serait plus malin.
Code : Tout sélectionner
_count_ones:
stx ,--s
beq L1
ldx #0
ldd ,s
L2:
leax 1,x
nega
negb
sbca #0
anda ,s
andb 1,s
std ,s
bne L2
L1:
puls d,pc
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Merci Samuel pour le test.
Pour des sections de code non critique, c'est tout a fait acceptable je trouve. C'est chouette. (bon apres faut que ca marche bien sur )
Pour des sections de code non critique, c'est tout a fait acceptable je trouve. C'est chouette. (bon apres faut que ca marche bien sur )
-
- Messages : 2367
- Inscription : 06 avr. 2009 12:07
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
C'est très intéressant en effet même si je ne peux pas apprécier toutes les subtilités du fait de ma méconnaissance de l'assembleur du 6809.
Forcément les compilateurs vont générer un code indigeste puisqu'ils vont pouvoir supporter des boucles imbriquées, des appels récursifs de fonctions et tout un tas de joyeusetés que l'alphabet permet d'écrire.
Le code machine fait directement par un humain va sans doute être plus optimisé car en fonction des besoins il tirera plus ou moins parti de certains raccourcis autorisés par le processeur.
Cependant je crois qu'il y aura autant de version du code machine que de développeur. Notamment des développeurs débutants vont sans doute répliquer en assembleur ce qu'ils connaissent de la programmation dans des langages interprétés ou procéduraux. Par exemple avoir un recours massif à des zones mémoires utilisées comme variables y compris pour des index de boucles, calquer des structures si alors sinon alors que l'utilisation judicieuse des valeurs du registre des flags permet d'économiser des tests superflus.
A l'inverse la créativité est sans limite. Récemment en décortiquant un programme sur CPC j'ai réalisé que le développeur avait placé ses chaînes de caractères au milieu du code au lieu de les placer comme des ressources après le code exécutable. Chaque fois que le programme affiche un message il appelle une routine qui récupère l'adresse de retour dans la pile et lit/affiche les caractères depuis cette adresse jusqu'à un code de fin de chaîne puis saute à cette l'adresse suivant le code de fin pour continuer l'exécution. Je ne sais pas si c'est une bonne pratique mais il faut se creuser les méninges pour comprendre.
Forcément les compilateurs vont générer un code indigeste puisqu'ils vont pouvoir supporter des boucles imbriquées, des appels récursifs de fonctions et tout un tas de joyeusetés que l'alphabet permet d'écrire.
Le code machine fait directement par un humain va sans doute être plus optimisé car en fonction des besoins il tirera plus ou moins parti de certains raccourcis autorisés par le processeur.
Cependant je crois qu'il y aura autant de version du code machine que de développeur. Notamment des développeurs débutants vont sans doute répliquer en assembleur ce qu'ils connaissent de la programmation dans des langages interprétés ou procéduraux. Par exemple avoir un recours massif à des zones mémoires utilisées comme variables y compris pour des index de boucles, calquer des structures si alors sinon alors que l'utilisation judicieuse des valeurs du registre des flags permet d'économiser des tests superflus.
A l'inverse la créativité est sans limite. Récemment en décortiquant un programme sur CPC j'ai réalisé que le développeur avait placé ses chaînes de caractères au milieu du code au lieu de les placer comme des ressources après le code exécutable. Chaque fois que le programme affiche un message il appelle une routine qui récupère l'adresse de retour dans la pile et lit/affiche les caractères depuis cette adresse jusqu'à un code de fin de chaîne puis saute à cette l'adresse suivant le code de fin pour continuer l'exécution. Je ne sais pas si c'est une bonne pratique mais il faut se creuser les méninges pour comprendre.
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Tout les assembleurs font ça. Ce n'est pas nouveau car ils ne connaissent pas la subtilité humaine
Le mieux, comme en BASIC, c'est de préparer ta routine sur une feuille et de la retravailler ensuite. Point de vue visuel, c'est plus reposant que faire défiler ton prg ligne après ligne
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Bonjour! Désolé de revenir au sujet initial concernant l'animation sur Mo5/TO7. N'y aurait-il pas une solution (bidouille ASM) afin d’éviter le "colorclash" lors des collisions entre sprite ? Je suis en train d'étudier le problème mais je n'ai pas encore de solution idéale, surtout si on compte conserver un maximum de couleur. Il y a en effet, comme évoqué plus haut, le même problème pour de nombreuses machines 8 bits et là je pense aussi à l'Alice 32 qui utilise des modes caractère. Au risque de passer pour une feignasse, ce serait sympa de créer un espace dans lequel les programmeurs motivés pourraient trouver des routines que d'autres auraient déjà faites (histoire de ne pas réinventer la roue éternellement). Je pense qu'en plus, cela permettrai de gagner du temps (que l'on à pas car tout le monde bosse et à certainement une vie de famille) mais surtout ouvrirai le champ à d'autres innovations ou optimisations. Je dis ça car le homebrew en matière de jeux sur les toutes petites machines françaises est au point mort, il y a pourtant un potentiel pour les passionnés, non?
Computer Love
-
- Messages : 7988
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
C'est pas au point mort. Ca se passe ailleurs:
- http://www.logicielsmoto.com/phpBB/view ... ?f=1&t=609
- http://www.logicielsmoto.com/phpBB/view ... ?f=3&t=620
(par exemple)
Sinon pour éviter le color-clashs W_oo_d avait trouvé un truc sympa:
- http://www.logicielsmoto.com/phpBB/view ... 5287#p5287
- http://www.logicielsmoto.com/phpBB/view ... ?f=1&t=609
- http://www.logicielsmoto.com/phpBB/view ... ?f=3&t=620
(par exemple)
Sinon pour éviter le color-clashs W_oo_d avait trouvé un truc sympa:
- http://www.logicielsmoto.com/phpBB/view ... 5287#p5287
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Merci pour les liens Sam. Tu as vu tourner un des jeux en mode Supercolor ? Est-ce vraiment peu perceptible à l'oeil ? En tout cas l'idée est effectivement géniale étant donné les contraintes de la machine.
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Oui SAM j'avais vu cette page sur le "Supercolor" mais pour les sprites une ligne sur deux avec une résolution déjà faible c'est à mon sens esthétiquement "limite". Mais c'est une super idée quand même à exploiter pour certains projets. De plus j'avais précisé "petites machines" c'est à dire le MO5 par exemple et pas un TO8 ou TO9 qui ont tout de même de meilleurs atouts. Certains de ces forums s'arrêtent en 2019!! Ce qui signifie bien qu'a chaque fois les projets n'aboutissent pas et que le programmeur s’essouffle. C'est bien dommage. Pour ma part je me remet juste à la programmation ASM, je n'avais pas pratiquer depuis 1991 (6809 et 68000). Ce n'est pas comme remonter sur un vélo. N'y aurait-il pas la possibilité d'alterner des pages écrans en changeant uniquement l'une d'un sprite1 puis l'autre du sprite2 (pour faire simple), ne chargeant que la couleur de forme? Il y a un risque de scintillement non?
Dernière modification par Mephistow le 05 mai 2021 22:45, modifié 1 fois.
Computer Love
-
- Messages : 7988
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
[edit] Effacement du doublon. Désolé.
Dernière modification par __sam__ le 12 mai 2021 15:05, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
-
- Messages : 7988
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [THOMSON] MO5 TO7-70 programmation animation FOX pixel/pixel
Non non les liens que j'ai données sont toujours actifs, mais il faut voir que développer un truc est un projet de longue halène (rien à voir avec les clefs). Ainsi les PACMAN ou Sonic se font sur plusieurs mois, presque une année. Il faut de la motivation en effet sur les petites machines. Il faut tout refaire depuis 0 avec pas mal de recherches infructueuses. C'est aussi le cas du supercolor W_oo_d qui regarde sur plusieurs machines à la foi (en ce moment il est sur Acorn... ). A noter aussi que quand adnz a commencé il n'avait aucune connaissance de l'asm 6809.
En outre les thomsons n'ont pas une puissance phénoménale (TO8 ou MO5 c'est pareil du point de vue CPU) et la notion de bibliothèque génériques et réutilisable (donc peu optimisées pour le cas dans lequel on se trouve) donne des résultats insatisfaisants. Au final, chaque jeu, en fonction de ses contraintes et particularités doit développer sa propre façon de gérer les sprites, le scroll et le son.
Néanmoins il y a 8bits-unity qui tente de faire un truc dans cet esprit, mais pas pour les thomson pour le moment. "8bits dude" est présent sur le forum et a annoncé vouloir plus tard faire en sorte que 8bits unity marche aussi sur les thomson. Je présume qu'il ne serait pas contre un petit coup de main. Il faut le "pinger" sur son fil.
En outre les thomsons n'ont pas une puissance phénoménale (TO8 ou MO5 c'est pareil du point de vue CPU) et la notion de bibliothèque génériques et réutilisable (donc peu optimisées pour le cas dans lequel on se trouve) donne des résultats insatisfaisants. Au final, chaque jeu, en fonction de ses contraintes et particularités doit développer sa propre façon de gérer les sprites, le scroll et le son.
Néanmoins il y a 8bits-unity qui tente de faire un truc dans cet esprit, mais pas pour les thomson pour le moment. "8bits dude" est présent sur le forum et a annoncé vouloir plus tard faire en sorte que 8bits unity marche aussi sur les thomson. Je présume qu'il ne serait pas contre un petit coup de main. Il faut le "pinger" sur son fil.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos