Necstasy

Ok.

Je vais rester en asm alors. Ca me fera une bonne expérience.

Tu veras. Il y a un avant et un après.
Les femmes ne te regarderont plus jamais de la même manière (voir même plus du tout).

Je sens déjà mes cheveux repousser.

Mais mooz a raison, d'ailleurs je viens de voir une vidéo du portage de shinobi sur MD, et j'ai déjà vu des ralentissement des que le mec tire 3 shuricans, pourtant y'a rien à l'écran, mais comme le jeu est codé en C, ça reste pas glorieux sur Md non plus, même si je pense que son code n'est pas encore optimal .

De toute façon dis toi bien que tu y passeras au tout asm sur PCE c'est sur,mais sur MD aussi, tu verras que finalement c'est pas plus long de faire les choses en ASM plutôt qu'en C quand tu as l'habitude, et surtout les optimisations sont évidentes, tu as rarement besoins d'y revenir .
Après je sais pas si tu trouves l'asm 65xxx complexe ou pas, mais la marge de progression est très rapide,en plus d'être très grande .

Et surtout quand tu reverras les routines de huc tu te diras "Oh putain qu'elles sont vraiment pourries" .

C'est un français le créateur de Huc ?

A la base le projet a été commencé par david michel, le créateur de magic engine et de mkit, puis continué et finalisé par david shadoff et zeograd je crois .

Donc on a du Usa et zeograd est francais ?

Oui,il me semble,et david michel l'est aussi ..

Bonnee année à tous.

Nouvelle année, nouvelle question.

D'après ce que j'ai compris du code que tu as écrit sur le forum pour la position du sprite X. On écrit sta posX + 1 pour la partie HIGH.
J'apprend vite mais des fois je bloque. Je dois faire une erreur entre l'adresse et le contenu.

J'ai une adresse de sprite et une variable pour mes anims :
SOLDIER .equ $4000 + $100
numAnim .ds 2

