'Drag and drop' sur n'importe quel Atari ? - Page 1

Je suis ce qu'on appelle un fanatique Atari, mais il y a une
chose sur laquelle, j'envie les PC. Vous coupez un texte, une
image n'importe ou et vous la posez n'importe ou, cela est
super pratique, super efficace et nous nous sommes la comme des c..

Du 'drag and drop' sur n'importe quel Atari ?!
Sur le Falcon, un protocole est en place, mais seulement sous
Multitos, et nous autre utilisateurs lambda on fait quoi ?

Donc la question m'est venue a l'esprit, peut on le faire sur un
Atari de base ou alors sur un Falcon mais sous Tos de base ?

Deux problèmes a la base se présente :

Le premier, c'est que pour copié un objet (On va désigné par
objet n'importe quelle info, que ce soit du texte, une image,
etc...) d'une application a une autre, ils nous faut deux
applications qui tourne en meme temps !!

Le second probleme c'est que meme en ayant deux applications
tournant en meme temps (Si si c'est possible sur n'importe quel
Atari !) par exemple si vous avez un accessoire et un programme,
comment faire pour savoir qui est là et comment lui parlé ?

Les prochains détails et explications ne pourrons s'appliqué
qu'aux programmes propres, c'est a dire ceux utilisant le Gem
(Vdi, Aes).

Vous etes prêt pour l'explication ? Ready ? GO !

Quand vous lancez un programme, celui ci doit faire une demande
d'identification a l'O.S., pour pouvoir s'ouvrir une 'station de
travail'. En clair, vous faites un appel système et celui ci vous
renvoie un identificateur, celui ci vous permet de vous faire
reconnaitre pour tous les appels système. Et permet a l'O.S. de
savoir qui est ou et qui fait quoi.

Vous me suivez toujours ?

On continue, pour ceux qui connaisse le Gem ou ont des bases de
celui ci passez votre chemin les autres restés ici. Le coeur
d'un programme est un ou plusieurs appels appels Evnt (Evnt
key, Evnt mouse, Evnt multi, etc..) ceux ci permettent
d'interrogés différents périphériques, le clavier pour evnt key,
la souris pour evnt mouse, etc...) mais il y a un appel qui
traite de choses super importantes, ces choses sont les
messages. Que sont ces messages ? Ces messages vous sont envoyés
par l'O.S. pour vous avertir par exemples, qu'on a modifié une
de vos fenetres, qu'on a cliqué dans votre menu.

Vous voyez un peu ou je veux en venir ? Si vous cherchez un peu,
vous trouvez dans l'Aes une fonction 'Appl_write', celle ci permet
d'écrire des messages a une application, oui d'envoyé des messages
a d'autres programmes !! Cela commence a cogité dans votre petite
tête !! Mais pour envoyez un message, il nous faut l'identificateur
de l'autre programme (Souvenez vous du pb numéro 2 !) et on va
le cherché ou ?

Petit soucis, pour un Atari standard, pas moyen d'avoir une liste
des applications présentes en mémoire, du moins pas de manière
'légale !'. Comment contournez cela ? Il y aurait un moyen simple,
vous vous connaissez votre identificateur, il suffirait de le
publié ! C'est simple non ?

La question est comment ? On va y venir !! Pas de panique !!

D'abord pour répondre a cela, essayez cette question ? Quels sont
les seuls types de programme qui sont constamment en mémoire sur
un Atari ? Vous trouvez pas ? C'est simple, les accessoires sont
toujours la. Et oui, imaginez un accessoire qui s'occupe de la
gestion de tous les identificateurs, cela nous résoudrait le
problème. Mais cet accessoire, pour gerer ceci, il lui faut
l'identificateur ! Donc on revient a notre point de départ !

On tourne en rond, comme un chien qui se mord la queue !!
On va arrèter de tourné, on reprend notre doc sur l'Aes et on
va cherché une fonction baptisé : 'Appl_find', celle ci permet
de trouvé un identif. d'après le nom du programme. Voila un pb
de règlé, donc pour s'enregistré cela va ètre simple :

1) Faire un 'Appl_find'
(On va recherché notre gestionnaire (accessoire))
L'Aes va vous renvoyé, l'identif de l'acc sinon -1
Si on a -1 pas de gestionnaire, c'est fini !!
Si on a autre chose que -1, on va se le gardé bien au chaud
l'identif de l'.ACC

2) On envoie au gestionnaire, un message, une sorte de
demande d'enregistrement, notre identif. est 'publi‚ '
Et voila le tour est joué !


Donc on revient a notre but premier. Dans votre prog, l'utilisateur
fait une selection, vous copiez votre selection (Par exemple dans votre
buffer affect‚ a cela) et vous envoyez un message a l'accessoire.
Celui ci aura connaissance qu'une selection a été faite.

Imaginons que notre utilisateur clique maintenant sur son traitement
de texte en .ACC (accessoire), si l'utilisateur fait une demande de copie
et qu'aucune copie n'aura été faite dans ce programme. Ce traitement
de texte va faire une demande a l'accessoire, est ce qu'une selection
a été faite ailleurs ? Et si oui ou est elle ? Donc l'accessoire va
renvoyé l'info.

