J'avance ! Je ne sais pas si cela va être la forme définitive du jeu dans les emplacements de cadre, mais pour le moment ça marche pas trop mal. J'ai ma carte qui s'affiche et se met à jour quand je me déplace. (11 x 7 tuiles. Chaque tuites fait 16x16 points).
A l'heure actuel le déplacement et l'affichage de tuile est opérationel. Je peux mémoriser 64 tuiles provenant d'un fichier externe. Le background est une image pi1 qui possède aussi la palette de couleur du jeu.
Au niveau de la gestion de passabilité, plusieurs méthode me sont donnée. Je viens de tester avec la méthode blocage directement sur un bit de la tilmap. Mais je pense re faire un tableau avec des donnés de tiles. Chaque tile aura son octet. Un bit indique si la case est traversable ou pas. D'autre peuvent permettre de lier un fond de combat, un autre si la case procure des dommages. Et pourquoi pas imaginer un autre bit qui offre la possiblité de passer sur la case avec certaine condition ?
J'aimerais faire un moteur portable. Le corps du moteur doit être facilement transportable sur d'autre machine. Comme le MSX2. Pour cela au niveau du code, je dois bien l'organiser pour séparer les fonctions du moteur en lui même et les routines propre à l'atari St.
A l'heure actuel au niveau de la mémoire des données :
- 4 ko pour la mémorision de la tilmap.
- 4 ko pour mémoriser le tableau des événements.
- 8 ko pour la mémorision de la planche de tilset. (64 x 128 octets)
- 64 octets pour mémoriser les informations de tiles.
Ce qui fait en gros 16ko de donnée pour l'affichage de la map du jeu.
Une bank sur CPC amstrad 6128 par exemple. Cela peut donner des idées.

