Necstasy

Non, je te rassure, y pas de bug. C'est un montage. Je suis écolo. Je voulais pas mettre deux images.

C'était pour montrer que le sprite à droite atteint sa limite et qu'il réapparait à gauche, comme si son origine était le coin supérieur droit. Mais j'ai bien qu'un sprite à l'écran.
Les caractères, c'est des tiles qui scrollent de droite à gauche.

Ah ok, donc je pense que tu as bien un soucis avec ta variable X,j'ai déjà eu ce problème, mais je me souviens plus du problème exact

J'ai une macro pour changer les coordonnées d'un sprite :

Code : Tout sélectionner

; spr_x(#x [,offset])
; ----
; x, the new x coordinate

	.macro spr_x
	 ldy   #2
	 .if (\# = 2)
	  lda   LOW_BYTE \1
	  clc
	  adc   LOW_BYTE \2
	  sta   [_si],Y
	  lda   HIGH_BYTE \1
	  adc   HIGH_BYTE \2
	 .else
	  lda   LOW_BYTE \1
	  sta   [_si],Y
	  lda   HIGH_BYTE \1
	 .endif
	 iny
	 sta   [_si],Y
	.endm

J'ai pas d'offset donc je passe dans le else. Et je vois qu'il ajoute seulement au Low_byte.

Grâce à ton explication, j'ai compris le low and high. Si j'ai ma coordonnée en X à 255, j'ai 0x00FF. Donc forcement si j'ajoute 1 je passe à 0x0000. il faut que j'ajoute 1 en high pour avoir 0x0100

Elle correspond à quoi ta valeur "deplacement" ?

Grâce à ton explication, j'ai compris le low and high. Si j'ai ma coordonnée en X à 255, j'ai 0x00FF. Donc forcement si j'ajoute 1 je passe à 0x0000. il faut que j'ajoute 1 en high pour avoir 0x0100

C'est ça,mais soit tu fais:

Code : Tout sélectionner

lda #LOW(val_depl_X)
clc
adc _pos_x
sta  _pos_x
lda #HIGH(val_depl_X)
adc _pos_x + 1
sta  _pos_x + 1

soit(c'est plus rapide):

Code : Tout sélectionner

lda #LOW(val_depl_X)
clc
adc _pos_x
sta _pos_x
bcc .pas_add_high
inc  _pos_x + 1

.pas_add_high:

Il faut tester la retenue (carry ) et non si le résultat est =0 (ça marche pour un déplacement toujours de 1 ou d'un nombre pair).

Elle correspond à quoi ta valeur "deplacement" ?

A la position courante de ton sprite, c'est juste une variable en RAM qu'ensuite tu mettras dans ta SAT avec ta macro qui me semble ma foi correcte (elle n'ajoute pas si tu es dans le else, elle positionne juste le LOW/HIGH d'une variable dans la SAT locale) .

Merci.

J'ai pu configurer mon code et j'ai même pu faire bouger mon sprite correctement dans toutes les directions

Maintenant j'ai le choix entre afficher 64 sprites à l'écran ou gérer le 2ème VDC de la supergrafix ... pour ma prochaine étape.

Super Tomna !

Et merci à touko ..

Je vous suis les gars

Hero_Tonma a écrit :Merci.

J'ai pu configurer mon code et j'ai même pu faire bouger mon sprite correctement dans toutes les directions

Maintenant j'ai le choix entre afficher 64 sprites à l'écran ou gérer le 2ème VDC de la supergrafix ... pour ma prochaine étape.

C'est cool, n'hésites pas si tu as des questions pour la SGX .

Merci pckid, mais moi je fais rien ..

touko a écrit :
Hero_Tonma a écrit :Merci.

J'ai pu configurer mon code et j'ai même pu faire bouger mon sprite correctement dans toutes les directions

Maintenant j'ai le choix entre afficher 64 sprites à l'écran ou gérer le 2ème VDC de la supergrafix ... pour ma prochaine étape.
C'est cool, n'hésite pas si tu as des questions pour la SGX .

Merci pckid, mais moi je fais rien ..

Quand même un peu ... sinon j'avancerai pas.
Et merci à tous les autres membres du forum aussi.

Quand même un peu ... sinon j'avancerai pas.

J'ai bcp appris grâce aux infos partagées ici et sur pcenginefx, c'est normal de partager à mon tour

Salut tonma,je réponds ici en français sur ton post sur pcenginefx (plus pratique d'expliquer en français

), si tu veux écrire dans le VDC de la sgx ça se passe comme sur celui de la PCE .
tu as juste les registres d'accès qui sont différents .

PCE
$0000
$0001
$0002
$0003

SGX
$0010
$0011
$0012
$0013

le registre du VPC $000E, permet de rediriger les opcodes STx (ST0 -> ST2) dans un des 2 VDC, si $000E = 0 les STx écrivent dans le VDC de la PCE, sinon c'est celui de la SGX .

Ok. Merci, je vais regarder de ce côté là dans les macros.

Pour être bien sûr parce que je suis un peu lourd et lent parfois.

Je fais mon code en asm avec pceas. J'utilise les macros de kit magicengine pour initialiser la pce et pour loader les graphs (/include/pce). Les macros sont pas optimisées mais ça ira quand même plus vite qu'avec HUC en c ?

Après, je pourrais optimiser les macros pour les sprites et la gestion des tableaux.

Je fais mon code en asm avec pceas. J'utilise les macros de kit magicengine pour initialiser la pce et pour loader les graphs (/include/pce). Les macros sont pas optimisées mais ça ira quand même plus vite qu'avec HUC en c ?

Ca dépend, certaines macros sont identiques, mais tu parles de macros ou de fonctions, parce que là c'est différent .

Pour les tableaux, si tu codes en asm, aucune optimisation n'est nécessaire(même si le tableau est déclaré en C) .

de toutes façon tout projet fait avec mkit, sera plus rapide et plus compact qu'avec HUC.

Je parles des macros dans le sprites.inc par exemple

Code : Tout sélectionner

; spr_set(#sprite, satb)
; ----
; sprite, the sprite number (0-63)
; satb,   the address of the SATB in RAM

	.macro spr_set

	; multiply the sprite number by 8 (the size of a SATB entry)
	; and put the result in _si

	 stz   <_si+1
	 lda   \1
	 asl   A
	 asl   A
	 asl   A
	 rol   <_si+1
	 sta   <_si

	; add the satb address to _si

	 addw  #\2,<_si
	.endm

Je pense que je parle de functions, c'est à dire les macros avec passage de paramètres. Mais peut-être que je me trompe.

Pour la vitesse d'exécution, les macros sont les mêmes entre le c et l'asm, mais Est-ce que la compile direct avec pceas est plus rapide qu'avec huc pour les même macros. C'est surtout pour savoir quel compilo utiliser parce si il s'agit que des macros autant garder le huc. Comprends moi bien, c'est pas la question de pas faire en asm mais + de garder un code portable.

Alors dans l'exemple que tu m'as donné c'est bien une macro, huc utilise une fonction pour les sprites, donc plus lente mais prend moins de place .

mais Est-ce que la compile direct avec pceas est plus rapide qu'avec huc pour les même macros

huc ne fait que mettre ton fichier texte.c en fichier .s qui sera compilé par pceas en .pce

donc non, seule la traduction du .c en .s fera que ce sera plus lent .
Le problème ne vien pas de pceas(le compiler) de huc, mais comment huc(le linker) traduit le c en asm .

Comprends moi bien, c'est pas la question de pas faire en asm mais + de garder un code portable.

Je comprends, pas de soucis, ce que je veux te dire c'est que le soucis vient du compilo C, donc si tu veux rester en 100% C pour faire du code portable, va falloir tout réecrire,ou alors voir si les perfs de huc n'impactent pas ton projet,et laisser huc tel quel .

Necstasy

Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up

Re: Développement Shoot them up