It's magic !! Vous pensez pas ? Par contre notre premier problème est
toujours la, nous n'avons pas de sytème multitache et tous les progs
n'acceptent pas d'ètre lancés en .ACC !! Comment résoudre ceci ?

NON je ne vais pas vous dire que je viens de codé un système multitache
je pourrais le faire, mais j'ai d'autres trucs a codé et certaines
autres personnes que moi s'y connaissent mieux et le font mieux que
moi !!

Donc que faire ? On peut règler ce problème en le contournant.

Quand votre utlisateur aura fait sa sélection, et va quitter votre
prog. Vous aurez qu'a envoyez un message a l'accessoire, genre
'Je fermes la boutique !'. L'accessoire va se prendre un peu de
mémoire et recopiez la selection dans ce morceau de mémoire.
Vous vous allez fermer votre programme comme d'habitude

L'utilisateur va chargé un autre prog et faire une demande de
copie, vous procèdez pareil qu'avant, vous adressez une demande
'Tu as une sélection en stock ?' et l'accessoire va vous renvoyez
le nécessaire et voila !!! Oui ont pourrait sauvegardé sur disque
et rechargez, mais cela implique après avoir rechargé, effacez
le fichier et pour ceux qui sont que sur disquette, cela accèlere
l'opération et surtout c'est transparente !!

Pour en revenir a une phrase plus haut, oui les Atari sont
multitaches (Ou presque !). Ce qui ont déjà dvp des accessoires
le save, vous enregistrez le nom de votre accessoire et après
que faite vous ? Et oui une boucle sans fin, vous attendez qu'un
message (Le numéro 41) vous soit envoyé, celui ci vous indique
que c'est vous qu'on a cliquez, sur votre .ACC.

