Re: ST Vs AMIGA : FIGHT !!!!!!!

[jf]

Un bon jeu c'est la réunion du talent de plusieurs personnes et du hardware sur lesquelles on les fait bosser ! Y a aussi une histoire de mentalité, les codeurs pendant un bon moment étaient endormi sur le ST

Tu peux avoir un hardware léger et concevoir des merveilles, comment faisaient les gars avant.
Comme comparatif tu peux voir certains jeux pcs, des glides à n'en plus finir et pour certains des graphisme du XX eme siecle où ca rame etc ...

Y a aussi une histoire de mentalité, les codeurs pendant un bon moment étaient endormi sur le ST, pensant qu'il déchirait grave, et on laissé l'amiga de coté en ne lui refilant que les miettes, pour au final bien voir que la machine en avait sacrément plus dans les tripes, mais voilà, seul les meilleurs codeurs savaient en tirer parti.

pas de mentalité, les codeurs font le travail qu'on leur donne à faire.
un informaticien est censé se renouveler et s'adapter, les gars sont mauvais c'est tout.

Mais fallait bien le dire, impossible de tirer la quinte essence de l'amiga tant que le ST était de la partie !

c'est le projet qui veut ça, tout dépend de la manière dont tu gères le projet.

A propos de la personne dont tu parles, j'ai des dossiers sur lui, et crois-moi c'est pas beau du tout, si tu veux de l'info,
je peux te les filer par PM.

je veux bien les infos aussi

c'est le déclin du ST comme machine de jeu
en
1992.

Epic, another world, gobliiins etc ... un beau déclin juste le temps de
voir arriver le pc

c'est sympa ces projets screetch, mais tu avoueras que l'intérêt pour ma part est limité, attention je ne critique pas l'énorme travail de conception effectué.

le Sam460 et AmigaOne X1000, il faut en avoir l'intérêt surtout au prix, qu'ils vont couter et pour faire quoi ?

MorphOS 2.4 rien à redire.

Le Minimig, là je vois vraiment pas l'intérêt pour l'AmigaOne c'est une nouvelle machine, mais le minimig c'est réinventer la roue.

Pour les périphériques qui upgradent les machines originelles là ok.

Pour moi ces nouvelles machines ne portent d'amiga que le nom.

[MacDeath]

Bof, pour ce qui est de dire que les codeurs de jeux étaient pas bon, je dirais que le problème est bien autre en fait.

Là sur CPCwiki, on a eut la visite d'un certain Keith A. Goodyer.

Ce type, c'est lui qui a fait le portage CPC de R-Type...
Bin c'est marrant : il nous a expliqué comment ça se passait.

http://cpcwiki.eu/forum/index.php/topic,433.90.html

En gros on lui a donné 21 jours pour se farcir la conversion, à lui tout seul.
Il avait un environement de cross Developpement :
"PDS system written by Foo Katan", un truc sur PC en fait.

Et bien sur il a eut le source code de la version Spectrum avec assez d'annotations pour bien comprendre le tout, et une conversation avec l'équipe spectrum (au téléphone).

Et c'est tout.

En gros il lui aurait fallut un graphiste rien que pour lui, bin non.
Rien que le temps d'analiser le code, de faire des trucs genre un émulateur Speccy sur l'amstrad...
Et mettre le système de protection (lol) lui a bien pris quelques jours aussi...



Mais comme il dit si bien :
"there were some VERY slimey men in suites that knew how to abuse the
geeks."

Tout est dit.


Donc les portages/crossdev. entre les 16bit, ça marchait pareil bien souvent, surtout concernant les portages de jeux d'arcade...

Un jeux d'arcade : tu paye une license, donc un truc que les gens veulent chez eux et "achèteront" malgré tout.

Donc tu fait du portage a l'arrache au moins coutant possible histoire de bénéficier de la réputation du jeux originel, et voilà.

sachant que en général : jeux Japonais mais programeurs des version Micro Européens.

Il était trés rare qu'ils aient accés à la borne d'arcade ou aux sources du jeux originel (Graphismes, Level design...etc...)

Donc ils devaient refaire au pif bien souvent.

Ensuite bin ça dépendait souvent de la volonté de la boite d'édition/production si ils voulait faire de la marge ou un bon jeux.

Mais l'avantage de l'Amiga fut en fait d'avoir eut dès le départ du support harwarze (blitters, scrolls/sprites, etc...).
Donc c'était déjà implémenté dans le système.
Que pour les Atari, ça fut intégré après, mais avec le soucis de rétro-compatibilité, donc c'était fait qu'a moitié et comme le parc éxistant était en old (sans ces trucs hard) bin les éditeurs en restaient au parc le plus porteur.

Comme pour les Amstrad donc (le PLUS).

Ce qui n'empèche pas des machines "Soft" d'être bonnes, c'est juste qu'elles sont moin joueuses de fait, ou alors moins bonnes pour certains types de jeux en général (les jeux d'arcade en fait, qui étaient d'ailleurs axé full-Hard de fait).

[jf]

En gros on lui a donné 21 jours pour se farcir la conversion, à lui tout
seul.
Il avait un environement de cross Developpement :
"PDS
system written by Foo Katan", un truc sur PC en fait.

On est d'accord, ça dépend comment le projet est géré.

[dlfrsilver]

En gros on lui a donné 21 jours pour se farcir la conversion, à lui tout
seul.
Il avait un environement de cross Developpement :
"PDS
system written by Foo Katan", un truc sur PC en fait.

On est d'accord, ça dépend comment le projet est géré.

La gestion de projet c'est une chose, vouloir faire faire à du hardware quelque chose pour lequel il a pas les tripes ça en est une autre.

Pour R-type CPC, manifestement le souci c'était une contrainte de temps, mais dans plein d'autre cas, le hardware de destination est trop sous-calibré pour recevoir un port digne de ce nom.

Désolé de le dire, mais la plupart des jeux de cafés si on passe outre le nombre de couleurs qu'il faut abaisser, utilisent des quantités astronomiques de sprites, et le tout bouge avec fluidité (nan les mecs me lancez pas avec l'affichage en 60hz de ces bouzingues......).

Forcément, lors de la conversion, on passe en général de 256 couleurs affichées en moyenne à l'écran à 16 couleurs (Atari ST oblige).
Seulement voilà, c'est trop pauvre, et le rendu est laid. Si sur amiga ils s'étaient donné la peine, 32 couleurs c'est jouable sinon plus (ex: snow bros qui en affiche plus de 60 ). Ensuite ce qui bouffe le plus de temps, c'est de convertir le code from scratch depuis le début. Ce qui m'amène à ceci :

