1

J'avais trouvé ça il y a quelques années mais je n'ai pas testé si c'était correct. Il s'agit à priori du format des fichiers GFA 3.
Un volontaire pour nous faire un éditeur moderne ?

http://members.aol.com/vbdis/GFAFormat.htm
avatar
De nouveaux jeux pour vos vieilles consoles ? En 2024 ?
https://yastuna-games.com

2


C'est sympa de publié un tel truc, cela peut ètre très arrangeant pour certaines choses, mais j'ai peur que personne n'ai envie de faire un autre éditeur.

On c'est tous attaché a la double barre en haut de l'écran, c'est de la nostalgie mais c'est cela le GFA ! cela pourrait ètre interressant d'écrire un éditeur moderne pour pouvoir utilisé l'éditeur en 896 par 440 sur un Falcon c'est sur mais un éditeur est un gros boulot !!


GT Turbo wink
avatar
Accrochez vous ca va être Cerebral !!

3

J'ai un util (que j'ai pas testé encore) qui permet de convertir un LST en GFA, en plus il est capable de charger automatiquement les inlines si les fichiers ont le meme nom que les variables, donc "yaurait plus qu'a" ajouter ca et le compilateur dans un editeur de fichier pour faire un IDE GFA !
Mefiez vous du Dr H qui sommeil en moi !
Muhahahahahahahahaha !
Muuuuhahaha...kof...kof...hahaha !

4

En fait, ce ne serait pas l'éditeur le plus gros boulot (en récupérant un éditeur existant pour lui faire mouliner du GFA, ça doit pouvoir se faire), mais ce qui me manquerait, ce serait effectivement l'interpréteur... je me vois mal compiler à chaque modif, autant revenir au C.
avatar
De nouveaux jeux pour vos vieilles consoles ? En 2024 ?
https://yastuna-games.com

5


Pendant un moment, j'ai réfléchi pour écrire un éditeur je voulais voir pour écrire mon propre assembleur, mais rien que la gestion de la mémoire a arrété tout mes espoirs donc je vais profité de ce poste pour voir si quelqu'un aurait une idée.

Pour faire bref, nous réservons pour le source un bloc de N kilo pour stocké l'ascii, mais par exemple si on veut inséré un caractère, faudrait décalé tout le source d'un caractère et quand cela fait plusieurs milliers de ligne imaginez l'attente !! Une gestion ligne par ligne avec bloc mémoires chainées, imaginez le nombre de bloc !!


Est ce que quelqu'un aurai une idée intelligente ?


GT Turbo happy
avatar
Accrochez vous ca va être Cerebral !!

6

Eine schone AVL baum, meine liebe ! Ich glaube das MString library muss dieses arbeit ganz klar machen...

Some links to help you my dear :

http://mstring.sourceforge.net/
http://www.niksula.cs.hut.fi/~tik76122/arkisto/dsaa_c2e/files.html
http://www.codeproject.com/cpp/avltree.asp

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

7

