Recensement - Page 2

ce qui explique pourquoi il est toujours seul

c'est une question de joug...

Romu:
c'est plus explicite?

vince :
ce qui explique pourquoi il est toujours seul

Vince toi aussi t'es seul?! non?!

non.. il a Piwi...c'est pire...

Pour info pour David
- programme encore sous GFA
- en ASM 68000 (bientot des intros...)
- touche pas au graphisme
- fait plus de DCK !

Voila !

kuk :
non.. il a Piwi...c'est pire...

Pauvre bête..., j'ai mal pour elle...

freddo :
Pour info pour David
- programme encore sous GFA
- en ASM 68000 (bientot des intros...)
- touche pas au graphisme
- fait plus de DCK !

Voila !

Salut mon grand, tu 'squattes' aussi ce forum !! Cela fais plaisir ! Laisse tombé le DCK tu est capable de faire mieux !!


GT Turbo

GT Turbo
alut mon grand, tu 'squattes' aussi ce forum !! Cela fais plaisir ! Laisse tombé le DCK tu est capable de faire mieux !!

Le plaisir et pour moi aussi vieux
DCK sera tjs un plaisir, sur ST...

Moi je programme en GFA,enfin je programme pas je mélange des routines et sous-programme (je comprend rien aux poke,bmove,xbios etc...).
D'ailleur j'en profite pour passer une annonce:
je cherche une routine rapide pour animer 9 sprites de 8*8(enfin bloc graphique) car avec mes rc_copy sa rameeeeeeee.

C'est pour adapter ce jeu que j'ai fais en Dark Basic sur pc et en nestor basic sur msx2
http://kirem.free.fr/pages/download/linex.zip pour pc 920ko
http://kirem.free.fr/pages/download/mars2004b.dsk pour msx2 720ko

euh, 9 sprites, ça devrait passer normalement avec rc_copy
sauf si :
- tu travailles directement à l'écran (xbios(2)) ,
- tu travailles sur un écran de travail mais tu le copies par rc_copy à l'écran
-> bmove serait mieux, l'idéal atant de travailler avec 2 écrans (physique et logique) et d'utiliser xbios(5 de mémoire) pour changer les adresses des écrans physiques et logiques lors d'une synchro écran (pour éviter les scintillements)

Enfin bon, tout ça, c'est de mémoire, d'autres qui ont continué le dev ST pourront te confirmer / aider

Si c'est pour tourner sur un ST(F), il te faut precalculer les 16 decalages de chaque sprites.
Pour commencer, un sprite de 8x8 c'est en fait un sprite de 16x8 a moitié remplit, car les ST gerent les bitmaps par colonnes de 16 pixels.
Ensuite tout depends comment tu affiche tes sprites, si tu dois les afficher a une coordonée X quelconque, tu dois precalculer les 16 decalages de chaque sprite.
Pour y parvenir, tu commence par elargir tes sprites en 32x8, puis tu le copie 16 fois en le decalant d'un pixel en X a chaque fois. Pour afficher ton sprite, tu calcul la coordonee X de la colonne destination (AND(x&,&HFFFFFFF0)) puis le numero du sprite a afficher (AND(x&,&HF)).
De cette maniere, le ST n'aura pas a s'occuper des decalages et tu vas gagner beaucoup de temps !
Si tu doit afficher tes sprites tout les 8 pixels, alors tu restes en 16x8 mais tu fais 2 versions de chaque sprite, une alignée a gauche et l'autre a droite, apres c'est le meme principe.

y'a quand même un truc louche... si le sprite n'est qu'à moitié rempli, pourquoi en prendre un deux fois plus grand pour les décalages ?

paske pour decaler un 8x8 il faut un (16+8)x8=24*8 soit un 32x8 puisqu'il faut un multiple de 16

je viens de regarder la version pc, tres marrant
en fait si tu refais la meme chose sur ST, c'est peut etre pas les sprites de smileys mechants qui vont le plus te ralentir, par contre il faut que tu cherche la meilleure strategie d'affichage pour ne deplacer qu'un miminum de memoire.
par exemple, tu peux sauvegarder le fond derriere les sprites et le restaurer pour effacer le sprite.
Fais gaffe a xbios(5), je crois me rapeller qu'il efface l'ecran et don il faut tout redessiner et c'est long.

ce que tu devrais faire, c'est utiliser un "ecran invisible" en ram ou tu dessine la partie revelée de l'image et tu t'en sert pour effacer tes sprites uniquement la ou ils sont dessinés et pas tout l'ecran a chaque fois. quand le joueur se deplace tu etends la zone revelée dans cet ecran ce qui fait que quand tu vas effacer le sprite du joueur ca va tout mettre a jour nickel.

