Non la syntaxe est vraiment cool, la puissance du C (typage etc) avec la simplicité du GML parfait quoi.

Ah, ça avance bien a ce que je vois. Vivement que l'on puisse tester

J'ai eu quelques idées pour améliorer l'efficacité de l'interface:

Code:

La console permettra de faciliter la vie du programmeur.
Elle aura un evaluateur d'expressions d'intégré, permettra l'accès aux ressources, etc.


---Specifications des commandes---

--Ressources--

#Afficher les ressources:
ls [options]
 -textures
 -sprites
 -sounds
 -paths
 -fonts
 -scripts
 -objects
 -rooms
 -l            Afficher les informations sur les ressources (voir info)
 -sort        Affiche les ressources par ordre alphabetique

#Afficher les informations sur une ressource
info [ressourceName]
Si ressourceName n'est pas spécifiée, alors la commande afficher les informations sur le projet.
 -s, -size    Afficher la taille de la ressource en octets
 -a, -author  Afficher l'auteur de la ressource
 -t, -time    Afficher la date et l'heure de création
 -e, -edit    Afficher la date et l'heure de la derniere edition
 -i            Informations specifiques au type de ressource


#Ouvrir une ressource
open [ressourceName]
Si ressourceName est déjà ouverte, elle seras mise en avant.
 -all          Ouvre toutes les ressources
 -textures
 -sprites
 ..

#Fermer une ressource
close [ressourceName]
 -all
 -textures
 ..
 -nosave      Ferme la ressource sans la sauvegarder


--Autres--
#Evaluer une expression
eval exp
 -opti        Optimise l'expression si possible
 -prefix      Affiche l'expression sous forme prefixée
 -postfix      Affiche l'expression sous forme postfixée

#Verifier les erreurs
check className[::method]
check scriptName[::function]
 -w            Affiche les warnings

Du coup y auras probablement une petite console dans le footer d'onidev, quand j'aurais la foi de l'intégrer a l'ui :b

(Si vous avez des commandes a me proposer, tentez votre chance :b)

C'est complètement HS, mais je viens d'y penser : pour toutes les fonctions de dessin, tu fera des fonctions :
drawRectangle(x,y,width,height)
ou
drawRectangle(x1,y1,x2,y2)
?
Parce qu'en fait le top du top, ce serai qu'on puisse choisir la façon, soit dans les paramètres globaux du soft, soit avec un argument facultatif en plus (avec une constante pour utiliser les dimensions ou les coordonnées)

Oh pour ça j'ai juste utilisé des fonctions aux noms différents :b

Genre drawRect(x, y, w, h, fill) et drawRectangle(x1, y1, x2, y2, fill).
Pas besoin de chercher compliqué :b

Je vois que tu pense à tout
Sinon (tout aussi HS), t'as une liste de toutes les fonctions dispo ?

Ouh la source d'erreurs ^^

DrawRectSize(x,y,w,h) et DrawRectCoords(x1,y1,x2,y2) ? :p

Bof jvois mal les gens faire des erreurs pour afficher des rectangles quand même xD
Enfin pour les noms de fonctions c'est pas prioritaire, mais l'idée est la :p

Térence>
Pas encore mais je mettrait prochainement la doc a jour :b


