MSX Village forum

Voici le zip ui contien le nécessaire avec les sources

METALION.zip

Pour faire simple dans l'explication:

Je génère un scrool sans avoir à donner quelques coordonnées que ce soit. Ni dans la partie a charger, ni dans la partie à coller à l'écran.
Sans la moindre coordonnée, je créer un scrooling

L'idée est produire un scrooling le plus aboutis qu'il puisse être en Basic.
Que les décors puissent être changés/ modifiés le plus simplement du monde.

L'astuce des Bribes d'image apporte une solution complète à tous ces problèmes de coordonnées à devoir exprimer.
Le seul problème selon moi est de trouver le meilleur moyen au MSX de localiser un fichier à charger.

Le temps que met le MSX à retrouver le bon fichier bloque tout le prcessus et donc la possibilité au joueur de déplacer un sprite pendant cette latence

Le fait de pouvoir déplacer la table des SPRITES est une super solution. Cela signifie que l'on pourra profiter de SPRITES avec tous les avantages que cela représente

Merci de ton aide.

Encore une chose.. Si tu veux t'y coller, pars sur l'idée que les BRIBES à charger ne feront plus que 4 X 256 et non plus 8 X 256.

Ainsi, la boucle principale devra charger....

[11 X (4 X256)] chargés par BLOAD"XXXXXXXX.SCC",S,0-44
suivi de la seconde zone...
[ 53 X (4 X256)] chargés par BLOAD"XXXXXXXX.SCC",S

Les Images sources restent les mêmes à savoir..
IMAGE0.BMP (44X256)
suivie de...
IMAGE1.BMP (212X526)
Ces deux images sont les gabarits de la source découpées sur PC.

Ensuite...Je convertis avec BMP2MSX

Et enfin, je dois modifier mon GENERAT.ASC pour qu'il créer des Bribes de 4 X 256 et non plus des Bribes de 8 X 256.

Enregardant les fichiers joints, tu comprendras mieux.

Bonne soirée et merci pour l'aide

Moi aussi je n'avais pas compris exactement le but recherché d'Igal

En faite c'est un scrolling en streaming c'est ca ?

Effectivement c'est une sorte de streaming
Chaque bribe à charger ne pèse qu'un ou deux Ko

Voici un dessin en espérant que c'est plus clair

Désolé pour la taille du graphique mais c'est pour résumer ce qui se passe dans ma tête

Lut Métalion.

Actuellement, toutes les Bribes sont stockées dans la CF virtuelle de BlueMsx.

La méthode mise en oeuvre pour le scroll nécessite de distinguer les séries de Bribes larges de 8 Pixels des celles larges de 4 Pixels.
Chaque Bribes de 8X256 Pixels en SCREEN 12 pèsent 2 055 Octets.
Remplir l'écran + Zone réservée soit 256X256 nécessite [5 X (8X256) + 1 X (4X256)] + [26 X (8X256) + 1 X (4X256)]
Soit 33 Fichiers à charger pour remplir la totalité des 256X256

La méthode envisagée pour le scroll ne contient plus que des Bribes larges de 4 Pixels et ne nécessitent plus de les distinguer
Les Bribes de 4X256 Pixels en SCREEN 12 pèsent 1 031 Octets.
Remplir l'écran + Zone réservée soit 256X256 nécessite [11 X (4X256] +[53 X (4X256)]
Cette méthode nécessite deux fois plus de fichiers pour couvrir les 256X256
Soit 64 Bribes des 1031 Octets
[(64 Bribes X 1031octets) = 65984 Octets / 1024 Octets = 64,4375 Ko
Les Deux zones d'affichages additionnées (Soit 256 X256) nécessitent 64,4375Ko.

En extrapolant, on peut en tirer les conclusions hypothèses suivantes:
La plus grande adresse accessible sur MSX (8Bits) étant FFFF soit 65535.
La capacité du VDP à afficher 256X256 à peut être été bridée en la divisant en deux zones distinctes:
1) La zone principale 212 X 256 exploitables avec les adresses 65535 (FFFF)
2) La zone en bas de l'écran qui fait 44 X 256 accessible simplement avec une Valeur Négative pouvant prendre comme point de référence la ligne ZERO et ou l'on accède à la dernière ligne de cette zone par...
BLOAD"FICHIER.SCC",S,[b]0-44 (Pour accéder à la ligne accolée à la ligne 212)
BLOAD"FICHIER.SCC",S,[b]0-43
Etc...Jusqu'à
BLOAD"FICHIER.SCC",S,[b]0-1