(C'est dailleurs dans cette boucle que j'attends le message
d'enregistrement (Voir exemple), cela permet de scruté le message
sans avoir a ouvrir l'.ACC !)

Et oui !! Le bureau accepte 6 accessoires, donc 6 boucles sans fin !
Ce n'est pas tout a fait du vrai multitache, quand vous faites
votre appel système (Attente souris, message, etcc..) L'O.S. va en
profité pour faire un petit tour dans chaque prog.

Une démonstration ? C'est simple, en bas de ce texte, vous aurez
un lien, vous pourrez téléchargé un exemple. Cet exemple est
constitué d'un .ACC, d'un .PRG et d'un petit source Gfa.

Vous mettez l'.ACC sur votre racine (Disque A, C pour le dur) et
lancez le .PRG, le .PRG va vous indiqué si l'.ACC est là et affichez
son identif, et si vous pressez une touche, notre PRG va envoyé un
message bidon a l'.ACC, l'.ACC va répondre en affichant une boite
d'alerte (Bidon aussi !). J'ai mis les sources .Gfa du .PRG pour
prouvez que le message ne vient pas du .PRG mais bien du gestionnaire
qui a eu le message. (Si vous cliquez sur l'.ACC vous aurez juste
un message de présentation.)

Voila vous avez eu votre exemple de 'multitache' et d'envoi de
messages 'inter-programmes'.

Pourquoi j'écris tout ceci ? C'est simple, tous les prochains
programmes (propres !) C.V.S.D. utiliseront ce système. Cela
est pas mal, mais ca serait mieux s'y bcp de dvpeurs optaient
pour ce sytème, on pourrait coupé/collé d'une application quelconque
a une autre.

Donc dvpeurs a vous de choisir, je voudrais savoir deux choses,
si vous etes prèt a utilisez ce protocole et si des personnes
sont prètes a me passez un coup de main pour les formats
d'échanges. Rassurez vous je me charges d'écrire l'.ACC, c'est
plus pour les formats d'échanges. Dans tous les cas faites moi signe !

Sinon, amis dvpeurs, regardez si vous pouvez passez votre .PRG
en .ACC, ou pouvoir autorisez de lancé un autre prog du votre.
Cela permettrait de lancé un autre prog, de faire une selection.
Vous quittez ce prog et donc on retourne sous votre PROG, cela mange
pas de pain et simplifiera la vie a tout le monde !!



Et voila l'exemple (Stf, STe, Falcon, Falcon CT6x, Hades, Milan, etc..) :

http://cerebral-vortex.net/files/whisper.zip


En souhaitant que d'autres personnes participent a ceci...


GT Turbo (C.V.S.D.)

Bof, et la bibliothèque scrap, tu t'en sert pas ? SCRP_READ et SCRP_WRITE ! Pas besoin d'avoir les deux applis lancées au même moment, puisque les données transitent par le répertoire CLIPBRD sur le disque de boot. Tu copies l'info, tu fermes l'appli, tu ouvres la seconde, tu colles ce qui est contenu dans le répertoire CLIPBRD.

A savoir que comme sur PC, tu peux utiliser le type de document courant. Genre tu copies/coupes une image d'une première appli, tu la sauve en l'encapsulant dans un format standart sur Atari, comme le IMG (préconisé par Atari), donc dans le fichier SCRAP.IMG. D'une autre appli, tu copies du texte ASCII, tu génères donc un fichier SCRAP.TXT. D'une troisième appli, tu coupes du texte formaté. Soit tu le sauve en SCRAP.RTF, ou mieux, en SCRAP.XML. Enfin, tu ouvres un dernière appli de retouche d'image façon Paint Shop Pro, et tu crée une image à partir du presse-papier, donc tu lis SCRAP.IMG. Tu sélectionne l'outil texte, et tu colles soit SCRAP.TXT soit SCRAP.XML (si tu veux préserver le formatage)...

Ca c'est comment ça marche. Windows le fait presque automatiquement (identification des types de conteneur d'objet COM), sur Atari faut tout refaire à la main (c'était un des buts de SSAVCALL, d'étendre les possibilitées du TOS avec des routines de gestion, des plugins, etc... mais je n'ai jamais fini tout ça)...

Kochise

Kochise :
Bof, et la bibliothèque scrap, tu t'en sert pas ? SCRP_READ et SCRP_WRITE ! Pas besoin d'avoir les deux applis lancées au même moment, puisque les données transitent par le répertoire CLIPBRD sur le disque de boot. Tu copies l'info, tu fermes l'appli, tu ouvres la seconde, tu colles ce qui est contenu dans le répertoire CLIPBRD.

A savoir que comme sur PC, tu peux utiliser le type de document courant. Genre tu copies/coupes une image d'une première appli, tu la sauve en l'encapsulant dans un format standart sur Atari, comme le IMG (préconisé par Atari), donc dans le fichier SCRAP.IMG. D'une autre appli, tu copies du texte ASCII, tu génères donc un fichier SCRAP.TXT. D'une troisième appli, tu coupes du texte formaté. Soit tu le sauve en SCRAP.RTF, ou mieux, en SCRAP.XML. Enfin, tu ouvres un dernière appli de retouche d'image façon Paint Shop Pro, et tu crée une image à partir du presse-papier, donc tu lis SCRAP.IMG. Tu sélectionne l'outil texte, et tu colles soit SCRAP.TXT soit SCRAP.XML (si tu veux préserver le formatage)...

Ca c'est comment ça marche. Windows le fait presque automatiquement (identification des types de conteneur d'objet COM), sur Atari faut tout refaire à la main (c'était un des buts de SSAVCALL, d'étendre les possibilitées du TOS avec des routines de gestion, des plugins, etc... mais je n'ai jamais fini tout ça)...

Kochise

Je connais la série des SCRAP fonctions, mais le pb c'est qu'il sauvé un fichier sur le disque, et a chaque fois que tu fais une sélection tu dois sauver sur le disque, imagine tu fais une selection, mais ce n'est pas la bonne ! Deux sauvegarde disque dont une pour rien !!

GT Turbo

GT Turbo :

Je connais la série des SCRAP fonctions, mais le pb c'est qu'il sauvé un fichier sur le disque, et a chaque fois que tu fais une sélection tu dois sauver sur le disque, imagine tu fais une selection, mais ce n'est pas la bonne ! Deux sauvegarde disque dont une pour rien !!

Ce n'est pas si genant que ça, surtout si tu mets le répertoire CLIPBRD sur un RAM disque.

pmandin
:

GT Turbo :

Je connais la série des SCRAP fonctions, mais le pb c'est qu'il sauvé un fichier sur le disque, et a chaque fois que tu fais une sélection tu dois sauver sur le disque, imagine tu fais une selection, mais ce n'est pas la bonne ! Deux sauvegarde disque dont une pour rien !!

Ce n'est pas si genant que ça, surtout si tu mets le répertoire CLIPBRD sur un RAM disque.

C'est vrai, mais question le CLIPBRD peut se trouvé sur n'importe qu'elle disque ? J'avais cru lire (Je confonds peut etre avec un autre 'truc' systeme !) qu'il ne peut se trouvé que sur les disque de boot ?

Mais le but de l'opération est plus une certaine transparence, parce que cela est effectivement possible avec le CLIPBRD.


GT Turbo

GT Turbo :
C'est vrai, mais question le CLIPBRD peut se trouvé sur n'importe qu'elle disque ?

GT Turbo

Oui, il y a un CPX fourni par Atari (clipbrd.cpx) qui permet de choisir l'emplacement du presse-papier.

Il n'y a pas eu le Tube GEM aussi dans le même genre ?

Si si, un truc développé par un certain 'Lapinou' il me semble, ou Parx...

Kochise

Le Féroce Lapin de chez Parx...
Une série de cours passait dans ST Mag au moment ou je me suis exilé outre-atlantique.

Mais c'était plus pour les communications inter-application que simplement pour du copier-coller.

Salut,

GT Turbo :
Sur le Falcon, un protocole est en place, mais seulement sous
Multitos, et nous autre utilisateurs lambda on fait quoi ?

On installe MiNT ou MagiC.

Je comprend pas pourquoi quelques-uns s'obstinnent à encore utiliser le TOS.. c'est lent, buggué, sans fonction avancé et, tout le monde le sait, monotache... Même Atari s'en était rendu compte y a plus de 10 ans.

Non, vraiment, à part pour les vieux jeux/demo, je ne vois pas..
Et encore, dés que je tombe sur une nouvelles demo ne se lançant pour sous OS multitache, je zappe et direct poubelle.

Ok, ca boot vite puisque en ROM.. pour ceux à qui ça manque, on peut trés bien graver MagiC dans un ROM et la mettre dans son Falcon.

On a la chance d'avoir un Unix complet + systéme graphique tenant dans moins d' un mega et y en a qui n'en profite pas... pfff.

GT Turbo :
Du 'drag and drop' sur n'importe quel Atari ?!

C'est juste que ce que tu décris n'a rien, mais alors rien a voir avec du drag&drop.

GT Turbo :
En souhaitant que d'autres personnes participent a ceci...

De tout les codeurs d'applications( je parle pas de demo) que je connaisse, tu es le seul à encore bosser exclusivement sous TOS... pour leur autres, c'est MiNT ou MagiC; et sur ces OS, le protocol Drag&Drop ( le vrai) existe depuis bien longtemps.

A+
Zorro

Mais bon je suis un mauvais exemple, je n'utilise que le TOS, par pure fainéantise et parce que je ne pense plus prendre le temps de coder sur Falcon.
et que ça me gonfle de me dire : "Tiens, je vais prendre un WE pour me faire une config Mint propre "

Mais dans l'ensemble, il faut se dire que quasi 100% des utilisateurs actifs sont sont Mint/Magic, donc GEM & multitaches, à défaut compatibilité (comme le fait Rajah en ouvrant une fenetre plein écran sans attributs).
Les autres, c'est juste des jeux ST qui les intéressent éventuellement (et encore, sous Steem)

A Zorro, l'utilisation de d'O.S. multitache c'est chouette, cela peut etre super, mais il y a une chose a savoir. Utilisé ce genre de sytème (Quand c'est possible !) sur un Ste, c'est du suicide, la seule machine sur laquelle on peut utilisé sans trop ce prendre la tête est un Falcon, le parc de machine n'est pas si grand que cela.

