devnewton 🍺 a écrit 8379 commentaires

http://www.boost.org/doc/libs/1_56_0/libs/numeric/ublas/doc/vector_sparse.htm

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Tu as mis les sources quelque-part?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Oui! Je cherche une idée de "store" qui minimise l'occupation mémoire pour comparer!

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Merci!

C'est intéressant, je me demande comment détecter les cas complètement contre-intuitif comme celui de la page 30.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

A l'oeil nu, c'est invisible, surtout que je limite les fps à 60.

Par contre dans la console, le boost::timer::auto_cpu_timer écrit des infos qui ne prenne pas en compte certaines opérations de la SDL (le swap de buffer par exemple).

On pourrait de la même façon mesurer chaque système indépendamment pour avoir une analyse plus précise, mais un bon profileur doit savoir le faire tout seul comme un grand.

Plus qu'à trouver un bon profileur!

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

comment les stocker efficacement, sachant que toutes les entités n'ont pas nécessairement tous les composants

Ca dépends quelle efficacité tu recherches. C'est un problème de space versus time versus flexibility. Dans les deux layouts que je présente, on sacrifie l'espace: chaque entité créé provoque une allocation égale à la taille de tous les composants.

Si tu as des idées d'autres layouts, je cherche de l'inspiration!

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

C'est ça!

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

L'entité est simplement un nombre, nombre qui sert de clef dans un conteneur à composants, pour retrouver les composants.

C'est le cas!

typedef std::size_t entity;


Pour moi, le layout mémoire idéal d'un système à entité consiste à regrouper par composant.

C'est implémenté par le store struct_of_array.

template< typename Component, typename... Components >
class store_base< Component, Components... > : private store_base< Components... > {
(...)
typedef std::vector<boost::optional<Component>> component_vector;
(...)
component_vector components_;
> Le conteneur peut être une hashmap ou un arbre.

Ici c'est un simple vecteur pour être plus sympa avec le cache!

(Désolé pour le formattage, le parseur markdown de linuxfr a l'air cassé).

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

J'arrive à lire le doc avec Libreoffice!

Sinon c'est une mairie, pas une boite qui court après les clients, elle peut parfaitement dire merde à quelqu'un qui lui envoie un doc.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Tu devrais résumer ta présentation à trois slides (au moins ça tiendra dans Impress):

1. On garde MS Office: ça coûte 12k€, il va falloir oublier [demande chiante du métier].
2. On passe à Libre Office: 0€, on va pouvoir utiliser l'argent économisé pour [demande chiante du métier].
3. A vous de choisir!

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Ce n'est pas la même chose. Avec le temps CPU, un vilain processus va juste ralentir ses petits copains et il peut être calmé par le kernel.

Avec les ressources GPU, si tu abuses des textures/shaders/buffers, plus personne ne peut rien afficher.

Si tu veux en être convaincu, lance quelques jeux 3D et enchaînent les alt-tabs.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Ce qui fait peur dans ce schéma c'est de voir que tout le monde, de l'éditeur de texte au modeleur 3D en passant par le widget de notification, va utiliser OpenGL, une API absolument pensé pour être utilisé par de nombreuses applications en même temps: tout le monde a accès à l'intégralité des ressources du GPU, par définition limitées…

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

compatibilité cassée par rapport à la 1.5.0

C'est triste de casser la compatibilité avec un changement de version mineure.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

au passage merci sarko

On oublie trop souvent sa surcompétence dans tous les domaines!

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

La présentation donne envie, mais je ne vois ni démo, ni capture d'écran.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Ca me semble un peu gros pour ma poche.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Est-ce qu'il y a des brevets par exemple?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Et le cas simple de 99% des gens

Ajoutons que dans le monde java, l'un des effets bénéfiques de maven a été de faire des builds particuliers de vilains petits canards qu'on évite comme la grippe aviaire.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Et on voit bien avec Maven que le déclaratif c'est bien sur le papier mais dans le vrai monde on fabrique des plugins en java pour pouvoir passer outre et avoir les comportements attendu

Et on configure ses plugins avec du déclaratif. Le système est bien fait.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions
ok, c'est pas en standard, mais bon, ça fait bien ce que tu demandes, avec encore moins d'infos "inutiles" que ton xml.

C'est bien ça le problème: rien n'est standard.

Avant de démarrer un projet, il faut choisir des conventions, une organisation, utiliser des scripts compliqués…

Vu qu'il faut gérer les dépendances à la main, il faut se taper non seulement sa propre organisation, mais aussi celles de toutes les libs dont on dépends.

Ne doit pas être infaisable.

Oui tout est faisable, mais on perds un temps infini sur des tâches que les autres langages (java, go, python, ruby…) ont standardisées et automatisées.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Et si l'outil propose de bonnes options par défaut pour 99% des projets (les sources dans src, les options Wall & co…), on pourrait réduire à:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://supercmake.lol/project/2.9">
    <name>pluma</name>
    <type>library</type>
</project>

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Que proposes-tu? Parce que un Makefile et des scripts, c'est pas spécialement plus lisible et modifiable par un humain…

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Disons que le gameplay est très casual pour l'instant!

J'ai voulu me faire un "hello devnewton" pour tester la SDL2. Je vais sans doute faire un autre essai avec http://www.polycode.org/

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Lapin compris :-(

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Nommons en particulier SFML, le couteau suisse de l'interaction avec le matériel (vidéo, audio, contrôleurs), et OpenSceneGraph, qui est un graphe de scène basé sur OpenGL, et dont les capacités sont remarquables.

On a pas mal débattu de la SFML ici et sur #jeuxlibres. Rewind l'utilise pour Akagoria et en est très content. Je suis plus sceptique et je pense que je vais partir sur cette bonne vieille SDL. En fait mon point de vue n'a pas beaucoup changé depuis ce journal :-)

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.