Re: GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée)

[Jacques Atari]

Dans le même style sur ST, il y a Fire & Ice et c'est tout aussi chiant. Toutes ces bestioles (Bubsy, Zool, Mister Nutz, Brian etc.) sont des imitations occidentales de Sonic, qui n'était déjà pas très passionnant...

[Zarnal]

Après, c'est le principe de la simple plateforme.

A part avancer/esquiver/sauter et zigouiller, que demander de plus ? A part peut être des passages secrets.

[stapha92]

Firebird,

Pour le fond en tunnel qui scrolle, je pense qu'ils étaient limités par la quantité de RAM.

Techniquement, la méthode utilisée est compatible avec un scrolling horizontal. Le problème est que l'effet de zoom est obtenu, en partie, en modifiant le nombre de pixel à scroller (de 0 à 15) à des positions précises pour faire disparaitre certains pixels.
Cela est fait par le copper car lui seul peut obtenir la précision nécessaire.

Si tu ajoute un scroll horizontal, la première valeur à mettre n'est plus 1 mais le nombre de pixels du scroll initial + 1.
Ce qui signifie que tu dois avoir 16 copperlists pour que ton scroll soit compatible avec l'effet. Et elle ne sont pas petites puisque les pixels à supprimer sont différents à chaque ligne : on ne peut pas utiliser de boucle...
Tu peux aussi jouer sur la texture mais c'est pire : il te faut 16 fois la même image pré-shiftée.
Edit : en fait, cette solution aurait été moins gourmande en RAM. 


Pour les palmiers par contre, il s'agit d'un sprite multiplexé qui n'est pas très haut. Donc pas RAM supplémentaire pour un scroll. La seul contrainte technique serait que ce sprite soit utilisé à d'autres hauteurs. Ce qui limiterait le scroll vertical. Mais ce n'est pas le cas : les seuls autres sprites sur l'écran sont ceux du HUD et du personnage et ce sont les même qui sont réutilisés.

D'ailleurs, sur la version AGA, il ont remplacé les sprites multiplexés par un 2eme playfield en 16 couleurs. Il auraient pu l'animer verticalement sans surcout et ils avaient 1 Mo de RAM en plus. Je pense donc que c'était voulu.

[babsimov]

Ben oui Rexx existe sur PC ... Rexx est à l'origine un langage IBM pour ses gros systèmes

Oui, Arexx a été porté sur Amiga suite à l'échange de technologie entre Commodore et IBM. IBM voulait de la techno issue de l'AmigaOS (et en a utilisé pour OS/2). Mais IBM est une petite entreprise anecdotique qui n'y connait rien, sinon ils auraient récupéré le superbe GEM pour savoir comment mettre cette limite de 4 fenêtres...
A l'inverse, Apple n'a même pas attaqué Atari pour le GEM, alors qu'ils l'ont fait pour la version PC...

Donc IBM prenait au sérieux l'OS du mig et Apple (qui a l'habitude d'attaquer à tout va) ignorait celui du ST. Intéressant...

Un écran VGA à 700 frs en 1991 ? Un monochrome peut être.... mais là un VGA 14 pouces couleurs c'est déjà 3200 frs.... et à 700 frs on a un écran Hercules (monochrome).... Et 1024x768 sur un 14 pouces c'est un peu limite niveau lisibilité.

Du reste en 1991 nous avons l'ECS sur Amiga... et de toute façon le Flicker Fixer n'était nullement une obligation comme je te l'ai dit. Les cartes RTG deviendront un must have sur Amiga après la fin de Commodore. Mais il y en avait aussi avec des performances équivalente à celle que tu présentes. Mais c'était pour le pro ça. 

Ne te laisse pas avoir. Qu'est-ce que tu fais avec ta CG si tu ne peux pas accélérer efficacement ton ST ?
Son architecture empêche même un 68000 de s'exprimer pleinement quand il tourne à 16 Mhz, malgré la mémoire cache qui a été ajoutée pour compenser partiellement...
Le TT est bien plus efficace : pour profiter de son processeur, il a fallu revoir l'architecture et copier le mig en mettant de la fast-ram (renommée TT-Ram). Dommage que, le principe n'étant pas en standard dès le départ, il n'a pas été efficacement intégré dans l'OS ( je n'abordais pas le hack honteux mis en place sur les entêtes d'exécutables) et les programmes ne l'exploite pas au mieux, contrairement au mig.

Pour le désentrelaceur : attention, il adapte le signal à un écran Multisync en doublant les trames. Donc il te permet d'obtenir du 720x576 en 16 couleurs non entrelacées. Rien à voir avec le mode monochrome du ST qui tourne sur un écran dédié : il te faut 2 écrans pour avoir tous les modes.
Et effectivement, un amiga ecs fait la même chose en 4 couleurs sans extension : toujours 2 fois plus que le ST.

J'ai vu que l'on comparait le rendu en 3D. Le ST est plus rapide mais on fait quoi comme 3D avec un 68000 ? Même avec la vitesse vertigineuse de 8 Mhz, c'est trop léger...
De toute façon, sans fpu, pas de 3D sérieuse. ça tombe bien ! même un a500 peut avoir une carte accélératrice sans rien démonter ! Pas le ST. Et même en démontant, y a de gros soucis, niveau hardware et os...

Mais admettons : Donc 4H pour un ST et 4H30 pour un mig. Ok. Un point pour le ST.
Sauf que sur mig, pendant le calcul, tu peux continuer à travailler sur la prochaine image. Même si ça rallonge le rendu à 5H, ça sera plus pratique...


Et pour les basics : Amos est pas mal. Et il n'est pas juste adapté au chipset, il propose d'autres choses comme AMAL. Un sous-langage qui permet de gérer des éléments par interruption. Donc qui s'appuie purement sur le 68000 :

http://obligement.free.fr/articles/amos_amal_animation.php

Y a pas que pour le chpiset qu'Amos a été adapté...

