La communauté Orx est heureuse d'annoncer la version 1.13. Il s'agit de la 13e version majeure annuelle depuis la version 1.0 en 2009. Il y a une quantité substantielle de changements dans cette version dont en voici une selection:
- Plus de 70 mises à jour ou nouvelles fonctionnalités
- Ajout d'un nouveau plugin SoundSystem basé sur MiniAudio : toutes les plates-formes prennent désormais en charge le chargement de fichiers OGG, WAV et MP3 ainsi que l'écriture de fichiers WAV
- Prise en charge de : filtres basés sur la configuration pour les sons et les bus, plusieurs auditeurs de son, panoramique sonore (y compris les commandes), spatialisation du son...
- Prise en charge du format d'image QOI pour tous les plugins/plates-formes
- Prise en charge des textures/icônes/curseurs compressés pour les versions de bureau utilisant Basis Universal (UASTC -> ASTC/BC7)
- Ajout d'orxMod (ProTracker MOD) basé sur la bibliothèque pocketmod, qui ajoute le support MOD piloté par la configuration aux objets
- Ajout de l'extension init orxMovie (MPEG1/MP2), basée sur la bibliothèque PL_MPEG
- Les générateurs avec UseSelfAsParent détacheront désormais les objets générés lors de la suppression
- Prise en charge native d'arm64 pour MacOS 11/XCode 12.x
- Prise en charge de VS2022 et prise en charge retirée de VS2015
La liste complète des changements est ici : https://github.com/orx/orx/blob/master/CHANGELOG .
Vous pouvez télécharger la version 1.13 ici : https://github.com/orx/orx/releases/tag/1.13 . La version de développement à jour se trouve à : https://github.com/orx/orx
Pour en savoir plus, rendez-vous sur le site Web d'Orx http://orx-project.org/ ou discutez avec la communauté (en Anglais, meme si le Dev du moteur est Francais) sur Discord: https://orx-project.org/discord.
Merci.
'lut,
Toujours sympa ce genre d'initiatives, mais deux questions me titillent :
1- Quelles spécificités apportent ce moteur par rapport aux propositions déjà existantes ? (comme p.ex. Godot, également open-source)
2- Qu'entends-tu par moteur "2,5D" ?
Hello Nival
Je ne suis pas l'auteur de ce moteur mais nous l'utilisons depuis plusieurs années pour faire nos jeux ou game jams, mais je vais essayer de répondre a tes questions.
- Quelles spécificités apportent ce moteur par rapport aux propositions déjà existantes ? (comme p.ex. Godot, également open-source
Goddot est Open source sous une license différente je crois, mais est un moteur de jeu 3D a interface de conception graphique (comme Unity ou Unreal). C'est a dire que son interface principale va être avec un Gui et sa partie code et scripte ne va apparaitre aux utilisateurs lambda que comme une couche pas forcement utilisé.
Orx est un moteur a base de C (comparer a C++) qui ne permet aujourd'hui que de faire des jeux 2d (comme Love2D par example). Il a l'avantage d'etre optimiser pour ca, et se targue simplement d'etre le plus rapide et le plus petit et optimise des moteurs 2D actuels. un example, il peut avoir jusqu'a 16 millions d'objets en memoire... déjà c'est pas commun, mais surtout, met 1 millions d'objets en memoire dans ton n'importe quel moteur actuel, et quitte le jeu, et regarde combien de temps le jeu et ton OS va mettre de temps pour te rendre cette memoire de dispo (indice, ca va se compter en dizaine de secondes voir minutes, Orx, c'est immédiat ou quelques secondes aux Max). et ce n'est qu'un example parmi tant d'autre. Il est spécialisé, DONC bcp plus efficace que des engines généraux.
Il a une approche data-driven, qui lui permet d'ecrire ses mécanique grace a du scrip (.ini) qui te permet de changer ton code ou assets en temps reel sans rebuilder le jeu par example. le build est tellement rapide que ca changerais pas grand chose de toute façon, mais meme, la, un utilisateur non codeur dans le groupe peut modifier et tester son script, ses mécanique ou ses effets ou graphisme en temps reel.
Ce moteur fort peu connu ne recherche pas a attirer des utilisateurs casuals, Goodot, Unity, Unreal le font fort bien et bien mieux. ce sont des merveilleux outils pour s'initier a la creation de JV, ou faire des JV Pro de haut niveau.
Orx lui va peut être attirer des devs de jeux 2D plus pro. qui veulent sur plusieurs années un moteur spécialisé dans ce type de produit, ou des professeurs et étudiants par example.
2- Qu'entends-tu par moteur "2,5D" ?
Le moteur affiche ses sprites grace au mapping de texture sur des triangles, et a donc 3 axes d'affichage, profondeur incluse. c'est donc un moteur 2.5D. Un moteur 2D afficherait ses sprites directement.
Il est fort possible pour un utilisateur de decider de porter Orx du coup pour un renderer 3D si ca lui chante (ca demandeais du boulot et il faudrait y comprendre l'interet (encore une fois, U+U+G font ca merveilleusement bien), MAIS c'est techniquement possible)
Ok, eh bien, merci pour ces réponses très claires !!
Je ne connaissais pas du tout et en tout cas ces caractéristiques peuvent le rendre tout particulièrement adapté pour certains types de projets. Après je suppose / crains que son aspect purement code / sans interface graphique limite fortement son public (d'autant que les dévs très à l'aise avec le fait de coder ont tendance j'ai l'impression à finalement coder eux-mêmes leurs propres moteurs, du moins sur des jeux graphiquement pas super ambitieux ce que semble recouper les projets que cible Orx).
Ca le "limite" en effet, mais le but n'a jamais été de concurrencer les moteurs grand public. C'est un projet perso a la base, qui est devenu un beau projet fort complet depuis toutes ses annees.
possible en effet de coder son propre moteur, mais ca ne va pas dire qu'il sera "meilleurs" que celui la et surtout, ils réinventeront la roue alors que "tout" est est déjà la. Ils pourraient partir de ce moteur et developer leurs outils propre et gagner un temps fou et se concentrer sur le jeu plus que sur le moteur.
Mais encore une fois, et ce malgré de bon tutoriaux, son cote plus proche du code n'attireras que peu comparer a d'autres moteurs plus connu et plus accessible.
N'importe quels jeux 2d est faisable, quelque soit l'ambition, il suffit juste qu'un dev ou une équipe un jour sorte un jeu qui devienne connu en fait. On verra ce que donne notre second gros jeu dessus, on espère lui apporter un peu de lumière.
Merci en tout cas pour tes questions.
Je rebondis un peu là-dessus pour signaler que ça e me parait pas si simple (l'adage "réinventer la roue" si souvent employé en programmation).
Pour quelqu'un de particulièrement à l'aise en développement, et pour peu que ses ambitions restent à sa portée, il peut être plus simple / efficace de développer soi-même qu'apprendre comment utiliser un outil tiers. Je me rappelle p.ex. que quand je faisais joujou avec le langage assembleur, j'avais trouvé beaucoup (beaucoup !) plus simple et efficace de développer mes propres petites routines de débugages que d'apprendre comment utiliser celles intégrées à l'éditeur de code que j'utilisais.
J'imagine sans mal que c'est la raison qui fait que des jeux techniquement tout à fait modestes comme Rogue Legacy, FTL ou encore Legend of Grimrock sont réalisés avec des moteurs maisons, alors que des moteurs type Unity (ou Orx pour les deux premiers) seraient parfaitement adaptés. Je ne pense pas que ce soit une coquetterie de la part des dévs, simplement que leur maitrise du code leur rend le développement direct plus simple que devoir apprendre à utiliser un logiciel spécifique avec toute sa logique propre, ses limitations, ses parts d'ombres, avec toute la lourdeur et les complications que cela peut occasionner.
Oui, c'est vrai.
Ca depend vraiment de ce qu'on fait et pourquoi et avec qui au final.
Nous, pour notre équipe, ca nous permet de nous concentrer sur le jeu plus que sur le moteur par example dont on aura ni le temps ni l'expertise de le faire "from scratch".