Re: [Megadrive] Conversion d'Alex kidd in miracle world

[oofwill]

Ah ah!

Basic = kikoolol?

C'est surtout que mes travaux à la maison ont bien avancé, et j'ai vraiment envie de me remettre au coding

Je relève le défi tiens :p

Il y a quoi en basic? SMS Brawl? Barbarian?

[oofwill]

Le travail du jour:

- Nouveau vêtements
- Nouvelle animation quand Alex attend
- Les débris lorsqu'on casse un bloc
- Alex peut prendre un item avec sa main
- Alex peut désormais mourir et monte au ciel ^^



Les vidéos enregistrées avec Fusion ne sont pas terribles, mais je n'ai pas trouvé mieux en gratuit. Des idées?

[pckid]

C'est super , bravo à toi ! tu es sur la bonne voie,

Tu penses que l'on pourra mettre des Boss, à combattre et non en mode chifoumi ?

[oofwill]

Il y a déjà des boss de prévu oui

Par exemple, sans trop spoiler:


Il y aura un mix. Certains boss se battront de manière classique, d'autres demanderont de gagner le janken contre eux avant de pouvoir les affronter. ^^

travail du jour: Pour la première partie de ce premier niveau, j'ai ajouté la possibilité d'utiliser l'onde de choc, ainsi que l'apparition et l'attaque du fantôme lorsqu'on casse un bloc mystère.

[pckid]

Super très bonnes idées !

Si tu veux des idées tu peux regarder pckid 3, il peut devenir énorme pour défoncer des ennemis,
très petit pour les passage secret. Jouer à deux, Voler avec la fleur, aller sous l'eau. glisser sur la glace. Pleins de points commun avec un Alex Kidd à jour.

https://www.dailymotion.com/video/x5l105_nec-pc-engine-1987-pc-kid-3_videogames

[oofwill]

Je ne connaissais PCkid que de nom, mais il a l'air bien sympa!!

Je prendrai peut être quelques idées ^^

[cammalleri]

c'est moi ou il plonge tête en avant sur les ennemis ?   
super boulot oofwill continues 

[pckid]

Super,

Sega avec alex kidd, ils auraient pu le faire vivre comme mario, avec des modes 4 joueurs,
faire évoluer le personnage, si nintendo vit avec mario, je ne vois pas pourquoi sega n'y arriverait pas.

[oofwill]

Bon, j'ai des petits problèmes de ralentissement.

Bon, en fait, j'ai de GROS problèmes de ralentissement. Dès qu'il y a 5 ou 6 sprites à l'écran, la consol eest à genoux. Blast processing mon oeil

Blague à part, je pense que mon code est pourri, mais si certains programmeurs chevronnés pouvaient me donner des tuyaux...

[Invité]

Bon, j'ai des petits problèmes de ralentissement.

Bon, en fait, j'ai de GROS problèmes de ralentissement. Dès qu'il y a 5 ou 6 sprites à l'écran, la consol eest à genoux. Blast processing mon oeil

Blague à part, je pense que mon code est pourri, mais si certains programmeurs chevronnés pouvaient me donner des tuyaux...

Mario peut-être ... ok je sors 

[pckid]

C'est quoi ton editeur ? pour developper ?

[oofwill]

SGDK de stef. J'ai utilisé le sprite engine qu'il a inclus il y a quelques temps et je pense que c'est ce qui me cause problème. Je l'utilise peut être mal.

J'avais fait une version il y a quelques mois avec mon propre moteur (mais un truc archaïque et chiant à mettre en place) et j'avais zéro ralentissements...




Du coup je vais essayer de demander à Stef si j'ai fait un truc qui pourrait ralentir le processus. Et sinon je referait le tout à ma sauce mais le problème c'est que j'ai quelques haures à passer pour refaire toute la gestion des sprites...

Bon, j'ai des petits problèmes de ralentissement.

Bon, en fait, j'ai de GROS problèmes de ralentissement. Dès qu'il y a 5 ou 6 sprites à l'écran, la consol eest à genoux. Blast processing mon oeil

Blague à part, je pense que mon code est pourri, mais si certains programmeurs chevronnés pouvaient me donner des tuyaux...