Sinon pour l'intégration avec l'OS. C'est vrai que j'aurai préféré. Cela dit, Amos est compatible avec tous les amigas. Donc quel est le problème ?
Et tant qu'à parler d'intégration : pourquoi le GFA du ST ouvre un écran pour faire un simple print alors que le mig le fait dans une fenêtre ? D'ailleurs, cette fenêtre peut être déplacé et redimensionné PENDANT que le programme GFA écrit dedans. J'ai déjà expliqué que le multitache permet aussi la programmation événementielle, indispensable aujourd'hui et déjà existante dans l'AmigaOS. Ben là on a un exemple : voir les vidéos que j'avais postées après que quelqu'un ait affirmé que le GFA du ST était beaucoup plus rapide. Malgré le multitâche et la gestion de la fenêtre, ce n'était pas le cas.
J'aimerai voir combien de lignes de code en GFA ST il faut pour répéter un "hello world" dans une fenêtre tout en permettant de la redimensionner et de la déplacer...


De toute façon, Amos ou GFA on s'en moque : le meilleur basic est le blitz. 
Tout est entièrement intégré à l'os et il peut créer des applis system ou des jeux. Il est extensible via des librairies. Il a un environnement totalement personnalisable (on peut utiliser l'éditeur de texte que l'on veut par exemple).


Et il a été utilisé pour créer ça :




ou ça (autre jeu/licence qui a une encore une notorité aujourd'hui) :



Et puis en langage vraiment sympa, il ne faut pas oublier le E qui intègre la programmation orientée objet...

Merci pour toutes ces précisions, c'est encore une fois intéressant.

[dlfrsilver]

Je pense c'est un choix des développeurs plus qu'une contrainte technique.
Le but de l'équipe était de faire mieux que ce qu'on trouvait sur SNES, et ils ont réussi. Les rotations sont plus fines et moins crues que sur SNES.

Je savais qu'on allait avoir une réponse de Silver façon "Je t'explique le code". C'est plus fort que lui hein, il faut qu'il brille et étale sa science de mytho... Et avec en prime:

- "Nan, c'est pas une contrainte de l'Amiga, c'est fait exprès!"

Sous-entendre, l'Amiga peut tout faire.

Rétablissons la réalité: Brian The Lion, c'est comme SOTB: une très belle démo mais clairement pas un jeu. C'est d'une pauvreté ludique rare. On saute, on met des baffes, on saute, on saute et on saute encore... C'est nul. Les décors semblent toujours les mêmes en plus. Alors, je sais, Silvy va encore nous dire:

- "Ouin ouin, tu dis ça parce que c'est impossible de faire ce jeu sur ST, fils de pute de golem!"

Que répondre à ça? Rien, c'est trop chiant.

Brian The Lion me rappelle Bubsy sur Super Nintendo. Hein? Mais non, pas l'autre ringard qui a gardé son Amiga jusqu'en 98 et qui a attendu 20 ans pour avoir l'USB 1 dessus, ça c'est Babsy. Non, là je parle de Bubsy, vous savez, le chat à la con avec un pull. Et oui, tout ça, c'est pareil. Brian est un lion en slip, Bubsy est un chat en pull... Et c'est exactement le même niveau de jeu: nul à chier! Un pote avait acheté Bubsy en 1993 je me rappelle et m'avait passé la cartouche. Quel ennui! Il saute, attrape des pelotes de laine, et saute, et saute et saute encore... On s'éclate, c'est dingue... Bubsy est juste plus rapide et y'a des scrollings dans toutes les directions. La preuve:



Brian The Lion un jeu. Ahahaha! Finalement, je crois que je préfère The Settlers, ça semble moins con et répétitif. Les jeux Amiga, ça ne se jouait pas, ça se regardait, c'est tout. Insérez ici vanne de gamin façon: "Ouais ben le ST, ça ne se joue pas et ça ne se regarde pas non plus, golem, gnahahaha!"

Tout est question de gout. Moi perso Dungeon Master m'ennuie à un point que t'imagines pas. 

The Settlers est sympa :) 

Sim City 2000 sur ST ? Mais tu rêves des genoux ! Un A1200 avec 68040 arrive à peine à le faire tourner 

la version A1200 requiert un écran capable de supporter un affichage de type SVGA 

Je comprends pas ton poste en fait. T'aimes pas les platformers, ok. Est-ce que moi je ponds un pavé pour dire tout le mal que je pense de Dungeon Master ? 

Non, car EOB 1 et 2 sont sublimes à côté de lui et infiniment plus immersif, avec un scénario et des graphismes exceptionnels.

[rocky007]

Sim City 2000 sur ST ? Mais tu rêves des genoux ! Un A1200 avec 68040 arrive à peine à le faire tourner 

la version A1200 requiert un écran capable de supporter un affichage de type SVGA 

eh oui c'est là qu'on voit la cochonnerie d'architecture Amiga.. même un A1200 68060 à 100MHz ne sait pas tourner le jeu fluidement..et tu nous apprend qu'il faut en plus un écran à 30000FF..
par contre, il tourne sur une SNES     donc oui , très facile un Falcon 030, si pas un ST 

[babsimov]

Sim City 2000 sur ST ? Mais tu rêves des genoux ! Un A1200 avec 68040 arrive à peine à le faire tourner 

la version A1200 requiert un écran capable de supporter un affichage de type SVGA 

eh oui c'est là qu'on voit la cochonnerie d'architecture Amiga.. même un A1200 68060 à 100MHz ne sait pas tourner le jeu fluidement..et tu nous apprend qu'il faut en plus un écran à 30000FF..

C'était connu que c'était un très mauvais portage en terme d'optimisation et il faut aussi reconnaitre que l'AGA était quand même lent en 256 couleurs haute résolution. C'est là qu'on voit qu'il aurait du sortir en 1987/88 et non en 1992. Donc je pense que le problème est un mix des deux, lenteur AGA en 256 couleurs haute résolution et manque d'optimisation.



En émulation MAC il tourne mieux, ce qui montre que le portage sur Amiga a été malgré tout un tantinet mal fait.
http://forum.amiga.org/index.php?topic=61120.0

