[terminé ] Barbarian sur PC engine (hucards envoyées)

F.L a écrit:salut à tous
je remonte le sujet pour vous dire que la conversion avance à grand pas. j'ai fait en quelques jours sur pce ce qui m'avait demandé des semaines sur megadrive
...
@+

Hello,

Déjà, c'est super chouette ce que tu fais et le rendu obtenu , ça me rappelle mes vertes années sur 6128 :,) ...

Ensuite, est-ce que tu pourrais faire un peu un delta sur le dev megadrive VS pce qui expliquerait pourquoi ça va plus vite d'après toi.

bonne idée ce petit comparatif bex/huc
TOUKO parlerait de Huc mieux que moi car je ne fais que decouvrir pour l'instant. il y a pleins de choses que je n'ai pas abordé. mais comme je l'ai dis plus haut, rien que pour de ma petite experience avec huc, les choses vont 3x plus vite.
mais comme toujours il y a du bon et du mauvais partout :

- coder, compiler
pour bex, une interface tout en un assez simple
pour huc il faut un editeur + compiler sous dos
les deux compilent super vite

- afficher un background :
4 lignes avec huc pour un decor non optimisé mais on utilise le fichier image (pcx) tel quel
9 lignes avec bex pour un decor optimisé mais il faut encoder avant l'image en .bin

- afficher un sprite
8 lignes pour huc. pareil, on utilise direct le fichier image. le sprite peut faire 32x64 maxi (16x16 mini)
6 lignes pour bex mais il faut l'encoder avant en tiles ou en .bin et le sprite fera 32x32 maxi (8x8 mini)
a savoir : les mises en vram demandent un peu de reflexion et decalcul avec huc alors qu'avec bex c'est ultra simple

-gerer les entrées pad
pareil

- jouer un son
impossible avec huc. ou alors en assembleur ?
3 lignes avec bex mais pour des sons basiques ou un generateur de bruit

- jouer une musique
j'attends de voir avec huc
une routine de 15 lignes environ en assembleur pour jouer une musique encodée en PCM

bon, j'ai comparé vite fait deux machines mais aussi deux langages differents ( C et basic )
et il ne faut pas oublier que la pcengine est une 8bits. sur pce les fonctions ne doivent pas depasser les 8ko, tout comme le main. il faut donc bien optimiser et partitionner son code si on veut que ça tourne bien.
de l'autre coté le basic de bex sur la megadrive avale un listing de plusieurs milliers de lignes et pas optimisé sans broncher à 60fps. (impressionnant d'ailleurs)

voila, si ça peut aider quelqu'un à faire son choix.
@+

impossible avec huc. ou alors en assembleur ?

C'est juste que de base (jeu hucard) le driver est trop basique, il faut soit coder son driver ou utiliser un driver déjà fait comme squirrel (MML) .
N'oublies pas que pour BEX c'est une intégration du driver de stef, c'est pas non plus d'origine .

Pour les PCM et la musique si j'arrive à faire ce que je veux ça devrait être simple à faire pour toi .

les mises en vram demandent un peu de reflexion et decalcul avec huc alors qu'avec bex c'est ultra simple

Oui huc ne gère pas l'occupation mémoire, donc tu es obligé de le faire à la mano, CAD savoir ce que tu utilises comme VRAM,c'est plus rapide niveau code, mais moins simple pour le codeur .

j'attends tes routines avec impatience !

Sans parler de la routine de stef, avec bex on peut "piloter" directement la puce sonore psg, les commandes dont tres simple, on fait
psgvol 1,15  ouvre le canal 1 au volume 15 a fond
psg 1, x  joue la note x sur le canal 1
psgvol 1,0 referme le volume du canal 1
il y a 3 canaux. Le troisieme cest un genérateur de bruit
en jouant avec les notes et les durées d'ouverture ont peut faire des trucs sympa.
par exemple, j'avais fait comme ça le son du moteur de crazy cars et la musique d'intro de barbarian appleii.
dommage qu'il n'existe pas un truc comme ça avec huc pour faire au moins des bip bip

hello
je remonte le sujet car aujourdh'ui j'ai fait une assez grosse MAJ du jeu :
- j'ai augmenté la vitesse des animations. il y a une sacré difference. ça va 2x plus vite qu'avant avec pourtant un affichage que j'ai limité à 30 fps. (comme sur one et ps4 quoi )
- toutes les animations en inversés sont ok.
- en mode solo, les barbares changent de couleurs.
- j'ai ajouté le sorcier et marianna. il manque encore qq details mais ça marche

