Si je sors un truc jouable du Metroid (du genre dans quelques jours) tu fais de même avec OniDev ?
C'est un marché équitable et dont tout le monde serait bénéficiaire...

Quant à tes (ta) View, pourquoi ne t'inspires-tu pas également de la SFML ?

Je peut essayer oui, mais elle auras pas grand chose de plus que l'ancienne visuellement étant donné que c'est surtout une refonte du code.

Pour les view je sais faire, ce qui est chaud c'est les view multiples, mais j'ai décidé de pas les mettre (suffiras de le coder sois même).

Je suis d'accord.

Quel objet possède la View ? Window, ou Room, ou est-ce indépendant ?
Est-ce possible de faire dans ce cas là deux versions : l'une avec une seule View et l'autre avec plusieurs ?

Ce seras un truc global la view, a la gm je pense.

Et le problème des view multiples, en fait c'est qu'il faut penser chaque draw pour qu'il s'affiche dans chaque view.
Sinon c'est juste que je vois pas comment faire, et j'implémenterais ça dans le futur.

Quoi qu'il en soit j'ai jamais eu besoin d'utiliser plusieurs view, donc c'est pas un truc tellement important.
Et pour le multi sur un pc c'est bidon, lan > all

+1, jamais eu besoin de plusieurs views...
De toute facon le split screen sur PC ca sert à rien

[oni]
OniCleaner est passé. Qual si tu continue a troller sur mon thread je fait peter tous tes posts
[/oni]

Je ne suis pas un gros gamer, je suis développeur et producteur avant tout. Si les éditeurs ne l'incluent pas c'est parce qu'elle ne sert pas à grand chose.

Personnellement j'attends impatiemment de voir ce que va donner le OniDev, donc je ne pense pas que cela soit indispensable de s'attarder sur des éléments peu utiles. Surtout pour une version 1.0

t'as intéret à assurer gars, tu vas finir multimillionnaire avec ton logiciel.

Zut -> Projets

Non, non, c'est bon, j'ai un titre de thread à mon nom, on fait ce que l'on veut dedans.

Donc, concernant l'éditeur de carte, si tu acceptes le python, je peux te filer un coup de main pour ça, même pour une version provisoire (un "template" pour une future version en C++). J'avais d'ailleurs commencé à en faire un, avant de tomber sur Tiled Map Editor. Et je suis passé à Qt (vu l'horreur qu'est wxPython), avec les mêmes outils que sous C (je pense à QtDesigner, bien pratique).
Et je suis en plein environnement Qt en ce moment (KDE à fond, j'ai laché totalement Gnome et gtk).
Par contre, faudra attendre la fin de la compèt', vu que j'essaye de bricoler un truc pour celle-ci. Et croiser les doigts que mon futur gamin ne soit pas un gueulard la nuit, qui m'empêche de dormir et de coder proprement.

Et ouvrir une partie Python, c'est useless. Y a que moi qui tape dans ce langage ici, et on ne peut pas dire que le topic dédié déborde de posts (hormis les miens, of course).
Par contre, une section C(++), pourquoi pas, vu que vous êtes nombreux ici à l'utiliser.

Ah ben si tu pouvais faire un ptit template en python avec Qt je doit t'avouer que ça m'aiderais vachement.
En fait le problème sous Qt, c'est que je sais pas du tout ce qui est le plus approprié pour faire un éditeur de carte.
J'avais commencé a regarder les "graphics scenes", mais ça m'a pris un peu la tête.
J'aurais bien aimé un truc bien plus simple, style double loop for, affichage d'un tableau de tiles, etc.
J'ai aussi testé d'utiliser un context opengl, mais j'ai du mal a l'intégrer a une scroll area.
Bref, cet éditeur me gave. Même sous GM j'arrive a en faire un plus facilement >.>
Puis ne t'en fait pas, ça fait un moment que le projet n'est plus vraiment pressé x)

En regardant dans le source de mon ancien truc, j'utilise effectivement les GraphicsView.
Pour ce truc, j'ai codé vraiment n'importe comment. J'ai plein de fichiers avec des méthodes doublons, et c'est franchement illisible, vu que je n'avais pas séparé clairement la partie affichage avec la partie moteur. Mais bon, quand je l'avais fait, c'était dans une optique quick&dirty, pour sortir un prototype que j'affinerais au besoin (je l'avais écrit dans un readme, pour m'en souvenir au cas où je regarderais ce code à l'avenir, ce qui est le cas actuellement. Je me remercie de ma prévoyance).

Bon, on va laisser ce thread de coté. On repasse dans le sujet OniDev pour parler de ça.

En fait le problème avec les graphics scenes, c'est que ça doit être un peu le bordel pour faire un changement de taille de la grille, quand on est en mode tuiles.
Vu que les graphics items sont pas bien rangés comme ils le seraient dans un tableau. Et ça, sa me perturbe x)
Pareil le ptit éditeur que j'avais fait dans les vielle version c'était du graphics scene.

