Re: * ATARI ST * TOPIC OFFICIEL

par dlfrsilver Lun 10 Juil 2017 - 11:28

TotOOntHeMooN a écrit:
dlfrsilver a écrit:Y a t'il un problème ?
Un développeur de Capcom a accordé dans une interview (Pix ou autre) que la MD utilise le code de l'arcade et en annecdote que les deux versions ont de ce fait les mêmes bugs ! (d'ailleurs, pourquoi faire autrement ?)

En suite, tu ressources beaucoup de jeux de façon confidentielle pour quelqu'un qui rend des dumps publiques.
J'imagine qu'évidemment qu'il faut te croire sur parole, alors même que tu ne code pas de jeux ?
D'ailleurs, tu te méprends au sujet des usages mémoires. Mais fano a déjà répondu à cela.

Enfin, pour fermer la parenthèse Amiga que tu ne peux t'empécher d'ouvrir, je dirai que cette machine n'a malheureusement pas suffisemment de Chip RAM pour procéder de la même manière qu'un STE.

J'ai lu aussi cet interview. Comme je l'ai dis, ils ont du simplifier la logique de jeu (qui prend une place folle en arcade), et ils ont passé comme je l'ai dis les métadatas en word de l'arcade en byte (la megadrive ne gère les métadatas qu'en byte et non en word).

Oui j'ai ressourcé plus de jeu que je n'ai pu en dire publiquement. J'ai ressourcé par exemple le jeu Last Duel de Capcom. 384ko de code et de data, ça m'a pris un temps considérable tellement le programme est gros (bon en même temps, je l'ai ressourcé sur Amiga, et non avec IDA Pro sur PC).

Pour ressourcer un logiciel, il faut simplement savoir distinguer ce qui est du code de ce qui est de la data. J'ai été formé au ressourçage et désassemblage par un des meilleurs (CFOU!) pour ne pas le nommer.

J'ai ressourcé intégralement le plus gros jeu de l'Amiga dans le but de le traduire en français. Ce qui est plus dur, c'est de faire en sorte que le programme puisse ensuite être modifié une fois ressourcé.

Concernant la VROM de ghouls'n'ghosts, lance le jeu via Callus95, tu verras exactement la quantité de mémoire nécessaire pour que le jeu puisse tourner sur un PC.

Pour Ghouls'n'Ghosts c'est 16mo de ram. la VROM de ce jeu fait 8mo. 8x2 = 16 ; pourquoi ? double buffering :)

Concernant la modification du code l'arcade pour faire tourner GNG sur STe, oui c'est un fait, l'Amiga 500 pourrait faire aussi bien, mais ça impliquerait un balancing entre la charge CPU et la charge Blitter. Il faudrait pour ça un programmeur à temps plein.

La tâche serait bien plus facile en adaptant le code pour qu'il puisse tourner sur un A1200, tranquille.

par fanoplusplus64K Lun 10 Juil 2017 - 13:52

dlfrsilver a écrit:(la megadrive ne gère les métadatas qu'en byte et non en word).

La megadrive ne gère ni metadatas ni metatiles, les metadatas ou metatiles comme tu les appelles c'est une méthode pour compresser la map et ses caracteristiques descriptives, perso j'utilise des "metadatas" 16 bits sur MD mais si ça me chante je peux avoir la taille que je veux, 8,12,24,32 ,64 ou encore 11bits , c'est juste propre au programme et non pas quelque chose de cablé dans la console.
Sur MD si ils ont choisi (peut être) d'encoder les metatiles sur 8bits c'est qu'ils se sont limités à 256 tiles par plan (malgré le fait que les nametables soient codés sur 16 bits sur la MD), et encore pas sur que ça soit les metatiles , ça peut très bien être les descriptifs de collisions et autres.

dlfrsilver a écrit:Pour Ghouls'n'Ghosts c'est 16mo de ram. la VROM de ce jeu fait 8mo. 8x2 = 16 ; pourquoi ? double buffering :)

Non, non et non, apprends à faire la différence entre un rendu à base de tiles (comme la plupart des consoles) avec une VRAM et eventuellement de la ROM dédiée au VDP et un rendu à base de framebuffer (comme la plupart des ordinateurs).Un double buffer , tu doubles le framebuffer, rien à voir avec le stockage des tiles de BG/sprites.

par kawickboy Lun 10 Juil 2017 - 14:24

C'est un jeu MD réalisé quand la machine était jeune, on aurait eu probablement mieux vers 93.

par dlfrsilver Lun 10 Juil 2017 - 14:54

fanoplusplus64K a écrit:
dlfrsilver a écrit:(la megadrive ne gère les métadatas qu'en byte et non en word).
La megadrive ne gère ni metadatas ni metatiles, les metadatas ou metatiles comme tu les appelles c'est une méthode pour compresser la map et ses caracteristiques descriptives, perso j'utilise des "metadatas" 16 bits sur MD mais si ça me chante je peux avoir la taille que je veux, 8,12,24,32 ,64 ou encore 11bits , c'est juste propre au programme et non pas quelque chose de cablé dans la console.
Sur MD si ils ont choisi (peut être) d'encoder les metatiles sur 8bits c'est qu'ils se sont limités à 256 tiles par plan (malgré le fait que les nametables soient codés sur 16 bits sur la MD), et encore pas sur que ça soit les metatiles , ça peut très bien être les descriptifs de collisions et autres.

dlfrsilver a écrit:Pour Ghouls'n'Ghosts c'est 16mo de ram. la VROM de ce jeu fait 8mo. 8x2 = 16 ; pourquoi ? double buffering :)
Non, non et non, apprends à faire la différence entre un rendu à base de tiles (comme la plupart des consoles) avec une VRAM et eventuellement de la ROM dédiée au VDP et un rendu à base de framebuffer (comme la plupart des ordinateurs).Un double buffer , tu doubles le framebuffer, rien à voir avec le stockage des tiles de BG/sprites.

Ah ok, jusqu'ici j'ai principalement vu des metadatas en 8bits sur MD. C'est d'ailleurs un des soucis quand à l'époque ils voulaient convertir un jeu de la MD vers l'Amiga. L'Amiga ne gère pas bien les metadatas en 8 bits. En 16 bits par contre c'est optimal.

Si ils avaient gardé les métadatas de la machine d'arcade, tout en gardant les mêmes assets graphiques, la cartouche n'aurait pas fait 512 kilo-octets, mais au moins 2 ou 3 mo !

Pour l'histoire du double buffer, je ne sais pas pour quelle raison l'émulateur Callus95 requiert autant de mémoire.

Mais je sais que dans le read me de cette émulateur, on voit la taille de mémoire prise :

Final fight requiert 12mo de RAM, Strider, Ghouls'n'Ghosts, 16mo, Carrier Air wing 12mo, Cadillac et Dinosaurs 20mo, etc etc etc.

Je suis au courant que le système CPS1 n'a pas de framebuffer, c'est de l'affichage direct. le 68000 de la machine d'arcade passe la majeure partie de son temps à envoyer des listes de tiles et de sprites en ram dédiée qui déclenchent une fois dedans l'affichage automatique à l'écran via le chipset. Par ailleurs dès que le chipset prend la main pour afficher les graphismes durant la VBL, le 68000 ne reste pas les bras croisés, il exécute pendant ce temps de balayage la logique du jeu.

Quand aux programmes des jeux CPS1, j'ai suffisamment mis mes mains dedans pour savoir de quoi je parle :) J'ai même déprotégé des sets de jeux XD !

par Invité Lun 10 Juil 2017 - 15:13

TotOOntHeMooN a écrit:
dlfrsilver a écrit:Y a t'il un problème ?
Un développeur de Capcom a accordé dans une interview (Pix ou autre) que la MD utilise le code de l'arcade et en annecdote que les deux versions ont de ce fait les mêmes bugs ! (d'ailleurs, pourquoi faire autrement ?)

En suite, tu ressources beaucoup de jeux de façon confidentielle pour quelqu'un qui rend des dumps publiques.
J'imagine qu'évidemment qu'il faut te croire sur parole, alors même que tu ne code pas de jeux ?
D'ailleurs, tu te méprends au sujet des usages mémoires. Mais fano a déjà répondu à cela.

Enfin, pour fermer la parenthèse Amiga que tu ne peux t'empécher d'ouvrir, je dirai que cette machine n'a malheureusement pas suffisemment de Chip RAM pour procéder de la même manière qu'un STE.

En tout cas pour ce qui est des collisions, c'est pas du tout le code de l'arcade .

par **TotOOntHeMooN** Lun 10 Juil 2017 - 15:16

TOUKO a écrit:En tout cas pour ce qui est des collisions, c'est pas du tout le code de l'arcade .

Si la MD avait le même VDP que le CPS1, ça se saurait ! Mr. Green

Il en va de même pour la gestion des contrôles et propablement le son à moindre mesure.

Je pense aussi que si le jeu était sorti un peut plus tard, on aurait eu une meileur conversion.

par dlfrsilver Lun 10 Juil 2017 - 15:18

TotOOntHeMooN a écrit:
TOUKO a écrit:En tout cas pour ce qui est des collisions, c'est pas du tout le code de l'arcade .
Si la MD avait le même VDP que le CPS1, ça se saurait !
Il en va de même pour la gestion des contrôles et propablement le son à moindre mesure.

Je pense aussi que si le jeu était sorti un peut plus tard, on aurait eu une meileur conversion.

anima expliquait qu'il était impossible d'avoir une conversion parfaite sans un 68000 clocké à 12mhz minimum.

par **TotOOntHeMooN** Lun 10 Juil 2017 - 15:26

dlfrsilver a écrit:anima expliquait qu'il était impossible d'avoir une conversion parfaite sans un 68000 clocké à 12mhz minimum.

Sur STE ?

par dlfrsilver Lun 10 Juil 2017 - 15:38

TotOOntHeMooN a écrit:
dlfrsilver a écrit:anima expliquait qu'il était impossible d'avoir une conversion parfaite sans un 68000 clocké à 12mhz minimum.
Sur STE ?

exactement. Une machine à 8mhz ne peut pas avoir une conversion parfaite. Le 68000 passe la majeure partie de son temps à traiter la logique du jeu.

Comme le STE est un ordinateur et pas la machine d'arcade, le 68000 ne va pas assez vite, et donc il y aura de gros ralentissement.

Idéalement, à sa place je dégagerai le 2ème plan et le 3ème si besoin pour soulager le CPU, et garder ce qu'on a vu dans la vidéo.

Le résultat qu'il a obtenu est déjà très intéressant, et la vitesse est tout à fait correcte. J'attends avec impatience l'ajout des musiques et des sons :)

par Invité Lun 10 Juil 2017 - 15:58

Si la MD avait le même VDP que le CPS1, ça se saurait !

Ce que je veux dire c'est que les box de collisions de la version MD ne sont pas les mêmes que l'arcade .
Donc ça me parait étrange que SEGA ait utilisé le code de l'arcade, mais pas pour les collisions .
Alors que sur SGX les collisions sont identiques à l'arcade .

par **TotOOntHeMooN** Lun 10 Juil 2017 - 17:12

Ce que je veux dire, c'est qu'ils ont du recoder les parties dont le hardware n'est pas identique.
Après, ça a certainement été fait de "visu" sur MD, puis corrigé sur SGX car le problème était connu.

par **TotOOntHeMooN** Lun 10 Juil 2017 - 17:16

dlfrsilver a écrit:exactement. Une machine à 8mhz ne peut pas avoir une conversion parfaite. Le 68000 passe la majeure partie de son temps à traiter la logique du jeu.

Ca ne veut rien dire... Le code 68000 en arcade ne prends pas forcément 100% du temps CPU.
De plus, rien empèche d'optimiser l'existant dans son projet. Mais oui, déjà avec 1 plan c'est très bien.

par cryodav76 Lun 10 Juil 2017 - 18:16

il pourrait faire la meme chose avec strider?

par **TotOOntHeMooN** Lun 10 Juil 2017 - 18:30

S'il a bien fait les choses, il peut porter les autres jeux CPS, une fois qu'il a son moteur qui va bien.

par **Zarnal** Lun 10 Juil 2017 - 18:42

Et je crains que cela ne reste que du coté atari. MDR

Mais bon cela fait toujours plaisir que des personnes se " cassent le cul " et après tout peu importe la machine. What a Face

par **TotOOntHeMooN** Lun 10 Juil 2017 - 18:45

Oui... Et j'espère sincèrement qu'il a prévu d'y intégrer la bande son MIDI du X68000.
Après tout, on est sur ST hein !!! Cool

par fanoplusplus64K Lun 10 Juil 2017 - 19:40

TOUKO a écrit:En tout cas pour ce qui est des collisions, c'est pas du tout le code de l'arcade .

Est ce que le CPS gère les collisions en hard ? si c'est le case,c'est peut être une des causes, une reprogrammation des collisions douteuse ou alors est ce qu'il y a pas eu une couille dans le potage dans les ratio de coordonnées en passant du 384 au 320 pixels.

par **Zarnal** Lun 10 Juil 2017 - 19:56

TotOOntHeMooN a écrit:Oui... Et j'espère sincèrement qu'il a prévu d'y intégrer la bande son MIDI du X68000.
Après tout, on est sur ST hein !!!

* ATARI ST * TOPIC OFFICIEL - Page 11 598556

par Invité Lun 10 Juil 2017 - 20:48

fanoplusplus64K a écrit:
TOUKO a écrit:En tout cas pour ce qui est des collisions, c'est pas du tout le code de l'arcade .
Est ce que le CPS gère les collisions en hard ? si c'est le case,c'est peut être une des causes, une reprogrammation des collisions douteuse ou alors est ce qu'il y a pas eu une couille dans le potage dans les ratio de coordonnées en passant du 384 au 320 pixels.

Non je pense que les collisions sont en soft .
Après bien sur un bug comme ça est tout à fait possible, mais bon je pense que SEGA se serait rendu compte que la difficulté était plus corsée que l'arcade lors des betas tests .

par **TotOOntHeMooN** Lun 10 Juil 2017 - 21:22

Mais c'était pas les joueurs qui betatestaient ? Mr. Green

par fanoplusplus64K Lun 10 Juil 2017 - 21:29

C'était le concept en vogue chez SEGA, c'était le client qui était betatesteur , c'étaient des visionnaires ! MDR

par dlfrsilver Lun 10 Juil 2017 - 22:57

fanoplusplus64K a écrit:
TOUKO a écrit:En tout cas pour ce qui est des collisions, c'est pas du tout le code de l'arcade .
Est ce que le CPS gère les collisions en hard ? si c'est le case,c'est peut être une des causes, une reprogrammation des collisions douteuse ou alors est ce qu'il y a pas eu une couille dans le potage dans les ratio de coordonnées en passant du 384 au 320 pixels.

J'ai la réponse à ta question : tout les jeux CPS gèrent les collisions en soft via le 68000.

par dlfrsilver Lun 10 Juil 2017 - 22:59

cryodav76 a écrit:il pourrait faire la meme chose avec strider?

N'importe quel jeu CPS1. Ces jeux ont la même base, le même socle. Tout les programmes de cette plateforme se ressemblent point de vue du code.

Donc c'est clair, moi Strider CPS1, je le dis même si ça choque, s'il le porte, même sur STE, je vais pas débander pendant une semaine tellement ça va être le pied !

par dlfrsilver Lun 10 Juil 2017 - 23:04

TotOOntHeMooN a écrit:Oui... Et j'espère sincèrement qu'il a prévu d'y intégrer la bande son MIDI du X68000.
Après tout, on est sur ST hein !!!

Oh là ! On se calme papy, on est sur STe, hein, pas sur Amiga ou sur la machine d'arcade lol.

Le YM2151 du CPS1 utilise plus de voix qu'un STe n'en aura jamais. Il faudra donc recomposer la musique au format YM :)

par **TotOOntHeMooN** Lun 10 Juil 2017 - 23:37

dlfrsilver a écrit:Oh là ! On se calme papy, on est sur STe, hein, pas sur Amiga ou sur la machine d'arcade lol.

Le YM2151 du CPS1 utilise plus de voix qu'un STe n'en aura jamais. Il faudra donc recomposer la musique au format YM :)

T'as un soucis de compréhension ? lol!

par dlfrsilver Lun 10 Juil 2017 - 23:42

TotOOntHeMooN a écrit:
dlfrsilver a écrit:Oh là ! On se calme papy, on est sur STe, hein, pas sur Amiga ou sur la machine d'arcade lol.

Le YM2151 du CPS1 utilise plus de voix qu'un STe n'en aura jamais. Il faudra donc recomposer la musique au format YM :)
T'as un soucis de compréhension ?

