M'Force Suite Alpha 1 - Page 1

Voilà, c'est aujourd'hui la sortie de la première alpha de M'Force Suite.
M'Force Suite, de LouisXIV, est une suite logicielle permettant de faire de la 3d filaire sur TI.
Elle permet des trucs totalement dingues lorsque l'on sait s'en servir,
LouisXIV a déjà fait faire du hip hop à une croix, ou un
morphing impressionnant (en CyclePic ) d'un cube se transformant en hélicoïde complexe.

Disclaimer: M'Force Suite est très complexe, et bien que connaissant personnellement l'auteur
et fouillant souvent dedans je n'en ai qu'une maîtrise très incomplète. De plus, aucune doc
n'est inclue dans le zip (alors qu'il en existe déjà), et la dernière version en développement
supporte déjà d'autres technologies, comme un nouveau moteur de rotation (RTD3) ou bien les scripts M'Script.
C'est pour cela que c'est une version alpha.

Néanmoins, les personnes persévérantes pourraient arriver à quelquechose avec.
Je prépare un autre post pour dire quelques bases...

Télécharger M'Force Suite Alpha 1

on peut avoir des screens ?

Tout d'abord, Lycos va vous bloquer alors persévérez, allez dans public/louis14/ et prenez le zip.
Ce zip est un groupe .9xg, c'est-à-dire un backup. Je ne suis pas sûr de son contenu, il
se pourrait qu'il y ait plein d'autres choses avec. Avant tout je vous conseille de tout archiver sur la caltos,
ça va prendre de la place.

Une fois que c'est arrivé, placez-vous dans le répertoire et faites "itsclean()".
Ce programme nettoie le répertoire. Pour la première fois, confirmez la suppressio des listes d'édition etc...

C'est quand le répertoire est propre ainsi qu'il faut tout archiver. Mais ne le faites pas la première fois, il faut que
les programmes soient tokénisés.

Bon, il est temps d'éditer une forme. Exécutez "create3d()".
Cet éditeur vous demande un point. Choisissez avec le curseur, puis ENTER.
Le programme vous demande la profondeur du point (coordonnée Z).
Entrez-la. Une boite de dialogue vous propose différentes options. QUand vous aurez terminé, choisissez
"Ignorer: voir barre d'outils" dans le menu dropdown de la boite. Un ESC bien placé vous permettra de sortir du modeleur.

Il est temps de passer aux choses sérieuses. Faites "mforce3d()". Cela démarre Xilon, le programme principal de la suite.
Il faut normalement certaines conditions, comme par exemple que vous ayez flib et flib2 dans le répertoire main...

Golden Crystal > Absolument rien de tel n'a hélas été fait pour l'instant. De plus, il faudrait un gif animé pour qu'on puisse se
rendre compte de la puissance de cet outil. On va essayer d'en faire un, mais ce sera certainement pas avant ce week-end,
le temps que je voie LouisXIV.

Xilon n'est absolument pas intuitif. Cependant, il permet du morphing avec Cross Morph 4D,
une interpolation linéaire avec le BC-Buffer, créer un objet à partir d'une fonction z=f(x,y) (Aspi3D)
du motion blur grâce à un tramage des images lors du rendu, Into3D pour extruder, RTD2 pour les rotations de l'objet, et
bien plus encore.

C'est en BASIC ?

bah ca en a tout l'air.

Il faut normalement certaines conditions, comme par exemple que vous ayez flib et flib2 dans le répertoire main...

Ben ça n'arrivera pas sur ma TI alors. Dommage...
Je signale au passage qu'il existe déjà un essai d'utilitaire pour faire de la 3D sur TI, solidworks de David Coz, si je me souviens bien.

Si vraiment le logiciel de Louis XIV est puissant, ce serait sympa d'avoir quelques screenshots pour apprécier

Sasume > Et ben on y est, le fameux "C'est en Basic, c'est nul"

Non, tout au contraire, car:

