Re: [ Demo Disponible !] - Papi Commando Tennis Megadrive - SGDK

[vincent2105]

Salut Vetea, whaou ça a bougé de ton coté ces dernières semaines !
T'as mis le basic au placard ??

[Invité]

Et oui !!
Le C a pris la relève !! :)

[ShiningBZH]

Papi déterminé à gagner

[Invité]

Bonsoir à tous,

Et bien ce soir je n'ai pas chômé après le boulot ... Tirage au sort du concours, et petite session codage !!
Et quelle session ... L'apparition de Papi sur le nouveau court sous les applaudissements du public ! 



J'ai codé un petit script qui prend la main du P1 lors de l'arrive sur le court. Le PAD est désactivé, tout est automatique.
Le Sprite Engine facilitant les séquences d'animation / déplacements d'une manière déconcertante ...
Par contre, question à Stef, est il possible de régler la vitesse d'animation initialement paramétré en ressource ?
Sinon, j'ai aussi géré la gestion du PAD pour le déplacement du P1 ( Diagonale inclue ) !
Que du bon !!

A bientôt.

[Stef]

Bonsoir à tous,

Et bien ce soir je n'ai pas chômé après le boulot ... Tirage au sort du concours, et petite session codage !!
Et quelle session ... L'apparition de Papi sur le nouveau court sous les applaudissements du public ! 



J'ai codé un petit script qui prend la main du P1 lors de l'arrive sur le court. Le PAD est désactivé, tout est automatique.
Le Sprite Engine facilitant les séquences d'animation / déplacements d'une manière déconcertante ...
Par contre, question à Stef, est il possible de régler la vitesse d'animation initialement paramétré en ressource ?
Sinon, j'ai aussi géré la gestion du PAD pour le déplacement du P1 ( Diagonale inclue ) !
Que du bon !!

A bientôt.

Excellent résultat

Pour répondre à ta question, tu peux mettre le paramètre "timer" à 0 quand tu déclares la ressource ainsi il n'y aura pas d'auto animation, ça sera à toi de gérer manuellement les animations (avec SPR_setFrame(..) ou SPR_nextFrame(..)).

Tu peux aussi modifier comme une brute la valeur de timer dans la structure Sprite directement :

Code:

Sprite* spr = SPR_addSprite(...);
...
// prochain changement d'animation dans 5 frames
spr->timer = 5;

Mais c'est un peu root et dans ce cas il faut le faire à chaque fois (par défaut quand le timer atteint 0 il est rechargé automatiquement avec la valeur contenu dans la ressource).

[Invité]

Super merci Stef !!
Bon du coup j'j'aurai d'autres questions :
1/ Avec rescomp et SPRITE, est ce que Sgdk permet de créer des spirites de plus de 32px ? Ou bien faut il les faire par blocs multiples ( meta sprite )
2/ J'aimerai une explication claire et nette sur le VBlank() et la manière dont cela est géré niveau code.
Ex:
While
..
..
Code 0
..
Code 1
..
Vblank()

Ce qui est avant est ytraité avant ?? Mais comment ?? A quelle ligne de synchro ?? Et le code après est il traité ??
C'est assez flou ...

[ichigobankai]

