Re: GUERRE ST-AMIGA, FIGHT !!!

[ryosaeba]

cette guerre ne cessera jamais, car les Amigaistes ne voit que les perfs...si les perfs pures faisaient uniquement la différence le monde serait vraiment différent aujourd'hui !

l'amiga a beau avoir 48 copros, 1028 cores, faire du 4K, si la machine est difficile en utilisation quotidienne et mal fichue, cela ne sert à rien.   Il y a avait des machines bien plus performante que l'Amiga   ( l'Archimede par exemple ), et pourtant cela a fait un four complet.  Preuve que ce n'est pas qu'une question de puissance.

L'Atari reste un ordi bien plus convivial en utilisation quotidienne non console de jeu. C'est à dire faire autre chose que : 1° mettre disquette dans lecteur" 2° switch on

Y a pas que les perfs, un grand nombre de logiciels sont quand même plutôt bien foutu sur amiga, faut quand même le dire. Quand j'allume mes STs ou STE, à part de très rare exceptions, franchement c'est faible. Certains jeux sont même mieux sur Amstrad CPC que sur ST. Le ST a une palette trop limitée globalement, et puis sorti d'un type très particulier de jeux (jeux en 16 couleurs, petits sprites, scrolling écran par écran le plus souvent), le ST patine totalement.

Quand à l'Archimedes, les anglais n'ont jamais voulu qu'il sorte de l'Angleterre, et puis pub quasi inexistante. Pas besoin de chercher midi à quatorze heures pour comprendre la raison du flop.

L'atari ST c'est une bécane de communiste. Quand tu vois le GEM, franchement comment ils ont osé. C'est juste merdique, je préfère encore le basic de l'Amstrad CPC en ligne de commande. Le GEM c'est le workbench en moins bien.

Quand à la musique sur le ST, c'est totalement variable, autant certains jeux pas très nombreux ont une bande son particulière qui assure, autant pour les autres c'est juste immonde. Même le CPC s'en sort mieux alors qu'il a la même puce son, mais différence de taille, le CPC est lui bien conçu sur le plan du hardware (on a pas le souffle ni le bruit dans les musiques par exemple présents sur les ST et STE).

Quand à l'ultrasatan, je précise également 2 choses : 1) C'est l'ultrasatan qui permet le débit indiqué et pas l'atari ST 2) En terme de vitesse, un disque dur A500 GVP II défonce littéralement en terme de perf l'ultrasatan. Et c'est de la techno des années 90. L'ultrasatan offre simplement 30 ans ce que l'amiga permettait déjà avant !

Ensuite, et cette info là ne tourne pas assez à mon gout (je l'ai postée en anglais sur l'Atari Forum, mais le voici en français sur Gamopat) :

Je possède les 2 types de ST et STE, à savoir 520 & 1040 STF, et 520 & 1040 STE blindés à 4 mo, avec leurs alims retapées de A à Z. Comme le hard du ST c'est de la quincaille off-the-shelf, et comme Jacko déjà en 1985 il connaissait déjà la méthode de compression des coûts, le hard du ST est mal foutu, ça se traduit par si les condos de l'alim lachent, le 220 fonce direct dans la carte mère, et pschhttt, c'est la mort par snou-snou ! Y a aussi le phénomène de vague lié à l'alim et lecteur de disquette, qui lui aussi est pas mal fourni en condos, le tout faisant une belle vague à l'écran quand on allume la bête.... Bref, le commodore 64 est dans le même genre, et c'est normal, c'est du Djacko. Ensuite, le point hyper important, un grand nombre de STF et de STE ont une puce DMA défectueuse. Cette puce gère les accès disque dur. Je possède un ultrasatan, mais j'ai aussi possédé un disque dur Atari SH305. Peu importe, dans les deux cas, tout les ST que je possède ont la maladie, qui consiste à corrompre presque systématiquement les données lors des accès en écriture sur le disque dur.

Mais j'ai mieux : un jour, en utilisant le système de dump PASTI couplé à l'ultrasatan, donc imager un logiciel original dans le format STX sur disque dur, pour transférer le tout sur mon PC, et sachant que le logiciel PASTI
demande de protéger en écriture la disquette avant de démarrer toute opération, le bug DMA a non seulement corrompu les données sur l'ultrasatan, mais mieux, le contenu de ma disquette originale (Scoop Junior de Génération 5) a été détruite dans le processus, et ça avec le taquet de protection en écriture ouvert comme demandé par PASTI ! Je possédais heureusement le jeu en 2 exemplaires, j'ai donc plus le restaurer avec le supercard Pro (autre hardware pour imager des originaux).

Ce genre d'anneries n'existe pas sur amiga. On est en 2015, et je ne peux toujours pas profiter de mon ultrasatan (qui est mise à jour) correctement et des jeux convertis pour disque dur..... Sur amiga, toutes les opérations liées aux disquettes ou aux disques durs sont simples et limpide même pour le néophyte total, sur ST ou STE faut avoir la chance de tomber sur une carte mère dotée de la dite puce révisée.... Merci Djack, top qualité Atari :)

Tu as pas de chance. Et j'ai jamais vu que le St savait outrepasser la protection disquette.....Franchement un délire total.........Tu sais au moins comment utiliser un ultra satan............;

[dlfrsilver]

Bien évidemment.... Y a rien de sorcier sur un ultrasatan.... y a un firmware à mettre à jour, 1 ou 2 cartes SD à préparer avec un pilote de disque dur (j'utilise celui d'Uwe Seimet), et le reste c'est du cable à brancher, et l'allumage s'effectue de façon standard : allumage en premier de l'US en premier, suivi du ST/E.

Le problème s'est produit PENDANT que le ST/E était en train d'imager la disquette sur l'ultrasatan. Le lecteur de disquette a pété un boulon, puis le ST a planté en soft. j'ai éteint PASTI, puis le ST, puis l'ultrasatan, j'ai sorti la disquette de Scoop, l'ai remise, relancé le STE sans l'US, et quand j'ai vérifié le contenu de la disquette, tout était corrompu. J'ai regardé après sur l'ultrasatan, tout était corrompu de la même manière. Comme la puce DMA gère les accès disque dur et disquette (rien à voir avec le FDC wd1772), les deux en ont pris plein la gueule. J'ai démonté le STE pour vérifier les puces présentes sur la carte mère, et là pas de surprise : le STE utilise la puce avec la mauvaise référence. Mon 520STE pareil, quand je l'ai acheté j'ai fait la maintenance de la machine, même problème, même tarif même punition.

J'ai mes 4 ST/E principaux, mais histoire d'être sur de mon coup, j'en ai acheté d'autres il y a un moment, et TOUS ont le problème.