Point de vue projet pur que c'était un peu du n'importe quoi. Quand une boite signait une licence de conversion, je m'excuse mais demander aux japonais le code source, les graphismes sous formes de fichiers IFF c'était le minimum syndical.

Pourquoi ? Un gain de temps considérable, avec juste à réduire le nombre de couleurs de 256 à 32 et hop les graphs sur amiga, et hop de 32 à 16 et on a les graphismes pour la version ST.

Et non au lieu de ça, les graphistes et codeurs perdaient un temps fou à tout retranscrire en soft sur atari ST au lieu de porter le programme sur amiga qui était largement plus doté pour celà.

Dans le même temps, les codeurs convertissent ligne à ligne le code source de la machine d'arcade, ajoutent ou suppriment certaines routines suivant les possibilités hardware des machines cibles. (ex: font sauter une parallaxe si c'est pas jouable techniquement, etc....).

Résultat, on arrive avec un jeu converti ET valable !

Exemple : Rod-land, St Dragon, Double dragon III (même mieux, ils l'ont amélioré, la version amiga est largement supérieure à la version arcade qui est une pure merde coté jouabilité malgré les 256 couleurs à l'écran.)
J'ajoute aussi Ninja warriors, qui est un beau morceau, encore plus malgré
le système bi écran de la machine d'arcade.

Tout ces jeux ont été portés d'abord sur Amiga, et on voit le résultat !
Y a aussi Pang et Toki, mention spéciale à Pang, qui utilise le copper pour afficher plus de 32 couleurs à l'écran sur amiga (dixit le graphiste, à qui le programmeur à permis celà :) ). Pang sur ST est une version downgradée de la version amiga, et qui correspond à ce que le ST peut offrir.
Y a Ghosts'n'Goblins développé d'abord sur amiga, et converti directement avec les données de la machine d'arcade, comme quoi, quand les boites demandaient les élements sources du jeu d'arcade, les japonais ne disaient pas non ! La version ST est un ton en dessous, par contre, ce jeu nécessite 1mo de RAM quand tout les jeux sortis à l'époque ne demandaient que 512ko.

A l'inverse, convertir un jeu d'arcade directement sur ST, ça pouvait qu'aboutir à des bouzes, parce que l'écart entre le hardware d'origine et cible est trop grand résultat, ils ont perdu un temps fou à recréer le programme (code + GFX), c'est bien connu, réinventer la roue c'est une perte de temps ! Et ensuite il est impossible d'améliorer un programme quand la 1ère conversion est déjà bas de gamme car programmée sur la machine la plus faible ! Car celà imposerait encore des contraintes en terme de développement et de cout, donc la parade à ce problème c'était de faire des portages directs en terme de code, résultat, c'est moche, c'est lent, c'est nul ! Regardez Mercs de capcom, pour être sur, j'ai demandé à un pote qui touche sa bille en langage 68000 et je lui ai demandé, s'il te plait, dis moi si ce jeu utilise le blitter et ou les puces customs de la machine.
Réponse : le jeu est truffé d'instruction atari ST ! A savoir bourré de loops (boucles), et aussi d'instruction TRAP #XX (hyper courant sur ST, mais pas sur amiga) et en plus il n'utilise pas les puces ! Résultat, des couleurs dégueux car les images sont au format PC1, et le personnage est aussi maniable qu'un fer à repasser, même la musique pue Autre exemple, Dragon ninja, Codetapper qui l'a patché m'a expliqué sur MSN qu'il y a du code ST dans le jeu.....

Faut bien comprendre que rien n'égale la précision de fonctions dédiées en hardware, et que même le plus balaise des codeurs ne pourra jamais reproduire quelque chose d'aussi bon en software, ça ne sera jamais qu'un ersatz.....

Autre anecdote bien sympatique, j'ai lu et j'ai eu des discussions avec des gens qui sont persuadés que la megadrive est plus proche du ST que de l'amiga. Mauvaise pioche, en ayant discuté avec Richard Costello, le programmeur de Golden Axe, Gauntlet II, Primal Rage et surtout de mortal kombat 1 et 2 sur amiga, en fait, c'est carrément un émulateur megadrive qu'il a mis au point pour faire le portage de MK1 sur A500, ainsi que MK2, et primal rage.

A savoir que c'est un atariste convaincu, il cross developpait sur mega ST4.
Voici traduit en français ce qu'il a dit à propos de Mortal Kombat 2:

Alors voici une partie du code, je ne sais pas pour la qualité, mais je me souviens avoir apprécié l'écrire...

Ca s'appelle "STRIPPER - SPRITE STRIP BLITTER (Emulateur de sprite hardware couleur 16x16x16)"

Ca crée une version logicielle/blitter des sprites hardware 16x16 de la megadrive parce que les utilitaires qui ont extrait et traités les graphismes du coin-op était conçu à l'origine pour la Megadrive. Néanmoins les couleurs ont été changées pour l'Amiga étant donné que la palette était différente.

