Gérer un moteur 2D utilisant DirectX dans KGF ?

Bon, je mets ce sujet dans barvadage car c'est un peu spécial. Je me demande si KGF pourrait créer une interface simple pour gérer un espace pour gérer les sprites à l'aide de DirectX

La gestion des sprites et du moteur 2D de directx peut être trouvé ici, par exemple: http://www.alrj.org/docs/2D/Moteur_2D_avec_DirectGraphics.doc

L'idée serait de faire une fonction qui créait un espace pour l'affichage et une pour créer un sprite, une pour bouger ce sprite, etc ... tout comme tu l'as fait dans ton exemple de gestion de sprites et de collisions, mais en déportant les procédures dans KGF pour travailler directement avec le moteur 2D de directX ?

Le but serait de voir si cela fonctionne et si on arrive à avoir une amélioration notable des performances ....

Vu la spécificité, il faudrait peut être une dll attitrée...

Je suis d'accord Ygeronimi Au moins le temps du développement après Klaus verra s'il arrive à faire ça et si ça a un intéret au niveau performance q'il l'intègre ou non dans KGF (Les fonctions directx permettent bien d'autres usages que l'animation de sprites ...)

@Jicehel:
J'ai regardé le petit tuto. A priori, ça semble faisable. Néanmoins, ce tuto est en C, pas en Delphi, et rien n'est dit sur la façon d'accéder ces fonctions (DLL ou autre). Je vais chercher un peu ce que je trouve à ce sujet.

OK, merci Klaus. Je sais que tu aimes les défits. C'est un défit qui me parait interessant et réaliste, mais je n'ai aucune idée si cela permettra d'obtenir de meilleures performances (je l'espère juste très fort ).
En fait l'utilisation de la DLL compliquerait un peu mais comme on peut intégrer la gestion des sprites directement dans un appel comme tu l'avais fait dans les procédures, on peut s'y retrouver assez facilement si les performances suivent.

Bonjour Klaus, alors, tes premières impressions ? Ca s'annonce plutôt réalisable à priori ou ce sera assez complexe voir impossible selon toi ? Enfin si tu as déjà eu le temps d'y regarder ou ne répond que quand tu auras eu le temps car tu as sans doute des tas de choses à faire en dehors de ça ....

J'ai avancé un peu dans mes recherches et les études de faisabilité.

Donc, oui, c'est faisable. Ceci dit, c'est un peu comme pour le système ISAM que je viens d'ajouter à KGF.dll. C'est un gros morceau.

Mais, contrairement au système ISAM que j'ai pu intégrer à l'aide de modules DELPHI de SourceForge que j'ai "enveloppés" dans une autre couche Delphi pour créer l'interface compatible Panoramic, il en va autrement pour le problème que tu m'as soumis.

Certes, il y a des modules Delphi en licence Mozilla que je peux utiliser, et que je peux "habiller" en Panoramic. Mais la grande différence, c'est que s'est insuffisant. Alors que les modules Delphi utilisés pour ISAM sont une implémentation auto-suffisante de B-Tree Filer, il faut ici deux éléments supplémentaires, aussi bien chez le développeur que chez l'utilisateur final des programmes (jeux) faits avec ce logiciel: ce sont deux DLLs d'une part, à installer soit dans le dossier où réside le programme, soit dans Windows\System\ ou Windows\System32\, et le runtime DirextX9 de MicroSoft, à télécharger chez eux et à installer sur chaque machine. Sans cela, impossible de faire marcher cela.

Est-ce que cette contrainte est acceptable pour toi ? Si oui, je vais plus loin, et en particulier l'installation du runtime DirectX9 chez moi, puisque je ne l'ai pas, à ce jour. C'est à toi de me dire si, pour chaque programme conçu avec ce logiciel, tu veux imposer à l'utilisateur d'installer, en plus de KGF.dll (ou d'une autre DLL spécialisée) les deux DLLs supplémentaires, plus le runtime DirectX9.

EDIT

