R P G - Page 1

cela doit faire le n-ieme topic sur le sujet ben jusqu'a maintenant je n'ai toujours rien compris j'ai demandé a plusieur personne comment ils auraient fait,ben pour la plupart je n'ai pas trop compri alors je vous demande votre technique pour faire des rpgs style bomber CF etc... à part les libs bien sure l'objetcif n'est pas de faire qqchose de rapide pour la rapidité on verra après,il faut déjà que je sache comment faire !

imaginons que mon ecran ne peut afficher que 4 x 4 cases et que je veux passer a la serie de case se trouvant a droite et tout cela pixel par pixel

matrice:
ecran + loin

1 0 1 0 0
0 1 0 0 1
0 1 0 1 0
1 1 1 1 1

n'oubliez pas qu'un morceau de code est tres explicatif quand il est bien commenté


[edit]Edité par HEvil le 24-02-2002 à 22:14:14[/edit]

Tout les bons programmeurs te le diront, il faut tout reafficher à chaque frame...

Mais bon ca je te l'ai deja dit par mini messages et apperement t'as pas capté donc j'espere k'il y aura 2,3 programmeurs ki auront le temps de t'expliquer ca en détail

excuse de mon ignorance mais que veux tu dire par frame ???

Une frame, c'est une image!
Et je confirme ce qu'a dit Aghnar : Tu réaffiche tout l'écran à chaque image.
Donc tu affiche la premiere image, et apres tu efface et tu affiche par dessus la seconde image, identique à la premiere mais déplacée d'un pixel.
Pour ca t'aura besoin d'un fonction de sprite avec clipping (puisque des bouts de sprite sortiront de l'écran, c'est nécessaire pour que ca fasse pas tout planter ) et d'un écran virtuel ( pour qu'on voit pas l'image se dessiner au fur et à mesure sur l'ecran ).
Je sais pas si j'ai été clair mais bon....

oui tu as été assez clair

donc il faut que je dessine ma partie en rouge dans un ecran virtuel ensuite si le gar se deplace je scroll mon ecran virtuel ensuite j'affiche a l'ecran

SURTOUT !!!
PAS DE SCROLLING !!!!

au lieu de faire un scrolling, il vaut mieux que tu efface tout l'écran, et que tu redessine tous tes sprites 1 pixel (ou plus) sur le coté !!!!

quel fonction sont bonnes pour l'affichage en clipping (pour des progs nostub en C of course !) ??

X_lib le fait
(mais y a que sprite16 et pas encore sprite32)

quand tu dis pas de scrolling squale92 c'est ?
pas de scrolling à l'ecran mais le faire avec l'ecran virtuel car sinon je ne vois pas trop comment afficher un ecran decaller d'un pixel sans faire au moins un scrolling

en clair fo pas faire ca :


http://multimania.com/aghnar666/Scroll.c

pourtant c de moi
mais bon c assez vieux comme source et meme en reaffichant tout je suis pas sur k ca soit plus rapide vu la lenteur des routines de sprite de extgraph (y a kan meme 88 tiles 16x16 à reafficher à chak frame sur la 92+ rien k pour le background, apres faut compter link+les ennemis+les objets animés !!!)

pit etre k'avec X lib... ou avec genNlib

je sauvegarde ça sur mon disque dur Scroll.c bien que je sois une queue en C je regarderais quand même

je pense avoir compris comment ça fonctionne

Xlib n'a pas de fonction de scrolling, et c'est tant mieux ! Ca évite de vouloir faire des movais trucs.

Au lieu de faire scroller ton écran virtuel, tu l'efface en entier (avec ClrScr si tu bosses avec TIGCCLIB) et ensuite tu redessine tous tes sprites dessus.
Tu n'utilises aucun fonction du style ScrollSCreenblablabla (de Extgraph par exemple) ou memcpy de TIGCCLIB

La derniere version de extgraphlib gere tout ce qu'il faut pour faire un rpg..

