GFA vs STOS - Page 1

Alut !
encore une question
mieux vaut programmer en GFA ou en STOS ?

cela depend de ce que tu veux faire le STOS etait plutôt pour les jeux avec pas mal de chose pour creer des spites et les animer.

Je ne connais pas bien le STOS mais tu trouveras davantage de gens qui codent en GFA qu'en STOS. Il y a également bien plus de sources dispos et de docs en ligne. En plus le STOS a des problèmes de compatibilité entre les machines.

Le GFA est encore d'actualité car il existe de nouvelles versions de l'éditeur, du compilateur et de l'éditeur de liens. Ce ne sont pas des versions officielles mais des réécritures ou des patchs d'anciens programmes. Plus d'infos ici : http://www.bright.net/~gfabasic/

Le STOS utilise son propre environnement graphique, et faire autre chose que du 'STOS' avec (genre du GEM) n'est pas vraiment conseillé. Tu trouveras tout ça ici : http://www.clickteam.com/frn/downloadcenter.php?i=114

Concernant le GFA, c'est un bon BASIC qui prend le programmeur débuttant par la main (indentation automatique) mais ce qu'il produit est très 'sale' (d'où source d'incompatibilités sur TT et Falcon). Strider à bien rappelé l'adresse la plus à jour, soit : http://www.bright.net/~gfabasic/

Sinon sur Atari y'avais aussi le BASIC livré avec la machine, une sombre daube (comme tous les softs livrés d'office par Atari) sauf éventuellement l'Omikron BASIC diffusé en partenariat avec Atari France au début des années 90. L'Omikron BASIC à eu beaucoup de succés de part sa puissance et son respect du GEM. Je te le conseille plutôt que le GFA qui nécessite pas mal de bricolage pour obtenir un résultat correct, par contre il n'a pas évolué coté respect des 68030 : http://www.berkhan.com/atari/atari_e.htm (pour info il existe aussi pour Mac, alorsque le GFA existe aussi sur PC). Petite doc pour la version livrée avec les Atari : http://www.jchr.be/inf/ata/omikron.htm

Enfin il reste le Megamax Modula-2 (le Modula-2 est un langage multiplateforme plus ou moins dérivé du Pascal, dont le GFA s'inspire pour les PROCEDURE et FUNCTION). Tu n'auras aucun mal à trouver des exemples en Modula-2, ni des interpreteurs/compilateurs pour PC/Mac/Amiga/... De nombreux programmes ont étés fait en Modula-2 sur Atari, des drivers, et même le jeu Oxyd ! Tu trouveras ça là : http://www.tempel.org/files-e.html ! Attention, le Modula-2 est utilisé dans certains calcul distribués (c'est une étape dans l'évolution des langages fonctionnels), il supporte le concept objet, etc... Voir ici pour démarrer : http://en.wikipedia.org/wiki/Modula-2

Mais bien évidement, ma préférence ultime va au C, qui en dehors de sa syntaxe étrange à prime abord, est un mélange de BASIC et d'assembleur (si si si !) et est réutilisable sur toutes les autres plateformes ! Pour peu qu'on soit un bon programmeur et qu'on arrive à correctement différencier les couches de haut niveau de celles de bas niveau, il ne reste que ces dernières à ré-écrire quand on porte sur une autre architechture...

Kochise

PS : Vu que l'environnement Modula-2 est dispo, gratos, avec source et docs, utilise plutôt ça si tu veux utiliser autre chose que le C sur Atari. Tu auras ensuite beaucoup de facilité à franchir le pas le moment venu...

Parmi tout ceux que tu viens de citer, quel est le language le plus rapide (en compilé) pour la game sft/e ?

Dépend des librairies et du programmeur. En GFA on peut s'amuser à faire des CARD (d'où des démo avec raster et cie). Avec le STOS tu peux inclure tes routines assembleur par TRAP. L'Omikron dispose de très bonne librairies, le Modula-2 est puissant et tu peux faire de l'assembleur en inline. De dire lequel est le plus rapide out-of-the-box, ce n'est pas possible... Et puis le plus rapide pour quoi, faire du GEM ? Du TOS ?

Kochise

templeton (./5) :
Parmi tout ceux que tu viens de citer, quel est le language le plus rapide (en compilé) pour la game sft/e ?

