| Amiga Impact

  · Accueil
  · Actualités
   · Proposer une info
  · Agenda
   · Proposer une date
  · Articles
  · Forum
  · Petites Annonces
  · Chat IRC
  · À propos du site
   · Confidentialité



 | Connexion

Identifiant :

Mot de passe :

 Mémoriser

  · Inscription
  · Mot de passe oublié



 | En ligne

Illustration du profil de junior2 Illustration du profil de __sam__






 | Nous suivre

Flux RSSGoogle+TwitterFacebook





Actualités


   AmiDARK Engine – Feuille de route, Beta Test, Ventes
   | 13 novembre 2010 | Logiciels,

programmation

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




Les commentaires appartiennent à leurs auteurs.
Nous ne sommes pas responsables de leur contenu.


Auteur Conversation
xray Posté le 13 novembre 2010



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

XRAY
Pour team RELEC



AmiDARK Posté le 15 novembre 2010



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.



thellier Posté le 15 novembre 2010



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 Posté le 16 novembre 2010



@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)



mahen Posté le 16 novembre 2010



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 Posté le 16 novembre 2010



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 Posté le 16 novembre 2010



@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 Posté le 16 novembre 2010



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 😉








Haut de page 

Copyright © 2004-2018 Amiga Impact. Tous droits réservés. Les marques citées sont déposées par leurs propriétaires respectifs.
Conditions d'Utilisation, Politique de Confidentialité et Information sur les cookies.


Fil RSS WordPressNicolas Gressard, Conseil et développement informatique

Do NOT follow this link or you will be banned from the site!