La je me prend un peu la tête avec les particules :b
Fonctions que personne n'utilise, mais ça fait parti des rares trucs que je trouvais vraiment bien foutu sous GM, du coup je me fait plaisir
(surtout que j'ai prog un moteur de particule qui marche nickel et exactement comme celui de GM mais en beaucoup plus opti).

Edit:
Pas con Mass :p

Je up parce que j'ai eu des idées
Je viens de remarquer à l'instant que lors d'un test avec des && ou des ||, GM vérifie toutes les conditions, même quand c'est pas nécessaire, je m'explique :

Code:

a=true
b=false
if(a==true||b=true){
//do something
}

Ici, a vaut true, donc la condition est forcément vérifié, peu importe la valeur de b, donc on n'a pas besoin de la vérifier. Parce que avec GM, si b n'existe pas, il soulève une erreur, ce qui empêche de faire ca :

Code:

if(instance_exists(heros)&&heros.life<=0){
// do something
}

Si le héros n'existe pas, la condition sera forcément fausse mais GM continue et comme il connait pas heros.life, il *****, ce qui oblige donc à faire ca :

Code:

if(instance_exists(heros)){
    if(heros.life<=0){
      // do something
    }
}

ce qui est plus long à écrire (et là je dois le faire à une vingtaine d'endroit...)...
Dans les autres langages, la vérification est arrêtée si on connait déjà son résultat avant d'avoir fini, ce qui permet en php :

Code:

if(isset($_POST["pseudo"]&&$_POST["pseudo"]!=""){
// do something
}

Et ca marche en java et dans tous les langages évolués à ma connaissance, donc comme j'étais pas sûr que t'y ai pensé, faudrait que t'implémente ca dans l'ODL

Sinon autre proposition, je me suis rendu compte que les fonctions de dessin sont incroyablement pauvre en GML par rapport à java, ce serait vraiment le pied si tu implémentais les arcs de cercle, bézier, l'épaisseur, les calques, les dégradés (pas juste la ***** infame de GM),etc...

edit : Ah oui et aussi, dans les script, un système commentaire suivant une certaine syntaxe pour l'auto-complétition:

Code:

// @info function_name(argument0_name,argument1_name)
// @info argument0_name @ description argument0

Ce qui donnerait par exemple :

Code:

// @info is_hover(x,y,w,h)
// @info x @ position x
// @info y @ position y
// @info w @ largeur
// @info h @ hauteur

Comme ca quand on code, on peut se rappeler l'ordre des arguments et leur utilité

Pour l'évaluation des expressions oui bien sur je comptait faire cela, vu que de toute façon ça doit être compatible ensuite avec l'évaluation en C++ (pour le transcodeur).
Ça a d'ailleurs un nom, je crois que ça s'appelle l'évaluation passive.

Pour les fonctions de dessin de même, je pensais récupérer pas mal d'idées des fonctions canvas en Js :b

Pour ce qui est des commentaires, ouai c'est un truc a la doxygen. Pareil je pensais le faire, mais ça c'est loin d'être prioritaire (mais c'est sur la todo list ).


En tout cas je finis la fac début juin (me reste un oral a passer), je pourrais reprendre le développement o/

Évaluation paresseuse :p

Ah oui voila! Je savais que ça commençais par un p xD

Pour l'évaluation paresseuse, je savais pas si t'y penserai donc je voulais être sur parce que c'est quand même super pratique
Pour le dessin, tu pourrais aussi essayer d'implémenter les fonctions SVG dans ce cas, ia vraiment moyen de faire des trucs superbes avec, et pour les commentaires, oui bien sûr, c'est vraiment pas prioritaire, mais ca fait partie des détails qui font apprécier un soft
Pareil, si t'arrivais à faire une ****** de complétition auto, plus à la éclipse qu'à la GM, ce serait vraiment superbe (genre importer les packages, renommer les variables en double,etc...)
Ah et aussi, encore dans le détail, pour l'indentation auto, permettre de choisir le type dans les options : comme ca :

Code:

function(){
    // do something
}

ou comme ca :

Code:

function()
{
    // do something
}

Parce qu'à chaque fois que je change de soft, ca m'oblige à changer GM préfère la seconde, alors qu'éclipse ou visual studio sont plus adaptés à la première...

Alors l'éditeur parsera le code en temps réel. Du coup oui y auras moyen de gérer l'auto complétion et le renommage intelligent sans trop de difficulté.
Je compte faire pas mal de features pratiques a ce niveau, mais pareil ça c'est l'enrobage, faut déjà que je code l'engine en lui même :b

J'ai fait un logo à la con en me basant sur le GameMaker que j'avais fait. :p

Sympa, mais un peu terne et les ombres rendent le tout flou plutôt que de l'embelir :b

Puis bon j'ai déjà un logo

Ce qui fait ***** c'est que les ombres ne s'affichent quasiment pas sur l'espèce d'échiquier de Photoshop, du coup c'est beaucoup plus foncé que prévu. :/

onilink_ a écrit:

Puis bon j'ai déjà un logo

C'est pas vrai d'abord !

Après un petit moment de grande réflexion.... je me suis remis a bosser sur le langage.
Vu que ces derniers temps j'ai beaucoup touché au C++ j'ai finis par croire que quoi que je fasse, je me retrouverais avec un langage pourris qui n'arriverait même pas a sa cheville...
Du coup si quoi que je fasse je me retrouve avec un sous C++, bah autant faire réellement un sous C++ pensé comme tel, et qui permet ensuite de générer du C++ réellement utile, pas juste du C++ qui sert de passerelle pour compiler un binaire.

Du coup je suis parti sur un C++ like pas mal simplifié, mais qui conserve certaines parties intéressantes de C++11 comme:
-les pointeurs intelligents: ce langage n'aura aucun pointeur nu, ni même pointeur en tant que tel, vous aurez uniquement le choix entre des shared/weak_ptr, des unique_ptr, ou des observer (qui sont comme un pointeur nu, sauf qu'on peut pas les delete, donc c'est un peu le weak_ptr de l'unique_ptr)
Bref niveau utilisation il n'y aura donc pas les *machin ou encore truc->bidule, tout ressemblera a une "reference" C# ou Java dans l'utilisation, mais il faudra gérer la mémoire a la main (même si avec les pointeurs intelligents ça reste extrêmement simple).
-les templates, il seront simplifiés mais permettront d'avoir comme en C++ des classes génériques (et peut être un jour de la TMP compile time)
-les references, const references, méthodes de classes constantes... pour la robustesse et la rigueur du code
-structures et classes, héritage et si tout se passe bien héritage multiple et virtuel
-tableaux dynamiques et statiques, qui seront convertis en std::vector (heap) et std::array (stack)

Bref comme je vais compiler ce langage en C++ je vais surement récupérer un paquet de choses, tant que le parsing ne deviens pas trop complexe (car parser du vrai C++ ça c'est vraiment une horreur).
Par contre a terme je compte aussi faire un interpréteur, donc je vais tout de même me limiter sur les features trop complexes.

Actuellement, j'en suis encore au début mais j'ai pas mal avancé.
Mon compilo gère les fonctions avec paramètres, variables typées, scopes, boucles, et surtout il compile tout ça comme il faut en C++ mais a aussi une analyse sémantique et gestion des erreurs qui commence a plutot bien fonctionner (avec déduction des types, fonctions ou variables qui existent pas, etc...)

Exemple compilable actuellement:
Input:

Code:

func f(int x) int
{
    return x;
}
 
func main()
{
    int i;
    float x = (1 + 2) * 3;
  
    for(i=0; i<10; i+=1)
    {
        x += f(i);
    }
}

Output:

Code:

void f(int x)
{
  return x;
}
 
void main()
{
  int i;
 
  float x = ((1 + 2) * 3);
 
  for(i = 0;(i < 10);i += 1)
  {
    x += f(i);
  }
 
}

Exemple de gestion d'erreur:

Code:

func main() void
{
    int x = 123;
    {
        int y = x;
    }
    int z = y;
}


13:13:error: y was not declared in this scope
    int z = y;
            ^

J'en ai aussi profité pour mettre a jour le premier post.

J'attend la version finale