Non et toi ? lol!

par **TotOOntHeMooN** Mar 11 Juil 2017 - 0:35

Moi ça va bien, je suis concient que le ST a un port MIDI, tout comme le X68000 et qu'il peut donc jouer les mêmes musiques par ce biais... LA grande classe ! Rien à voir avec ton petit Amiga ou l'arcade. Toi, tu me prends pour un crétin en pensant que je parle du son FM du YM2151, et qu'il faudrait se prendre la tête pour rien à recomposer en PSG... Sauf que t'es juste à la ramasse. Allez, un supo et au lit mon petit ! Mr. Green

par Invité Mar 11 Juil 2017 - 2:08

ca doit etre fort pratique d'avoir à brancher un synthé externe en midi pour avoir du son.

"-tiens, tu t'es remis au synthé rené ? "
"-non non, je vais juste faire une partie de ghouls & ghosts, t'as pas un cable midi steuplait?" * ATARI ST * TOPIC OFFICIEL - Page 11 418468

* ATARI ST * TOPIC OFFICIEL - Page 11 418468

par **TotOOntHeMooN** Mar 11 Juil 2017 - 8:49

Il y a même plus pratique qu'un synthé (moins encombrant) ... Utiliser un sound canvas.
Tu branches le boitier sur la sortie MIDI et audio du ST, et il te mixe le tout en direction des enceintes.