D'ailleurs MAXIS le savait puisqu'ils ont fourni un patch en 1995 :
http://aminet.net/package/game/patch/SimCity2000pch

Autrement, là tout à coup en 1994, selon toi, un écran SVGA c'est 30000 frs.... quand on a vu qu'en 1991 c'était 3200 frs. (enfin toi tu disait 700 frs en 1991 pour avoir un écran capable d'afficher du 24 bit en 640x400 ou 800x600). 
Ah oui, c'est en 1994 que j'ai acheté mon 1960 (multisynchro) d'occasion et de mémoire j'ai pas du acheter ça plus de 2000 frs, sachant que j'avais du revendre mon 1084 dans les 1000 frs. Et ce moniteur affichait toutes les résolution Amiga à partir du 15khz...
 https://bigbookofamigahardware.com/bboah/product.aspx?id=857

par contre, il tourne sur une SNES        donc oui , très facile un Falcon 030, si pas un ST  

C'est sur que la version SNES c'est pas tout à fait pareil :



Et sinon de toute façon un ST de base tu peux oublier, vu que la configuration minimum c'est 4MO de RAM, 256 couleurs et 640x480 et disque dur... et 386 25 mhz... 
Ou sinon t'a quelque chose du style de la SNES, mais on peut pas vraiment dire que c'est équivalent graphiquement (et même pas sur puisqu'il me semble que graphiquement la SNES est capable de mieux que le ST en terme de couleurs affichable simultanément sans bidouille).

https://www.computerhope.com/games/games/simcity.htm

Operating System:	MS-DOS 5.0, Windows 3.1
Processor:	Intel 386 25 MHz Intel 486 33 MHz (CD-ROM edition)
Memory:	4 MB RAM 8 MB RAM (CD-ROM edition)
Graphics Card:	SVGA graphics, 256 colors, 640 X 480 resolution 512 KB Video RAM required for CD-ROM edition
Sound Card:	Windows compatible sound card
Hard Drive Space:	7 MB
Drives:	3½″ Floppy Drive or 2X CD-ROM
Controls:	Keyboard & Mouse
Multiplayer:	n/a

Donc même sur Falcon avec de base à 16 mhz je pense bien que tu peux oublier et ça aurait ramé tout pareil, à moins que le DSP soit utilisé, mais vu le portage "douteux" de la version Amiga, je doute qu'ils aient été utiliser le DSP.

Et de toute façon il semble que le jeu ramait déjà sur la configuration minimale sur PC :
https://groups.google.com/g/comp.sys.amiga.games/c/2S4HmRKLdLs

"The fact is that games like SC2000 really NEED
a lot of hardware power. The game is slow even on a 25Mhz 386
PC which is roughly equivalent to an A1200 w/fastram."

Il faut cependant noter que Maxis avait jugé qu'en 1994 le marché Amiga était encore suffisamment rentable pour y porter leur jeu, surtout que c'est uniquement sur la génération AGA qui n'était pas la plus répandue.

[dlfrsilver]

Sim City 2000 sur ST ? Mais tu rêves des genoux ! Un A1200 avec 68040 arrive à peine à le faire tourner 

la version A1200 requiert un écran capable de supporter un affichage de type SVGA 

eh oui c'est là qu'on voit la cochonnerie d'architecture Amiga.. même un A1200 68060 à 100MHz ne sait pas tourner le jeu fluidement..et tu nous apprend qu'il faut en plus un écran à 30000FF..
par contre, il tourne sur une SNES     donc oui , très facile un Falcon 030, si pas un ST 

Le jeu a été porté de la version MAC 68040.

[Jacques Atari]

Je pensais que la version Amiga de Sim City 2000 était pratiquement égale à celle du PC, j'ai pas dû voir le bon truc à l'époque. Pourtant, je ne vois pas trop ce qu'il y a de compliqué dans ce jeu. Trop de trucs à gérer en même temps?

[rocky007]

Je pensais que la version Amiga de Sim City 2000 était pratiquement égale à celle du PC, j'ai pas dû voir le bon truc à l'époque. Pourtant, je ne vois pas trop ce qu'il y a de compliqué dans ce jeu. Trop de trucs à gérer en même temps?

ouaip c'est comme Settlers, si l'animation se fait à 10 FPS, c'est parce les 40 frames restantes servent uniquement à mettre à jour toutes les paramètres du jeu de tout l’environnement visible+invisible contrairement à un jeu d'arcade où tu peux mettre à jour que ce qui apparait sur l'écran..

même si je ne connais pas le jeu dans les détails, ni la quantité de paramètres que Sim City 2000 doit mettre à jour, mais ça me parait excessivement lent quand même.

[rocky007]

C'était connu que c'était un très mauvais portage en terme d'optimisation et il faut aussi reconnaitre que l'AGA était quand même lent en 256 couleurs haute résolution. C'est là qu'on voit qu'il aurait du sortir en 1987/88 et non en 1992. Donc je pense que le problème est un mix des deux, lenteur AGA en 256 couleurs haute résolution et manque d'optimisation.

et oui, comme disait ton mentor, c'est bien joli d'avoir une haute reso graphique et plein de couleurs mais quand tu as un architecture à la ramasse qui ne sait pas le gérer, ça ne sert pas à grand chose.

Et sinon de toute façon un ST de base tu peux oublier, vu que la configuration minimum c'est 4MO de RAM, 256 couleurs et 640x480 et disque dur... et 386 25 mhz...

oui sur une version mal codé, mal optimisée... la SNES a-t-elle 4mo de RAM ? un 386 25 Mhz ? ben non il petit cpu à 3.58 mhz et 128ko de RAM.  tu vois comme quoi avoir la plus grosse ne prouve rien  

Donc même sur Falcon avec de base à 16 mhz je pense bien que tu peux oublier et ça aurait ramé tout pareil, à moins que le DSP soit utilisé, mais vu le portage "douteux" de la version Amiga, je doute qu'ils aient été utiliser le DSP.

bien sûr que oui le DSP aurait le point crucial puisqu'il aurait pu faire tout les traitements sur les données du jeux...cela n'aurait pas été facile vu la spécifité du DSP, mais cela aurait largement soulagé le 68030.

[dlfrsilver]

Sim City 2000 sur SNES a été revu à la baisse. Y a au moins 128 couleurs, autant de paramètres, mais exit la résolution SVGA. Le jeu est en basse résolution. 

Le mec qui a converti Sim City 2000 sur A1200-4000 C'est John John-Steele..... 

Et franchement, convertir le jeu pour Falcon 030 avec le tout petit parc de machine installée, même pas. Car le DSP, s'il est puissant, y a pas masse de mecs qui sachent le coder. 

Pourquoi vous croyez que les éditeurs globalement ont rejeté le Falcon 030 ? Trop compliqué, trop spécifique, pas assez de machines.

Ceux qui ont sortis les 30 jeux commerciaux ont pris un risque énorme, acheter un jeu original falcon 030, c'est super chaud, y a eu peu d'exemplaires vendus, et ceux là se vendent à des prix stratosphériques......

[dlfrsilver]

Je pensais que la version Amiga de Sim City 2000 était pratiquement égale à celle du PC, j'ai pas dû voir le bon truc à l'époque. Pourtant, je ne vois pas trop ce qu'il y a de compliqué dans ce jeu. Trop de trucs à gérer en même temps?

La version Amiga AGA est un portage de la version 68040 du mac, qui elle même a été portée de la version PC originale. Les 2 version AM/MAC sont en HD, et sont identiques à la version PC. 

Le code n'a pas été optimisé clairement, c'est un portage à l'arrache du code 68040 (avec une grosse partie en C) non optimisé. Si ma mémoire me fait pas défaut, c'est le taux de refresh écran qui est mortel, pour lequel il faut un écran multisync, et pas un écran 15khz classique, sinon ça scintille de dingue, et faut un 68030 - 50mhz pour avoir une vitesse à peine potable. 

Faut utiliser la version mac native sous shapeshifter, avec 4mo de chip et 8mo de fast, plus rapide.

[Anarwax]

ah sim city 2000, bon jeu oui, sur pc

le falcon est sorti trop tard, bien dommage, sacrée bécane

[rocky007]

Sim City 2000 sur SNES a été revu à la baisse. Y a au moins 128 couleurs, autant de paramètres, mais exit la résolution SVGA.

Ce n'est pas la résolution qui ralenti le jeu


Mais encore une preuve qu'une fois le codeur Atari se sont bare sur PC, il n'y avait plus personne pour faire des jeux Amiga

[Copper]

C'est vrai que beaucoup d'Ataristes sont passés sur 1200 (car le Falcon était forcément trop cher pour eux) c'est sans doute pour ça que la qualité des softs n'a jamais été exceptionnelle sur cette génération de machine

Alors que les derniers jeux OCS comme Settlers restent exceptionnels...

[rocky007]

C'est vrai que beaucoup d'Ataristes sont passés sur 1200 (car le Falcon était forcément trop cher pour eux) c'est sans doute pour ça que la qualité des softs n'a jamais été exceptionnelle sur cette génération de machine

Alors que les derniers jeux OCS comme Settlers restent exceptionnels...

ouais c'est clair que vous pouvez être fier de Settler, un jeu avec 16 couleurs et 48 nuances de noirs.
c'est le problème de l'Amiga, soit tu utilises à fond les copros et le jeu est naze, soit tu fais du statique et le jeu est intéressant mais ressemble à un jeu ST

[rhod-atari]

ce qui est bien avec ce topic, c'est que tu reviens dans 1 ou 2 an(s),
on lira les mêmes choses et chacun n'aura pas changé d'avis et restera dans son camp
en disant que sa machine est la meilleure.

[dlfrsilver]

Sim City 2000 sur SNES a été revu à la baisse. Y a au moins 128 couleurs, autant de paramètres, mais exit la résolution SVGA.

Ce n'est pas la résolution qui ralenti le jeu


Mais encore une preuve qu'une fois le codeur Atari se sont bare sur PC, il n'y avait plus personne pour faire des jeux Amiga

John Jones-Steele est à la base un programmeur Atari   Tu disais ? 

La résolution ralenti le jeu si, justement. l'Amiga a énormément de mal à rafraichir l'écran, car je suppose que Jones-Steele a utilisé des routines C2P crades ou mal optimisées. 

Ensuite à cette période, restait des programmeurs Amiga justement. La plupart des jeux n'était pas programmés par le même coder (version PC codé par un programmeur PC natif, version Amiga par un spécialiste de la machine).

[dlfrsilver]

C'est vrai que beaucoup d'Ataristes sont passés sur 1200 (car le Falcon était forcément trop cher pour eux) c'est sans doute pour ça que la qualité des softs n'a jamais été exceptionnelle sur cette génération de machine

Alors que les derniers jeux OCS comme Settlers restent exceptionnels...

ouais c'est clair que vous pouvez être fier de Settler, un jeu avec 16 couleurs et 48 nuances de noirs.
c'est le problème de l'Amiga, soit tu utilises à fond les copros et le jeu est naze, soit tu fais du statique et le jeu est intéressant mais ressemble à un jeu ST

48 nuances de noirs ? T'as envie d'attirer les wokes ici, ça se passe comment ? 

C'est tout le problème du ST, sois tu fais du statique et ça ressemble à un jeu naze de 1985, soit tu utilises à fond le chipset sur Amiga, et tu as un bon confort de jeu AAA de 1994.

[dlfrsilver]

ah sim city 2000, bon jeu oui, sur pc

le falcon est sorti trop tard, bien dommage, sacrée bécane

Le GEM aurait du être refait du sol au plafond. C'est imbitable qu'ils aient laissé le GEM dans le même état qu'en 1985.

Fallait étoffer le tout, passer en 256 couleurs direct, foutre en l'air la compatibilité avec l'Atari STF/E, et bon sang, utiliser l'accélération matérielle pour l'affichage. 

Sacré proto plus que sacrée bécane (elles n'étaient pas finalisées quand Atari les a vendu sur le marché).

[Copper]

ouais c'est clair que vous pouvez être fier de Settler, un jeu avec 16 couleurs et 48 nuances de noirs.
c'est le problème de l'Amiga, soit tu utilises à fond les copros et le jeu est naze, soit tu fais du statique et le jeu est intéressant mais ressemble à un jeu ST

Le vrai problème c'est les jeux qui se limitent à cause de l'Atari ST... C'est un peu comme si les jeux PS5 se limitaient à cause de la switch...

Un jeu comme Lotus Turbo Challenge II j'ai pas envie d'y jouer sur ST, c'est moins beau, c'est moins fluide et puis sans les digits vocales ca n'a pas non plus le même charme... Sur Amiga le jeu est excellent sur le ST le jeu est juste moyen (heureusement que la version Amiga n'est pas un portage de la version ST)

[Jacques Atari]

Un jeu comme Lotus Turbo Challenge II j'ai pas envie d'y jouer sur ST, c'est moins beau, c'est moins fluide et puis sans les digits vocales ca n'a pas non plus le même charme... Sur Amiga le jeu est excellent sur le ST le jeu est juste moyen (heureusement que la version Amiga n'est pas un portage de la version ST)

