Necstasy

salut tout le monde
depuis quelques jours je suis en train d'adapter mon remake de barbarian (le jeu de 1987 de palace software) avec HUC sur la pcengine.
la chose n'est pas simple, je decouvre un nouveau langage le C, et en plus une nouvelle machine....
TOUKO m'avais envoyé qq exemple de code et j'ai été convaincu, que ce soit par la simplicité du langage et les perfs de la machine
mon 1er remake de barbarian de 2012 avait été fait en basic sur pc (qb64) puis sur megadrive (bex) et depuis j'ai reussi à convertir le listing en C, via un petit passage par du html5 pour que la transition ne soit pas brutale
le moteur de jeu tourne impeccable en C sur un pc avec la sdl, et là je suis en train de l'adapter à la console.
j'ai reussi à bien decouper mon code en fonctions de moins de 8ko et ça tourne. pour l'instant, le moteur n'affiche que le decor et qq sprites, mais je suis assez confiant pour la suite. ça risque d'etre long.pour le moment je n'ai pas encore decoupé mes sprites et tout affiché en meme temps pour voir si je ne vais pas atteindre le nombre maxi de tiles à l'ecran avec ma maiere d'afficher les sprites (qui sont gros quand meme)
voici une photo :

edit 21/03/2017 :
les 7 versions sont finis !
cliquez sur les images pour telecharger les roms :
AtariST
Amiga500
Amstrad CPC
Commodore 64
ZX Spectrum
Ibm-Pc
AppleII
etant novice et manquant cruellement de bases de programmation (j'ai appris sur le tas), j'ai pleins de questions et parfois sur des choses toutes betes, genre afficher une variable int à l'ecran.....j'ai des dizaines de questions comme ça
j'espere que le projet vous plaira et que vous prendrez du temps pour me repondre !!
@+

Oh chouette ! Un jeu mythique de ma première machine adapté sur PCE !
J'avoue ne pas encore avoir essayé ton adaptation sur Megadrive.

Question : tu comptes le faire en version carte ou CD ?

pour le moment je n'y ai meme pas pensé.
il y a tellement de boulot à faire dessus que je ne suis meme pas sur d'y arriver.
je suis d'un naturel prudent alors je ne veux pas mettre la charrue avant les boeufs !!

ps : j'ai mis les decors de la version cpc. si j'arrive à jouer correctement la musique du cpc, c'est cette version que je ferais !
sinon je me rabattrais sur la version appleII qui avait des sons très basiques, mais ça serait dommage

Vu que de toute façon les combats sont sur écran fixe, une cartouche suffira largement.

Cool, merci pour la rom et bon courage pour la suite.

Cool, ça avance bien, c'est génial .
si tu n'arrives pas à supprimer le petit glishe (même si j'ai du mal à voir où il est) n'hésites pas,ou même si tu as des question n'hésites pas,même si ça fait un bail que j'utilise plus huc .

Ps:génial les nouveaux émoticons .

touko a écrit :Cool, ça avance bien, c'est génial .
si tu n'arrives pas à supprimer le petit glishe (même si j'ai du mal à voir où il est) n'hésites pas,ou même si tu as des question n'hésites pas,même si ça fait un bail que j'utilise plus huc .

Ps:génial les nouveaux émoticons .

pour le glitche, quand le perso avance, il y a comme un clignotement du sprite sur les jambes du perso. c'est très rapide, ça doit se passer sur une frame
ce qui est bizarre,c'est que ce glitche n'est pas present quand le perso avance "sur place", seulement quand il avance

Je me doutait que c'était ça que tu prenais pour un glishe,fais avancer ton perso contre le second, et continue de marcher .
Le perso ne va plus avancer, mais l'anim de la marche va continuer, tu verras qu'il n'y a pas de glishes dans l'anim .
Je pense que ton soucis doit venir du positionnement des sprites .
Tu utilises combien de sprites / perso ??, car pour la marche un sprite de 32x64 suffit .

