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

[Invité]

Attention, c'est chaud tentative de portage de Xevious (premier shoot'em vertical) sur... Amiga 1200 




"I'm focusing on an AGA port which should run on bare A1200"


Le truc qui tourne sur Atari 7800 et Nes...

Le 1200 c'est pour des raisons de simplicité technique, sur un jeu de 82 tu forces pas pour refaire le jeu vu que tu n'as aucunes contraintes .
D'après l'auteur, c'est plus de l'émulation qu'un portage, d'où aussi le choix du 1200, ça reste sympa même si c'est regrètable .

ça m'a toujours fait pitié les mecs qui aiment rabaisser un codeur parce qu'il ne maitrise pas tel ou tel langage... je peux encore comprendre quand ce sont des ados de 15 ans qui friment...mais à quasi 50 ans, faut commencer à se remettre en question

En même temps c'est ce que fait le doc sans arrêt dès qu'il poste sur un jeu amiga en cours de dev, mais bon on va pas vous demander non plus d'être impartiaux .

[youki]

oui, c'est bien connu ca, les codeurs Amiga ne font jamais de gros effort...  on l'a bien vu...

[Invité]

oui, c'est bien connu ca, les codeurs Amiga ne font jamais de gros effort...  on l'a bien vu...

Donc aucun intérêt de porter la version ST non plus qui serait toute nase,car il y a matière à faire largement mieux sur A500 .

[Copper]

oui, c'est bien connu ca, les codeurs Amiga ne font jamais de gros effort...  on l'a bien vu...

Convertir le code Z80 en 68000 ca nécessite plus d'effort en fait...

[rocky007]

mais bon on va pas vous demander non plus d'être impartiaux .

ben oui ce serait un comble vu l'attitude de l'autre camp

[Invité]

Tu sais paille ,poutre tout ça quoi,et bon nous faire la morale alors que le doc crache sur les devs amiga 2 posts plus haut, c'est fort qd même .

[youki]

oui, c'est bien connu ca, les codeurs Amiga ne font jamais de gros effort...  on l'a bien vu...

Convertir le code Z80 en 68000 ca nécessite plus d'effort en fait...

tu parles, ca s'automatise facilement.

[Invité]

Enfin tu vas pas coder un convertisseur juste pour un jeu, à moins qu'ils aient (car oui le codeur principal ce n'est pas celui de la version amiga,mais NG) prévu d'autres conversions de jeux tournant sur Z80 .

[Copper]

Après au vu du blog ça reste quand même pas mal d'efforts...

[Invité]

Franchement je trouve que c'est bcp d'effort de convertir les merdes de la version arcade en transposant le code, par rapport à refaire le jeu de 0 .
Surtout que vu l'année du jeu, le GP ne doit pas être compliqué à assimiler .

[Zarnal]

Je ne sais pas trop, je trouve qu'il n'y a aucune ambition quant à l'Amiga. Pourquoi ne pas s'attaquer à un jeu du genre Forgotten Worlds ou bien refaire un R-Type par exemple ( dans les limites de la machine, on ne fera pas de grands miracles non plus ) plutôt que de s'attaquer à de si vieux trucs ayant pour la plupart mal vieillis.

On a pourtant eu un super truc avec T2 AGA. 

Après, une architecture arcade, malgré les apparences, cela peut être très compliquée à gérer.

[rocky007]

Surtout des jeux bof.. déjà en 1987 personne ne jouait à Xevious ...

[youki]

Xevious , c'est un hommage au GEM de l'ATARI , c'est le jeu préféré de copper.

C'est pour ca qu'ils le portent sur Amiga... ils ont un peu l'impression d'avoir un ST.

[Copper]

Ça reste intéressant techniquement parlant à porter fidèlement (ou à émuler)

[Jacques Atari]

L'Amiga a déjà du mal avec Scramble, alors Xevious... Les (rares) codeurs sur cette poubelle feraient mieux de se concentrer sur une version A500 de Bad Apple...

[Invité]

Je ne sais pas trop, je trouve qu'il n'y a aucune ambition quant à l'Amiga. Pourquoi ne pas s'attaquer à un jeu du genre Forgotten Worlds ou bien refaire un R-Type par exemple ( dans les limites de la machine, on ne fera pas de grands miracles non plus ) plutôt que de s'attaquer à de si vieux trucs ayant pour la plupart mal vieillis.