J'ai pas aimé le 2 non plus, y'a rien de plus par rapport au 1, sauf que c'est BEAUCOUP plus difficile... Je me demande aussi si la voiture n'est pas plus petite que dans le 1. En tout cas, le Lotus version STE sorti l'an dernier est gentil mais n'apporte, lui non plus, pas grand-chose. De ce jeu, je préfère la version Super Nintendo qui écrase tout le monde:

[babsimov]

Je pensais que la version Amiga de Sim City 2000 était pratiquement égale à celle du PC, j'ai pas dû voir le bon truc à l'époque. Pourtant, je ne vois pas trop ce qu'il y a de compliqué dans ce jeu. Trop de trucs à gérer en même temps?

De mémoire à l'époque je l'avais joué, et le consensus des tests était qu'il y avait un problème d'optimisation du jeu, vu qu'en émulation MAC le jeu tourne mieux sur la même configuration Amiga.

Mais, il y aussi l'AGA. Tu n'as pas connu ce chipset, mais en gros son problème était que le blitter et le copper sont restés les mêmes que l'OCS de 1985 et tournaient à 3.5 mhz comme à l'origine. 
Enfin ce n'est pas tout à fait exact. Le blitter et le copper gère 8 bit (256 couleurs) au lieu des 5/6 bit (32/64 couleurs) d'origine et le blitter AGA a un mode rafale similaire à ce qui existe sur le 68030 ce qui permet un gain en performance. 
Ainsi le blitter peut gérer 256 couleur en 15 khz sans trop de problème, mais par contre dès qu'on passe en 31 khz là ça devient lent, voir assez lent. La palette de l'AGA passe de 4096 à 24 bit et il y un mode HAM8 ajouté (262144 couleurs simultanées dans toutes les résolutions, de mémoire).