Information importante:
Le runtime DirectX9 ne peut pas être désinstallé ! Information de MicroSoft !

Hum, directX, c'est un produit qui peut être un pré requis comme il est utilisé par beaucoup de choses. Les 2 DLL, et bien oui, si les performances sont là, pourquoi pas. De toute façon, si cela permet d'améliorer la rapidité d’exécution nécessaire aux jeux d'action, c'est DLL serviront une fois pour toutes KGF on l'utilise déjà dans pleins de programmes et l'autre et bien on fera avec. Ce sera embêtant puisqu'il faudra jongler entre les 2 DLL. A moins qu'entre temps tu trouves encore une autre astuce.
En tout cas c'est absolument acceptable pour faire les tests de performance et savoir si ça vaut le coup ou non de passer par ce biais.

D'accord, Jicehel. Je vais l'installer chez moi, faire des essais et proposer une version de démo. On verra bien...

Plus serviable que Klaus, difficile d’en rencontrer !

C'est sûr, mais les défits chez Klaus, je pense que ça lui procure la même satisfaction que certains peuvent avoir en faisant des casses tête ou autre jeux de réflexion.

Bon plus qu'à espérer que ce soit satisfaisant au niveau performances en utilisant cette méthode

A priori, je me heurte à un problème non prévu: l'installation du runtime DirectX9 échoue chez moi, car pour un des modules à installer, j'ai un module plus récent sur ma machine. Et j'ai réussi à lancer deux des démos (en EXE) fournies avec le logiciel DirectX pour Delphi, mais cela fait évidemment une violation d'accès, vu que DirectX ne s'installe pas...

Je vais continuer à chercher une solution de contournement...

Bon, j'ai réussi à installer une extension DelphiX à mon Delphi 6 Personal Edition, avec une collection de composants englobant tout DirectX 9. Et ça marche ! Un programme de démo est fourni avec. Et lorsque je le lance, je peux choisir 2 modes: harware ou software. En mode software (sans support hardware des fonctions de dessin), sur ma machine, j'ai plus ou moins 10 FPS. Mais en passant en mode hardware, j'ai entre 220 et 230 FPS. Est-ce que ces chiffres te disent quelque chose ? Est-ce que c'est intéressant ? Est-ce que ça vaut le coup de continuer avec cet outil ? Techniquement, c'est possible !

EDIT

Dans mon WebDav, j'ai créé un dossier DirectX dans lequel j'ai copié ce programme de démo. Tu oeux le télécharger et essayer chez toi pour voir ce que ça donne. Ca m'intéresserait à titre de comparaison.

EDIT BIS

J'ai recompilé ce programme entièrement sur ma machine. Et là, l'exécution en mode hardware indique 365 FPS. Est-ce intéressant ? En mode software, cela reste à 10 FPS. J'ai mis cette version du EXE dans le dossier DirectX.

Une remarque: chez moi, le mode full_screen ne marche pas. Par contre, le mode fenêtré (par défaut) marche parfaitement.

Je ne veux pas répondre pour Jicehel mais 365 FPS cela me parait très bien.
Sauf, qu' il faudrait savoir à combien on tourne avec Panoramic pour savoir si c' est mieux ou pas...

EDIT:

Je viens de tester ta demo.
Je n' arrive pas à 365 FPS en Hardware mais autour de 160 FPS, peut être une histoire de mémoire vive (2go).
mais je trouve cela déjà très très correct.

