Re: Sgdk - Sega Megadrive / Genesis Development Kit

[fanoplusplus64K]

Dans tous les cas le coup minimum sera une multiplication au moment de calculer le vecteur, ça reste raisonnable pour un 68k tout de même.

[Invité]

@Tryphon merci, c'est un peu complexe, mais j'ai compris l'essentiel. Pas grave pour la précision, c'est juste pour forcer le joueur à éviter un peu les boules ^^

Après je doute lancer pleins de boules dans la direction du joueur si c'est gourmand. Une ou deux grand max serra suffisante.

[TotOOntHeMooN]

Après, fano te propose une solution plutôt intéressante...

[Tryphon]

J'avoue que je suis pas sûr d'avoir exactement compris sa solution.

[Invité]

Faudrait déjà que dans un premier temps j'arrive à faire celle de @Tryphon ^^

[vingazole]

Y aurait pas moyen d'utiliser l'algorithme de Bresenham pour les lignes droites ? 

[Tryphon]

Il ne se fait pas à vitesse constante.

[fanoplusplus64K]

Désolé si mon propos était pas compréhensible, j'étais au taf sur le téléphone.
Une idée vite fait, qui donne une bonne approximation sur 8 bits, avec des vecteurs en 8.8.
Soit dX,dY qui est le vecteur sur 32 bits en 16.16.
Si dX>dY  le vecteur en X sera de 1 et le vecteur en Y sera de dY/dX , la partie haute des 16 bits sera de 0 et la partie basse sera la partie fractionnaire, si dY>dX ça sera alors dX/dY.
Ensuite , reste juste qu'à multiplier le vecteur en procédant à une simple addition à lui même.
Pour finir, les coordonnées du projectile sont évidemment en 32 bits 16.16 mais tu n'utilises que la partie haute pour l'affichage.
C'est moins précis qu'une normalisation mais c'est assez efficace et surtout rapide puisqu'il n'y a qu'une seule division (qui peut être ramenée à une multiplication dans le cas du Z80)

[vingazole]

Il ne se fait pas à vitesse constante.

Bah si : un pixel / itération.

[Tryphon]

un pixel par itération sur une diagonale, ça va 1.414 fois plus vite qu'un pixel sur une horizontale. C'est sensible (41% plus rapide)

[Tryphon]

Désolé si mon propos était pas compréhensible, j'étais au taf sur le téléphone.
Une idée vite fait, qui donne une bonne approximation sur 8 bits, avec des vecteurs en 8.8.
Soit dX,dY qui est le vecteur sur 32 bits en 16.16.
Si dX>dY  le vecteur en X sera de 1 et le vecteur en Y sera de dY/dX , la partie haute des 16 bits sera de 0 et la partie basse sera la partie fractionnaire, si dY>dX ça sera alors dX/dY.
Ensuite , reste juste qu'à multiplier le vecteur en procédant à une simple addition à lui même.
Pour finir, les coordonnées du projectile sont évidemment en 32 bits 16.16 mais tu n'utilises que la partie haute pour l'affichage.
C'est moins précis qu'une normalisation mais c'est assez efficace et surtout rapide puisqu'il n'y a qu'une seule division (qui peut être ramenée à une multiplication dans le cas du Z80)

C'est justement l'algorithme de Bresenham, si je ne m'abuse ?

[fanoplusplus64K]

C'est justement l'algorithme de Bresenham, si je ne m'abuse ?

Content d'avoir réinventé la roue pour le coup

[Tryphon]

Avec upsilandre y'a pas longtemps on s'est "battu" pour savoir qui allait le plus vite entre faire une table pour des arctangentes et une autre pour des renormalisations, avant de se rendre compte que c'étaient exactement les mêmes et qu'on avait démontré les égalités sin(arctan t) = x/racine(1 + x^2) et cos(arctan t) = 1/racine(1 + x^2)... que tous les étudiants qui ont vu l'arctan ont déjà démontré au moins une fois...

Cela dit, pour Shingo, c'est peut-être suffisant comme algo, si le pb de la vitesse variable selon la direction ne le gêne pas...

[vingazole]

Désolé si mon propos était pas compréhensible, j'étais au taf sur le téléphone.
Une idée vite fait, qui donne une bonne approximation sur 8 bits, avec des vecteurs en 8.8.
Soit dX,dY qui est le vecteur sur 32 bits en 16.16.
Si dX>dY  le vecteur en X sera de 1 et le vecteur en Y sera de dY/dX , la partie haute des 16 bits sera de 0 et la partie basse sera la partie fractionnaire, si dY>dX ça sera alors dX/dY.
Ensuite , reste juste qu'à multiplier le vecteur en procédant à une simple addition à lui même.
Pour finir, les coordonnées du projectile sont évidemment en 32 bits 16.16 mais tu n'utilises que la partie haute pour l'affichage.
C'est moins précis qu'une normalisation mais c'est assez efficace et surtout rapide puisqu'il n'y a qu'une seule division (qui peut être ramenée à une multiplication dans le cas du Z80)

