Re: Amiga vs consoles (Snes, Md, Pc Engine,.......)

[cryodav76]

et puis il y a aussi tous les jeux d'aventure quasi impossible sur console
dune et sa musique un vrai space opera



universe et ses 256c sur un simple a500



the settler premier jeux de gestion sur amiga qui ma marqué
d'ailleurs il y a encore des suites on en est au 7


et le meilleur jeu d'aventure (14 disquettes mais instalable sur hdd)

[dlfrsilver]

@TOUKO : tiens voilà l'archive qui contient le code source d'Art of Fighting  Neo-geo ainsi que le code source de la version PCE CDROM :
https://app.box.com/s/xkijbgqarafj65jb1fic

@Cryodav76 :

moi je l'avais acheté a l'epoque mais trop de texte en anglais du coup j'y ai pas joué

Le jeu n'a jamais été vendu en anglais, uniquement en langue allemande. J'ai traduis le prototype donné au site thalion webshrine en français (et en corrigeant les fôtes et les bugs internes des textes....)

[cryodav76]

@TOUKO : tiens voilà l'archive qui contient le code source d'Art of Fighting  Neo-geo ainsi que le code source de la version PCE CDROM :
https://app.box.com/s/xkijbgqarafj65jb1fic

@Cryodav76 :

moi je l'avais acheté a l'epoque mais trop de texte en anglais du coup j'y ai pas joué

Le jeu n'a jamais été vendu en anglais, uniquement en langue allemande. J'ai traduis le prototype donné au site thalion webshrine en français (et en corrigeant les fôtes et les bugs internes des textes....)

ah ba dans mes souvenir c'etait anglais mais du coup je comprend encore plus pourquoi j'y comprenais rien
edit: j'ai confondu avec perihelion

[dlfrsilver]

si si je me rends bien compte, j'en ai parlé avec des programmeurs amiga confirmés qui m'ont dit que franchement l'affichage en 25 fps, ils auraient pu se fouler un peu.

Rien que CFOU par exemple, qui est un génie en programmation sur amiga, pourrait te le dire. Beau jeu, mais clairement poussif. On a des jeux en 32 couleurs mieux foutus que ça !

Et hormis critiquer, ils codent quoi ses bons programmeurs ?
Car pour moi, l'Amiga est définitivement le parent pauvre de la scène homebrew.

