Necstasy

J'ai un doute en voyant les captures de Shining.

Ton test de routine AC est sensé inclure un morceau de gameplay ? Parce que je n'ai que le background statique avec ton ISO.

Non pas sur l'ISO PCE, faut tout réécrire sinon, donc j'ai fait au plus simple pour que les tests soient possible sur les 2 hardwares, une image fixe à partir de ce qui est chargé dans l'AC .

Je viens de faire quelques tests avec HuCC d'Elmer (pas encore de release officielle, même s'il est en beta publique depuis quelques mois).

La nouvelle fonction scroll déchire l'ancienne, vieille de 25 ans. Elle supporte jusqu'à 128 splits par VDC... car oui, il est maintenant possible de faire des parallaxes sur le VDC2

Quel bonheur !

C'est cool, reste à voir les perfs et comment c'est fait .

Qd je vois encore ce genre de trucs dans le code :
Rien de méchant, mais pas pour un confirmé .

J'ai jeté un coup d'œil au code et je trouve ça assez lourdingue je pense qd même que ce sera surement bien mieux que les anciennes routines de scroll, mais j'ai l'impression qu'avec elmer c'est souvent "pk faire simple ,qd on peut faire compliqué" .
Bon en même temps il est tout seul sur ce projet, donc on peut peut être pas trop lui en vouloir .

Kaminari a écrit : ↑jeu. 02 févr. 2023 16:23 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).

Pas que ça me trigged (enfin si), mais j'ai envie d'y répondre parce que beaucoup ne comprend pas le manque d'homebrew sur SNES.
Et là je peux affirmer que c'est clairement pas parce que la SNES "cible" des plus jeune et qui sont passé à autre chose.
La scene SNES dev est très active, mais elle ne sort pas de jeux .