je rapelle le lien de la rom, qui n'a pas changé :
https://www.dropbox.com/s/z4qu5rq6eebdzsx/barbarianBETA.pce?dl=0
pour ceux qui n'ont jamais lancé de rom pce, je recommande l'emulateur mednafen

je pensais mettre une vidéo en ligne ce wee-end mais l'everdrive que j'ai acheté ne marche pas...

j'aurais besoin de votre avis en ce qui concerne la difficulté. dites moi si c'est pas trop facile car l' IA provient de la version megadrive, et je l'avais rendu plus facile car il est assez difficile de faire les diagonales avec la manette megadrive, alors que ce n'est pas le cas avec la PCE. comme je connais le jeu par coeur depuis 2012 je ne me rends plus vraiment compte de la difficulté des IA et de plus, il ne faut pas que le jeu soit trop difficile. pas evident! merci d'avance

manque plus que les sons et musique grace à TOUKO et le jeu sera quasiment fini. dire que je n'ai commencé qu'il n'y a seulement un mois environ !
@+

a premiere vue, ça n'a pas l'air compliqué, tant mieux.

au départ c'était Joue_Sample( tab_sample_a_jouer , num_de_la_voix_pcm );
Donc appel 100% C.

mais qu'entends tu par "changer l'ordre d'inclusion des fichiers(graphiques)" ?

 
Il faudra juste inclure la librairie+samples avant tes fichiers graphiques.
Les fichiers "chargement des tiles du titre", j'ai du les inclure après la création de tes variables .

j'ai augmenté la vitesse des animations. il y a une sacré difference. ça va 2x plus vite qu'avant avec pourtant un affichage à 30 fps. (je garde de la marge au cas ou la musique fasse ramer le jeu)

Cool, techniquement même en C, le jeu devrait tourner à 60fps même avec la musique + les samples,déjà en faisant un peu de ménage dans ton code tu arrives à bien booster les perfs, c'est bien .  

- toutes les animations en inversés sont ok. (oui j'utilise bien la fonction flip, mais il fallait dire au programme où mettre quoi aussi en inversé, car j'ai tout en double   )

ah ok, c'était juste au cas où  

manque plus que les sons et musique grace à TOUKO et le jeu sera quasiment fini. dire que je n'ai commencé qu'il n'y a seulement un mois environ !  

Si on arrive à inclure les 2, ton jeu va de suite prendre une autre tournure, les sons+zique ça habille bcp .

Je croyait qu'a ton age on croyait plus au père noel doc ?? 

drfloyd a écrit:

F.L a écrit:à ce rythme là , je vais finirpar porter barbarian en assembleur sur coleco

c'est une boutade ou pas ?

pour l'assembleur oui c'etait une boutade !
vétéa m'a montré vite fait ce qu'etait l'assembleur et j'ai été un peu découragé
comme je lui ai expliqué, il ne faut pas qu'il y ait trop de contrainte pour que je "lache" les codes sinon j'ai le cerveau qui fauche (je ne plaisante pas)
l'idéal ça serait parler à la machine et qu'elle s'execute. mais là je reve...

