Tu peux t'attendre au même genre de problème avec std::shared_ptr puisque s'il est créé avec std::make_shared ou std::allocate_shared, la mémoire pour les données propres au pointeur partagé et celle pour l'objet lui-même sont généralement allouées en un seul bloc. C'est en fait un fonctionnement assez proches des std::string copy-on-write puisque la mémoire était aussi partagée (jusqu'à la première écriture).
Je crée des tableaux de taille COUNT(1) jusqu'à COUNT(800), puis 1000 de plus avec COUNT(100). J'utilise g++ 11.0.1 et clang++ 12.0.0. Les temps sont des moyennes pifométriques calculées après quelques essais.
g++: TEMPLATE → 530ms, FUNCTION → 450ms, FOLD → 15s
clang++: TEMPLATE → 540ms, FUNCTION → 600ms, FOLD → instantiating fold expression with 257 arguments exceeded expression nesting limit of 256
Ce genre d'utilisations de fold expressions est clairement une mauvaise idée. Entre variable et fonction, la différence est moins nette et dépend du compilateur, donc pas de vainqueur.
Donc sur PC, seulement Windows 10. Je veux dire que c'est très relatifs, selon quelles plateformes comptent le plus pour toi. Et, personnellement, pour un jeu comme Minecraft, je n'imagine pas y jouer sur autre chose que PC (clavier/souris).
Là je suis curieux, parce que quand tu vas sur le site de Minecraft, il est explicitement mentionné que la version Java (celle qui tourne sous Linux & Mac, mais tout de même dispo sous Windows) te met dans un monde isolé de toutes les autres plateformes, avec des restrictions comparé au multi-plateformes (pas de mini-jeux, par exemple).
C'est le contraire, c'est la version Windows 10 qui te met dans un monde isolé de toutes les autres plateformes (tu ne peux pas jouer avec ceux sous Linux/Mac/vieux Windows).
Méfie-toi de la façon dont c'est présenté, Microsoft veut mettre en avant sa version la plus verrouillée.
Si tu veux aider un projet de RPG à s'améliorer, OpenMW essaie de créer une suite d'exemple. Ce projet à réimplémenté le moteur d'elder scroll III, et est déjà bien meilleur que l'original sur pas mal de points (je suppose qu'il en reste ou il est au maximum equivalent…) notamment graphiques.
Ils ont également un éditeur de carte de leur cru, qui semble nécessiter encore du travail mais être utilisable (mieux que l'original? Pas sûr), et avec lequel il est prévu de faire cette fameuse suite d'exemple.
Je n'ai aucun doute que personne n'aura rien contre transformer une telle suite d'exemple en jeu complet, il faut "juste" faire le taf. En attendant, openmw est un bon moyen de jouer à morrowind, en y mettant au passage le contenu de tamriel rebuilt, si la licence des fichiers de jeu ne te dérange pas trop.
Le moteur de jeu lui-même est largement supérieur au moteur original. C'est par rapport à MGE XE qu'il y a des retards graphiques (post-traitements et, à mon goût, la qualité des effets atmosphériques mais ce dernier est peut-être déjà faisable en modifiant les shaders). Le gros retard d'OpenMW est surtout sur l'éditeur de niveau, qui n'est pas complet. En particulier, il manque un éditeur de dialogue (à moins que ça n'ait été ajouté très récemment).
Mais que l'état de l'éditeur ne décourage pas ceux qui voudrait créer un RPG libre avec OpenMW, il y a suffisamment de travail d'écriture et de créations d'assets avec ce genre de projet pour être occupé jusqu'à ce que l'éditeur soit complet (mais c'est peut-être justement l'ampleur de ce travail qui décourage beaucoup de libristes).
Mais si on a un pseudo, c'est plus comme faire un tag sur un mur quelconque. Les passants peuvent le lire mais ne savent pas qui est vraiment l'auteur (à part celui qui a accès à la caméra de surveillance qui t'a filmé en train de taguer : l'admin du site/service).
Ça semble possible avec la nouvelle syntaxe mais je ne garantie pas le qualité de ce que j'ai écrit. Ça marche avec GCC et clang, mais MSVC ne semble pas encore supporter la nouvelle syntaxe. Donc en pratique, pour l'instant, c'est pas mieux que l'extension GNU mais ça pourrait être le futur.
Il me semble que la syntaxe des littéraux que tu utilises pour _kw est une extension GNU et pas du C++14 standard.
Je me souviens avoir essayé de créer des littéraux du même genre (chaîne dans un type) et de ne rien avoir trouvé de pratique et standard. Peut-être que C++20 améliore ça, je ne connais pas encore très bien.
J'ai pas essayé coc, ça a l'air un peu trop gros pour moi. Pour pouvoir utiliser LSP, j'ai installé LanguageClient-neovim. Il y a juste à lui dire quel serveur utiliser pour chaque langage, pas besoin d'installer nodejs.
Oui c'est comme ça qu'il y a des consoles libres à base de microcontroleurs 8bits. Mais c'est du temps processeur de pris donc ça peut facilement ramer si le jeu a un rafraichissement rapide ou exige beaucoup de changements de pixels par image. C'est l'une des raisons de la disponibilité de différents modes d'affichage sur les vieux ordis.
Sinon pas nécessaire d'aller si bas niveau pour une console virtuelle conçue pour des ordinateurs actuels de 32bit ou plus qui possédent tous un GPU gérant au minimum OpenGLES.
On est quand même sur du dessin très simple : rotations à 90 degrés et étirements par des facteurs entiers pour les opérations les plus complexes. On a surtout besoin de copier des pixels un peu partout, un CPU n'est pas si mauvais pour ça.
Et OpenGL, c'est aussi du temps CPU pour envoyer les données et commandes à chaque image. Et sur un eeepc avec une implémentation logiciel d'OpenGL, on doit se retrouver avec un surcoût énorme comparé à un rendu logiciel naïf qu'on aurait pu écrire soi-même.
La NES et la SMS
Des machines avec des processeurs très très faibles mais compensés par des GPU spécialisés dans le dessin de sprites. J'aurais plutôt comparé aux vieux jeux DOS qui faisaient mieux que le TIC-80 mais sans accélération matérielle.
Vu le type de dessin, ça devrait être possible de faire ce genre de rendu en logiciel sur n'importe quel processeur du 21ème siècle, non ?
À une époque j'ai pas mal programmé sur TI-89 (Motorola 68k à 12MHz, 256Ko de RAM), il n'y avait pas d'accélération matériel graphique mais ça ne posait pas trop de problèmes pour faire des jeux 2D simples. Ce n'était que du monochrome mais avec la différence de puissance des processeurs on devrait quand même pouvoir passer à 16 couleurs.
Il est bizarre ce logiciel libre : je n'ai pas trouvé de lien vers le code source sur le site. La seule version Linux est un paquet Debian, j'ai donc besoin de compiler pour ma distribution exotique (fedora). On trouve bien des liens vers github pour les bugs ou le wiki, mais rien vers le code lui-même.
J'ai l'impression que c'est le pronom relatif implicite qui te dérange : « Falsehoods (that) programmers believe about names » → « Erreurs auxquels les programmeurs croient au sujet des noms »
Pour compléter les autres réponses, il y a un mécanicisme un peu plus complexe mais plus puissant (et qui est celui utilisé dans le journal). Il se base sur une règle du C++ abrégée en SFINAE (Substitution Failure Is Not An Error). L'idée est que si, lors de la substitution d'un type dans un template, on obtient une déclaration que n'a pas de sens, le compilateur ignore la fonction au lieu d'émettre une erreur. Ça ne marche que dans la déclaration (paramètres du template, type de retour, ou types des paramètres), pas dans le corps de la fonction.
#include<iostream>template<typenameT>typenameT::Af(T){std::cout<<"J'ai un type imbriqué A"<<std::endl;return{};}template<typenameT>typenameT::Bf(T){std::cout<<"J'ai un type imbriqué B"<<std::endl;return{};}structType1{usingA=int;};structType2{usingB=int;};intmain(){f(Type1{});f(Type2{});return0;}
Ce qui donne :
J'ai un type imbriqué A
J'ai un type imbriqué B
Pas d'erreurs puisqu'à chaque fois exactement une des fonctions est gardée. Si un type avait à la fois une type imbriqué A et B, les deux fonctions seraient valide et le compilateur générerait une erreur comme il ne saurait pas choisir. Si un type n'a aucune des deux propriétés, les deux fonctions sont ignorées et le compilateur génère une erreur disant que f n'existe pas (mais s'il est sympa, il t'explique pourquoi il a ignoré les deux possibilités avec un message à rallonge).
Ça permet d'avoir des fonctions surchargées qui sélectionnent la bonne alternative en fonction des propriétés d'un type paramètre du template. Évidemment, si la condition que tu veux avoir n'est pas un type que tu utilises en retour ou en paramètre, ça devient plus compliqué mais beaucoup de choses sont possibles. Les concepts de C++20 simplifient largement tout ça.
Pour aider à l'utilisation avancée du SFINAE pré-C++20, il y avait quelques aides comme enable_if et une TS proposait d'ajouter des détecteurs (mais c'est sûrement devenu obsolète avec les concepts).
# shared_ptr
Posté par Clément V . En réponse au journal Alignement chaotic neutre. Évalué à 2.
Tu peux t'attendre au même genre de problème avec
std::shared_ptr
puisque s'il est créé avecstd::make_shared
oustd::allocate_shared
, la mémoire pour les données propres au pointeur partagé et celle pour l'objet lui-même sont généralement allouées en un seul bloc. C'est en fait un fonctionnement assez proches desstd::string
copy-on-write puisque la mémoire était aussi partagée (jusqu'à la première écriture).[^] # Re: Ed(1)
Posté par Clément V . En réponse à la dépêche LSP (Language Server Protocol). Évalué à 2.
Étrange, c'est souvent dans le système de base. Sur Fedora, c'est le paquet
ed
.Normal, ex c'est vi et, de nos jours, vi c'est vim.
À éditer des textes sans s'encombrer de fonctionnalités inutiles comme voir le texte qu'on est en train d'éditer.
[^] # Re: et avec les fold-expressions ?
Posté par Clément V . En réponse au journal Constexpr versus template. Évalué à 3.
Je tente un petit benchmark vite fait, et au passage je compare aussi variable template vs. fonction.
Je crée des tableaux de taille COUNT(1) jusqu'à COUNT(800), puis 1000 de plus avec COUNT(100). J'utilise g++ 11.0.1 et clang++ 12.0.0. Les temps sont des moyennes pifométriques calculées après quelques essais.
instantiating fold expression with 257 arguments exceeded expression nesting limit of 256
Ce genre d'utilisations de fold expressions est clairement une mauvaise idée. Entre variable et fonction, la différence est moins nette et dépend du compilateur, donc pas de vainqueur.
[^] # Re: et avec les fold-expressions ?
Posté par Clément V . En réponse au journal Constexpr versus template. Évalué à 4.
Comme l'a fait remarquer SChauveau, les fold-expressions utilisent des packs. Il faut donc en créer un, par exemple avec make_integer_sequence :
Mais ça utilise des templates avec plein de paramètres, sûrement très lourds. Alors qu'on pourrait simplement utiliser une boucle for.
Mais je n'ai pas fait de benchmarks pour comparer, peut-être que je me trompe.
[^] # Re: question naïve
Posté par Clément V . En réponse au journal Battle royal et adolescence…. Évalué à 1.
Donc sur PC, seulement Windows 10. Je veux dire que c'est très relatifs, selon quelles plateformes comptent le plus pour toi. Et, personnellement, pour un jeu comme Minecraft, je n'imagine pas y jouer sur autre chose que PC (clavier/souris).
[^] # Re: question naïve
Posté par Clément V . En réponse au journal Battle royal et adolescence…. Évalué à 9.
C'est le contraire, c'est la version Windows 10 qui te met dans un monde isolé de toutes les autres plateformes (tu ne peux pas jouer avec ceux sous Linux/Mac/vieux Windows).
Méfie-toi de la façon dont c'est présenté, Microsoft veut mettre en avant sa version la plus verrouillée.
[^] # Re: pas tout seul
Posté par Clément V . En réponse au journal Nostalgie d'Internet des années 2000.. Évalué à 2.
Le moteur de jeu lui-même est largement supérieur au moteur original. C'est par rapport à MGE XE qu'il y a des retards graphiques (post-traitements et, à mon goût, la qualité des effets atmosphériques mais ce dernier est peut-être déjà faisable en modifiant les shaders). Le gros retard d'OpenMW est surtout sur l'éditeur de niveau, qui n'est pas complet. En particulier, il manque un éditeur de dialogue (à moins que ça n'ait été ajouté très récemment).
Mais que l'état de l'éditeur ne décourage pas ceux qui voudrait créer un RPG libre avec OpenMW, il y a suffisamment de travail d'écriture et de créations d'assets avec ce genre de projet pour être occupé jusqu'à ce que l'éditeur soit complet (mais c'est peut-être justement l'ampleur de ce travail qui décourage beaucoup de libristes).
[^] # Re: Beaucoup de "solutions"
Posté par Clément V . En réponse au journal Jouer à distance avec du logiciel libre. Évalué à 1.
Steam Link, ce n'est ni payant, ni du cloud. Tu utilises ton propre ordinateur pour lancer le jeu. Mais c'est proprio et nécessite un compte en ligne.
# VirtualGL
Posté par Clément V . En réponse au journal Jouer à distance avec du logiciel libre. Évalué à 5.
https://www.virtualgl.org/
C'est du X11 à distance mais le rendu 3D est effectué sur le serveur puis envoyé au client sous forme d'images.
[^] # Re: La part des choses...
Posté par Clément V . En réponse au journal Ados et réseaux sociaux. Évalué à 3.
Mais si on a un pseudo, c'est plus comme faire un tag sur un mur quelconque. Les passants peuvent le lire mais ne savent pas qui est vraiment l'auteur (à part celui qui a accès à la caméra de surveillance qui t'a filmé en train de taguer : l'admin du site/service).
[^] # Re: Mainteneurs
Posté par Clément V . En réponse au lien Trouver facilement un téléphone compatible avec LineageOS. Évalué à 4.
Il faut comparer ça à la version d'Android pour le même matériel qui a sûrement 0 mainteneurs.
[^] # Re: Fichier mp3 bien « taggé » mais toujours galère à récupérer
Posté par Clément V . En réponse au lien [Matinale France Culture] Pourquoi les logiciels libres intéressent-ils les Etats ?. Évalué à 1.
Je m'étais fait un script greasemonkey mais il a cassé. Je l'ai réparé, c'est un peu moche, mais ça marche au moins (pour l'instant) :
[^] # Re: Moui
Posté par Clément V . En réponse au journal Toujours plus proche du Python avec C++. Évalué à 2.
J'imagine que reference_wrapper doit passer.
[^] # Re: Littéraux non-standard
Posté par Clément V . En réponse au journal Toujours plus proche du Python avec C++. Évalué à 4.
J'ai tenté un bricolage en C++20 : https://gcc.godbolt.org/z/MxExbc
Ça semble possible avec la nouvelle syntaxe mais je ne garantie pas le qualité de ce que j'ai écrit. Ça marche avec GCC et clang, mais MSVC ne semble pas encore supporter la nouvelle syntaxe. Donc en pratique, pour l'instant, c'est pas mieux que l'extension GNU mais ça pourrait être le futur.
# Littéraux non-standard
Posté par Clément V . En réponse au journal Toujours plus proche du Python avec C++. Évalué à 2.
Il me semble que la syntaxe des littéraux que tu utilises pour
_kw
est une extension GNU et pas du C++14 standard.Je me souviens avoir essayé de créer des littéraux du même genre (chaîne dans un type) et de ne rien avoir trouvé de pratique et standard. Peut-être que C++20 améliore ça, je ne connais pas encore très bien.
# LanguageClient
Posté par Clément V . En réponse au journal Transformer vim en IDE avec LSP et DAP. Évalué à 6.
J'ai pas essayé coc, ça a l'air un peu trop gros pour moi. Pour pouvoir utiliser LSP, j'ai installé LanguageClient-neovim. Il y a juste à lui dire quel serveur utiliser pour chaque langage, pas besoin d'installer nodejs.
[^] # Re: Solution technique à un problème économique
Posté par Clément V . En réponse au journal Gemini et Solid, deux alternatives au Web (qu'il faut qu'on m'explique). Évalué à 3.
SGML est une syntaxe trop horrible, l'XHTML2 c'était bien.
[^] # Re: Config
Posté par Clément V . En réponse à la dépêche Sortie de TIC‑80 version 0.80 . Évalué à 2.
On est quand même sur du dessin très simple : rotations à 90 degrés et étirements par des facteurs entiers pour les opérations les plus complexes. On a surtout besoin de copier des pixels un peu partout, un CPU n'est pas si mauvais pour ça.
Et OpenGL, c'est aussi du temps CPU pour envoyer les données et commandes à chaque image. Et sur un eeepc avec une implémentation logiciel d'OpenGL, on doit se retrouver avec un surcoût énorme comparé à un rendu logiciel naïf qu'on aurait pu écrire soi-même.
Des machines avec des processeurs très très faibles mais compensés par des GPU spécialisés dans le dessin de sprites. J'aurais plutôt comparé aux vieux jeux DOS qui faisaient mieux que le TIC-80 mais sans accélération matérielle.
[^] # Re: Config
Posté par Clément V . En réponse à la dépêche Sortie de TIC‑80 version 0.80 . Évalué à 2.
Vu le type de dessin, ça devrait être possible de faire ce genre de rendu en logiciel sur n'importe quel processeur du 21ème siècle, non ?
À une époque j'ai pas mal programmé sur TI-89 (Motorola 68k à 12MHz, 256Ko de RAM), il n'y avait pas d'accélération matériel graphique mais ça ne posait pas trop de problèmes pour faire des jeux 2D simples. Ce n'était que du monochrome mais avec la différence de puissance des processeurs on devrait quand même pouvoir passer à 16 couleurs.
[^] # Re: PICO-8 vs TIC-80
Posté par Clément V . En réponse à la dépêche Construisez et programmez votre console de jeux open source. Évalué à 2.
Il est bizarre ce logiciel libre : je n'ai pas trouvé de lien vers le code source sur le site. La seule version Linux est un paquet Debian, j'ai donc besoin de compiler pour ma distribution exotique (fedora). On trouve bien des liens vers github pour les bugs ou le wiki, mais rien vers le code lui-même.
Donc je mets le lien vers la page github pour ceux que ça intéresse : https://github.com/nesbox/TIC-80
[^] # Re: Croyances
Posté par Clément V . En réponse au lien Falsehoods Programmers Believe About Names – With Examples. Évalué à 3.
J'ai l'impression que c'est le pronom relatif implicite qui te dérange : « Falsehoods (that) programmers believe about names » → « Erreurs auxquels les programmeurs croient au sujet des noms »
[^] # Re: Dommage que ce ne soit pas pour DNF
Posté par Clément V . En réponse au lien yum history. Évalué à 3.
Il y a des chances que yum ne soit qu'un alias de dnf et que donc tu utilisais déjà dnf sans le savoir. Sur Fedora 32 en tout cas :
# uBlock Origin bloque les trackers déguisés
Posté par Clément V . En réponse au lien Le déguisement des trackers par Cname. Évalué à 2.
Je ne connaissais pas la technique mais je suis rassuré : uBlock Origin a déjà une solution contre celle-ci (https://github.com/gorhill/uBlock/releases/tag/1.25.0).
[^] # Re: Firefox a eu sa chance par le public
Posté par Clément V . En réponse au journal Hégémonie et navigateurs. Évalué à 1.
Sync n'est toujours pas complet, il manque les moteurs de recherche : https://bugzilla.mozilla.org/show_bug.cgi?id=444284 12 ans que ça dure !
[^] # Re: Typage structurel
Posté par Clément V . En réponse au journal C++ Hell/Heaven et les concepts. Évalué à 3.
Pour compléter les autres réponses, il y a un mécanicisme un peu plus complexe mais plus puissant (et qui est celui utilisé dans le journal). Il se base sur une règle du C++ abrégée en SFINAE (Substitution Failure Is Not An Error). L'idée est que si, lors de la substitution d'un type dans un template, on obtient une déclaration que n'a pas de sens, le compilateur ignore la fonction au lieu d'émettre une erreur. Ça ne marche que dans la déclaration (paramètres du template, type de retour, ou types des paramètres), pas dans le corps de la fonction.
Ce qui donne :
J'ai un type imbriqué A
J'ai un type imbriqué B
Pas d'erreurs puisqu'à chaque fois exactement une des fonctions est gardée. Si un type avait à la fois une type imbriqué A et B, les deux fonctions seraient valide et le compilateur générerait une erreur comme il ne saurait pas choisir. Si un type n'a aucune des deux propriétés, les deux fonctions sont ignorées et le compilateur génère une erreur disant que f n'existe pas (mais s'il est sympa, il t'explique pourquoi il a ignoré les deux possibilités avec un message à rallonge).
Ça permet d'avoir des fonctions surchargées qui sélectionnent la bonne alternative en fonction des propriétés d'un type paramètre du template. Évidemment, si la condition que tu veux avoir n'est pas un type que tu utilises en retour ou en paramètre, ça devient plus compliqué mais beaucoup de choses sont possibles. Les concepts de C++20 simplifient largement tout ça.
Pour aider à l'utilisation avancée du SFINAE pré-C++20, il y avait quelques aides comme enable_if et une TS proposait d'ajouter des détecteurs (mais c'est sûrement devenu obsolète avec les concepts).