- L'utilisateur peut faire des tonnes de trucs, il peut faire des plug-ins pour M'Force (un système est prévu et fonctionne
dans cette alpha, et depuis bien longtemps d'ailleurs) ce que Edit3D est totalement incapable de proposer.

- M'Force est lent, il n'est pas prévu pour du temps réel. On règle tout, et on lance un rendu. Ca peut mettre un quart d'heure,
le résultat est en CyclePic, ce qui est très lourd, mais en attendant les anims sont bien plus jolies que celles de Solidworks,
qui à ma connaissance ne fait pas de morphing de gros barbare.

- Il faut vraiment que je fasse les screens.

Bref à part la rapidité et l'application de texture, M'Force Suite est systématiquement supérieur à Solidworks...
C'est comme comparer un jeu sous DirectX et un rendu de 3DSMax... sauf que là ça se passe sur TI.

Et pourquoi ne pas l'avoir développer en C? le résultat aurait été meilleur à tout point de vue ...

Justement, c'est pour des petites astuces faciles et accessibles à tous: le expr().
Tout programmeur de plug-in n'a qu'à savoir quelle variable fait quoi (et c'est plutôt simple, par exemple
d1 contient la liste des X des points, d2 les Y etc) et il peut faire absolument tout ce qu'il veut.

Par exemple, le plug-in BCBuffer prend une liste de 10 points par exemple, et interpole pour que l'on ait 30 points.
Tout ça se fait simplement...

Pour donner en C le même accès aux variables du programme, ce serait un véritable cauchemar, genre en lieu et
place des expr("") qui n'embêtent pas il faudrait faire des fonctions de callback, avec un test si le pointeur est NULL,
et puis en plus s'arranger à aller chercher un nom de fichier, prendre un pointeur vers l'origine et lire des info pour savoir que
c'est un plug-in, arranger un header pour savoir où sont les fonctions dans le programme plug-in.....
Tout cela demandant un format de fichiers spécial...

De plus, LouisXIV ne sait pas programmer en C... d'ailleurs même s'il savait,
il programme tellement comme un cochon que le prog ne se lancerait même pas...

bah en C tu peux très bien exporter les mêmes variables qu'en Basic franchement je ne vois pas le problème. Et si c'est en Basic mal programmé ça doit vraiment être lent
Et si il ne connait pas le C c'était le moment d'apprendre

1) On s'embête quand même moins en Basic, et si le programme C doit utiliser sans cesse des variables Basic,
qu'il va chercher pour el moindre petit calcul la variable a, et l'élément truc de telle matrice, ça va pas être terriblement
rapide, et en plus on va s'emmerder avec les structures des données, un string c'est simple, une matrice ou une data
un peu moins... Autant le faire en Basic, on se concentre sur les fonctionnalités du prog...

2) Non, c'est pas TROP lent (juste très lent) car LouisXIV finit toujours par s'en sortir...

3) Pour le C, c'est ce que je me tue à lui dire...


