Nouveau Quadratarist

[zisquier]

Irfan View, même si c'est pas le plus simple à utiliser...
Sinon, quelqu'un ici même à fait une version WEB, mais plus moyen de me rappeler qui... Il doit y avoir le lien dans le topic sur la conversion de Metal Slug, il me semble...

Je viens de le télécharger et installer mais il ne propose aucun format de fichier que par exemple DEGAS sur atari peut utiliser :/

[zisquier]

Irfan View, même si c'est pas le plus simple à utiliser...
Sinon, quelqu'un ici même à fait une version WEB, mais plus moyen de me rappeler qui... Il doit y avoir le lien dans le topic sur la conversion de Metal Slug, il me semble...

Merci
Par contre çà ne me créer pas d'image *.i1 ou *.i2 ni *.i3
j'ai essayé XviewPM c'est pareil

[zisquier]

Autre recherche :https://ataritools.fr.gd/DEGAS-ELITE-XL ... IT-k2-.htm
très bon soft mais obligé d'importer un fichier déjà au format *.i1 etc ...

[zisquier]

çà y'est !!!!!!
BON )))) j'ai trouvé un soft qui s'appelle Multipaint et qui importe en png ou autre et sauvegarde en .pi1 !
voici l'URL pour ceux qui comme moi chercherait : http://multipaint.kameli.net/
Et du coup merci à Shaoth de mon discord (un mec ultra doué en GFA qui code un jeu qui s'appelle Catacomb

[zisquier]

Quand tu te sentiras à l'aise :

• The documentation for TOS pour potasser Bios, Xbios et GEMDOS.
• ST/E Blitter FAQ
• l'Atari Compendium

J'ai compris comment fonctionnait les appelles du XBIOS avec l'instruction Trap #14 et les paramètre qui sont lus dans la pile, c'est une super doc y'a plein plein de possibilité !! merci pour ces liens !

[sporniket]

De rien, c'est ce que j'utilise moi-même.

[BlankVector]

Vincent Rivière a fait des vidéos tutos d'assembleur sur sa chaine vretrocomputing : https://www.youtube.com/playlist?list=P ... agQlvo-zUo

Merci pour la pub

Merci oui je connait les tuto de Vincent Rivière et sur atarist.free mais malheureusement çà va pas assez loin, çà ne m'explique pas comment le CPU communique avec les péripherique ni comment la RAM est agencé

Tout ça est expliqué en détail et en français dans Le livre du développeur Tome 1. Les autres documents essentiels, déjà cités et en anglais, sont l'Atari Compedium et tos.hyp (même s'ils se focalisent plus sur les OS, Falcon et MiNT inclus, plutôt que sur le hardware).

Et concernant le 68000, tu as déjà trouvé tout ce qu'il faut : les cours de Féroce Lapin (sur le site de Zorro 2) le livre Mise en œuvre du 68000. Sans oublier la doc officielle de Motorola, en anglais : MOTOROLA M68000 FAMILY Programmer’s Reference Manual.

Voilà des bases solides pour commencer !

[zisquier]

Vincent Rivière a fait des vidéos tutos d'assembleur sur sa chaine vretrocomputing : https://www.youtube.com/playlist?list=P ... agQlvo-zUo

Merci pour la pub

Merci oui je connait les tuto de Vincent Rivière et sur atarist.free mais malheureusement çà va pas assez loin, çà ne m'explique pas comment le CPU communique avec les péripherique ni comment la RAM est agencé

Tout ça est expliqué en détail et en français dans Le livre du développeur Tome 1. Les autres documents essentiels, déjà cités et en anglais, sont l'Atari Compedium et tos.hyp (même s'ils se focalisent plus sur les OS, Falcon et MiNT inclus, plutôt que sur le hardware).

Et concernant le 68000, tu as déjà trouvé tout ce qu'il faut : les cours de Féroce Lapin (sur le site de Zorro 2) le livre Mise en œuvre du 68000. Sans oublier la doc officielle de Motorola, en anglais : MOTOROLA M68000 FAMILY Programmer’s Reference Manual.

Voilà des bases solides pour commencer !

Merci beaucoup Oui entre temps j'ai eu le temps de potasser les cours de ST Mag 64 et çà m'a permis d'avoir certain concept expliqué pour comprendre mieux les vidéo de Vincent Rivière, et du coup je vais relire Lapin Féroce car je me sent prêt là. Je suis ultra motivé.
J'ai comprit ce qu'était le TOS et ce que l'on pouvait faire avec le GEMDOS et XBIOS pour le moment grace à l'insctruction TRAP qui va lire les paramètre directement dans la pile et execute ce que l'on souhaite. Franchement c'est top !

J'ai réussit a faire des trucs sympa déjà

[zisquier]

