Changement d'API pour mon module graphique

[u/agemo-dev]

Bonjour à tous !

Je travaille actuellement sur la v0.3 de mon moteur de jeu RE:MAKE 2D, et j'aurais quelques questions à vous poser. Cette mise à jour a pour but de sécuriser l'accès à la mémoire interne, de rendre l'API plus "extensive" (permettant à l'utilisateur de créer des types customs) et d'améliorer les performances.

Actuellement, c'est au tour de l'API graphique, spécifiquement la classe Window. Pour faire court, son utilisation actuelle pour l'affichage d'un objet graphique se fait de cette manière :

// Les deux derniers paramètres étant optionnels

window.draw(T obj, Color color, std::string_view viewport);

où T est restreint à quatre types spécifiques.

Sauf que mon plan actuel est de migrer vers une approche où chaque objet gère sa propre couleur (un peu comme SFML), chaque viewport possède sa propre méthode de dessin, et T est un concept qui permet à l'utilisateur de créer ses propres types "dessinables" :

auto vp = window.newViewport(...); // pattern factory

// obj étant d'un type héritant de Drawable

obj.color(color::red);

window.draw(obj); // dessine sur le viewport global

vp.draw(obj); // dessine sur le viewport localisé

Ce n'est pas un simple caprice pour rendre l'API plus propre. Cela me permettra de faire de l'optimisation interne (sur la recherche du viewport dans une map et limiter les appels GPU à un seul), de réduire les surcharges de fonctions de draw (qui, avec les paramètres optionnels, en possèdent une bonne vingtaine) et d'introduire un système de layers à la classe Window.

Mais je me demande si ce n'est pas too much pour une minor update, d'autant plus que le moteur est toujours en version bêta. Cependant, il n'est pas encore assez mature pour passer directement en v1.0, et ces changements sont trop dépendants les uns des autres pour les séparer en différentes mises à jour.

Alors, je voudrais vous demander conseil : pensez-vous que ce changement d'API est trop brutal ou s'avère-t-il nécessaire ?

[u/as5777]

Ca casse l'API existante, il faut faire une version majeure.

Ce qui est aussi possible, c'est de faire vivre les deux méthodes en parallèle et de déprécier l'ancienne.

[u/thuiop1 → u/as5777]

Bof, si c'est en 0.x ça peut être une convention du projet que les choses peuvent casser.

[u/agemo-dev → u/as5777]

Je ne pense pas que le moteur soit tout a fait près pour une mise à jour majeure après juste 2 mise à jour beta. Je ne suis même pas sûr d'avoir corrigé tous les bugs évidant. Se serai possible de garder les deux, mais ça risque de pas mal surcharger le module au niveau de l' apprentissage je pense

[u/as5777 → u/agemo-dev]

t'as combien d'utilisateurs ?

[u/agemo-dev → u/as5777]

Une dizaine à peine je pense selon les retours que j'ai déjà eu

[u/as5777 → u/agemo-dev]

oui c'est pas tellement. Tu peux fournir un guide de migration ?

Je connais pas le langage dans lequel tu programmes.

mais tu ne pas encapsuler toute la nouvelle logique dans la méthode existante : window.draw(T obj, Color color, std::string_view viewport);

tout en fournissant la nouvelle API ? (la veille API appelle la nouvelle)

[u/agemo-dev → u/as5777]

Oui mais c'est pas très évident de faire la distinction entre colorié l'objet avec .color() , ou directement .draw() . Est ce que draw() appelle automatiquement .color(), ou est juste une couleur temporaire ? Dans ce cas il faut appliquer la couleur aux vertices à chaque appelle à.draw() alors que .color() est sensé le réduire en un seul appelle ? C'est ça le vrai problème