Alors j'ai essayé plusieurs manières mais sans surprise. Ca marche pas. J'utilise la macro spr_pattern(#addr), on lui donne l'adresse mémoire du sprite SOLDIER spr_pattern #SOLDIER
Si je fais spr_pattern #(SOLDIER + $100), j'ai bien mon deuxième sprite. Ce que je voudrais faire c'est incrémenter ma variable numAnim de $100 à chaque fois mais spr_pattern #(SOLDIER + numAnim)

J'ai testé avec un stw $100, numAnim ( stw qui load le lowbyte et highbyte) et à la main avec un lda HIGH. J'ai bien la bonne valeur dans numAnim. j'ai fait un test en l'utilisant pour les coordonnées de mon sprite.
Mais quand je fait spr_pattern #(SOLDIER + numAnim), j'ai pas de sprites à l'écran.

Je peux pas augmenter SOLDIER car c'est une constate.

J'ai essayé aussi en mettant $4200 dans numAnim avec un set_pattern #numAnim, mais pareil. stw #$4200,numAnim.

J'espère être clair. je continu mes tests.

spr_pattern #(SOLDIER + numAnim)

Normal, là #(SOLDIER + numAnim) ça fait comme si numAnim était une constante et non une variable .

Si tu veux modifier le pattern d'un sprites, après avoir fait spr_set (macro ou fonction) il te positionne un pointeur(<__spr_ptr avec huc) sur les données du sprite sélectionné .
Avec les 2 premiers octets posy du sprite
2 octets pos X du sprite
2 octets pattern
2 octets attributs .

Il te suffit d'écrire dans [ __spr_ptr ].4 et [ __spr_ptr ].5 pour les patterns.

PS: [ __spr_ptr ].4 l'assembleur va le traduire par:
ldy #4
[ __spr_ptr ] , Y

Merci, je vais regarder ça.

Je commence à prendre la main sur l'asm. je fais mes boucles pour incrémenter, tester ... mais je comprends pas encore tout. Et c'est normal.

Il transforme en constante mais ça vient du + parce que ça marche pas quand je fais un
stw #$4200, numAnim
spr_pattern #numAnim

J'ai fais des tests mais je comprends pas. Dans les macros, ils utilisent _si au lieu de __spr_ptr, chez moi il indique __spr_ptr inconnue.
J'ai essayé avec _si : Ca fonctionne mais c'est normal, par contre quand je veux utiliser une variable ça marche pas. Ca me paraissait trop facile aussi. Heureusement que je commence pas avec le z80

Je commence à prendre la main sur l'asm. je fais mes boucles pour incrémenter, tester ... mais je comprends pas encore tout. Et c'est normal.

Euh oui c'est normal, ce serrai même le contraire qui ne le serrai pas

Il transforme en constante mais ça vient du + parce que ça marche pas quand je fais un
stw #$4200, numAnim
spr_pattern #numAnim

C'est normal, il ne transforme rien, les macros ne prennent que des constantes en argument donc comme ton numAnim est une variable, le compilo va surement balancer la valeur de son adresse et non la valeur contenue dans son adresse .

Après compilation le compilo génére un .s, tu peux voir dedans comment est interprété spr_pattern #numAnim.

J'ai fais des tests mais je comprends pas. Dans les macros, ils utilisent _si au lieu de __spr_ptr, chez moi il indique __spr_ptr inconnue.

Ok, alors ça veut juste dire que mkit utilise _si comme pointeur, donc tu peux faire [ _si ].4 et [ _si ].5 à la place, oublies l'ancien pointeur il ne concerne que huc en fait .

Ca fonctionne mais c'est normal, par contre quand je veux utiliser une variable ça marche pas.

Oui car la macro attend bien des constantes .
lda #LOW((numAnim) >> 5)
Prend la valeur LOW de la constante numAnim (qui normalement est une variable et fait un décalage de 5)
tu dois faire ça à la place avec les variables Là tu prends la valeur LOW contenue dans la variable num_anim
Et après tu prends la valeur HIGH contenue dans la variable num_anim + 1

lda #LOW(ma_var) prend la partie LOW d'une constante ou de l'adresse de la variable .

Au final il faut faire après un spr_set :

Merci beaucoup. Ca avance dans ma petite tête.

Une autre chose, j'aimerai voir le contenu de la variable. Avec Mednafen, j'utilise le debug (même si le texte est un peu petit pour moi). Comment je dois m'y prendre pour lire le contenu d'une variable comme mon numAmin pour vérifier sa valeur? Sur les interfaces modernes ça va mais là, je trouve pas.

Je sens que je vais m'amuser quand je vais faire les collisions ...

P.S. j'avais oublié de dire que je passe tout sur pceasm donc je compile pas du tout avec HUC.

Une autre chose, j'aimerai voir le contenu de la variable. Avec Mednafen, j'utilise le debug (même si le texte est un peu petit pour moi). Comment je dois m'y prendre pour lire le contenu d'une variable comme mon numAmin pour vérifier sa valeur? Sur les interfaces modernes ça va mais là, je trouve pas.

Déjà il faut connaitre à qu'elle adresse num_Anim se trouve, avec le .s tu peux facilement le savoir .

Pour mednafen il faut utiliser le mode débug,je te mets le lien vers les commande du mode debug de mednafen, ce sera plus simple que de mal t'expliquer comment il marche (je connais/n'utilise pas tout) :
http://mednafen.fobby.net/documentation/debugger.html

Le mode débug s'active en appuyant sur ctrl+D .

P.S. j'avais oublié de dire que je passe tout sur pceasm donc je compile pas du tout avec HUC.

C'est ma faute moi j'utilise encore l'ossature de huc même si je code tout en ASM

Cool pour le debugger. J'y ai passé un bon moment pour comprendre en gros son fonctionnement et ça aide. Je ne sais pas pourquoi mais ma variable hier numAnim était toujours égal à 0. Donc très utile pour pas perdre des heures pour rien. J'ai changé le nom, rajouter une autre variable et ça passe. Bon, je m'étais peut être trompé dans l'adresse aussi.

J'ai commencé les collisions en faisant de la bounding box. Les premiers essais avec deux sprites sont concluant. Mais pour optimiser avec plusieurs sprites et faire des tests d'optimsation, je voudrais sauvegarder la hauteur et la largeur des sprites. Après je saurais faire une boucle pour les passer un par un.

J'aimerais utiliser un tableau (ou une structure dynamique struct myStruct {int width, int height}; mais un tableau c'est bien pour commencer )
Quand je crée un sprite je note dans le tableau sprite1[0] = #32, sprite1[1] = #16 ...

Je sais pas si c'est la meilleur solution, mais je vais aller regarder sur les sites d'asm voir un peu comment ils font les tableaux ...