Adressage des pixels d'un picture

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

Je suis en train de bricoler sur le format bmp (simple) et ico (plus tarabiscoté).
Quelque chose me chiffonne dans l'adressage des pixels dans Panoramic.
Un exemple:

Code:: DIM w,h
w = 20: h = 20
PICTURE 1: WIDTH 1,w: HEIGHT 1,h: COLOR 1,0,0,128
2D_TARGET_IS 1: 2D_PEN_COLOR 255,0,0
2D_LINE 0,0,w-1,h-1
2D_FILL_OFF: 2D_RECTANGLE 0,0,w-1,h-1
Zoom(1,0,0,w,h,30): ' zoom x30, pour voir
Terminate
' ==============================================================================
SUB Zoom(pict%,x%,y%,w%,h%,z%)
' Zoom x z% de la zone du picture p% en x%,y%, dimensions w%,h%
  IF LABEL("Ex") = 0 THEN LABEL Ex
  DIM_LOCAL n2d%,ff%,f%,p%,i%,j%,xp%,yp%,r%,g%,b%
  ff% = 0: f% = 900: p% = f%+1: ' variable ff% définie dans le programme appelant
  n2d% = NUMBER_2D_TARGET
  FORM f%: BORDER_SMALL f%: WIDTH f%,w%*z%+16: HEIGHT f%,h%*z%+35: ON_CLOSE f%,Ex
  PICTURE p%: PARENT p%,f%: FULL_SPACE p%
  2D_TARGET_IS p%
  yp% = 0
  FOR j% = y% TO y%+h%-1
   xp% = 0
   FOR i% = x% TO x%+w%-1
   r% = COLOR_PIXEL_RED(pict%,i%,j%): g% = COLOR_PIXEL_GREEN(pict%,i%,j%)
   b% = COLOR_PIXEL_BLUE(pict%,i%,j%)
   2D_PEN_COLOR r%,g%,b%: 2D_FILL_COLOR r%,g%,b%
   2D_RECTANGLE xp%,yp%,xp%+z%-1,yp%+z%-1
   xp% = xp%+z%
   NEXT i%
   2D_PEN_COLOR 128,128,128: 2D_LINE 0,yp%,WIDTH(p%),yp%
   yp% = yp%+z%
  NEXT j%
  FOR xp% = 0 TO WIDTH(p%) STEP z%: 2D_LINE xp%,0,xp%,HEIGHT(p%): NEXT xp%
  2D_TARGET_IS n2d%
  CAPTION f%," ZOOM x "+STR$(z%)
  WHILE ff% = 0: PAUSE 300: TO_FOREGROUND f%: END_WHILE: DELETE f%: EXIT_SUB
Ex:
  ff% = 1
RETURN
END_SUB
' ==============================================================================

C'est un Picture carré tout bête, de 20x20 pixels. Et une fonction zoom pour voir le résultat plus en détail.
Normalement les adresses des pixels devraient aller du pixel 0 au pixel 19 (20 pixels en tout).

Eh bien je m'aperçois que dans la fonction
2D_LINE x1,y1,x2,y2: ' tracé d'une ligne entre x1,y1 et x2,y2, la ligne s'arrête en x2-1 et y2-1.
Le point d'arrivée n'est pas compris dans le trait.
De même pour la fonction:
2D_RECTANGLE x1,y1,x2,y2, le rectangle est tracé de x1 à x2-1 et y1 à y2-1
Ça perturbe un peu ma logique...

Si je veux tracer ici une ligne ou un rectangle qui couvre le Picture, il faut aller de 0,0 à 20,20 (au lieu de 19,19), ça ne me paraît pas normal.

Idem pour le 2D_IMAGE_COPY x1,y1,x2,y2 qui copie la zone x1 à x2-1 et y1 à y2-1

Code:: DIM w,h
w = 20: h = 20
PICTURE 1: WIDTH 1,w: HEIGHT 1,h: COLOR 1,0,0,128
2D_TARGET_IS 1: 2D_FILL_OFF
IMAGE 2
2D_PEN_COLOR 255,0,0: 2D_RECTANGLE 0,0,5,5
2D_IMAGE_COPY 2,0,0,4,4
2D_IMAGE_PASTE 2,10,10
Zoom(1,0,0,w,h,20): ' zoom x20, pour voir
Terminate

J’avais déjà constaté ça et j’en ai conclu que le point d’arrivée des commandes de tracé est EXCLU, et aussi que jack a EXCLU cette information du fichier d’aide Sad

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

C'est bien dommage, parce que ce n'est pas logique, et pour moi c'est un bug, pas forcément très gênant, mais il faut bien en tenir compte quand on travaille au pixel près ! une droite, c'est du point de départ au point d'arrivée tous deux inclus.

