Développer sur PC Engine en 2026 ?

[touko]

La différence c'est que tu peux accéder aux 512 ko n'importe quand et ça change pas mal de choses,là on est limité à 256ko,pour les GFX (même si certains peuvent être mis en VRAM directement depuis le CD), les sfx et le code .
De plus avec 64ko de RAM de la MD tu peux décompresser des données plus facilement en RAM .
Sans parler que sur PCE tu peux pas gagner de la place grâce au flip X/Y des tiles,et aux sprites 8x8 .

EDIT: A titre infos, la ROM sms fait 512ko .

[Kaminari]

Donnes moi le nom d'un titre SCD proche d'un golden axe en matière de ressources graphiques !!

Tu as relancé Golden Axe dernièrement sous Mame ? Les planches d'anim font peut-être du zèle, mais quand tu vois le résultat en pratique, c'est quand même pas de la motion capture ni même la folie niveau sprites en général

Je ne peux pas te citer de titre SCD équivalent à Golden Axe, vu qu'on a une pénurie bien connue de beat them all sur PCE
Mais dans des genres différents (notamment les shoots), il y a des tonnes de jeux sur SCD qui ne sont pas avares en matière de claque graphique, taille de sprites, nombre de sprites et planches d'animation. Et puis au passage, Golden Axe de Telenet n'utile pas 256 Ko mais seulement 64 Ko (CD oblige). Je maintiens qu'il y avait de la marge pour faire une adaptation plus efficace, mais il aurait fallu un studio à la hauteur.

Je comprends cependant tes réserves sur la limite de RAM des lecteurs optiques par rapport au potentiel des jeux cartouche. Le plus gros mapper existant (MC Genjin) supporte 8 Mo, de quoi tacler l'Arcade Card. Dommage qu'il n'ait jamais été exploité par les devs homebrew, alors qu'il est open source.

[touko]

Je comprends cependant tes réserves sur la limite de RAM des lecteurs optiques par rapport au potentiel des jeux cartouche. Le plus gros mapper existant (MC Genjin) supporte 8 Mo, de quoi tacler l'Arcade Card. Dommage qu'il n'ait jamais été exploité par les devs homebrew, alors qu'il est open source.

Tout à fait, ce que je veux bien sur dire, c'est pas qu'on peut pas faire des jeux qui envoient sur scd, les exemples ne manquent pas, mais par contre certains types ne s'y prête clairement pas avec seulement 256ko, comme les VS, ou les BTU,sauf à faire de grosses concessions pour rester dans les clous .
Après certains manque techniques de GA sont pour moi injustifiés, comme le nb d sprites à l'écran, les sons, etc ..

[pnauts]

Qui s'y colle pour un remaster ?

[Kaminari]

Haha

Touko, tu n'aurais pas gardé une trace de ces screenshots refaits sur pcenginefx ? J'avais moi-même commencé à convertir quelques écrans arcade sur PCE l'année dernière, ça m'intéresserait de comparer leurs choix de palette avec les miens.

[touko]

Et non hélas,mais putain qu'ils étaient beaux !!

[lunoka]

Et voilà, j'ai envie de m'y mettre aussi ...

[kawickboy]

[Sujet issu de la discussion sur Another World.]

Et sinon c'est agréable de porter un jeu sur PCE ? A une époque où aidé par un SGDK de folie la megadrive profite de développements de plus en plus dingues, la PCE est un peu délaissée ce serait sympa d'avoir un retour d'expérience.

[lunoka]

Pour ma part, j'ai commencé avec SGDK l'année dernière avec un tetris que j'avais codé sur GP2X il y a quelques années. ça s'est très bien passé. La force de SGDK, c'est d'avoir proposé du langage C pour coder, l'assembleur est long à apprendre et rebute souvent les développeurs quand ils n'ont pas appris à en faire avant.

En fait, je pense que SGDK a énormément bénéficié de l'effet réseaux sociaux + Youtube. Contrairement au Kit HuC pour PCE qui existe depuis des lustres en version 3.21 et permet aussi de coder en C.

