Question

J'ai une application MFC C ++ mature qui s'affiche à l'écran et imprime à l'aide de wrappings CDC sur le GDI Win32. Bien qu'il ait été optimisé au fil des ans, j'aimerais le remplacer par quelque chose d'un peu plus rapide. Les graphiques comprenaient des modèles de surface triangulaires rendus, des polylignes et des polygones complexes, ainsi que de nombreux textes. Il doit répondre aux critères suivants:

  • Le nombre de vecteurs affichés est susceptible d'être très grand. Par exemple, un triangle de surface unique est susceptible de générer des lignes numériques et des fonds pleins lors du rendu. Actuellement, ces informations ne sont stockées nulle part, elles sont générées et dessinées à la volée. Le SDK doit prendre en charge la limitation du nombre total de vecteurs mis en mémoire tampon, sinon il risque de manquer de mémoire.

  • Le SDK doit pouvoir afficher toutes les classes dérivées de CWnd, y compris les classes CView et ScrollView.

  • Le SDK doit prendre en charge l'impression sur tout périphérique d'impression Windows,

  • Le SDK doit être suffisamment bas pour rendre le port d'appels de bas niveau CDC / GDI relativement simple.

  • L'open source est toujours agréable, mais un coût ponctuel pouvant aller jusqu'à 2 000 dollars, avec des mises à niveau / un support optionnels, serait également acceptable. Un coût de licence par utilisateur n'est pas acceptable,

  • L'accès au code source constituerait un avantage considérable, en particulier si vous vouliez exécuter des parties du SDK sous Windows CE / Mobile.

  • Je gère actuellement ma propre gestion de fenêtres 3D à 2D. Si un SDK de bas niveau correct n'est pas disponible, un SDK de niveau supérieur doit gérer correctement les fichiers 3d et fonctionner avec des millions de triangles, polygones et entités de texte sur une plate-forme Windows 32 bits.

Des suggestions? Il serait grandement apprécié d’énumérer les avantages et les inconvénients spécifiques de votre proposition.

Était-ce utile?

La solution

J'ai déjà évalué FastGraph ( http://www.fastgraph.com ) pour un projet. Cela m'a plu dans les petits programmes de test que j'ai écrits, c'était très rapide. Nous avons fini par ne pas l'utiliser pour des raisons externes (rien à voir avec les bibliothèques que j'ai évaluées), donc je n'ai pas plus d'expérience pratique.

Autres conseils

Je pense que DirectX ou SDL répondra à vos besoins. Ils sont conçus pour la 3D mais fonctionnent également pour la 2D. Les deux prennent en charge Windows CE / Mobile et SDL est également disponible pour de nombreux systèmes d’exploitation non Microsoft.

Malheureusement, la compatibilité directe avec GDI n'est pas prise en charge dans les bibliothèques. Mais vous pouvez y arriver en créant une classe de convertisseur, qui acceptera tous les graphiques en sortie de vos classes d'applications conçues par GDI et convertira le format en fonction des besoins des classes DirectX ou SDL (selon ce que vous voulez utiliser).

Personnellement, j’ai fait cette classe de conversion une fois. J'avais un jeu écrit pour Pocket PC, utilisant SDL et je devais le porter sur un appareil Palm. Là, j'ai dû utiliser différentes bibliothèques graphiques (je ne me souviens plus du nom de la bibliothèque à présent), mais j'ai réussi à porter toutes les fonctions SDL au format requis par l'autre bibliothèque. J'avais besoin de changer d'application pour appeler les fonctions de conversion (wrapper), qui transmettaient l'appel à la bibliothèque Palm ou Pocket PC, en fonction du périphérique utilisé. Donc, je pense que vous pouvez faire la même chose pour convertir GDI - > DirectX ou GDI - > SDL.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top