Si ma mémoire se souvient bien (c'était il y a 15 ans!). Chaque image était découpée en tile 16 x 16 . Tel que celà était fait, les images étaient déplacées légèrement (sous forme de bandes de 16 pixels de haut) et flippée à la fois en X
& Y (abscisse et ordonnées) pour essayer de correspondre avec la tile en cours avec celle qui avait été crée précedemment. Par exemple il y a d'ordinaire un espace de 16 pix x 16 pix entre les jambes d'un combattant en position debout.

Mais l'espace peut se trouver dans un limite de 16 pixel. Alors déplacer les tiles légèrement et
les flipper/flopper écrasait la taille définie des tiles.
Alors chaque image de combattant consistait alors en un fichier mappé doté d'une grille qui contenait les références des tuiles vers le fichier SCH.
Toutes les images étaient stockées pointant dans une direction et
de ce fait avaient besoin d'être refletées en temps réel tel que c'était nécessaire.

Chaque tile 16 x 16 était alors compressée en utilisant le code de Nick Pelling pour réduire encore le tout.

La logique du jeu tourne à la même vitesse que celle du coin-op (60Hz), et l'écran est rafraichit tout les 1,2,3 ou 4 balayages verticaux (il y a un truc quelque part pour que le PAL soit pris en compte en 50Hz). Alors quelquefois il y a des moments
ou la logique du jeu est rafraichie 4 fois pour un seul rafraichissement d'écran.
Cela devait être fait pour garder la fluidité naturelle du jeu et faire face à la quantité de traitement écran requis.

Les tiles 16 x 16 pixel étaient décompressées, déplacées, flipéés et
flopées dans un tampon image (frame buffer) par le 68000 depuis la fast ram (512K à 1024K)
vers la chipram. Ainsi une fois qu'une image était construite il n'y avait pas d'autre mise en place jusqu'à ce qu'elle change. Je me souviens que changer de direction provoquait une perte de cycle à cause de toutes les reflections requises mais celà une fois qu'un cycle d'images s'était produit (par ex en étant debout) que les réflections n'était pas requises tant que le combattant ait changé à nouveau de direction. Mais maintenant je sais plus comment c'était possible, sans creuser dans le code il est vrai et j'ai pas du tout le temps pour ça maintenant.

Une fois l'image construite, elle était blittée à l'écran en utilisant un "cookie cutting minterm standard" (je ne sais pas ce que c'est, donc pas traduit) (sprite en 16 couleur sur un écran en 32 couleurs, le 5ème bitplan était éffacé ou mis en place en utilisant le mask).

Il y a avait 2 écrans un construit tandis que l'autre était affiché alors ils étaient flippés pour afficher la nouvelle image.

etc etc etc....

[ryosaeba]

Je pense qu'on surestime l'amiga.

Un bon code sur St doit être en principe un bon code sur Amiga. Le processeur est le même et le langage utilisé est normalement l'ASM.

[kawickboy]

rodland amiga m'a toujours paru être un portage du st justement vu sa palette.

perso, le mec qui a converti mortal kombat sur amiga, il ferait mieux de creuser un trou et de se faire oublier. je ne sais pas si illustrer les liens md/st/amiga sur un titre de ce genre c'est le top.
par contre dans le genre titre développé sur les 3 machines, je veux bien des infos sur addams family.

exemple de conv arcade réussie: rainbow island. grafcold avait reçu un hdd de taito avec entre autres les graphs.

[MacDeath]

exemple de conv arcade réussie: rainbow island

C'est bien simple : à l'époque si le jeux Amstrad était bon, bin toutes les versions 16 bit l'étaient...non?

Un bon code sur St doit être en principe un bon code sur Amiga. Le
processeur est le même et le langage utilisé est normalement l'ASM.

Hélas on pourrait alors dire la même chose avec le Spectrum et l'Amstrad...
Et pourtant, rien que un système vidéo radicalement différent change grandement la donne.

L'Amiga avait du hard en sprites et scrolls, donc un code qui les fait en soft chiera complètement sur un Amiga...
Et de même si le code n'est pas forcément prévu pour intégrer ça à la base, bin y'a des bizareries qui peuvent se produire quand on implémente les fonctions Hard par dessus.

[ryosaeba]

une routine sprite ou scroll uniquement soft est tout à fait faisable sur amiga.

[dlfrsilver]

@RyoSaeba :

Je pense qu'on surestime l'amiga.Un bon code sur St doit être en principe un bon code sur Amiga.
Le processeur est le même et le langage utilisé est normalement l'ASM.

D'accord donc si on suit ton raisonnement, la neogeo est programmée en 68000, donc un bon code neogeo
doit être un bon code sur amiga ou ST ?
J'ai écrit juste avant à propos du cas de Mercs, le jeu est correct sur un atari ST au vu de ce que la machine
peut proposer, mais raté sur amiga, car l'amiga n'est à la base pas fait ni conçu pour faire tourner des jeux
avec des routines soft ! Et j'enfonce le clou en disant que l'instruction TRAP sur amiga n'est principalement
utilisé que dans les protections copylock, mais pas dans le cadre d'un programme en tant que tel.
Bref, une usine de marmotte emballe des tonnes de chocolat dans du papier d'allu !
Franchement, réfléchis 2 sec ! L'amiga, le ST et la neogeo n'ont pas la même memory map, le hardware de chacun
n'a pas la même puissance. Le 68000 dedans n'est un élément, pas l'élément principal et ne fait pas le TOUT !.
L'atari a un 68000 mais pas de fonctions dédiées, l'amiga et la neogeo OUI, et les 3 machines sont clairement
différentes !
Le 68000 sur ST gère TOUT, programme, graphismes, son, etc, c'est donc l'homme à tout faire.
Le 68000 sur amiga gère le programme, mais pas les graphismes (blitter + copper), le son est géré par paula.
Bref, le processeur sur ce micro fait principalement chef d'orchestre.
Le 68000 sur neogeo est comme sur amiga un chef d'orchestre, à la différence qu'il ne peut pas accèder aux
graphismes (donc il envoie des instructions à la puce graphique qui est 10x plus balaise que lui), et la
partie son est complètement indépendante, le z80 pilote la puce son et possède sa propre RAM dédiée, dans
laquelle le 68000 peut lui envoyer "les consignes". Résultat, le 68000 est hyper allégé dans sa charge
de travail.
Les 3 bécanes ont le même processeur, et dans chacune, l'utilisation est différente, à cause des différences
de conceptions hardware.
et sur ta dernière phrase, oui on peut faire une routine sprite ou scroll uniquement soft sur amiga c'est évident,
mais c'est merdique. Exemple : Mercs, Super wonderboy in monsterland, ghouls'n'ghosts, entre autres, directement
porté du ST. Une routine soft n'aura jamais la fluidité et la vélocité d'une routine hardware, jamais !
Pourquoi ? j'explique la différence :
Sur un ordinateur comme le ST, on doit demander au 68000 de calculer, de mettre en place en mémoire puis d'afficher
à l'écran les éléments graphique, donc tout en soft par le biais de routines logicielles.
Sur une machine qui traite en hardware, c'est à dire de façon dédiée, c'est tu prends tel éléments situé à tel
endroit, et tu affiches à l'écran.
Voilà la différence. C'est ce qui fait la force d'une machine qui fait tout en hardware par rapport à une machine
qui se tape tout en soft. Pour celle chez qui tout est en hard, y a pas de perte de cycles de traitement,
et chez celle qui fait tout en soft, l'impact est rude.
Le résultat ? Pourri, parce que le processeur se ramasse tout dans la gueule et qu'il a normalement d'autres
choses à gérer.
Pour info, j'ai posé la question à Pierre Adane quand j'ai sauvé Snow Bros pour le préserver, c'est quoi le plus
dur à implémenter sur ST par rapport à l'amiga de façon générale ? Réponse : l'intelligence artificielle
dans un jeu. Le ST n'étant pas conçu normalement pour le jeu, l'AI prend un temps machine monstre, ce qui restraint
la machine pour faire d'autre choses.
@Kawickboy :

rodland amiga m'a toujours paru être un portage du st justement vu sa palette.
perso, le mec qui a converti mortal kombat sur amiga, il ferait mieux de creuser un trou et de se faire oublier.
je ne sais pas si illustrer les liens md/st/amiga sur un titre de ce genre c'est le top.
par contre dans le genre titre développé sur les 3 machines, je veux bien des infos sur addams family.
exemple de conv arcade réussie: rainbow island. grafcold avait reçu un hdd de taito avec entre autres les graphs.

Mortal Kombat sur amiga du point de vue programmation est hyper complexe, le jeu en lui-même c'est à l'appréciation
de chacun, mais avoir codé un émulateur de sprite hardware, c'est quand même sacrément balaise, franchement,
on aurait rigolé si ça avait été porté sur atari ST MDR !
Concernant Rodland, Au moment de la signature de la licence pour convertir le jeu, JALECO a donné 4 ou 5 disquettes
contenant les tiles du jeu à Sales Curve, et c'est Ronald Pieket-Weeserik (un néerlandais super balaise en
programmation) qui a remis les tiles en ordre, et à crée les planches de graphismes au format IFF sous deluxe paint 3.
(sprites+décors). Le jeu a été passé de 256 couleurs à 32 sur amiga en premier, et la version atari ST a été crée
juste après en 16 couleurs seulement.
Addams Family a été démarré sur amiga, puis stoppé, et redémarré sur super nintendo. une fois terminée les codeurs
ont repris la version amiga, mais ils l'ont torchées. en effet le plan de fond n'a pas été rajouté, tandis que
sur la version ST qui a été traitée en dernier, ils l'ont mis (pourquoi? une bande de flemmard!).
A propos de rainbow Islands, taito a fourni 4 disquettes atari ST contenant tout les graphismes au format IFF,
comme ils l'avaient fait pour Operation Wolf (j'ai les graphismes de ce jeu :) ) Rainbow Islands est un jeu codé
en STOS (recodage intégrale from scrach) si ma mémoire est bonne, et les 3 dernières iles n'ont pas été implémentées
(Pfff....Rainbow islands aurait pris 3 disquettes si tout avait été incorporé, et Ocean n'a pas voulu, en même
temps faut dire que sur ST, les codeurs étaient des champions du gachis de place ! un jeu comme rainbow island ça
doit tenir en 2 disquettes maximum, la faute à l'organisation des données sur les disquettes, voir shadow warriors
sur ST, 3 disquettes, on se demande bien pourquoi, y a quasiment rien sur la disquette 1 et 3 tout est principalement
sur la disquette 2).
Et avec le recul, et d'après Gary Bracey, le manager d'ocean, Rainbow Islands ne s'est pas vendu comme espéré.
en même temps, les gens savaient que les 3 dernieres iles étaient pas là, et en plus bof quoi, ça cassait pas trois
patte à un canard. Le jeu amiga est une conversion du ST, en 25 images secondes, la ou parasol stars, qui est plus
compliqué tourne en 50 images sec pour les décors et 25 pour les sprites. Les couleurs sont plus belles, et c'est
plus fluide. Pourtant PS a été retouché sur l'outil graphique interne de chez ocean (que j'ai en ma possession),
qui ne tourne que sur atari ST.