L'assembleur !!



GT

Disons si j'avais à choisir, ce serait le Modula-2, qui permet de faire des outils systèmes et des débuggeur (voir la page que j'ai donné, TempleMon)... On peut trouver des émulateur écrits en Modula-2, des systèmes d'exploitation, ... Je vous ai mis quelques sources Modula-2 de Meinolf Schneider (l'auteur d'Oxyd) pour que vous puissiez voir ce que l'on peut faire avec (haute résolution uniquement) http://david.koch.9online.fr/GAGS.ZIP (39 KiB). Essayez donc de faire ça en STOS, GFA ou Omikron, pour voir...

Kochise

PS : D'autres compilateurs Modula-2 http://www.thefreecountry.com/compilers/modula2.shtml (à défaut de Modula-3 qui n'a pas été porté sur Atari) et sources http://www.modulaware.com/m2wr/?ring=modula2&id=10&m=hub ( http://www.vectorbd.com/bfd/pascal/ )

PS2 : GT, faut savoir grandir un peu, l'assembleur est peut être rapide, mais tu atteinds vite ses limites en matières de gestion de données...

Kochise (./8) :
PS2 : GT, faut savoir grandir un peu, l'assembleur est peut être rapide, mais tu atteinds vite ses limites en matières de gestion de données...

Question quelles limites ? Ne pas oublier que l'assembleur n'a pas de limites !!

GT

Théoriquement il n'en a pas, alors dit moi pourquoi il existe tant de langages différents qui apportent un ch'tit plus par rapport à l'assembleur ? Essaye de faire de l'objet en assembleur (polymorphisme, héritage et cie) pour voir... Essaye aussi de faire un système distribué et concurrent, en assembleur ! Bien du plaisir...

Kochise

Kochise (./10) :
Théoriquement il n'en a pas, alors dit moi pourquoi il existe tant de langages différents qui apportent un ch'tit plus par rapport à l'assembleur ? Essaye de faire de l'objet en assembleur (polymorphisme, héritage et cie) pour voir... Essaye aussi de faire un système distribué et concurrent, en assembleur ! Bien du plaisir...

Kochise

Pas théoriquement, pratiquement, ce sont rien que des routines de traitement de données, que tu peux écrire en assembleur aussi. Beaucoup de personnes pensent que les structures sont l'apanage du C. En assembleur les structures sont tout a fait possibles aussi.

Quand j'ai commencé a écrire Opale (Macro langage de commandes) pour les ennemis (Pour Project Apocalypse), je me suis apercu d'une chose, pour que les ennemis puissent réagir face a tes mouvements, j'avais des tests qui dit test dit CCR, au début pour faire les essais, je pensais écrire en Gfa, et je me suis apercu que cela aurait été plus dur, car j'aurais du écrire toute une gestion du reg CCR alors qu'en asm je le recopies juste et c'est tout, et pour faire le test un CMP suffit largement. Dans n'importe quel autre langage dit 'évolué' j'aurais du écrire des choses qui existent en inhérent au sein de n'importe qu'elle microprocesseur. L'informatique est la pour le traitement de données, c'est la base première de cet outil. et l'assembleur existait bien avant le C et traitait déjà des données, les autres langages simplifient simplement certain traitements c'est tout

GT

Bon, mauvaise pioche, on va pas polémiquer, tu ne connais volontairement pas les langages de haut niveau et tu ne sais donc pas ce qu'il peuvent apporter. Dis toi que si les programmeurs en général ne codent plus en assembleur (même des choses simples) c'est qu'il y a peut être une raison. Que si la Jaguar avait disposé d'un compilateur C/C++ à l'époque de sa sortie, c'est ce qu'aurait utilisé les programmeurs, et peut être qu'ils auraient pondus des jeux mieux foutus...

Kochise

Kochise (./12) :
Bon, mauvaise pioche, on va pas polémiquer, tu ne connais volontairement pas les langages de haut niveau

J'ai fait du Gfa pendant des années, j'ai essayer a plusieurs reprises le C, mais bon.

Kochise (./12) :
Que si la Jaguar avait disposé d'un compilateur C/C++ à l'époque de sa sortie, c'est ce qu'aurait utilisé les programmeurs, et peut être qu'ils auraient pondus des jeux mieux foutus...