C'est justement l'algorithme de Bresenham, si je ne m'abuse ?

Non l'intérêt de Bresenham c'est de ne pas faire de division (juste un décalage à droite pour la division par 2) : http://rosettacode.org/wiki/Bitmap/Bresenham%27s_line_algorithm#C

[Tryphon]

Oui, c'est vrai, j'oubliais l'astuce.

Mais tu as quand même le problème que sur une droite à 45°, tu vas sensiblement plus vite que sur une droite horizontale ou verticale.

Cela dit, on doit pouvoir incorporer à l'algo un terme "distance parcourue en pixels" qu'on incrémente à chaque itération. Trop crevé ce soir, mais j'y réfléchirai demain.

[Tryphon]

Mal dormi, mais j'ai quand même l'impression que rajouter une variable qui compte la longueur parcourue (en tenant compte que si on bouge x et y, on l'augmente de 1.414 et pas simplement 1) n'est pas si efficace :

* on continue à avoir des erreurs de calcul de longueur (même si elles sont beaucoup plus faibles : de l'ordre de 8%, pour des angles proches de 26,5° avec l'horizontale ou la verticale)

* il faut itérer plusieurs fois l'algo sur une frame (jusqu'à ce que le compteur de longueur dépasse la valeur de vitesse souhaitée), ce qui fait que c'est plus long que de rajouter directement de dx, dy calculé par normalisation

Bref, le calcul initial est beaucoup plus court, mais les calculs à chaque MAJ sont un peu plus longs.

Par contre, gros avantage : ça ne nécessite pas de table !

[Invité]

si tu utilises le driver XGM, alors tu peux passer le timing à 50 de force et ça devrait jouer à la bonne vitesse sur une machine PAL et NTSC , mais là encore il faut que tu sois à jour dans les versions de SGDK et driver XGM...

a partir de quelle version ca marche?

[Invité]

Salut, j'ai un mal de crâne pas possible, mais bon à force de bloquer trois jours sur un bug à la con... et le pire c'est de ma faute !

En fait, j'avais remarqué que c'était le bordel total dans les animations des explosions et le problème c'était parce que j'avais défini l'index du sprite dans la VRAM. Hors, quand on pointe tous les sprites vers un index, dès que la frame est modifié, c'est tous les sprites qui sont affectés !

Du coup, je dois laisser le Sprite Engine allouer automatiquement l'index dans la VRAM.

Je voulais juste savoir, n'est-il pas possible d'avoir un seul sprite indexé dans la VRAM et de mettre à jour les frames des sprites sans que cela affecte les autres ?

Si c'est non, cela rajoute une contrainte supplémentaire, mais bon vu la place dans la VRAM, ça ne devrait pas être trop méchant.

Du coup, je pense que le mieux c'est de laisser le Sprite Engine faire ses affaires...

[Invité]

Faut laisser le SE tout gérer.
C'est ce que j'ai fait pour Papi Reload, et crois moi, il y a beaucoup plus de choses en vRAM et à gérer que ta Démo.
Stef l'a bien remanié et ça fonctionne nickel.
Après si tu utilises des pointeurs, faut faire attention avec ... Sous peine de crasher la console. ^^

[Invité]

Ça marche, je vais laisse le SE faire son taff. En tout cas je suis content tout fonctionne au poil de cul :)

[Invité]

@Stef tu penses intégrer un jour un support pour développer aussi sur Mega CD ?

[Stef]

C'est quelque chose que j'avais prévu il y a longtemps mais je dois admettre l'avoir un peu mis de côté / oublié :p
Ajouter le support de Mega CD n'est pas si difficile (au moins la construction de l'iso), c'est le même CPU que la MD, par contre là où c'est plus de travail c'est ajouter les fonctions qui permettent d'utiliser facilement les capacités du Mega-CD dans SGDK (lecture des pistes audio, transfert des données en RAM, utilisation du chip vectorielle...).. et surtout que ça ne va intéresser qu'une très faible partie des utilisateurs de SGDK (beaucoup n'ont pas de Mega-CD).
Je sais que quelqu'un avait déjà bricolé avec SGDK pour pouvoir développer sur Mega CD mais je n'arrive pas à remettre la main sur le topic en question (sur SpritesMind)

[Stef]

Ça marche, je vais laisse le SE faire son taff. En tout cas je suis content tout fonctionne au poil de cul :)