oui, c'est excellent et comme disait Ygeronimi, il faudra voir ce que l'on optient en passant par les appels des DLL. L'objectif serait d'avoir environ 30 FPS (30 images par secondes en bougeant par exemple 30 sprites à l'écran). Si on y arrive, cela serait clairement intéressant (essayez de le faire en Panoramic pur par exemple pour voir ce que ça donne sinon ...)
Après, il faudra étudier les petits problèmes.
Par contre j'ai une interrogation. Tu parles de Directx 9 qui est une vieille version de DirectX qui n'est pas forcément la plus compatible avec nos matériels récent. Cela ne fonctionne pas avec la version DirectX 11, voir la version DirectX 12 qui est sorti très récemment ou qui est sur le point de l'être ?

Je cherche des informations sur la version DirectX utilisée. Ce que je sais actuellement:
- le dernier élément de l'historique des modification est de Septembre 2013
- je viens de me rendre compte que sur ma machine, DirectX 11 est installée (exécuter DxDiag.exe, choisir l'onglet système)
- le programme fourni utilise le DirectX installé sur le système, pas une version quelconque embarquée

Donc, mon laïus concernant DirectX 9 est obsolète - résultat de mon ignorance à ce sujet. Ce que le viens de dire ci-dessus, est vérifié et confirmé par divers sites d'info sir DirectX, y compris MicroSoft (information sur DxDiag).

Donc, pas d'inquiétude, on utilise toujours la dernière version de DirectX. C'est d'ailleurs la raison pour laquelle les performances ont augmenté de 50 %, entre la version binaire fournie du petit programme de démo et ma version recompilée sur ma machine. As-tu exécuté ce programme sur la tienne ? J'aimerais avoir une indication de comparaison...

D'ailleirs, j'ai placé une autre démo dans ce dossier DirectX: un exemple de tir avec des sprites animées. Il s'agit de tirer sur des abeille en essaim. La touche Espace tire, les flèches gauche:droite déplacent l'engin, la touche Echap sort du programme. Est-ce que ça marche directement chez toi ? Le programme a été recompilé et généré sur ma machine.

J'ai réfléchi à l'intégration dans une DLL. Mais je pense malheureusement qu'on se heurte à une des limitations lourdes de la gestion des DLLs en Panoramic !

En effet, toute la logique sous-jacente à DirectX est une utilisation permanente des évènements, en particulier tout ce qui touche les sprites.

D'abord, les animations sont gérées dans une boucle dont chaque exécution est lancée par un timer. Certes, Panormaic a un timer. Mais celui requis pour les animations DirectX est différent et plus précis, et surtout interruptible à tout moment par d'autres évènements. Ce qui n'est pas le cas des timers Panoramic.

Ensuite, chaque sprite génère plusieurs évènements dont les principaux sont MOVE et COLLISION. Dans le programme de démo de tirs, il y a 30 sprites "abeille", un sprite "vaisseau" et plusieurs sprites "balles". Et tout ça génère des évènements à-gogo, et il fait les traiter dans un minimum de temps si l'on veut garder la performance.

Or, à ce jour, en-dehors de l'astuce que j'utilise dans KGF.dll pour déclencher un évènement en Panoramic (un on_change sur un EDIT ou un MEMO), j' n'ai aucun moyen d'avertir Panoramic d'un évènement quelconque. Et même mon souhait d'un USER_EVENT que j'avais proposé, ne pourrait pas résoudre le problème ici. Car là encore, on passerait par une API SendMessage pour envoyer un code à un objet Windows appartenant à Panoramic, et on est à ce moment totalement en-dehors de la synchronisation nécessaire pour faire tourner le moteur des sprites dans DirectX.

Une solution pourrait être la mise à disposition par Jack d'un mécanisme de "call back" - un moyen de passer une adresse à la DLL au moment du DLL_ON, et qui permettrait d'appeler directement une procédure de Panoramic, et qui se débrancherait alors sur un traitement Panoramic approprié, en fonction des paramètres transmis. Mais là encore, le temps qu'une procédure Panoramic appelle des fonctions DLL pour gérer l'évènement du sprite en prenant les mesures nécessaires, sera certainement incompatible avec une animation fluide.

Franchement, je ne vois pas comment je pourrais donner suffisamment de souplesse et en même temps de la performance à une interface Panoramic autour de DirectX.

Merci Klaus, je n'ai pas pu tester ton programme car j'ai regardé le forum ce matin avant de partir, mais il est certain que je le testerais ce soir.
Là au boulot, j'ai pas mal de charges, pas trop le temps d'aller sur le Webdav avant ce soir, mais pour info, tu as fait un programme compilé sous Delphi, c'est bien ça ?
Tu as bien creusé le sujet déjà et tu as répondu a une bonne partie des questions déjà: Utiliser DirectX permet d'avoir des animations beaucoup plus rapide mais son utilisation avec Panoramic tel qu'il est à ce jour est très complexe voir impossible à première vue sans intervention de Jack.

Bon, à moins que tu es une idée de génie, pour le moment, je pense que le débat est clos en attendant une éventuelle intervention de Jack (Je mettrais quand même la réponse au test du programme ce soir)

En tout cas, merci d'avoir tenté le coup Klaus.

PS: Que pense tu d'une idée encore plus farfelue, mais sans doute encore moins réaliste: faire un exe Delphi qui tournerait et qui recevrait des commandes Panoramic (taille de la fenêtre à créer, nom des sprites à créér et règles de déplacement et qui enverait une information au programme par ton astuce d'interuption pour prévenir en cas de collision entre 2 objets non traversables ou avec un des bords d'une zone de l'écran ?)

Ca me parait très farfelu, mais bon, disons que c'est mon dernier espoir, Général Kénobi (Heu non, Klaus )

Bref, un fichier exe qui serait lancé en parallèle et piloté par un programme Panoramic. Mais sinon, on attend de voir si Jack a une solution plus simple pour booster les performances.

Je ne suis pas un grand spécialiste de la 2D 3D, mais effectivement je pense que ce serai une grande avancé que de permettre l'utilisation de DIRECT-X.

D'ailleurs La plupart des jeux pour le pas dire la totalité utilisent ce logiciel. c'est donc qu'il doit y avoir un intérêt certain !

Rien que les premiers tests de Klaus paraissent édifiants !
de 10 a 365 FPS c'est juste multiplié par X36 !!

@ Jicehel,

Piloter un programme Delphi par un programme Panoramic !?§?! 
Autant tout faire en Delphi, non ?...
...enfin si tu sais programmer en Delphi.
Et si tu ne sais pas, il te faut l' apprendre pour faire tes deux programmes .

C' est un peu   ton affaire, non ?

L'idée de Jicehel, c'était de trouver un système plus rapide pour faire des jeux 2D avec des sprites multiples, en Panoramic.

Techniquement, la solution pourrait bien être DirectX. C'est fourni par MicroSoft, maintenu et suivi, performant et évolutif. Et surtout, DirectX utilise (si on l'autorise) le support hardware pour différentes fonctions très lourdes en calcul, comme les mouvements et la transparence. Donc oui, si DirectX était utilisable à partir de Panoramic, ce serait certainement un vrai progrès.