Et pour les jeux mieux foutu, je demande à voir ! 
(sauf si c'est encore de la poudre au yeux façon coquille vide...)

Oh oui j'oubliais ! CFOU a reprogrammé (ressourcé d'abord) Eye of the beholder I et II (sur mon idée), pour passer le jeu en 256 couleurs sur A1200 comme sur PC, pouvoir traduire le jeu en français (ça c'est moi).....

Je peux te dire que c'était pas une mince affaire, il a du programmer des outils pour ouvrir tout les fichiers du jeu (compressés et ou encryptés), et pour finir il a incorporé dans le jeu une map exactement comme dans lands of lore qui n'était pas présente au début.

Donc je pense que je peux m'appuyer sur lui et l'écouter

[Invité]

tiens voilà l'archive qui contient le code source d'Art of Fighting  Neo-geo ainsi que le code source de la version PCE CDROM : 
https://app.box.com/s/xkijbgqarafj65jb1fic

Merci bcp, je vais voir ça de près 

Donc je pense que je peux m'appuyer sur lui et l'écouter 

Si tu peux avoir son avis sur les jeux amiga, fais nous en part, ce serrait intéressant je pense .


EDIT:Je viens de regarder un peu les sources PCE, et c'est très instructif .
1 - C'est le bordel, lol plein de fichiers .
2- Très grosse utilisation de macros, et effectivement émulation du jeu d'instructions du 68000 
3- y'a des déclarations de variables propres à un compilo C 
4- Comme je le pensais,c'est quand même assez mal codé, la vache.
5- Il manque des fichiers, dommage 

[TotOOntHeMooN]

Oh oui j'oubliais ! CFOU a reprogrammé (ressourcé d'abord) Eye of the beholder I et II (sur mon idée), pour passer le jeu en 256 couleurs sur A1200 comme sur PC, pouvoir traduire le jeu en français (ça c'est moi).....

Je peux te dire que c'était pas une mince affaire, il a du programmer des outils pour ouvrir tout les fichiers du jeu (compressés et ou encryptés), et pour finir il a incorporé dans le jeu une map exactement comme dans lands of lore qui n'était pas présente au début.

Donc je pense que je peux m'appuyer sur lui et l'écouter

Non mais des gars qui savent patcher et bidouiller des jeux/outils il y en a à la pelle. 
Le truc, c'est qu'ils sont incapable de bosser sur un vrai projet, si ça prends plus de 2/3 semaines.
Chacun son truc...

[Invité]

Non mais des gars qui savent patcher et bidouiller des jeux/outils il y en a à la pelle.  
Le truc, c'est qu'ils sont incapable de bosser sur un vrai projet, si ça prends plus de 2/3 semaines.
Chacun son truc...

Je plussois, on sent l'expérience mon petit toto 

Quand tu codes un jeu, tu vois plus les bouses de la même façon 

[TotOOntHeMooN]

et puis il y a aussi tous les jeux d'aventure quasi impossible sur console
dune et sa musique un vrai space opera

Tout à fait, c'est ce que je soulignais en disant que l'Amiga n'est pas enfermé dans un moule come une console de salon ou une machine d'arcade.
Il permet beaucoup de créativité et proposer une multitude de genres difficilement réalisables sur d'autres machines !
Et c'est la que l'Amiga est roi...

[TotOOntHeMooN]

Je plussois, on sent l'expérience mon petit toto  
Quand tu codes un jeu, tu vois plus les bouses de la même façon 

C'est exactement ça ! 

[Invité]

t'as quand même pas divorcé avec fano ??, rassures moi !!

[TotOOntHeMooN]

Ca va pas !
Il fait parti des rares programmeurs de talent* qui savent tenir un projet sur le long terme.

* que dis-je, d'exception!

[Invité]

Ca aurait été vraiment dommage, surtout que je veux voir finir vos projets en cours .. 

[TotOOntHeMooN]

Heureusement que tu ne vois pas ce qui est déjà existant alors.
Y'en a qui prendraient une crise cardiaque à Gamopat... 

[Invité]

Ahaha, mais je vous fais confiance là dessus   ...

Y'en a qui prendraient une crise cardiaque à Gamopat... 

Faudra fournir le défibrillateur avec alors,parce qu'ils sont plus très jeunes les gars ici 

[TotOOntHeMooN]

Oui, faudra mettre un avertissement avant...

[Invité]

LOL un PEGI -60 ans ??

[TotOOntHeMooN]

A méditer... 

[dlfrsilver]

Oh oui j'oubliais ! CFOU a reprogrammé (ressourcé d'abord) Eye of the beholder I et II (sur mon idée), pour passer le jeu en 256 couleurs sur A1200 comme sur PC, pouvoir traduire le jeu en français (ça c'est moi).....

Je peux te dire que c'était pas une mince affaire, il a du programmer des outils pour ouvrir tout les fichiers du jeu (compressés et ou encryptés), et pour finir il a incorporé dans le jeu une map exactement comme dans lands of lore qui n'était pas présente au début.

Donc je pense que je peux m'appuyer sur lui et l'écouter

Non mais des gars qui savent patcher et bidouiller des jeux/outils il y en a à la pelle. 
Le truc, c'est qu'ils sont incapable de bosser sur un vrai projet, si ça prends plus de 2/3 semaines.
Chacun son truc...

C'est tout sauf de la bidouille, faut savoir faire mieux que ça pour reprendre un jeu tel que celui-là de A à Z.
Recoder EOB I et II ça lui a pris 8 mois !

[dlfrsilver]

tiens voilà l'archive qui contient le code source d'Art of Fighting  Neo-geo ainsi que le code source de la version PCE CDROM : 
https://app.box.com/s/xkijbgqarafj65jb1fic

Merci bcp, je vais voir ça de près 

Donc je pense que je peux m'appuyer sur lui et l'écouter 

Si tu peux avoir son avis sur les jeux amiga, fais nous en part, ce serrait intéressant je pense .


EDIT:Je viens de regarder un peu les sources PCE, et c'est très instructif .
1 - C'est le bordel, lol plein de fichiers .
2- Très grosse utilisation de macros, et effectivement émulation du jeu d'instructions du 68000 
3- y'a des déclarations de variables propres à un compilo C 
4- Comme je le pensais,c'est quand même assez mal codé, la vache.
5- Il manque des fichiers, dommage 

1-Oui plein de fichiers
2-Oui macros à donf et conversion à la ligne du code original 68000
3-Viiii
4-tu parles du source PCE ? surement lool (la version neogeo est bien faite elle)
5-certain, mais ça devrait pouvoir se corriger :)