J'ai pu porter ma démo de SGDK vers HuC en quelques semaines, mais cela a été beaucoup plus difficile. Très peu de tutos, des sites à moitié crevés, plusieurs forks de HuC sur github, ça aide pas. Ensuite, officiellement on a pas de moteur de son pour un format cartouche dans HuC. Il faut passer par un format CD.

Plusieurs moteurs son sont en cours pour hucard ( Mooz bosse sur l'un d'eux ) mais à l'heure actuelle, rien de final n'est intégré à HuC. Il faut savoir que Elmer qui maintient actuellement HuC est pro CD, il ne voit pas l'intérêt d'ajouter un moteur son compatible hucard. Je pense que c'est une grosse erreur et que ça rebute énormément les développeurs qui voudraient s'y essayer.

Des nordiques ont réalisé une démo PCE il y a pas longtemps, avec du son en se basant sur du format Amiga/Atari ( format Mod ). Il me semble que ça serait une bonne option pour Another World mais je ne sais pas quand ils vont releaser ce moteur non plus.

Il y a un moteur qui est opérationnel en third party depuis des années ( pompé en retro ingénieurie il me semble, depuis une system card ) mais le format de musique est du MML. Un truc à la con quasi inconnu par les musiciens occidentaux, donc très dur de trouver des gens capables de produire des musiques, sans compter l'aspect pas très légal de réutiliser du code de l'époque ( de Konami je crois ).

L'apparition des trackers Deflemask & Furnace étaient vraiment un truc qui manquait pour faire de la musique. Mais maintenant, il faut arriver à faire le player, et réussir à l'inclure dans HuC, si Elmer veut bien le faire.

Il faudrait vraiment que HuC soit complet je pense pour inciter des gens à faire des choses de manière plus facile su PCE, c'est ce que je retiens de mon année 2022 passée à découvrir les kits C des consoles rétro.

J'ajoute qu'il ne faut pas oublier le rapport 1 pour 4 entre les pc engines et les megadrives en nombre de vente, et le fait que n'importe qui peut se faire faire des cartouches customs Megadrive sur Alie Express, c'est plus compliqué avec les hucards. Je ne connais que le gars de chez Retro Blaster qui vient de sortir son format hucard, et je ne sais pas comment fait Tobias pour faire ses clones ( il y a aussi le problème de l'étui à hucard, on commence à trouver des modèles 3D à faire imprimer, mais pour de l'injection ça douille, et rien en vu chez Alie Express concernant du matos relatif aux hucards, à part les pochons plastiques ).

[shubibiman]

Ça c’est du retour détaillé

[Kaminari]

La situation que tu décris n'a malheureusement pas changé depuis 20 ans, depuis que David Michel avait filé les clés de Magic Kit à Zeograd pour développer son front-end C, soit disant le Graal pour accélérer le développement sur PCE (miracle qui ne s'est jamais produit). L'argument selon lequel le C était plus cool et facile que l'ASM était simplement ridicule. Elmer n'étant pas plus intéressé par l'assembleur que Zeograd en son temps, tous les docs et tutoriaux originaux sont partis à la poubelle. Les néophytes qui se lancent dans HuC n'ont rien à se mettre sous la dent. HuC est une coquille vide qui ne sert de mon point de vue à rien.

Ca n'est pourtant pas une fatalité. Quand tu vois la scène homebrew Spectrum (qui défonce toutes les autres) et les outils dont ils disposent, on comprend simplement que la PCE est une machine obscure qui n'attire ni joueurs ni développeurs. Les outils ne peuvent venir que de notre communauté, et on sait bien que les développeurs d'outils PCE ne courent pas les rues.

[Artial]

alors pour Another World c'est simple, je n'utilise pas HuC je code uniquement en assembleur avec ca65. Et hormis avoir porté Micromages de la nes à la PCE je n'ai jamais fait d'assembleur avant.
Pour le son le jeu n'utilise que des samples PCM y compris pour la seule musique (intro), donc normalement pas besoin de moteur son.

[David Shadoff]

Hmmm.
Il y a quelques déclarations ici qui devraient être clarifiées.