le vblank (ou plutot wait_vblank()) attend une ligne de scanline précise (224, 240 ou autre sur MD, vu que je ne code pas dessus, je ne saurais etre précis, pas compliqué c'est ta valeur de résolution verticale)

tant que le code situé au dessus ne dépasse par cette scanline, no soucy, 
si par contre ton code est trop gros/lourd et que ca dépasse cette limite ca attendra le vblank suivant (frame d'après)...et tu chuteras à 30fps (si tu étais en 60 à l'origine)

et oui le code traité avant y est avant (sinon ce serait complètement con ^^), comme je l'ai marqué à FL dans son topic PCE
il faut différencier le temps pendant le vbl et celui hors vbl.

pendant le vbl tu as un accès illimité à la machine, donc tu dois y faire les choses les plus lourdes (transferts de datas graphiques & cie) et pendant le temps affichage actif (hors vbl donc) le temps les calculs/préparation.

pour savoir quel code prend combien de temps, là par contre c'est bien plus hard, faut calculer les cycles...

[Invité]

Merci Ichigo, c'est un peu plus clair ...
En fait, il est difficile de maitriser cela autrement que par l'assembleur.
Mais ce qui m'intéressait surtout, c'est cette notion, dans la boucle principale, de traiter les calculs / affichage et comment les agencer au mieux.
Par expérience, je place toujours les routines d'affichage à la fin, juste avant Vblank(), les calculs plus lours, je les place au début.
Je ne sais pas si c'est la bonne méthode, mais avec mes autres projets, je faisais comme ça.

[Stef]

Pour les sprites, pas de soucis, tu peux mettre bien sur des sprites de plus de 32x32 pixels, c'est le sprite engine qui va gérer les meta sprites pour toi.
Pour l'histoire du vblank, de manière général on fait:

période active:
logique jeu, calcul collisions, préparation de la prochaine frame...

vblank:
Envoie des données graphiques en VRAM.

Avec SGDK, le mieux c'est même d'utiliser le callback V-Int pour faire les mises à jour en VRAM. Ou alors tu le fais dans la boucle principale mais il ne faut pas oublier de protéger chaque accés VRAM en désactivant les interruptions sinon tu peux avoir un conflit d'accés VDP (si l'interruption arrive au beau milieu de ton accès au VDP).

[Invité]

Génial ça Stef !!!
Très fort le Sprite Engine ... Quand je pense à Bex ... 

Quant à cette histoire de Vblank(), pas tout compris dans ton explication.

>> Avec SGDK, le mieux c'est même d'utiliser le callback V-Int pour faire les mises à jour en VRAM
Alors ce n'est pas VDP_waitVSync() qui s'en occupe ?! A moins que tu parles HORS boucle principale avant .. Bref, ça m'embrouille cette histoire ... 

>> Ou alors tu le fais dans la boucle principale mais il ne faut pas oublier de protéger chaque accés VRAM en désactivant les interruptions sinon tu peux avoir un conflit d'accés VDP (si l'interruption arrive au beau milieu de ton accès au VDP).
La je crois avoir (un peu) compris .. Avec les fonction SYS_enableInts() et SYS_disableInts().
Par contre, qu'appelles tu réellement les accès VRAM ?! Les fonctions qui permettent d'afficher un/ou plusieurs TILE à partir de la VRAM ? Les changements de Tile en VRAM via les fonction Haut/Bas niveaux ? L'affichage des sprites ?


Ce sont des concepts que j'utilise, mais sans vraiment les maitriser vraiment ... Pas taper. 

[Stef]

En fait dans SGDK (et dans BEX tu as aussi cette possibilité), tu peux définir une fonction qui sera appelée automatiquement lors de l'interruption verticale (elle arrive au moment où le vblank commence) :

Code:

SYS_setVIntCallback(vintEvent);

Ensuite il te suffit juste de définir cette fonction vintEvent :

Code:

void vintEvent()
{
   ...
}



Cette fonction vintEvent sera donc toujours appelée lors de l'interruption verticale (et donc interrompt l'execution de ta boucle principale d'ou les précautions à prendre), tu es sur d'être dans le vblank à son appel et donc dans la gestion du vblank de SGDK. Si tu gères tout tes accès VDP dans cette fonction tu as la garantie de ne jamais entrer en conflit avec "la gestion vblank" de SGDK (qui fait également des accès VDP pour les palettes fading ou les DMA queues).

Ce que je veux dire par accès VRAM / VDP c'est vraiment toutes les méthodes qui vont écrire dans le VDP, donc oui, tout les chargement de tiles en VRAM, les tilemaps, l'écriture de texte... pour la gestion des sprites, normalement le sprite engine est protégé donc tu n'as pas à t'en soucier.

