J'ai travaillé dessus par bribes. Le remplacement de la boucle événementielle c'est assez facile car c'est presque du 1:1 entre les événements Windows et SDL2. Il y a quelques différences notables entre les deux en ce qui concerne les touches modificateurs comme Ctrl, Shift, etc,... mais rien d'insurmontable.
Au tout début j'ai travaillé uniquement avec Visual Studio en gardant le code DirectX tout en ajoutant en parallèle une fenêtre SDL2 pour produire le même résultat graphique. Le lancement du jeu produisait alors deux fenêtres. Celle de DirectX continuait de recevoir les événements. Celle pour SDL2 se contentait de reproduire le dessin.
Cette étape n'était pas très complexe au début, car les surfaces DirectDraw peuvent facilement être traduites en surfaces SDL2. Une fois que j'ai fait le 90% du travail (j'avais encore qques soucis avec la minimap qui travail au pixel et quelques incrustations qui foiraient), je suis passé des surfaces SDL2 au textures SDL2. Pour ceux qui ne connaissent pas trop SDL2. Les textures sont chargées dans la carte graphique, ce qui n'est pas le cas des surfaces qui restent en RAM principale. Cette différence est fondamental car ça exploite mieux la matériel, par contre ça complique un peu le travail si on désire accéder directement à une texture en écriture.
En parallèle à tout ça, il y a eu le remplacement de DirectSound par SDL2_mixer. En résumé j'ai pu virer beaucoup de code car DirectSound reste plus bas niveau qu'SDL2_mixer. J'ai juste pris un peu de temps sur le panning (faire varier le son de gauche à droite et droite à gauche selon la position des objets qui génèrent des sons). Ca m'a pris un petit peu de temps à recalibrer tout ça car DirectSound travail en décibel et SDL_mixer en gain (0-100%). Honnêtement je n'ai jamais compris pourquoi DirectSound parle de décibel. L'API reste plus obscure qu'SDL2_mixer qui est très clair.
Pour les traductions, le code original utilise des ressources Win32 (assez classique pour des win-app). Donc en gros c'était vraiment de la productique d'insérer les appels gettext partout où il y avait des LoadString(id) à l'origine.
Une fois que j'ai remplacé tout ce qui était purement Windows par SDL2, j'ai viré le code Win32/DirectX et je suis enfin passé sous Linux (j'ai développé une forte intolérence à Visual Studio, et je dois tout le temps l'utiliser au job). Du coup je développe que sous Linux et avec Kdevelop (je ne publie pas les fichiers de projets Kdevelop, ils sont facile a régénérer).
Finalement la première version utilisable a été pour Linux. Ensuite je me suis occupé de Windows est utilisant MSYS2. Je ne souhaite pas supporter MSVC à nouveau car pour gérer les dépendances c'est galère (nuget, non merci.. j'ai pas de temps à perdre avec ça). Avec MSYS2 je garde le même CMakeLists avec quelques conditions mais rien d'incroyable.
Bref, les builds sont static autant que possible. La aussi, c'est personnel car je n'aime pas beaucoup le dynamique pour ce type de projet. Si vous regardez dans l'AppImage, il y a qu'un seul binaire, pour macOS également. Il y a juste sous Windows qu'il reste une DLL car je n'ai pas réussi à la linker en static sans que ça me rajoute d'autres liens dynamiques.
Il est possible de faire du dynamique en utilisant directement le dépôt planetblupi à la place de planetblupi-dev. C'est par exemple nécessaire pour ceux qui génèrent les paquets des distributions. Je m'excuse d'avance de mes CMakeLists qui ne sont pas des oeuvres d'arts mais ils font le job sur les 3 plateformes et c'est ce qui m'importe.
[^] # Re: Portage
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 10.
Merci, pour répondre un peu à ta question :
J'ai travaillé dessus par bribes. Le remplacement de la boucle événementielle c'est assez facile car c'est presque du 1:1 entre les événements Windows et SDL2. Il y a quelques différences notables entre les deux en ce qui concerne les touches modificateurs comme Ctrl, Shift, etc,... mais rien d'insurmontable.
Au tout début j'ai travaillé uniquement avec Visual Studio en gardant le code DirectX tout en ajoutant en parallèle une fenêtre SDL2 pour produire le même résultat graphique. Le lancement du jeu produisait alors deux fenêtres. Celle de DirectX continuait de recevoir les événements. Celle pour SDL2 se contentait de reproduire le dessin.
Cette étape n'était pas très complexe au début, car les surfaces DirectDraw peuvent facilement être traduites en surfaces SDL2. Une fois que j'ai fait le 90% du travail (j'avais encore qques soucis avec la minimap qui travail au pixel et quelques incrustations qui foiraient), je suis passé des surfaces SDL2 au textures SDL2. Pour ceux qui ne connaissent pas trop SDL2. Les textures sont chargées dans la carte graphique, ce qui n'est pas le cas des surfaces qui restent en RAM principale. Cette différence est fondamental car ça exploite mieux la matériel, par contre ça complique un peu le travail si on désire accéder directement à une texture en écriture.
En parallèle à tout ça, il y a eu le remplacement de DirectSound par SDL2_mixer. En résumé j'ai pu virer beaucoup de code car DirectSound reste plus bas niveau qu'SDL2_mixer. J'ai juste pris un peu de temps sur le panning (faire varier le son de gauche à droite et droite à gauche selon la position des objets qui génèrent des sons). Ca m'a pris un petit peu de temps à recalibrer tout ça car DirectSound travail en décibel et SDL_mixer en gain (0-100%). Honnêtement je n'ai jamais compris pourquoi DirectSound parle de décibel. L'API reste plus obscure qu'SDL2_mixer qui est très clair.
Pour les traductions, le code original utilise des ressources Win32 (assez classique pour des win-app). Donc en gros c'était vraiment de la productique d'insérer les appels gettext partout où il y avait des
LoadString(id)à l'origine.Une fois que j'ai remplacé tout ce qui était purement Windows par SDL2, j'ai viré le code Win32/DirectX et je suis enfin passé sous Linux (j'ai développé une forte intolérence à Visual Studio, et je dois tout le temps l'utiliser au job). Du coup je développe que sous Linux et avec Kdevelop (je ne publie pas les fichiers de projets Kdevelop, ils sont facile a régénérer).
Finalement la première version utilisable a été pour Linux. Ensuite je me suis occupé de Windows est utilisant MSYS2. Je ne souhaite pas supporter MSVC à nouveau car pour gérer les dépendances c'est galère (nuget, non merci.. j'ai pas de temps à perdre avec ça). Avec MSYS2 je garde le même CMakeLists avec quelques conditions mais rien d'incroyable.
Bref, les builds sont static autant que possible. La aussi, c'est personnel car je n'aime pas beaucoup le dynamique pour ce type de projet. Si vous regardez dans l'AppImage, il y a qu'un seul binaire, pour macOS également. Il y a juste sous Windows qu'il reste une DLL car je n'ai pas réussi à la linker en static sans que ça me rajoute d'autres liens dynamiques.
Il est possible de faire du dynamique en utilisant directement le dépôt
planetblupià la place deplanetblupi-dev. C'est par exemple nécessaire pour ceux qui génèrent les paquets des distributions. Je m'excuse d'avance de mes CMakeLists qui ne sont pas des oeuvres d'arts mais ils font le job sur les 3 plateformes et c'est ce qui m'importe.