Je découvre la programmation sur atari ste en langage C. Enfin peux importe le langage, le plus important c'est d'entrer dans les entrailles de la machine. Son OS. Je peux vous dire que son OS est diablement efficace et possède des fonctions à gogo. Autant que "puissance graphique" du ST nous sommes très loin des amiga, (Ce n'est pas le même prix non plus à la sortie des machines), au tant qu'au niveau os et fonctionnalité pour une machine de 85 cela m'impressionne... Le St possède des DOS. La gestion de disquettes il connait très bien... Formatage, copie, création de dossier... Et tout ça qui peux être utilisé en programmation... Ok les machines 8bits savent le faire xd.

La mémoire vidéo est par plan. (Comme l'amiga). Ce qui rend un peu plus difficile le traitement des "images". Ceci dit ce n'est pas la mort non plus.

Je suis en train de créer ou tenter de créer un RPG occidental de type post apo, a l'heure actuel j'arrive à afficher ma carte de jeu(11x7 tiles de 16x16 pixel), et à la déplacer en mode case par case avec le clavier. Mon workflow est simple. J'ai mémorisé en mode linéaire dans un tableau, les tiles. Un tiles fait 128 octets. Ensuite je re décompose ça sur l'écran vidéo mon tiles par 16 lignes de 8 octets. Le ST travaille en mots de 2 octets. Chaque mots encode 8 points à l'écran dans le plan. Donc 2 octets, 16 points. Cela tombe bien, c'est la largeur de mon tiles. commes nous sommes en mode Lowres, il faut 4 plans pour reconstituer nos couleurs. Donc 8 octets pour encoder une ligne de 16 pixel.

A l'heure actuel je n'arrive pas à travaillé avec un sprite avec couleur transparente avec la méthode des "tiles". Le St possède une fonction sprite software. Je pense que je vais fouinner de ce coté la ...

Le retour sur micro se fait, machine, l'atari ST. J'ai réussis à compiler du C pour le ST en Cross Dev avec GCC. A l'heure actuel j'arrive à afficher une image DEGA à l'écran. (Lenna !!!)

L'envie de trifouiller le ST, retourner sur le C64 et le MSX...

Au niveau des entrée de janvier... :

Un petit jeu sur Master System : Alien 3

L'everdrive Pro pour la Famicom

Un livre sur les consoles 8 bits.

Le Tome 1 du livre du developeur, trop bien, j'ai les deux tomes.

Bien débuté avec le ST/Ste. Dispensable mais bon.

Truc et Astuce pour le ST !

Computer Graphics en C, pas encore lu, mais gros pavé pour les graphismes micro ordinateur.

Le micro Yeti pour mes vidéos

Nes, master system, megadrive, super nintendo, game boy,dreamcast... Des petites consoles dont j'ai réussis à mettre la main dedans. Qu'elle plaisir de pouvoir lancer des homebrew sur console. La master system, console de coeur. J'ai réussis à sortir un jeu en cartouche. Prisonnier II. Vendu entre 20 et 30 exemplaires. C'est un petit chiffre si je compare à Twin Dragon, ou micro mage pour ne citer que deux grands homebrews sur la nes, mais un grand plaisir pour moi. Une victoire d'arriver au bout d'un projet... Ma vie de créateur de jeu s'est beaucoup ralentie depuis un certain temps. A vrais dire je ne sors plus de jeu depuis que je n'utilise plus clickteam fusion mise à part le prisonnier de la master system et des version déma de ce meme jeu sur colecovision et amiga...

Es le temps de faire mes adieux au monde du jeu vidéo ? Au monde de la création du jeu vidéo ?

Mais vous êtes fous ? Oh que non. Mais peut être qu'une page va se fermer. La page de la console vidéo pour revenir à mon première amoure. (Ma copine bien sure), mais aussi le micro ordinateur 8 et 16 bits. L'envie de revenir sur ce genre de machine. Ceux pour quoi ce site existe à la base. Amistrad !!! La contraction de Amiga et Amstrad ! Jolie non ?

Je pense donc que l'année 2020 sera l'année du micro ordinateur et le retour au source que j'aime tant. Le CPC, L'amiga, l'atari ST, le C64 dont j'ai promis un SDK en C xd, Et très certainement remettr en place mon park informatique pour notre plus grand plaisir !!!

Bisous

Un peu de technique snes ... Ce matin je me suis penché sur comment certain RPG de la snes utilisait la mise à jour de la tilemap. La Tilemap c'est la zone mémoire qui contient l'index des tiles à afficher sur l'écran pour faire simple...

Sur Master System, l'écran visible permet d'afficher 32 tiles sur 24. Mais possède 4 tiles non visibles en "bas". Un scrol vertical est plus facile sur la MS qu'un scrol horizontal car ce qui est affiché à l'écran c'est la tilmap complet. Ceci dit il existe une option pour cacher à l'affichage la première colonne pour que la mise à jour des tiles soit caché pour un scrolling. (Donc faut injecté des tiles par tiles-8x8 en horizontal et on peux directement faire du 16x16 en vertical. Pas pratique.

Sur NES c'est plus agréable car il est possible de foutre un écran en plus en horizontal et vertical. Si ne dit pas de bétise la nes permet d'avoir trois écran en mémoire. 2 (ou 3 je ne sais plus)virtuel et 1 affiché bien sur. Ce qui permet de facilité le scrolling.

Je me suis penché ce matin sur la snes et certain RPG. La SNES à 4 configurations possibles. - Le 32x32 tiles. Un seul écran. Avec une zone petite zone invisible en verticale. - Le 64x32 tiles. Ce qui permet de facilité le scrooling horizontal car il y a deux écran cote à cote. -L e 32x64 tiles. Même chose que plus haut mais sur la verticalité. -L e 64x64 tiles. 4 écrans.2x2.

FF4, Secret of mana utilises en mode "carte" le 64x32. Ce qui permet de facilité la mise à jour de la map en scrolling.

FF6 à une particularité. Il reste en 32x32 ceci dit comme la master system, il cache les 8 premier pixel à gauche. ET à droite (chose que la MS ne sait pas faire) pour facilité la mise à jour des tiles de 16x16 très certainement. Verticalement il y a de l'espace. Donc la résolution visible de FF6 est plus petit que FF4. (-16 pixel donc un meta tiles en moins. Méta tiles c'est tout simple un regroupement de tiles qui dans la majeur des case c'est 4 tiles de 8*8 pour donner un tiles de 16x16 )

Le Zelda lui fonctionne en 64x64. Sur le peux que j'ai analysé beaucoup de map n'a pas de modification de map à la volé. La carte est chargé entièrement sauf certain passage comme celui du chateau en extérieur. Mais j'ai pas tout regardé. Pour cela qu'il y a des "chargement de map" avec déplace de caméra...

Les "RPG" utilise souvent le Mode 1 de la snes qui offre 3 plans de background. Les deux premiers plan permettes d'utiliser des palettes de 16 couleurs et le dernier est limité à des palettes de 8 couleurs. Souvent utilisé pour le Hud de zelda ou les boites de dialogue. Je pense que c'est le plan Windows. A ce petit jeu la mégadrive possède un plan backgound et après le choix entre un 2em plan background ou un plan windows (qui est fixe et ne scroll pas) si je ne dit pas de bêtise...

Bref ce matin je n'ai pas programmé, mais j'ai appris plein de truc en décortiquant rapidement certain jeu et en discutant avec mon ami Alek Maul.

Alors oui, peut être ce petit rêve de faire un RPG sur console va peut être se réalisé. Mais j'ai du travaille à faire et encore plein de connaissance à prendre... Wait en scie à bois comme les chiens !!!

La Super Nintendo, (ou super famicom au japon), est ma 2em console de coeur après la séga master system.
Qu'elle plaisir de voir un Hello World sur la vrais machine, compilé par ses mains. J'utilise le devkit d'alekmaul, mais je voulais compilé avec mon traditionel.bat.
Pour cela, je devais comprendre qu'elles sont les lignes de commande à utiliser. Et voici une petite explication en reproduisant au plus proche le workflow d'alekmaul :

- il faut passer du fichier C au fichier assembleur mais avec un préfixe ps. Pour cela il faut utiliser le logicil 816-tcc et linker le dossier include de la librairie d'alek.
816-tcc -Wall -I lien\include -c main.c -o main.ps

-Alek passe par une optimisation. 'deux fois'. Avec 816-opt.py (donc python doit être installer), et constify. Voici les deux lignes de commandes.
816-opt.py main.ps >main.asp
constify main.c main.asp main.asm

-Maintenant il faut passerr à l'assembleur et transformer le main.asm, le data.asm et le hdr.asm en fichier obj.
Pour cela on utilise le logiciel wla-65816
wla-65816 -io main.asm main.obj
wla-65816 -io data.asm data.obj
wla-65816 -io hdr.asm hdr.obj

-L'étate ou il faut réunir tout les objets pour créer le fichier binaire utile. Dans notre cas un .sfc pour la super nintendo/famicom.
Cette fois si c'est au tour du linker wlalink entrer en jeu. Il faut linker votre fichier obj de codage , date et hdr et les bibliothques du sdk.
wlalink -dsnov data.obj hdr.obj crt0_snes.obj main.obj libc.obj libm.obj libtcc.obj snes.sfc

-Un petit coup de finalisation avec snestools est utile.
snestools -hi! -ht"snes" snes.sfc

Ceci est un exemple d'utilisation. Il faut bien penser à indiquer ou se trouve les logiciels en question, et le include de librairie, les fichiers.obj de la lib. Mais qu'elle pied quand cela fonctionne comme on le souhaite. Pour moi cela me permet de compiler comme je veux, et sur ce que je veux. Me reste un peu à optimiser mon.bat comme je le fais avec mes .bat du compilateur sdcc, et à entrer dans le secret de la super nintendo.

Retrouver le pvsneslib a cette adresse :https://github.com/alekmaul/pvsneslib

Je vous souhaite une bonne année 2020. L'année 2019 vient d'être archivé. Cela fait 6 ans que j'ai ce site mais cela fait un petit moment que je ne fais pas de compte rendu de mes test snif.
Lien

Coté livre, deux nouveaux livre pour ma collection de livre de développement pour l'atari st.

Livre pour commodore 8bits

Livre pour l'amiga

Un lecteur de carte Microsd pour la dreamcast

J'ai réçu plusieurs jeu de super famicome

Le Homebrew Sydney Hunter sur snes. En cartouche europe/jap et us.

Une petite carte flash pour l'asmtrad GX4000,464 plus et 6128 plus. La C4CPC !

Mon parc de TV accueil un 4em écran "pro". Un petit PVM. 9220

Deux logiciels pour le stos

Je suis aussi sur le codage d'un mini sdk pour la game boy. Happy GB (mais qui devrait changer de nom, un émulateur porte ce nom).
A l'heure actuel les fonctions exsitantes permetent de gérer la gameboy standard avec une cartouche de 32ko. Le Happy permet d'afficher les sprites (40), charger des données brutes en mémoire (non compressé), gérer le scrolling.
Afficher des tiles à l'écran, et gérer les entrées. Il n'y pas de module sonore. Mais la fonction peek et poke est présent pour taper dans la mémoire de la machine facilement.
Une bêta sera délivré bientôt.