Hello, bon j’ai appris déjà quelques petits trucs, et je commence à explorer ce que peut donner l’affichage d’un Sprite, mais je suis confronté à une spécificité de l’affichage sur l Atari , à savoir les colonnes de 16 pixels.
Visiblement quand je recopie des Long mot à l’écran, donc quatre octets, pour un Sprite qui fait huit octets de longueur je suis obligé de démarrer sa coordonnées X, sur un pixel multiple de 16.

Quand j’essaye de l’afficher sur une coordonnées différentes, ça me décale une couleur, bref savez-vous comment ça fonctionne ?

Voici le dernier stream, de mes progrès :
https://youtu.be/hPbQ8izHoPA

[sporniket]

C'est ici que les mots "prédécalage" et/ou "blitter" entrent dans la danse.

Rappel de la structure d'écran :

1. Comme tu l'as constaté, regroupement en colonnes de 16 pixels, chaque groupe étant représenté par "un certains nombre de mots" (valeurs sur 16 bits, largeur du bus de données de l'atari ST). Le nombre de mots dépend du nombre de bits nécessaire pour coder le numéro de la couleur du pixel : 1 bit (0 à 1) pour le mode monochrome, 2 bits (0 à 3) pour la moyenne résolution, 4 bits (0 à 15) pour la basse résolution.

2. Et là, c'est le drame (pour nos neurones), alors prenons un exemple : si le sprite est un pixel à l'extreme gauche du groupe, avec le-dit codé avec la couleur 12 , soit %1100 en binaire, on éparpille façon puzzle les 4 bits, chacun dans un mot et tout à gauche (bit 15), en partant du bit de poids faible(0) dans le premier mot, jusqu'au bit de poid fort (1) dans le quatrième.

Soit :

Code: Select all

0xxxxxxxxxxxxxxx
0xxxxxxxxxxxxxxx
1xxxxxxxxxxxxxxx
1xxxxxxxxxxxxxxx

Conséquence : Pour placer ce sprite à la position X = 4, chaque mot doit subir un décalage logique de 4 bits vers la droite, pour obtenir :

Code: Select all

----0xxxxxxxxxxx
----0xxxxxxxxxxx
----1xxxxxxxxxxx
----1xxxxxxxxxxx

Au passage, dans chaque mot on a perdu les 4 bits de droite dans l'opération.

Tout ça, c'est long à faire (surtout que sur le 68000, le temps pris par le décalage est proportionnel à la portée du décalage : pour faire un décalage de 4 bits, le 68000 procède à 4 décalage de 1 bit), et c'est embêtant.

Alors, deux solutions possible :

1. On précalcule tous les sprites décalés (décalage 1 à 15) dont on a besoin à partir du sprite normal (décalage 0)
2. Soit on demande gentiment au blitter de faire tout ça pour nous.

Voilà bon courage.

[Zorro 2]

Voici le dernier stream, de mes progrès :
https://youtu.be/hPbQ8izHoPA

Nouvel abonné ! ... et sur FB aussi

Ça fait très "oldschool" mais j'aime bien tes lignes de codes bien aérées avec les commentaires et que tu compiles direct sous Devpac 3.

Et oui ! Quand on découvre l'assembleur il y a beaucoup de boulots, même si tu as 16 registres il y a beaucoup de subtilités sur le ST
Par exemple en regardant une partie d'une de tes vidéos, n'oublie que les multiplications et les divisions se font par décalage de bits (instructions LSR ou ASR) car moins gourmand que les instructions originelles.

Bref, impatient de voir la suite

[zisquier]

C'est ici que les mots "prédécalage" et/ou "blitter" entrent dans la danse.

Rappel de la structure d'écran :

1. Comme tu l'as constaté, regroupement en colonnes de 16 pixels, chaque groupe étant représenté par "un certains nombre de mots" (valeurs sur 16 bits, largeur du bus de données de l'atari ST). Le nombre de mots dépend du nombre de bits nécessaire pour coder le numéro de la couleur du pixel : 1 bit (0 à 1) pour le mode monochrome, 2 bits (0 à 3) pour la moyenne résolution, 4 bits (0 à 15) pour la basse résolution.

2. Et là, c'est le drame (pour nos neurones), alors prenons un exemple : si le sprite est un pixel à l'extreme gauche du groupe, avec le-dit codé avec la couleur 12 , soit %1100 en binaire, on éparpille façon puzzle les 4 bits, chacun dans un mot et tout à gauche (bit 15), en partant du bit de poids faible(0) dans le premier mot, jusqu'au bit de poid fort (1) dans le quatrième.

Soit :

Code: Select all

0xxxxxxxxxxxxxxx
0xxxxxxxxxxxxxxx
1xxxxxxxxxxxxxxx
1xxxxxxxxxxxxxxx

Conséquence : Pour placer ce sprite à la position X = 4, chaque mot doit subir un décalage logique de 4 bits vers la droite, pour obtenir :

Code: Select all

----0xxxxxxxxxxx
----0xxxxxxxxxxx
----1xxxxxxxxxxx
----1xxxxxxxxxxx