Et ce n'est pas un problème de compétence il y'a des personnes extrêmement talentueuse et passionné pour le dev SNES.
Mais la console est complexe et le CPU est vachement long, et le hardware demande pas mal de calcul pour le gérer (y'a bien plus de truc complexe que sur PCE) , notamment les sprites hard qui prend un certain temps de calcul (d'où pourquoi y'a des ralentissement sur certain jeux).

Pr exemple la Mega drive profite du SGDK.
La SGDK se base sur "GCC" , c'est un compilateur pour le langage C qui est un des meilleurs et qui fournit un code relativement bon en sortie avec un bon CPU.
Et sur SNES tu n'as pas de GCC , et donc tu ne peux pas faire un kit de dev comme SGDK.
Et comme la PCE à un processeur assez semblable à celui de la SNES ,elle aussi n'a pas de GCC et donc pas de super SDK.

Donc sur SNES , il reste que la prog en assembleur , et c'est à peu pres le meme cirque qui dure :
Y'a un nouveau qui se pointe , se dit "ah ben les nuls vous savez pas coder en ASM , je vais vous montrer moi" (je caricature evidamment).
Il fait des démo , ça marche super bien et donc pour l'aventure pour faire un jeux vidéo , donc ça rajoute des trucs petit à petit ,jusqu’à le code devient extrêmement complexe et difficilement maintenable, et dans le long terme ça pousse à ce fameux dev à abandonner le projet , voilà voilà , c'est globalement ce qui se passe.

Et la scene SNES dev à perdu énormément de "bon dev" qui ont littéralement abandonné la SNES après avoir fait de gros démo/début de jeux , ou moteur de jeu etc.

Et forcément les "mentalités" ne change pas , ce qui du coup pousse à reproduire ce shéma ad eternam.

Pour résumé :
-un CPU long
-coder en asm (pas de bon compilateur C , c'est encore pire que la PCE ou la NES sur ce coup)
-hardware complexe
-les meme erreur se répète dans la scene snes dev

Donc on a vraiment le combo gagnant là pour réduire le nombre de homebrew , et la MD aurait eu le meme soucis s'il n y'a pas de C (et donc pas de SGDK).
Alors certain me diront "oui mais la Nes y'a des Homebrew" ah ben si tu veux faire un jeu Nes, sur SNES , y'a pas de soucis et y'en aurais beaucoup plus , mais les gens s'attende à des homebrew au minima à celle de la MD.
Donc des projets assez conséquents, et gros projet veut dire bien plus complexe à gérer , donc c'est une complexité accru qui devient vite "ingérable" sur SNES vu les fortes contraintes de la machine.


Pour finir je dev sur SNES depuis 10 ans, donc je fais partit des "anciens" et effectivement je compte cassé un peu ce cycle d,en proposant mon dev kit SNES , mais en faisant un jeu aussi.
Alors ça marchera ou pas , je ne sais pas , mais ça sera ma "participation" au moins

On espérant expliqué pourquoi y'a peu d'homebrew sur SNES.

Un état des lieux intéressant sur cette scène indé, finalement assez proche de la situation PCE (notamment à propos des projets avortés).

Cela dit, HuCC (qui est basé sur KickC) va peut-être rendre le homebrew PCE à nouveau fréquentable.

Ah ben tant mieux, du coup j'ai l'impression d'arriver trop tard, vu que je voulais proposer mon kit de dev pour PCE , mais qui n'est pas sur du C (ni en asm) , mais un langage intermédiaire avec un style C ^^'

Au contraire ! Toutes les solutions alternatives sont les bienvenues, surtout après des années de disette. HuCC reste un compilateur avec des macros à la SGDK, ce n'est certainement pas un kit de développement complet.

Je serais curieux de savoir pourquoi il n'est pas complet ?
Qu'est qui lui manque ?

Parce que bon moi je compte pas aller plus loin que gérer un BG , les sprites , le scrolling , les SFX et la musique.
Et je rajouterai sûrement quelque fonction pour gérer les collisions et les anims.

Je suis un gros noob sur le sujet, donc mon opinion est mineure, je trouve qu'une des difficultés principales c'est la gestion des tileset. C'est ce qui me pose le plus de problème pour faire un truc de base.

Sans parler optimisation performance etc...

Tu utilise HUCC non ?
Il n'est pas suffisamment optimisé ?

Je dis ça parce que elmer m'avait dit que le C avec son SDK (codé en asm) est suffisant pour la PCE.

Moi je disais le contraire disant que le C à ces limites , surtout sur le 6502 , meme si KickC fait un code pas trop dégueu comparé à d'autre compilo 6502.

C'était sur nesdev quand j'ai présenté mon langage de programmation.
Quand je le présenterai sur les forum pc-engine anglophone, je sens que va y'avoir certain débat x)

Sinon je compte faire un tileset+scroling intégré et compatible avec tiled, bref donné un outils complets, je vois pas l’intérêt que chaque personne doit le recoder ( et surtout assez mal).

Je dis ça parce que elmer m'avait dit que le C avec son SDK (codé en asm) est suffisant pour la PCE.

Ouai il est gentil elmer, ça dépend ce qu'on entend par suffisant .

Le problème c'est que les nouveaux venus ne se rendent pas compte du temps que prend le dev d'un jeu, au début t'es hyper motivé, ça avance vite, puis tu commences à saturer petit à petit(vu l'ampleur d'un jeu complet), la motiv s'estompe, et le dev tire en longueur, jusqu'à arriver à ne plus avoir envie de finir, voire être parti sur autre choses, car le dev est bien monté en compétences, et code de mieux en mieux, et son premier projet codé avec le cul, il a plus trop envie de le finir .

Il suffit de voir tous les projets en cours, peu importe la machine, pour se rendre compte de cela .On est tous pareil .
Perso je me lancerai plus dans des jeux originaux, je laisse ça aux courageux .

PS: Pour ceux qui comprenaient pas trop ma réaction envers le jeu Nyanja! , vous comprenez maintenant avec la démo RPG de kami, ce que je veux dire par minimum syndical ? kami qui débute, ne se contente déjà pas du minimum syndical d'un débutant, et ça se voit à l'écran .

Sur twitter on m'a répondu ça (ParanoiaDragon) :

Il y a certainement des choses qui se passent en ce qui concerne les kits de développement et les moteurs, mais principalement en arrière-plan pour le moment. Il y a des choses dont je ne peux pas parler, mais qui seront révélées bientôt. Honnêtement, je ne sais pas quand, mais on m'a dit bientôt que certaines choses seraient révélées.

Beaucoup de choses me passent par-dessus la tête puisque je ne code pas, mais je sais qu'il existe plusieurs outils en cours d'élaboration on. Je pense que le moteur #HuSlayer de @turboxray
pourrait changer la donne. Et il y a quelques projets dont je suis au courant que je ne suis pas censé répéter, donc je dois faire attention à ce que je dis.

Apparemment il dit qu'il y'a un kit de dev prévu pour PC-Engine en cours , mais secret !

Je reste sceptique avec ce genre d'annonce, si quelqu'un à quelque chose de solide, je doute que tout soit en sous marin.

Je connaissais pas la démo : HuSlayer

https://www.youtube.com/watch?v=kU7myUxemZg

Impressionnante , mais si elle est faite en assembleur, ça risque pas de changer la donne, faire un moteur en assembleur facilement modifiable est tout sauf trivial.
Et j'en sais quelque chose pour codé en asm depuis 15 ans !
Il y'a eu des projets plus ou moins similaire sur SNES (des libs/moteur en full asm) , mais aucun n'a marché.

HuSlayer est une vieille arlésienne qui n'a rien de secret.

Le codeur Rick Leverton (Tomaitheous / Malducci / Bonknuts / TurboXray) est un champion de l'assembleur, qui est malheureusement aussi connu pour promettre beaucoup d'outils sans jamais les terminer — par manque de temps comme de motivation. J'observe toujours ses bidouilles avec grand intérêt (comme sa technique de transparence qu'il a récemment partagée sur Github), mais je dois reconnaitre que je n'en attends rien de concret. Tout ce que fait Rick depuis des années, au niveau graphique comme sonore, est expérimental et en assembleur pur.

On ne connais pas non plus l'état exact de son kit. Je doute qu'il soit vraiment grand public. Il s'agissait au départ d'un moteur graphique capable de gérer des maps... faites en sprites ! Le principe était fun mais l'intérêt pratique très limité, notamment à cause de la faible résolution (192x224).