Il aurait fallu que Commodore améliore davantage l'AGA, mais c'était un chipset fait à la va vite parce que Commodore avait pris conscience que le chipset AAA prenait trop de retard et qu'il fallait quelque chose en face des PC VGA.
http://obligement.free.fr/articles/aaa.php

Donc pour les jeux en 320x256 256 couleurs ça va, mais au delà c'est plus compliqué pour l'AGA. Sans parler que l'AGA n'a pas de mode chunky (celui bien utile pour les jeux de types DOOM), ce qui fait que ce type de jeu sera plus compliqué à faire sur AGA. Même si nous en aurons des spécifiques à l'Amiga. Le copper permettra un peu de pallier ce problème, mais pour que ce soit parfait, il aurait fallu qu'il soit lui aussi amélioré.

Tout ces points devaient être adressé dans le chipset AA+ (version évoluée du AGA, prévue à la commercialisation en fin 1994) et après on devait passer à la 3D avec Hombre
http://obligement.free.fr/articles/aa+.php
http://obligement.free.fr/articles/hombre.php
Mais avec la faillite de Commodore en mai 1994, rien de tout ça ne fut finalisé.


Pour revenir à l'AGA, à l'origine la gamme AGA était prévue pour sortir en fin 1991. L'AGA était fonctionnel dans les laboratoires Commodore début 1991. 
Deux modèles étiaient prévu :
L'Amiga 1000+ (format boitier Pizza dans le style des MAC LC). Il aurait eu les caractéristiques du 1200 que nous avons connu, mais un disque dur en standard, de la fast en standard et deux ports d'extension zorro II intégré, avec un clavier séparé. Le tarif prévu était de 1000 dollars, soit 6500 frs. Ce qui aurait été plutôt compétitif pour une configuration de ce type en 1991.

L'Amiga 3000+
http://www.bambi-amiga.co.uk/amigahistory/prototypes/a3000plus.html
Qui aurait été équipé en standard d'un DSP. 

Récemment un Amigaïste a réussi, à partir des plans d'origine, à recréer la carte mère du 3000+ avec le DSP inclus. Quelques temps plus tard le code source des library pour le DSP a refait surface et il a été possible de le rendre fonctionnel. Ici un démo d'un programme à l'origine écrit pour MAC (qui avait un modèle avec le même DSP, parce qu'Apple avait plus ou moins récupéré le travail entamé par AT&T et Commodore pour interfacer ce DSP avec les 68k).

Ce DSP gérait la virgule flottante, à la différence du DSP du Falcon. Et avec cette démo on voit que le DSP est plus rapide que la FPU du 68040 (donc pour 1991 ça aurait été un vrai plus).



Commodore avait la reconnaissance vocale gérée par ce DSP, la décompression MPEG2, émulation modem en logiciel et son 8 voies 16 bit. Bien sur le moment venu ce DSP aurait pu lire les MP3, 

