Fonction FILE_WRITEBUF: création d'un fichier BMP

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Le code suivant tente de créér de toutes pièces un fichier BMP de 1500x1000 pixels, fond blanc.

Code:: REM TEST.BAS écriture dans un fichier binaire (image BMP)
DIM wf, hf, et$, i%, v, x%, fr3$, a$, r%, mkl$
LABEL VMKL, rbc
fr3$ = "Z:\COMPOSIT.BMP"

REM en-tête du fichier BMP résultat à créer (image= 3 octets par pixel) ---wf = 1500: hf = 1000: REM largeur et hauteur en pixels de l'image résultat
REM Fichier = en-tête + (wf x hf x 3) octets à 255 (fond blanc)
DATA 66,77,0,0,0,0,0,0,0,0,54,0,0,0,40,0
DATA 0,0,0,0,0,0,0,0,0,0,1,0,24,0,0,0
DATA 0,0,0,0,0,0,18,11,0,0,18,11,0,0,0,0
DATA 0,0,0,0,0,0
et$ = "": REM en-tête du fichier BMP (54 octets)
FOR i% = 1 TO 54
READ r%: et$ = et$ + chr$(r%)
NEXT i%
v = wf :GOSUB VMKL
x% = 19: et$ = LEFT$(et$, x%-1) + mkl$ + RIGHT$(et$, LEN(et$)-x%-3): REM largeur pixels
v = hf: GOSUB VMKL
x% = 23: et$ = LEFT$(et$, x%-1) + mkl$ + RIGHT$(et$, LEN(et$)-x%-3): REM hauteur pixels
v = wf * hf * 3: GOSUB VMKL
x% = 35: et$ = LEFT$(et$, x%-1) + mkl$ + RIGHT$(et$, LEN(et$)-x%-3): REM taille datas image
v = wf * hf * 3 + 54: GOSUB VMKL
x% = 3: et$ = LEFT$(et$, x%-1) + mkl$ + RIGHT$(et$, LEN(et$)-x%-3): REM taille totale

FILE_OPEN_WRITE 5, fr3$
FILE_WRITEBUF 5, et$, LEN(et$): REM écriture de l'en-tête
REM puis écriture de wf*hf*3 octets à 255 (3 octets: couleur RGB, par pixel)
a$ = STRING$(100, CHR$(255)): REM STRING$ est limité à 200 octets
FOR i% = 1 TO hf
FOR r% = 1 TO 3*wf/100
FILE_WRITEBUF 5, a$, 100
NEXT r%
NEXT i%
FILE_CLOSE 5
END

VMKL:
REM S/P conversion entier long en chaîne de 4 octets
mkl$ = ""
rbc:
mkl$ = mkl$ + CHR$(256*FRAC(v/256))
v = INT(v/256)
IF LEN(mkl$)<4 THEN GOTO rbc
RETURN

Je tombe en erreur dans la boucle contenant le FILE_WRITEBUF, 5, a$, 100 (deux boucles imbriquées à cause de la limitation du STRING$ à 200 octets).
Les erreurs signalées sont les suivantes:
d'abord une première fois
Analyse_Ligne_Du_Source. FILE_WRITEBUF. Chaine->BMVªD ???
puis à chaque passage dans la boucle (il faut arrêter par Ctl/Alt/Sup):
Analyse_Ligne_Du_Source. FILE_WRITEBUF. Chaine->ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Manifestement le contenu de la chaîne ne lui convient pas...
Mais je ne comprends pas pourquoi.

Admin Nombre de messages : 2386 Date d'inscription : 28/05/2007

Créer des nouvelles commandes de lecture/écriture d'un nombre déterminé d'octets dans un fichier BINAIRE est ma prochaine priorité. Ces commandes feront partie d'un nouveau jeu de commandes (ouverture, fermeture, écriture, lecture, taille, ...) portant sur des fichiers binaires car il se trouve très coûteux en temps de réalisation d'adapter les commandes existantes (qui ont été concue pour des fichiers texte) à des fichiers binaires. Il est plus rentable (toujours en temps de réalisation) de créer des nouvelles commandes que de "bidouiller" et adapter des commandes existantes.