Le fait que le ST ait outrepassé la protection disquette indique une sérieuse vérole sur le plan hardware. Si encore j'avais utilisé une appli ne vérifiant pas la protection en écriture, j'aurais pu me remettre en cause et me dire, "mince j'ai du oublier de protéger la disquette quel con", mais là y a pas de doute possible, PASTI sur ST refuse d'imager quelque disquette que ce soit si celle ci n'est pas protégée en écriture.

[Doctoritchy]

pour la qualiter mécanique ,  le st as des tole epaisse et solide  qui ne rouille pas  , l'amiga as des tole acier tres fine qui plie et dont le chromage est rouiller :/ 

pour les corruption disquette  oui je confirme j'ai eu la blague  disquette protégée en ecriture , transfert d'un fichier de 1 mo sur le disque dur  puis une fois fait  fichier sur le hdd corrompus et celui sur la disquette aussi , etrange  je n'ai pas pousser plus loin  , le lecteur fonctionne tres tres bien pour le reste :) , il me faut un bon dma chips !


je vais rechercher apres les schéma des modif du son et je les posterais pour celui qui veut

[dlfrsilver]

Tout les ST que j'ai récupéré j'ai du passer leur tôle à la toile éméri et au "frameto" pour retirer la rouille. A l'inverse, tout mes amiga, que ce soit 500 ou 1200 ont quelques pigment de rouille, mais rien de bien méchant.

AH ! enfin quelqu'un qui a rencontré le même problème que moi pour la corruption Disquette et Disque dur !!!

[ryosaeba]

pour la qualiter mécanique ,  le st as des tole epaisse et solide  qui ne rouille pas  , l'amiga as des tole acier tres fine qui plie et dont le chromage est rouiller :/ 

pour les corruption disquette  oui je confirme j'ai eu la blague  disquette protégée en ecriture , transfert d'un fichier de 1 mo sur le disque dur  puis une fois fait  fichier sur le hdd corrompus et celui sur la disquette aussi , etrange  je n'ai pas pousser plus loin  , le lecteur fonctionne tres tres bien pour le reste :) , il me faut un bon dma chips !


je vais rechercher apres les schéma des modif du son et je les posterais pour celui qui veut

cela m'intéresse. D'ailleurs je vais te re-contacter bientôt...... Si cela t'intéresse tu peux télécharger quelques plans du Falcon ici : http://www.amigaimpact.org/forums/topic/qui-peut-reparer-un-atari-officiellement-actuellement/

[Doctoritchy]

ok pour les plan du falcon , lui j'aimerais bcp en trouver un  cette machine ma toujours facinée etant jeune  c'etait la rolls de tout as cette epoque :)

j'ai la sauvegarde quelque part  mon pc as planté dernierement donc j'ai perdu pas mal , mais je doit aussi avoir noté ça sur papier , enfin au pire je renote le tout as partir du ste :)

on peu aussi allez plus loin et symetrisé les sortie son  on outre/passe quelque composant et on gagne en qualiter audio , mais il faut entré dans un ampli symetrique apres (XLR 3 broche ) ,enfin tout ça est noter quelque part , je vais aussi regarder as amélioré les sortie son de l'amiga  si amélioration est possible :)

[ryosaeba]

Un très bon blog :http://topamigaretro.blog4ever.com/

[rocky007]