[youki]

Rainbow island en STOS???

donc le portage sur Amiga aurait été fait en AMOS?

Tout ce que tu dis es vrai, que le processeur n'indique pas la puissance de la machine, que les coprocesseurs font la difference , etc..etc...

Pour avoir programmer sur les 2 machines Amiga et ST , il n'empeche que je prefere le ST du point de vu programmation.Le fait de toute faire avec le 68000 et de maitriser exactement tes routines et ne pas faire appel a des "boites noires" a ses avantages. Et surtout ne te limite pas a ceux que peut faire ton coprocesseur. Ca laisse plus de plus à l'imagination et ne t'enferme pas dans un framework donné et rigide. Sur Amiga tu es un peu obligé de passer par le coprosseseur pour faire de l'affichage, de la musique etc...

[jf]

Bof, pour ce qui est de dire que les codeurs de jeux étaient pas bon, je dirais que le problème est bien autre en fait.

les codeurs
ont repris la version amiga, mais ils l'ont torchées.

oui tu as raison je vais tempérer mes propos, la médiocrité de certains jeux vient également des conditions des projets.

D'accord donc si on suit ton raisonnement, la
neogeo est programmée en 68000, donc un bon code neogeo
doit être un
bon code sur amiga ou ST ?

Bien moi je vais te dire que oui si c'est bien fait, c'est tj la même chose.

Dans un projet idéal, on aurait développé des routines, fonctions etc qu'on améliore et qu'on réutilise selon les machines. Le codeur fait quoi ? il réutilise les fonctions/routines qu'on lui a donné. Un gros travail de développement au départ, mais rentable à la fin, ça s'appelle une vision à long terme. Ca permet beaucoup de choses, en autre éviter d'avoir un mauvais travail pour un jeu similaire sortie peu de temps après, de vendre aussi son travail aux autres boites de dev.

Que font la majorité des boites de prod ? Vision à court terme (très très court terme) et va y que je te développe la roue et mal et que je te fais un projet sans avoir les bons outils. Je transfère le travail à des sous traitants sans leur donner un bon cahier des charges ou les fonctions/routines qui vont bien.

Alors forcément lorsque le délai du projet se rétrécie en peau de chagrin, force est de constater qu'on arrive même pas à avoir un jeu qui a la même qualité parce qu'on a du réinventer avant la roue.

La question maitresse tj le pognon, l'argent qu'on refuse d'investir au départ, on le paye à la fin.

Ce qu'il y a d'excellent, enfin si l'on peut dire ça, c'est ce que ce qui est valable y a 20 ans est tj d'actualité, comme quoi l'histoire est un éternel recommencement.

Et pourquoi changer une technique qui marche ? il y aura tj des gens honnêtes qui se feront arnaquer.

c'est quoi le plus
dur à implémenter sur ST par rapport à l'amiga de façon générale ? Réponse : l'intelligence artificielle
dans un jeu.

Là encore c'est une question de codage et la il faut savoir de quoi on parle entre les ia qui reproduisent les mêmes choses constamment et une véritable ia. La première est reproductible par n'importe quelle machine, la deuxième par contre, il faudra attendre le monde du pc pour la voir émerger.

[ryosaeba]

Petit question, y-a-t-il des effets provenant du monde de la demo amiga, qui n'ont pas pu être reproduit sur le St ?

Moi, j'en connais pas:)

[dlfrsilver]

@Youki :

Rainbow island en STOS???
donc le portage sur Amiga aurait été fait en AMOS?