On a pourtant eu un super truc avec T2 AGA. 

Après, une architecture arcade, malgré les apparences, cela peut être très compliquée à gérer.

Parce qu'aujourd'hui les gens ne veulent pas se coltiner de la doc technique et coder en ASM, il veulent comme le doc, du tout cuit, avoir juste le minimum syndical en terme de code, et aucune contraintes, donc ils codent sur des machines largement plus puissantes que la cible pour être sur de ne pas avoir à faire trop d'efforts .

Après, une architecture arcade, malgré les apparences, cela peut être très compliquée à gérer.

Pour xevious, il n'y a rien de spécialement compliqué pour un A500, des jeux bien plus impressionnants ont été fait dessus .
T'as qu'à voir tinyus sorti en 2021 .


Prenons la MD par exemple, la scène produit pas mal de jeux parce qu'il y a un devkit en C, sinon il y a peut être 2/3 personnes qui codent en ASM dessus,et grâce au fait que la taille des ROMS ne soit plus un problème, ils peuvent coder comme des gorets et avoir des ROMS de 4Mo pour y faire rentrer un jeu qui aurait pu tenir sur 1 .

[rocky007]

Tinyus ? c'est pas une MST ça ?  j'ai déjà entendu Copper en parler

[Copper]

Pour xevious, il n'y a rien de spécialement compliqué pour un A500, des jeux bien plus impressionnants ont été fait dessus .

La borne utilise une palette de 128 couleurs et affiche 64 sprites (taille 8x8 à 16x16 / 8 couleurs dont une transparente) ce qui n'est pas si simple pour un Amiga 500

C'est déjà plus facile en AGA vu que l'on peut avoir les 128 couleurs et même avoir une bitplane de libre pour le layer des scores (ce layer nécessite par ailleurs plusieurs couleurs mais on peut sans doute tricher avec une Copperlist)

Après de toute façon pour gérer une résolution de 224x288 dans le sens normal (la borne elle doit avoir un écran retourné de 90°) cela pose déjà un souci vu qu'à priori il manquerait quelques lignes (WinUAE semble limité à 224x284 par défaut en plus en PAL on a plus la vitesse de rafraîchissement de 60 Hz non plus)

Après sans surprise cette version MSX 2 à l'air bien mieux que la version STF :

[tapomag]

Pas mal le Xevious MSX2. Ça me fait penser à Zanac, auquel j'ai beaucoup joué sur MSX tout court.

[Invité]

La borne utilise une palette de 128 couleurs 

Je me trompe peut être, je suis pas allé jusqu'à vérifier, mais j'ai pas l'impression que les tiles du décors utilisent plus de 16 couleurs, et pour les sprites pareil .
La borne peut probablement afficher jusqu'à 128 couleurs, mais je doute que xevious en affiche autant en même temps .
Tu me donnes les caractéristiques de la borne, et pas ce que le jeu utilise, car j'ai pas souvenir que le jeu affiche bcp de sprites à l'écran .

EDIT: j'ai récup tout le tileset (tilemap+sprites) et on est à 52 couleurs au total, dont 23 pour la map, donc rien de foufou et d'infaisable sur de l'OCS donc.

[Copper]

52 couleurs c'est toujours plus que le mode 32 couleurs... Le mode half-brite n'étant pas forcément judicieux à utiliser ici ni le HAM6 (même si ca serait sympa mais pas assez de sprites coté OCS)

Avec les lookup table c'est pas forcément évident de savoir qu'elle couleurs sont utilisées de prime abord ni combien de sprites sont utilisés dans le pire des cas non plus...

[iktos]

parfait pour conversion sur Atari Jaguar tout ça :)

[Invité]

52 couleurs c'est toujours plus que le mode 32 couleurs... Le mode half-brite n'étant pas forcément judicieux à utiliser ici ni le HAM6 (même si ca serait sympa mais pas assez de sprites coté OCS)