Les 300 Ko/s, c'était pour me moquer : déjà tu mettais 2,5 megabits/s et ensuite ce nombre est moins ridicule que le tien. Déjà on est passé de HD qui faisaient 2,5 Mo/s à une interface qui n'atteint que la moitié... On progresse...
La fameuse interface dont je parle est un adaptateur qui n'existait pas à l'époque du ST (ou alors elle aurait couté 10x fois le prix du ST...) et, pour fonctionner, elle necessite une modification du ST (un Hack, pour reprendre les termes de l'auteur...). Non il ne fait aucun test car ça ne sert à rien : Il explique qu'avec un UltraSatan (plus performant que tout ce qui existait à l'époque) on ne peut atteindre que du 320x158 en 25 i/s (on oublie les 30K couleurs perceptibles...)...

je donné les débits SCSI, dont je parle SCSI, ne mélange donc pas tout et sois un peu plus attentif dans tes lectures.   donc comme tu confirmes, l'auteur ne donne aucun débit en SCSI, cela n'empêche de sa faisabilité.

 
Y avait quoi d'autre ? Ben renseigne toi : la plupart des applis fonctionnent, ce sont les jeux qui coincent (et encore, pas toujours...).
Pas de chance pour le STE (parce qu'on a du oublier le ST dans ce débat..), parce que si, sur le mig, les player qui font des changements de palette à chaque ligne tournent très bien quel que soit le modèle de mig. En plus de faire plus de changement qu'un 68000, de faire des changement couleur par couleur, le copper permet de rendre ce genre de trick indépendant du processeur... D'ailleurs l'OS lui même les utilise... En même temps avec un TOS incompatible avec les processeur 32 bits, ça n'aurait servi à rien ! lol !!!

les applis ? tu parles de celles qui en bougeant la souris trop vite provoquaient un guru ou celle qui débordait sur la ram d'un autre appli ? ou tu parles peut-être de celle qui tournait sur WB 1.3 mais pas sur la 2.0 ?  tu parles de cette magnifique copper n'a pas évolué sur le A1200, le rendant dès le départ obsolète ?  à quoi bon être compatible si c'est pour brider la machine...

Non on lui doit pas le monde, mais c'est le premier micro que l'on peut qualifier de multimedia (image, son et animation)

comme déjà expliqué ici, la définition du mot multimedia ne comporte pas de critère qualitatif.  pourquoi une image atari ST ne peut-elle pas être "multimedia" ?? parce qu'il n'a que 512 couleurs ?  Une Atari ST peut jouer une vidéo / photo, avec du son, cela en fait donc un ordi multimedia.  il peut également piloter des synthés, laserdisc etc.. ce qui le fait rentrer dans le monde pro sans difficulté.  Du reste, soyons clair, l'amiga n'a rien de plus à offrir: il est lui aussi incapable de jouer une video 50 FPS en qualité vidéo. 

Ah mais je ne cherches pas à te convaincre, je veux juste corriger quelques une des inepties que j'ai vues ici. Les lecteurs se feront leur opinion. Je leur dirai simplement qu'il y a des jeux qui utilisent le dual-playfield et ajoutent un troisième layer à base de sprites mutiplexés horizontalement par le copper. Et ils font scroller tout ça sans aucun problème. Pourtant ça prend autant de ressource qu'un Ecran SHAM ou sliced EHB (6 bitplans et autant d'instructions pour le copper)...

et bien montres-nous cela ... j'attends toujours ton jeu en scrolling horizontal en sliced EHB ou SHAM...et concernant les jeux dual + sprite, cela se limite  à 99% des cas à un score qui s'affiche en sprite sans plus.  c'est bien joli de faire du parallax, mais cela ne se prêt à ...ben Shadow of the beast, un jeu très joli, développé sur un effet mais con comme la lune.  tous les tricks amiga sont inutilisables dans des jeux classiques. 

Ah bon ? Comment gérer les sprites et le scrolling ? Et ou as-tu vu que ça ne se fait qu'avec le copper ? Les sprites sont autonomes, y compris pour le multiplexage vertical. Quand au scrolling, c'est 2 registres à modifier. Cela peut être fait avec le 68000 mais comme on fait ça en dehors de l'affichage pour éviter les "tearing", ça peut être fait avec le copper sans soucis puisque pendant ce temps là, il n'y a pas de palette à modifier...
La différence ? Y en a plusieurs :
 - Sur ST, tu dois synchroniser tes instructions 68000 avec l'affichage. En gros tu demandes au 68000 de faire des move sans arret du début à la fin de la zone affichée. ça représente 65% de la frame avec 200 lignes. Sur le mig, le 68000 peut utiliser toute la frame (voire 2 frames avec une vidéo à 25 i/s).Il peut même préparer plusieurs copperlist à l'avance...
 - Sur St, la synchro avec le début de l'affichage prend pas mal de cycles. Sur le mig, vu que c'est le copper, c'est gratuit...
 - Sur ST, tu es obligé d'utiliser des movem et de modifier toute la palette d'un coup pour atteindre 48 couleurs lignes. Le copper fait des move simple sur n'importe quel registre. C'est beaucoup plus efficace.
 - Sur ST, dans un logiciel de dessin (ou dans un viewer), le 68000 est occupé 65 % du temps même si aucun pixel change. Sur le mig, le 68000 se repose....
 - Sur ST, tu ne disposes plus des interruptions 68000 pendant l'affichage. Sur le mig si...
 - Sur ST, ça ne peux marcher qu'avec le proc d'origine. Sur le mig c'est compatible avec tous les 680x0. Peut importe que la copperlist soit remplie plus vite...
Je pourrai continuer a t'expliquer les avantages mais ce n'est pas la peine je pense.

ah super, on passe donc de temps  à réel à des coppers prédéfinie..wow magnifique ça, donc dans un jeu en temps réels, tu vas donc utiliser une copper par frame ??  bonne idée ça...  tu vas utiliser le 68000 pour préparer la copper qui va suivre... ah oui juste, vu comme ça, ça change du tout au tout ...
qd à ton exemple du logiciel de dessin, magnifique, l'amiga se repose et pas l'atari qui doit bouloter pour afficher ses couleurs...et après ?  tu as peur de consommer trop d'electricité ?  bref, on reviens à la même chose : si tu as un copper dynamique à chaque frame, cela ne change rien.

Non ce n'est pas sans fondement. Tu prétendais que le ST aurait pu faire aussi bien que le mig en matière de titrage et de vidéo et SCALA est un programme hyper utilisé dans ce domaine. Cela impliquerait que le ST est capable de reproduire les effets disponibles dans SCALA. Il en est incapable meme en bidouillant, alors que le SCALA le fait sur le mig en étant OS friendly

oui et je confirme : le ST AURAIT pu faire, cela n'a pas existé, mais cela AURAIT PU.  Je ne vois pas c qu'il aurait été impossible à faire sur un ST que faisait SCALA.

.
Oui bien sur : lance un player de module et 2 ou 3 commodities (c'est comme les accessoires mais 100 fois plus puissants avec une consommation des ressources préemptive) et déplace des fenêtres sur le WB ou manipule une brosse sous deluxe paint et tu constatera que le mig sera toujours plus réactif qu'un ST sans rien qui tourne derrière. Et fais des test avant d'affirmer que ça prend plus de place que tes accessoires (qui sont nuls et limités en nombre, non ?). Ensuite tu m'expliquera le principe d'un spooler d'impression dans un environnement monotâche parce que je comprend pas trop là...
LE seul avantage de l'atari c'est qu'il permettait d'avoir un affichage sur 400 lignes avec un moniteur N&B qui ne coutait pas cher. Je l'ai déjà expliqué ici. Et c'était un avantage énorme. Le mig devra attendre longtemps pour que les écrans vga et/ou multisync soient accessibles. Pro24 (longtemps la référence des compositeurs) existait sur le mig (et oui...) mais il fallait payer une fortune pour pouvoir l'utiliser sur un affichage haute résolution. 704 x 576 x 16 couleurs inabordable, c'est moins bien que 640 x 400 x 2 couleurs hyper accessibles. Avec ce genre de logiciel, les 400 lignes apportent un vrai plus.
J'ai mieux défendu le ST que tous les posts remplis de sornettes que j'ai lus ici (le TOS/GEM comparé à l'amigaos : trop ridicule !!!)

100 fois plus puissant...woooaaaaw...  tu dois avoir une super calculette pour trouver un tel chiffre... oui c'est bien ce qu'on dit depuis le début : le multitâche ne sert qu'à lancer un module s'il reste un peu de RAM.  Amiga inventé le substitut de radio pendant qu'on bosse sur un ordi.   Au prix de l'amiga, on pouvait acheter 2 ST, un pour jouer de la musique et un pour bosser.  les accessoires ST remplissent parfaitement leurs rôles ( ce sont des accessoires ), et sont super pratiques.  tu devrais vraiment essayer.  tu devrais aussi revoir ton source d'un spooler, tu as oublié  comment cela fonctionne.  ce qui est ridicule c'est l'obsession des amigaistes à comparé leur usine à gaz à un ordi fonctionnel au quotidien.  exactement comme un macintosh : un outil simple, fiable et perfomant pour le travail de tout les jour.  si on voulait une console de jeu, l'amiga était clairement le bon choix. 

Parce que le GenLock ne se locke par sur la synchro : il récupère celle d'un signal vidéo et l'impose au STE (pas ST, ce n'est pas possible. Marrant : alors que le ST s'est bien plus vendu...) ou au mig. 

ah bon ?  un genlock externe ne se lock pas sur la synchro..tiens tiens...alors comment il fait pour mixer les 2 signaux vidéos ?  y'a un random qui choisit la fréq au hasard ?

.Tu n'es pas spécialiste mais ça ne t'empeche pas d'affirmer pleins de choses. Et de faire pleins d'erreurs..

éclaires donc ma lanterne, montres moi de la 3D hyper rapide grâce au blitter...
et idem pour c2p sur un A500 de base, montres-nous donc une routine plus rapide que sur un ST, grâce au blitter...très impatient également

Bisous

[dlfrsilver]

@Rocky007 : Si tu veux de la vraie 3D texturée, il y a Ambermoon de thalion sur Amiga.

La version amiga 500 dispose de la 3D d'un niveau de celle de wolfenstein 3D si c'est pas mieux (tout est texturé comme sur 1200 si le 500 utilise une carte acceleratrice), et sur A1200 tout est texturé en vraie 3D du sol au plafond. Les programmeurs ont mis au point une routine mélangeant l'usage du copper et du blitter. Et c'est du planar, et pas du C2P, et ça tourne en 50 fps.

Le jeu affiche entre 70 et 80 couleurs (merci la routine copper server), et dispose de Zoom sur les sprites lors des combats de type mode 7 mieux foutu que sur la super nes (A500 et A1200).

Le ST même avec la meilleure volonté du monde ne pourrait pas supporter un tel jeu, que ce soit en nombre de couleur, en terme de vitesse d'affichage (les zooms, le nombre de sprites, etc etc).

Je peux t'en parler, j'ai désossé entièrement le jeu pour pouvoir le traduire en français :)

Seul le falcon aurait pu vraiment le supporter, mais comme c'est une machine mort née, les développeurs ne s'en sont pas occupé.

si tu veux le voir sans l'installer, google le nom ou vas sur youtube.

[rocky007]

je sais pas si je suis le seul à voir la différence...il y a comme une légère différence de la zone d'affichage...très légère.. concernant Ambermoon, le proto de la version ST était proche de la version Amiga

ps: très bon boulot sur ambermoon

[Seb]

Pour la petite histoire, un des codeurs de Ambermoon sur Amiga n'est autre que Hexogen de TNT Crew sur Atari ST, connu entre autre pour la F.N.I.L demo (1988) et pour son screen 3D dans la Union demo sur ST :)

[dlfrsilver]

je sais pas si je suis le seul à voir la différence...il y a comme une légère différence de la zone d'affichage...très légère.. concernant Ambermoon, le proto de la version ST était proche de la version Amiga

ps: très bon boulot sur ambermoon

Merci pour le compliment, cependant je voudrais attirer ton attention sur plusieurs faits :

- Le programme n'existe pas même à l'état de prototype sur Atari ST, ni de graphismes, et voici pourquoi :

Jurie Hornemann a confié avoir passé 1 an/1 an et demi a reprogrammer intégralement tout ses outils de developpement de jeu, car les précédents ne tournaient que atari ST et rendaient impossible l'exploitation maximale de l'amiga.

Il a également indiqué avoir repris et reprogrammé from scratch ce qu'il avait fait sur ST, et qui existait en tant que première version sur amiga. Insatisfait de la médiocrité du résultat, il a tout repris et reprogrammé le jeu dans les règles de l'art (70-80 couleurs à l'écran, utilisation intensive du copper et du blitter, 3D texturée faces pleines, et ainsi de suite) pour l'amiga, qui était la machine du moment.

(PS 1 : outils atari ST lockés sur 16 couleurs, hyper limités dans leurs fonctions, et surtout, les outils étaient buggés!)

(PS 2 : Dragon Flight, un bon jeu RPG a été flingué à cause de ça, seule la version allemande peut être terminée, les version anglaises et françaises ont des bugs liés aux outils !)

Lionheart et Ambermoon avaient été conçus comme deux "missiles longue portée" (dixit Erik Simon), ceci dans le but de voir si le développement sur Amiga en valait vraiment la peine sur le plan financier. La réponse des utilisateurs d'amiga 500 et 1200 a été clairement positive, Lionheart s'est très très bien vendu, et Ambermoon a littéralement cartonné (en Allemagne). Mais malheureusement, Ambermoon était un projet bien trop ambitieux pour un si petit éditeur, et malgré l'argent rentré, Thalion a du mettre la clé sous la porte.

Pour te donner une idée, Le code programme seul d'Ambermoon fait 2,5mo pour chacun des 2 éxécutables. Il y a un certain nombre de bugs dans la version anglaise (le prototype donné par Erik Simon à Alex Hollander, le webmestre du site Thalion Webschrine). L'amiga 2000 de développement contenant le code source d'Ambermoon est parti à la benne..... Raison pour laquelle j'ai du ressourcer et désosser le programme. Ensuite, l'outil de génération de textes du jeu était buggé, j'ai découvert en décompressant les fichiers du jeu des énormités du style non affichage d'un pan entier de l'histoire à cause d'un défaut de caractère de définition. J'ai corrigé ça, et traduit tout le truc en français, il ne reste que le texte de l'outro à traduire correctement :) Tout le reste est en français, les sorts, les dialogues, etc, etc.).

Ambermoon je l'ai terminé dans les moindres recoins (débug de la VF), par contre, et je peux le dire, le jeu est aussi long voir plus que Final Fantasy 7 sur PSX, c'est dire le truc de ouf ! Quand on connait pas le jeu, faut au moins 6 mois entier en jouant 8 heures par jour pour en voir la fin, et fait 100% du jeu. Un joueur chevronné connaissant le jeu comme sa poche a besoin de 35 heures de jeu ininterrompu à minima pour en voir le bout.

La map principale du jeu est streamée depuis les disquettes ou le disque dur. La carte fait 5 mètres de long sur 3 mètres de haut, un truc de folie.

[dlfrsilver]

Pour la petite histoire, le codeur de Ambermoon sur Amiga n'est autre que Hexogen de TNT Crew sur Atari ST, connu entre autre pour la F.N.I.L demo (1988) et pour son screen 3D dans la Union demo sur ST :)

Rectification : Le codeur principal d'Ambermoon c'est Jurie Horneman (relayer). Mikal Bittnaaa (hexogen) n'a fait que coder la routine qui tue 3D texturée faces pleines du jeu.

Et Jurie habite à Lyon au cas ou héhéhé :)

[Seb]

Je parlais de la 3D, j'ai d'ailleurs rectifié mon post au moment ou tu postais le tiens apparemment.

[dlfrsilver]

j'ai rajouté un truc aussi :)

[Seb]

Hehe, oui je connais un peu Jurie et ses demos de l'époque, d'ailleurs son CV est passé chez nous il y a un an ou 2

[rocky007]

Merci pour le compliment, cependant je voudrais attirer ton attention sur plusieurs faits :

- Le programme n'existe pas même à l'état de prototype sur Atari ST, ni de graphismes, et voici pourquoi :

Jurie Hornemann a confié avoir passé 1 an/1 an et demi a reprogrammer intégralement tout ses outils de developpement de jeu, car les précédents ne tournaient que atari ST et rendaient impossible l'exploitation maximale de l'amiga.

Il a également indiqué avoir repris et reprogrammé from scratch ce qu'il avait fait sur ST, et qui existait en tant que première version sur amiga. Insatisfait de la médiocrité du résultat, il a tout repris et reprogrammé le jeu dans les règles de l'art (70-80 couleurs à l'écran, utilisation intensive du copper et du blitter, 3D texturée faces pleines, et ainsi de suite) pour l'amiga, qui était la machine du moment.

(PS 1 : outils atari ST lockés sur 16 couleurs, hyper limités dans leurs fonctions, et surtout, les outils étaient buggés!)

(PS 2 : Dragon Flight, un bon jeu RPG a été flingué à cause de ça, seule la version allemande peut être terminée, les version anglaises et françaises ont des bugs liés aux outils !)

Lionheart et Ambermoon avaient été conçus comme deux "missiles longue portée" (dixit Erik Simon), ceci dans le but de voir si le développement sur Amiga en valait vraiment la peine sur le plan financier. La réponse des utilisateurs d'amiga 500 et 1200 a été clairement positive, Lionheart s'est très très bien vendu, et Ambermoon a littéralement cartonné (en Allemagne). Mais malheureusement, Ambermoon était un projet bien trop ambitieux pour un si petit éditeur, et malgré l'argent rentré, Thalion a du mettre la clé sous la porte.

Pour te donner une idée, Le code programme seul d'Ambermoon fait 2,5mo pour chacun des 2 éxécutables. Il y a un certain nombre de bugs dans la version anglaise (le prototype donné par Erik Simon à Alex Hollander, le webmestre du site Thalion Webschrine). L'amiga 2000 de développement contenant le code source d'Ambermoon est parti à la benne..... Raison pour laquelle j'ai du ressourcer et désosser le programme. Ensuite, l'outil de génération de textes du jeu était buggé, j'ai découvert en décompressant les fichiers du jeu des énormités du style non affichage d'un pan entier de l'histoire à cause d'un défaut de caractère de définition. J'ai corrigé ça, et traduit tout le truc en français, il ne reste que le texte de l'outro à traduire correctement :) Tout le reste est en français, les sorts, les dialogues, etc, etc.).

Ambermoon je l'ai terminé dans les moindres recoins (débug de la VF), par contre, et je peux le dire, le jeu est aussi long voir plus que Final Fantasy 7 sur PSX, c'est dire le truc de ouf ! Quand on connait pas le jeu, faut au moins 6 mois entier en jouant 8 heures par jour pour en voir la fin, et fait 100% du jeu. Un joueur chevronné connaissant le jeu comme sa poche a besoin de 35 heures de jeu ininterrompu à minima pour en voir le bout.

La map principale du jeu est streamée depuis les disquettes ou le disque dur. La carte fait 5 mètres de long sur 3 mètres de haut, un truc de folie.

merci pour cette info très complète.  Je pensais qu'un proto existait, car dans certain articles / interview, on pouvait lire " When we came to convert Ambermoon from the Atari ST to the Amiga, we found that it had to be virtually rewritten and not just ported across as we'd hoped.  "   ( interview de Erik Simon, Jurie Horneman and Karsten Köper ) et sur le site officiel de Thalion, on trouve les screenshot de la version ST, images très proche de la version Amiga. ( http://thalion.exotica.org.uk/games/ambermoon/stuser.html )

Personnellement je n'ai aucun doute à la faisabilité sur un ST.  Je rappelle que Wolgenstein Ste tourne en plein écran et non en quart d'écran.



C'est un sacré boulot que tu as fait là, surtout sans le code source si j'ai bien compris ?  Comment t'es venu cette idée de traduire ce jeu ?

[dlfrsilver]

Merci pour le compliment, cependant je voudrais attirer ton attention sur plusieurs faits :

- Le programme n'existe pas même à l'état de prototype sur Atari ST, ni de graphismes, et voici pourquoi :

Jurie Hornemann a confié avoir passé 1 an/1 an et demi a reprogrammer intégralement tout ses outils de developpement de jeu, car les précédents ne tournaient que atari ST et rendaient impossible l'exploitation maximale de l'amiga.

Il a également indiqué avoir repris et reprogrammé from scratch ce qu'il avait fait sur ST, et qui existait en tant que première version sur amiga. Insatisfait de la médiocrité du résultat, il a tout repris et reprogrammé le jeu dans les règles de l'art (70-80 couleurs à l'écran, utilisation intensive du copper et du blitter, 3D texturée faces pleines, et ainsi de suite) pour l'amiga, qui était la machine du moment.

(PS 1 : outils atari ST lockés sur 16 couleurs, hyper limités dans leurs fonctions, et surtout, les outils étaient buggés!)

(PS 2 : Dragon Flight, un bon jeu RPG a été flingué à cause de ça, seule la version allemande peut être terminée, les version anglaises et françaises ont des bugs liés aux outils !)

Lionheart et Ambermoon avaient été conçus comme deux "missiles longue portée" (dixit Erik Simon), ceci dans le but de voir si le développement sur Amiga en valait vraiment la peine sur le plan financier. La réponse des utilisateurs d'amiga 500 et 1200 a été clairement positive, Lionheart s'est très très bien vendu, et Ambermoon a littéralement cartonné (en Allemagne). Mais malheureusement, Ambermoon était un projet bien trop ambitieux pour un si petit éditeur, et malgré l'argent rentré, Thalion a du mettre la clé sous la porte.

Pour te donner une idée, Le code programme seul d'Ambermoon fait 2,5mo pour chacun des 2 éxécutables. Il y a un certain nombre de bugs dans la version anglaise (le prototype donné par Erik Simon à Alex Hollander, le webmestre du site Thalion Webschrine). L'amiga 2000 de développement contenant le code source d'Ambermoon est parti à la benne..... Raison pour laquelle j'ai du ressourcer et désosser le programme. Ensuite, l'outil de génération de textes du jeu était buggé, j'ai découvert en décompressant les fichiers du jeu des énormités du style non affichage d'un pan entier de l'histoire à cause d'un défaut de caractère de définition. J'ai corrigé ça, et traduit tout le truc en français, il ne reste que le texte de l'outro à traduire correctement :) Tout le reste est en français, les sorts, les dialogues, etc, etc.).

Ambermoon je l'ai terminé dans les moindres recoins (débug de la VF), par contre, et je peux le dire, le jeu est aussi long voir plus que Final Fantasy 7 sur PSX, c'est dire le truc de ouf ! Quand on connait pas le jeu, faut au moins 6 mois entier en jouant 8 heures par jour pour en voir la fin, et fait 100% du jeu. Un joueur chevronné connaissant le jeu comme sa poche a besoin de 35 heures de jeu ininterrompu à minima pour en voir le bout.

La map principale du jeu est streamée depuis les disquettes ou le disque dur. La carte fait 5 mètres de long sur 3 mètres de haut, un truc de folie.

merci pour cette info très complète.  Je pensais qu'un proto existait, car dans certain articles / interview, on pouvait lire " When we came to convert Ambermoon from the Atari ST to the Amiga, we found that it had to be virtually rewritten and not just ported across as we'd hoped.  "   ( interview de Erik Simon, Jurie Horneman and Karsten Köper ) et sur le site officiel de Thalion, on trouve les screenshot de la version ST, images très proche de la version Amiga. ( http://thalion.exotica.org.uk/games/ambermoon/stuser.html )

Personnellement je n'ai aucun doute à la faisabilité sur un ST.  Je rappelle que Wolgenstein Ste tourne en plein écran et non en quart d'écran.



C'est un sacré boulot que tu as fait là, surtout sans le code source si j'ai bien compris ?  Comment t'es venu cette idée de traduire ce jeu ?

Traduction : " When we came to convert Ambermoon from the Atari ST to the Amiga, we found that it had to be virtually rewritten and not just ported across as we'd hoped.  "

En français : "Lorsqu'on en est venu à convertir Ambermoon de l'Atari ST vers l'amiga, on a découvert qu'il fallait virtuellement tout réécrire et pas seulement le porter comme on l'espérait"

J'ai découvert d'autre articles tirés de magazines allemand ou Jurie explique qu'il a du tout réécrire, et que la version ST a pour cette raison été abandonnée (le ST est incapable de supporter le jeu tel que tu peux le voir sur amiga, il y a trop de couleurs utilisées, un trop grand nombre de sprite, et le programme est trop lourd).
J'ajoute également que le jeu est plus à l'aise sur un 68030 qu'un 68000, même si sur un A500 le rendu est splendide.

Ambermoon souffre du même problème que Flashbask, le jeu tourne sur A500 étendu, mais les deux ont été en réalité fait pour tourner plus sur A1200 que sur A500. Il y a des ralentissements lors des combats même sur un 68030, alors imagine si le jeu avait été porté sur un ST ou STE..... Un jeu comme ça nécessite 25-50 fps et pas en dessous, ensuite pour te répondre, Wolfenstein 3D sur STE, tout est étant une belle prouesse est TRES LOIN du rendu 3D face pleine d'Ambermoon, pour te dire un peu, W3D sur STE utilise très peu de couleurs, les murs sont en 4 couleurs à peine, et les sprites enemis ont peu d'étapes d'animations. Dans Ambermoon quand tu te déplaces dans les environnements en 3D, chaque élément plaqué est en 16 couleurs, les sprites en 16 couleurs, il y a des textures animées et la plupart des sprites sont gigantissimes, la plupart font 128x128 pixels et jusqu'à 256x256 pixels le tout avec des zooms au pixel.

La première version que Jurie avait mis au point sur ST était surement bien plus spartiate que la version définitive, sans tout les effets présents sur la version définitive de l'amiga. C'est pour ça qu'il a tout repris de zéro. En 1995 l'éditeur ne pouvait pas se permettre de sortir un jeu avec la technologie utilisée sur ST à la fin des années 80. Et y a qu'à voir à quel point Amberstar est faible par rapport à Ambermoon. On dirait un jeu 8 bits en 16 couleurs.

Les photos de la preview du magazine ST user ne sont hélas pas celle de la version ST, mais de la version amiga à ses débuts. Il y a déjà beaucoup trop de couleurs à l'écran, de plus des photos écrans de cette version ont été publiés dans les magazines pour amiga de l'époque.

Pour ce qui est de ce travail monstrueux qui m'a pris un temps fou, les raisons étaient les suivantes :

- Le prototype anglais avait un grand nombre de bugs, répertoriés pour certains, et pas pour d'autres. Je les ai tous corrigé (des fixs d'autres personnes, et certains des miens jamais découvert avant), car ça amputait et dégradait le plaisir de jeu, soit une bonne 30aine.

- Le texte allemand d'origine comme le texte anglais sont d'un niveau faible. J'ai du donner de l'épaisseur au texte, car une fois traduit de l'original, c'était franchement plat.

- Le jeu comporte des énigmes, ces dernières ont été traduites de façon merdique en anglais, j'ai donc totalement rectifié le tir et traduisant ces dernières de l'allemand, et j'ai gardé dans notre langue le sens d'origine, tout en gardant les rimes de l'original. Résultat le joueur peut maintenant les résoudre sans s'arracher les cheveux comme dans la version anglaise.

- Un tel jeu pour en comprendre l'histoire correctement doit se jouer dans notre langue natale.

- Il fallait que je traduise en français la solution intégrale (dieu qu'elle est longue.....)

- Le jeu supporte le chargement des fichiers décompressés (le compresseur LOB sur atari ST est une merde sans nom à utiliser, dès que ce sera possible, un programmeur virera cette compression, et utilisera le compresseur RNC propack amiga, bien plus efficace).

[Invité]

ya des sacrées connaissances sur ce forum messieurs vous m'épatez a chaque fois.

@dlfrsilver : ta version traduite est dispo qqpart?

[cryodav76]

oui sur le forum amiga impact
http://www.amigaimpact.org/forums/topic/ambermoon-de-thalion-software-francais/

[rocky007]

En français : "Lorsqu'on en est venu à convertir Ambermoon de l'Atari ST vers l'amiga, on a découvert qu'il fallait virtuellement tout réécrire et pas seulement le porter comme on l'espérait"

oui DE l'atari vers l'amiga, cela veut dire qu'un proto devait exister

J'ai découvert d'autre articles tirés de magazines allemand ou Jurie explique qu'il a du tout réécrire, et que la version ST a pour cette raison été abandonnée (le ST est incapable de supporter le jeu tel que tu peux le voir sur amiga, il y a trop de couleurs utilisées, un trop grand nombre de sprite, et le programme est trop lourd).

selon Thalion, ils ont abandonné la version ST car le marche ST était mort, ils n'indiquent à aucun moment que ce serait d'un point de vue technique.
concernant le wolfenstion, tu oublies que la surface de travail est le double d'ambermoon.  en réduisant le fenêtre, je suis certain qu'on aurait pour obtenir un résultat très proche.  le moteur doom ci dessus en est la preuve, alors qu'il est plus complexe que celui d'ambermoon.

Les photos de la preview du magazine ST user ne sont hélas pas celle de la version ST, mais de la version amiga à ses débuts. Il y a déjà beaucoup trop de couleurs à l'écran, de plus des photos écrans de cette version ont été publiés dans les magazines pour amiga de l'époque.

afficher 70 couleurs sur St n'aurait pas posé le moindre problème, au contraire le jeu est idéalement construit pour qu'un ST puisse afficher les couleurs sans problème.
les phases de combats se font sur un décort fixe et ne sont pas très dynamique, là aussi cela n'aurait pas posé de problème de le faire sur le ST.  je trouve en fait ambermoon pas très technique en faite ( le scroll saccadé des phase dans les intérieurs par exemple )

mais tu m'as donné envie de l'essayer en français..j'étais fan de Alternate Reality lorsqu'il était sorti sur Atari 800 XL

[dlfrsilver]

En français : "Lorsqu'on en est venu à convertir Ambermoon de l'Atari ST vers l'amiga, on a découvert qu'il fallait virtuellement tout réécrire et pas seulement le porter comme on l'espérait"

oui DE l'atari vers l'amiga, cela veut dire qu'un proto devait exister

J'ai découvert d'autre articles tirés de magazines allemand ou Jurie explique qu'il a du tout réécrire, et que la version ST a pour cette raison été abandonnée (le ST est incapable de supporter le jeu tel que tu peux le voir sur amiga, il y a trop de couleurs utilisées, un trop grand nombre de sprite, et le programme est trop lourd).

selon Thalion, ils ont abandonné la version ST car le marche ST était mort, ils n'indiquent à aucun moment que ce serait d'un point de vue technique.

Les photos de la preview du magazine ST user ne sont hélas pas celle de la version ST, mais de la version amiga à ses débuts. Il y a déjà beaucoup trop de couleurs à l'écran, de plus des photos écrans de cette version ont été publiés dans les magazines pour amiga de l'époque.

afficher 70 couleurs sur St n'aurait pas posé le moindre problème, au contraire le jeu est idéalement construit pour qu'un ST puisse afficher les couleurs sans problème.
Je n'ai pas vu sur le vidéos lers phases de combats avec les sprite , zoom etc...toutes les vidéos que j'ai regardé était composé d'une bête balade dans les couloirs vides.. je vais regarder à nouveau.

C'est clair que l'amiga a un sacré avantage pour les sprites., mais le faire sur ST n'aurait pas impacté le framerate tant que cela.

Ce que tu appelles prototype a été détruit et effacé, il a refait le programme de A à Z.

Quand tu dis que Thalion a abandonné le marché ST car il était mort, c'est ni complètement vrai ni totalement faux. J'ai retrouvé l'article en allemand que je vous traduis ici :

"Le travail sur Ambermoon"

Pour Ambermoon on a participé à quelques sessions de brainstorming ou on réfléchissait à de nombreuses améliorations et des changements radicaux. De plus, on nous avait donné la deadline de notre manager ... Parce qu'on avait rangé toutes les idées d'Amberstar 2 sur une étagère, la ou elles sont Amberstar 3 repose en paix. On est en train de se décider sur comment faire une suite (avec le titre temporaire Amberstar 1 1/2) sans faire trop de changements techniques, mais que ceux-ci soit fait avec la plus grande efficacité possible. Bien sur, on a du refaire le programme presque tout entier et les changements n'étaient pas seulement d'ordre cosmétique, mais avaient significativement augmenté la complexité et la diversité. Tandis qu'on est en train d'écrire Amberstar en version étendue et pas un nouveau jeu entier, on a décidé d'utiliser à nouveau le code original. Il n'y a rien de pire pour un programmeur que de réutiliser du code qui a été écrit en pensant 'Je ne pourrais jamais le réutiliser, mais ça pourrait éventuellement marcher'. De plus, on a décidé de développer Ambermoon sur l'Amiga en 32 couleurs car le marché de l'amiga était plus fort que celui des STs. Cela m'a amené un nouveau problème, parce que les éditeurs étaient écrits sur le ST et utilisaient un mode 16 couleurs. J'ai également du apprendre à utiliser une toute nouvelle machine. Alors j'ai converti moi-même Ambermoon sur le ST, ou j'ai utilisé le même programme que celui utilisé dans Amberstar. J'ai divisé le programme en parties dépendantes de la machine, et indépendantes, l'implémentation sur ST était juste une question de réecrire la partie dépendante de la machine, et puis ça marcherait. Bien évidemment il y a plus à faire, cette méthode rend la conversion, cependante, plus facile.

Lorsque j'ai fait mon travail préparatoire sur le ST et que je me suis mis sur l'amiga on était le 14 Août 1992. Ceci incluait des choses telles que la gestion de la mémoire, une initialisation complète et la restauration de l'ordinateur, une simple sortie texte, tout un tas de routines graphiques, une gestion des interruptions raster, la gestion du clavier et du contrôle de la souris et la gestion de fichier. Comme Ambermoon devait tourner à la fois sur disquettes et sur disque dur, je devais utiliser l'OS. D'un côté, cela m'a épargné beaucoup de problèmes, de l'autre j'ai perdu un peu le contrôle sur l'ordinateur, mais au final tout s'est bien passé."

Etc etc.

En fait, quand je disais qu'il avait réécrit le programme, c'est pas tout à fait exact. D'après le texte ici, il indique qu'Ambermoon sur ST (ré-)utilisait le code d'amberstar, tandis que la version amiga était simplement une amélioration du code d'amberstar (et quelles améliorations !)

[rocky007]

merci pour ces infos... Thalion avait toujours l'esprit de faire le top sur ST, ( enchanted land, wings of death etc..), je suis certain qu'ils auraient pu faire un excellent jeu avec Ambermoon...

[dlfrsilver]

Ambermoon ST ressemblait apparemment à Amberstar d'un point de vue technique et couleur.

Mais franchement, quand tu vois le boulot monstre que ce logiciel a demandé, c'était juste trop pour une si petite équipe. Ambermoon est sorti sur amiga et il avait du retour, et le jeu avait déjà sur la version originale allemande des bugs, dont certains assez vilains..... Puis thalion a sorti des mises à jour, et le jeu est passé de la version 1.00 à la 1.02, puis la v1.05 qui corrigeait des bugs de la 1.02 qui rendait le jeu affreux à jouer. Le prototype anglais porte le numéro de version 1.07, et la version française la 3.00 (j'ai apporté tellement de modifs et fixes que j'ai monté le numéro de version).

[Seb]

Rapport aux posts précédents, le truc d'avoir plus de 16 couleurs par ligne sur ST est un trip de demomaker (et de Spectrum 512), c'était plus ou moins inappliquable en pratique pour un jeu, sauf pour des images statiques.

Ca bouffe trop de temps machine, ca demande d'avoir des frames à temps constant et d'insérer le code du jeu entre les changements de palette en comptant les cycles de chaque instruction, ce qui est un horrible casse-tête pour un jeu.

Par contre, du classique changement de palette à certaines lignes à coups de timer était évidemment courant.

   

[rocky007]

justement, ambermoon ayant 3 zones différentes horizontales bien distinctes, il était facile d'avoir sa propre palette par chacune de ces zones et un dégradé dans la zone d'action.

[dlfrsilver]

oui sur l'amiga, mais sur le ST, non, car comme je l'expliquais, le jeu ralenti sérieusement à certains moment même sur un A1200 doté d'un 68030. Et ça hors des moments ou on évolue dans les environnements 3D. Les zones de couleurs sont gérées par le copper, donc ça ne bouffe rien sur l'amiga.

Mais voilà, comment un ST avec un simple 68000 pourrait mieux faire qu'une machine full 32 bits avec un 68030 tournant à 50 mhz sur la partie combats avec les animations et zooms sans compter les sprites de 128x128 et 256x256 ?

[Seb]

justement, ambermoon ayant 3 zones différentes horizontales bien distinctes, il était facile d'avoir sa propre palette par chacune de ces zones et un dégradé dans la zone d'action.

Pour les séparations haut/bas oui c'est possible et plein de jeux le faisaient sur ST (cf screenshots au dessus)

Pour les séparation gauche/droite, non, c'est juste trop compliqué sur ST, ca demande une synchro sur chaque ligne, ca bouffe un temps fou de changer la palette 2 fois par ligne et il faut intégrer le code du jeu entre les changements de palette au cycle près, tout ca en s'assurant qu'il soit constant, ce qui est une utopie pour un jeu, sauf peut être un avec à scrolling vertical dans lequel 50% de la frame serait dédié à faire des centaines de movem. Dans ce cas on pourrait placer ces instructions dedans mais même là ca serait de la folie.

Ce genre de magouille rend l'utilisation de branchements conditionnels dans le code intégré entre les changements de palettes très pénibles à gérer, et tout ce qui est tests avec des "if". Un jeu est truffé de "if" pour la partie gameplay et d'instructions à temps non constant pour les calculs 3D (muls, divs etc).
On peut compenser le temps non constant des "if" et des branchement en remplissant le code de NOPs pour "égaliser" le temps de chaque branchement, mais ca fait évidemment perdre du temps machine.

Bref, c'était une belle astuce de demomaker, ca marchait sur papier et dans les demos, mais c'était en pratique inutilisable pour un jeu commercial.

L'écran de Delta Force ci-dessous utilisait cette méthode, en changeant la palette une fois au debut de la ligne, et une fois au milieu (l'effet met du temps à demarrer, on voit mieux vers 3:00).
Le reste du temps machine était probablement utilisé à faire des copies des zones du texte avec toutes les tailles de zoom de 15 couleurs déjà précalculées. Donc du bon movem.l à temps constant, sans "if", ni calculs 3D, ni code de gameplay, probablement juste de l'indexation avec une table (lookup table). C'est à l'opposé de ce qu'on voit dans un jeu niveau code.

Beaucoup de jeux étaient fait en C au passage, soit à 100% soit avec quelques routines en assembleur pour les choses critiques. Le mix C / Assembleur aurait rendu la tache d'intégrer du code à temps constant entre les synchros de palette encore plus impossible :)

Pour la petite histoire, Glenn Corpes m'avait raconté qu'il avait codé Populous en C puis plus tard Powermonger en Assembleur mais qu'il avait trouvé que le passage a l'Assembleur n'avait finalement pas valu le coup pour ce jeu.

[Julien Amandine]

slt tt le monde^^

je voie encore que le st vs amiga existe encore^^

le st c'est pourrie, les composant sont cheap parce que c'est fais en Israêl

l'amiga ça cartonne parce que c'est pas fais pour les pauvres^^

y a pas un forum atari tout pourrie aussi ? je sait pas sa fais tellement lontemps que de vous lire sa m'as rappellé des souvenirs

dlfrsilver : super génial de travail, merci :)

[dlfrsilver]

justement, ambermoon ayant 3 zones différentes horizontales bien distinctes, il était facile d'avoir sa propre palette par chacune de ces zones et un dégradé dans la zone d'action.

Pour les séparations haut/bas oui c'est possible et plein de jeux le faisaient sur ST (cf screenshots au dessus)

Pour les séparation gauche/droite, non, c'est juste trop compliqué sur ST, ca demande une synchro sur chaque ligne, ca bouffe un temps fou de changer la palette 2 fois par ligne et il faut intégrer le code du jeu entre les changements de palette au cycle près, tout ca en s'assurant qu'il soit constant, ce qui est une utopie pour un jeu, sauf peut être un avec à scrolling vertical dans lequel 50% de la frame serait dédié à faire des centaines de movem. Dans ce cas on pourrait placer ces instructions dedans mais même là ca serait de la folie.

Ce genre de magouille rend l'utilisation de branchements conditionnels dans le code intégré entre les changements de palettes très pénibles à gérer, et tout ce qui est tests avec des "if". Un jeu est truffé de "if" pour la partie gameplay et d'instructions à temps non constant pour les calculs 3D (muls, divs etc).
On peut compenser le temps non constant des "if" et des branchement en remplissant le code de NOPs pour "égaliser" le temps de chaque branchement, mais ca fait évidemment perdre du temps machine.

Bref, c'était une belle astuce de demomaker, ca marchait sur papier et dans les demos, mais c'était en pratique inutilisable pour un jeu commercial.

L'écran de Delta Force ci-dessous utilisait cette méthode, en changeant la palette une fois au debut de la ligne, et une fois au milieu (l'effet met du temps à demarrer, on voit mieux vers 3:00).
Le reste du temps machine était probablement utilisé à faire des copies des zones du texte avec toutes les tailles de zoom de 15 couleurs déjà précalculées. Donc du bon movem.l à temps constant, sans "if", ni calculs 3D, ni code de gameplay, probablement juste de l'indexation avec une table (lookup table). C'est à l'opposé de ce qu'on voit dans un jeu niveau code.

Beaucoup de jeux étaient fait en C au passage, soit à 100% soit avec quelques routines en assembleur pour les choses critiques. Le mix C / Assembleur aurait rendu la tache d'intégrer du code à temps constant entre les synchros de palette encore plus impossible :)

Pour la petite histoire, Glenn Corpes m'avait raconté qu'il avait codé Populous en C puis plus tard Powermonger en Assembleur mais qu'il avait trouvé que le passage a l'Assembleur n'avait finalement pas valu le coup pour ce jeu.

Erik Simon l'a d'ailleurs dit lui-même : au final les gens n'en avaient rien à carrer des astuces hyper compliquées à mettre en place sur Atari ST, et il a également ajouté que l'amiga avait le meilleur hardware de son époque (ce qui ne l'a pas empêché de faire des trous dans des murs et des portes chez Thalion car il n'utilisait pas correctement le blitter de l'amiga, ce qui l'énervait passablement

[dlfrsilver]

slt tt le monde^^

je voie encore que le st vs amiga existe encore^^

le st c'est pourrie, les composant sont cheap parce que c'est fais en Israêl

l'amiga ça cartonne parce que c'est pas fais pour les pauvres^^

y a pas un forum atari tout pourrie aussi ? je sait pas sa fais tellement lontemps que de vous lire sa m'as rappellé des souvenirs

dlfrsilver : super génial de travail, merci :)

Non les puces n'était pas fabriqué en Israel mais dans les pays asiat. Cependant il est clair que pour tirer les prix vers le bas au maximum, les composants de l'atari ST étaient clairement pas de 1ère qualité. C'est juste une évidence, à l'époque de sa vente, la RAM, les TTL coutaient très cher, donc forcément pour casser le cout de l'ordinateur, ils ont fait déjà un hardware à la va vite, et ils ont utilisés des composants à pas cher.

De rien pour Ambermoon :)