J'ai eu une discution avec un Reservoir Gods (Pink ou SH3, je me souviens plus) il m'a dit de faire des jeux spécifiques au Falcon n'est pas le truc le plus intelligent qu'il soit, parce que le parc de machines est trop petit.

La je suis d'accord avec lui, cela sert a quoi d'écrire un programme si seulement 20% de la population Atari peut le voir ou l'utilisé ?

Je peux me permettre de dvp certains progs spécifique quand je les garde pour moi (Certains outils dvp express) mais si je dvp pour 'le public' j'essaie d'atteindre la plus grande partie sinon cela servirait a quoi ?

Un truc méga con, exemple : notre prochain jeu Falcon, Poong tourne en 640*250 True Colour, mais sur un Falcon de base ce mode n'est possible qu'en RVB !! Donc je vais faire une version spéciale Vga, pour ceux qui ont des Falcons modifiés, cela va réduire le parc d'utilisateur a encore la moitié, cela sera surement le premier jeu ou seule 200 personnes dans le monde vont pouvoir jouer ?

Ou est l'interet ?

Autre probleme, nous sommes un groupe, perso je possède un Ste et un Falcon, RaZ possède un Falcon et un Pc, mais Azrael ne possèdant pas de Falcon, on en fait quoi de lui si on dvp que du code Falcon ?


GT Turbo

Non non, par pure fainéantise (et par manque d'opportunité et de puissance), j'utilise encore mon TOS 4.04 de base, mais agrémenté par GEMRAM et WINX, plus PICDESK et mon SSAVCALL pour faire du RAD...

Sinon j'ai bien récupéré un Falcon à Rajah, avec NVDI 5 et STING, mais je n'ai pas encore cherché à porter les modules surmes autres Falcon (le standart est très bien sous WINX, à 16 MHz il ne fera pas mieux, et le CT60 n'a pas encore d'interface Eiffel)...

Kochise

GT Turbo :
A Zorro, l'utilisation de d'O.S. multitache c'est chouette, cela peut etre super, mais il y a une chose a savoir. Utilisé ce genre de sytème (Quand c'est possible !) sur un Ste, c'est du suicide, la seule machine sur laquelle on peut utilisé sans trop ce prendre la tête est un Falcon, le parc de machine n'est pas si grand que cela.

Il y a eu plus ou moins 200 CT60 de vendu, 700 Milan ( disons qu'il n'en reste que 150 en circulation et toujours utilisés) et plus de 1200 Hades.

Et je ne compte pas les émulateurs qui sont majoritaire aujourd'hui( je discute de chose et d'autres tout les jours avec une dizaine de codeurs.. tous sont sur Aranym a temps plein), de ce fait, je peux t'assure qu'il y a de part le monde, AU MOINS 1500 utilisateurs Atari "moderne"; çad systéme multitache + CPU relativement puissant.