et puis, sinon, il y a le RPG maker de la TICT (ou GDK... cf http://tict.ticalc.org)

pq vous voulez po de scrolling ???
j'en fait un et c assez rapide

je viens de faire une tentative et ça n'a pas fonctionner je vais faire ça au brouillon et je retourne dessus
un mauvais recopiage de mon ecran virtuel je pense
[edit]Edité par HEvil le 26-02-2002 à 15:41:58[/edit]

gugusg> un vrai scrolling est en général plus lent que de tout redessiner, si j'en crois :
Mon expérience perso
La doc de Genlib
l'auteur de Genlib
Tous ceux qui ont déjà traité de ce sujet

>squale92: Xlib n'a pas de fonction de scrolling, et c'est tant mieux ! Ca évite de vouloir faire des movais trucs.

Pourtant les big_screens de XLib me semblent idéaux pour le scrolling: On peut afficher le prochain tile devenant visible une seule fois, quand le premier pixel devient visible, et puis on scrolle le big_screen d'un pixel à chaque fois sans devoir réafficher à chaque fois le tile dont on voit un pixel de plus.

si c'est bien ce que je pense cette technique est pas tres propre imaginons que quelqu'un est une énorme map, trop de mémoire !

Ce n'est pas ce que tu penses alors.
Tu n'as pas bien compris: il s'agit juste d'avoir une marge d'un tile de chacun des 4 côtés. La taille de la map entière n'a aucune importance.

ah d'accord,ensuite tu fais un scrolling avec les marges !
Justement c'est cette technique que je comptais utilisé
[edit]Edité par HEvil le 26-02-2002 à 22:07:28[/edit]

j'ai enfin nettoyer et finit ma partie que me permettra d'afficher les sprites dans un ecran virtuel voici la routine dite moi tout ce qu'on peut optimisé dedans

 ClrScr		#1360-1,#EcranVirtuel	;nettoie l'ecran virtuel
 lea.l		Map,a0
 move.w		#17-1,d6
 move.w		#10-1,d7

 moveq.w	#0,d0
 moveq.w	#0,d1

BoucleDessineMapEcranVirtuel:
 tst.b		(a0)+
 beq		FinTestSprite
 Sprite16EV	d0,d1,#EcranVirtuel,#BlockSprite ;routine speciale pour l'ecran virtuel

FinTestSprite:
 add.w		#16,d0
 dbf.w		d6,BoucleDessineMapEcranVirtuel
 lea.l		13(a0),a0		;il reste 30 - 17 que l'on va sauter pour passer a la ligne suivante 
 moveq.w	#0,d0
 add.w		#16,d1
 move.w		#17-1,d6
 dbf.w		d7,BoucleDessineMapEcranVirtuel

pour l'instant elle ne teste que les 1 de la map 0 = vide

Sprite16EV  macro
 movem.l	d0-d2/a0-a1,-(a7)
 move.w		1,d0
 move.w		2,d1
 move.l		3,a0
 move.l		4,a1
 moveq.l	#0,d2
 move.w		d1,d2	;optimise la multiplication par 34
;>------ sequence optimisé --------
 lsl.w		#5,d1
 add.w		d2,d2
 add.w		d2,d1
;------ sequence optimisé --------<
;;;;;;;;;;;;;;;;;;;;;;;;;;
 move.w		d0,d2	;copy d2
 lsr.w		#3,d0	; d0 / 8
 and.w		#$FE,d0
 add.w		d0,d1
 add.w		d1,a0	;A0 pointe sur le bon word :)
 and.w		#15,d2	; mod(16)
 moveq.w	#16,d0	;pour pouvoir allumé le bon bit
 sub.w		d2,d0   ;décallage ! :)
 move.w		(a1)+,d1 ;nombre de boucles ! en word !
 sub.w 		#1,d1	; à cause du dbf !
@BoucleSprite16:
 moveq.l 	#0,d2
 move.w		(a1)+,d2 ;Le sprite
 lsl.l		d0,d2	 ;On decalle le sprite !
 or.l		d2,(a0)	 ;On applique le sprite!
 lea		34(a0),a0 ;A0 + 30 -> A0
 dbf.w		d1,@BoucleSprite16
 movem.l	(a7)+,d0-d2/a0-a1
 endm

si qq1 pouvait me passer 2 3 sprites pour pouvoir tester mon programme
exemple briques,cailloux,etc...

Kevin> c vrai que XLib est pratique pr ces BigScreen...
mais le scrolling, j'ai jamais vu de routine aussi rapide que tout réaffciher

Je confirme, tout va se réafficher très vite !!!
[edit]Edité par Pim89 le 27-02-2002 à 20:45:45[/edit]

merci pr la confirmation.
De toute façon, si tu n'est toujours pa convaincu, teste par toi même.

>La doc de Genlib >
>l'auteur de Genlib

C'est surtout que tu es limite a un deplacement de 1 pixel par 1 pixel.
Mais si c'est dont ut as besoin et que tu n'affiches que peu de sprites, ca peu etre une bonne methode.

oué, mais dans un RPG, tu affiche rarement peu de sprites !

En es-tu sur ?
Cf n'est pas vraiment un bon exemple