Non, pas tout à fait. En fait petite boulette de ma part, C'est l'éditeur graphique de RI qui a été codé en STOS
et andrew braybrook a codé en ASM le jeu sur ST. Sur amiga il a rajouté l'utilisation du blitter, ce qui permet une
meilleure fluidité et rapidité que sur ST. Si le jeu avait du être fait en 32 couleurs, et un peu plus lent,
il aurait d'après lui fallu refaire tout les graphismes et recoder entièrement le jeu spécifiquement pour l'amiga.
Ce qui me fait dire que du code porté c'est jamais aussi bon que du code crée pour la machine, et fait pour elle.

Tout ce que tu dis es vrai, que le processeur n'indique pas la puissance de la machine, que les coprocesseurs font la difference
, etc..etc...

Les coprocesseurs ont été inventés pour délester le processeur dans son fonctionnement, et empecher son étranglement tout simplement.

Pour avoir programmer sur les 2 machines Amiga et ST , il n'empeche que je prefere le ST du point de vu programmation.Le fait de
toute faire avec le 68000 et de maitriser exactement tes routines et ne pas faire appel a des "boites noires" a ses avantages. Et surtout
ne te limite pas a ceux que peut faire ton coprocesseur. Ca laisse plus de plus à l'imagination et ne t'enferme pas dans un framework
donné et rigide. Sur Amiga tu es un peu obligé de passer par le coprosseseur pour faire de l'affichage, de la musique etc...

Oui je peux comprendre que tu préfères le codage sur ST, et ne t'en tenir qu'au processeur. Beaucoup de programmeurs de l'époque
pensaient comme toi, et ils ne s'en cachaient pas. Mais après fallait pas qu'ils s'étonnent de voir les jeux qu'ils avaient crée
se faire descendre ! Et les utilisateurs gueuler parce que les machines étaient pas exploitées !
Genre new zealand Story 19,99 livres et la version amiga 24,99 livres, alors que c'est un portage Atari ST sans amélioration !
C'était clairement du vol ! les 5,00 livres de plus en quel honneur ?
La ou je suis pas d'accord, mais du tout alors, c'est que les coprocesseurs ne sont pas là pour limiter ou restreindre, mais au contraire
permettre d'incorporer plus d'effets, d'AI, et consort sans que le 68000 (puisqu'on parle de lui), ne se retrouve défoncé
par le taux d'occupation et de perte de cycles. Sans compter qu'en plus les coprocesseurs de par leur nature sont plus puissants
que le processeur lui-même (bah vi sinon je vois pas comment ça delesterait le 68000 si ils étaient moins costauds!).
De plus, ton 68000 seul étant fort limité, ton imagination l'est aussi forcément. Et je vois pas ou est la rigidité.
Avec le 68000 comme seule arme, ça c'est de la rigidité, tu veux implémenter des effets en plus ? dans le cul lulu,
ton ordi mono-processeur se met à ramer mieux que moi sur radeau avec un grand-blanc gueule ouverte aux fesses ! LOL
Et pour finir quand tu dis que sur amiga t'es obligé de passer par les coprocesseurs, mais évidemment !
Sérieux, je me demande des fois si les codeurs qui ont tes idées ont bien compris pourquoi il y a des copros, leur utilité,
et pourquoi les jeux qui les utilisent sont infiniment mieux que ceux qui ne les utilisent pas !
A titre d'information, Shadow of the beast, même si on en dit que la maniabilité est pas bonne (j'ai connu pire sur ST
et sur des titres infiniment plus pourri techniquement!), le 68000 de l'amiga a un taux de charge de l'ordre de 20-25%
quand sur atari ST on atteint 80-85% de charge sur le même jeu..... T'es sur que tu vois pas l'avantage d'avoir des copros ?
Résultat, pour convertir à presque "identique", et presque ici c'est larrrrggeeeee, il aurait fallu des atari ST avec 2mo
de RAM quand la version A500 n'en utilise que 512ko !
Alors imagine, un programmeur qui reste "rigide" sur "nan, chui 68000 only moi, j'en veux pas des copros, c'est trop chiant!"
résultat, les clients en bout de ligne, se tapent des programmes mal fagotés bourrés de routines soft !
et qui dépassent pas les 25 images seconde avec de la musique naze et des sprites minuscule (Voir Dynasty Wars d'US GOLD qui
illustre parfaitement le problème!).
Avec coprocesseurs, on peut avoir des jeux complexes, en 50 images par secondes, avec de la musique digitalisée qui déchire,
des effets qu'une machine mono-processeur peut pas sortir à moins d'un framerate à 5 images par seconde, etc, etc, etc.
Moi mon choix est fait, comme bcp d'autres personnes ! Je préfère le plus que le moins !
Sans compter qu'en plus les outils ST pour le crossdev étaient très pratiques, mais carrément sous-calibrés pour l'amiga.
Y a qu'a voir la différence entre des graphs sous deluxe paint 3, 4 ou 5 et ceux des jeux réalisées avec degas elite
ou même neochrome (pitié épargnez-moi le crédo Ouuuii mais les jeux thalion comme WOD ou EL hé ben trop fin trop la classe....
oui sur ST la classe, mais sur amiga peux largement mieux faire!).
@JF :
Citation:
Bof, pour ce qui est de dire que les codeurs de jeux étaient pas bon, je dirais que le problème est bien autre en fait.

Citation:
les codeurs ont repris la version amiga, mais ils l'ont torchées.
oui tu as raison je vais tempérer mes propos, la médiocrité de certains jeux vient également des conditions des projets.

Oui mais y avait pas que ça. Je compte pas les interviews ou les programmeurs avouaient clairement leur atarisme de base
et ces chers petits ne voulaient surtout pas pousser l'amiga. Me force pas à donner des noms steu plait !
Les temps de devs trop court, on est au courant, il est vrai que ça arrivait assez souvent. Mais dans beaucoup de cas je note
ceci :
1) Developper des jeux infiniment mieux sur amiga, ça aurait obligé le codeur d'un jeu a se sortir les doigts du cul.
Mais surtout, fait plus embetant, sérieusement compromis les versions atari ST rendues bien plus problématiques avec
toutes les tailles et omissions d'effets.
Atari ST = solution de facilité lol
Amiga = Pour ceux qui en ont en bas Mdr
2) Rien, je dis bien rien n'empechais un programmeur même avec une deadline de bien programmer sur amiga si il en
avait envie. Beaucoup ne l'ont pas fait et ont juste pris l'argent en faisant de la daube.
Tiertex inside, usgold inside, blablabla !
Par essence j'aime pas les gens qui ne se donnent pas à fond.
3) On a tout de suite vu les codeurs qui avaient le niveau pour coder correctement l'amiga, et ceux qui l'avaient pas.
Trop facile de dire, l'amiga c'est trop dur à programmer. Trop la flemme surtout, et trop faiblards !