[TotOOntHeMooN]

C'est tout sauf de la bidouille, faut savoir faire mieux que ça pour reprendre un jeu tel que celui-là de A à Z. Recoder EOB I et II ça lui a pris 8 mois !

8 mois, je suis quand même surpris... Hormis s'il a effectivement recodé tout le jeu.

Passer un jeu OCS/ECS en AGA, ça nécessite de patcher le mode graphique pour qu'il soit en 8 bitplan au lieu de 4/5 bitplan et substituer les anciennes resources avec les nouvelles. (gfx et texte dans ton cas)
Un amis avait fait quelque chose de semblable avec WingCommander, pour l'utiliser sur A1200 à l'époque.

[Stef]

EDIT:Je viens de regarder un peu les sources PCE, et c'est très instructif .
1 - C'est le bordel, lol plein de fichiers .
2- Très grosse utilisation de macros, et effectivement émulation du jeu d'instructions du 68000 
3- y'a des déclarations de variables propres à un compilo C 
4- Comme je le pensais,c'est quand même assez mal codé, la vache.
5- Il manque des fichiers, dommage 

C'est de la traduction de code 68000 en code 6502, en disant émulation on pourrait penser qu'ils émulent carrément le jeu d'instruction 68000 ce qui n'est pas le cas (dans ce cas la conversion aurait pris 1 journée). Et ça reste de la traduction manuelle fort heureusement, ce qui permet quand même d'arranger un peu le code pour que ça tourne sur le 6280 (y'a pas mal de parties où le code a été adapté au 6280). Cela dit effectivement globalement ça produit un code non optimisé pour le 6280, heureusement que ce n'est pas un jeu exigeant en ressource CPU. D'ailleurs le code 68000, s'il est propre et bien structuré n'est pas particulièrement optimisé non plus (mais y'en a vraiment pas besoin ici).

[Invité]

C'est de la traduction de code 68000 en code 6502

Non c'est bien des fonctions (enfin des macros) comme des intructions 68000 .
Tu as des move (An),quelque chose, lea , etc ...
En gros des trucs pour simplifier la prog ,et qui sont inoptimisables et pas adaptées du tout.

(y'a pas mal de parties où le code a été adapté au 6280)

Dans tout le code que j'ai pu voir (y'a pas celui du programme pricipal et de pas mal de fonctions comme la gestion du son) c'est plein de macros,et en plus du code générique, pas optimisé du tout .
Rien qu'a voir la traduction du MOVE fait peur .
Alors qu'un move peut être remplacé par une seule instruction txx @source, @dest , taille
On programme pas comme ça sur 65xx, et encore moins sur 6280 .
Y'a encore aussi pas mal de choses codées comme sur un 6502, et non un 6280 .

Tu as en plus pleins de boucles, alors que l'utilisation des instructions de transfert de blocs auraient été plus performante tout en consommant moins d'espace .
J'ai vu aucune utilisation des instructions de transfert de blocs .

J'ai aussi vu des if/else à ralonge (style une 20 aine de lignes) .

D'ailleurs le code 68000, s'il est propre et bien structuré n'est pas particulièrement optimisé non plus (mais y'en a vraiment pas besoin ici).

Le code 68000 (mais je suis pas expert) est bcp plus propre, du moins dans l'organisation .

[Kristof]

La plupart des mecs qui tuent sur amiga manquent de temps pour coder. Ils sont pris par des projets professionnels, ou bien par leur vie de famille.

Voila oui.

J'ai mangé 10 ans de code asm quand j'étais jeune et je pense que maintenant je n'aurai plus le courage. De plus, pas sur qu'il y ai un réel public.

Il y a tellement d'autres machines sympas, que c'est sympa de tenter de nouvelles choses. En homebrew j'ai surtout fait de la GBA et de la PSP. Les console ca reste toujours plus sympa que les micros (pour des problèmes de compatibilité)

[Stef]