Pour le moment, je code la mémorisation de la police et de la taille des caractères utilisés pour le source.

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Bien noté... donc je laisse tout ça en jachère pour le moment, je ne peux guère aller plus loin sans ces commandes spécifiques.
D'un autre côté je ne vois pas trop l'intérêt des READ_BUF et WRITE_BUF d'un nombre donné d'octets pour un fichier exclusivement TEXTE (surtout s'ils butent sur certains caractères, comme '1A'), on peut déjà faire à peu près ce qu'on veut avec les READLN et WRITELN.
C'est d'autant plus dommage que le caractère 1A est le seul qui bloque FILE_READBUF, j'ai essayé tous les autres qui sont lus sans problème.

Après tests un peu plus poussés, le message console qui apparaît à chaque FILE_WRITEBUF:

Code:: ---------------------------
Panoramic
---------------------------
Analyse_Ligne_Du_Source. FILE_WRITEBUF. Chaine->@ABCDEFGHIJKLMNO

semble être un test que vous avez oublié d'ôter après mise au point, car il n'y a pas de conséquences sur l'écriture qui se fait correctement. L'embêtant c'est qu'il faut confirmer à chaque fois (OK) pour continuer !

Admin Nombre de messages : 2386 Date d'inscription : 28/05/2007

Mille excuses !
Un test servant à la mise au point est effectivement resté !
Il s'agit d'un point de visualisation qui affiche le résultat de l'évaluation du string passé à la commande FILE_WRITEBUF. Cette visualisation n'a absolument aucun effet sur le résultat, sauf qu'il faut l'acquitter car l'exécution est suspendue jusqu'au click sur OK (principe même d'un point de visualisation)! Et cela est particulièrement agaçant.

Je code la mémorisation de la police, de la taille et du dernier répertoire de chargement d'un source, et je retire ce point de visualisation.

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

OK, c'est bien ce que j'avais compris !

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

J'ai repris le code ci-dessus avec les instructions pour fichiers binaires;

Code:: REM CREBMP.BAS écriture dans un fichier binaire (image BMP)
DIM wf, hf, et$, i%, j%, v, x%, fr$, a$, r%, mkl$
LABEL VMKL, rbc
fr$ = "Z:\COMPOSIT.BMP"

REM en-tête du fichier BMP résultat à créer (image= 3 octets par pixel) -------------------
wf = 320: hf = 240: REM largeur et hauteur en pixels de l'image résultat
REM Fichier = en-tête + (wf x hf x 3) octets à 128 (fond gris)
DATA 66,77,0,0,0,0,0,0,0,0,54,0,0,0,40,0
DATA 0,0,0,0,0,0,0,0,0,0,1,0,24,0,0,0
DATA 0,0,0,0,0,0,18,11,0,0,18,11,0,0,0,0
DATA 0,0,0,0,0,0
et$ = "": REM en-tête du fichier BMP (54 octets)
FOR i% = 1 TO 54
READ r%: et$ = et$ + CHR$(r%)
NEXT i%
v = wf :GOSUB VMKL
x% = 19: et$ = LEFT$(et$, x%-1) + mkl$ + RIGHT$(et$, LEN(et$)-x%-3): REM largeur pixels
v = hf: GOSUB VMKL
x% = 23: et$ = LEFT$(et$, x%-1) + mkl$ + RIGHT$(et$, LEN(et$)-x%-3): REM hauteur pixels
v = wf * hf * 3: GOSUB VMKL
x% = 35: et$ = LEFT$(et$, x%-1) + mkl$ + RIGHT$(et$, LEN(et$)-x%-3): REM taille datas image
v = wf * hf * 3 + 54: GOSUB VMKL
x% = 3: et$ = LEFT$(et$, x%-1) + mkl$ + RIGHT$(et$, LEN(et$)-x%-3): REM taille totale

FILEBIN_OPEN_WRITE 5, fr$
REM écriture de l'en-tête du fichier
FOR i% = 1 TO LEN(et$)
FILEBIN_WRITE 5, ASC(MID$(et$, i%, 1))
NEXT i%
REM puis écriture de wf*hf*3 octets à 128 (3 octets: couleur RGB, par pixel, gris)
FOR j% = 1 TO hf
FOR i% = 1 TO wf*3
FILEBIN_WRITE 5, 128
NEXT i%
NEXT j%
FILEBIN_CLOSE 5
END

VMKL:
REM S/P conversion entier long en chaîne de 4 octets
mkl$ = ""
rbc:
mkl$ = mkl$ + CHR$(256*FRAC(v/256))
v = INT(v/256)
IF LEN(mkl$)<4 THEN GOTO rbc
RETURN

Mais je constate que c'est très très long à exécuter, il faut écrire octet par octet, du coup j'ai réduit le fichier bmp à 320x240, malgré ça ça met plusieurs secondes à créer le fichier.

PS: le disque Z: qui me sert de volume de manoeuvre est un disque virtuel (Ramdisk) de 32M pris sur la mémoire vive de la machine (c'est négligeable, sur 2G). C'est bien pratique pour les fichiers temporaires, mais c'est effacé à chaque extinction de la machine. C'est aussi pour ça que c'est pratique, mais il faut bien en être conscient.

Je m'aperçois que je déterre ce vieux topic qui date du 20 décembre... l'année dernière !
En effet, dans la date des messages il n'y a pas l'année, ça trompe.

» Comment reconvertir un fichier exe Panoramic en fichier BAS
» le processus ne peut pas accéder au fichier car ce fichier..
» Convertir un fichier BAS panoramic en fichier EXE
» creation de 300 pictures?
» Création d'une Playlist