Comment bien s'organiser pour programmer?

[Vicomte]

Voilà!
comme je débute (à mort) pour programmer en GFA j'aimerais savoir comment je dois m'organiser pour ne pas me mélanger les pinceaux!
je suppose que vous ne connaissez pas par coeur la programmation et que vous notez tous sur papier!
si vous avez des astuces cela m'aiderais grandement.
merci.

[leglod]

Salut, ca depand de ce que tu programme si c'est un utilitaire un jeu ou une demo .
Perso je n'ai jamais rien noter , a par repocier sur papier quelques truc de programmation .
Par contre commenter le listing est vivement conseiller, chose que moi je ne faisais pas a l'epoque et que je regrete maintenant.
Faire prlusieurs sauvegardes aussi est super important, si tu travail sur disquette n'esite pas a en utiliser 2 ou 3 pour y sauvegarder.

[shadow272]

Pour ma part, j'ai toujours un bouquin GFA 3 ou 3.5 à portée de main, plus pour vérifier la bonne manière d'utiliser les mots clef.
La mémoire humaine étant ce qu'elle est, il nous est impossible de retenir toutes les fonctions.

Il faut aussi bien structurer ton programme en mémoire avant de le commencer, bien visualiser l'ordre de fonctionnement (lecture par l’interpréteur) de manière à optimiser dès le départ.

[ManuM]

Je commence avec une simple feuille de papier,
je marque les variables qui vont etre utilisées et le principe du programme (déroulement,actions)
la suite dépend de ce que tu veus réaliser
si c'est un jeu ,un accessoire pour le bureau , etc...
il faudra commencer par sauvegarder les paramètres du systéme ( couleur du bureau, souris ,clavier....)
de façon à le restituer quand on sort de ton PRG .

Commence par les exemples qui sont dans les tutos et modifie les pour voir ce qui se passe
un simple print @(10,10);"HELLO WORLD" et déja tu verras quand modifiant @(x,y) le résultat sur ton écran

cela ne fait que 3 ans que je code du GFA (Merci JB ,SHADOW, et tous les intervenants du GFA FORUM)
je pense que je n'exploite que 10/100 des possibilités du GFA et je m'éclate bien déjà avec ça (lecteur MP3 piloté par le port parallele, récepteur TNT sur ST piloté par une télécommande sur le port cartouche,carte relais ...)

RDV à l'ADN2011

[leglod]

A l'epoque les avant de faire un programme il fallait faire un organigrame je ne sais pas si c'est toujours d'actualite , perso je n'ai jamais rien noter j'avais encore un bon cerveau Ce n'est plus le cas maintenant
http://fr.wikipedia.org/wiki/Organigram ... grammation

[Vicomte]

merci de vos réponses!
je vais quand meme noter une bonne parti sur papier étant donné que je commence à peine à programmer (grace aux tutos).
mon but (cela dépendra du temps et de la motivation) c'est de programmer un jeu.

Dis donc ManuM! tu utilises 10/100 des possibilitées du gfa et tu arrives à faire tous ce que tu viens d'écrire!!
donc si tu connaitrais le gfa à 100% tu pourrais programmer pour la nasa

[leglod]

Oui par contre je notais des bout de code genre l'utilisation du blitter ou le hardscroll car je n'avais pas d'imprimante !
Le GFA permet de faire plein de chose sur le ST , notament programmer le Gem faire des accesoire mais tout cela dans les jeux on en a pas besoin , sauf pour eventuellement faire un editeur de niveau !
Donc pas la peine de connaitre toutes les instruction pour faire un jeu en GFA

[tomchi]

Salut.
Je n'ai jamais programmé qu'en GfA, je ne connais rien d'autre donc j'ai forcement de mauvaises habitudes