Citation:
D'accord donc si on suit ton raisonnement, la
neogeo est programmée en 68000, donc un bon code neogeo
doit être un bon code sur amiga ou ST ?
Bien moi je vais te dire que oui si c'est bien fait, c'est tj la même chose.

Ben non justement. Prends du code neogeo (un petit jeu par ex), patches tout les accès aux fonctions hardwares, et ensuite
recode les fonctions ou routines hardware en soft.
Attends-toi à faire ramer ton atari ST ou ton amiga à plein rendement. Pourquoi ? parce que le code permet le pilotage
des fonctions hardware, et non faire tourner le jeu en lui-même sur le 68000 SEUL !
Il pilote les puces customs par le biais de fonctions cablées.

Dans un projet idéal, on aurait développé des routines, fonctions etc qu'on améliore et qu'on réutilise selon les machines.
Le codeur fait quoi ? il réutilise les fonctions/routines qu'on lui a donné. Un gros travail de développement au départ, mais
rentable à la fin, ça s'appelle une vision à long terme.

Impossible d'être d'accord sur une telle vision des choses. Si les programmeurs japonais avaient pensés comme ça, jamais
on aurait eu les jeux géniaux et hyper complexes que seuls eux savent coder.
Quand on fait appels à des fonctions hardware en dédié, on gagne un temps fou, même le code du jeu en lui-même est plus léger.
Et toi tu me dis que dans un projet idéal, on aurait developpé des routines ? Mais c'est clair que c'est une perte de temps !
et une perte d'argent ! maintenant on est d'accord que certaines routines ne peuvent pas être traitées en hard, mais ça,
c'est pas un problème, on sait bien que dans un jeu c'est l'animation et le son surtout sur les machines retro qui pose problème
et peuvent ralentir la machine.
............

La question maitresse tj le pognon,

Et le facteur humain t'en fait quoi ? Les mauvais programmeurs, ceux qui sont attirés que par le fric,
ceux qui ont comme politique de ne coder principalement que pour une machine et pas la plus balaise (en bref
des raisons personnelles et politiques, dans lesquelles le client est perdant car au final ayant acquis un
produit mal foutu et mal codé ? On les comptes plus les softs dans ce cas précis.

L'argent qu'on refuse d'investir au départ, on le paye à la fin.
Ce qu'il y a d'excellent, enfin si l'on peut dire ça, c'est ce que ce qui est valable y a 20 ans est tj d'actualité, comme quoi
l'histoire est un éternel recommencement.
Et pourquoi changer une technique qui marche ? il y aura tj des gens honnêtes qui se feront arnaquer.

Citation:
c'est quoi le plus dur à implémenter sur ST par rapport à l'amiga de façon générale ? Réponse : l'intelligence artificielle
dans un jeu.

Là encore c'est une question de codage et la il faut savoir de quoi on parle entre les ia qui reproduisent les mêmes choses
constamment et une véritable ia. La première est reproductible par n'importe quelle machine, la deuxième par contre, il faudra
attendre le monde du pc pour la voir émerger.

L'AI bouffe un paquet de cycle, et sur ST, si le 68000 est trop chargé, le ST rame comme un porc. C'est pas le but dans un jeu.
surtout un jeu d'arcade. faut que ça bouge vite et bien, et que l'AI soit pas trop naze.
Pour résumer les choses, si on démarre un jeu sur Atari ST, il sera calibré pour la machine, très bien,
mais une fois sur amiga, il fera très pauvre. A l'inverse, un jeu calibré pour l'amiga sera appauvri sur ST
sinon même pas la peine de le convertir.....

[ryosaeba]

Un doom like sur un St(e) ? Oui cela est possible

[jf]

Oui mais y avait pas que ça. Je compte pas les
interviews ou les programmeurs avouaient clairement leur atarisme de
base
et ces chers petits ne voulaient surtout pas pousser l'amiga

oui le refus du changement ou de l'évolution, un syndrome bien connu dans le domaine informatique. D'un autre coté il vaut mieux dire qu'ils ne voulaient pas, plutôt qu'on ne sait pas faire :p

Beaucoup ne l'ont pas fait et ont juste pris
l'argent en faisant de la daube.

c'est clair, on peut penser aux différentes licences de film et autres.

Attends-toi à faire ramer ton atari ST ou ton
amiga à plein rendement. Pourquoi ? parce que le code permet le pilotage
des
fonctions hardware, et non faire tourner le jeu en lui-même sur le
68000 SEUL !

oui il faut adapter à la machine, forcément.

Et toi tu me dis que dans un projet idéal, on
aurait developpé des routines ? Mais c'est clair que c'est une perte de
temps !

on sera pas d'accord sur ce point, par type de jeux prècis on peut créer des routines/fonctions, réutilisables, paramétrables et surtout pouvant à chaque nouveaux jeux être améliorées.

Attention, utiliser les mêmes routines/fonctions ne veut pas dire jeux identiques !

Pour prendre un exemple "relativement récent", en extrapolant un peu, on peut parler des moteurs 3D UnrealEngine, améliorés à chaque version.

A faire de l'indépendant, on s'est retrouvé avec une quantité de jeu n'ayant pas de gameplay digne de ce nom, les gars partent de rien, ça arrive que dans certains cas ça marche, enfin c'est les exceptions qui confirment la rêgle.

Bien sur si il y a un nouveau concept et bien on développe un nouveau moteur, mais ça a l'intérêt de partager les connaissances et aussi de vendre le travail effectué.

Pour résumer les choses, si on démarre un jeu sur
Atari ST, il sera calibré pour la machine, très bien,
mais une fois
sur amiga, il fera très pauvre. A l'inverse, un jeu calibré pour
l'amiga sera appauvri sur ST
sinon même pas la peine de le
convertir.....

D'où l'intérêt des routines/fonctions, plutôt que de faire bêtement du calibrage ou de la reconversion bête et méchante. Tout ça, ça a donné quoi ? Et bien des jeux bâclés pour l'une ou l'autre machine.

[youki]

@dlfrsilver :

Alors autant des fois tu dis des trucs plutot vrai autant tu t'emballe et tu dis beaucoup de conneries. Et en plus tu ne lis pas bien les posts...

Tu es developpeur, tu as deja travail pour un studio de developpement ? Tu as deja creer un jeu? Est ce que tu as "touché" le milieu de l'interieur? Est ce que tu as la moindre idée des contraintes que l'on a?

Biensur, il y a de mauvais programmeurs, des programmeurs debutants , des "stagiaires" a qui ont confier des projets , generalement des portages "simple" sur des machines a faible potentiel commercial. Mais la plus part des problemes de "portage" ne sont pas le fait de la competence des programmeurs. La grande majorité dans ce milieu etait des passionnés qui aime le travail bien fait et qui ne demandait pas mieux d'exploiter au mieux la machine. Mais on leur en laisser simplement pas le temps. Business avant tout. Et des qu'il y a la moindre notion de business , tout par en vrille..

[Clinteeswoud]

Cà va partir en cou.lle bientôt ici

Pour faire râler, je dirais que celui qui voulait des bons jeux d'arcade à l'époque de la guerre ST/Amiga se devait d'avoir.....une PC Engine ou une Megadrive, là on était rarement déçu si on choisissait bien ses jeux



Ok je sors, mais c'est quand même un peu vrai...

[Invité]

Je voulais le dire depuis un moment mais j'osais pas...

[Chrysaor]

Ok je sors, mais c'est quand même un peu vrai...

C'est même tout à fait vrai

[Clinteeswoud]

Je voulais le dire depuis un moment mais j'osais pas...

OSONS !

https://www.youtube.com/watch?v=Ogcpl1Ajbbg&feature=related

[Invité]

Je pense qu'on surestime l'amiga.

Un bon code sur St doit être en principe un bon code sur Amiga. Le processeur est le même et le langage utilisé est normalement l'ASM.

AU SECOURS !!!!!!!

[dlfrsilver]

@dlfrsilver :

Alors autant des fois tu dis des trucs plutot vrai autant tu t'emballe et tu dis beaucoup de conneries. Et en plus tu ne lis pas bien les posts...

Tu es developpeur, tu as deja travail pour un studio de developpement ? Tu as deja creer un jeu? Est ce que tu as "touché" le milieu de l'interieur? Est ce que tu as la moindre idée des contraintes que l'on a?

Biensur, il y a de mauvais programmeurs, des programmeurs debutants , des "stagiaires" a qui ont confier des projets , generalement des portages "simple" sur des machines a faible potentiel commercial. Mais la plus part des problemes de "portage" ne sont pas le fait de la competence des programmeurs. La grande majorité dans ce milieu etait des passionnés qui aime le travail bien fait et qui ne demandait pas mieux d'exploiter au mieux la machine. Mais on leur en laisser simplement pas le temps. Business avant tout. Et des qu'il y a la moindre notion de business , tout par en vrille..

Ma réponse : Je connais personnellement des développeurs célèbres, avec qui je parle souvent (mail ou téléphone). Et je bosse dans le monde informatique, j'ai même été manager. Donc oui si on me parle de contraintes, j'en connais un rayon.

Les raisons politiques sont en général le souci, et ça même dans ta branche à toi. Les contraintes y en a toujours eu, ça ça n'a pas changé, simplement les mecs en face sont excellents, moyens, ou mauvais. Y a que ça qui varie. Des mecs super bons sortiront du très bon, et les autres du moyen ou de la merde. Et la passion ça suffit pas !

si je m'emballe, c'était parce que j'ai lu à l'époque des choses qui m'ont hyper déçu, de la part de mecs qui auraient pu vraiment avec les contraintes données, faire mieux que ce qui est sorti.

Des jeux ont été massacrés alors qu'ils auraient pu être mieux foutus.

Si j'avais été manager à l'époque, c'est clair j'aurais plus d'une fois tapé du poing sur la table si j'avais du bosser chez les éditeurs en question. finalement il a fallu que 2 mecs de psygnosis leur ouvrent les yeux car ils en avaient marre de voir l'amiga sous-utilisé et de voir le niveau des daubes qui sortaient en terme technique en provenance du ST. C'est bien la preuve que les mecs étaient trop axés ST dans leur esprit. Et l'autre aspect si on regarde bien, c'est que techniquement pour aller plus haut ou plus loin, fallait une bécane avec les reins plus solides, et ils ont donc fini par coder les jeux sur l'amiga en premier, donc plus poussés.

Comme je disais sur un autre forum : y a eu 3 générations de jeux 16 bits.
la 1ère génération de 87 à 89 (jusqu'à beast en fait, ou c'était que du portage ST -> Amiga), la deuxième de 90 à 91, et la dernière de 92 à 95
ou la les jeux sur ST n'étaient plus convertibles (enfin si, mais ça aurait été tellement mauvais vu le nombre d'éléments à ne pas inclure que ça ne se serait pas vendu de toute façon).