http://obligement.free.fr/articles/dsp3210_genese_amiga.php


Mais aucune des ces machines ne fut commercialisé, car entre temps la direction de Commodore a changé et le nouveau responsable des ingénieurs (celui à l''origine du PCjunior IBM, un échec retentissant) a annulé tous les projets de son prédécesseurs pour qu'on pense que c'était des mauvais projets. Au final il va tenter d'imposer des machines basées sur l'ECS (ce qui équipait le 3000 en 1990). Aucune des filiales de Commodore ne voudra valider cette "nouvelle" gamme. Au final un an après il sera forcé de reprendre l'AGA, mais fera virer le DSP (pourtant finalisé) et le 1000+ sera remplacé par le 1200 qui était une configuration bien moins extensible que l'aurait été le 1000+

Il a fait perdre un an à Commodore pour la nouvelle génération et à précipité la faillite, car en fait il a fait produire beaucoup de trop de 600 (ECS) dont plus personne ne voulait quand le 1200 est sorti. Commodore a été obligé de les brader à perte. Et c'est ce qui a commencé à plomber les compte de Commodore fin 1992. 

Voilà j'espère que tu ne m'en voudras pas de t'avoir fait ce récapitulatif de la situation à l'époque. Bien toutes ces infos à l'époque on les avait pas, au fil des années elles ont fait surface.

[babsimov]

C'était connu que c'était un très mauvais portage en terme d'optimisation et il faut aussi reconnaitre que l'AGA était quand même lent en 256 couleurs haute résolution. C'est là qu'on voit qu'il aurait du sortir en 1987/88 et non en 1992. Donc je pense que le problème est un mix des deux, lenteur AGA en 256 couleurs haute résolution et manque d'optimisation.

et oui, comme disait ton mentor, c'est bien joli d'avoir une haute reso graphique et plein de couleurs mais quand tu as un architecture à la ramasse qui ne sait pas le gérer, ça ne sert pas à grand chose.

L'architecture n'est pas le problème. Celle de l'Amiga est très bien. Le problème est que dans l'AGA Commodore n'a pas augmenté la fréquence du Blitter et Copper qui sont restés à 3.5 mhz. 
Ca montre que le blitter de 1985 était déjà taillé pour gérer 256 couleurs en 320x200 ou 640x256. Mais au delà, il lui aurait fallu plus de vitesse. Tel quel avec l'AGA, de mémoire, en 31 khz 640x512, jusqu'à 64 couleurs ça allait. Après 128 couleur il y avait un ralentissement perceptible et 256 couleurs c'était pas vraiment confortable. 
Mais comme dit, l'AGA de toute façon n'aurait pas du être commercialisé en 91/92, mais plutôt en 87/88 en face des premières carte VGA. En 1987 il aurait été très bien.

Et sinon de toute façon un ST de base tu peux oublier, vu que la configuration minimum c'est 4MO de RAM, 256 couleurs et 640x480 et disque dur... et 386 25 mhz...

oui sur une version mal codé, mal optimisée... la SNES a-t-elle 4mo de RAM ? un 386 25 Mhz ? ben non il petit cpu à 3.58 mhz et 128ko de RAM.  tu vois comme quoi avoir la plus grosse ne prouve rien  

La version SNES ce n'est ni la même qualité graphique que la version MAC/PC/Amiga et surtout pas la même résolution. Et la SNES comparé au ST elle a des copros graphique, ça doit aussi bien aider.

Donc même sur Falcon avec de base à 16 mhz je pense bien que tu peux oublier et ça aurait ramé tout pareil, à moins que le DSP soit utilisé, mais vu le portage "douteux" de la version Amiga, je doute qu'ils aient été utiliser le DSP.

bien sûr que oui le DSP aurait le point crucial puisqu'il aurait pu faire tout les traitements sur les données du jeux...cela n'aurait pas été facile vu la spécifité du DSP, mais cela aurait largement soulagé le 68030.

Peut être, mais à mon avis faut pas trop rêver. Maxis a simplement tout fait au processeur je pense et n'aurait probablement pas utilisé le DSP, car il aurait fallu vraiment tout réécrire pour une plateforme à base de 680x0 pour laquelle ils pouvaient se contenter de reprendre tel quel le code du MAC. 
Le Falcon ne représentait surement pas un marché suffisamment rentable pour que MAXIS ait payé pour réécrire le jeu spécifiquement pour un DSP. D'ailleurs Maxis n'a même pas considéré la gamme ST pour ce jeu dirait on.

[dlfrsilver]

Un jeu comme Lotus Turbo Challenge II j'ai pas envie d'y jouer sur ST, c'est moins beau, c'est moins fluide et puis sans les digits vocales ca n'a pas non plus le même charme... Sur Amiga le jeu est excellent sur le ST le jeu est juste moyen (heureusement que la version Amiga n'est pas un portage de la version ST)

J'ai pas aimé le 2 non plus, y'a rien de plus par rapport au 1, sauf que c'est BEAUCOUP plus difficile... Je me demande aussi si la voiture n'est pas plus petite que dans le 1. En tout cas, le Lotus version STE sorti l'an dernier est gentil mais n'apporte, lui non plus, pas grand-chose. De ce jeu, je préfère la version Super Nintendo qui écrase tout le monde:

Personnellement, Je n'aime que Lotus 2 et Lotus 3 sur Amiga. 

Pourquoi ? Tout simplement parce que même si Lotus 1 a été calibré pour les limites du ST, j'aime pas du tout le format écran du jeu. Une grosse partie de l'écran est mangée par un bout d'écran qui sert à rien, à part gagner des cycles en mettant justement une petite fenetre type boite au lettre. 