(y'a pas mal de parties où le code a été adapté au 6280)

Dans tout le code que j'ai pu voir (y'a pas celui du programme pricipal et de pas mal de fonctions comme la gestion du son) c'est plein de macros,et en plus du code générique, pas optimisé du tout .
Rien qu'a voir la traduction du MOVE fait peur .
Alors qu'un move peut être remplacé par une seule instruction txx @source, @dest , taille
On programme pas comme ça sur 65xx, et encore moins sur 6280 .
Y'a encore aussi pas mal de choses codées comme sur un 6502, et non un 6280 .

Tu as en plus pleins de boucles, alors que l'utilisation des instructions de transfert de blocs auraient été plus performante tout en consommant moins d'espace .
J'ai vu aucune utilisation des instructions de transfert de blocs .

J'ai aussi vu des if/else à ralonge (style une 20 aine de lignes) .

En fait j'ai regardé un peu plus et ça dépends beaucoup des parties...
Certaines parties ont été complètement réécrites, notamment celle proche du hardware (pour gérer les scrollings etc...) ce qui semble logique :p
Certaines parties ont été traduites mais avec une certaines adaptation au 6502 et d'autres effectivement simulent plus "bêtement" l’exécution du 68000 (surement par flemme) et dans ce cas ça génère un cas catastrophique pour le 6502...
Genre cette partie de code :

Code:


 ;MOVE.W VZ(A2),D4
 ;MOVE.W VZ(A3),D5
 ;MOVE.W HIT_UPPER(A4),D0
 ;ADD.W D4,D0
 ;MOVE.W HIT_LOWER(A6),D1
 ;ADD.W D5,D1

 lda ar_HIT_UPPER_l,x
 add ma_VZ_l,x
 sta _d0_l
 lda ar_HIT_UPPER_h,x
 adc ma_VZ_h,x
 sta _d0_h
 ;
 lda ar_HIT_LOWER_l,y
 add ma_VZ_l,y
 sta _d1_l
 lda ar_HIT_LOWER_h,y
 adc ma_VZ_h,y
 sta _d1_h
 ;
 ;CMP.W D1,D0
 lda _d0
 cmp _d1
 lda _d0_h
 sbc _d1_h
 bmi BODY_HIT_NON_rts2 ;BLT BODY_HIT_NON(rts)
 ;
 ;MOVE.W HIT_LOWER(A4),D0
 ;ADD.W D4,D0
 ;MOVE.W HIT_UPPER(A6),D1
 ;ADD.W D5,D1
 lda ar_HIT_LOWER_l,x
 add ma_VZ_l,x
 sta _d0_l
 lda ar_HIT_LOWER_h,x
 adc ma_VZ_h,x
 sta _d0_h
 ;
 lda ar_HIT_UPPER_l,y
 add ma_VZ_l,y
 sta _d1_l
 lda ar_HIT_UPPER_h,y
 adc ma_VZ_h,y
 sta _d1_h
 
 ;CMP.W D1,D0
 lda _d0
 cmp _d1
 lda _d0_h
 sbc _d1_h
 bpl BODY_HIT_NON_rts2 ;BGT BODY_HIT_NON(rts)
 ;
 phx
 jsr GET_BODY_MOVE ;BSR GET_BODY_MOVE
 plx
 jsr DAM_STOP ;BSR DAM_STOP
 ;
 ;MOVE.L X_POSITION(A1),D0
 ;ADD.L D3,D0
 lda h_X_POSITION_f,y
 add _d3_f
 sta _d0_f
 lda h_X_POSITION_l,y
 adc _d3_l
 sta _d0_l
 lda h_X_POSITION_h,y
 adc _d3_h
 sta _d0_h
 ;SUB.L #300_0000H-DE_Lim*10000H,D0
 sec
; lda _d0_f
; sbc #0
; sta _d0_f
 lda _d0_l
 sbc #low (MAP_WIDTH-DE_Lim)
 sta _d0_l
 lda _d0_h
 sbc #high(MAP_WIDTH-DE_Lim)
 sta _d0_h
 ;BLE.S BODY_HIT_1
 bmi BODY_HIT_1
 ora _d0_l
 ora _d0_f
 beq BODY_HIT_1
 ;
 ;SUB.L D0,D3
 lda _d3_f
 sub _d0_f
 sta _d3_f
 lda _d3_l
 sbc _d0_l
 sta _d3_l
 lda _d3_h
 sbc _d0_h
 sta _d3_h
 ;SUB.L D0,D2
 lda _d2_f
 sub _d0_f
 sta _d2_f
 lda _d2_l
 sbc _d0_l
 sta _d2_l
 lda _d2_h
 sbc _d0_h
 sta _d2_h
