Hello,
Quelques news à propos du développement de raafal.
Je sais.. le développement de raafal est plutôt lent, mais comme vous le savez sans doute déjà, je le fais durant mes temps libres et j'aimerai, dans la mesure du possible, faire les bons choix dès le départ, tout en gardant le projet aussi simple et léger que possible mais également aussi flexible et puissant que possible. Facile à dire mais pas si facile à faire quand on est confronté à pas mal de choix possibles. Ceci dit je ne suis pas non plus hyper pressé, je préfère prendre le temps qu'il faut pour faire les choses proprement, en tout cas en accord avec l'idée de départ. Il est vrai que jusqu'à présent j'ai passé la plupart de mon temps à tester et expérimenter différents choix possibles au lieu de coder raafal. Ceci dit, une bonne partie de la base du framework est déjà en place.
Cela dit, le développement de raafal commence à évoluer un peu plus rapidement car certains choix définitifs concernant certains points clés du framework ont désormais été pris:
1) OpenGL:
Pour un framework orienté graphiques, l'accélération hardware est obligatoire, notamment avec l'OpenGL et PureBasic offre plusieurs options dans ce sens, mais manque encore d'une chose pour pouvoir aborder le développement d'application professionnelles sans avoir à "bidouiller": La possibilité de pouvoir configurer le contexte OpenGL utilisé pour avoir accès aux récentes versions "Core". J'ai pesté un peu partout sur le forum à propos de ça mais j'ai finalement arrêté de me poser la question pourquoi cet OpenGLGadget ne propose pas cette possibilité de configuration.. C'est comme rechercher le Sens de la Vie et cela me rend fou..
Pour circonvenir ce problème, j'ai expérimenté avec plusieurs librairies, GLFW, SFML, SDL, .. mais je me suis retrouvé confronté à d'autres problèmes, notamment des interférences dans la "main loop" entre PureBasic et les librairies. Au final, et suivant le principe KISS (keep it simple), je suis revenu aux "basiques" si je puis dire: utiliser le OpenGLGadget. Et pour contourner le problème de configuration OpenGL, je crée désormais un contexte OpenGL indépendant de celui de PureBasic et je le lie à la vue de l'OpenGLGadget. Ca parait simple, comme ça, mais encore faut-il savoir le faire, et j'ai été bloqué pas mal de temps à cause de cela sur Mac OSX.. Évidemment, au final, c'est super simple, *une fois que l'on sait comment faire*..
Voici le code pour ceux qui seraient intéressés:
Code : Tout sélectionner
; ---[ Allocate Pixel Format Object ]---------------------------------
Protected pfo.NSOpenGLPixelFormat = CocoaMessage( 0, 0, "NSOpenGLPixelFormat alloc" )
; ---[ Set Pixel Format Attributes ]----------------------------------
Protected pfa.NSOpenGLPixelFormatAttribute
With pfa
\v[0] = #NSOpenGLPFAColorSize : \v[1] = 24
\v[2] = #NSOpenGLPFAAlphaSize : \v[3] = 8
\v[4] = #NSOpenGLPFAOpenGLProfile : \v[5] = #NSOpenGLProfileVersion3_2Core ; will give 4.1 version (or more recent) if available
\v[6] = #NSOpenGLPFADoubleBuffer
\v[7] = #NSOpenGLPFAAcceleratedCompute ; I also want OpenCL available
\v[8] = #Null
EndWith
; ---[ Choose Pixel Format ]------------------------------------------
CocoaMessage( 0, pfo, "initWithAttributes:", @pfa )
; ---[ Allocate OpenGL Context ]--------------------------------------
Protected ctx.NSOpenGLContext = CocoaMessage( 0, 0, "NSOpenGLContext alloc" )
; ---[ Create OpenGL Context ]----------------------------------------
CocoaMessage( 0, ctx, "initWithFormat:", pfo, "shareContext:", #Null )
; ---[ Associate Context With OpenGLGadget NSView ]-------------------
CocoaMessage( 0, ctx, "setView:", GadgetID(oglcanvas_gadget) ) ; oglcanvas_gadget is your OpenGLGadget#
; ---[ Set Current Context ]------------------------------------------
CocoaMessage( 0, ctx, "makeCurrentContext" )
; do your OpenGL drawing..
; ---[ Swap Buffers ]-------------------------------------------------
; CocoaMessage( 0, ctx, "flushBuffer" )
Ce code est extrait de raafal moins la gestion des erreurs et il est supposé être exécuté dans une procédure (d'où les "Protected").
Pour des raisons pratiques, NSOpenGLPixelFormatAttribute est une macro en dur référençant une autre macro en dur sur une structure de taille fixe..
Code : Tout sélectionner
; ...[ array9_t ]......................................................
Structure array9_t
v.l[9]
EndStructure
; ...[ NSOpenGLPixelFormatAttribute ]...................................
Macro NSOpenGLPixelFormatAttribute
array9_t
EndMacro
; ...[ NSOpenGLPixelFormat ]............................................
Macro NSOpenGLPixelFormat
i
EndMacro
; ...[ NSOpenGLContext ]................................................
Macro NSOpenGLContext
i
EndMacro
Comme ce problème est désormais résolu, le développement de l'interface graphique de raafal est de nouveau sur des rails..
2) Scripting:
Au départ j'étais parti pour intégrer dans raafal le langage de script DAO. DAO était vraiment un super langage, très prometteur, en partie accéléré JIT. Malheureusement, son auteur a décidé d'en arrêter le développement.. et bien sûr, ceci lorsque j'avais intégré DAO assez complètement avec PureBasic et raafal.. Donc j'ai perdu pas mal de temps avec ça, mais ceci dit l'exercice en fut néanmoins assez intéressant.
Au final j'ai décider de revenir sur une valeur sûre, un langage robuste, bien connu et pas prêt de disparaître! Mon choix final se portait sur soit Python, soit Lua (en version JIT). Python est devenu le standard "industriel" dans les application liées aux images de synthèses, mais moi j'aime pas
c'est lent, il faut une installation spécifique, c'est pénible de l'interfacer avec le code natif et son formatage à base d’indentation peut mener à des résultats catastrophiques. Je ne comprends toujours pas pourquoi c'est devenu un standard "industriel" mais bon, le syndrome du Sens de la Vie repointe sont nez, je laisse tomber..
KISS !! Bref, de nouveau, "keep it simple"/rester simple - tout en étant puissant - voici LuaJIT. LuaJIT est trop exceptionnel pour l'ignorer. Il est super léger à intégrer en tant que librairie statique avec PB, et c'est tout simplement le langage de script le plus rapide du monde. Point. De plus avec le développement récent de Terra (terralang), une extension de Lua utilisant LLVM, on peut envisager des développements incroyablement simples et puissants. Ainsi soit-il, raafal utilisera LuaJIT, affaire classée.
Sauf que.. comme d'habitude, je suis maintenant confronté à un autre "petit" problème, et comme par hasard pour de la compilation x64 sur Mac OSX (encore lui!): LuaJIT demande aux applications qui l'utilisent d'être compilées avec les options de liens suivants:
J'ai bien essayé d'utiliser les options de liens disponibles à partir de l'IDE de PureBasic, mais pour l'instant, rien à faire, ça marche pas.. (voici le lien du forum où j'en parle:
http://www.purebasic.fr/english/viewtop ... 19&t=65866).
Si vous pouvez apporter une quelconque aide à ce sujet, vous serez plus que bienvenu(e)!
Il y a d'autres parties pour lesquelles des choix définitifs ont été fait, notamment côté données et tâches, mais elles seront abordées plus tard dans un autre message.
Merci de l'intérêt porté à ce projet,
Guy.