Ca fonctionne en effet, mais il faut bien voir que SGDK fait de l'allocation dynamique pour tout tes objets (ce qui consomme pas mal de RAM et un peu de temps CPU sur la creation de l'objet) et dans un soucis d'optimisation, je pense qu'à terme tu devras switcher sur une allocation et gestion manuelle de certains sprites qui partagent les mêmes spritesheet, en gros l'idée c'est de précharger en VRAM toutes les données graphiques (tout les tiles des explosions par exemple) et ensuite de faire pointer le sprite sur le bon VRAM index selon la frame à afficher (et bien sur de désactiver l'upload automatique en VRAM pour ce sprite).
Bon pour le moment tu en as pas encore besoin mais plus tard ça te permettra d'optimiser l'usage de la VRAM, réduire la quantité de data à transférer par frame, moins de traitement CPU...

[Invité]

Pour le Mega CD, tu parles de ce topic peut-être ? http://gendev.spritesmind.net/forum/viewtopic.php?t=2138

C'est vrai que ce n'est pas une feature essentielle qui sera utilisé de beaucoup, mais je trouve ça vraiment bien de pouvoir développer sur Mega CD d'autant plus qu'on peut bénéficier de plus de puissance et d'une grande capacité de stockage en plus des pistes audio !

Après voilà en tant que passionné, je te dirais que se sera vraiment super d'ajouter les fonctions permettant de bosser sur le Mega CD même si sortir un jeu sur cet addon serait vraiment rare.

En tout cas si demain le SGDK supporterais le Mega CD, il est certain que mon projet projet sera sur cette plateforme.

[Stef]

Non ce n'est pas ce topic hélas.. il y avait eu un sujet plus ancien mais beaucoup plus interessant où une personne avait vraiment fait des modifications dans SGDK pour supporter le compilation d'un ISO.

Mais bon déjà cette partie là nécessiterait quand même pas mal de travail et ensuite supporter les fonctions du Mega CD c'est encore beaucoup de boulot... bon clairement vu que je n'arrive déjà pas à faire ce que je souhaite sur la partie MD (il y a encore plein de choses que je veux faire) la partie Mega-CD n'est pas ma priorité pour l'instant...

Et si ton projet va sur le Mega-CD alors seulement 5% des 100 personnes potentiellement interessés par ton projet initial sur MD seront toujours interessés
J'exagère un peu mais c'est l'idée, déjà en développant sur MD tu captes peu de monde et ça sera encore moins sur Mega-CD (et je ne parle même pas du 32X ). Le seul avantage du Mega-CD est la production de CD qui est plus simple que la production de cartouche.

[Invité]

Hier j'ai voulu régler quelques soucis dû à la réinitialisation du niveau, mais ça plante avant que les sprites ne s'affichent plus.

Normalement, quand un on fait un SPR_releaseSprite(Sprite*), il est retiré de la VRAM ? J'ai l'impression que ça plante, car les sprites sont toujours chargés et donc forcément quand je fais un SPR_addSprite() bah ça ne marche pas.

Ce que je voudrais faire, c'est que lorsque je retourne au menu après un Game Over, c'est de nettoyer la VRAM puis de réinitialiser le niveau au début d'une nouvelle partie.

[Invité]

Mauvaise méthode ! J'ai un peu la doc et voilà ce que j'ai fais comme fonction pour effacer les sprites :

Code:

void stageClear() {
    SYS_disableInts();
    VDP_fadeOut(0, (16*4)-1, 20, TRUE);
    VDP_resetScreen();
    XGM_stopPlay();
    SPR_clear();
    SPR_reset();
    SYS_enableInts();
    cleared = TRUE;

    KDebug_Alert("Stage was cleared");
}

[Stef]

Ça m'a l'air plutôt pas mal ;-)
Ça ne fonctionne pas ?

[Invité]

Sisi ça marche :)

Je voulais partager ce bout de code au cas où quelqu'un aurait rencontré le même soucis ou voudrait un exemple de comment "effacer" un niveau.

Je suis en train de m'interroger sur comment gérer les ennemis. Jusqu'à présent j'utilisais un fonction assez simple pour générer des ennemis, mais j'aimerais vraiment pouvoir contrôler le comportement de chaque ennemi plutôt que de le faire génériquement.

[Tryphon]

Gérer la gestion ?

Je ne comprends pas ton problème. Peux-tu être plus précis ?

[Invité]

XD c'est tout moi. Je pense que je n'aurais pas le choix, je devrais définir le comportement des ennemis un à un. L'idéal serait que je me développe un petit outil qui me permettrait de tester et générér le comportement des ennemis si je veux mettre en place des vagues travaillé. Au boulot !!!!