BODY_HIT_1:
 ;MOVE.L X_POSITION(A0),D0
 ;ADD.L D2,D0
 lda h_X_POSITION_f,x
 add _d2_f
 sta _d0_f
 lda h_X_POSITION_l,x
 adc _d2_l
 sta _d0_l
 lda h_X_POSITION_h,x
 adc _d2_h
 sta _d0_h
...


Les sub.l sont catastrophiques sur le 6502  
Enfin bon évidemment une traduction bête et méchante comme celle ci est loin d'être optimale mais ça montre quand même à quel point le jeu d'instruction du 68000 est plus avancé que celui du 6502. Je pense que toutes les instructions du 6502 (et dérivé) de traduisent en 1:1 sur un 68000 par contre l'inverse c'est clairement pas le cas  

[Invité]

Surtout quand en plus la trad en code 6280 est pourrie 

Bon bien sur in-game on s'en rend pas compte du tout, ça montre bien que ça dépote comme CPU, car en plus même les partie en 6280 sont même pas optimisées puisque c'est du bête code 6502 .

Les sub.l sont catastrophiques sur le 6502  
Enfin bon évidemment une traduction bête et méchante comme celle ci est loin d'être optimale mais ça montre quand même à quel point le jeu d'instruction du 68000 est plus avancé que celui du 6502. Je pense que toutes les instructions du 6502 (et dérivé) de traduisent en 1:1 sur un 68000 par contre l'inverse c'est clairement pas le cas  

Déjà encore une belle aberration, une soustraction en 32 bit dont je suis sur qu'elle n'a rien à foutre ici et est facilement évitable,et témoigne encore un peu plus d'une façon de coder très 68000, et non 6280 native .

Oui le jeu d'instructions du 68000 est plus avancé, je dis pas le contraire, mais plus lent aussi,et surtout bien moins optimisable  , d'ailleurs même avec ce code merdique la version PCE d'AOF dépote grave 

[Stef]

Surtout quand en plus la trad en code 6280 est pourrie 

Bon bien sur in-game on s'en rend pas compte du tout, ça montre bien que ça dépote comme CPU, car en plus même les partie en 6280 sont même pas optimisées puisque c'est du bête code 6502 .

Les sub.l sont catastrophiques sur le 6502  
Enfin bon évidemment une traduction bête et méchante comme celle ci est loin d'être optimale mais ça montre quand même à quel point le jeu d'instruction du 68000 est plus avancé que celui du 6502. Je pense que toutes les instructions du 6502 (et dérivé) de traduisent en 1:1 sur un 68000 par contre l'inverse c'est clairement pas le cas  

Déjà encore une belle aberration, une soustraction en 32 bit dont je suis sur qu'elle n'a rien à foutre ici et est facilement évitable .

Oui le jeu d'instructions du 68000 est plus avancé, je dis pas le contraire, mais plus lent aussi,et surtout bien moins optimisable  , d'ailleurs même avec ce code merdique la version PCE d'AOF dépote grave 

Ouais enfin c'est pas du miracle non plus, un jeu de versus figthing c'est hyper light en CPU, genre là le code que je te montrais c'est la collision sur le corps du perso, le code va s'executer 2 fois par frame, ça va, il va tenir le CPU, même si c'est pas optimisé
Puis tu dis que le 6280 n'est pas bien utilisé, mais que veux tu l'utiliser ici ? y'a pas de copie / mémoire, juste un peu de logique... et là dessus je ne sais pas ce qu'apporte un 6280.
Pour la soustraction 32 bits, oui effectivement elle n'est surement pas obligatoire (16 bits suffirait probablement) mais pour garantir le fonctionnement ils ont préféré assurer la même execution que le code 68000.
J'aurais bien aimé voir le résultat s'ils avaient tenté de traduire le code 68000 mais venant d'un jeu comme ...Gynoug (fallait bien en prendre un :p), ça m'étonnerait que le petit 6280 s'en sorte encore

[Invité]

Oui enfin tout le jeu est comme ça, si seule une partie l'était ok ..

Et tu imagines le désastre sur le 65816 qui en plus doit faire avec l'archie pourrie de la snes !!! 

Puis tu dis que le 6280 n'est pas bien utilisé, mais que veux tu l'utiliser ici ?