Lotus 2 donne une perspective bien plus intéressante, un jeu en quasi plein écran, Et Lotus 3 pareil (sauf que là, un 68020 c'est quand même mieux pour éviter les ralentissements). 

Je sais que Shawn Southern et Andrew Morris ont fait des portages de leurs jeux sur ST en 25fps, et avec une qualité générale tout à fait bonne. (Shawn Southern est le Pierre Adane anglais, les deux partagent la même volonté de faire de bons jeux sur ST, dans les limites de la machine).

Top Gear 2 est un ratage total. Y a pas d'autres mots pour le dire, que ce soit sur Amiga comme sur SNES.
C'est un jeu qui s'est très mal vendu

[rocky007]

Mais, il y aussi l'AGA. Tu n'as pas connu ce chipset, mais en gros son problème était que le blitter et le copper sont restés les mêmes que l'OCS de 1985 et tournaient à 3.5 mhz comme à l'origine.

 mais quelle farce Amiga..donc tu veux dire qu'après 8 ans de recherche, ils ont sorti un truc encore pire que le A500 ?  mais comment est-ce possible ?

je viens de regarder à nouveau la vidéo de Sim City 2000, c'est juste déplorable...vous faites les malin avec vos " ah ben nous on a des jeux qui sont encore sorti "..mais ils sont juste injouables, une vraie farce.

et c'est vraiment le comble que vous ayez à émuler version MAC pour que cela soit jouable..effarant... je comprends mieux pourquoi vous aviez absolument voulu un émulateur Atari ST, c'était pour jouer à des jeux rapides et décents.

Mais cela n'aurait pas été plus facile d'acheter un Atari ou un Mac ?

Ainsi le blitter peut gérer 256 couleur en 15 khz sans trop de problème, mais par contre dès qu'on passe en 31 khz là ça devient lent, voir assez lent. La palette de l'AGA passe de 4096 à 24 bit et il y un mode HAM8 ajouté (262144 couleurs simultanées dans toutes les résolutions, de mémoire).

oui en effet j'ai vu, je pensais pas que c'était lamentable à ce point. je pense que  Sim City 2000 aurait pu être rapide même dans cette reso s'il avait utilisé ses propres routines au lieu d'Intuition.

Mais aucune des ses machines ne fut commercialisé, car entre temps la direction de Commodore a changé et le nouveau responsable des ingénieurs (celui à l''origine du PCjunior IBM, un échec retentissant) a annulé tous les projets de son prédécesseurs pour qu'on pense que c'était des mauvais projets.

ce n'est pas plus mal pour l'humanité.  j'imagine encore le CO2 qui cela aurait produit pour rien du tout

Voilà j'espère que tu ne m'en voudras pas de t'avoir fait ce récapitulatif de la situation à l'époque.

non pas du tout, très bon résumé pour conclure le fail de Commodore... on gardera tous en mémoire le C64, le seul et vrai succès de Commodore,

Peut être, mais à mon avis faut pas trop rêver. Maxis a simplement tout fait au processeur je pense et n'aurait probablement pas utilisé le DSP, car il aurait fallu vraiment tout réécrire pour une plateforme à base de 680x0 pour laquelle ils pouvaient se contenter de reprendre tel quel le code du MAC. 
Le Falcon ne représentait surement pas un marché suffisamment rentable pour que MAXIS ait payé pour réécrire le jeu spécifiquement pour un DSP. D'ailleurs Maxis n'a même pas considéré la gamme ST pour ce jeu dirait on.

c'est clair qu'exploiter le Falcon nécessitait des programmeurs qui ne contentait pas de compiler les sources C PC sur la machine  (comme font les codeurs Amiga ). 
c'est fou quand on y pense, de 1985 et à 1992 le jeux Amiga étaient compilé à partir des sources Atari, et de 1992 à 199x, ils ont été compilé à partir des sources PC.  Heureusement vous avez eu SOTB quand même

[rocky007]

je suppose que Jones-Steele a utilisé des routines C2P crades ou mal optimisées.

mais tu es complétement fou ou quoi ?

[dlfrsilver]

Je pensais que la version Amiga de Sim City 2000 était pratiquement égale à celle du PC, j'ai pas dû voir le bon truc à l'époque. Pourtant, je ne vois pas trop ce qu'il y a de compliqué dans ce jeu. Trop de trucs à gérer en même temps?

De mémoire à l'époque je l'avais joué, et le consensus des tests était qu'il y avait un problème d'optimisation du jeu, vu qu'en émulation MAC le jeu tourne mieux sur la même configuration Amiga.

Mais, il y aussi l'AGA. Tu n'as pas connu ce chipset, mais en gros son problème était que le blitter et le copper sont restés les mêmes que l'OCS de 1985 et tournaient à 3.5 mhz comme à l'origine. 
Enfin ce n'est pas tout à fait exact. Le blitter et le copper gère 8 bit (256 couleurs) au lieu des 5/6 bit (32/64 couleurs) d'origine et le blitter AGA a un mode rafale similaire à ce qui existe sur le 68030 ce qui permet un gain en performance. 
Ainsi le blitter peut gérer 256 couleur en 15 khz sans trop de problème, mais par contre dès qu'on passe en 31 khz là ça devient lent, voir assez lent. La palette de l'AGA passe de 4096 à 24 bit et il y un mode HAM8 ajouté (262144 couleurs simultanées dans toutes les résolutions, de mémoire).

Il aurait fallu que Commodore améliore davantage l'AGA, mais c'était un chipset fait à la va vite parce que Commodore avait pris conscience que le chipset AAA prenait trop de retard et qu'il fallait quelque chose en face des PC VGA.
http://obligement.free.fr/articles/aaa.php

Donc pour les jeux en 320x256 256 couleurs ça va, mais au delà c'est plus compliqué pour l'AGA. Sans parler que l'AGA n'a pas de mode chunky (celui bien utile pour les jeux de types DOOM), ce qui fait que ce type de jeu sera plus compliqué à faire sur AGA. Même si nous en aurons des spécifiques à l'Amiga. Le copper permettra un peu de pallier ce problème, mais pour que ce soit parfait, il aurait fallu qu'il soit lui aussi amélioré.

Tout ces points devaient être adressé dans le chipset AA+ (version évoluée du AGA, prévue à la commercialisation en fin 1994) et après on devait passer à la 3D avec Hombre
http://obligement.free.fr/articles/aa+.php
http://obligement.free.fr/articles/hombre.php
Mais avec la faillite de Commodore en mai 1994, rien de tout ça ne fut finalisé.


Pour revenir à l'AGA, à l'origine la gamme AGA était prévue pour sortir en fin 1991. L'AGA était fonctionnel dans les laboratoires Commodore début 1991. 
Deux modèles étiaient prévu :
L'Amiga 1000+ (format boitier Pizza dans le style des MAC LC). Il aurait eu les caractéristiques du 1200 que nous avons connu, mais un disque dur en standard, de la fast en standard et deux ports d'extension zorro II intégré, avec un clavier séparé. Le tarif prévu était de 1000 dollars, soit 6500 frs. Ce qui aurait été plutôt compétitif pour une configuration de ce type en 1991.

L'Amiga 3000+
http://www.bambi-amiga.co.uk/amigahistory/prototypes/a3000plus.html
Qui aurait été équipé en standard d'un DSP. 

Récemment un Amigaïste a réussi, à partir des plans d'origine, à recréer la carte mère du 3000+ avec le DSP inclus. Quelques temps plus tard le code source des library pour le DSP a refait surface et il a été possible de le rendre fonctionnel. Ici un démo d'un programme à l'origine écrit pour MAC (qui avait un modèle avec le même DSP, parce qu'Apple avait plus ou moins récupéré le travail entamé par AT&T et Commodore pour interfacer ce DSP avec les 68k).