Bon, sinon pour des trucs rapides, j'avais prévu de faire un lecteur d'un format, le VectorCG, qui contiendrait
les instructions de tracé de point, de ligne etc... bref une sorte de bytecode qui contienne la liste des opérations à faire
pour retracer le dessin. Ca prendrait très peu de place et pourrait faire des choses rapides, avec en plus une gestion du temps,
le "Bullet Time" peut se faire (M'Force peut déjà s'arranger pour ça, d'ailleurs...)
Le pb, c'est que j'ai eu des blèmes, peut-être pb d'alignement, ça a jamais bien marché... Faut que je regarde plus sérieusement..

Snow Tiger :
- L'utilisateur peut faire des tonnes de trucs, il peut faire des plug-ins pour M'Force (un système est prévu et fonctionne dans cette alpha, et depuis bien longtemps d'ailleurs) ce que Edit3D est totalement incapable de proposer.

On peut aussi faire des plugins en C.

- M'Force est lent, il n'est pas prévu pour du temps réel. On règle tout, et on lance un rendu. Ca peut mettre un quart d'heure,

C'est une chose de plus qui fait que c'est nul. Je ne vois pas en quoi c'est un argument en sa faveur.

Franchement, dis à ton ami d'arrêter de se prendre pour un roi (cf. son pseudo) alors qu'il ne sait même pas programmer en autre chose que le BASIC.

On peut aussi faire des plugins en C.

Plus facile en Basic.

C'est une chose de plus qui fait que c'est nul. Je ne vois pas en quoi c'est un argument en sa faveur.

J'ai pas dit que c'était bien... mais simplement que c'était pas son but d'aller vite.

Franchement, dis à ton ami d'arrêter de se prendre pour un roi (cf. son pseudo) alors qu'il ne sait même pas programmer en autre chose que le BASIC.

T'es méchant .
Dès qu'on utilise pas TIGCC....

Moi je pense que les fonctions qui sont dans les plugins (apparemment, c'est pour l'automatisation des mvts, etc...) n'ont pas besoin d'être aussi optimisées que les fonctions de rendu (le ray-tracer proprement dit), donc c parfaitement possible de faire des plugins en Basic et un moteur de rendu en C... Et ça permettrait de faire des grays, de faire du vrai remplissage et même de mettre des textures

Pour M'Force, c'est à LouisXIV de voir. Quant à moi, je fais également un soft de 3d, qui est tout le contraire:

- C'est par triangles
- C'est bien programmé
- Y'a pas 150 000 variables dans le répertoire qui bouffent toute la mem.

Et dans cette conception, ça serait l'inverse de ce que tu viens de dire: le coeur en Basic (de toute façon c'est même pas
vraiment un coeur, ça définit 3 fonctions Basic, ça doit prendre 900 octets )
et les plug-ins en ce qu'on veut, que ce soit Basic ou compilé.
Et j'envisage pour mon moteur du vrai remplissage avec textures, en Basic d'abord puis en C avec du Gray...

Enfin bon, là LouisXIV ne va pas être content si le topic de son oeuvre part part sur mon oeuvre...
Les deux suites seront assez compatibles (partage de plug-ins à mon format) ce qui permettrait aussi d'utiliser
mes modules dans M'Force. Il faut que je fasse ces modules, et que LouisXIV se décide à permettre l'utilisation de
mon architecture (ce qui lui prendrait 5 minutes )

Et il ne peut pas venir en parler lui-même l'intéressé ?

Quand il aura l'ADSL
(il a fait un topic rien que pour ça )

moi qui pensait qu'un 56k suffisait pour se connecter... ou un PC dans son bahut...
enfin bon.

Basic=nul > c'est bien gentil de dire ça, mais c'est parce que les defenseurs du basic et ceux du C n'ont pas le meme objectif en prog: ceux en C cherchent la performance pure, de bon graphismes, la fonction ultime... ceux en Basic cherchent la simplicité (du langage), la compatibilité (en général... et oui, je sais ce qu'est un notsub), et un moyen de se marrer sans se prendre la tete.

maintenant si c'est lent (du code basic special goret, tu m'etonnes), tant pis!

Je trouve ça idiot de se lancer dans un projet qui demandera de la puissance en BASIC plutôt qu'en C/ASM.
Si vous avez la flemme d'apprendre le C, c'est que vous n'êtes pas fait pour la programmation. Le C est un langage simple et cohérent.

Oui, le Basic n'est pas tellement plus simple, en fait. Il est plus abordable, mais à l'usage c'est bcp moins pratique (même si y a des trucs sympa, genre la gestion native des listes et des chaînes).

Je trouve dommage que Sasume soit aussi borné au sujet du basic... Personellement ça m'amuse tjrs de faire (et donc d'utiliser, par curiosité) des petits programmes basic. Justement ça ne se programme absolument pas comme du C, et tout ce qui est optimisation consiste à trouver des astuces ou des combinaisons de fonctions d'AMS pour aller le plus vite possible.

C'est loin d'être ininteressant (et également loin d'être "simple", comme tu le sous-entend, c'est d'ailleurs pour ça qu'il n'y a presque que des programmes en basic très mal réalisés), sauf peut-être pour quelqun qui n'a jamais cherché à y jeter un oeil.

Je suis d'accord avec toi, Bob, mais comme tu le dis ça M'amuse MOI perso de faire de la prog basic. Utiliser un prog basic me saoule quand même pas mal (en dehors des progs typiques de maths qui gagnent à être interfacés avec AMS).

Vertyos> C'est vrai que je descends souvent le BASIC dans mes posts.
Moi aussi, je fais de temps en temps des petits programmes en BASIC (enfin, j'en faisais quand j'utilisais encore ma TI), mais justement, le BASIC c'est très bien pour des petits programmes (les seuls gros programmes pour lesquels je vois une utilité à ce qu'ils soient codés en BASIC sur TI sont les progs de math), mais pas pour des gros jeux. On se retrouve après avec des tonnes de fichiers sur la calc et un jeux trop lent. Alors qu'en C/ASM, on peut faire la même chose moins encombrante et plus fluide (donc plus jouable).