Mario peut-être ... ok je sors 

[pckid]

Est ce que tu aurais changer le saut comme tu l'avais dit plus haut ? car il faudrait le laisser comme au debut.

[oofwill]

De quoi parles tu?

Je n'ai rien changé sur le saut récemment.

[oofwill]

Bon, je pense avoir saisi.

Quand je veux changer ou faire apparaitre des sprites, je les initialise.
Je pense que je devrais plutôt les initialiser une fois pour toutes et ne changer que les attributs en cours de jeu.

Je vais tenter de modifier cela ce soir ^^

[philip]

J'utilise aussi sgdk, avec la vieille méthode bas niveau pour les sprites, et la nouvelle pour les tiles des deux scrolls.

 Si tu utilise beaucoup de boucle for ou while, le 68000 risque de patiner. De plus le 68000 de la MD est sous cadencé avec ses 7,67 MHz, beaucoup de jeux subissent des ralentissements avec beaucoup de sprites à l'écran.

[oofwill]

Je vais reprendre ma vieille méthode aussi. Le sprite engine n'est pas encore très optimisé d'après ce que dit Stef.
Et mon code l'est encore moins lol

Par contre, j'utilise quelques boucles for() oui, mais comment puis-je faire autrement?

[pckid]

Mince je suis pas encore à votre niveau les gars, cela me fait peur,

Vous parlez bien de tiles et de la map ou uniquement les sprites ?

car si c'est uniquement l'affichage des sprites, quelle fonction est touchée par un ralentissement ?

[oofwill]

En fait, le sprite engine peut visiblement gérer les sprites, bientot les maps, et les images fixes.

Pour les images fixes, ce peut être intéressant puisque cela ne demande pas beaucoup de ressources, donc tu peux t'y tester les yeux fermés.

Pour les sprites, ça dépend du nombre, un jeu tout simple peut tourner largement avec je pense.
Mais le mieux est de développer son propre moteur graphique à mon avis.

C'est pas hyper compliqué au fond ^^

De mon coté c'est la gestion des sprites qui me fait ralentir, mais je pense que c'est aussi parce que mon code est loin d'être optimisé.

[philip]

J'utilise des listes chaînées, pour tester le comportement de plusieurs objets, je ne vois pas d'autres solutions que les boucles. Pour éviter les ralentissements, pour moi la solution est hardware, avec dans la cartouche de jeu un 68000 à 15,34mhz..

[oofwill]

Désolé si ma question parait stupide, mais c'est quoi une liste chaînée?
Ca se présente comment?

[philip]

Désolé si ma question parait stupide, mais c'est quoi une liste chaînée?
Ca se présente comment?

A placer le code ci-dessous avant int main()

#define MAXBADGUY 8 // 8 sprites pour les ennemis du jeu.
typedef struct
{
    u16 bgid;    // id comme identité
    u16 bget;    // et comme étape
    s16 bgx;
    s16 bgy;
    u16 bghauteur;
    u16 bglargeur;
    u16 bganim;
    u16 bgaie;
    u16 bgtempo1;
    u16 bgtempo2;
    u16 bgtempo3;
} badguy_;
badguy_ badguys[MAXBADGUY];



Après int main( ) tu met la variable qui fera offfice de compteur :
u16 compta;



Et après dans la boucle principale :

for(compta=0; compta < MAXBADGUY; compta++) // 0 à 7
{
if (badguys[compta].bgid == 1)    // identité ennemi numéro 1
    {
    if (badguys[compta].bget == 0)    // état 0, initialisation : on place son objet à l'écran
        {
        badguys[compta].bget = 1;
        badguys[compta].bgx = 10;   
        badguys[compta].bgy = 10;   
        }
    if (badguys[compta].bget == 1)    // action !
        {
        badguys[compta].bgx += 1;   
        }
    }
}



Et enfin tu récupère les variables bgx et bgy pour tes sprites :