Comme shadow, mon manuel est toujours à portée de main.
Ce qui me plait c'est le coté "graphique" du ST enfin du STE , comment deplacer des sprites, faire des effets de demos et depuis 2009 faire des jeux.
Pour comprendre un peu, j'ai recopié les listings dans les ST mag, puis essayé de changer des lignes de codes pour modifier un peu l'effet de base.
Au début, pas de grande réussite, pas de manuel, donc je panais pas grand chose.
Depuis 2008, grace à internet, plein de sources, et des gens à qui poser des questions, mon niveau a fait un enorme bond en avant, je m'evertue à faire ce que je revais de faire à l'epoque quand je n'avais rien pour comprendre ni même programmer.

Bref, le premier truc pour apprendre c'est de lire des sources, yen a plein sur le forum, essayer de comprendre ce que le prog fait et le bidouiller.
Ensuite, quand tu as une petite idee de comment les choses marchent, il faut faire ton propre prog, simple. Perso, il m'arrive de réflechir pendant des mois à comment je peux faire tel ou tel effet avant de poser la moindre ligne de code, en attendant le petit eureka qui me laisse penser que ça va marcher. Mais un prog simple peut se faire même sans grande connaissance dans le GfA. Le manuel est alors bien plus qu'une aide, c'est une bible

Je ne note quasiement rien, parfois comme ManuM, quelques lignes de pseudo code pour me donner une ligne conductrice ou le nom des variables quand yen a trop ou que le prog est trop long.
Le GfA est si facile que à mon avis, quel que soit le domaine qui t'interesse, il ne faut pas hesiter à faire de petits progs des le depart.

Mon conseil pour programmer, ou plutôt comment je fais:
Je programme sous steem, pas de disquette, reboot facile et rapide et surtout les memory snapshots.
En géneral, je boote, lance le GfA basic en ST basse, je crée les routines d'init et de fin, je rajoute celle des registres d'adresses du blitter et je sauvegarde mon fichier MONPROG.GFA. ensuite j'ouvre le selecteur de fichiers pour charger ledit programme, et là je cree un memory snapshot auquel je donne le doux nom gfa editor monprog.
ensuite je reboote et je lance le compilateur, j'ouvre le selecteur de fichiers, je me mets dans le dossier ou il y a mon prog et je cree un autre memory snapshot gfa COMP mon prog.
hop mon environnement de travail est fait, ensuite j'ai qu'à revenir sur le memory snapshot de l'editeur.
De cette maniere, je code dans l'editeur, quand je veux tester, je prends le compilateur ,"F2", "F10", "control"+"T" et hop je vois comme il tourne, si il plante, un undo last memory snapshot et je reviens à l'editeur.
Parfois, je veux tester sous l'editeur, je sauvegarde MONPROG.GFA et je fais RUN, si le prog plante et reboote par example, ce qui arrive souvent, ben hop je recharge le memory snapshot de l'editeur, et je recupere mon prog en cours en une fraction de seconde.
Bon Ok, ya beaucoup de "memory snapshot" dans ce que je viens d'ecrire mais c'est une revolution par rapport ou les gars codais uniquement sur leur ATARI, j'ose pas imaginer le temps qu'il leur fallait ^^'

Il m'arrive aussi de sauvegarder le prog en LST (Save A) , comme leglod a dit, tu peux ensuite lire ce fichier avec le bloc note de windows, j'imprime la partie de code qui m'interesse ou me pose souci, pour tout avoir sous les yeux, et à coté, j'ecris ce que je veux remplacer, ce que je peux optimiser.