C'est pas 52 couleurs à l'écran, mais 52 au total, donc des changements de palettes lors des changement de sprites est toujours possible,pareil pour la tilemap .
Après faut voir si toutes les couleurs sont justifiée(souvent en arcade tu as bcp de couleurs trop proches pour faire la dif à l'oeil nu), et peuvent donc être réduites sans perte .

La version ST même avec seulement 16 couleurs rend déjà pas trop mal .

(même si ca serait sympa mais pas assez de sprites coté OCS)

Je dirai qu'un hybris ou un BSQ affichent au moins autant de sprites à l'écran que xevious .

Avec les lookup table c'est pas forcément évident de savoir qu'elle couleurs sont utilisées de prime abord ni combien de sprites sont utilisés dans le pire des cas non plus...

Pas besoin, du moins pour le tilemap, les sprites je pense pas non plus vu que tu n'as jamais tous les sprites à l'écran en même temps, donc je pense que ça tient dans 16 couleurs, même si il y a quelques pertes, elles seront pas visibles in game,tu changes la palettes pour chaque vague.
Le fait d'avoir bcp de palettes permet surtout d'eviter de changer de couleurs à la volée .

[Copper]

Tu les sors d'où tes 52 / 23 couleurs ?

[dlfrsilver]

La borne utilise une palette de 128 couleurs 

Je me trompe peut être, je suis pas allé jusqu'à vérifier, mais j'ai pas l'impression que les tiles du décors utilisent plus de 16 couleurs, et pour les sprites pareil .
La borne peut probablement afficher jusqu'à 128 couleurs, mais je doute que xevious en affiche autant en même temps .
Tu me donnes les caractéristiques de la borne, et pas ce que le jeu utilise, car j'ai pas souvenir que le jeu affiche bcp de sprites à l'écran .

EDIT: j'ai récup tout le tileset (tilemap+sprites) et on est à 52 couleurs au total, dont 23 pour la map, donc rien de foufou et d'infaisable sur de l'OCS donc.

C'est malheureusement pas une blague, l'arcade utilise un bon paquet de couleurs. Regarde l'horrible version Atari ST du jeu, là il essaie de sortir une version classieuse (pour un jeu qui, je l'avoue est franchement pas intéressant, mais ça n'engage que moi).

[dlfrsilver]

Le GFA sur ST est bien mieux et bien plus rapide que l'Assembleur sur Amiga.

Aussi vrai que le fait de dire que le ST est capable d'afficher un soft en 64 couleurs en 50 images secondes avec 10 sprites par ligne. Mort de rire 

[dlfrsilver]

Copper démarre assez fort 2023, il devient presque aussi bête que silver...

Mais il reste toujours plus intelligent que Monsieur Atari 

[Copper]

Tu parles d'un compliment être plus intelligent que Monsieur Atari

Pour le reste, concernant Xevious, connaitre la ou les lookup table utilisées pour chaque tile dans le jeu permettrait sans doute de simplifier tout ça mais j'ai pas l'impression que c'est la solution qu'ils ont choisi pour le moment

[Zarnal]

La borne utilise une palette de 128 couleurs 

EDIT: j'ai récup tout le tileset (tilemap+sprites) et on est à 52 couleurs au total, dont 23 pour la map, donc rien de foufou et d'infaisable sur de l'OCS donc.

Après, le 500 au dela de 4 bitplans, cela plie rapidement en général ( le copper ne compte pas au niveau des couleurs, c'est du cache misère la plupart du temps mais pas toujours heureusement  ).

On le voit bien avec TinyUs ou bien TinyBubble. Cela peut tousser en OCS. Je ne prétends pas que c'est systématique non plus mais bon...

Après, il reste le 50/25 ou bien le 25/25 mais pour un shoot ( et comme nous ne sommes plus dans les 80 )...

[Jacques Atari]

Copper démarre assez fort 2023, il devient presque aussi bête que silver...

Mais il reste toujours plus intelligent que Monsieur Atari 

Tu parles d'un compliment être plus intelligent que Monsieur Atari

Venant d'un mytho qui court après son frère pour être, lui aussi, reconnu d'un milieu où il est constamment rejeté, et d'un pseudo codeur qui se la pète mais a bien du mal à coder deux carrés qui changent de couleur sur son Amiga, j'apprécie les commentaires. Merci les filles!

[Copper]

Toi c'est sur que tu n'arriverais pas à animer 2 carrés sur ton STF avec son alimentation cramée...

Pour ma part j'ai réussi le 54x54 carrés de 4x4 et ça me suffit amplement pour le moment...