monspritebg1.posx=badguys[0].bgx;monspritebg1.posy=badguys[0].bgy;VDP_setSpriteP(20, &monspritebg1);
monspritebg2.posx=badguys[1].bgx;monspritebg2.posy=badguys[1].bgy;VDP_setSpriteP(21, &monspritebg2);
monspritebg3.posx=badguys[2].bgx;monspritebg3.posy=badguys[2].bgy;VDP_setSpriteP(22, &monspritebg3);
monspritebg4.posx=badguys[3].bgx;monspritebg4.posy=badguys[3].bgy;VDP_setSpriteP(23, &monspritebg4);
monspritebg5.posx=badguys[4].bgx;monspritebg5.posy=badguys[4].bgy;VDP_setSpriteP(24, &monspritebg5);
monspritebg6.posx=badguys[5].bgx;monspritebg6.posy=badguys[5].bgy;VDP_setSpriteP(25, &monspritebg6);
monspritebg7.posx=badguys[6].bgx;monspritebg7.posy=badguys[6].bgy;VDP_setSpriteP(26, &monspritebg7);
monspritebg8.posx=badguys[7].bgx;monspritebg8.posy=badguys[7].bgy;VDP_setSpriteP(27, &monspritebg8);



Et voilà, c'est fait.

[oofwill]

Ah ok, bah c'est exactement comme ça que je fais

Mais ça fait une boucle for() dans tous les cas pour la gestion des sprites :)

Mais c'est trop sympa de prendre un peu de temps pour m'expliquer :)
J'ai bossé sur l'écran titre et pas du tout sur les sprites hier. Je vais essayer d'avancer un peu ce weekend

[pckid]

Je suis content de trouver un fan d'alex kidd, il va etre venger sur la megadrive,

par ce que Enchanted castle , les sprites et le gameplay sont pas au top du tout !

[philip]

Ah ok, bah c'est exactement comme ça que je fais

Mais ça fait une boucle for() dans tous les cas pour la gestion des sprites :)

Mais c'est trop sympa de prendre un peu de temps pour m'expliquer :)
J'ai bossé sur l'écran titre et pas du tout sur les sprites hier. Je vais essayer d'avancer un peu ce weekend

Avec plaisir, et oui, une boucle for() pour les sprites, et une autre boucle for() pour les tiles d'un scroll (pour les objets du jeu qui sont immobiles), et bon courage pour la gestion des sprites. 

[oofwill]

Merci
J'espère fournir la première partie du niveau  jouable d'ici la fin de la semaine, faut que je bosse dur ^^

Je suis en plein dans la gestion des sprites justement. Question:

Vaut-il mieux que j'initialise mon sprite une fois pour toutes et que je change les tiles à la volée pour faire l'animation (utilise moins de mémoire vidéo) ou plutôt que je charge en VRAM chaque étape de l'animation et que j'initialise mon sprite à chaque fois que c'est nécessaire (plus gourmand en VRAM mais plus rapide??)?

à l'origine je faisais du changement de tiles à la volée, mais je ne sais pas si c'est la meilleur méthode...

[Invité]

Salut oofwil,
Message d'encouragement pour cette conversion qui est d'excellente facture.
Je rencontre tout comme toi, quelques soucis de ralentissements avec un nombre conséquent de sprite ( > 15 ) mais bon, ça reste jouable .. Et puis on est pas des pros, on fait ce que l'on peut.
Ce qui me rassure, c'est que même en asm, c'est pareil pour les autres ( enfin pas les pros bien sur ! )
Personnellement, j'utilise souvent des tempos pour le traitement de certaine fonction gourmande ( hitbox, etc ... ) 
Bon, j'utilise BEX qui est très différent de Sgdk, mais le principe reste le même, c'est de la prog. !
Allez courage, on se motive entre homebrewer Français !!
A bientot !

[vingazole]

Je suis en plein dans la gestion des sprites justement. Question:

Vaut-il mieux que j'initialise mon sprite une fois pour toutes et que je change les tiles à la volée pour faire l'animation (utilise moins de mémoire vidéo) ou plutôt que je charge en VRAM chaque étape de l'animation et que j'initialise mon sprite à chaque fois que c'est nécessaire (plus gourmand en VRAM mais plus rapide??)?

