Necstasy

Quelle vidéo ? Tu parles sûrement des Hu7D, plus compact, sortis plus tard.

Voici ce que j'ai trouvé en Hu7CD (éventuellement créer un topic dédié) : Hu7 + IFU-30






A noter la voisine Super Famicom




Intéressant la mention Hu-PC98





Le Hu7D en format tour, j'en sais pas beaucoup là-dessus, je pencherai pour un module d'inscription sur bande magnétique, pour faire le master avant pressage, mais c'est hypothétique, je vais me renseigner.

Oui ça vaudrait peut être le coup de déplacer un bout de la discussion dans le topic développement.

Ooops pardon : https://www.youtube.com/watch?v=YDgEMeubib4

Merci Thibaut pour ces images! Je n'avais jamais vu ce type de kit, je pensais que c'était une tour! Ça fait vraiment artisanal!

Concernant cette tour, ça serait sympa d'en savoir plus sur elle.

Alors à priori, à l'époque (1987) il n'y avait pas de CD-R, ils passaient donc par la "tour" Hu7CD pour inscrire le jeu sur bande magnétique via le PC98. Le système de développement est bien un Hu7 couplé avec un IFU-30.

L'inscription sur CD-R serait apparu en 92 avec Tengai 2 Maru, mais le taux d'erreurs restait important.

C'est vraiment à partir de 1994 que les CD-R sont devenus fiable.

Qq infos ici :
http://www.highriskrevolution.com/gamel ... x.php?e=76

Mike Daily en train de jouer à SOTB sur ce qui ressemble être un kit de dev (non?)
https://www.youtube.com/watch?v=f14k2j9 ... tu.be&t=61

Merci pour le lien.

Oui en effet il s'agit de la version US.

Peperocket : tu l'as eu ?

De ce que je comprends de l'article, le Hu-7CD est une tour de disques durs. Les HDDs commerciaux de l'époque ne dépassaient pas 40 Mo et étaient volumineux. Les HDDs industriels comme celui présent dans le Hu-7 grimpaient à 600 Mo, mais sous quelle forme ? Je ne serais pas étonné qu'il s'agissait d'un rack de plusieurs disques, d'où la taille de la tour.

Le master était ensuite transféré sur une DAT ou une cassette vidéo 8 mm ; des supports qui pouvaient contenir jusqu'à 1 Go mais étaient extrêmement lents et n'étaient donc utilisés que pour la duplication.

J'aurais jamais cru que les données de jeux eussent été stockées dans des DAT !

Le mec était motivé 4000€! Plus cher qu’un kit snes!

En même temps on en voit tellement peu ...

Merci Kaminari pour cet éclaircissement! Moi qui pensait que c’était un kit!

1 giga-octet et pas 1 tera...

J'ai édité mon message

shubibiman a écrit : ↑lun. 13 nov. 2017 21:07 J'aurais jamais cru que les données de jeux eussent été stockées dans des DAT !

La bande magnétique, y'a que ça de vrai !
Et pour l'audio professionnel le DAT a survécu jusqu'au début des années 2000. Après les cartes mémoires flash ont tout balayé (du moins pour les équipements d'enregistrement nomades).

Autant je savais que c'était beaucoup utilisé dans le milieu de la musique, autant je ne savais pas pour les données informatiques.

Les sauvegardes informatiques idem (DLT ...).

Au boulot, on sauvegardait les données des serveurs sur bande magnétique jusqu'en 2010

J'ai une question :
Est-ce que c'est possible que des codes soient directement transférables et fonctionnels de console à une console différente ?
Par exemple on sait qu'on peut faire tourner un jeu NES sur PC Engine, on l'a vu avec les ports de Megaman, Castlevania... Pourrait-on imaginer prendre le code d'un jeu NES et l'upgrader pour la PC Engine ?
Idem de la PC Engine à la SFC : j'ai lu que le system Hu-7 pouvait être compatible avec le kit de dev de la SFC. Pour être précis c'est le témoignage d'un développeur de chez Human qui disait qu'ils avaient directement repris les assets graphiques de l'arène de catch de Fire Pro Wrestling pour les épisodes SFC, est-ce techniquement avéré ? Si c'est possible pour des graphismes, est-ce aussi possible pour les mouvements de sprites ou seulement pour des graphismes ou du son ?
Désolé si j'ai pas le bon vocabulaire technique, je ne suis pas spécialiste du codage... J'espère que vous voyez ce que je veux dire.

Il faut faire la distinction entre l'algorithmique de base aussi appelée "game logic" (si obstacle = mortel, alors game = over) qui est facilement transposable à n'importe quelle architecture, et la programmation spécifique à chaque machine (les Apple II, Atari XL, C64, NES, SNES, PCE et d'autres partagent les mêmes instructions CPU 6502, mais n'ont rien à voir au niveau graphique, sonore et organisation de la RAM). Il faut aussi prendre en compte les différences de vitesse. La PCE tourne à 7.2 MHz quand la SNES plafonne à 3.6 MHz et la NES à 1.8 MHz, ce qui fait qu'un programme optimisé pour la PCE peut être poussif sur une SNES. Il faudrait donc dans ce cas réécrire la "game logic" elle-même !

Un jeu NES ne peut pas tourner tel quel sur PCE. Les instructions CPU de base sont compatibles, mais toute la partie graphique et sonore doit être réadaptée au hardware de la PCE. Tomaitheous (TurboXray) a ainsi dû développer un code spécifique pour chaque jeu NES qu'il a voulu supporter, notamment pour l'audio. On ne parle plus de portage mais d'une émulation partielle !

Reprendre les assets graphiques d'une machine à l'autre est relativement trivial. Toutes les consoles et bornes d'arcade 16 bits de l'époque fonctionnent sur le même principe : 1 palette par objet (sprite ou tuile), et 16 couleurs par palette. En revanche, le nombre maximum de palettes peut faire une énorme différence — seulement 4 palettes pour la MD contre 32 pour la PCE et 200 pour le CPS ! Sans parler du nombre de couleurs sélectionnables (512 teintes pour la PCE, 32768 pour la SNES). Il y a donc nécessairement un gros travail d'adaptation graphique à opérer si on ne veut pas se contenter d'un portage en 16 couleurs sur chaque machine ciblée.

L'adaptation du code dépendra surtout du langage utilisé. Il est à mon avis plus facile de convertir un programme écrit en C (par exemple entre le kit SGDK de la MD et le kit HuCC de la PCE) que de convertir un programme écrit en assembleur, même entre deux machines à base de 6502. Quand on voit un jeu comme Street Fighter 2, porté sur SNES et PCE par les mêmes développeurs d'Alfa System, on imagine qu'il doit y avoir du code commun entre les deux versions, notamment sur la "game logic". Mais la partie programmation hardware a dû être clairement spécifique. Les capacités (ou non) en matière de parallaxe, par exemple, dictent la manière dont les décors vont être redessinés pour chaque machine. Les capacités en matière de sprites impliquent également des choix différents : la SFC ne peut manipuler que des sprites de 8x8 ou 16x16 pixels, tandis que la PCE gère facilement des sprites jusqu'à 32x64 pixels (mais avec une taille minimum de 16x16). Des persos comme Zangief ne sont donc pas graphiquement "fabriqués" de la même façon sur les deux machines.