Merci en tout cas silverman de m'avoir rassuré, je me sens moins seul.

En 1961, j’ai appris le théorème suivant : Un segment de droite est une portion de droite limitée par deux points de cette droite.
Je me rappelle que j’ai fait la remarque à mon professeur de math que cette phrase était trop lourde : répétition de droite trois fois.
Sa réponse était : en mathématiques, il faut définir les choses sans ambiguïté.

Salut à tous,

@JL35,

Ton code fait appel à une procédure, sans END Exclamation

C'est curieux ça, non ?. Very Happy

A+

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

Il n'y a pas de END mais il y a un TERMINATE qui termine tout !
Tu trouves ça choquant ?

On va dans la procédure pendant la phase de mise en place des objets (donc avant le End théorique), et au retour de la procédure ce End n'est plus nécessaire puisqu'on clôt le programme, on n'attend plus rien de l'utilisateur.

Le End serait nécessaire si on attendait des actions de l'utilisateur, ce qui n'est pas le cas ici, c'est une démo à sens unique.

@Jean Claude
Tu n’as pas vu le TERMINATE qui remplace le END ?
Seulement ce TERMINATE je le déteste affraid

TERMINATE = PLANTAGE

Admettons !

Pourquoi utiliser TERMINATE, qui bug, à la place de END qui lui est irréprochable.
Si tu mets un END à la place de TERMINATE, il n'y a pas de plantage à la sortie.

A+

C'est bien ce que je dis. tongue

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

Le Terminate ferme le programme, ce que ne fait pas le End.
Et chez moi il ne plante pas, je suis revenu à la version précédente de l'éditeur à cause de ça.

Mais bon, c'est un détail par rapport au sujet, le code est court et à usage unique, chacun peut mettre un end à la place du terminate.

@JL35
c'est dommage d'être revenu en arrière, la dernière version de travail fonctionne bien hormis le souci du 'terminate', mais ce pb est facile à contourner:

Code:: '
' remplacement de 'terminate' pour eviter le bug:

sub close_form(window)
   dll_on "user32" : dim_local null%
   null%=dll_call1("DestroyWindow",handle(window)) :' libere les resources memoires
   if window=0
   null%=dll_call1("PostQuitMessage",0) :' indique au systeme que c'est la fin du programme
   end_if
   dll_off
end_sub

' ou a partir de panoramic0927i2 et +, on peut utiliser cette autre sub:

sub close_form(window)
dim_local n
   n=0
   repeat
   n=n+1
   until library$(n)="_" or lower$(library$(n))="user32"
   if lower$(library$(n))<>"user32" then library n,"user32"
   '
   command "free_resources","DestroyWindow",n,"I","stdcall" :' libere les resources memoires
   command "quit_form","PostQuitMessage",n,"I","stdcall" :' indique au systeme que c'est la fin du programme
   '
   free_resources handle(window)
   if window=0 then quit_form 0 :' 0=code de sortie
end_sub

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

Je sais bien silverman qu'il y a des palliatifs au terminate défectueux, mais bon
- pour le moment je n'utilise pas les dernières modifs de l'éditeur, donc je ne suis pas très motivé.
- j'ai depuis longtemps sur le bureau un petit batch qui ferme (fermement) Panoramic.exe pour tous les cas où ça tourne en rond ou autres, j'ai juste à cliquer dessus, et c'est radical.

Le .Bat sert à fermer impérativement une tâche quelconque en cours d'exécution:

Code:: @echo off
Taskkill.exe /F /IM %1 /T

enregistré dans C:\BAT\ sous le nom Kill.bat
Appelé depuis le bureau par:

Code:: C:\BAT\Kill.bat Panoramic.exe

Ça ferme toutes les sessions de panoramic.exe qui restent actives, on ne sait pas toujours pourquoi (j'ai aussi sur le bureau un petit utilitaire qui m'affiche tous les programmes actifs au moment du clic, avec possibilité de supprimer certains).

Il me suffirait, dans mes programmes actuels, de mettre à la place de TERMINATE:

Code:: EXECUTE "cmd.exe /c C:\BAT\Kill.bat Panoramic.exe"

et ça ferme sans discuter.

Mais je garde quand même sous le coude ta sub qui ne nécessite pas de ressource externe.

PS Pour le taskkill de panoramic.exe, je pense que c'est ce que fait d'une façon ou d'une autre l'option 'Stop' dans le menu de Panoramic_editor.

» Problème en adressage de strings par ADR() ?
» Picture
» Taille en pixels d'une police fixe
» TextLen: longueur d'une chaîne en pixels
» Comment calculer l'épaisseur en pixels d'une fenêtre