par contre, pour la coleco ou autre, si on me montre comment faire une boucle et afficher un sprite sur une console (et si c'est pas trop tiré par les cheveux pour y arriver) maintenant je peux adapter mon code en C sur pas mal de machines, ça serait un beau challenge de sortir barbarian sur une console tous les ans, pourquoi pas !
il y a un mois je cherchais une machine, j'etais meme partant plutot pour la snes...
TOUKO m'a envoyé un petit dossier avec un exemple bien fait, j'ai fait ma rom en 2 minutes et je me suis dit bingo, c'est reparti

grace aux codes de TOUKO, j'espere finir barbarian version cpc en janvier, et si ça se passe aussi bien, faire les 6 autres versions sur pce, comme j'avais fait sur megadrive. pour le moment je suis seduit par la pcengine, alors je ne vais pas lacher l'affaire, elle a un super potentiel. mais on verra par la suite si je peux porter barbarian sur d'autres supports. si crom veut bien me donner la force 

En janvier c'est faisable vu le boulot énorme que tu as fait .
Arriver à faire ça en si peu de temps sur une machine et un langage que tu connaissais pas, chapeau .

J'ai testé la rom sur emu.
Comme l'a dit Touko, mes félicitations pour déjà être arrivé à ce résultat en si peu de temps / sans connaissance en C !

Comme sur MD je percois des petits accrocs d'anim / tiles qui sautent de façon "bizarre".
Je ne sais pas si c'est du aux VBL qui sortent des clous ou autre, mais d'avis qu'il faut enregistrer l'écran via quicktime (par exemple) et regarder ca image par image. (à 60fps)
Perso j'utilise un vieux quicktime sur mon Mac (un QT 7) car on peut avancer image par image et c'est bien pratique pour voir les merde (car à 60fps bon courage pour bien identifier un couac à l'oeil)

edit. J'ai trouvé en fait ce qui me gênait visuellement ^^
Quand les sprites arrivent de chaque coté, bizarrement la frame d'anim est changée avant de bouger (alors qu'il faudrait que ce soit après logiquement)


Divers problèmes de metamap & cie.


Le passage du logo Barbarian à la démo a aussi un problème de chargement/provoque un flash au niveau de la palette (gris en bas)
Pour charger tous les tiles du background il faut que tu coupes l'affichage complet, charge le tout, puis ré-allumes l'affichage.

Courage FL !

merci pour les encouragements !
rien n'echappe à tes yeux de lynx

- le bug de la marche sur le joueur de gauche, me poursuit depuis la version megadrive.... c'est quand la boucle est trop rapide, et ça ne le fait pas sur le joueurB (a droite) alors que les routines sont les memes . ça ne le fait que sur console, pas sur pc. il faut vraiment que je trouve pourquoi ça fait ça.j'ai l'impression que sur console parfois les lourdeurs de programmation font des variations de vitesse interne et c'est là que ce "glitche" apparait...

- pour l'apparition du decor avec la bonne palette, bien vu. je vais essayer comme tu dit mais je ne maitrise pas encore bien les subtilités de Huc.

- je n'ai pas encore réglé les priorités entre les deux sprites des joueurs.c'est normal. pour l'instant j'ai mis que B ait priorité sur A, mais il faut que je regle ça car quand A meurt, il passe derrière et c'est pas beau.

- sur le screenshot ou il manque les jambes. je ne vois pas ce que ça peut etre. les sprites sont coupés en deux parties. peut etre que sur cette frame, la seconde partie a mis du temps à s'afficher

il reste encore du boulot !
@+

Y'a aussi les timing que l'emulateur ne respecte pas forcement et qui crée des glishes sur le vrai hard .

je ne sais pas comment est structuré ton code, mais normalement faut bien dissocier le code pendant la partie active de l'affichage et celui du v-blank (j'occulte volontairement les interruptions & cie *).

Utiliser le vblank pour mettre à jour les positions des sprites et (re)charger les tiles des sprites.

Le décors étant lui charger au départ, avant que quoi que ce soit commence.

donc en gros, tu devrais avoir quelque chose comme ca :

- ecran off
- charge tiles/map du background
- ecran on

while(x){
- pad
- collisions & répercussion (pv, points etc)
wait vblank()
 - maj frame music / sfx
 - maj des sprites (chargement tiles et positions)
}

ps. attention je ne connais pas la syntaxe propre à huc, ni spécialement la pce au niveau dev, c'est une notation "généraliste" si l'on peut dire

Touko confirmera ou non, mais je ne pense pas que charger des tiles à l'arrache pendant l'affichage actif soit une bonne chose (on peut le faire sur SMS, donc devrait pas y avoir de souci sur PCE, mais y'a des délais d'écriture à respecter sous peine de glitchs)

*meme si le v-blank lui meme en est une.

Tous mes encouragements pour cette adaptation d'un jeu mythique sur une console qui l'est tout autant !

Touko confirmera ou non, mais je ne pense pas que charger des tiles à l'arrache pendant l'affichage actif soit une bonne chose (on peut le faire sur SMS, donc devrait pas y avoir de souci sur PCE, mais y'a des délais d'écriture à respecter sous peine de glitchs)

En gros c'est la bonne procédure, sur PCE tu peux faire aussi comme ça, surtout avec HUC, mais sinon en ASM et si tu sais ce que tu fais, tout peut être fait pendant l'affichage vu qu'il n'y a pas de restrictions d'accès à la VRAM pendant l'affichage.
Mais bon avec les tiles si tu modifies celles qui sont affichées vaut mieux attendre le vblank pour éviter les glishes.