Au passage, dans chaque mot on a perdu les 4 bits de droite dans l'opération.

Tout ça, c'est long à faire (surtout que sur le 68000, le temps pris par le décalage est proportionnel à la portée du décalage : pour faire un décalage de 4 bits, le 68000 procède à 4 décalage de 1 bit), et c'est embêtant.

Alors, deux solutions possible :

1. On précalcule tous les sprites décalés (décalage 1 à 15) dont on a besoin à partir du sprite normal (décalage 0)
2. Soit on demande gentiment au blitter de faire tout ça pour nous.

Voilà bon courage.

Ouaaaaah d’accord donc étant donné que 2 pixels représentent 1 octets, en mémoire dans le debugger on lira une valeur en hexadécimal qui finalement n’est pas explicite y’a qu’en binaire que l’on peut complément se représenter : l’es couleur sont dans l’ordre à l’écran mais dans le désordre en mémoire mais organisée tout de même … effectivement un vrai casse tête et j’imagine qu’il fait pas mal d’instruction pour en faire une routine d’affichage et donc manger un peu plus de temps CPU ?
Alors moi j’ai fait autrement mais ça bouffe de la ram à la place mdrrrr
Mes sprites occupent 2 blocs de 16 et je l’es dessine en les décalant de quelques pixel puis arrivé en fin de 2ème bloc je change pour les 2 blocs suivant.

Par contre le blitter je connaît pas du tout mis à part qui. Le trouve uniquement sur la gamme ste

[zisquier]

Voici le dernier stream, de mes progrès :
https://youtu.be/hPbQ8izHoPA

Nouvel abonné ! ... et sur FB aussi

Ça fait très "oldschool" mais j'aime bien tes lignes de codes bien aérées avec les commentaires et que tu compiles direct sous Devpac 3.

Et oui ! Quand on découvre l'assembleur il y a beaucoup de boulots, même si tu as 16 registres il y a beaucoup de subtilités sur le ST
Par exemple en regardant une partie d'une de tes vidéos, n'oublie que les multiplications et les divisions se font par décalage de bits (instructions LSR ou ASR) car moins gourmand que les instructions originelles.

Bref, impatient de voir la suite

Mais à part devpac existe t il’des solution pc utilisant notepad++ par exemple et qu’on assemble ensuite ?
LSR et ASR je connaît pas encore mais quand je chercherait à optimiser ça va être super utile

[sporniket]

Je ne sais pas si vasm dispose d'un binaire pour windows, mais c'est ce que j'utilise.

http://sun.hasenbraten.de/vasm/

La licence est embêtante pour faire des programmes commerciaux "en dehors de l'Amiga", mais sinon ça marche pas mal.

[terence]

Super ! N'hésite pas à poster des liens sur le forum

Et bien ils y sont plus haut ce sont ceux que j'ai checké mais sinon dans le numero 63 de ST Mag j'ai pu avoir des information très très bien expliqués également.
Sinon depuis ce matin je cherche sans succès comment mettre un fichier .png ou .jpeg au format lisible sur Atari (et que çà tienne sur une disquette)
sur CPC on a des outils PC genre CPC image converter, mais pour Atari il existe quoi dans ce genre ? (je connait déjà les soft gfx sur Atari même)

il va falloir te coder des outils sur PC, par exemple sous visual studio en C ou C++
utiliser une librairie déjà existante pour lire le format source style png, et transformer ça en bloc d'octets avec les plans et la palette convertie

[xdelatour]

GrafX2 devrait pouvoir faire ça, il importe et exporte pas mal de formats : http://grafx2.chez.com/

[EDIT:] Je viens de tester avec un gif (conversion vers Neochrome) et la palette n'est pas correcte

[EDIT 2:] Au temps pour moi, il fallait cliquer sur le bouton PAL (palette) et réduire le nombre de couleurs à 16

[zisquier]

Super ! N'hésite pas à poster des liens sur le forum

Et bien ils y sont plus haut ce sont ceux que j'ai checké mais sinon dans le numero 63 de ST Mag j'ai pu avoir des information très très bien expliqués également.
Sinon depuis ce matin je cherche sans succès comment mettre un fichier .png ou .jpeg au format lisible sur Atari (et que çà tienne sur une disquette)
sur CPC on a des outils PC genre CPC image converter, mais pour Atari il existe quoi dans ce genre ? (je connait déjà les soft gfx sur Atari même)

il va falloir te coder des outils sur PC, par exemple sous visual studio en C ou C++
utiliser une librairie déjà existante pour lire le format source style png, et transformer ça en bloc d'octets avec les plans et la palette convertie

Merci mais je ne sais pas coder autre quand assembleur moi lol mais j'ai trouvé y'a déjà plein d'outil très efficace qui existe depuis un moment

[dlfrsilver]

tu peux utiliser XNview sur PC, qui permet de convertir les images PNG ou JPG au format image atari style Degas Elite par exemple.