vince :
y'a quand même un truc louche... si le sprite n'est qu'à moitié rempli, pourquoi en prendre un deux fois plus grand pour les décalages ?

C'est une spécialité des sprites de l'atari !!!!! Si tu veux que cela pousse un peu faut mangé plein de mémoire !!


GT Turbo ( )

X données du sprite (le sprite fait 16 de large pour une ligne dans mon exemple)
_ pour l'espace vide (mon sprite réel fait 8 donc je rajoute 8 vides)

XXXXXXXX________ 

_XXXXXXXX_______ 

__XXXXXXXX______ 

___XXXXXXXX_____ 

____XXXXXXXX____ 

_____XXXXXXXX___ 

______XXXXXXXX__ 

_______XXXXXXXX_ 

________XXXXXXXX

avec 16 de large, on a toutes les positions, à quoi bon se péter le cul avec 32 ?

t'es libre de douter de ce que je dis, mais le mieux serait que tu codasse un peu sur un ST pour voir par toi meme, ca m'est deja difficile d'expliquer clairement ce que je sait alors si en plus faut discutailler sur des trucs alors la hein bon alors quoi non mais ho.
voila.

je veux pas discutailler, je veux juste comprendre...à quoi bon rajouter 16 _ à droite (ou a gauche) ? pour 8 X par lignes seulement...

Merci pour vos réponses mais je comprend toujours rien,ma routine que j'utilise fonctionne comme cela:
J'ai 3 écrans en mémoire ( A,B, écran physique et logique et C celui de donnée et sauvegarde ):
A est visible a l'écran
je sauvegarde le fond de B ou je vais mettre un sprite par rc_copy sur C
je transfére le masque du sprite (de C)avec rc_copy sur B
enfin l'image du sprite avec toujours rc_copy(C->B)
puis j'affiche l'écran B avec un bmove de 32ko sur xbios(2)
et pour finir je remet le fond sur l'écran A pour éffacer l'ancien sprite(rc_copy)

Ma routine est lente j'utilise 4 rc_copy par sprite plus un bmove de l'écran entier.
Bon je vais essayer de coder ce petit jeu et je posserais d'autres question pour l'optimiser en temps utile.

au lieu d'afficher l'ecran B par un bmove sur xbios 2 (A ?), tu devrais juste faire un SWAP des deux variables (A et B) et appele la fonction xbios 5 qui va bien pour changer les pointeurs des deux ecrans.
resultat identique, gros bmove tres gourmand en moins
par contre il faut gerer deux liste de restoration qu'il faut swapper aussi afin de ne jamais dessiner dans l'ecran physique mais toujours dans l'eccran logique.

vince, comme je l'ai dit, l'ecran d'un ST est géré par bloc de 16 pixels :

soit 16 couleurs = 4 bits 'dcba'
[code]
x : 1111110000000000
5432109876543210
offset 0 : aaaaaaaaaaaaaaaa
offset 2 : bbbbbbbbbbbbbbbb
offset 4 : cccccccccccccccccccccc
offset 6 : dddddddddddddddd
[/code]

toutes les routines d'affichage travail de cette maniere, et le probleme c'est quand tu veux afficher a un X qui n'est pas multiple de 16 : il faut shifter les valeures a ecrire pour positionner les bits au bon endroit et c'est tres long.
deja ca explique pourquoi on ne travail qu'avec des X multiples de 16.
pour accelerer l'affichage, il faut avoir 16 versions d'un meme sprite, de facon a precalculer les decalages.
si ton sprite fais 8x8 pour les routines d'affichage il sera geré comme un 16x8 sauf qu'en plus il y aura un AND pour chaque mot copié afin d'eliminer les 8 pixels indesirables. donc autant faire tout de suite un 16x8 ca evite les ANDs.
ensuite, quand tu predecale ton sprite, puisque tu est en 16x8 tu doit passer en 32x8 pour alloué les 16 nouveaux bits pour stocker les bits qui vont sortir a gauche de chaque mot.

voila voila