Brian the lion par exemple, propose des effets identiques à ceux fournis par la SNES (effets de rotations), mais en beaucoup mieux à l'aide du copper, d'après ce qu'en a dit Martin edmondson. L'amiga avec le copper sait faire des rotations plus pointues et plus précises que la snes, en sachant que sur cette dernière les effets de rotations sont même buggés !
Ils s'en sont rendu compte quand ils ont fait des tests avant d'implémenter la chose sur Brian the lion. Faut rajouter à ça une très bonne maniabilité, une quantité impressionnante de sprite rien que pour brian (215), et je parle pas des autres personnages.... A rajouter les multiples parallaxes,
les effets de de-rezing (effets de pixellisation façon super mario world quand on est sur la carte), effets de transparences, un défilement à 50 images seconde, 2 méga octets de musiques & sons. Vous auriez vu ça sur ST ? Pas moi !

@archimedes : Oui comme tu dis, au secours !

@clinteeswood : Tu as tout à fait raison, ces 2 consoles ne font appels qu'à des fonctions hardware, tout est cablé...... donc forcément ça permettait des jeux bien plus etoffés.... logique !

[youki]

L'amiga avec le copper sait faire des rotations plus pointues et plus précises que la snes, en sachant que sur cette dernière les effets de rotations sont même buggés !

Des rotations avec le Copper , mais oui , mais oui....

j'ai même été manager.

Donc tu ne l'es plus! Heureusement...

Si j'avais été manager à l'époque, c'est clair j'aurais plus d'une fois tapé du poing sur la table si j'avais du bosser chez les éditeurs en question.

