Necstasy

David Shadoff a écrit : ↑mer. 01 févr. 2023 05:44 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.

Je viens de vérifier rapidement sur Zeograd.com et je ne trouve ni doc, si sample (je ne parle pas des démos qui sont nombreuses).

Personnellement, je trouve justement que HuC a raté son objectif. Si le but était de convertir les gens à l'assembleur, alors c'est un échec. Les gens voulaient du C, ils ont eu du C... et ils n'en ont rien fait de vraiment concret. D'ailleurs la production de démos s'est arrêtée vers 2006, après quelques années pourtant très actives et encourageantes. Peut-être justement parce que le développement de HuC a été abandonné cette année-là. Elmer en a récemment repris la maintenance et la mise à jour, mais à la base c'est toujours le même kit qui n'a pas vraiment changé depuis 15 ans.

Selon moi, Magic Kit n'aurait jamais dû être remplacé par HuC.

Kaminari a écrit : ↑mer. 01 févr. 2023 16:34 Je viens de vérifier rapidement sur Zeograd.com et je ne trouve ni doc, si sample (je ne parle pas des démos qui sont nombreuses).

Toutes les démos (à ma connaissance) ont été fournies avec le code source dans le but d'être un exemple de code. C'est quelque chose que j'ai précisé comme étant une exigence pour les soumissions et j'ai veillé à ce que tous mes exemples soient fournis (avec commentaires). (Zeograd gérait cependant le site.)
De plus, les fonctions de la bibliothèque HuC ont également été fortement commentées, afin d'expliquer ce qui est nécessaire pour faire fonctionner un jeu sur du matériel PC Engine. Mais il semble que seul Chris Covell ait utilisé ce code comme "bootstrap" pour écrire ses propres programmes assembleur.

Personnellement, je trouve justement que HuC a raté son objectif. Si le but était de convertir les gens à l'assembleur, alors c'est un échec. Les gens voulaient du C, ils ont eu du C... et ils n'en ont rien fait de vraiment concret.

C'est une critique juste. Mais c'est à la fois une critique de l'outil et des utilisateurs qui demandent plus d'outils (et se plaignent des limites de la machine), plutôt que de perfectionner leurs propres compétences.

D'ailleurs la production de démos s'est arrêtée vers 2006, après quelques années pourtant très actives et encourageantes. Peut-être justement parce que le développement de HuC a été abandonné cette année-là.

Deux choses se sont produites à ce moment-là. IRC et #tghack-list étaient les principaux canaux de communication, mais la communication a chuté de façon spectaculaire à cette époque. De plus, Zeograd et moi sommes devenus très occupés.

Elmer en a récemment repris la maintenance et la mise à jour, mais à la base c'est toujours le même kit qui n'a pas vraiment changé depuis 15 ans.

Encore, une critique juste.

Selon moi, Magic Kit n'aurait jamais dû être remplacé par HuC.

Le problème avec cette déclaration est que MagicKit n'a jamais été remplacé... cependant, personne à part David Michel ou moi-même n'avait jamais créé de démos entièrement en assembleur à cette époque (Chris Covell est venu plus tard). HuC a été construit pour l'augmenter. Vous pouvez toujours utiliser MagicKit, et l'assembleur inclus dans HuC est de toute façon similaire à 99% à MagicKit.

Au moment de la construction de HuC, je craignais que la création de HuC ne soit une erreur... à cette temps la plupart des personnes qui s'intéressaient à l'écriture de jeux pour PC Engine ne connaissaient pas non plus le "C". Mais sans débogueur (rappelez-vous que le débogueur de Mednafen n'a existé qu'en 2006 environ), l'assembleur aurait été désastreux pour n'importe qui, sauf pour les programmeurs assembleurs expérimentés.

Le vrai problème ici est qu'il n'y a jamais eu beaucoup de personnes intéressées par le développement pour PC Engine, et la création d'outils a toujours consommé > 80 % de tous les talents disponibles.