personellement, je code que pour STE et j'utilise le blitter qui fait les decalages gratuitement, mais ca evite pas de travailler en multiples de 16 et d'ajouter 16 pixels vides pour nourrir le decalage (bon en fait ya une ruse on peut dire au blitter d'inventer un mot supplementaire a la fin de chaque ligne mais la ca change tout le setup du blitter donc pour l'instant je m'attarde pas la dessus).

note : pour abcd c'est plus lisible avec une police a espacement fixe

1111110000000000   : x
5432109876543210
aaaaaaaaaaaaaaaa : offset 0
bbbbbbbbbbbbbbbb : offset 2
cccccccccccccccc  : offset 4
dddddddddddddddd : offset 6

C'est chiant, la preview n'affiche pas la même chose que le texte une fois posté.
Je viens d'essayer avec différentes balises et les effets ne sont pas ceux espérés.

Edit bis, au temps pour moi, ça fonctionne avec la balise pre (et le bon nombre de charactères).

je vois bien ce que tu veux dire, à ceci près que tu prévois un alignement pour les "piexels indésirables", inutile à mon sens... enfin si vous avez assez de ram pour faire de tels gachis... tant mieux pour vous

vince :
je vois bien ce que tu veux dire, à ceci près que tu prévois un alignement pour les "piexels indésirables", inutile à mon sens... enfin si vous avez assez de ram pour faire de tels gachis... tant mieux pour vous

Une fois que tu a codé une routine de sprite sur un stf, une routine temps réel et une prédécaléé, tu t'y connais a un point en sprite tu peux meme pas savoir, c'est pour cela que codé sur une Jag avec des spritos en hard, cela va etre le bonheur !!


TG Tourb

Vince, je m'amuse pas a raconter des conneries sur les forums pour m'amuser...

tobe :
Vince, je m'amuse pas a raconter des conneries sur les forums pour m'amuser...

Non je te rassure il ne s'amuse pas a raconté des conneries sur les forums, je peux confirmé ces dires, dévéllopé une routine de sprite sur un ST, c'est plus un exercice de fou furieux que de la programmation pure, d'ailleurs quand j'ai fais mes premiers essais au blitter (Coz j'ai vu Roger et cela m'a impressionné !) c'était magique le blitter, pas de décalages, des valeurs dans des registres et hop le tour est joué !!


GT D'accord avec mon copain Tobe ( )

Vince, je m'amuse pas a raconter des conneries sur les forums pour m'amuser...

j'ai jamais dit ça, j'ai juste demandé à comprendre l'utilité des 16 octets en rabbe

Normalement la mémoire vidéo : Pixel-00  Pixel-01 Pixel-02 Pixel-03 ...
Offset en mémoire vidéo      : n+0                n+1               n+2 ...
Numéro des bits par octet    :  7 6 5 4   3 2 1 0  7 6 5 4  3 2 1 0 ...
Les bits en 16 couleurs      : d0c0b0a0  d1c1b1a1 d2c2b2a2 d3c3b3a3 ...

Alors normalement, à l'octet n+0 de la mémoire vidéo, on aurait les deux
premiers pixel. Mais ça justement, c'est la théorie, et la mémoire vidéo
des ATARI (en mode palette) est une vraie merde. Les bits sont classés par
paquet de 16 bits de même poids, c'est ce qu'on appelle les plan de bit :

Offset : n+0                              n+2
Bits   :  F E D C B A 9 8 7 6 5 4 3 2 1 0  F E D C B A 9 8 7 6 5 4 3 2 1 0 ...
Plan   : aFaEaDaCaBaAa9a8a7a6a5a4a3a2a1a0 bFbEbDbCbBbAb9b8b7b6b5b4b3b2b1b0 ...

Donc si on suit bien, vous aurez compris que le bit 0 du premier pixel se
trouve... 16 bits après le début de la mémoire !

Imaginons que notre sprite de 16 couleurs fasse 2 pixels de large :

Sprite : Pixel-00  Pixel-01
Offset : n+0
Bits   : d0c0b0a0  d1c1b1a1

Pour l'écrire au premier pixel de la mémoire vidéo, voilà comment il faudrait
décomposer les plans et ranger les bits. Attention les yeux :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 ............................a1a0
n+00000002          1 ............................b1b0
n+00000004          2 ............................c1c0
n+00000006          3 ............................d1d0

n+00000008 16-31    0
...          ...  ...

De ce fait, ton sprite, au lieu de tenir sur 1 octet (2 fois 4 bits) tiens
en... 4 plans de 16 bits (4 fois 2 octets, soit 8 octets) !!!

Si tu veux ensuite positionner ton sprite sur les pixel 1/2 de ton écran
plutôt que les pixels 0/1, voici ce que tu dois écrire en mémoire :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 ..........................a1a0..
n+00000002          1 ..........................b1b0..
n+00000004          2 ..........................c1c0..
n+00000006          3 ..........................d1d0..

n+00000008 16-31    0
...          ...  ...

Vu le foutoir que ça implique, de passer de 'd0c0b0a0 d1c1b1a1' à quelque
chose comme '..........................a1a0.. ..........................b1b0..
..........................c1c0.. ..........................d1d0..', on
précalcule les 16 décalages possibles avec un masque supplémentaire :

*** Décalage 0 pixel :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 ............................a1a0
n+00000002          1 ............................b1b0
n+00000004          2 ............................c1c0
n+00000006          3 ............................d1d0

n+00000008 16-31    0
...          ...  ...

Masque
n+00000000  0-15    0 ............................ 1 1
n+00000002          1 ............................ 1 1
n+00000004          2 ............................ 1 1
n+00000006          3 ............................ 1 1

*** Décalage 14 pixels :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 a1a0............................
n+00000002          1 b1b0............................
n+00000004          2 c1c0............................
n+00000006          3 d1d0............................

n+00000008 16-31    0
...          ...  ...


Masque
n+00000000  0-15    0  1 1............................
n+00000002          1  1 1............................
n+00000004          2  1 1............................
n+00000006          3  1 1............................

Maintenant y'a le problème quand on veut décaler de 15 pixels, on se trouve
avec un plan sur un paquet de 16 bits, et l'autre plan sur le paquet suivant :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 a0..............................
n+00000002          1 b0..............................
n+00000004          2 c0..............................
n+00000006          3 d0..............................

n+00000008 16-31    0 ..............................a1
n+0000000A          1 ..............................b1
n+0000000C          2 ..............................c1
n+0000000E          3 ..............................d1

n+00000010          0
...          ...  ...

Bien sûr avec les masques idoines ! C'est à ce moment que votre sprite de
1 octet passe à... 16 octets ! Et comme il faut compter le masque de la
même taille, on passe à 32 octets ! Cependant ça ne prendra pas plus de
place tant que le sprite ne fera pas plus de 16 pixels !

On peut cependant limiter la casse en ne faisant que 8 prédécalages :

*** Décalage 0 pixel :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 ............................a1a0
n+00000002          1 ............................b1b0
n+00000004          2 ............................c1c0
n+00000006          3 ............................d1d0

n+00000008 16-31    0
...          ...  ...

Masque
n+00000000  0-15    0 ............................ 1 1
n+00000002          1 ............................ 1 1
n+00000004          2 ............................ 1 1
n+00000006          3 ............................ 1 1

*** Décalage 7 pixels :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 ..............a1a0..............
n+00000002          1 ..............b1b0..............
n+00000004          2 ..............c1c0..............
n+00000006          3 ..............d1d0..............

n+00000008 16-31    0
...          ...  ...


Masque
n+00000000  0-15    0 .............. 1 1..............
n+00000002          1 .............. 1 1..............
n+00000004          2 .............. 1 1..............
n+00000006          3 .............. 1 1..............

On obtiendra les 8 prédécalages suivants en faisant juste une inversion
sur les octets qui composent les plans :

*** Décalage 8 pixel (0 pixel inversé) :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 ............a1a0................
n+00000002          1 ............b1b0................
n+00000004          2 ............c1c0................
n+00000006          3 ............d1d0................

n+00000008 16-31    0
...          ...  ...

Masque
n+00000000  0-15    0 ............ 1 1................
n+00000002          1 ............ 1 1................
n+00000004          2 ............ 1 1................
n+00000006          3 ............ 1 1................

Histoire de vous faire peur, imaginez ce que ça donne en 256 couleurs
(c'est à dire 8 plans) :

Sprite : Pixel-00           Pixel-01
Offset : n+0                n+1
Bits   : h0g0f0e0 d0c0b0a0  h1g1f1e1 d1c1b1a1

*** Décalage 0 pixel :

Offset     Pixel Plan Bits
                       F E D C B A 9 8 7 6 5 4 3 2 1 0
n+00000000  0-15    0 ............................a1a0
n+00000002          1 ............................b1b0
n+00000004          2 ............................c1c0
n+00000006          3 ............................d1d0
n+00000008          4 ............................e1e0
n+0000000A          5 ............................f1f0
n+0000000C          6 ............................g1g0
n+0000000E          7 ............................h1h0

n+00000010 16-31    0
...          ...  ...

Masque
n+00000000  0-15    0 ............................ 1 1
n+00000002          1 ............................ 1 1
n+00000004          2 ............................ 1 1
n+00000006          3 ............................ 1 1
n+00000008          4 ............................ 1 1
n+0000000A          5 ............................ 1 1
n+0000000C          6 ............................ 1 1
n+0000000E          7 ............................ 1 1

Ducoup, nos 2 pixels prennent... 16 octets, soit 32 octets
avec le masque :/ En comptant 8 prédécalages, ça donne donc
256 octets !!!

C'est pour ça que le plus simple est soit de travailler en
monochrome (1 bit par pixel), soit en NTC sur Falcon, ou
TC sur MegaST/TT avec une carte vidéo qui va bien :/

Ca peut ne pas sembler clair, pourtant, relisez bien tout ça !

Kochise

D'ac avec GT, sur ST on est des dieux du code, voila...