Tu n'aurais pas fait long feu. Vouloir, c'est une chose, pouvoir c'est autre chose. Meme en tant que Manager tu ne fais ce que tu veux, tu fais ce que les shareholders veulent.
toi en tant que manager , tu auras l'ordre suivant : Je veux une adaptation de cette license, sur tel et tel plateform , tu as un budget de tant, et il faut que le jeu sorte telle date. Et toi, en tant que bon manager tu regarde ce que tu as a disposition comme moyen, et tu t'apercois que pour faire bien ce que l'on te demande il te faudrait 4 fois plus de temps. Alors comme la date , le budget et tout et tout sont inflexible. Tu essaye de faire au mieux.
=> Reutiliser un max ce que l'on a deja, routines, library, "moteur de jeu" . Mutualisé un maximum le code pour les portages pour pas avoir a tout refaire . Idem pour les graphismes , les son et tout et tout. Sans comptais que tu n'a meme pas assyez de ressource humaine pour arriver a tes fins.
Le resultat, oui tu as raison, malheureusement, c'est le nivelement par le bas. Qui peut le plus, peut le moins.
Exemple typique de ce type de developement mutualisé : Barbarian de palace software. (il me semble qu'il y a d'ailleu un excellent article dans pix'n love).

Et puis, avec des 'SI' ont peu tout faire. L'art est difficle, la critique est facile.

Mais bon on est d'accord sur un point tout les machines ont été sous exploité. Que ce soit ST,AMIGA,CPC ,C64 ou autres... et c'est particulierement vrai pour les ST et AMIGA.

[screetch]

Pour moi, malgré la supériorité de tas de jeux sur la Megadrive par rapport à l'Amiga, je préfèrerais toujours l'Amiga grâce au son qu'il était capable de sortir... La Megadrive n'avait pas un mauvais proc. sonore mais bien en deça de l'Amiga quand même.

Je n'ai rien contre les Atari ST, j'ai longtemps hésité entre les deux supports lorsque je me suis acheté ma machine en 1991, mais l'Amiga 500 surpasse largement l'Atari 520 ST au vu de ses capacités, n'en déplaise à certains. Certes le 68000 était moins rapide mais ses coppros prenaient en charge tellement de choses...

C'est d'ailleurs ce même principe qui est repris dans le nouvel AmigaOne X1000, le CPU est un bête CPU PowerPC multi-coeur mais il est soulagé par sa puce Xena à 4 coeurs. De plus, via le port Xorro, on peut lui rajouter quasiment autant de puces Xena (4 coeurs toujours) que l'on veut !

Pour en revenir à la grande époque, si j'avais pus vraiment choisir ma machine 68000, je pense que je me serais rabbatus sur le X68000 de Sharp. Avec toujours le même CPU, l'Amiga et l'Atari ST faisaient figure de Spectrum à côté !! Comme quoi le CPU ne suffit pas !!

Sharp X68000 pour ceux qui ne connaitraient pas cette machine, uniquement distribuée au Japon :



Final Fight sur Amiga (franchement, ils auraient pus faire mieux quand même) :


Final Fight sur X68000 :

[Invité]

Et l'Archimedes !

[screetch]

L'Archimedes n'était pas trop mal, mais la comparaison est plus compliquée car le CPU est différent. Pour moi, l'Archimedes se compare plus à l'Apple II GS, mais en mieux.

J'ai un RiscPC à la maison d'ailleurs, mais je n'ai pas de souris, @Archimedes, tu saurais ou en trouver ? Il y a moyen de faire évoluer son OS ? Le fait qu'il soit en ROM n'est pas toujours une bonne idée en cas d'évolution.

En parlant d'Archimedes, j'ai fait mes études aux Pays de Galles (1996-1998) à Wrexham et il y avait encore une salle d'informatique remplie d'Archimedes et j'étais le seul à allumer ces machines de temps en temps. Et dans la médiathèque, il y avait des Amiga 2000 et 3000 pour ceux qui bossaient sur la vidéo. Et je faisais mes "assignments" sur mon Amiga 1200 avec une 030 en émulant un PC sous PC-Task pour faire mes compilations en Borland C++ ! Que de souvenirs !!

[jf]

sympa comme machine, mais vache ça douille :
http://cgi.ebay.fr/Sharp-x68000-Expert-HD-PC-Japan-40GB-HDD-2MB-RAM-NICE_W0QQitemZ350342211787QQcmdZViewItemQQptZVintage_Electronics_R2?hash=item519205e8cb

[68000]

je cherche des infos sur le jeu "baby joe" par Loriciel un jeu plébliscité à outrance et finalement hyper déçu réalisation digne d'une machine sans copro scrolling,sprite sacadés bande sonore mignonne mais sans plus et aussi une jouabilité pourrie !! .

[screetch]

je cherche des infos sur le jeu "baby joe" par Loriciel un jeu plébliscité à outrance et finalement hyper déçu réalisation digne d'une machine sans copro scrolling,sprite sacadés bande sonore mignonne mais sans plus et aussi une jouabilité pourrie !! .

Quelles genres d'infos tu cherches sur Baby Joe ? Je bosse avec Philippe Seban, l'ancien boss de Loriciel, nous éditons maintenant un magazine papier sur les robots en kiosque "Planète Robots", j'en suis le rédacteur en chef.

[Invité]

L'Archimedes n'était pas trop mal, mais la comparaison est plus compliquée car le CPU est différent. Pour moi, l'Archimedes se compare plus à l'Apple II GS, mais en mieux.

J'ai un RiscPC à la maison d'ailleurs, mais je n'ai pas de souris, @Archimedes, tu saurais ou en trouver ? Il y a moyen de faire évoluer son OS ? Le fait qu'il soit en ROM n'est pas toujours une bonne idée en cas d'évolution.

En parlant d'Archimedes, j'ai fait mes études aux Pays de Galles (1996-1998) à Wrexham et il y avait encore une salle d'informatique remplie d'Archimedes et j'étais le seul à allumer ces machines de temps en temps. Et dans la médiathèque, il y avait des Amiga 2000 et 3000 pour ceux qui bossaient sur la vidéo. Et je faisais mes "assignments" sur mon Amiga 1200 avec une 030 en émulant un PC sous PC-Task pour faire mes compilations en Borland C++ ! Que de souvenirs !!

Apple II GS ? Heu celle là on ne me l'avait jamais fait.

Souris : Ebay, ou bien tu me demandes gentiment je t'en envoie une.

Evolution système : en ROM juqu'au 4.39 et le 6.xx en soft sur tout RISC OS à partir de 4.xx
http://select.riscos.com/RISCOS6/
Là ausi j'ai ROM et CD.
Plus en MP ?

Bye.

[68000]

je cherche des infos sur le jeu "baby joe" par Loriciel un jeu plébliscité à outrance et finalement hyper déçu réalisation digne d'une machine sans copro scrolling,sprite sacadés bande sonore mignonne mais sans plus et aussi une jouabilité pourrie !! .

Quelles genres d'infos tu cherches sur Baby Joe ? Je bosse avec Philippe Seban, l'ancien boss de Loriciel, nous éditons maintenant un magazine papier sur les robots en kiosque "Planète Robots", j'en suis le rédacteur en chef.

juste des infos sur sa conception (technique,commercial)...