En ce qui me concerne et sans vouloir blesser personnes, seul ceux-ci m'interesse car les personnes allumant une fois par an le STE pour matter une démo ne sont pas à considérer comme de vrais Ataristes... des nostalgiques tout au plus.

GT Turbo :
J'ai eu une discution avec un Reservoir Gods (Pink ou SH3, je me souviens plus) il m'a dit de faire des jeux spécifiques au Falcon n'est pas le truc le plus intelligent qu'il soit, parce que le parc de machines est trop petit.

Ben oui, donc faut faire des jeux limité à 16 couleurs et tournant correctement sur 68000?

Question: A part si tu nous sors un truc jamais vu, où est l'interet de refaire ce qui a déjà été fait 100X avant?

Je sais pas moi, mais faire un jeu exploitant à font le falcon ( je parle même pas de la CT60) ça botte personne? ha oui, ca ne sera "que" pour une cible de 400 personnes :/

Dites, si vous voulez une plus large palette d'utilisateur potentiels, faut coder sur window hein !

GT Turbo :
La je suis d'accord avec lui, cela sert a quoi d'écrire un programme si seulement 20% de la population Atari peut le voir ou l'utilisé ?

Non pas 20% des Ataristes mais tout les Ataristes !

Réféchis un peu, admettons que tu fasses un jeu pour STE et superieur, déjà, tu
auras le désinteressement complet de toute la VRAI communauté Atari ( faut vraiment qu'un jeu STE soit exeptionnel pour que je le lance sur ma CT60).

Ensuite voyons tes "clients" potentiels.. c'est qui? l'utilisateur qui va essayer ton jeu vite fais sur son STE dans le meilleur des cas ou sur émulateur la plupart du temps?

Tu penses que ton jeu, aussi exeptionnel soit-il, va laisser une trace indélébile dans leur mémoire?

Par contre, admettons que tu codes un jeu exploitant un falcon voir une CT60.. là, tu auras les vrais Ataristes qui vont s'y interesser, ton jeu sera à temps plein sur leur dur ( ben oui, les vrai jeu falcon sont rare) et tu auras la reconnaissance de tes pairs.

Je me souviens à la UKONX 1999 ( demo partie de Vesoul), y avait des PCiste, Atariste ( strider était là) et même maqueux..

Lors de la presentation des démos, tout le monde s'en foutait, t'avais les PCistes qui continuaient à jouer en LAN et tout le monde parlait; puis, tout à coup, Makind montre sa démo AmigaPPC.

Silence, plus un mot, les pcistes ne jouaint plus... Fin de la démo, tonnerre d'applaudissement, tout le monde est parti le féleciter.

Crois moi, ce jour là, c'était le roi... et même si la carte PPC pour A1200 ne s'est vendu qu'a quelques centaines d'exemplaires, tout les amigaleux possédant cette carte ont cette demo sur leur dur et elle est resté dans les mémoires.

Pour en revenir à ce que je disais, un jeu demandant un machine "moderne" sera destiné à tous les ataristes car les seuls utilisant leur atari tout les jours en posédent une.

Le top du top, c'est de faire un jeu proprement, c'est a dire sans taper direct dans le hard ( ca fonctionnerait même sur le clone et carte graphique dans ce cas) mais faut pas trop en demander hein :/

GT Turbo :
Un truc méga con, exemple : notre prochain jeu Falcon, Poong tourne en 640*250 True Colour, mais sur un Falcon de base ce mode n'est possible qu'en RVB !! Donc je vais faire une version spéciale Vga, pour ceux qui ont des Falcons modifiés, cela va réduire le parc d'utilisateur a encore la moitié, cela sera surement le premier jeu ou seule 200 personnes dans le monde vont pouvoir jouer ?

Heuu.. PLUS personne n'utilise son falcon en mode RGB !

J'ai dit utilise, çad tout le temps, pas passe en RGB de temps à autre.

Un jeu falcon true color se doit d'etre soit 320*200 soit 640*480.. ça passe partout avec un videl overclocké ( tous le sont) et c'est un ratio standard.

GT Turbo :
Autre probleme, nous sommes un groupe, perso je possède un Ste et un Falcon, RaZ possède un Falcon et un Pc, mais Azrael ne possèdant pas de Falcon, on en fait quoi de lui si on dvp que du code Falcon ?

On lui installe Aranym?

A+
Zorro

Zorro270 :
Un jeu falcon true color se doit d'etre soit 320*200 soit 640*480.. ça passe partout avec un videl overclocké ( tous le sont) et c'est un ratio standard.

A+
Zorro

AUCUN de mes 3 Falcon n'a de Videl overclocké :/ Prend pas ton cas pour une généralité... C'est par fainéantise et par sécurité (mes Falcon ont 10 ans, et je compte pas en griller un par inadvertance)...

Y'a juste qu'un à un CT60, un autre une Eagle Sonic 32, le dernier est nature, out-of-the-box (mais quand même dans son rack de la mort qui arrache et déchire la vie)

Kochise

Fadest
: Mais dans l'ensemble, il faut se dire que quasi 100% des utilisateurs actifs sont sont Mint/Magic, donc GEM & multitaches, à défaut compatibilité (comme le fait Rajah en ouvrant une fenetre plein écran sans attributs).

Les VDI_FX, mhhhhh ?

Zorro270
: Le top du top, c'est de faire un jeu proprement, c'est a dire sans taper direct dans le hard ( ca fonctionnerait même sur le clone et carte graphique dans ce cas) mais faut pas trop en demander hein :/

Ben on essaye, mais c'est clair que pour la vitesse, c'est dur : on ne peut maîtriser vraiment cet aspect, et les shoot'm up et autre trucs à réflexes et plein de spritounets, fodra y réfléchir à deux fois. Quand je pense à la conversion GEM du Pooz, ça va me donner des sueurs froides, sans compter l'idée du jeu rézo en TCP/IP (celle de STING, vu que c'est compatible avec tout )
Autre difficulté : la couleur. C'est plus sympas et moins barbant en True Color, mais il faut vraiment avoir du CPU + RAM.

Pour ce qui est de faire oldskool ou avangardiste : c'est le choix du codeur, et il est à respecter. Avant tout une question de feeling. Est-ce le chemin pour y arriver ou bien le résultat final qui compte ? Si l'on doit coder pour une population, c'est se soumettre à certaines contraintes (service après "vente", configurations requises, verdict du public, utilité de programme/concept...) qui sont parfois démotivantes. D'un autre côté, il y a la reconnaissance de la communauté... Pour&Contre... Ce sera un débat sans fin.

Pour ce qui est du topic : Drag&Drop sur TOS de base <- je trouve pas utile, bien qu'il soit pas con d'y réfléchir. On a pas plusieurs applications en RAM, donc le clipboard suffit. Et les routines fait maison de D&D doivent suffire à l'intérieur de sa propre application (GRAF_DRAGBOX ou qq comme ça).

Rajah, qui a fait un "oh ew ra" et peut mater tranquillou à travers le murs et les portes. Heureusement que j'ai pas schunté l'affichage des objets cachés pour accélérer le display, sinon j'aurais été bien emmerdé.
La magie est presque terminée, reste à coder les traces de pas. Manqueront les sorts avec projectiles, mais ce sera après les monstrounets.

Rajah Lone :
Pour ce qui est de faire oldskool ou avangardiste : c'est le choix du codeur, et il est à respecter. Avant tout une question de feeling.

Toutafé !

Bien que le ton du post semble agressif, c'etait pas le but ( mais alors du tout).

Je soutiens GT, quoi qu'il fasse.. j'esprimai juste tout haut ce que les falconistes pensent tout bas.

AMHA, les jeu ST(E), c'est bien mais ça sera un jeu de plus; un jeu falcon/machine puissante, ça manque vraiment et même si le resultat est moyen ( ce que je doute vu les premiére ébauche), ça sera accueilli les bras ouvert par toute la communauté Falconiste.

Maintenant, à lui de voir.

A+
Zorro

Zorro270 :

Bien que le ton du post semble agressif, c'etait pas le but ( mais alors du tout).


A+
Zorro

Rassure toi personne ne le prend mal, ce qui le pense peuve sortir.
.

Zorro270 :

Et je ne compte pas les émulateurs qui sont majoritaire aujourd'hui( je discute de chose et d'autres tout les jours avec une dizaine de codeurs.. tous sont sur Aranym a temps plein), de ce fait, je peux t'assure qu'il y a de part le monde, AU MOINS 1500 utilisateurs Atari "moderne"; çad systéme multitache + CPU relativement puissant.

Aranym fonctionne a peu près, j'ai essayé Topaze chez RaZ, c'est pas du 100% il y a encore des trucs a faire ! différents soucis (Surtout graphiques !) Et ce n'est pas du code de démo !

Zorro270 :
En ce qui me concerne et sans vouloir blesser personnes, seul ceux-ci m'interesse car les personnes allumant une fois par an le STE pour matter une démo ne sont pas à considérer comme de vrais Ataristes... des nostalgiques tout au plus.

Je possède un Ste, et si je l'allumes ce n'est pas par pure nostalgie. Nous avons participé a la DHS online compo, on aurait pu participé en partie Falcon, mais pour
nous il y a plus de personne qui possède un Ste qu'un Falcon, la machine on la connait mieux aussi, qui oserait dire qu'il connait a 100% un Falcon ? C'est mpossible !

Encore maintenant on arrive a trouvé ou a appliqué des techniques (Exemple Chunky to Planar !) sur de simple ST !

Un truc super flagrant, prend les premiers jeux St, des merdes ambulantes sauf certains, reprend des jeux récents ST, tu pleures, on réussi a faire des trucs qu'on faisait pas avant !

Tu peux dvp un prog pour qu'il tourne sur toutes les machines et rajoutés des trucs en plus suivant les machines. Exemple un jeu, sur un Stf tu aura une sounchip, sur un Ste un soundtrack a 12 Khz, sur un Falcon le son en 50 Khz 16 bit avec interpol linéraire!!

Exemple Wolfenstein, dvp par Ray (TSCC) il tourne aussi bien sur un Ste et sur un Falcon, sur un Falcon il est plus rapide. Tu peux faire des versions 16 couleurs et des versions 256 voire True Color sur Falcon.

Poong est un prog spécial Falcon, par contre Blood Money II, aura des parties propres a chaque machine, et me dit pas qu'un Blood Money II ne va pas resté dans les mémoires, le I était déjà une merveille, mais une version spéciale Ste, Falcon.

Si par exemple Aranym tournait a 100%, tout a fait d'accord avec toi, cela serait super, mais pour l'instant ce n'est pas le cas. Un truc bete regarde les émulateurs Jaguars, ils ont du mal a émulé une machine qui tourne a 26 Mhz, cela va ètre assez chaud d'émulé une CT 60 tu crois pas !


GT Turbo (C.V.S.D.)

Une dernière chose, si je voulais vraiment faire un jeu spécial Falcon a fond, je ferais que du code spécifique 68060 (Sinon cela servirait a quoi d'avoir un 060 !) sur des CT6X a 100 Mhz, comme cela je pourrais faire un truc qui arrache a mort, mais je pourrais juste le montré lors de party !! Et seul certain mortels y auraient accès !

GT Turbo

Ouais, mais au moins t'aurais un truc 060 "qui arrache a mort". Les CT63 sont encore en ventes, donc ton public potentiel existe

Kochise

Kochise :
Ouais, mais au moins t'aurais un truc 060 "qui arrache a mort". Les CT63 sont encore en ventes, donc ton public potentiel existe

Kochise

Comme tu l'a dit, enfin un truc qui arrache a mort, en parlent de cela je fais une parenthèse, il existe de bon livres sur le 68060 ?

Je penses que certaines routines ou certain de mes codes sortiront en version spéciale 68060, si déjà. Une version (68000 ou 68030) pour tout le monde et des versions 'Je vais t'arraché les chicots !' spécial pour ceux qui aime !!!

J'ai pensé hier soir, avoir un O.S. multitache avec une machine a 100 Mhz c'est bien beau mais quand je vois des jeux comme Gempanic, c'est marrant, mais ca je peux le refaire en une Vbl sur un Ste, donc pourquoi avoir des machines qui poussent (Enfin !) pour réécrire des trucs qui poussent pas ?


Poulpi !

Parce que ta machine qui pousse, elle peut aller sur internet tout en continuant à pousser. Si tu te limite au ST, tu te limite aux applis développées pour le ST, donc la plupart du temps à quelques jeux de nostalgique...

C'est ce que Zorro à essayé de t'inculquer : tes applications de l'informatique sont strictement limitées au coding. Mais autour de toi, y'a des utilisateurs qui ne veulent pas se limiter à quelques jeux qui 'poussent' en 16 couleurs. Dans ce cas, y'a les consoles de jeux

Kochise

Kochise :
Parce que ta machine qui pousse, elle peut aller sur internet tout en continuant à pousser. Si tu te limite au ST, tu te limite aux applis développées pour le ST, donc la plupart du temps à quelques jeux de nostalgique...

C'est ce que Zorro à essayé de t'inculquer : tes applications de l'informatique sont strictement limitées au coding. Mais autour de toi, y'a des utilisateurs qui ne veulent pas se limiter à quelques jeux qui 'poussent' en 16 couleurs. Dans ce cas, y'a les consoles de jeux

Kochise

D'accord mais cela pour l'instant (!) est quand meme plus simple de dvp sur micro que sur console, donc on dvp sur micro.

Mes applis ne sont pas que limités au coding (presque mais bon ! lol !), cela fait du bien de temps en temps de joué (Dubble Bobble, Bunion ,etc...) et j'ai juste a cliqué pour le lancé, pas besoin de branché la Jag. En plus certain hits n'existe pas sur console, donc !

Mais cela n'empeche quand meme pas de dvp une version standard (68000, 16 couleurs) et de faire des versions enhanced (68060, NTC), comme cela bcp plus de personnes y auraient accès. Les noyaux se transportent très bien, juste les parties son et vidéo qui sont différentes, on peut meme si on se débrouille bien, dans le meme prog avoir les deux versions.

Et cela vaut pour tout, pas que les jeux, les outils de dvp comme le reste. On ne change pas de plate forme (Ou du moins pas a 100, certaines choses sont exacement les memes, donc pourquoi privé certaines personnes ? Alors qu'un peu d'huile de coude en plus et tout le monde pourrait en profité !

Pour Poong, on pourrait profité du copro arithmétique, mais on le fait pas pour évité de pénalisé ce qui en on pas !

Ce que je veux dire c'est que je suis tout a fait d'accord pour dvp des app. qui 'décolle la moquette' mais il ne faut quand meme pas oublié les autres, une utilisation correcte du Gem, fait qu'on a pas besoin de modifié son code pour le faire tourné sur n'importe qu'elle machine, et l'utilisation de celui ci meme si ce n'est pas une foudre de guerre, fait que sur une CT60 (ou autres machines boostés !) il tournera quand meme plus vite !


TG bortu

GT Turbo :
[...]sur une CT60 (ou autres machines boostés !) il tournera quand meme plus vite !

T'es sur ? Tiens, regarde : movep, movep, movep, movep, ...

Kochise

Kochise
:

GT Turbo :
[...]sur une CT60 (ou autres machines boostés !) il tournera quand meme plus vite !

T'es sur ? Tiens, regarde : movep, movep, movep, movep, ...

Kochise

L'exception qui confirme la règle, la tu cherches la petite bete ! Mais une question est ce que les compilos C use de cette instruction ? Sinon pourquoi s'inquiété ? Depuis que je sais cela ne n'utilise plus cette instruction, on le sait, donc on evite et il y a aucun soucis !!

GT Turbo

Je crois que la réponse à ta première question est oui, car elle était dans tous les processeurs 680X0 existants au moment de la sortie des compilos C Atari.
Sauf peut-être le GCC qui a continuer d'avoluer, en spécifiant compilation pour 68060.
Je pense que Zorro pourra nous en dire plus à ce sujet

Fadest :
Je crois que la réponse à ta première question est oui, car elle était dans tous les processeurs 680X0 existants au moment de la sortie des compilos C Atari.

En fait oui et non.

Dans le cas de PureC, l'instruction movep n'est utilisé que si on deal avec les periphs 8 bits genre port cartouche.

Pour le code d'un jeu ou d'une app standard, elle n'est jamais utilisée.

Fadest :
Sauf peut-être le GCC qui a continuer d'avoluer, en spécifiant compilation pour 68060.

Même en mode 68000, GCC n'utilise jamais cette instruction.

Petite parenthése, NE JAMAIS utiliser GCC si on ne compile pas pour minimum un 68020 avec bus 32 bits!


A+
Zorro

Merci, c'est donc plutôt positif alors.

GT Turbo :

D'accord mais cela pour l'instant (!) est quand meme plus simple de dvp sur micro que sur console, donc on dvp sur micro.

Ce qui est bien entendu faux aussi bien financièrement parlant que niveau outils

GT Turbo :
Mais cela n'empeche quand meme pas de dvp une version standard (68000, 16 couleurs) et de faire des versions enhanced (68060, NTC), comme cela bcp plus de personnes y auraient accès. Les noyaux se transportent très bien, juste les parties son et vidéo qui sont différentes, on peut meme si on se débrouille bien, dans le meme prog avoir les deux versions.

Oui mais non... si ton jeu est prévu pour 68000 à la base, t'as beau y mettre des graphs 16 bits + musique meilleur, ça ne restera qu'un jeu pour 68000.

Dans le même esprit, pense au portage de jeu SNK sur PS2... c'est mieux, plus beau, y a quelques details en plus mais ca reste des jeux de console ancienne génération. ( ça n'enléve rien à leur fun bien entendu).

GT Turbo :
Pour Poong, on pourrait profité du copro arithmétique, mais on le fait pas pour évité de pénalisé ce qui en on pas !

Dans le cas de Poong, c'est inutile mais pour d'autre cas, la FPU est obligatoire.


A+
Zorro

GT Turbo :
il existe de bon livres sur le 68060 ?

Pas besoin, si on oublit le code FPU qui est TRES différent, pour le CPU, il n'y a que trés peu de choses à faire.

Pour le MOVEP, tu le sais déjà.

Pour le move, le faire le plus souvent possible avec des longs ( oui, je sais, c'est plus lent sur falcon de base).

Si tu veux bouger plus de 16 bytes à la fois, le MOVE16 est 20% plus rapide que 4 move.l et posséde l'énorme avantage de ne pas utiliser le cache ( ce qui le laisse libre pour d'autres données).

GT Turbo :
J'ai pensé hier soir, avoir un O.S. multitache avec une machine a 100 Mhz c'est bien beau mais quand je vois des jeux comme Gempanic, c'est marrant, mais ca je peux le refaire en une Vbl sur un Ste, donc pourquoi avoir des machines qui poussent (Enfin !) pour réécrire des trucs qui poussent pas ?

Gempanic n'est pas un bon exemple... lance Quake sur CT60 et regarde de quoi je parle ( et encore, ce n'est pas codé spécifiquement pour la CT60, ca n'utilise pas le move16 et il y a du C2P à chaque image).

Si un travail plus profond aurait été fait sur le portage, ça irait minimum 2 fois plus vite.

Tu as vu le petit film de Xerus?

http://falcon060.free.fr/


Sinon, à ta question sur le pourquoi "les trucs ne poussent pas"; si si, elles poussent
mais faut regarder dans les apps et non dans les demos/jeux.

Mais bon, apparement, on utilise pas son falcon de la même façon

http://the.zorro.free.fr/gfx/zview.jpg

A+
Zorro