AmiDARK Engine – Feuille de route, Beta Test, Ventes

Voici un communiqué de Frédéric “AmiDARK” Cordier, le développeur de l’AmiDARK Engine (langage de programmation dans la veine de DarkBASIC et de DarkGDK en cours de développement) :

Bonjour,

De nouvelles informations sont disponibles concernant l’AmiDARK Engine !

Cette information décrit la feuille de route non-officielle du projet, le programme d’alpha/beta test de l’AmiDARK Engine ainsi que les méthodes disponibles pour la vente du produit lorsqu’il sera finalisé.

Voici le lien sur le site officiel : http://www.amidark-engine.com/spip.php?article1

Site internet : http://www.amidark-engine.com

8 Commentaires

Passer au formulaire de commentaire

    • XRAY sur 13 novembre 2010 à 23h21

    Yessssssssssssssssss, plein succès et vive AmiDARK:-)

    XRAY
    Pour team RELEC

    • AmiDARK sur 15 novembre 2010 à 0h27
      Auteur

    Merci 🙂

    La DOC HTML (anglaise) avance bien.
    Je devrais l’avoir fini d’ici Mardi soir si tout va bien.
    Je pourrais donc mettre en ligne la dernière Alpha publique sur os4depot.net
    et l’ Alpha Test pourra commencer normalement d’ici 7/8 jours.

    @ +
    AmiDARK.

  1. Salut AmiDark
    Je testerais volontier ton moteur 3D 🙂
    Pour la 2D par contre j’ai pas vraiment d’avis….

    Si tu veut une donation je peut t’envoyer un cheque (oui je sais c pas moderne mais moi non plus je suis plus si jeune ;-p )

    J’ aurai deux remarques générales à faire sur ton ‘langage’:
    1) Si on le fait avec deux fonctions alors se demander si on peut pas le faire avec une
    2) Si on fais toujours les memes fonctions dans le meme ordre (genre pour démarrer un programme) alors le faire en une seule genre mon-truc-init()

    Plus généralement je prends un exemple j’ai ma soft3d.library (soft3D est le driver soft de Wazp3D http://aminet.net/driver/video/Wazp3D.lha) qui fait que 23 fonctions et j’en viens à me demander si qques fonctions ont vraiment besoin d’ etre indépendantes ou pourrait pas etre inclues dans des fonctions plus ‘globales’

    Avec ce genre de remarques tu comprendra que je n’apprécie pas trop OpenGL avec ces centaines de fonctions et states …

    Un simple exemple: le brouillard (fog)
    J’ai vu dans tes exemples que tu reprenais la syntax ‘à la opengl’ avec plusieurs fonctions pour faire un simple brouillard
    Alors qu’une simple fonction comme
    Fog(CONTEXT sc,UBYTE FogMode,float FogZmin,float FogZmax,float FogDensity,APTR FogRGBA);

    Suffirait largement…

    Enfin voilà l’idée….

    Alain Thellier – Auteur de Wazp3D

    • AmiDARK sur 16 novembre 2010 à 2h31
      Auteur

    @Thellier :

    Avec ce genre de remarques tu comprendra que je n’apprécie pas trop OpenGL avec ces centaines de fonctions et states …

    C’est ton choix, ton droit … mais c’est pas forcément la meilleure vision qu’il soit …
    (la mienne ne l’est peut-être pas plus :p)

    1) Si on le fait avec deux fonctions alors se demander si on peut pas le faire avec une

    La ou tu te trompes c’est que faire 1 seule fonction, force, lorsque tu veux changer 1 paramètre dans ton brouillard à tout changer dans le brouillard … donc forcément si tu modifies 6 paramètres … c’est plus long que d’en modifier 1 seul … si je ne veux modifier que la distance, je ne modifie que la distance … ( par exemple, et effectivement en background ma fonction ne modifie que 1 paramètre ) … donc ton point de vue fait perdre en performances …

    Simplifier c’est une chose … mais supprimer la flexibilité d’un langage et le rendre rigide … pour moi ce n’est pas une solution.
    De plus, avoir plusieurs fonctions avec des NOMS PRECIS permet de mieux imprégner le sens que chaque commande …
    Chaque commande est nécessaire et importante …

    2) Si on fais toujours les memes fonctions dans le meme ordre (genre pour démarrer un programme) alors le faire en une seule genre mon-truc-init()

    En fait oui et non …
    Faire ceci supprime encore de la flexibilité … Tout ce qu’il est nécessaire de faire en initialisation est déjà en initialisation (ce que l’utilisateur ne voit pas, créer les contextes, ouvrir les librairies, faire les vérifications systèmes, etc …) avant que la fonction DarkLoop() ne soit lancée.
    N’oublie pas que les exemples sont la pour montrer le principe de fonctionnement… rien n’oblige l’utilisateur de programmer exactement comme je le fais mais je garde toujours la même structure pour que l’utilisateur s’y retrouve d’un exemple à l’autre dans son apprentissage …

    /Me pense que Thellier aimerait le langage de programmation mono-commande avec la seule et unique commande : MakeGame() :p

    Et puis comme l’on dit .. tous les chemins mènent à Rome cependant … Tous ne sont pas forcéments pavés, sinueux, en montagne, bord de mer, campagne …
    A méditer 😉

    EDIT :
    Après, rien n’empêche d’allier les deux … Mettre les fonctions décomposées et la fonction qui gère tout d’un coup 😉 (histoire de satisfaire les 2 écoles)

    • sur 16 novembre 2010 à 18h43

    AmiDARK : en fait, je pense (mais je lis entre les lignes) que c’est effectivement ce que tu mets dans ton “PS” qui était suggéré. Enfin, c’est comme ça que je l’avais compris. Mais c’est effectivement pas écrit explicitement 🙂

    (en tout cas, bel accomplissement, j’ai l’impression que tu as fait tout ça en un temps record !)

    • LorD sur 16 novembre 2010 à 21h03

    Après, rien n’empêche d’allier les deux … Mettre les fonctions décomposées et la fonction qui gère tout d’un coup 😉 (histoire de satisfaire les 2 écoles)

    Mootools (framework javascript) a cette philosophie (d’autres framework font surement de même). Par exemple, pour un fondu, il est possible de faire
    $(‘mondiv’).tween(‘opacity’, 0, 1) ou bien $(‘mondiv’).fade(‘in’).

    /me sort sa science à 2 balles :-p.

    • elwood sur 16 novembre 2010 à 22h08

    @Amidark

    La ou tu te trompes c’est que faire 1 seule fonction, force, lorsque tu veux changer 1 paramètre dans ton brouillard à tout changer dans le brouillard … donc forcément si tu modifies 6 paramètres … c’est plus long que d’en modifier 1 seul … si je ne veux modifier que la distance, je ne modifie que la distance … ( par exemple, et effectivement en background ma fonction ne modifie que 1 paramètre ) … donc ton point de vue fait perdre en performances …

    j’ai rien compris 😆

    Mais je vois de quoi ça parle quand même. On peut bien fournir les deux ensuite le développeur choisit la fonction “all in one” ou les fonctions qui correspondent.

    • AmiDARK sur 16 novembre 2010 à 23h48
      Auteur

    De toute façon, lorsque l’AmiDARK Engine sera en phase Beta Test et, même après sa “release”, si un codeur me demande une fonction simplifiée pour une commande existante ou même une commande qui regroupe plusieurs paramètres d’un objet, je pourrai l’ajouter pour la mise à jour suivante …
    Rien n’est définitif.
    L’objectif est tout de même d’avoir une base de travail pour avancer … Après, on peut toujours broder autour 😉

Les commentaires sont désactivés.

Amiga Impact