à l'origine je faisais du changement de tiles à la volée, mais je ne sais pas si c'est la meilleur méthode...

Ce qu'on fait généralement sur Master System (c'est le cas dans Alex Kidd in Miracle World, par exemple^^) c'est un mix des deux : les données graphiques des tiles du joueur sont rechargées à la volée (économie de VRAM permettant d'avoir plus de frames d'animation) alors que les tiles de toutes les frames d'animation des ennemis/autres objets sont chargées une fois pour toutes et on affiche les sprites en sélectionnant les tiles voulues (beaucoup plus rapide, surtout si on a plusieurs instances des mêmes objets présentes à l'écran), sans quoi on arrive assez rapidement à dépasser le VBlank, d'où des glitches graphiques et/ou la chute du framerate.

Maintenant est-ce que c'est pertinent sur Megadrive, je ne sais pas

[oofwill]

Merci Vetea!

Clair que ça fait plaisir de voir des projets sur MD, ça motive en fait.
Tu avances super vite, j'avoue que je n'avance pas aussi vite (mais j'ai pas trop le temps en ce moment je l'avoue...)

Je ne connais pas du tout BEX, je programmais en basic sur ma calculatrice à l'époque ^^
Mais il a l'air assez bien fichu, quand je vois le résultat sur Papi commando!!

Vingazole: merci pour tes  conseils!
En fait, j'ai commencé ce soir à récrire toute la gestion, et c'est chiant quand tu as déjà mis pas mal de choses en place!
Mais bon, voilà ou j'en suis: j'ai géré le sprite Alex de la façon suivante, je charge toutes les anims en VRAM, puis je choisis en fonction du besoin la frame qui va bien.
Je pense faire pareil pour les ennemis. Je ne vais pas économiser de VRAM; mais graphiquement le jeu est simple, les décors sont répétitifs et les animations simples également. Je pense que ça va convenir comme ça.

Actuellement, j'ai pu réécrire la gestion d'Alex uniquement. Il court, saute, donne un coup de poing, et meurt. me reste à animer les blocs qui sont détruits, l'onde de choc si Alex est équipé et les ennemis.
ça devrait aller assez vite maintenant. J'avoue que j'ai hâte parce que concrètement, jusqu'à maintenant, je n'ai jamais finalisé un niveau jouable à 100%, j'aimerais au moins faire ça dans la semaine :)

[oofwill]

OK  

La gestion des sprites à été entièrement réécrite!
Pour le moment pas de collision, mais les ennemis apparaissent correctement, sont animés, se déplacent en tenant compte du décor et surtout, SURTOUT, sans ralentissement!!
J'ai corrigé pas mal de bugs et autres glitchs par la même occasion.

Le jeu présente maintenant un écran titre. Il n'est pas définitif car il manque Alex dessus, mais ça donne déjà une bonne idée du rendu!

Comme on peut le voir sur la page juste après l'écran titre, il sera possible de reprendre la partie sauvegardée. Je compte mettre en place un système de checkpoint avec save automatique à chaque fin de niveau. On pourra ainsi reprendre sa partie un peu plus tard (souvenez vous des parties commencées le matin en attendant le bus et qu'on n'avait pas le temps de finir )

Bref, je suis plutôt content de l'avancée de ce soir:


PS: passez en 480P, vous aurez le rendu normal, parce que franchement, la conversion Youtube en 360P est dégueulasse...

[philip]

Je ne pense pas que les transferts des images en ROM vers la vram provoque des ralentissements. Bfg utilise aussi la méthode bas niveau pour les sprites, 
struct genresSprites
CODE:

Code:

struct genresSprites
{
    u16 *pal; //pointer to pal data
    u32 **sprites; //pointer to sprites data
    u16 count; //nb sprites
    u16 width; //width of each sprite in pixels (not tiles!)
    u16 height; //height of each sprite in pixels (not tiles!)
    u16 size; //since we use width/height in pixel, useful info on sprite size
    //TODO : size is not SGDK compliant, you need to use size>>8
    // will be fixed in coming release

};
Son message avec le code, là :

https://www.gamopat-forum.com/t75587-sgdk-sega-megadrive-sprite#1946991