PB Override : Redéfinir une fonctionnalité de PureBasic

[falsam]

Ce code est incorrect

Code : Tout sélectionner

Enumeration Window
  #MainForm
  #MyText
EndEnumeration

If OpenWindow(#MainForm, 0, 0, 800, 600)
  TextGadget(#MyText,20, 20, 100, 22, "My text", RGB(255, 0, 0)) 
  Repeat : Until WaitWindowEvent(10) = #PB_Event_CloseWindow
EndIf

Quels sont les erreurs ?
-Le titre de la fenêtre est manquant
-La couleur n'est pas un paramètre de la fonction TextGadget()

Et pourtant .....

En regardant un des codes d'Eddy sur le forum Anglais, j'ai vu qu'il a trouvé une astuce pour Overrider les fonctions natives de PureBasic.

Imaginons que vous souhaitez redéfinir :
- OpenWindow() pour toujours afficher les fenêtres centrées sur l'écran et sans titre.
- TextGadget() pour ajouter le paramétre couleur du texte.

L'include et la zone de test sont dans ce code que je partage avec vous.

Code : Tout sélectionner

;PBOverride.pbi
CompilerIf Not Defined(MacroBuilder, #PB_Module)
  DeclareModule MacroBuilder
    EnableExplicit    
    
    Macro _Colon
      :
    EndMacro    
    
    Macro DefineMacro(_MacroHead, _MacroBody)
      _Colon#Macro _MacroHead#_Colon#_MacroBody#_Colon#EndMacro
    EndMacro    
    
    Macro Override(_Name, _Prefix=_)
      DefineMacro(_Name, _Prefix#_Name)      
    EndMacro           
    
  EndDeclareModule  
  Module MacroBuilder
  EndModule
CompilerEndIf

CompilerIf Not Defined(PBFunctionRename, #PB_Module)
  
  DeclareModule PBOverride
    EnableExplicit
    
    Declare _OpenWindow(Window, x, y, InnerWidth, InnerHeight)
    Declare _TextGadget(Gadget, x, y, Width, Height, Text$, Color=$000000)
    
  EndDeclareModule 
 
  Module PBOverride
    
    ;Redéfinition de OpenWindow()
    Procedure _OpenWindow(Window, x, y, InnerWidth, InnerHeight)
      Protected Result
      
      If Window = #PB_Any
        Result = OpenWindow(#PB_Any, x, y, InnerWidth, InnerHeight, "", #PB_Window_SystemMenu|#PB_Window_ScreenCentered)
      Else
        Result = OpenWindow(Window, x, y, InnerWidth, InnerHeight, "", #PB_Window_SystemMenu|#PB_Window_ScreenCentered)
      EndIf
      ProcedureReturn Result
    EndProcedure
    
    ;Redéfinition de TextGadget()
    Procedure _TextGadget(Gadget, x, y, Width, Height, Text$, Color=$000000)
      Protected Result
      
      If Gadget = #PB_Any
        Result = TextGadget(#PB_Any, x, y, Width, Height, Text$)
        SetGadgetColor(Result, #PB_Gadget_FrontColor, Color)
      Else
        Result = TextGadget(Gadget, x, y, Width, Height, Text$)
        SetGadgetColor(Gadget, #PB_Gadget_FrontColor, Color)
      EndIf  
      
    EndProcedure
  EndModule
  
  UseModule MacroBuilder
  UseModule PBOverride  

  Override(OpenWindow)
  Override(TextGadget)
CompilerEndIf

; ****** Zone de test ******
;IncludeFile "PBOverride.pbi"
Enumeration Window
  #MainForm
  #MyText
EndEnumeration

If OpenWindow(#MainForm, 0, 0, 800, 600)
  TextGadget(#MyText,20, 20, 100, 22, "My text", RGB(255, 0, 0)) 
  Repeat : Until WaitWindowEvent(10) = #PB_Event_CloseWindow
EndIf

Il est fort ce Nantais ...

[blendman]

j'avais vu ça, mais je n'avais pas compris
Quand on analyse ce qu'il fait c'est clair qu'il jongle sacrément ^^.

[falsam]

bon .... franchement, je ne vois pas trop l'interet

Parce que tu n'as pas compris.

_openwindow() ne fait pas parti du vocabulaire de PureBasic

Alors que OpenWindow() oui.

L’intérêt est de remplacer OpenWindow() par le contenu d'une autre procédure qui se nomme _OpenWindow()

Quand tu tapes dans ton éditeur OpenWindow(), le compilateur ira chercher le contenu de _OpenWindow()

Je peux par exemple recréer la fonction CreateSprite() (Natif PureBasic) et faire mémoriser à cette fonction la position x et y du Sprire, chose qui n'existe pas actuellement.

Si tu ne vois toujours pas l'intéret et bien .... tant pis.

ou bien j'ai peut etre pas compris ton enthousiasme

Un commentaire de ma part ? ha non.

[falsam]

si encore c’était dans un but d'améliorer soit la vitesse, la taille des programmes ou autre chose
ok , j'aurai compris,

Ben tu vois que tu as compris.

je vois pas ou tu bloques la dessus

Je ne bloque pas. Je pose juste des questions. Pourquoi devoir créer une structure pour gérer la position des sprites alors que ça pourrait être en natif comme pour les entité 3D qui sont eux aussi que des dessins dans un screen.

[falsam]

@SPock: Encore une utilisation de ce module. Imagines que tu as employé 1000 fois dans ton code ButtonGadget() et que suite à une nouvelle version, ce bouton ne réagit plus de la même manière. Je pense que dans ce cas tu seras content d'Overrider ButtonGadget() par ton propre code au lieu de créer un CustomButtonGadget() et ensuite aller remplacer ButtonGadget() par CustomButtonGadget()

Je sais ce que tu vas me répondre : Rechercher/Remplacer c'est pas pour les chiens.

[falsam]

"et si cette nouvelle version changeait le fonctionnement de 'Macro' ou bien compiler If ou bien les Modules " ...

Toujours le dernier mot hein ? haha. vtfv vieux crouton :p

[G-Rom]

Je rejoins "michou" sur sa pensé, a part du cirque , cela ne sert à rien , un overload de methode pour ajouté ou retiré un paramètre d'une fonction pb , voila l'usine à gaz , je ne parle même pas comment debugger en cas d'erreur interne à la fonction "overloadé". ceci dis , l'utilisation des macro montre à quel point il est facile de grugé le compilo. Quand au sprite, je ne suis pas d'accord avec spock, il manque bien des fonctions , je ne vois pas pourquoi on ne pourrais pas avoir les infos de position. même un "objet" peu être à deux endroit en même temps , comme en physique quantique ^^ il suffit de le rendre 2x , comme avec les fonctions classique PB.

en SFML par exemple , tout les sprite sont des objets pur

Code : Tout sélectionner

sf::Sprite monSprite(maTexture);

m_window.clear();
monSprite.setPosition(150,150);
 m_window.draw(monSprite);
  monSprite.setPosition(50,50);
 m_window.draw(monSprite);
m_window.display();

std::cout << "position x " << monSprite.getPosition().x << std::endl;

dans ce petit bout de code, le sprite est dessiné 2x. ton raisonnement est pas bon mr.spock

de toute facon , je travaille depuis quelque temps (année... ?) sur un FrameWork2D écrit complètement en c++ , le portage PB sera prévu , il résouds tout les problèmes que PB à avec la 2D , gestion de camera , relation parent / enfant , shader , postfx sur camera , son dynamique , gestion des ressources , etc...
j'en parlerais le moment voulu ^^

[Kwai chang caine]

j'avais vu ça, mais je n'avais pas compris
Quand on analyse ce qu'il fait c'est clair qu'il jongle sacrément ^^.

Il m'avait semblé voir aussi ce genre de manip avec les macros..
Mais pareil, j’étais pas arrivé à la reproduire

Alors moi je trouve ça génial et super utile au risque de désespoir de certains de vous
J'ai une utilisation toute trouvée, un truc qui me gonfle depuis des années
On pourrait peut-être, si j'ai bien compris, supprimer les "trous" de PB

Certaines fonctions ne réagissent pas avec certains gadgets, comme les couleurs sur les boutons, les frames, mais bien d'autres encore
Si j'ai bien compris, on pourrait grâce à cette manœuvre "terminer" le langage afin que toutes les fonctions marchent avec tous les gadgets, compléter aussi certaines fonctions ou les constantes sont sans effets, rajouter des constantes etc...tout ceci sans avoir le besoin de réinventer des fonctions persos

Je remercie EDDY et aussi FALSAM d'avoir amené et expliqué ce sujet
Bon me direz vous....reste encore le plus dur...créer ce super module qu'on pourrait appeler PB+
Affaire à suivre...

[blendman]

j'aurai bien aimé que tu me réponde sur les Sprites

Au début, venant de gamemaker, je pensais aussi qu'un sprite était un objet, alors qu'en fait ce n'est pas un objet comme les entités.
Donc effectivement, spriteX() et SpriteY() ne peut pas exister pour tous les sprites, dans ce contexte, car ça nous donnerait la dernière position uniquement.

Heureusement, venant de GameMaker, j'ai toujours utiliser une structure dès que j'utilise des sprites, je recrée mes objets et donc, je connais toujours le x et Y de mon "sprite -objet" que j'ai créé par moi-même.

Maintenant, je comprends aussi la remarque de Falsam : si on estime qu'une fonction native ne nous convient pas (ou qu'elle change lors d'une nouvelle version), ça peut être pas mal d'avoir ce genre d'alternative pour pouvoir la modifier et éviter de se retaper la modification de tout le code (même si c'est une usine à gaz ^^). Le mode rechercher/remplacer marche, mais c'est quand même un peu chiant de devoir tout changer à chaque fois qu'on change de version ^^.
Bon, cela dit, c'est ce que je fais tout le temps. Après, par exemple, pour du prototypage, l'astuce d'eddy peut être intéressante.
Après, c'est comme les sub ou d'autres choses. Certains s'en servent d'autres non, chacun son truc ^^.


@G-rom : je comprends ton raisonnement, mais cet exemple ne me semble pas quantique .
Ton sprite est dessiné deux fois car tu n'effaces pas l'écran/fenêtre entre son changement de position.
Donc en fait, s'il est dessiné deux fois, il n'est pas en même temps aux deux positions (non, il n'est pas quantique ^^).
On le place à une position, on le dessines , puis on le mets à une autre position, on le dessine et on affiche l'écran.
Si tu fais un getPosition(), tu auras uniquement la dernière position, non ? OU alors, il te dit : le sprite est en (100,100) et en (50,50)

D'ailleurs, ça, on peut déjà le faire avec purebasic (positionner un sprite, le dessiner, le positionner ailleurs, le dessiner, puis afficher le dessin.
C'est comme un drawalphaimage() (ou circle ou autre) sur un canvas. On n'a pas de ImageX() et ImageY() car c'est à nous de savoir où on les place.

D'ailleurs, c'est pour ça que c'est vraiment dommage qu'on ne puisse plus dessiner un sprite sur un autre sprite (pour mon soft de painting), ce serait hyper pratique !

[blendman]

par contre, nous pourrions avoir besoin de fonctions de manipulation de l'image Sprite ...
rotations, flips,transformations,et pourquoi pas Morphing , transparences modulable ,etc ... etc .....

Entièrement d'accord avec toi, d'ailleurs, il faudrait aussi pouvoir récupérer facilement l'image du sprite (elle doit bien être quelque part ^^).
On peut l'obtenir avec GrabDrawingImage(), mais bon, ce serait intéressant de pouvoir effectivement modifier directement cette image et non la copier ^^.
Bon, après il faudrait voir si ce serait plus rapide que de choisir l'image d'un sprite, la modifier (rotation, transformation...) et la redessiner sur le sprite.

[blendman]

il faudrait aussi pouvoir récupérer facilement l'image du sprite (elle doit bien être quelque part ^^). .

oui... faudrai chercher dans les context Device , seul Fred pourrai répondre a ça, car il faut connaitre sa gestion des sprites en interne ...
t'a fait une recherche sur le forum anglais ? ,ptete quelqu'un a fait une recherche la dessus ?

OUi, j'ai trouvé ça, mais c'est windows uniquement et j'essaie d'éviter les apis si possible (pour que ce soit multiplateforme) :

Code : Tout sélectionner

Procedure SpriteToImage2(Sprite)
  hDC=StartDrawing(SpriteOutput(Sprite))
  bmp.BITMAP\bmWidth=SpriteWidth(Sprite)
  bmp\bmHeight=SpriteHeight(Sprite)
  bmp\bmPlanes=1
  bmp\bmBitsPixel=GetDeviceCaps_(hDC,#BITSPIXEL)
  bmp\bmBits=DrawingBuffer()
  bmp\bmWidthBytes=DrawingBufferPitch()
  hBmp=CreateBitmapIndirect_(bmp)
  StopDrawing()
  ;Debug hBmp
  ProcedureReturn hBmp
EndProcedure

Avec ce code, je pense qu'on peut modifier l'image directement (d'ailleurs, on peut le faire avec drawingbuffer en fait)