Kochise

Oui avec un printf a 100 Kilos (Voire lib de SebRmv), c'est sur qu'on aurait pu jeter le Gpu avec sa ram de 4 Kilos et le Dsp avec sa ram de 8 Kilos, donc on aurait juste eu un 68000 a 13 Mhz pour afficher des sprites....

Bon comme tu as dit, on va pas re-polémiquer une x fois, donc promis j'arrete la !!

GT

Kochise (./12) :
Dis toi que si les programmeurs en général ne codent plus en assembleur (même des choses simples) c'est qu'il y a peut être une raison.

Pas une, plusieurs.

1) Coder dans un langage évolué réduit les temps de développement (hé oui, réinventer la roue, ça prend du temps) et simplifie certaines choses, si le langage a été bien conçu.

Mais aussi...

2) Ça demande moins de compétences de la part du programmeur pour obtenir quelque chose qui marche (note : je n'ai pas dit quelque chose de bon). Hé oui, s'il y a x fois plus de programmeurs C que de programmeurs assembleur, et y fois plus de programmeurs .NET que de programmeurs C, ce n'est pas un hasard, ce n'est pas que les gens deviennent plus intelligents et ce n'est pas parce que ces langages permettent faire du bon code sans réfléchir. D'ailleurs, parmi cette armada de codeurs, combien sont médiocres ? (pas tous, hein, ne me faites pas dire ce que j'ai pas dit)

3) Les processeurs sont devenus suffisamment puissants pour que l'"overhead" requis par les langages de haut niveau soit considéré comme acceptable.

Que si la Jaguar avait disposé d'un compilateur C/C++ à l'époque de sa sortie, c'est ce qu'aurait utilisé les programmeurs, et peut être qu'ils auraient pondus des jeux mieux foutus...

Mauvais pioche aussi, le DSP et le GPU de la Jaguar ne sont pas du tout adaptés à la programmation en langage de haut niveau (c'est même marqué dans le manuel ; d'ailleurs, conscients de leur erreur de stratégie, les concepteurs avaient prévu de modifier l'architecture pour que la Jaguar II soit "C-friendly").
Et pour avoir codé dessus, je peux te dire que pour exploiter vraiment ces processeurs (en tenant compte de toutes les limitations du pipelining), tu ne peux pas faire autrement que de concevoir tes algos en tenant compte des spécificités hardware dès le début (et c'est pas évident). Aucune chance que l'optimisateur d'un compilateur C arrive à dépatouiller ça tout seul comme un grand !

De toute façon, ça ne sert pas à grand-chose que vous débattiez, vu que vous ne parlez pas de la même chose ! GT est un codeur amateur sur une architecture fixe, dont le but est de tirer le maximum de la bécane (en plus, je le connais, sa façon de promouvoir l'assembleur n'est pas toujours à interpréter au premier degré, hein) ; les applications dont tu parles n'ont pas du tout les mêmes contraintes...

Allez, faites la paix, c'est Noël, quoi

Le DSP du Falcon030 ne se code pas en C, le 68030 oui. La Jaguar dispose d'un 68000 justement pour ça. Il 'suffit' d'écrire 'quelques' routines DSP et de lier la sauce au 68000... Bon après, que Atari nous ai habituer à nous filer qu'une moitié de puissance (regarde le Falcon030, bus 16 bits, 16 MHz alors que le reste était à 32 voire 40 MHz) est une chose, qu'ils aient récidivé dans la Jaguar en cadencant le truc à 13 MHz pour le 68000 (bus 16 bits) en est une autre...

Kochise

Kochise, Kochise, Kochise...

Je crois savoir que tu connais la Jaguar, tu dois savoir aussi que le 68000 n'a été intégré que pour aider les programmeurs à démarrer, en leur donnant un processeur qu'ils connaissaient bien... Pour citer l'un des concepteurs : « Le 68000 n'est là que pour gérer les manettes » (et encore, on peut très bien s'en passer).

Et le 68000 de la Jaguar n'apporte pas grand-chose, il gaspille tellement de cycles de bus qu'il est en général plus intéressant de le désactiver et de se contenter des autres processeurs.