Bien sur tu n'es pas du tout obligé d'utiliser ce vint callback et tout faire dans la boucle principale avec un appel à VDP_waitVSync() comme tu le fais actuellement si tout ça te semble obscure

[Tryphon]

Peut-être que j'enfonce des portes ouvertes mais déjà faut comprendre ce qu'est une interruption. Normalement, l'exécution d'un programme en langage machine (assembleur) est séquentielle : une instruction après l'autre.

Mais les composants autre que le CPU peuvent générer des interruptions, qui interrompent le fonctionnement normal du processeur. Quand une de ces interruptions arrivent, le processeur arrête l'exécution normale du programme et saute directement à un sous-programme spécifique. Quand celui-ci est terminé, le programme retourne à l'endroit où il avait été interrompu.

L'une de ces interruptions est le VInt, qui est provoqué par le BDP au moment du VBLANK (il y en a deux autres).

Wait_VSync() ne fait que mettre le programme en pause en attendant que le VInt se produise.

Le sous-programme spécifique du VInt est implémenté dans SGDK et fait des trucs en sous-marin comme gérer les accès DMA, gérer le driver XGM, peut-être mettre à jour la SAT (je suis pas sûr, Stef t'expliquera mieux que moi) et... éventuellement exécuter du code à toi, une fois qu'il aura fait tout son boulot (je crois que dans les evrsion récentes tu peux même insérer du code AVANT qu'il fasse son boulot) que tu peux préciser via SYS_setVintCallback.

Les accès VRAM c'est copier des tiles en VRAM (avec ou sans DMA), mettre à jour les tilemaps, ou la SAT.

[Invité]

Ca roule merci !
Les interruptions et tout le bazar, je connais. Mais en tant que créatif, je ne pense pas vraiment à tout ça quand je réalise et synthétise mes idées, mes ressources et tout le reste ... Bref, j'ai pas vraiment un fonctionnement de vrai codeur ... Pour moi, tant que ça marche, c'est l'essentiel.
Je suis surtout un petit mania de l'optimisation ...

En tout, merci de vos lumières, je suis sûr que ça en servira plus d'un(e) !

[Stef]

Peut-être que j'enfonce des portes ouvertes mais déjà faut comprendre ce qu'est une interruption. Normalement, l'exécution d'un programme en langage machine (assembleur) est séquentielle : une instruction après l'autre.

Mais les composants autre que le CPU peuvent générer des interruptions, qui interrompent le fonctionnement normal du processeur. Quand une de ces interruptions arrivent, le processeur arrête l'exécution normale du programme et saute directement à un sous-programme spécifique. Quand celui-ci est terminé, le programme retourne à l'endroit où il avait été interrompu.

L'une de ces interruptions est le VInt, qui est provoqué par le VDP au moment du VBLANK (il y en a deux autres).

Wait_VSync() ne fait que mettre le programme en pause en attendant que le VInt se produise.

Tu as tout à fait raison de rappeler ça, effectivement ce n'est pas une notion très simple à appréhender :)

Le sous-programme spécifique du VInt est implémenté dans SGDK et fait des trucs en sous-marin comme gérer les accès DMA, gérer le driver XGM, peut-être mettre à jour la SAT (je suis pas sûr, Stef t'expliquera mieux que moi) et... éventuellement exécuter du code à toi, une fois qu'il aura fait tout son boulot (je crois que dans les evrsion récentes tu peux même insérer du code AVANT qu'il fasse son boulot) que tu peux préciser via SYS_setVintCallback.

Je vois que tu es parfaitement au courant, il n'y a rien à rajouter et effectivement depuis la dernière version tu as un callback special pour être appelé avant que SGDK fasse son travail..

[Invité]

Bon, du coup je vais retravailler ma planche de sprite principale avec cette prise en compte des MetaSprites ... Car en 32x32 je trouvais mes joueurs beaucoup trop "compactés" ...

Pour ce qui est de ces notions, on verra ça en court de jeu et surtout, sur du vrai Hardware.

[Invité]

Ahhhhh ... presque 2h de graph pour juste une pauvre ligne de sprite ... 

Papi New:

Comme je l'avais dit, je voudrais des personnages un poil moins écrasé, un poil plus grand et plus fin ... A voir si le jeu en vaut la chandelle ... Les modèles d'origines sont déjà pas si mal .. Mais quand même j'aimerai essayer !
Bon du coup, ça fait reculer les sessions codages ! 

Et voila ce que cela donne à l'écran :



Ca me plait beaucoup plus comme ça !!

[Invité]

le processeur arrête l'exécution normale du programme et saute directement à un sous-programme spécifique

Petite précision, le CPU fini d'abord l'instruction en cours (c'est très important de savoir) .
Donc si tu utilises des div/mul par exemple l'interruption ne sera prise en compte qu'a la fin de l'instruction si elle est déjà commencée,donc avec un délai pouvant être important .

[Tryphon]

Dans quelles situations tu as besoin de ce détail ?

[Invité]

Dans quelles situations tu as besoin de ce détail ?

Dans le cas où tu utilises les div/mul par exemple (pour le calcul du score ou autre) .
Bien sur c'est dans le cas où tes interruptions doivent être plus ou moins précises .

C'est juste une précision à ton explication .

[Invité]

Bonsoir à tous,

Ce soir, j'ai bien avancé dans la refonte du Design du sprite de Papi.
Beaucoup moins pataud, et plus dans le style "Tennis" qu'auparavant.
J'ai aussi géré le Zorder entre le Sprite P1 et son décor ainsi que les autres sprites du court !
( Vous remarquerez aussi le mode statique du joueur fonction de sa coordonnée Y ...  )

La petite vidéo :




Il me reste les coups du tennis à faire ... Le plus long ! Mais une fois cette étape de faite, alors je pourrai les utiliser comme base pour les autres joueurs.

A bientôt !

[Stef]

Je trouve que le nouveau sprite est effectivement plus sportif, plus dynamique et mieux animé dans un sens. Après l'ancien chara design avait également son style, j'aime les 2

[Invité]

J'ai aussi géré le Zorder entre le Sprite P1 et son décor ainsi que les autres sprites du court ! 

Petit détail bien vu 

[Invité]

Merciii !!!

Techniquement et visuellement, ça commence à me plaire !! Beaucoup plus que l'ancien prototype.
J'ai hâte de recevoir mon Everdrive, et de tester ça sur ma toute nouvelle Megadrive II customisée par mon ami Uran.

[ShiningBZH]

Mais quel corps d'athlète ce Papi ! Tu as perdu ton ancien everdrive ??

[Invité]

Nann !! 
Je l'ai offert à mon ami Uran qui s'est mis au développement sur MD ... Je l'ai bien motivé !

Et ouiiiii !! J'ai modifié un peu le skin d'origine pour un rendu plus dynamique et dans l'esprit d'un jeu de sport.
C'est franchement un travail de forçat, surtout quand tu te tapes tout en "point par point" ... Mais quand on aime ...

Planche ( proto ):

[uran]

Il a de jolies gambettes ton alter-ego Vetea

[Invité]

archi fan du nouveau chara design !

[philip]

Chouette graphisme, un personnage plus ample ça va le faire.

[drfloyd]

ouais désormais les graphismes et animations sont au top, j'adore.

[Invité]

Merci les potos !!!
Oui c'est super comme ça, je viens de finir coup droit et revers ... Ça n'a plus rien a voir, c'est un cran au dessus la.
J'ai intégré les nouvelles frames et codé la gestion des coups, ça rend super !!
Je voudrais intégrer les glissades sur terre battue au moment du coup ... Une petite valeur de decceleration de la vitesse ...
Je ne peux rien vous montrer, en rentrant du taf, panne de connexion ....
J'espère demain.
A bientôt.

[vincent2105]

Comme les autres... ils sont nickels ces nouveaux sprites