Présentation

OniDev est un framework en cours de développement, spécialisé dans la création de jeux (2d pour l'instant). Il possède une interface proche de celle de GameMaker dans l'idée ou tous les outils nécessaires a la création d'un jeu seront disponibles dans le même logiciel.

Le but est de proposer un game engine avec un langage intégré plus efficace que la plupart des langages présents dans les logiciels comme GameMaker, ou encore Construct (qui permet d'utiliser du javascript)...


Spécificités du langage

Features
-Syntaxe familière avec les langages C++, C#, Java...
-Fortement typé pour une compilation efficace et une meilleur détection des erreurs
-Orienté objet
-Sans Garbage Collector mais avec des 'pointeurs intelligents', qui permettent de ne pas se soucier de la mémoire, sans perdre les perfs du GC quand utilisés correctement
-Ou les objets peuvent être allouées en dynamique ou statique (contrairement a java ou haxe par exemple, qui obligent a faire des allocations dynamiques) pour gagner considérablement en performances dans certains cas, mais aussi pouvoir plus facilement connaitre la durée de vie des variables (cela permet d'appliquer le RAII efficacement)
-Avec de la meta-programmation pour éviter de réécrire inutilement du code réutilisable

Engine
-Compilable
-Transcodable en C++ pour permettre la réutilisation du code dans de gros projets C++
-Devrait être interpretable a terme
-Utilise la bibliothèque C++ OniDev Library comme bibliothèque standard


Ports prévus

-Windows, linux et mac dans un premier temps, pour les exports (nécessite de recompiler sur l'os concerné, ou de générer le jeu en mode interprété)
-Android, et peut être Ios
-PS3 et XBox One si Planet Centauri est porté sur ces consoles (nécessitera un port du moteur d'OniDev quoi qu'il arrive)

ok

rasengan, si tu n'a que ça à dire face à cette merveille tu peut tout de suite sortir.

sinon... year! je teste tout de suite!

youpi j'ai réussi a me faire remarquer

sinon bon travail !

Ça l'air d'avoir de la gueule, c'est cool. Je télécharge, et je testerai si je n'ai rien d'autre à faire x)

J'aime bien le coup des masques, c'est pratique de pouvoir les différencier du reste. Pas contre, il n'y a pas de catégories pour les sons du tout ? Parce que bon, ça reste un des éléments principaux dans la constitution d'un jeu vidéo.

Aussi, une petite question : quel est le compilateur utilisé ? Est-ce-qu'il supporte le C++0x ou bien il ne supporte que le classique C++98 ? Parce que bon, les ajouts du C++0x sont quand même bien pratiques pour gagner du temps dans l'écriture^^

Alors pour les sons, j'ai encore rien fait vu que je m'en occuperais plus tard et que c'est pas prioritaire.
De toute façon rien n’empêcheras l'utilisateur d'utiliser une librairie externe.

Pour le compilo, malheureusement j'utilise un vieux MinGW, le 3.4 je crois.
La raison ? Bah y a un bug qui fait que quand je change de compilo impossible
de lancer la compilation, aucune erreur, rien, juste g++ qui réagis pas oO
Fin bref un truc bizarre, que je réglerais une fois terminé. Je pense faire un
système pour pouvoir facilement changer de compilateur (a la code::blocks).

M'enfin bon la mes priorités sont la gestions des objets/room. La base même du système.
Sinon tant qu'a faire du C++ ailleurs avec la lib que je fournis avec, ce qui peut être cool aussi.

Bon, juste pour vous dire de profiter que la version est en alpha, et donc que je peut changer pleins de trucs.

Par exemples les noms des fonctions.
Voila la liste des fonctions que j'ai actuellement finies. Donc si vous pensez a des noms plus courts et simples dites le moi et je ferais le ménage.
Bon bien sur les fonctions comme setSynchronization n'ont pas besoin d'être changées vu qu'on les appelle qu'une fois durant le jeux.
Mais une fonction qu'on appelle plein de fois est mieux en version plus courte, je pense notamment a keyboardCheckPressed qui serais plus pratique
en keyPressed comme me l'a fait remarqué lolman :p

Spoiler:

MinGW ? Je crois que le compilateur par défaut de la suite est GCC, donc il ne devrait pas y avoir de problèmes. Si c'est le cas, le C++0x est également utilisable, ça fait d'une pierre deux coups (par contre, je ne sais pas quelle version de GCC est utilisée, probablement entre 4.3 et 4.5).

Les noms des fonctions ne sont pas choquants, je trouve, ils veulent bien dire ce qu'ils veulent dire. Après, je n'aime pas trop la syntaxe varEnPlusieursMots, je lui préfère celle var_en_plusieurs_mots. Mais bon, ça reste de la préférence, donc rien de grave^^

Aussi, juste en supposition, si tu fais des classes/structures de bases, je te conseille de mettre déjà la classe/Structure Point et de faire quelques méthodes qui marchent avec. Ça aura l'avantage de filer de base pas mal de trucs utiles (Au pire, j'ai déjà développé pas mal de fonctions C/C++ pour gérer la géométrie dans le plan et l'espace si ça t'intéresse : intersections, projetés, etc...).

Ah si tiens, pour les noms de fonctions, je pense que colorGetRed, colorGetBlue et colorGetGreen pourraient être abrégées à getRed, getBlue et getGreen ; en toute logique, il ne sert à rien de préciser que c'est des composantes d'une couleur, je pense que c'est en soi déjà implicite^^

Wep pas con pour les couleurs.
Sinon pour le coup des fonction_en_plusieurs_mots j'ai choisis la syntaxe avec des majuscules étant donnée que c'est la
syntaxe la plus utilisée :p (pis c'est plus rapide a écrire). M'enfin bon après rien n’empêche de faire une liste de define et de les ajouter dans les options de compilation lawl.

Pour C++0x il est pas encore complètement supporté par mingw 4.5, donc pour la 3.4 c'est mort :p
De toute façon, je sais pas si tu connais bien code::blocks mais je vais grandement m'en inspirer pour pas mal de menus d'options, donc
y auras pas de soucis.
Le but actuellement c'est juste de faire une application GM Like suffisamment complète pour y développer un jeu.
D'ailleurs je serais le premier a la tester complètement vu que je compte y dev un rpg, un bon moyen de voir si le systeme est solide, oupa.


Aussi si y en a qui ont des idées n'hésitez pas les poster. Je la mettrai dans la boite a idées :p

Perso, je pense qu'il vaut mieux garder des noms longs : on sait plus facilement ce que c'est, et si on en utilise vraiment une très souvent... ben on la réécrit en vitesse, hein

Ben entre keyboardCheckPressed et keyPressed on perd pas vraiment le sens.
Pareil pour getRed, tu l'utilise pas au hasard.
Mais je suis d'accord, faut pas que ça rende le code illisible.

De toute façon je ferais en sorte que la doc soit la plus simple et pratique d'utilisation.
En gros y auras pas de soucis pour trouver une quelconque fonction. Mais faut raccourcir ce qui peut l'être.

Pis le logiciel auras tellement rien a voir avec GM a part la 'logique' dans le fonctionnement, que de nouveaux noms de fonctions
n'effrayerons pas plus que ça lol.

salut bon tu connais mon niveau en prog!

téléchargement,décompression,exécution impeccable
présentation claire comme gm c'est nickel
exécution du test.od0 écran noir avec un pixel blanc suivant la souris mais plus bas et à droite!

requête: en français svp
des "objets" tout prêt paramétrable comme les icônes gm pour affichage,gestion ,clavier
sons ..je sais que tu déteste mais pense aux moins (doué,courageux,qui n'ont pas
le temps de s'investir dans l'apprentissage c++,..)

bonne continuation!

:p
Merci :p
Pour l'exemple c'est exactement ce qu'il est sensé faire, donc content que ça fonctionne

Sinon t'en fait pas je réfléchi aussi a un système de codage analogique, bon pas comme le drag & drop mais en
aussi simple, plus joli, et plus efficace.
Le truc c'est que je l'implémenterais une fois tout terminé, donc va falloir être patient, ou ce mettre au C++


Au fait, vous le trouvez comment le logo ?

cool me fait penser à starcraft 2!

Cool ! C'est vachement propre et tout. Ca fait très professionnel, et la présentation y a rien à redire.

Super.

J'ai toujours rêvé d'un GM-like en C++

Tu utilise quoi comme Bibliothèques?

La onilib

C-a-d rien, mis a part opengl et les trucs de la bibliohtèque standard.
Aussi j'utilise des bouts de codes modifiés de stbi, pour charger les png et les jpg.
Je me suis aussi inspirés de quelques trucs de SDL et SFML pour le fenêtrage (pour trouver certains trucs que je connaissais pas).
Bref sinon tout est custom :p

&Merci pour les compliments plus haut

Ah j'oubliais, je vois que tu n'as pas encore refait les fonctions gérant les fichiers INI. Comme tu le sais déjà, je les ai toutes refaites en C récemment, donc si jamais t'as la flemme de les faire, je peut toutes te les filer ; elles gèrent plusieurs styles d'attributions de valeurs aux clef (le ':' ou le '='), et gèrent également les commentaires

À part si tu préfères que tout soit entièrement custom (ce qui ne m'étonnerait pas =p).


EDIT : Oui, j'oubliais, bien sûr que je connais code::blocks, le meilleur IDE que je connaisse pour le moment. Il est vraiment chouette et très complet. Y'a juste la page "Start here" réapparaissant tout le temps qui me donne parfois envie de tout arrêter

Lol. Pour les ini je compte faire un truc un peu différents de ceux dont on a l'habitude, mais bon pareil c'est pas la priorité.

En fait tant que mon éditeur de tiles/cartes/objets est pas opérationnel on va dire qu'il y a pas grand chose a faire.
C'est pour ça d'ailleurs quand j'avais fait le thread : Le game maker idéal.
Le but est de faire tout comme il faut, et ça je sent que ça va être chaud x)


Entk si tu fait une lib documenté compatible MinGW3.4, je pourrais l'ajouter au composants si tu veux :p

Oh purée, ça gère du cube ça !

Bon chez moi ça marche, sinon qui serait pas c'est qu'il puisse convertir des gmk
Juste une petite questions comme ça, ça se passera comment pour assigné un sprite à un objet ? Il se charge automatiquement ? Est-ce qu'il faudra modifier le main pour la création de chaque objet, ou ils modifiera tout seul ?

Ça ce passeras comme GM en fait.
Les objects permettrons de coder haut niveau, les headers et sources bas niveau.
Fin bref 2 en un.
Sinon pour les gmk sur que ce serais bien :p Mais vu comme la structure est différente pas sur que ce soit possible,
sauf si j'ajoute des contraintes de compatibilités.

Bon aujourd'hui je m'attaque aux objects.
Souhaitez moi bonne chance lol.

Bonne chance, sinon tu veux dire que ça sera plus lent avec les objets ?

Gné ? Non haut niveau c'est plus simple a programmer :p
Quand j'aurais totalement optimisé le système d'objet il devrais pouvoir gérer bien plus d'instances que dans GM t'inquiète
Mais les optis je les ferais a la fin, donc la faut ce dire que le système seras pas au max.

Awé et juste pour dire qu'hier soir Qual a fait une page pour le fun, en 1h \o/
http://brainwizz.fr/ftp/oni/onidev/

Donc plus de mediafire, et je mettrait certainement les niouz la bas :p

Bon, j'ai testé un peu quand même. Pour le moment, c'est très bien, mais je vais quand même soulever quelques petits problèmes :

• Dès que je ferme un source, il me demande si je veux ou non enregistrer les modifications, même si aucune n'a été effectuée.
  
• Les fenêtres qui s'ouvrent à droite de l'écran ont tendance à dépasser.
  
• Ah oui, ce serait sympa de sauvegarder leur position à l'écran aussi.
  
• Faudrait pouvoir renommer/supprimer/autres les fichiers depuis le logiciel (enfin, c'est prévu, je pense).
  
• Niveau coloration syntaxique, j'aurais mis une couleur plus visible pour les opérateurs.
  
• Toujours niveau coloration syntaxique, ce serait cool d'utiliser une couleur différente pour les caractères spéciaux dans les chaînes de caractère.
  
• De la même manière, avoir une couleur spéciale pour les nombres (même héxadécimaux), ça serait cool aussi.
  
• Proposer de désindenter lors de la fermeture d'une accolade ?
  

La plupart des trucs ne sont que des idées en vrac, surtout pour la coloration d'ailleurs, mais bon, je sais que tu te concentres d'abord sur d'autres trucs avant de passer aux détails.

C'est tout pour le moment. Sinon, j'ai l'impression en l'utilisant d'avoir un mélange entre code::blocks, Game Maker, et la SFML. Ça m'a l'air d'être très très agréable à utiliser en tout cas, encore bravo

Et bon courage pour la suite !

Merci :p
Pour la plupart des trucs que tu propose je comptait les faire. Mais bon toujours les priorités avant :p
(pis tu t'imagine pas a quel point c'est ****** de mettre une coloration syntaxique lol, surtout que c'est fait 'a la main')

Sinon le coup GM+SFML+Code::blocks c'est exactement ce que je veux faire. Ça va pas être simple mais c'est possible.
De toute façon si le projet arrive a un stade suffisamment avancé, je compte peut être créer une petite communauté pour continuer son
développement a plusieurs, ce qui aurais comme conséquence une évolution énormément plus rapide.

Eh bah t'as bien raison^^

Ah, tant que j'y pense, un truc tout con à faire mais qui est bien sympathique quand même : le fameux raccourci clavier (F11 sous Code::blocks) qui permet d'ouvrir un header ou un source correspondant au fichier actuellement ouvert.

Si jamais le logiciel avance assez pour arriver à ce que tu veux faire, je pense que je changerai de logiciel pour développer mes projets, personnellement =D

Ah pas bête le coup de F11, je met dans la todo liste des utilisateurs :p
En tout cas ça me ferais vraiment plaisir que ce programme devienne suffisamment intéressant pour être une alternative a code::blocks ou GM :p
M'enfin pour ça faut que j’arrête de parler et que je bosse lawl.

J'ai l'impression que tu t'est laissé la possibilité de le faire portable.
A cause du :

Code:

#if defined(_WIN32) || defined(__WIN32__)
    #include "win32/implWin32.h"
    typedef ImplWin32 ImplWindow;
#endif

et du fichier implWin32.h.

Vrai?


edit:

Sinon, le truc primordiale dans l'éditeur de code pour moi, c'est comme dans GM, un afficheur de liste de fonction qui commence comme on est en train de l'écrire.
Du genre:
draw_ -> (draw_sprite(arg,arg,arg,arg),draw_point(),...)