Je trouve ça idiot de se lancer dans un projet qui demandera de la puissance en BASIC plutôt qu'en C/ASM. Si vous avez la flemme d'apprendre le C, c'est que vous n'êtes pas fait pour la programmation. Le C est un langage simple et cohérent.

Pas d'accord. Déjà à la base je n'aurais jamais pu commencer le C si je n'avais pas eu d'ordi à moi (celui de mes parents est accessible 1 à 2 heures par week-end, imagine tes projets dans ces conditions! ) et le fait de pouvoir programmer en Basic directement sur sa calc (donc pendant les cours) est encourageant. Toutes les idées que j'ai eues ont d'abord émergées en Basic pendant les cours ennuyeux... Donc le basic c'est pas si nul que ça...

Brunni> Je n'ai jamais dit le contraire, moi aussi j'ai débuté en BASIC, et j'ai expérimenté plein de trucs dans ce langage.
Mais s'est un peu bête de se mettre à développer des jeux importants et gourmands en BASIC, je trouve.

Perso j'ai bcp programmé en Basic avant de programmer en C (c assez marrant d'optimiser chaque octet et d'utiliser des moyens détournés pour utiliser au maximum les fonctions séquentielles qui évitent les boucles), mais bon une fois qu'on a pris goût à la rapidité et à la flexibilité du C (pas de listes imbriquées en Basic sans hack lourd ), c'est dur de s'y remettre... Ce que je trouve frustrant aussi, c'est de se dire que telle routine est lente non pas pour des raisons profondes (difficulté physique à réaliser, par exemple), mais juste parce qu'un programmeur de TI n'a pas eu le temps de faire un petit copier-coller en plus... Evidemment on peut se dire que l'important n'est pas la vitesse, ce qui est vrai; mais on est quand même vaguement obligé de se limiter à des algos de complexité très faible : un algo qui fait n^2 additions ne tourne à 1 fps que pour n<=10, c vraiment dommage. En tout cas, on finit par se dire au bout d'un certain temps qu'on a envie de passer à qqch de plus puissant dans lequel on puisse avoir enfin des algos en O(n^2) vraiment exploitables avec n=100...

Mais c'est vrai qu'il suffirait de peu de choses (interpréteur plus rapide, portée des variables mieux définie et qques primitives en plus) pour lui redonner une seconde jeunesse Si je continuais à programmer sur TI, je pense que je continuerais surtout GT-Basic. Mais j'ai un peu la flemme, et ce que j'ai fait jusqu'à maintenant concerne surtout la structure de l'interpréteur et qques routines-clé (gestion du tas, boucle principale de l'interpréteur, format du bytecode, extensions de langage [nouvelles structures de données, nouvelles fonctions, nouvelles syntaxes]), donc c pas vraiment assez consistant pour que qqun d'autre le reprenne (à moins d'être vraiment _très_ motivé, mais ça m'étonnerait).

Sasume
: Vertyos> C'est vrai que je descends souvent le BASIC dans mes posts.

C'est pas véritablement ça le problème, c'est juste que tu ne fais "que" le descendre, sans donner le moindre argument. Je me met à la place de ceux qui proposent leur programme et qui voient tes posts... À leur place, honnêtement, je t'aurais déjà smashé depuis longtemps

mais justement, le BASIC c'est très bien pour des petits
programmes (les seuls gros programmes pour lesquels je vois une utilité à ce qu'ils soient codés en BASIC sur TI sont les progs de math), mais pas pour des gros jeux. On se retrouve après avec des tonnes de fichiers sur la calc et un jeux trop lent.

Ça dépend. Il n'est pas question de "gros" jeux, mais de jeux avec beaucoup de graphismes, ce qui n'est pas la même chose. Par exemple, un RPG peut être considéré comme un gros jeu, et logiquement ce n'est pas la partie graphisme qui doit faire son interet (c'est pê pour ça qu'il n'existe quasiment aucun bon rpg sur Ti, d'ailleurs). Il n'existe aucun exemple à ce que je dis, à ma connaissance, mais il est parfaitement possible d'avoir des trucs exploitables en Ti-Basic, le problème vient de la difficulté à les programmer.