Techniquement, c'est une autre paire de manches ! Il y a une interface Delphi pour DirectX: elle s'appelle DelphiX, et les programmes de démo que j'ai placés sur mon WebDav, sont faits avec ça. En Delphi, la performance est convaincante, et la programmation est "facile", une fois qu'on a compris le principe. Mais, du fait de l'utilisation intensive des évènements, l'interface avec Panoramic sera très lourd et lent, et donc inadapté à ce que l'on veut faire.

Pour pouvoir gérer cela en Panoramic, il faudrait:
- un moyen très rapide, immédiat, pour appeler une SUB Panoramic directement à partir de la DLL (KGF.dll par exemple). Et ce ne peut pas être un label qu'on appellerait comme un GOSUB, mais il faudrait bien pouvoir appeler une SUB en passant une série de paramètres, dont le nombre serait à définir, et le type serait integer.
- pouvoir appeler un nombre non limité (ou assez large) de ces prodédures, car de manière générale, des dizaines de sprites peuvent générer des évènements différents
- pouvoir appeler ces procédures alors que d'autres sont encore en cours d'exécution, afin de répondre aux besoins des sprites en un temps proche du temps réel

Alors on pourrait créer des applications 2D avec sprites, performantes et souples. Et d'ailleurs, des applications 3D avec les mêmes moyens, puisque des sprites ne sont qu'un des types d'objets que DelphiX sait gérer. Il y a également les objets 3D classiques, avec textures, meshs, gestion de la 3ème dimension etc.