Dans la façon de coder, là le codeur fait du code 6502, et n'utilise que très peu les instructions supplémentaires du 6280 qui sont nombreuses .
Par exemple il fait des boucles monstrueuse (au sens code) pour effacer la vram, alors qu'en utilisant le DMA ou les instructions txx c'est autrement plus rapide et gratuit en cas de DMA .

Il fait aussi des copies mémoire avec des pseudos instructions MOVE, alors qu'on doit utiliser txx qui est bccccp plus rapide(que le move du programme hein, pas celui du 68000) .

Te sors 20 lignes de if/else à la suite alors qu'un codeur 6280 pense de suite jump table bcp plus rapide ..

Le pire c'est que j'ai vraiment l'impression que le jeu a été codé en C ..

J'aurais bien aimé voir le résultat s'ils avaient tenté de traduire le code 68000 mais venant d'un jeu comme ...Gynoug (fallait bien en prendre un :p), ça m'étonnerait que le petit 6280 s'en sorte encore 

C'est fort probable, mais n'oublies pas aussi que la version PCE d'AOF simule un zoom, pas en temps réel ok, mais faut recalculer la map à la volée + retransférer à la volée les sprites qui du coup sont BCP plus gros,et tout au CPU .
Le CPU gére aussi le son (bon là c'est pas énorme non plus) .

Mais le truc est que tu codes en natif pour ton CPU, tu essaies pas de coder comme un autre sur une archi qui n'a rien à voir, j'aimerai bien voir comment se comporterait le 68000 avec le code de gynoug en 6280/65xx ..

Le code de merde tu en sais quelque chose sur le résultat catastrophique que ça peut avoir (sf2CE !!) 
De toutes façons quand tu codes correctement tu traduits pas des instructions mais un algo .

Je viens de trouver des fonctions avec ce style de code traduit à l'arrache (CAD à l'instruction prêt) par kilo

BACK2_CENTOR:
LEA.L BACK2(A5),A6
CLR.W Z_POSITION(A6)
MOVE.W #100H,D4
MOVE.W D4,BIG_X(A6)
BSR GET_Lxy

MOVE.W #180H,REG_D0(A5)
BSR GET_WINDOW_POSITION
BSR GET_WINDOW_WIDTH
BSR GET_WINDOW_EDGE
BSR GET_SCROLL_LSPC
BSR BACK2_BUFFER_IN
RTS
 

[dlfrsilver]

C'est tout sauf de la bidouille, faut savoir faire mieux que ça pour reprendre un jeu tel que celui-là de A à Z. Recoder EOB I et II ça lui a pris 8 mois !

8 mois, je suis quand même surpris... Hormis s'il a effectivement recodé tout le jeu.

Passer un jeu OCS/ECS en AGA, ça nécessite de patcher le mode graphique pour qu'il soit en 8 bitplan au lieu de 4/5 bitplan et substituer les anciennes resources avec les nouvelles. (gfx et texte dans ton cas)
Un amis avait fait quelque chose de semblable avec WingCommander, pour l'utiliser sur A1200 à l'époque.

Wing commander est déjà compatible 1200. La version CD32 est en 256 couleurs elle :)

[Stef]

Oui enfin tout le jeu est comme ça, si seule une partie l'était ok ..

Et tu imagines le désastre sur le 65816 qui en plus doit faire avec l'archie pourrie de la snes !!! 

Effectivement mais encore une fois je pense que le jeu est très light en logique, 2 persos à afficher et à gérer, même avec du merde c'est le genre de jeu qui va bien tourner, la seule difficulté, c'est la bande passante pour la mise à jour du sprite.

Dans la façon de coder, là le codeur fait du code 6502, et n'utilise que très peu les instructions supplémentaires du 6280 qui sont nombreuses .
Par exemple il fait des boucles monstrueuse (au sens code) pour effacer la vram, alors qu'en utilisant le DMA ou les instructions txx c'est autrement plus rapide et gratuit en cas de DMA .
Il fait aussi des copies mémoire avec des pseudos instructions MOVE, alors qu'on doit utiliser txx qui est bccccp plus rapide(que le move du programme hein, pas celui du 68000) .