<b><font color=#FF0000>Petit test à la con</font></b>
Autre test à la con
%3c%66%6f%6e%74%20%63%6f%6c%6f%72%3d%23FF0000%3eVraiment très con là%3c%2f%66%6f%6e%74%3e
<
<h6><</h6>[font color=#FF0000]Test[/font]
[16]Test[/16]

Bon, on fout où les tags HTML ? Et comment on réduite l'espace entre les lignes à l'affichage ?

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

8

Kochise :
Eine schone AVL baum, meine liebe ! Ich glaube das MString library muss dieses arbeit ganz klar machen...

Some links to help you my dear :

http://mstring.sourceforge.net/
http://www.niksula.cs.hut.fi/~tik76122/arkisto/dsaa_c2e/files.html
http://www.codeproject.com/cpp/avltree.asp

Kochise



Je viens de survolé le premier lien mais sauf erreur de ma part, je penses que c'est du C, piti problème !!!

Je vais vite voir les autres liens, mais personne comme cela aurait une idée sympa ?

GT Talbot top
avatar
Accrochez vous ca va être Cerebral !!

9

Bah j'ai développé mon propre gestionnaire de mémoire pour mon OS. C'est basé sur celui de Doug Lea, puis je l'ai modifié pour y foutre un gestionnaire AVL. Ensuite je me suis inspiré de MString, bien que j'avais déjà commencé à implémenter un truc similaire sans en avoir connaissance au préalable.

Le C, c'est comme du GFA, la syntaxe est légerement différente :/ Tu verras que le C c'est vraiment pas bien méchant, tu veux un ch'tit cours rapide ? Là ? Entre nous ?

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

10

J'accepte le concours a trois conditions : tu attaques au C, moi j'attaques au 68xxx. La taille du fichier de sortie jouera pour determiné le gagnant ainsi que la vitesse d'éxécution !!


Oui je sais je triche a peine pas !!

Je connais un peu le C j'ai fait un ou deux essais, d'ailleurs la routine fractale en C posé dans cette section est de moi, c'est sur c'est du transcodage de la gfa version mais bon.

Le probleme quand je fais du C, est le temps de la compilation, je craques au bout de 4 secondes !! Les librairies qu'il faut déclaré, et alors les deux trucs cité plus haut :

Taille des fichiers en sortie (.PRG) alors la c'est du délire : la routine de fractale si je me souviens bien, fait 13 kilos en C pour 2 Kilos en ASM !!!

C'est pour cela qu'il vaut mieux programmé en asm sur une Jag (4Kilo de ram pour un processeur et 8 kilo pour l'autre !) et la vitesse d'execution il n'y a pas photo !!

Oui je sais, c'est plus facilement portable sur une autre machine, mais je pense que tout mon dégout pour ce langage vient du fait que je suis a la base un démomaker et la vitesse est un point crucial, et ce n'est pas le langage le plus rapide !!

Et surtout ce c...... de compilateur qui me prend la tete a cause des points virgules oubliés a la fin des instructions !!!

GT Turbo (assembleur !) cool
avatar
Accrochez vous ca va être Cerebral !!

11

Bwaaa, le C, si tu évites les raffinements du C++ et que tu codes en char*, c'est de l'assembleur avec une autre syntaxe, sans plus. En général, un executable C c'est gros, très très gros, je te l'accorde, mais on peut coder très très petit en C, regarde là : http://leonard.oxg.free.fr/demos/demos.html - REGARDE EN BAS : "Secret ?? Easy: "Ignore default library" ! :-) Simply remove them in your Visual options, and your EXE will be small !"

Pour les librairies, c'est chiant, c'est vrai, mais ça revient au même problème que les INLINE en GFA. Tu sais en général à quelle librairie appartient la fonction que tu utilises. Tu remonte au début de ton fichier C, et tu regarde si tu as bien inclus le fichier H de définition de la librairie (explication du pourquoi et de ce que c'est plus bas). Rien de sorcier :/

Actuellement je suis développeur en C++ chez Bayo sur des softs Windows. C'est pas la joie, mais ça marche (et putain, Windows mérite bien sa sale réputation) =sad Avant, j'ai travaillé dans l'embarqué (petits processeurs avec peu de RAM/ROM) chez Motorola (à Angers), Magneti Marelli (Chatellerault), Sagem (Pontoise), Johnson Controls (Pontoise)... Aaaahhhh, le pied, un processeur Nec 8 bits ou Hitachi 16 bits, et même ARM 32 bits, 4 Ko de RAM, 128 Ko de ROM, un émulateur, miam wink Ma production la plus connue est la gestion intégrale de l'affichage de la J77 de Renault, la nouvelle Modus wink Un bonheur à programmer, et c'est pourtant du C :/ Tout ce que j'ai pu coder dans l'embarqué, c'est du C :/

Un bon compilo te chie un code propre, rapide et léger. C'est les librairies qui prennent le plus puisque d'un coup tu embarques un jeu de 20 fonctions alors que tu n'en as besoin que d'une seule :/

Pour les points virgule, c'est une question d'habitude. Ca permet au parseur du compilateur de faire un travail plus efficace. Quand en GFA tu veux écrire plusieures instructions par ligne, tu les sépares par une virgule, PARFOIS. En C, c'est un point virgule, TOUJOURS ! Le pourquoi ? Simple :

En BASIC normal, tu as des numéros de ligne pour aider l'interpreteur à s'y retrouver.
EN GFA, pas de numéro de ligne mais un indentation automatique qui sert de structure.
En PASCAL, tu as les 'begin' et 'end;'
En C, les '{', les '}' pour comprendre la structure et les ';' pour identifier les instructions.

Un programme BASIC est simple et tu as en général une ligne pas instruction. Un programme PASCAL, bien qu'indenté pareil que le GFA (et comme le GFA sans numéro de ligne) apparait des 'marqueurs' de début et fin de fonction. Et le C c'est pareil, puisqu'un programme C peut être écrit sur une seule et même ligne.

Pour que le compilo puisse s'y retrouver dans ce fichier texte brut (qui est souvent écrit sous VI sur UNIX), il lui faut des marques claires pour faire son boulot, d'où tous ces signes cabalistiques dont nous n'avons pas besoin en GFA, puisque l'éditeur s'occupe déjà de l'indentation et de la correction syntaxique.

.../...
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

12

Prennons enfin un petit cour pour ceux qui n'y connaissent rien. A savoir concernant le type des variables...

En ASM :

8 bits : BYTE.b
16 bits : WORD.w
32 bits : LONG.l
flottant : FPU.x
chaîne de caractères : N'existe pas

En GFA :

8 bits : N'existe pas
16 bits : suffixe!
32 bits : suffixe%
flottant : sanssuffixe
chaîne de caractères : suffixe$

Et en C :

8 bits : char
16 bits : short
32 bits : int
flottant : float (32 bits) ou double (64 bits)
chaîne de caractères : N'existe pas (comme en assembleur)

Le C, c'est donc vraiment comme l'assembleur, il faut traiter les chaines de caractères à la main, ou utiliser les fonctions d'une librairie comme 'stdio'. Sur ATARI, ces librairies sont en ROM et connues sous le nom de GEMDOS/BIOS/XBIOS smile

Comparons enfin un programme en GFA, et un en C :

truc%=2            ! Un LONG sur 32 bits qui vaut 2
trac=FN Calcul(truc%)  ! On récupère un flottant sur 6 octets (format GFA) qui vaut 4
GOSUB Affiche(trac)  ! On affiche la variable 'trac'
~INP(2)      ! On attend une touche
EXIT    ! On se barre

FUNCTION Calcul(var%)
  RETURN (var% * 2)
ENDFUNC

PROCEDURE Affiche(flottant)
  PRINT "Résultat = ";flottant
RETURN


La même chose en C :

/* Comme le compilo est à une passe, on définie la gueule des fonctions pour qu'elles soient connues dans 'main */
float Calcul(int); /* Ce n'est pas les fonctions, juste la définition du prototype */
void Affiche(float); /* Avec ça le compilot pourra vérifier si on n'a pas fait une faute de syntaxe */

int main(void) /* Le programme commence TOUJOURS dans la fonction qui s'appelle 'main' */
{ /* Les accolades servent au compilateur à connaitre la hiérarchie des fonctions, puisqu'il n'y à pas d'indentation automatique */
  int truc = 2; /* On définie un variable locale et on l'initialise à 2 */
  float trac = Calcul(truc); /* Un flottant sur 4 octets, et on l'initialise avec le résultat du calcul */

  Affiche(trac); /* Affiche le résultat */

  getch(); /* Equivalent de VOID INP(2), on attend un caractère du clavier mais sans utiliser la valeur retournée par getch() */

  return 0;  /* Si on arrive là, le programme se termine, on renvoie un code d'erreur, comme pour PTERM */
}

float Calcul(int var)
{
  return (var * 2); /* Pas plus compliqué que ça */
}

void Affiche(float flottant)
{
  printf("Résultat = %ld\r\n", flottant); /* Affiche le résultat en tant que flottant, \r\n c'est CRLF, $0D$0A en assembleur */
}


Alors, c'est pas si dur wink Pour comprendre l'intéret de la définition des prototypes des fonctions, il faut savoir que j'aurais pu écrire le même programme comme ça :

/* On écrit directement les fonctions avant le 'main', comme ça leur format d'entrée/sorie sera connu dans 'main */
float Calcul(int var)
{
  return (var * 2); /* Pas plus compliqué que ça */
}

void Affiche(float flottant)
{
  printf("Résultat = %ld\r\n", flottant); /* Affiche le résultat en tant que flottant */
}

int main(void) /* Le programme commence TOUJOURS dans la fonction qui s'appelle 'main' */
{ /* Les accolades servent au compilateur à connaitre la hiérarchie des fonctions, puisqu'il n'y à pas d'indentation automatique */
  int truc = 2; /* On définie un variable locale et on l'initialise à 2 */
  float trac = Calcul(truc); /* Un flottant sur 4 octets, et on l'initialise avec le résultat du calcul */

  Affiche(trac); /* Affiche le résultat */

  getch(); /* Equivalent de VOID INP(2), on attend un caractère du clavier mais sans utiliser la valeur retournée par getch() */

  return 0;  /* Si on arrive là, le programme se termine, on renvoie un code d'erreur, comme pour PTERM */
}


Dans ce cas, il faut faire bien attention à l'ordre d'écriture des fonctions, ce qui peut poser problèmes. Le mieux est donc la première version. La définition des prototype de fonction peuvent etres mises dans un autres fichier, le fameux fichier H (Header, entête en français dans le texte). Ca donnerait ça :

--- Test.h ---

/* Fichier de définition */
float Calcul(int); /* Ce n'est pas les fonctions, juste la définition du prototype */
void Affiche(float); /* Avec ça le compilot pourra vérifier si on n'a pas fait une faute de syntaxe */


--- Test.c ---

#include "Test.h"

int main(void) /* Le programme commence TOUJOURS dans la fonction qui s'appelle 'main' */
{ /* Les accolades servent au compilateur à connaitre la hiérarchie des fonctions, puisqu'il n'y à pas d'indentation automatique */
  int truc = 2; /* On définie un variable locale et on l'initialise à 2 */
  float trac = Calcul(truc); /* Un flottant sur 4 octets, et on l'initialise avec le résultat du calcul */

  Affiche(trac); /* Affiche le résultat */

  getch(); /* Equivalent de VOID INP(2), on attend un caractère du clavier mais sans utiliser la valeur retournée par getch() */

  return 0;  /* Si on arrive là, le programme se termine, on renvoie un code d'erreur, comme pour PTERM */
}

float Calcul(int var)
{
  return (var * 2); /* Pas plus compliqué que ça */
}

void Affiche(float flottant)
{
  printf("Résultat = %ld\r\n", flottant); /* Affiche le résultat en tant que flottant */
}


L'intéret, c'est quand on fait un programme coupé en plusieurs fichiers, on inclus les headers au début du fichier C qui utilise les fonctions, et on ajoute le fichier C au makefile (toute une science, le makefile). Imaginons que j'ai une grosse fonction dans un fichier externe, ça pourrait donner ça :

--- Einstein.h ---

/* Définition de la fonction Einstein */
float Einstein(float super); /* On peut mettre un nom ici pour aider à la compréhension, mais le compilo à juste besoin du type de la variable */


--- Einstein.c ---

/* La fonction e=mc2 */
float Einstein(float machin) /* Le nom de la variable est important ICI, pas dans la définition. Mais le type doit bien correspondre à la définition */
{
  return machin*machin;
}


Pour l'utiliser dans le code, voici comment ça se passerait avec le nouveau 'main' :

--- Test2.c ---

#include "Test.h"
#include "Einstein.h" /* Bah oui, faut pas l'oublier, on ajoute une fonction */

int main(void) /* Le programme commence TOUJOURS dans la fonction qui s'appelle 'main' */
{ /* Les accolades servent au compilateur à connaitre la hiérarchie des fonctions, puisqu'il n'y à pas d'indentation automatique */
  int truc = 2; /* On définie un variable locale et on l'initialise à 2 */
  float trac = Calcul(truc); /* Un flottant sur 4 octets, et on l'initialise avec le résultat du calcul */

  Affiche(Einstein(trac)); /* Affiche la valeur Einstein du résultat de Calcul */

  getch(); /* Equivalent de VOID INP(2), on attend un caractère du clavier mais sans utiliser la valeur retournée par getch() */

  return 0;  /* Si on arrive là, le programme se termine, on renvoie un code d'erreur, comme pour PTERM */
}


Quand tu compile, voilà ce que voit le compilateur avec le pseudo makefile suivant :

--- makefile ---

compile : Test.c -> Test.o
compile : Einstein.c -> Einstein.o
link : Test.o Einstein.o -> Programme.prg


--- COMPILER ---

/* Fichier de définition */
float Calcul(int); /* Ce n'est pas les fonctions, juste la définition du prototype */
void Affiche(float); /* Avec ça le compilot pourra vérifier si on n'a pas fait une faute de syntaxe */
/* Définition de la fonction Einstein */
float Einstein(float super); /* On peut mettre un nom ici pour aider à la compréhension, mais le compilo à juste besoin du type de la variable */

int main(void) /* Le programme commence TOUJOURS dans la fonction qui s'appelle 'main' */
{ /* Les accolades servent au compilateur à connaitre la hiérarchie des fonctions, puisqu'il n'y à pas d'indentation automatique */
  int truc = 2; /* On définie un variable locale et on l'initialise à 2 */
  float trac = Calcul(truc); /* Un flottant sur 4 octets, et on l'initialise avec le résultat du calcul */

  Affiche(Einstein(trac)); /* Affiche la valeur Einstein du résultat de Calcul */

  getch(); /* Equivalent de VOID INP(2), on attend un caractère du clavier mais sans utiliser la valeur retournée par getch() */

  return 0;  /* Si on arrive là, le programme se termine, on renvoie un code d'erreur, comme pour PTERM */
}
float Calcul(int var)
{
  return (var * 2); /* Pas plus compliqué que ça */
}

void Affiche(float flottant)
{
  printf("Résultat = %ld\r\n", flottant); /* Affiche le résultat en tant que flottant */
}

/* La fonction e=mc2 */
float Einstein(float machin) /* Le nom de la variable est important ICI, pas dans la définition. Mais le type doit bien correspondre à la définition */
{
  return machin*machin;
}


Voilà, en mémoire il a 'recomposé' un seul fichier à compiler. En fait c'est pas vraiment comme ça que ça marche, puisqu'il fait des fichiers objet (les .O) qui contiennent en fait le code compilé contenu dans le fichier C définit dans le makefile. Ce code objet est un code non relogeable dont l'adresse d'origine est 0 (en assembleur, c'est ORG $0).

Le processus de linkage, c'est foutre dans un fichier PRG des deux fichiers O en modifiant les adresses de relocation. C'est grosso modo ce que mais l'ATARI quand il charge un programme en mémoire, le PRG à toutes ses adresses qui commencent à partir de 0, et l'ATARI les corrige par rapport à l'adresse où il a mis le programme.

Le linkeur fait ça avec les O (ou fichier OBJ) pour générer un deuxième fichier PRG. Le premier fichier O dans le PRG ne commencera pas à 0, mais après le header. Le fichier O suivant suivra...

Le fichier H sert à savoir par exemple le type de donnée que retourne la fonction Einstein du fichier Einstein.o. Comme ça vous pouvez juste diffuser le fichier O et H. Imaginons que la fonction Einstein est une fonction commerciale que vous avez achetez et dont vous n'avez pas le code source. Vous avez donc le fichier H et O, vous avez juste à modifier le makefile comme suit :

--- makefile ---

compile : Test.c -> Test.o
link : Test.o Einstein.o -> Programme.prg


Pas de Einstein.c à compiler, vu que vous l'avez déjà en fichier binaire. Par contre pour vérifier la syntaxe, le compilo à besoin du H inclus dans le fichier Test.c. Ensuite, il n'y a qu'à assembler les fichiers binaires ensembles smile

Alors, en GFA, c'est le même principe avec MENUX.PRG qui utilise GFA_BCOM.PRG (le compilateur), puis GL.PRG (le linkeur)... C'est donc pareil, c'est 'juste' une question de syntaxe. Dis toi quand même que comme le C c'est juste une autre forme d'assembleur, tu feras plus de choses en C qu'en GFA (sans à utiliser de CAR et POKE). Essaye, c'est chiant à mettre le système de développement en route, mais après c'est bonheur wink

Sur PC, Visual C++ est très bien, puisque le makefile est généré automatiquement. Ensuite le débug est facile puisque tu fais directement du pas-à-pas sur le code source en C avec le contenu de chaque variable. Mais tu peux aussi le faire au désassembleur wink

Sur ATARI, c'est vrai que comme il n'y a pas de débuggeur visuel, on est obligé de débugger en assembleur. Et comme il n'y a pas de correspondance visuelle avec le code original et donc que l'on ne sait pas où l'on est, c'est pas évident. Pour ça, il reste le nom des variables et des fonctions qui apparaissent sous Adebug/MonST, et y'a les fichiers de décompilation qui mixent le code source en C et l'ASM généré. Donc ça devient plus facile pour débugger.

Sinon, tu fais de la compilation conditionnelle et tu mets pleins de messages qui affichent le contenu de tes variables :

#define DEBUG

int main(void)
{
  int truc = 2;

#ifdef DEBUG
  printf("DEBUG : Avant Calcul, truc fait = %d\r\n", truc);
#endif

  float trac = Calcul(truc);

#ifdef DEBUG
  printf("DEBUG : Après Calcul, trac fait = %ld", trac);
#endif

  Affiche(Einstein(trac)); /* Affiche la valeur Einstein du résultat de Calcul */
  getch(); /* Equivalent de VOID INP(2), on attend un caractère du clavier mais sans utiliser la valeur retournée par getch() */

  return 0;
}


En compilant ça, tu auras deux lignes de texte en plus :

DEBUG : Avant Calcul, truc fait = 2
DEBUG : près Calcul, trac fait = 4
Résultat = 16


Allez hop, vas-y, fait ton premier test en C, sans inclure de librairie si tu n'en à pas besoin wink

Kochise

PS : http://software.audela.free.fr/exten3.htm
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

13

Y'en a qui se sont bien gavé cet aprem smile
---------------------------------
Cooper / Paradize
STf/Mega ST/STe/F030/Lynx
---------------------------------
mes prods lynx : http://atarithemes.chez-alice.fr/lynx/index.php
mes prods ST/Falcon : http://paradize.atari.org

14

En tout cas on peut pas dire que Kochise se fou de nous quand il veut expliquer un truc, chapeau !

15

Bon, à l'occasion, je vais convertir un de mes vieux programme du GFA vers le C, et faire la version Windows par la même occasion wink C'était un générateur de montagne fractale parus dans ST Magazine n°53 d'été 91 que j'avais repris et considérablement modifié, même que j'avais écrit une version qui générait des height-field pour NeoN GraphiX. Mais la taille des fichiers générés prohibait toute utilisation, même sur une machine de 14 Mo :/

Depuis j'ai amélioré le procédé en faisant une optimisation de mesh avec un roaming adaptatif pas dégueux (une sorte de mipmapping sur les mesh, c'est à dire moins de facettes en fonction de la distance et de l'angle qu'elles font entre elles)... En tous les cas, voici un exemple :

PICA.PNG

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

16

Tiens, ça me fait penser à PowerMonger cette jolie map...

trivil epee

Sonja (réveillé son neurone chargé des souvenirs) hehe

17

Ah oui, j'ai oublié, vous pouvez déjà jouer avec la version 7 que j'ai mise à disposition sur mon site. Je vous ai mis les sources GFA et LST wink La version C va suivre...

http://dkoch.9online.fr/framogen/

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

18

cool

Merci pour la précise démonstration, ensuite félicitations pour ton palmares, mais tu pourras faire la démonstration que tu veux, l'asm restera toujours plus petit et rapide !!


Regarde rien que la routine de fractal, la difference de vitesse est flagrante et encore mieux, la version asm utilise le mode étendu du 68881/2, cela signifie que le calcul est plus précis mais théoriquement plus lent, et hors !!! La version C compilé pour du 68882 coté précision je crois bien que c'est du simple, enfin meme si c'était du double, cela va toujours plus vite que le mode étendu !!

Je sais c'est un peu limite mais essaie de codé un fullscreen en boosecteur en C !!! Désolé !!!


GT Turbo (asm lover !) wink
avatar
Accrochez vous ca va être Cerebral !!

19

Le C, c'est donc vraiment comme l'assembleur, il faut traiter les chaines de caractères à la main, ou utiliser les fonctions d'une librairie comme 'stdio'. Sur ATARI, ces librairies sont en ROM et connues sous le nom de GEMDOS/BIOS/XBIOS


Ouch petite erreur je penses ! il n'y a aucune fonction en rom pour le traitement de chaines de caracteres ! A part l'impression d'une sur un péripherique !!

Toutes les fonctions pour chaines de caracteres sont a codé a la main, j'ai écrit toutes mes fonctions moi meme (Recherche d'une chaine dans une autre, copie, etc....)

En C beaucoup de ces fonctions existe déjà, ensuite le C ne ressemble pas tellement a l'asm, pour tracé en cercle avec la VDI en C tu utilises la fonction GEM, en asm faut empilant tout a la main dans les tableaux, exemple :

vs_clip(x,y,x1,y1,flag) (C'est méga faut mais c'est un exemple ) Ligne qui
est censé clippé un carré de coordonnées x,y,x1,y1

En asm on se retrouverait avec un truc comme cela:

lea control,a0
move.w #109,(a0)+
move.w #2,(a0)+

lea intin,a0
move.w x,(a0)+
move.w y,(a0)+
move.w x1,(a0)+
move.w y1,(a0)+

jsr call_vdi

Surtout n'essayez pas ces exemples, ce ne sont que de petits bout de code de tete mais c'est pour situé la chose. Kochise tu ne peux pas dire que du C ressemble beaucoup a de l'asm !!! Quand tu vois cela !!

Beaucoup de respect pour toi, Kochise, tu connais très bien ton langage, la démonstration fut impressionante.

Mais en fin de compte après cette joute amical je ne penses qu'il n'y a qu'un truc a dire : on a un paquet de langage assez important, de toutes les sortes, on peut choisir donc faites votre choix et programmez !!!

Amicalement votre,
GT Turbo ( calin )
avatar
Accrochez vous ca va être Cerebral !!

20

Quand je disais que le C c'est comme de l'assembleur, c'est une fois compilé. Tu retrouves assez facilement ton code C quand tu désassembles ton programme. Tu le trouve moins bien quand c'est du C++ compilé. Encore moins quand c'est du GFA.

Je disais 'juste' que le C est une autre forme d'écriture de l'assembleur, puisque les instructions C sont presque transformé tel quel en leur équivalent ASM. Le C n'ajoute 'que' la structuration facile et la gestion des appel aux sous-fonctions. Sinon en ASM, essaye les macro rs, c'est pareil...

Le code SOURCE en C ne ressemble pas à l'ASM, mais le code C compilé si. Tiens, je vais tacher le faire la version ASM et la version C de FRAMOGEN7 sur ATARI. Courant de la semaine, hein...

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

21


Je me charges de faire la version asm de Framogen si cela te convient, cela sera plus juste pour comparé !!



GT Turbo ( octopus )
avatar
Accrochez vous ca va être Cerebral !!

22

Naaaaan, j'la fait (je sait coder en ASM quand même) smile Mais code ta version, on compare le style ensuite wink

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

23

Kochise :
Naaaaan, j'la fait (je sait coder en ASM quand même) smile Mais code ta version, on compare le style ensuite wink

Kochise



Je penses bien que tu c'est codé, la dessus j'ai aucun doute rassure toi.
Mon style a moi c'est gros bourrin, tu pourras jamais comparé ta routine avec la mienne !!! Désolé !! J'ai déjà du mal a comprendre ce que je code moi meme !!! confus


GT Une grosse brute !!! cool
avatar
Accrochez vous ca va être Cerebral !!

24

OK, OK. Attention, je code pas vite. Je ne code pas beaucoup non plus wink D'ailleurs moins j'en fait mieux je me porte... Mais pour le sport, pourquoi pas ! Dire que mon FRAMOGEN date de 2001 :/ Eeeek, reprendre du vieux code !

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

25

Quelques liens vers des copilos C sur ATARI. Je vais en utiliser un pour mes exemples de programmation. Ce ne sera pas GCC, trop complexe à mettre en oeuvre pour une simple initiation, et trop lourd (le pack complet fait 8.91 Mo). Je vous dirais quel package j'utiliserais :

http://www.logicalvue.com/atari/software/prog/LC56.ZIP (1.8 Mo)
http://www.reservoir-gods.com/CODE/PURE_C.ZIP (1.1 Mo)
ftp://ftp.lip6.fr/pub/atari/Programming/sozbin15.zoo (231 Ko)
ftp://ftp.lip6.fr/pub/atari/Programming/sozlib15.zoo (560 Ko)
ftp://ftp.lip6.fr/pub/atari/Programming/sozuti09.zoo (203 Ko)
http://www.zhell.co.uk/streview/strev_17.zip (410 Ko) http://www.zhell.co.uk/streview.html

Je vais éviter d'utiliser le copro, histoire de pouvoir comparer entre les différentes versions. Pour l'instant, les routines GFA sont en LONG (à l'origine en REAL), donc il n'y aurait pas de problème à une conversion C/ASM wink J'me lance pas trop ce soir, la flème (grosse maladie ça) !

Kochise

PS : P'tit bonus pour GT Gouraud, un p'tit prog de mon cru en ASM - ATTENTION : Falcon030 et FPU indispensables - : http://yn1.free.fr/up/GOURAUD5.PRG
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

26

Jolie code Kochise,

Par contre ma version asm de framogen ne sera pas écrite tant que Poong ne sera pas fini, donc prend ton temps !!!

Juste une question Kochise, quand tu veux intégré une routine C dans du GFA tu fais comment ? Parce que sauf erreur de ma part, le pc relatif n'est pas une option du C.

J'ai vite survolé framogen, code ultra propre par contre un truc m'a tilté, pour récupéré la résol, un appel a la ligne A. A l'époque on disait qu'il fallait évité la ligne A parce on était pas sur du support sur les machines a venir, c'est sur qu'actuellement la question ne se pose plus. Tu peux récupéré la taille de l'écran par la VDI alors pourquoi cet appel ?

GT Turbo happy
avatar
Accrochez vous ca va être Cerebral !!

27

Pour faire simple wink Rapide et simple... Le VDI utilise la LineA quand elmle est disponible, pour quelques fonctions. Ca me faisait chier de définir des tableaux et pomper la VDI juste pour deux infos wink Je t'avais prévenu, ch'us un branleur en puissance... Remarque, la version 8 publique qui sera donc écrite en GFA/ASM/C récupèrera la réso par VDI, vu qu'appeler la LineA par le C c'est pas vraiment pratique (même astuce que sur GFA, mais plus chiadé).

En plus je vais intégrer quelques routines graphiques comme les polygones et lignes, ceci pour avoir des routines similaires en GFA/ASM/C (parce que les routines graphiques du GFA, caca). J'évite le VDI, puisqu'il faut définir un viewport, et là aussi ça me fait chier, surtout quand je suis en plein écran dans une session non GEM (TOS quoi).

Ca me permettra d'ailleurs d'avoir des routines graphiques qui gèrent le 256 couleurs en GFA, et je pourrait donc générer depuis la version 8 des maps ombrés comme sur ma page ouiab (générés à partir d'une version spéciale de framogen en TGA).

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

28

J'au testé le cube sur un copro à 32 et c'est fluide smile
Par contre l'ombrage gouraud est bien mais sans plus, c'est en planar ou en chunky?

29

Ben tu sais, avec 'seulement' 32 niveau de bleu, je ne pouvait pas faire demiracles, vu que c'est du planar wink Mais je vais modifier ça en dithering (error diffusion) histoire que ça passe mieux. Tu ne verras pas les pixels à cause de la rotation, ce sera trop rapide pour l'oeil...

Je nettoie les sources, je comment un peu le merdier, et je diffuse tout ça sur mon site wink

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

30

Et paufine ta routine d'initialisation, car en quittant la démo j'ai eu un beau reset sur mon rapace CT60 smile
Sinon tu veux pas t'essayer au mode 16 Bits?