Pour le corps du programme à proprement parler, je ne le fais pas tout le temps mais de plus en plus maintenant:
Creer une procedure d'init et une de fin des le debut, pour que le prog quitte correctement et eviter quelques bugs.
Faire un seul MALLOC, et allouer la memoire totale de ce dont j'aurais besoin si il me faut plusieurs buffers.
Utiliser des variables EXPLICITES, claires, et si possible pas trop longues (eventuellement les noter sur un bout de papier)
faire des procedures, cad ne pas tout taper d'un bout, les procedures c'est bien , ça s'ouvre et ça se ferme, permettant d'avoir acces aux listing dans son ensemble plus facilement, sans avoir a scroller 4000 lignes de code pour voir le UNTIL dela boucle principale par exemple
Procedure de test clavier ou joystick, procedure d'affichage, de calcul enfin bref, tout depend de ce que tu codes.
Les commentaires, c'est pas mal pour t'y retrouver quand tu reviens sur le prog beaucoup plus tard, pis c'est bien pour les autres quand tu partages ton code
Quand je code pour moi, j'en mets pas des masses, en géneral je sais ce que je fait et sinon je le retrouve pas trop difficilement, je dis en général parce qu'il y a des fois ... avec des noms de variables bidons, beaucoup de lignes de code, j'ai du mal à retrouver quoi fait quoi et est qui ^^'
par contre je note toujours quand je cree un buffer, à quoi il sert et comment je vais ecrire les donnes dedans.
Pour le jeu que je vais sortir chais pas quand, c'est un shoot'em up, ben pour la gestion des ennemis j'utilise un buffer en memoire ou je stocke leur force, energie, deplacements etc etc, ben au debut de la procedure de tests, j'ai noté à quoi correspond chaque octet ou mot de ce buffer, ce qui fait qu'aujourd'hui j'arrive encore à m'y retrouver alors que cette routine de gestion des ennemis je l'ai commencée il y a un an.

Le mieux pour avancer dans un projet, c'est de le commencer, ben oui c'est nul mais bon.
Genre tu veux afficher un sprite.
Ben tu commences simple, ton sprite tu l'affiche avec RC_COPY, quand ça marche, les deplacements, gestion de sortie d'ecran ou chais pas quoi, ben là tu vas essayer d'optimiser ton code et changer le RC_COPY par un appel au blitter ( je kiffe le blitter ) ou si c'est pour ST, ben tu vas generer une bonne routine pleine de CARDS et tu vas preshifter ton sprite. il vaut mieux un prog pas optimisé qui tourne meme en ramant, qu'un prog optimisé qui plante et que t'arrives pas à savoir où ou encore mieux qui plante à plusieurs endroits ( c'est du vecu )

j'ai encore 2 ou 3 trucs mais bon, vu l'heure et la tartine que je viens de pondre je terminerai par : n'hesites pas à poser des questions sur ce forum et voire d'autres pour te faire avancer, même si tes questions sont theoriques ou basiques , quand quelqu'un te files un coup de pouce ou te debloques sur un truc con que t'avais pas capté, ça aide à ne pas baisser les bras.

Bref, fonces et montre nous ce que tu fais

[leglod]

Parfais ton discoure
A propos de Steem c'est vrais que c'est super pratique, a l'epoque moi je coder sur la Tele une vielle avec un tube fatiguer c'est simple en plein jour je ne voyais rien j'etais obliger de fermer les volets et d'eteindre la lumiere l'avantage c'est que la TV fesait presque 60cm et je rigolais bien en lisant les test des jeu amiga en fulscreen en me disant bein ton fullscreen sur ton ecran 13pouces est plus petit que l'image de mon ST sur ma grosse tele qui a mourir avec ces border noir, j'etais bien naif jeune et con et quand j'ai vu les premier fullscreen sur ST je me suis a oui filialement ils ont bien de la chance sur Amiga !
Bref je m'eloigne de ce que voulais dire, donc programmer sur un vrais ST, c'est aussi le risque de sauvegarder sur une disquette foireuse ca m'es deja arriver
L'avantage de Steem est que l'on peut l'ouvrir trois fois en meme temps voir plus, image , un avec l'editeur un autre avec le compilateur et un troisieme directement sur le bureau pour test le programme compiler voir meme un Saint pour voir si c'est compatible (mais bon moi j'arrive pas avec Saint et le TOS 1.62 le bureau est tout pourrit ?)

Mais surtout faut pas hésiter a sauvegarder x version meme quand on change juste une ligne et surtout le commenter version 1.0001

[ManuM]

Je n'utilise pas STEEM car j'ai besoin du hardware du ST pour mes montages ,
mais coté fiabilité les PC c'est pas terrible , (mon ST a 21ans ,mon portable a laché au bout de 2ans )

Tout à fait d'accord pour les sauvegardes sur différents supports ( satandisk et disquette)

MicroSTalgia pour la doc du GFA,

et tu es pret pour du code