Effacer la VRAM ? pourquoi faire ??
Sinon justement je n'ai pas vu ce genre de code (memset, memcpy en gros), en même temps je n'ai pas regardé longtemps...
Effectivement s'il simule des move plutot que de faire du txx ou de la copie de bloc (mais la copie de bloc c'est génant pour les digits j'imagine...) c'est malheureux.

Te sors 20 lignes de if/else à la suite alors qu'un codeur 6280 pense de suite jump table bcp plus rapide ..

Oui oui enfin là pour le coup, même sur 68000 c'est plus rapide, c'est pour ça que je disais que le code 68000 n'était pas particulièrement optimisé, on sent que le développer a privilégié la lisibilité... et surtout s'il en avait pas besoin il a bien eu raison.
D'ailleurs une question tout conne, c'est quoi du code lisible sur 6502 ? non parce-que vu l'architecture du CPU j'ai du mal à imagine un code propre et lisible... rapidement tu as beaucoup de ligne de code pour faire peu d'instruction, ça doit forcément être un peu plus fouillis.

Le pire c'est que j'ai vraiment l'impression que le jeu a été codé en C ..

Puisqu'ils partent d'une base en assembleur 68000 ça me semble juste impossible de repasser par du C derrière, ça serait anti productif :p
Et vu la gueule du code 68000, je ne pense pas que le jeu ait été codé en C à la base (ou alors ils avaient un bon compilateur).

[
C'est fort probable, mais n'oublies pas aussi que la version PCE d'AOF simule un zoom, pas en temps réel ok, mais faut recalculer la map à la volée + retransférer à la volée les sprites qui du coup sont BCP plus gros,et tout au CPU .
Le CPU gére aussi le son (bon là c'est pas énorme non plus) .

Ouais je sais, mais j'ai regardé le jeu, et au moment du zoom tu noteras que le jeu utilise plusieurs frames pour mettre à jour la map et les sprites, après ça passe plutot bien mais ça fait quand même une petite pause dans le jeu.

Mais le truc est que tu codes en natif pour ton CPU, tu essaies pas de coder comme un autre sur une archi qui n'a rien à voir, j'aimerai bien voir comment se comporterait le 68000 avec le code de gynoug en 6280/65xx ..

Le 68000 doit passer les instructions du 6502 en 1:1, après effectivement vu le débit d'instruction sur la PCE, ça ne tiendrait pas sans optimisation spécifique... sur SNES je me demande. En tout cas sache que Super Mario Bros NES a été porté sur Megadrive de cette manière, une traduction automatique du code 6502 en 68000 plus une couche d'émulation pour le son et l'affichage. Le code est inchangé, toutes les variables et la logique du jeu tient dans les 2 ko de RAM d'origine de la NES. Ca montre quand même que le 68000 est relativement puissant puisque le code est clairement pas optimisé pour son architecture et en plus il gère une surcouche d'émulation :
http://devster.proboards.com/thread/613

Le code de merde tu en sais quelque chose sur le résultat catastrophique que ça peut avoir (sf2CE !!) 
De toutes façons quand tu codes correctement tu traduits pas des instructions mais un algo .

Oui bien sur, c'est la raison pour laquelle je dis que c'est n'importe quoi de comparer les cycles des différentes instructions des CPU.
Un vrai comparatif c'est d'implémenter le même algo sur chaque CPU en prenant soin de correctement les utiliser et ensuite de comparer le résultat.

[TotOOntHeMooN]

Wing commander est déjà compatible 1200.

Il était lent et en 16 couleurs... Avec son patch, ça a permis de l'avoir en 256 couleurs, installable sur disque dur et avec un affichage bien plus rapide.
D'ailleurs, je ne serai pas surpris que son code ait été utilisé à l'époque pour la version CD32.
(en tout cas, c'est toujours dispo sur Aminet)

[dlfrsilver]

Wing commander est déjà compatible 1200.

Il était lent et en 16 couleurs... Avec son patch, ça a permis de l'avoir en 256 couleurs, installable sur disque dur et avec un affichage bien plus rapide.
D'ailleurs, je ne serai pas surpris que son code ait été utilisé à l'époque pour la version CD32.
(en tout cas, c'est toujours dispo sur Aminet)

Le jeu est sorti en 2 version : 1 version en 32 couleurs pour Amiga, compatible toute machine (j'ai l'original), et une version CD32 en 256 couleurs officielle. Celle-ci a été hackée par les pirates de l'époque pour tourner sur A1200 (ce qui n'était pas prévu au départ).