Tout d'abord, David Michel était la personne à l'origine de HuC, car personne à part Zeograd, moi et lui-même ne semblions intéressés par l'assembleur. HuC a été placé sur zeograd.com parce que David a arrêté le développement actif peu de temps après sa création, mais Zeograd et moi avons continué à faire évoluer les bibliothèques et le code d'exemple. Le code d'exemple était entièrement sur zeograd.com, mais il semble que - à un moment donné - il y ait eu des gens qui ont téléchargé le compilateur et n'ont jamais regardé les exemples... et ont créé une communauté qui a été séparée du code d'exemple.

Plusieurs moteurs son sont en cours pour hucard ( Mooz bosse sur l'un d'eux ) mais à l'heure actuelle, rien de final n'est intégré à HuC. Il faut savoir que Elmer qui maintient actuellement HuC est pro CD, il ne voit pas l'intérêt d'ajouter un moteur son compatible hucard. Je pense que c'est une grosse erreur et que ça rebute énormément les développeurs qui voudraient s'y essayer.

C'est à moitié vrai.
Il y a plusieurs moteurs sonores en cours de construction, c'est vrai. Cependant, ils utilisent tous un bytecode différent et différents outils pour créer le bytecode. C'est ce qui provoque des disputes entre les développeurs. La plupart des gens rejettent le système basé sur MML du passé et veulent d'énormes flux d'octets qui ne s'intègrent pas bien dans une ROM. C'est pourquoi Elmer suggère que la musique sur CD est meilleure. Tant que votre jeu ne tient pas sur une ROM, vous devez quand même utiliser un CDROM. Les systèmes de code d'octet basés sur MML (il y en a plusieurs) ont été utilisés dans les jeux HuCard et aussi la carte système, il semble donc que des outils soient nécessaires, plutôt que de nouveaux moteurs.

L'argument selon lequel le C était plus cool et facile que l'ASM était simplement ridicule. Elmer n'étant pas plus intéressé par l'assembleur que Zeograd en son temps, tous les docs et tutoriaux originaux sont partis à la poubelle. Les néophytes qui se lancent dans HuC n'ont rien à se mettre sous la dent. HuC est une coquille vide qui ne sert de mon point de vue à rien.

Je n'ai jamais pensé que HuC était plus cool que l'assembleur ; Zeograd, David Michel ou Elmer (les personnes qui ont le plus travaillé sur HuC au fil des ans) non plus. Nous préférerions tous que les gens développent en assembleur... mais peu de gens sont d'accord avec cela. Nous savons tous que HuC produit un code volumineux et lent et qu'il ne peut pas être comparé à l'assembleur.

HuC a été conçu pour être populaire ; David Michel et moi-même pensions que cela encouragerait les gens à apprendre l'assembleur, tout comme nous étions passés du BASIC à l'assembleur dans nos propres passés. (Mais ces jours étaient révolus depuis longtemps, je suppose)

[touko]

Ouh plein de jolis posts ici

on comprend simplement que la PCE est une machine obscure qui n'attire ni joueurs ni développeurs. Les outils ne peuvent venir que de notre communauté, et on sait bien que les développeurs d'outils PCE ne courent pas les rues.

A mon avis c'est bien ça le problème, console obscure et sans réel affect de la part des gens car "peu diffusée" .
D'ailleurs fait étrange, même la commu 6502 ne s'y intéresse pas,alors que celle qui codait des démos sur ST ou amiga s'est intéressé à la MD , dommage .
Même le forum 6502.org ne connaissait pas le hu6280 avant que turboxray/malducci en parle, c'est dire !

HuC a été conçu pour être populaire ; David Michel et moi-même pensions que cela encouragerait les gens à apprendre l'assembleur, tout comme nous étions passés du BASIC à l'assembleur dans nos propres passés. (Mais ces jours étaient révolus depuis longtemps, je suppose)

En ce qui me concerne c'est mission réussit, et je trouve Huc très bon pour ça, avoir pu faire de l'ASM en ligne à été un moyen très simple pour m'y mettre et passer le cap
Avec le recul, on peut difficilement faire de gros projets avec, et on passe à côté de ce tout ce que la machine offre en terme d'astuces,et d'optimisations .

[GuiM]

D'ailleurs ces posts pourraient être archivés dans un topic dédié