Surtout qu'il n'y a pas besoins de perf de fou pour faire un editeur. Par contre comment vous comptez l'intégrer ?

Non, pas besoin de perf de ouf pour ça. De toute façon, ça ne devrait pas bouffer grand chose, c'est quasi-uniquement de l'affichage, y a pas de calculs qui tournent en parallèle.
Par contre, c'est vrai que ça peut perturber, parce qu'il faut faire à la manière Qt pour placer les tuiles sur une grille qui peut changer de taille. Mais c'est possible, vu que j'y arrivais avec wx (et dans une moindre mesure, avec pyqt).
Faut que je me replonge dans mon code, ça date.

Pour l'intégration, je ne vois pas trop où est le souci. Il faut un flux d'entrée et de sortie, c'est tout. Ça peut être une structure en C++, un dico en python, une archive zip, une string, une base de donnée, etc... Ça n'a aucune importance, le C++ et le Python sont largement complémentaire, l'un pouvant accéder à l'autre. Du moment qu'on ne tape pas dans des trucs ésotérique ( et encore... y a vraiment peu de trucs qui soit innaccessible à l'un ou à l'autre).

Si c'est l'intégration au sein de l'éditeur (à la game maker, une fenêtre modale), bah, je n'en ai aucune idée. Mais c'est secondaire (passer d'un logiciel indépendant à une fenêtre modale n'est pas compliqué avec Qt, si on découpe bien le moteur et l'affichage) et l'éditeur en Python servirait surtout de base de travail pour une future version en C++, et permettrait à Onilink de bosser sur un truc moins ******.
Bien entendu, si quelqu'un veut essayer de faire un éditeur directement en C++, qu'il le fasse. Moi, je pourrais bosser sur l'éditeur en python qu'à partir de fin avril/début mai, comme dit plus haut. Ça laisse le temps de réflexion.

Ah ok merci pour l'info.

[Message-automatique de spambotV.0.2b créer par Onilink ©]

Père noël (réfère a ton post dans la 1ere page), a-t-il un éditeur d'animation 2D comme GM?

Pas encore, ça fait partie des choses que je doit implémenter x)
Faudrait vraiment que je me bouge un peu... sachant qu'en une semaine intensive je pourrais au moins finir un truc utilisable.

Fin pour l'instant je m'occupe de l'éditeur de carte.
Je vais voir ce que donne un contexte opengl + des scrollbar. Si ça donne bien je garderais surement ça.

T'as qu'à utiliser des variables globales pour le scroll

Bon alors tu t'y remets quand ?
De toute façon tu ne pourras pas faire quelque chose de moins complet que GMS

Je bosse sur la onilib la, vu que ce seras le pilier central d'onidev x)

A mon avis une nouvelle version d'onidev ne sortiras pas de ci tôt.
L'idée serais de faire une onilib complète, créer des éditeurs de sprites/tiles/maps en externe (qui generent un fichier source) avant tout.
Donc bon, va falloir être patient, et pour les plus pressés, tester la onilib x)

Quoi qu'il en soit je commence a avoir un peu plus de temps la, ça devrais coder plus vite

Vu la tournure que prend GameMaker, et vu que je n'ai pas trouvé d'autre logiciel du même genre j'ai décidé de repenser complètement OniDev.

J'ai lu une grande partie d'un gros livre de C++ et acquis les capacités d'écrire un compilateur/interpreteur.
Je suis en ce moment même en train d'écrire un langage haut niveau qui comblerais les lacunes de GM.
La langage seras plus efficace, et normalement plus rapide (en tout cas plus rapide que GM <= v8.1).

Pourquoi un langage interprété?
Les raisons sont simples:
-Pas besoin d’intégrer un compilateur tel que gcc (qui pèse ~100Mo)
-Possibilité de générer des exécutables vers tous les systèmes ou l'interpreteur auras été porté de manière simple et rapide (je me concentrerais pour l'instant sur windows et linux).
-Possibilité d'utiliser un langage bien plus simple que le C++.
-Cela n'interdit pas la génération d'une source c++ pour ensuite la compiler et gagner les performances perdues par l'interpretation.


Je propose donc le langage ODL, qui seras un mix gml/c++ :
-Typage des données.
-Fonctions typées avec paramètres typés, l'on pourras aussi passer des références.
-Mots clés habituels: if, else, for, while, do, switch, etc...
-Une librairie standard proche de celle de GM
-Un système objet plus efficace que celui de GM (possibilité de créer des methodes).
-Tableaux unidimensionnels, bidimensionnels et peut être tridimensionnels (je me suis pas encore trop penché sur les tableaux a +1D)
-Possibilité de l’interpréter directement pour les tests (temps de lancement instantané).
-Possibilité de le compiler en une forme spéciale plus optimisée et rapide a lire par l’interpréteur (temps de compilation en fonction de la taille des sources).