Donc, en réalité, tout dépend de l'évolution de l'interface entre Panoramic et les DLLs. Je verrais bien une commande du type:

Code:

DLL_SET_EVENT_SUB N,sub$,npar

avec:
N étant un numéro identifiant cette SUB pour son appel
sub$ contenant le nom de la SUB à appeler
npar étant le nombre de paramètres de type entier qui seront passés à la SUB par la DLL
Et il faudrait un mécanisme dans la DLL de pouvoir dire à Panoramic qu'on veut appler la SUB de numéro N, en donnant la liste des paramètres à passer à la SUB.

Techniquement, cea pourrait être réalisé en appelant une fonction particulière de la DLL directement par Panoramic, lors de l'exécution de la commande DLL_ON. Cette fonction aurait un nom et deux paramètres particuliers, comme ceci:

Code:

function DLL_To_Panoramic(adr%)

adr% serait une adresse qui correspond à une procédure dans Panoramic lui-même que la DLL pourrait appeler en passant le numéro de la SUB définie par la commande DLL_SET_EVENT, ainsi que la liste des paramètres prévus. On appelle cela une procédure call_back. C'est une technique connue, employée très souvent par les APIs de Windows, gérable en Delphi (et donc forcément par le noyau Panoramic).

Mais je crains que là, on se heurte à quelques-unes des limites que Jack s'est fixées: la simplicité tout d'abord, même si la présence de cette fonctionnalité n'impose pas au programmeur de l'utiliser, mais surtout la portabilité alors qu'on est en pleine discussion autour du compilateur et autour du portage sous Android. Cela dépendera peut-être aussi des souhaits des Panoramiciens...

Perso, tout ce qui peut être un plus je suis pour.
Que ce soit pour KGF.dll ou Panoramic ( je ne parle pas des autres, vous savez ce que j' en pense ).
L' Argument du "C' est trop compliqué " ne tient pas.
Si un utilisateur trouve le sujet trop complexe, il n' est pas obligé de s' en servir mais en évoluant dans ses
connaissances du langage il sera heureux de les retrouver.
Comme, malheureusement (ou pas   ) nous ne sommes pas éternels, tout ce qui est fait n' est plus à faire
et laissera un acquis.

Oui, plus qu'à voir ce qu'en pense Jack en fonction de ce qu'il a prévu et de ce qui est techniquement possible de faire.
De toute façon le système d'événement pour les DLL est demandé par Klaus depuis quelques temps car les applications en sont multiple (notamment l'interaction avec des objets externes à Panoramic). Attendons d'avoir sa réponse et bien sûr, je suis pour l'ajout de ce mécanisme et il est certain que cette fonctionalité ne sera à utiliser (si cela est techniquement possible) que par les utilisateurs avancés de Panoramic. Pour les nouveaux, il devront se contenter de copier les parties de codes fournient par Klaus pour en utiliser les fonctionnalités en modifiant les quelques paramètres commentés dans l'aide qu'il fournit toujours en accompagnement de ces ajouts.

Je vais me permettre de donner mon avis technique sur une éventuelle intégration de DirectX dans Panoramic. J'espère que Jack n'en prendra pas ombrage - c'est juste une réflexion sur la faisabilité et la méthodologie d'une telle approche.

J'ai examiné et expérimenté plusieurs systèmes, avec plus ou moins de bonheur. Le système DelphiX est ce que j'ai réussi à utiliser le mieux, le plus facilement. Voici le lien vers la page qui m'a permis de tout télécharger.

J'ai utilisé le premier lien dans la section "Downloads" - il y a un installateur qui s'adapte automatiquement à toutes les versions Delphi. Il a trouvé facilement mon Delphi 6 Personal Edition et a intégré les composants dans la palette de l'EDI, sans problème. Les démons fonctionnenent directement. Pour certaines, il faut télécharger des modules Rx... (SourceForge), mais ce n'est pas en lien direct avec la partie DirectX.