Au final, avec GNG tu pourrais avoir les SFx de jouées par le STE et la musique originale en MIDI.
Ce qui sonnerait bien mieux et prendrait moins de temps CPU, à garder pour le jeu en lui même.
J'en ai touché deux mots au développeur du jeu, au cas où il soit passé à coté, comme notre cher amis...

Par exemple sur le Roland SC-55 que j'utilise (50 balles sur le bon coin) :
https://www.youtube.com/watch?v=-Dw4qx3xXOM

par Invité Mar 11 Juil 2017 - 9:11

TotOOntHeMooN a écrit:Mais c'était pas les joueurs qui betatestaient ?

Tout s'explique alors Wink

par dlfrsilver Mar 11 Juil 2017 - 9:51

TotOOntHeMooN a écrit:Moi ça va bien, je suis concient que le ST a un port MIDI, tout comme le X68000 et qu'il peut donc jouer les mêmes musiques par ce biais... LA grande classe ! Rien à voir avec ton petit Amiga ou l'arcade. Toi, tu me prends pour un crétin en pensant que je parle du son FM du YM2151, et qu'il faudrait se prendre la tête pour rien à recomposer en PSG... Sauf que t'es juste à la ramasse. Allez, un supo et au lit mon petit !

Oui sauf que Ghouls 'n' Ghosts sur X68000 les musiques sont jouées via l'YM 2151 et pas le port midi, ce qui confirme que tu es bien un crétin Mr. Green

!

Comme les musiques de GNG n'existent pas au format midi, et comme tu peux te brosser, il faudra effectivement trouver un mec pour convertir les musiques si anima souhaitait utiliser celles de la version X68000.

PS : crétin bis : Les conversions CPS1 sur X68000 sont toutes encryptées y compris l'executable de lancement du jeu.

PS : crétin bis 2 : le midi n'est pas un format musical, c'est un protocole de transmission de données. Et non, j'ai pas envie de m'acheter un clavier bontempi dédié à l'atari STe simplement pour jouer les musiques du jeu.

des fichiers YM feront bien l'affaire.

C'est ballot :)

Tu as des soucis de compréhension ?