J'ai essayé PCEAS 4 (inclus dans HuC 4) il y a quelque temps et la compatibilité avec PCEAS 2.51 (Magic Kit) semble inexistante. Toutes les macros et includes ont fortement changé, sans aucune doc pour expliquer les modifications ou les ajouts, et je ne comprends pas grand chose aux messages d'erreur lors de la compilation. Ce n'est pas seulement un problème de syntaxe, j'ai l'impression que des fonctionnalités ont disparu. Si je dois inventer mes propres includes, je suis mal barré

Ah, alors ce sont les bibliothèques qui vous causent des problèmes. Oui, ceux-ci ont changé. Malheureusement, en tant que programmeur assembleur, vous pourriez probablement être affecté par même de petits changements dans les versions (même les corrections de bogues changent la taille.

Le contrôle de version peut être un gros problème pour l'assembleur, en particulier lorsque quelqu'un essaie de recompiler un programme plusieurs années plus tard et s'attend à une version propre.

Je vous recommande de créer et de gérer votre propre ensemble de bibliothèques pour chaque projet. Dans le cas de Chris Covell, il a pris une copie des bibliothèques de base, supprimé les éléments indésirables et effectué des ajustements mineurs si nécessaire. Cela nécessite souvent une compréhension plus approfondie du fonctionnement des fonctions de la bibliothèque.

Personnellement je veux vraiment essayer de travailler avec HuC. En l'état je pense que l'on peut faire un jeu complet sans souci en version CD.
Pour un petit développeur, avoir du C permet d'envisager un portage du projet beaucoup plus facilement sur les consoles voisines ( je suis passé de la MD à la PCE pour ma démo, et j'ai fait un crochet par la SNes, presque réussi à 1 ou 2 détails près, le kit d'Alek est opérationnel aussi ).

Le vrai problème ici est qu'il n'y a jamais eu beaucoup de personnes intéressées par le développement pour PC Engine, et la création d'outils a toujours consommé > 80 % de tous les talents disponibles.

C'est un constat dur mais réaliste. De mon point de vue :
- la PCE est une pure console japonaise, avec ce que cela implique en terme de ludothèque. Hudson n'avait pas les moyens de tout traduire.
- Ni Hudson ni Nec n'avait l'équipe pour comprendre le marché occidental ( la megadrive est quasi plus US que japonaise par exemple ).
- bien vendue au japon, mitigée aux US et inexistante en europe avec le gros fail de la Turbografx PAL restée à dormir dans un hangar.
- au final un rapport 1 pour 4 PCE/MD, et 1 pour 5 PCE/SNes, donc moins de gens potentiels à l'arrivée pour dev dessus.

En l'état actuel des choses, quels types d'action pourraient être menés pour faire progresser la commu dev nec ?

- un discord dev dédié ?
- des vidéos tutos basées sur les très bons tutos de OSHAT sur MD ? ( la plupart des FR qui rejoignent le chan SGDK les ont faits ) ?
- des participations PCE sur des gamejams un peu connues ?
- des streams Twitch/Youtube ?
- un Twitter devpce ?

@David : Pour le format hucard, je suppose que tu pensais surtout à Squirrel. Que le format de sortie final soit du MML, aucun problème. Mais c'est quasi impossible d'aller convaincre des musiciens occidentaux de bidouiller ce format à la compo, donc oui la piste de l'outil est essentiel pour convaincre du monde.

Avec Furnace qui est open source, on pourrait peut-être envisager un plugin d'export FUR2MML, après tout il y a bien un MOD2MML qui traine sur je ne sais plus quel moteur. Maintenant il faut trouver le dev qui connait bien à la fois le format tracker et le format MML, et ponde le plugin en C++. Puis ensuite que Squirrel soit quasiment intégré à HuC ( à la limite un module git ). Oui, ça fait fainéants qui ne veulent pas trop ce bouger les fesses pour apprendre à maitriser une plateforme, mais il suffit de voir le succès de GB Studio ou NesMaker pour admettre que c'esst efficace de prendre les gens par la main.

Je suis un peu obsessionnel sur cette histoire de son hucard mais si on fait une comparaison, c'est comme si le SGDK actuel ne proposait que du megacd, cela aurait je pense largement refroidi les ardeurs. Le côté nostalgie me semble jouet à plein. Et le format CD nec représente qu'à peine 20% des possesseurs de console Nec ( et je crois que c'est à peu près pareil pour la megadrive ).

Désolé pour le côté un peu "yakafokon", mais j'essaie simplement d'envisager comment espérer du mieux pour la petite bécane carrée ( et indépendamment de tout l'énorme travail qui a déjà été accompli par les anciens de la plateforme , dont toi David, David Michel, Elmer, XRay, Touko, Mooz et tout ceux que j'oublie ou que je ne connais pas encore )

Merci Dave, je vais creuser le sujet et essayer de comprendre comment basculer mon code vers PCEAS 4.

@Lunoka

Il existe un Discord Necstasy (pas très actif), mais on pourrait ajouter une chat room pour le développement

Le PSG (ou plutôt WSG) de la PCE est un peu le parent pauvre des développements homebrew, pas seulement par manque d'outils (Deflemask/Furnace pourraient très bien faire l'affaire avec un player DMF) mais surtout parce que je crois que le son PCE n'a pas la même réputation que d'autres machines plus populaires, comme la Famicom ou le MSX. C'est fort dommage. On note tout de même un certain intérêt pour les chiptunes PCE sur YouTube, quelques compositeurs font un excellent travail.

Le MML était surtout un format de sauvegarde et d'export, un peu comme le MIDI. Personne ne fait du MIDI en tapant directement des commandes dans un fichier texte, on passe par un séquenceur ou un tracker C'était pareil pour les compositeurs japonais qui utilisaient des outils dédiés, souvent fait maison. Je ne pense pas que ces outils aient survécu (à part peut-être ceux de Koshiro, qui insiste à travailler sur son PC-88).

N'oubliez pas que j'ai arrêté de prendre en charge HuC il y a peut-être 20 ans, donc mes observations datent de cette époque... il y avait beaucoup de gens qui demandaient de nouvelles fonctionnalités qui leur seraient bénéfiques, mais qui n'étaient pas réalistes à mettre dans les bibliothèques principales. En d'autres termes, ils demandaient aux développeurs de HuC d'écrire leur jeu pour eux. Ces personnes ont maintenant disparu, ce n'est donc pas une réflexion précise sur les utilisateurs actuels, bien qu'Elmer ait mentionné une ou deux histoires similaires.

Pour la musique, chaque fois que j'entends deux développeurs discuter d'un lecteur de musique, ils veulent deux formats différents, et ils rejettent tout ce qui existe actuellement. Dans cette situation, il n'y aura jamais de solution qui plaise même à 50% des utilisateurs, donc je préfère ne pas participer à cette discussion.

Étant donné que PC Engine est essentiellement une machine 8 bits, il a beaucoup de travail supplémentaire pour gérer un type "int". Et transmettre des données en tant que paramètres de fonction (en les plaçant sur la stack) est encore pire. Cela en fait un choix terrible pour un compilateur "C", sauf en tant que jouet. Même la version du langage est pré-ANSI, donc le code ne sera pas portable. Elmer a considéré KickC comme une alternative, qui résout ces problèmes, et est également une version plus moderne de 'C'... mais il n'est pas encore prêt.

Au final, pour ces raisons de langage, faire un SDK pour PCE est beaucoup plus difficile que pour MegaDrive (qui peut s'appuyer sur des outils créés pour l'Amiga).

Je pense que les comparaisons avec NES ou GB ne sont pas réalistes, car ces communautés sont des centaines de fois plus grandes que le PC-E. Cela signifie que beaucoup plus de personnes créent des outils et beaucoup plus de personnes créent des jeux. Et beaucoup plus de personnes créant de la documentation, je suppose.

La plupart des anglophones qui écrivent des jeux "complets" envisagent de faire des copies physiques et de les vendre. Ce n'est que récemment que cela est devenu possible pour les supports HuCard, et il existe encore des limitations de taille. C'est pourquoi nous demandons généralement "pourquoi ne pas faire un CDROM ?" (au moins dans le passé)

Pour être honnête, quand je regarde le PC-FX, cela ressemble à un système beaucoup plus convivial, avec le support du compilateur gcc, plus de mémoire, plus de puissance CPU, moins de limitations et du matériel similaire (HuC6270, puce audio, etc. ) au PC-E. J'étudie actuellement cette machine.

La Snes a un parc imposant pourtant niveau sortie homebrew c'est pauvre, inférieur à des machines comme la Neogeo ou les Lynx/Jaguar, donc le succès à l'époque n'explique pas tout. Sur Snes on a eu quelques jeux annulés récupérés, Nekotako, un jeu VS 2D médiocre... Alors que sur MD on a un paquet de sorties qualitatives (BTA, shoot, RPG, loin des clones de pong et cie qui ont pullulé sur les consoles Atari, pionnières dans le homebrew) + une scène de hack ultra-vivante. La disponibilité des machines et la qualité du kit de dev compte. Après sur MD il y a eu un avant et un après Pier Solar je pense. Un jeu comme Xenocrisis a suffisamment marqué pour qu'il sorte physiquement sur Vita/PS4/Switch/Dreamcast/Neogeo donc une sortie de qualité peut se rentabiliser au delà de la PCE.

Je maintiens que si Analogue distribue pas trop mal sa machine (une DUO avec sortie HDMI à 200$, dans le cas de la PCE contrairement aux NES/MD/SNES Analogue est moins cher que le matos d'origine), il suffirait d'un homebrew suffisamment qualitatif pour attirer les DEV.

Disons que sur Md, sgdk est complet.Il permet de gérer le hard de la machine facilement(tout comme huc le fait avec la PCE ), et surtout a un vrai driver son qui permet de rejouer facilement des musiques faites avec un tracker moderne, donc assez simple de trouver des musiciens.Pour les SFX pareil, stef a inclut un driver PCM 4voix, il vaut ce qu'il vaut, mais est fonctionnel au moins et ne semble pas trop gêner les codeurs .
C'est ce qui fait la force de SGDK, il est complet .

Ensuite favoriser le CD c'est bien, mais pour des projets ambitieux, c'est qd même limité, les 256ko ne suffisent clairement pas, encore moins pour une conversion d'arcade,à moins d'ajouter l'AC,ce qui accroit les temps de loading .

Le hacking a été extrêmement actif sur SNES entre 2000 et 2010, notamment la traduction de ROMs SFC japonaises.

En revanche niveau homebrew, je m'explique leur inexistance par le fait que la SNES visait un public clairement plus jeune que la concurrence, public qui n'a plus aujourd'hui le même intérêt pour cette machine autrement que par nostalgie. Sans compter qu'au niveau technique, c'est un peu de l'arnaque : officiellement 128 sprites simultanés, 32 sprites par ligne... alors que dans les faits, la bécane rame dès qu'il y a 3 sprites à l'écran (encore vérifié récemment avec Demon's Blazon et Chō Makai Mura).

"qui n'a plus aujourd'hui le même intérêt pour cette machine autrement que par nostalgie"
dans mes bras !!!

Un clone/hommage à Rick dangerous, financé par KS a quelque chose comme 3 ans de retard. En rpg ou plate-formes la SNES a largement ce qu'il faut sous le capot, et comme sur MD des cartouches de >32mb c'est à la portée de tout le monde.
C'est peut-être le kit de développement qui est à la ramasse sur SNES, même sur Jaguar il se passe des choses.

Kaminari a écrit : ↑jeu. 02 févr. 2023 16:23 Sans compter qu'au niveau technique, c'est un peu de l'arnaque : officiellement 128 sprites simultanés, 32 sprites par ligne... alors que dans les faits, la bécane rame dès qu'il y a 3 sprites à l'écran (encore vérifié récemment avec Demon's Blazon et Chō Makai Mura).

Suffit de voir RR² pour voir que c'est faux hein !!
Ceci dit, la snes a effectivement un gros soucis hardware avec les sprites, ça c'est un fait,cependant de simples hacks ont démontrés que les ralentissements sont surtout liés à du code de merde .

Tu parles des hacks qui utilisent la puce additionnelle destinée à l'origine pour du son ? Genre le Super R-Type ou le Gradius 3 ?

R2 est sorti 5 ans après la sortie de la console. Et Trenz est celui qui avait poussé le C64 très loin. Tous ces éditeurs qui avaient brillé sur Nes ont eu bien du mal sur SNES je trouve : Irem, Sunsoft, Taito, même Konami dans une moindre mesure.