Mathieu Schroeter a écrit 131 commentaires

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 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.

En effet, l'ARM c'est une autre question. Je me suis même demandé si j'allais faire aussi un build FreeBSD. Et comme tu dis, j'ai supposé que l'auteur parle bien de l'architecture x86-32.

Tu as tout compris car c'est pas le plus fun de pondre des binaires. Surtout que pour Windows je dois passer par une clef hardware pour signer les binaires et l'installateur (y a peut être moyen de faire supporter par Linux en cross mais je n'ai pas vraiment le temps et l'envie). Et pour macOS je suis toute façon obligé de booter le Mac exprès car c'est le seul moyen de signer un .app. Et le SDK Apple en cross c'est très compliqué (on le faisait il y a très longtemps avec le projet GeeXboX, que des builds cross pour macOS mais ce temps là est révolu).

Le plus simple ça reste Linux avec une signature GPG sur l'AppImage. Un pote s'occupe du paquet Debian officiel un de ces 4.

Je ne vois aucun intérêt de faire du 32 bits en 2017. Je n'ai donc pas l'intention de compiler moi-même pour cette architecture que je considère personellement comme obsolète.

Il faut faire un :

git clone --recursive https://github.com/blupi-games/planetblupi-dev.git

pour prendre les sous-modules avec.

Principalement parce que j'ai envie de le faire tout seul.

Merci

le design de l'UEFI n'est pas de la responsabilité de Microsoft

C'est juste une question mais pourquoi les partitions de boot EFI doivent utiliser FAT32 ? Y'a vraiment aucun lien entre Microsoft et UEFI ?

Je répète que c'est une question, ce n'est pas sarcastique.

Hello,

Pour le fun j'ai testé le code suivant avec le compilateur CL de Microsoft en toolset vc140.

#include <iostream>

int t[6] = { 0, 0, 0, 0, 0, 0 };

struct A
{
  A () { ++t[0]; }
  A (A const&) { ++t[1]; }
  A& operator=(A const&) { ++t[2]; return *this; }
//#if __cplusplus > 201100
  A (A &&) { ++t[3]; }
  A& operator=(A &&) { ++t[4]; return *this; }
//#endif
  ~A () { ++t[5]; }
};

A f () { return A (A ()); }

int main ()
{
  { A a = A (A (A (f ()))); }

  std::cout << "Dflt = " << t[0] << "\n"
    "Copy = " << t[1] << "\n"
    "CpAs = " << t[2] << "\n"
//#if __cplusplus > 201100
    "Move = " << t[3] << "\n"
    "MvAs = " << t[4] << "\n"
//#endif
    "Dtor = " << t[5] << '\n';
}

Résultats :

Dflt = 1
Copy = 0
CpAs = 0
Move = 3
MvAs = 0
Dtor = 4

A priori CL ne sait pas faire l'élision aussi efficacement que g++ et clang++ dans ce cas de figure.

Et le lien sans la date pointe toujours sur le dernier:
http://88.80.16.63/torrent/cablegate/cablegate.7z.torrent

Question 2 : quel environnement de build utilisez vous ? Bon ok question idiote :) disons plutot "est ce un projet from scratch ou bien en collaboration avec par exemple BuildRoot ? )

A l'origine le projet a été écrit "from scratch" et pour le plaisir de faire les choses par soi-même par les deux fondateurs du projet GeeXboX (dont l'auteur de la news). Puis le toolchain a été amélioré par beaucoup d'autres contributeurs. Jusqu'à OpenBricks il n'y avait aucune promotion de nos outils. Bien que parfois il y avait quelqu'un qui passait sur notre devel-list pour proposer des patchs parce qu'il utilisait le toolchain à d'autres fin que pour le multimédia par exemple. Un intérêt pour certaines personnes de passer par un toolchain GeeXboX modifié que par un buildroot, etc,... était donc bien réel.
Personnellement j'ai utilisé le toolchain GeeXboX pour équiper un robot dans un labo. Néanmoins, faisant partie du team c'est "normal" que je ne sois pas passé par un autre outil.

Un des gros avantages de GeeXboX c'est à mon avis sa simplicité. Sans documentation c'est facile à comprendre comment ça fonctionne. Puis un deuxième point que je considère très important par rapport aux autres solutions c'est qu'il est orienté shell script. Je trouve indigeste les toolchains orientés Makefiles (comme buildroot) ou Bitbake (comme OE). Mais c'est une question de goût je suppose.

Si si.. les sources d'HL2 étaient bien sur le net.

C'est toujours possible de forcer une localisation dans le fichier de configuration.

Il n'y a aucune régression, mais uniquement plus de choix pour les utilisateurs. Le mono-fenêtre est optionnel.

J2SE c'est un framework (grossièrement un amas de bibliothèques), quel est donc le rapport avec la libc (une seule bibliothèque) ?

Le problème principal c'est les fork() et exec*(), qui devraient être gérés par Evil mais ce n'était pas encore le cas la dernière fois que j'ai essayé de l'utiliser. Et pthread-win32 fait l'affaire à part pour quelques détails. A noter aussi quelques accrochages avec les changements de priorités sur les threads. Mais là aussi il n'y a rien d'insurmontable.

Reste à avoir l'envie de le faire. :)