Pour les fonctions ça sert à rien de lancer la fonction du gnome si il n'y a pas mort avec tête coupée par exemple,et donc de déplacer la fonction qui est dans le main, au niveau de celle qui gère les morts(du coup ça rendra la main plus lisible) .

En général on ne met pas les fonctions d'intro(personnages qui arrivent/partent,init,etc ..) dans la boucle principale.

De plus n'hésites pas à déclarer en char, les variables qui n'ont pas besoins d'être supérieure à 256,c'est inutile, on est pas sur Md là ,et tu accéléreras le traitement, car huc va traiter les variables 16 bit en 2 passes, alors qu'il va le faire en 1 avec un char .
Ex:
int temp;
char var

temp=0;
var=0;

Huc va générer ce style de code ASM(en réalité c'est plus crad)
stz _temp
stz _temp + 1

stz _var

Si tu vois ce que je veux dire ,car ce serra ça à chaque traitement d'une variable,donc 2x plus de traitement souvent inutile .

oui je vois (en gros)
une grande partie de mes variables ne depassent pas les 256, cool. ça va acceller tout ça alors !

il y a 53 sprites à gerer rien que pour les barbares. quasiment tous rentrent dans une case de 48x64. je pense les decouper en 3 sprites de 16x64
car une bonne partie n'utilise que 32x64.
il y a juste deux animations (attaque au cou) et (attaque devant) ou il faudra un quatrieme sprite pour le bout de l'epee

au fait :
est ce que le 2eme joueur peut bouger ou pas ?
quelles sont les commandes pour le deuxieme joueur avec mednafen ? je trouve pas.
je ne sais pas pourquoi ,quand j'appye sur F2, qui normalement devrait configurer les commandes, rien ne se passe.....

une grande partie de mes variables ne depassent pas les 256, cool. ça va acceller tout ça alors !

Oui forcement, surtout qu'il en faut pas bcp à huc pour ramer

il y a 53 sprites à gerer rien que pour les barbares. quasiment tous rentrent dans une case de 48x64. je pense les decouper en 3 sprites de 16x64

Pk ne pas faire 32x64+16x64(ou moins) si besoin ??

Tant que ça clignote pas faut pas hésiter à utiliser les plus grandes tailles, ça fait moins de traitement à la fin .

est ce que le 2eme joueur peut bouger ou pas ?

j'ai pas testé, car ma config de mednafen utilise le pad numérique, et mon clavier de maison n'en a pas

quelles sont les commandes pour le deuxieme joueur avec mednafen ? je trouve pas.

tu peux les redéfinir, appuies sur F1 pour l'aide (je me souviens plus de la touche) .
Si tu utilises ma version, c'est les flêches du pad numérique pour les directions(normalement) .

hello
je profite d'avoir un rhume pour avancer le jeu,
meme si ça n'aide pas pour la concentration.. .
depuis hier j'ai mis un max de sprites à l'ecran pour tester :

je suis impressionné par la puissante de la console et/ou du langage !!
sur emulateur, rien ne clignote. quelqu'un pourrait me l'essayer sur une vraie console ?
ça serait sympa. voic le lien de la rom :
https://www.dropbox.com/s/s78m5g4l49yd5kc/15.c?dl=0
ceci represente le maximum d'affichage de sprites en meme temps pour le jeu,
si je ne me prends pas trop la tete à decouper mes sprites en plusieures petites parties. 2x(32x64) ,voir moins pour certains
si ça marche c'est cool, ça va m'eviter de longes soirée de decoupage.
de plus, dans le jeu les joueurs passent derrière les arbres. j'ai mis des sprites sur les cotés pour faire comme si les arbres etaient des sprites de 32x64. j'imagine qu'il y surement un moyen d'afficher des tiles par dessus les sprites, plutot que creer deux gros sprites comme ça, ce qui allegera un peu le jeu.
meme dans cette configuration là le moteur de jeu (pas optimisé) tourne, donc je suis de plus en plus optimiste dans la possibilité du jeu.
j'ai pas mal de questions :
- comment changer une couleur dans une palette ? (par exemple le torse jaune de mes sprites)
- comment afficher des tiles par dessus des sprites (si c'est possible)
merci d'avance et @+ pour la suite

Ca clignote pas non plus,car tu peux mettre 16 sprites 16x16 sur une même ligne .
Un sprite de 32 pixels de large compte pour 2 .
Sur ton écran tu as 6 sprites 32x64 donc 12 sprites de 16 pixesl de large + le gnome et les 2 taches de sang fait un total de 15 sprites de 16 pixels .
Tu peux en rajouter encore 1 de 16 pixels sans que ça clignote(sauf si le gnome est en 32 pixels,là tu es à la limite) .

PS: l'emulateur gère le clignotement, sauf si c'est désactivé dans la conf (pas par défaut) .

si je ne me prends pas trop la tete à decouper mes sprites en plusieures petites parties. 2x(32x64) ,voir moins pour certains

Etant donné que normalement tu devrais pas avoir tout ça en même temps, je pense que tu n'auras pas de soucis .

j'ai mis des sprites sur les cotés pour faire comme si les arbres etaient des sprites de 32x64. j'imagine qu'il y surement un moyen d'afficher des tiles par dessus les sprites, plutot que creer deux gros sprites comme ça, ce qui allegera un peu le jeu.

Non hélas, mais vu que c'est juste pour l'arrivée/départ des persos, rien ne t'empêche de les cacher quand ils ne sont pas utilisés .
spr_set(mon_sprite);
spr_hide();

comment changer une couleur dans une palette ? (par exemple le torse jaune de mes sprites)

set_color(int num_couleur, int couleur);

comment afficher des tiles par dessus des sprites (si c'est possible)

Pas possible, il faut utiliser des sprites de priorité supérieure .

je suis impressionné par la puissante de la console et/ou du langage !!

Pourtant le C n'est pas le point fort de ces CPU, et c'est encore plus surprenant quand tu sais à quel point Huc n'est pas optimisé .
Huc est un très bon outil pour débuter, pas très performant, mais ultra simple à utiliser .
Avec de l'expérience, tu peux vite arriver à contourner pas mal de ses faiblesses .

F.L a écrit : si je ne me prends pas trop la tete à decouper

Vu qu'on parle de Barbarian, cette phrase m'a fait sourire.

cool, bonne nouvelle
on peut dire que le projet est viable alors... manque plus qu'à le faire
tout à l'heure je me suis acheté une pcengine sur le coincoin, il ne me manque plus qu'un linker ou autre everdrive et je vais pouvoir admirer tout ça !
d'ailleurs si jamais vous avez un style d'everdrive à me conseiller ou à eviter, ça serait cool que vous me le disiez, je vais surement en acheter un dans la semaine.

@TOUKO : oui le sprite du gnome est en 32 aussi. j'ai un peu de marge quand meme car je peux utiliser le meme sprite pour la tache de sang , le feu du sorcier et la tete volante car ces 3 ont la meme taille et toujours presents sans les 2 autres.
pour les arbres , tant pis. sur megadrive j'avais fait pareil.
au fait, les deux persos bougent, ça marche.
par contre, la routine pour le pad n'accepte pas plusieures touches en meme temps. j'ai lu dans la doc qu'il faut utiliser get_joy_events(char num);
si jamais tu as un exemple, je prends car ce jeu demande parfois jusqu'à 6 touches enfoncées dans un meme loop

@warhol : bien vu. je ne l'avais meme pas vu venir celle-là ! tu as l'humour tranchant

Pour tester plusieurs touche il faut faire un ou :
If joy(0) == (JOY_STRT | JOY_A), un truc comme ca, j ai plus exactement les noms des boutons du pad en tête .

EDIT: ok c'est ça :

if(joy(0) == (JOY_STRT | JOY_A ))

Donc ça teste si tu appuies sur start et A/I en même temps .

le sprite du gnome est en 32 aussi

Donc avec ce que tu affiches tu es à la limite, 1 sprite de plus et ça clignote
Mais pour moi c'est un cas improbable (a moins de jouer à 4,tiens une idée pour un hyperbarbarian sur SGX ), donc pas de soucis .