Je n'ai pas encore finis de définir complètement la syntaxe de l'ODL car je me concentre actuellement sur les optimisations d’interprétation d'expressions.
Mais je verrais la chose ainsi. A vous de me dire ce que vous en pensez.

A la place des scripts on auras des modules. Les modules serons des librairies ODL écrites par les utilisateurs.
Vous pourrez écrire autant de fonctions que vous le souhaitez dans un module.

Exemples:
tris.mod.od

Code:

void triBulles(int &t[])
{
   int i, swap;
   do
   {
      swap = false;
      for(i=0; i<t.size()-1; i++)
      {
         if(a[i] > a[i+1])
         {
            a[i] <> a[i+1];
            swap = true;
         }
      }
   } while (swap);
}

void triBullesOpti(int &t[])
{
   int i, tmax, m = t.size();
   while(m > 0)
   {
      tmax = 0;
      for(i=0; i<m-1; i++)
      {
         if(a[i] > a[i+1]) {
            a[i] <> a[i+1];
            tmax = i+1;
         }
      }
      m = tmax;
   }
}

Les objets devraient fonctionner comme sous GM, a ceci près que tout se feras dans un unique code.
Exemple:
player.scr.od

Code:

// Load functions in tris.mod.od
loadmodule tris
// Do not load module functions
unloadmodule std.surfaces

#sprite: sprPlayer
#parents: PhysicsObject, DrawableObject
#visible: 1
#depth: -1


/*
   Define local variables for this object
*/
#variables
{
   int dir = 0;
   int moving = false;
   int key[4] = {vk_right, vk_up, vk_left, vk_down};
   int lx[4] = {1, 0, -1, 0};
   int ly[4] = {0, 1, 0, 1};
}

/*
   Create event
   Called when object is instantiated
*/
#create
{
   
}

/*
   Step event
   Called each step
*/
#step
{
   if(placeSnapped(16, 16))
      moving = false;

   int i;
   for(i=0; i<4; i++) {
      if(!moving && keyCheck(key[i]))
      {
         dir = i;
         moving = true;
      }
   }

   if(moving) {
      if(placeFreeRelative(lx[dir], ly[dir]))
         translate(lx[dir], ly[dir]);
      else
         moving = false;
   }
}

// method
void translate(int a, int b)
{
   x += a;
   y += b;
}