Ce DSP gérait la virgule flottante, à la différence du DSP du Falcon. Et avec cette démo on voit que le DSP est plus rapide que la FPU du 68040 (donc pour 1991 ça aurait été un vrai plus).



Commodore avait la reconnaissance vocale gérée par ce DSP, la décompression MPEG2, émulation modem en logiciel et son 8 voies 16 bit. Bien sur le moment venu ce DSP aurait pu lire les MP3, 

http://obligement.free.fr/articles/dsp3210_genese_amiga.php


Mais aucune des ces machines ne fut commercialisé, car entre temps la direction de Commodore a changé et le nouveau responsable des ingénieurs (celui à l''origine du PCjunior IBM, un échec retentissant) a annulé tous les projets de son prédécesseurs pour qu'on pense que c'était des mauvais projets. Au final il va tenter d'imposer des machines basées sur l'ECS (ce qui équipait le 3000 en 1990). Aucune des filiales de Commodore ne voudra valider cette "nouvelle" gamme. Au final un an après il sera forcé de reprendre l'AGA, mais fera virer le DSP (pourtant finalisé) et le 1000+ sera remplacé par le 1200 qui était une configuration bien moins extensible que l'aurait été le 1000+

Il a fait perdre un an à Commodore pour la nouvelle génération et à précipité la faillite, car en fait il a fait produire beaucoup de trop de 600 (ECS) dont plus personne ne voulait quand le 1200 est sorti. Commodore a été obligé de les brader à perte. Et c'est ce qui a commencé à plomber les compte de Commodore fin 1992. 

Voilà j'espère que tu ne m'en voudras pas de t'avoir fait ce récapitulatif de la situation à l'époque. Bien toutes ces infos à l'époque on les avait pas, au fil des années elles ont fait surface.

Concernant Sim City 2000, je l'ai en original 3 disquettes en version française. 

Au sujet de la lenteur de l'AGA, en fait, le principal problème, c'est que de base Commodore a interdit aux programmeurs de taper au ras du métal, et de n'utiliser que du code High level. Forcément, ça pouvait pas le faire, car pour sortir les tripes du 1200, il faut faire l'inverse, c'est à dire taper au ras du métal. 
On s'aperçoit ou du moins on s'est aperçut récemment que l'AGA n'est pas SI lent que ça, à la condition expresse d'utiliser le chipset à fond. Le 1200 est aussi capable qu'une Super NES, c'est juste plus compliqué à programmer. 

Quand j'ai participé au projet Rygar pour A1200, la première question qui s'est posée a été de dire : 

"OK, combien de couleurs, ou du moins combien de palettes de 16 couleurs on va utiliser pour ce portage de l'arcade ?"

"64 couleurs, en 4 palettes de 16 couleurs, afin de se donner du mou puisqu'il y a une parallaxe, et aussi ne pas cramer d'un coup tout les canaux DMA disponibles".

Dans les faits, un 1200 se débrouille très bien en 64 ou en 128 couleurs. 256 couleurs c'est faisable, mais là faut vraiment que le programmeur connaisse les registres les plus obscures et les fonctions les moins courantes pour accélérer et fluidifier le tout.

En 64 couleurs sur Rygar, le jeu tourne en 50/60fps, avec une capacité à afficher 20 sprites enemis à l'écran sans broncher en 256x224 (la réso de l'arcade quoi).

On s'en est très bien tiré, puisque la perte graphique est très légère et ce jeu est le premier a vraiment pousser le 1200. En 1994, le 1200 était vraiment pas poussé à fond. Même un beau jeu comme Simon le Sorcier, qui est en 256 couleurs (donc 8BPL), et plus lent qu'il ne le serait si il avait été programmé en 2022.

[dlfrsilver]

je suppose que Jones-Steele a utilisé des routines C2P crades ou mal optimisées.

mais tu es complétement fou ou quoi ?

Au moins autant que ta question. Sim City 2000 AGA transforme en temps réel des données graphiques au format chunky (données PC d'origine) en planar (format Amiga). 

La preuve : tu prends shapeshifter (émulateur MAC), et tu fais tourner la version MAC sur A1200, c'est bien plus rapide que le port AGA !

[rocky007]

Au moins autant que ta question. Sim City 2000 AGA transforme en temps réel des données graphiques au format chunky (données PC d'origine) en planar (format Amiga).

as-tu la moindre source pour cette affirmation délirante ?