Nass0931 a écrit:

Ce qui est drôle c'est le fait de voir que même si tout le monde ne parle pas, on voit qu'il y a quand même au moins 10 personnes activent sur ce sujet, et qui suivent et lisent les avancements (d'où les 13 ups) !

En effet, et ça fait même assez plaisir 

Maeiky a écrit:

Comme promis, et pour ceux que ça intéresse, voir: CWC

En espérant que ça fonctionne de votre coté

Fonctionne sans le moindre problème de mon côté, ça a l'air intéressant et même si je ne compte pas m'en servir dans l'immédiat, ça semble prometteur.

Au fait.

Je voudrais effectuer un petit sondage, je pense qu'un frein dans l'utilisation du moteur (mis à part le fait qu'il n'ait pas de version stable) est le besoin de le compiler, et je pensais donc commencer à distribuer des binaires précompilés pour Windows (pour Visual Studio 2015 et MinGW, en 32 et 64 bits), et dans la foulée commencer à le versionner.

Je voudrais donc savoir si ça vous intéresse, de façon plus large: est-ce que des précompilés du moteur vous inciteraient à l'utiliser ? Mettez un +1 sur le message si oui, ça me permettra de mesurer l'impact d'une telle décision (désolé pour le côté putalike de ce message !).

Merci à vous !

Hello !

Aujourd’hui sort la première version du moteur, j’ai nommé la version 0.1.0, disponible avec des précompilés pour Windows !

Cette première version va apporter quelques bénéfiques changement par rapport au cycle de développement:

• Tout d’abord la mise à disposition de précompilés, vous avez été nombreux à montrer que cela vous intéresserait, et c’est maintenant chose faite.
• Ensuite de véritables changelog, dernièrement je n’ai fait que poster toutes les deux à trois semaines la liste des changements intéressants, en passant des changements mineurs du point de vue de l’utilisateur mais parfois essentiel du point de vue du développeur (un changement d’interface par exemple).
• La mise à disposition de nightlies: depuis peu le moteur dispose d’intégrations continue via AppVeyor et Travis CI, ces deux services compilent le moteur à chaque push, exécute(ront) les tests unitaires et mettent les binaires compilés à disposition pour le téléchargement.
• Dernier changement et le plus important: le moteur va enfin être utilisé par quelques-un d’entre vous (du moins j’espère ).

Quelques questions éventuelles que vous pouvez vous poser (et leurs réponses):

1. Pourquoi une version 0.1 et pas 1.0 ?
   Parce que malgré toutes ces années de développement, le moteur ne répond pas encore à mes critères pour une version stable, qui sont que chaque système majeur fonctionne et ait été testé par suffisamment d’entre-vous.
   De plus, n’étant pas encore certain du système que je vais adopter pour les versions, je préfère tester avec une version beta.
2. Quel système pour les versions ?
   Le système bien courant major.minor.patch va être utilisé, où major représente le numéro de version majeur, qui ne change qu’en cas de gros changement cassant complètement la compatibilité de l’API.
   Le numéro de version mineur pourra changer pour deux raisons, en cas d’ajout de fonctionnalité suffisamment importante ou en cas de changement d’API existant (en faisant en sorte de respecter la compatibilité le plus possible).
   Quant au numéro de patch, il augmentera avec chaque modification mineure (le plus souvent des corrections de bug ou l’ajout de fonctionnalités mineures), il est remis à zéro en cas de changement de version mineure.
   Un système bien classique en somme
3. Des paquets prévus pour Linux ?
   J’adorerai en faire, mais je ne suis pas certain que ça soit une excellente idée pour l’instant, le moteur risquant de voir de nombreuses corrections arriver prochainement. N’hésitez pas à me faire remarquer si je me trompe.

Voici maintenant le dernier changelog à l’ancienne, dont les changements font partie de la version 0.1:

• Le moteur propose maintenant l’allocation sur la pile (alloca). : Très utile lorsque vous avez un espace de taille relativement faible mais connu seulement à l’exécution, je ne recommande cependant pas son utilisation dans la vie de tous les jours (alloca étant connu pour être désastreux lorsque mal utilisé, et le site StackOverflow n’a pas ce nom pour rien ), si alloca n’est pas supporté alors une allocation sur le tas est employée.
• Les tilesmap supportent maintenant les maps isométriques - L’affichage de maps isométriques est une feature demandée par un utilisateur, pouvant donner des résultats intéressants. Exemple de ce que ça peut afficher.
• La classe SocketPoller a été ajoutée, cette classe était assez attendue côté réseau, elle vous permet par exemple de faire attendre un serveur sur plusieurs sockets en attendant que des données soient reçues, de plus je l’ai implémenté avec WSAPoll sous Windows (si l’option NT6 est active, ce qui casse la compatibilité avec Windows XP, select sinon), epoll() sous Linux et poll() sous les autres, ce qui autorise de très bonnes performances sans limitation du nombre de sockets attendues (un des gros problème de l’implémentation traditionnelle).
• Les tests unitaires ont été corrigés, ils devraient fonctionner correctement maintenant (je vais en faire une version serveur pour qu’AppVeyor et Travis CI les exécute en fin de build).
• Le loader OBJ ne va plus perdre son temps à essayer de décoder des fichiers sans aucun token obj, jusqu’ici lorsque le loader OBJ était confronté à un flux, il tentait de décoder le fichier OBJ en émettant une erreur à chaque ligne qu’il ne pouvait pas décoder (jusqu’à arrêter le chargement si le taux d’erreur est trop élevé). Ce comportement est corrigé, le loader va maintenant essayer de trouver au moins une directive OBJ dans les vingt premières lignes n’étant pas des commentaires avant d’abandonner silencieusement.
• Le premake propose maintenant une option de packaging, vous permettant de compiler le moteur vous-même, d’exécuter l’action et d’obtenir un dossier package/ avec tous les fichiers intéressants placés aux bons endroits, très utile pour générer les nightlies ou compiler des précompilés à redistribuer aux autres
• J’ai recompilé Newton avec le flag /MT, un problème rencontré par les utilisateurs de MinGW était que Nazara nécessitait quand même le runtime de Visual Studio à cause de cette dépendance.

Toutes mes autres contributions concernent la mise en place de Travis CI, et AppVeyor.

Quelques liens utiles:

• Le wiki, plusieurs utilisateurs du moteur ont créé des pages pouvant vous aider avec la suite du tutoriel que j’ai commencé à écrire
• La documentation, presque complète et suffisante pour les nouveaux utilisateurs, que demander de plus ?
• Groupe #42, il s’agit d’un Mattermost, un genre de chat en temps réel qui, bien qu’il ne soit pas dédié entièrement à Nazara (il y a un canal pour ça), peut vous être très utile, j’y suis très souvent et je peux vous donner un coup de main (que votre problème soit sur Nazara ou sur du C++ en général).

Et pour finir:

Nazara Engine - Release 0.1.0

Toutes ces années...

Et dire que l'aventure ne fait que commencer... :'D !