La syntaxe n'est pas définitive mais l'idée est la.
Le fait de pouvoir charger des modules ou non permettra d'éviter les collisions entre noms de fonctions par exemple.
Ce seras a l'utilisateur d'être bien organisé par contre (du genre commencer toutes les fonctions d'un même module par le même mot).

Si vous avez des idées d'amélioration ou des questions n'hésitez pas donc, j'essayerais de les prendre en compte.


Pour ce qui est de la grande question: l’exécutable générée seras-t-elle décompilable?
Oui et non.
La nouvelle forme générée de code ne seras pas trop difficile a retranscrire pour un gars qu'en a dans le ciboulot en ODL d'origine, mais tous les commentaires aurons disparus, tous les noms de variables et fonctions n'existerons que sous forme d'identifiants, donc le code généré seras pas vraiment lisible.
Pour l'instant protéger les exécutable générée sont le dernier de mes soucis, j'essaye déjà de faire quelque chose de fonctionnel.
On verras donc par la suite l'ajout de protections telles que le cryptage du 'bytecode' et des ressources dans l'executable (ou en dehors de celle ci).
De plus lorsque j'aurais codé l'option pour compiler avec G++, les exécutables générées seront donc compilées en assembleur. Très dur donc d'obtenir la source d'origine pour celles la ...


Bon y a beaucoup de blabla pour pas grand chose, mais je vais me dépêcher de finir au moins l’interpréteur ODL et sortir un mini compilo en console histoire de vous montrer que ça avance
Une date? Disons dans 3 mois :b (y auras qu'a me fouetter si j'ai rien a vous donner d'ici la )

Ca s'annonce super sympa, courage mec

Waow !
Par contre j'ai pas bien compris, ce sera que du ODL (d'ailleurs ca veut dire quoi ?) Ou on peut aussi faire du c++ ?
Et j'ai pas capté ce bout de code :
a[i] <> a[i+1];
Bref bonne chance

J'avoue que ça fait rêver, je ne vois rien à redire sur la syntaxe ODL qui m'a l'air d'un GML Like mais en mieux :vP
Sinon j'ai ma petite idée sur la signification de ODL (OniDev Language???)

J'ai franchement du mal à comprendre. Faudra donc utiliser une "machine" pour interpréter le truc, à la java, python ou javascript ? Dans ce cas, pourquoi ne pas directement utiliser ces langages, plus universel et polyvalent ?
Si c'est pour se rapprocher du GML, mouais. Le GML est simple, ok, mais l’inconvénient, c'est qu'il est trop spécifique à GM, et l'évolution est plus ou moins dur selon les langages visées.

Ou alors, c'est du faux interprétable et c'est plutôt de la traduction de code (ODL => parseur =>C++). Comme Cython avec Python et le C (on écrit un code en python, puis il passe à la moulinette d'un parseur et ce dernier recrache du C à compiler).

Non de ce que j'ai compris c'est comme un exe gm, mais en mieux. L'interpréteur est dans l'exe, c'est donc pas une machine virtuelle.

Sekigo>
Comme l'a dit Mass il n'y a pas de machine virtuelle, l’interpréteur seras dans l'exe, tout comme le runner de GM.
Mais il y auras aussi la possibilité de compiler avec un compilateur externe (ODL => parseur => C++ => g++ => executable)
De plus la grande différence avec les GM existants (a part peut être GMS) c'est que le code seras précompilé, et non pas copié collé directement a la suite du runner.
Cela permet d'optimiser la vitesse d’exécution étant donné que le code est mis dans une forme préparée a l'interprétation.
Pour donner un ordre de grandeur, j'ai fait les premiers tests avec des expressions mathématiques:
Une expression de 15Mo dans un fichier txt prend ~900msec a être évaluée telle qu'elle, et ~90msec si elle a été 'précompilée'.
Sous GM elle n'est même pas évaluée car trop grosse, et fait planter l’interpréteur x)


Térence68>
C'est un bête opérateur de swap, ce qui évite d'utiliser une variable temporaire pour échanger les valeurs de deux variables.
Perso c'est un truc qui m'a toujours manqué alors je le met maintenant que je peut

Et oui ODL = OniDev Language :b


Si la syntaxe vous plait je continue sur ma lancée donc.
Et pour ceux qui se posent la question il y auras aussi les cast, et possibilité qu'un objet ai plusieurs parents (ça par contre faut que j'arrive a l'implémenter).

Je propose de déclarer les tableaux en plaçant les crochets sur le type (comme en Java) et pas sur le nom, ça m'a toujours paru plus logique :p

Ok merci je connaissais pas mais c'est vrai que ca peut être utile !
Pour le cast et plus précisément pour la concaténation, je l'ai déjà dit je sais plus ou, tu pourrais faire comme en php, et contrairement aux autres langages genre gml ou c++, mettre un autre caractère que +, un point par exemple :
a=3+4 //a=7
b="3"+4 //bug
c="3".4 //c="34"
Perso je trouve ca plus clair et ca évite justement le cast, par exemple avec gm pour afficher "score" et la valeur de la variable score, faut faire :
"score : "+string(score)
alors qu'en php, suffit de faire :
"score : ".$score
Bref chaque langage a ses points forts et ses points faibles, tu devrais essayer de récupérer tous les point forts des différents langages pour l'ODL !
J'ai vraiment hâte que ton truc soit fini, je vais beaucoup l'utiliser !
J'ai vite arrêter le c++ parce que je suis une ***** en anglais (donc pour la doc....) et surtout que ca manque beaucoup de fonctions d'affichage et de fonctions pour les jeux ; avec ton projet je suis convaincu que ca irait mieux
Pareil, je pense que tu pourrais intégrer quelques éléments de formulaire simple (textbox, checkbox,etc..) ; là aussi ca erai un énorme plus !

Alors pour le cast avec le point ce ne seras pas possible car il est déjà utilisé pour tout ce qui est objet.attribut|methode.
Et comme je considère une chaine string comme un objet avec des méthodes, bah y a pas la place pour autre chose.

En revanche, je pense laisser la possibilité de faire "chaine"+(string)5 => "chaine5" par exemple.
Reste a voir s'il y a un soucis d'optimisation ou non.

Deezee>
Bonne idée ça, je le note et si c'est plus simple a implémenter que l'autre je garde ça :b

Pour ceux qui voudront suivre l'avancée de l'implémentation je l'écrit en première page.
Actuellement:
Expressions:
Types byte, int, float et double pris en compte. Les expressions n'évaluent qu'en int et double cependant.
Cast int et double possibles. Prise en compte du type lors de l'évaluation.
5/2 => 2
5.0/2 => 2.5
(double)(1+2*(int)31.41592+'A')/10 => 12.8

Pour ce qui est des optimisation, l'évaluation d'un expression mathématique de 15Mo en texte
prend ~250ms sur mon ordi (2.50GHz).
Sous GM ça fait planter le runner donc j'ai pas pus tester x)