J'ai pas essayé, mais peut être qu'il est possible d'accéder à cette zone avec une valeur Positive du genre...
BLOAD"FICHIER.SCC",S,212+1 (Pour accéder à la ligne accolée à la ligne 212)
BLOAD"FICHIER.SCC",S,212+2
Etc...Jusqu'à
BLOAD"FICHIER.SCC",S,212+44

@Métalion;
J'ai pensé à séparer les bribes par groupes/Répertoires:

REPERTOIRE 0
00000000.SCC
00000001.SCC
Etc....
00000064.SCC

REPERTOIRE 1
00000000.SCC
00000001.SCC
Etc....
00000064.SCC

REPERTOIRE 2
00000000.SCC
00000001.SCC
Etc....
00000064.SCC

REPERTOIRE ETC...
Le MSX n'aurait à chercher le bon fichier qu'au milieu de 63 autres au lieu de le chercher au milieu de 500 autres fichiers

Pour ce qui est du Stockage en RAM, j'y ai pensé aussi mais...avec 1000 Bribes de 1031 Octets on a besoin de 1006Ko soit 1Mo de Ram environ
Ca réduit considérablement le nombre de personne pouvant en tirer partie. (Ca reste quand même une possibilité à envisager). Edité par igal Le 15/09/2014 à 12h22

Igal,

Voici déjà un premier brouillon de travail, fait avec les 3 premiers écrans.

Pour l'instant, j'ai gardé une taille des bribes à 8px, mais j'ai passé la hauteur d'écran à 192px, ce qui est divisible par 8 (et donc plus simple à gérer). Bien évidemment, il y a toujours le temps de latence du chargement des images qui est problématique ...

Toaplan.dsk

Igal,

Je ne pense pas que le nom du fichier ou sa localisation ait une quelconque importance dans le temps de chargement. L'adresse relative de chaque fichier est stocké dans la FAT, et le temps d'accès moyen est probablement le même pour tous les fichiers. Eventuellement, sa localisation physique sur le média peut influencer (sur une disquette par exemple), mais c'est un paramètre qu'on ne maitrise pas, étant donné qu'on ne décide pas de l'emplacement physique d'un fichier (c'est le système qui le fait).

Ce qu'il se passe probablement dans le cas de chargements à répétition, c'est que le MSX utilise certainement un buffer de données, qui se remplit et qui se vide par alternance. Ce phénomène de pompage n'est pas synchronisé (forcément) avec les appels par le BASIC et les accès à la VRAM, et il y a donc des chargements plus longs et d'autres plus courts.

Le problème se double par le fait que les fichiers sont lus en interruption : toute tâche du MSX est suspendue pendant le chargement d'un fichier (il n'y a pas de tâche en parallèle). Je l'ai confirmé tout à l'heure en essayant de modifier le registre 24 du VDP à intervalles réguliers, en utilisant ON INTERVAL. Les appels réguliers par cette instruction étaient gelés pendant le temps de l'accès au fichier (alors que ces appels sont basés sur les interruptions hardware), ce qui prouve que les accès fichiers sont prioritaires sur tout le reste.

La seule solution raisonnable pour avoir un scroll fluide est de stocker la map en mémoire. Le problème est alors la taille de ta map : chaque écran en 256 x 192 pèse 48Ko en SCREEN12 et une map complète de niveau ne peut être stockée en RAM (du moins dans des machines "normales")

Je pense que la solution est de passer à un mode graphique inférieur (SCREEN5 par exemple), et de stocker les maps en RAM (via le mapper) ou dans une ROM.

Ceci dit, je veux bien continuer à travailler sur le schéma que tu as commencé à développer, mais il faut que tu saches que les problèmes de temps d''accès fichier aléatoire continueront à être un gros problème. Mes programmes de génération et de scrolling sur la disquette sont flexibles, je vais les modifier pour passer en 4px, on verra ce que ça donne.

Bonsoir Eric,

Bonne idée, le Nestor Basic
Et particulièrement à la gestion des segments de RAM, et des transferts en VRAM !

Après ça dépend de ce que Igal veut faire ...
Edité par Metalion Le 15/09/2014 à 21h35

Comme l'a déjà suggéré Jipe, le plus raisonnable serait de charger des (bribes de) pattern. Celle_ci +une carto prennent moins de place et peuvent être stockée en RAM ou vram.
Puis être moins gourmand en utilisant un mode écran plus léger.

Par contre je ne sais pas comment opérer avec la commande copy et le scroll.