Ça devrait être une étape dans le développement (car l'auteur original d'Enna souhaite le voir sous Windows, et depuis longtemps d'ailleurs), mais je ne pense pas que ça sera fait dans un futur proche.

Peut être qu'il aimerait des GIF animés? Qu'est-ce que t'en penses?

Je ne saurais dire si Geexbox est laid, je ne l'ai jamais vu., Il faudra que tu me le présentes. Et il n'y a pas si longtemps, des collègues me disaient 'Linux c'est moche'. Peut être que tu pourras aussi me le présenter, car j'ai toujours voulu le voir.

Quoi qu'il en soit, si mon code est aussi laid que Geexbox, je ne dois pas risquer grand chose. :)

Techniquement c'est pas difficile à faire, libplayer le permet indirectement. Mais ça demande du hack dans Enna.

Dit autrement, c'est pas possible dans l'état actuel.

J'ai personnellement rejoins le team GeeXboX uniquement par intérêt personnel. Il faut être clair. Souvent on le fait pour sois, comme ajouter une nouvelle fonctionnalité parce qu'on en a besoin à un moment ou un autre (avec le temps les choses évoluent car certaines responsabilités apparaissent et donc certaines choses doivent se faire parce qu'il le faut et non plus parce qu'on en a envie).

Le fait que se sois du logiciel libre laisse la porte ouverte à tout le monde. Et je n'ai jamais vu dans ces projets la moindre concurrence. GeeXboX a un intérêt bien particulier. C'est avant tout une distribution fait maison. Le toolchain est facile à comprendre et l'ensemble fonctionne bien. Ce projet permet de comprendre comment se construit un système basé sur Linux sans faire des efforts monstrueux. Et puis à cette époque j'avais besoin d'un petit media center pour le salon. C'était une bonne occasion de s'y intéresser. Le design et l'ergonomie j'en avais rien a faire tant que ça lisait les fichiers que je voulais

Je trouve décevant le genre de réponse 'quel intérêt?'. Tous les projets en ont, au moins pour les gens qui y participent.


Après pour les personnes extérieurs, et bien c'est très simple, si ça les intéressent alors tant mieux.. sinon tant pis. Honnêtement s'il y a que 10 personnes qui utilisent Enna dans le monde, ou alors 10000 ça ne me change pas la vie. Je ne travail pas pour ces gens. L'avantage d'en avoir 10000 c'est d'avoir plus de rapports de bugs (pas toujours de très bonnes qualités mais c'est mieux que rien), et surtout d'avoir des gens qui proposent des patchs (et là c'est déjà beaucoup plus limité).


Maintenant XBMC.. je l'ai testé et c'est très sympa.. même qu'on a repiqué des idées dans Enna. Au niveau sources il ne m'intéresse pas du tout. En plus la sortie est uniquement OpenGL a priori. Maintenant pourquoi ne pas bosser sur XBMC??
La division des efforts je n'y crois pas.. Pourquoi travailler sur un projet où l'on en a pas envie? A moins d'être payé... ça serait discutable..

Autre exemple.. Freevo.. c'est super, j'aime bien .. d'ailleurs un temps on a voulu utiliser Freevo2 comme GUI pour GeeXboX 2. Mais on a laissé tombé pour différentes raisons. Personnellement j'ai aucune envie de faire du Python. Alors quel intérêt de travailler avec l'équipe de Freevo surtout si on préfère le C? Et il y a d'autres raisons aussi..


Bref.. chacun à ses propres intérêts dans chaque projet. A mon avis se sont particulièrement les utilisateurs qui voient de la concurrence entre les projets. Ou alors ceux qui ont des intérêts financiers..

Bien sûr, tout ce que je dis n'engage que moi.. je ne connais pas vraiment les intérêts des autres membres du team.

Oui c'est bien Enna qui servira à la prochaine version de GeeXboX. L'ancienne interface (GeeXboX 1.x) est très rigide; non pas par choix, mais pour des raisons techniques. L'ancienne est basée sur OSD d'MPlayer, et il ne faut pas rêver, c'est très limité (néanmoins c'est très léger). La nouvelle est basé sur les EFL et ça n'a donc plus rien à voir. Par rapport à l'ancienne interface on peut même aller jusqu'à dire que les seules limitations sont le temps, la motivation et l'imagination.

Par défaut Enna est configuré en software_x11. Tu peux passer en OpenGL mais il faut le modifier via le fichier de config $HOME/.enna/enna.cfg .. c'est beaucoup plus réactif.

Mplayer et Xine par exemple possède déjà des mécanismes gérant en 'externe' le CSS ('decss'),

MPlayer et xine utilisent la libdvdcss qu'il ne faut pas confondre avec DeCSS. L'implémentation est différente.

Depuis Karmic, il est possible d'annuler le check (le système le propose) sans passer par un CTRL+C.

Pour libpthread je ne suis pas sûr de comprendre où tu veux en venir?
Si tu fais référence à des choses tel que (t1 == t2) au lieu d'un pthread_equal(t1, t2) par exemple, le premier se plante sous Windows vu que se sont des structures. En général c'est une bonne raison pour envoyer un patch au projet.
C'est jamais une grosse affaire à corriger, et je serais étonné que le mainteneur du projet qui aurait ce type de "bug" refuse, vu que ce serait de toute façon une mauvaise utilisation de pthread.