il faut dire que je n'ai pas vraiment de structure de codage predefinie.
tout se fait "à la volée" avec moi
vous connaissez le jazz manouche , et bien il y a aussi le code manouche
pour resumer ma maniere de faire : si ça marche tant mieux, on garde sinon, on modifie jusque ça marche
j'exagere un peu mais c'est pas loin. il faut dire que j'utilise le meme moteur de jeu depuis 2012. ce listing de plusieurs milliers de lignes imaginé en basic avec qb64 a été adapté ensuite à la megadrive puis a transité par l' html5 l'année derniere et des devenu du C dans huc cette année. a chaque fois sa synthaxe change mais au fond il reste le meme.
petit à petit, il se transforme pour etre de plus en plus structuré.
avec huc j'ai été obligé de bien le modifier. j'ai meme revu certaines fonctions que je n'avais pas touché depuis 2012, nottament les entrées clavier. j'ai retrouvé mes premieres variables x1 et y1 qui etaient des vestiges de mes premiers essais ou je faisait bouger un sprite à l'ecran. helas j'ai été obligé de m'en separer car il y avait des redondances mais jusqu'ici ça marchait.
a force, ce code que j'ai crée va devenir propre et sans défaut : ça me fait presque peur

ichigobankai a écrit:(j'occulte volontairement les interruptions & cie *).
*meme si le v-blank lui meme en est une.

Non-non, ne pas confondre VBlank et interruption de VBlank

oups ^^
désolé chef !

Edit. en plus j'suis vraiment con, c'est pas comme si je l'avais déjà codé dans mes menus SMS pour intérargir avec les micros controleurs derrière... oh le boulet 

Ah au fait, message personnel pour FL :

Le GOTO EXISTE EN C !! 


A toi les ruses des vieux codeurs manouches !!!

Syntaxe :

Code:

Goto suite;
Ton code;
Suite:;

Voilà, simple !

et oui je suis degouté, depuis ma version en html5 j'ai pollué mon code de mes variables manouches "gotou" alors que le goto existe toujours.....
car on me disais que le gotou ne se faisait pas en C....
pas grave, ça marche quand meme. mais le gotou me manque parfois.
c'est bon a savoir qu'en cas d'urgence, je peux quand meme l'utiliser

Ahah !! Dommage copain !!

De toute manière, sache qu'en assembleur, on utilise BEAUCOUP l'équivalent du goto (Bra, JSR, JMP, etc ...) donc aucun complexe à l'utiliser !! J'ai déjà mis UN goto dans mon code ... 

F.L a écrit:car on me disais que le gotou ne se faisait pas en C....

Oui, ça ne se fait pas... Mais oui, ça existe. 

goto or not goto, telle est la question

petite update du jour (ou plutot de la nuit)
- j'ai resolu le petit clignotement de palette souligné par ichigobankai
ensuite j'ai rajouté les petits sprites :
- les taches de sang
- le feu du sorcier
- les tetes volantes
pour celle-ci, c'est pas encore bien fini, il manque leur ombre et à fignoler leur passage derriere les arbres, mais elles ont là.
j'espere pouvoir finir ça avant noel.
ensuite il ne manquera plus qu'a faire les priorités de sprites , créer la police, afficher les scores ,les serpents et les messages de fin de partie et ça sera la derniere ligne droite : les sons et la musique
y'a encore du boulot 

Disons que GOTO est l'instruction du saut inconditionnel directement hérité du language machine... Il est généralement utilisé dans les languages primitifs pour réaliser des boucles, ou dans des programmes mal structurés par les programmeurs. Cette instruction rend le code souvant peut lisible, parfois imprévisible, et donc dificilement maintenable. L'abus de GOTO est souvant lié à une méconnaissance du language utilisé (en BASIC à la place de GOSUB par exemple), plus qu'à un soucis d'optimisation. 
Déjà en 1970 on remettait en cause son existence... Aujourd'hui, les languages modernes n'ont plus cette instruction. Amen.

@FL,
Il te manque aussi, les 6 autres arènes, le bonus stage, le vrai boss de fin, le perso caché... oups je confonds, ca c'est dans ma version

sinon pour les fameux goto en C, si ton code est bien architecturé tu peux t'en passer facilement.
Juste faire attention aux variables locales (qui ne seront plus accessibles après le saut) si tu l'utilises.
Perso y'en a aucun dans mon code.

Vétéa dans ton exemple tu as du oublié la condition du Goto, sinon "ton code" ne sera jamais executé ^^

if(x) Goto suite;
Ton code;
Suite:;

Je ne veux pas plus polluer le topic de mon copain avec ça ! Mais si si, mon code fonctionne sans condition. Dans mon cas, c'est pour zapper des portions de code justement sans condition, quand j'ai besoin de faire des tests ...
Sinon oui Goto c'est mal, mais a nos niveaux on s'en fout un peu ...

Juste faire attention aux variables locales (qui ne seront plus accessibles après le saut) si tu l'utilises.
Perso y'en a aucun dans mon code.

Oui vaut mieux avoir 3/4 variables globales qui serviront de variables temporaires ou locales .