J'ai téléchargé également DelphiX_all_in_one_12 qui est un fichier RAR contenant beaucoup de choses, y compris une démo du module de gestion des sprites, programme recompilé par moi et mis à disposition sur mon WebDav, à titre de démo.

Techniquement, DelphiX se présente sous la forme d'un jeu d'unités en Delphi/Pascal. Ces unités peuvent être directement ajoutées à un programme Delphi pour bénéficier des fonctionnalités. En utilisant DelphiX, pas besoin de DLLs annexes - DelphiX accède directement la version installée de DirectX. Ce qui est un gros avantage.

Il y a aussi une encapsulation complète de ces fonctionnalités sous forme de composants VCL. Ces composants apparaissent automatiquement, après l'installation de DelphiX, dans un nouvel onglet de l'IDE de Delphi. Et absolument tout peut être géré via ces composants.

Je peux donc imaginer une intégration de tout ou partie de ces composants dans Panoramic, sous forme de nouveaux objets, tout simplement. Une partie des commandes existantes peuvent s'appliquer à certains de ces objets (WIDTH, TOP, TIMER_INTERVAL, ...). Pour d'autres, il faudra des commandes spécifiques, et des fonctions spécifiques pour retourner certaines valeurs. Et également de nouveaux types d'évènement, ou alors un seul type d'évènement ON_DIRECT_X, avec deux variables DIRECT_X_EVENT_TYPE et DIRECT_X_EVENT_OBJECT, ainsi que les fonctions citées ci-dessus pour connaître tous les détails sur l'évènement en question: mouvement d'un sprite, collision, timer DirectX, ..., identifiant de l'objet DirectX concerné (sprite, objet 3D, ...). C'est ainsi qu'on pourrait réagir directement et piloter l'application (le jeu).

L'avantage de DelphiX, c'est que ce module gère les collisions et livre un évènement en cas de collision. On n'a pas besoin de programmer la détection des collisions, ce qui facilite largement la programmation.

Un autre avantage, c'est que tout est passé automatiquement en double tampon. En effet, chaque vue est composée dans un tampon en mémoire. Lorsque l'image est prête, avec tous les déplacements, gestion de transparence etc, l'image est affichée par celle construite en mémoire, en une seule opération. Conséquence: un affichage très stable sans scintillement !

Un autre point fort: DelphiX peut utiliser les fichier PNG en utilisant le canal alpha pour la tranparence, qui n'est plus gérée en "tout ou rien", mais avec un taux de transparence entr 0 et 255. Il est ainsi facile de faire passer un nuage translucide devant certains objets... Et chaque fichier PNG peut contenir une ou plusieurs images pour le même sprite. Ces images seront affichées en boucle, donnant ainsi l'illusion d'un sprite animé (dans le cas des abeilles dans la démo de tir, ce sont deux images pour chaque abeille: ailles vers le haut, ailes vers le bas).

Et comme on est dans un système 3D, on peut évidemment faire des scènes 3D avec des objets chargés par des structures complexes (mesh) et habillés de textures.

Accessoirement, il y a des outils pour construire des bibliothèques d'images et/ou de sons qui, dans un seul fichier, peuvent contenir l'ensemble des éléments de leur catégorie pour un programme.

Conclusion:
Je pense que Jack a déjà réfléchi à un système 2D et 2D plus performant, et des versions de Panoramic autour de ce sujet sont déjà présentes. Je ne sais pas si ma petite réflexion peut avoir un intérêt pour lui, ni si cela rentre dans le cadre de l'orientation qu'il a choisie. Ce qui est certain, c'est que DirectX restera cantonné au monde Windows toutes versions - il y en a même une pour les Windows Phone sous W8.1 (comme le mien). Mais pas pour Android, ni les clones d'Unix. Donc, c'est un choix, et il ne m'appartient pas.