Page 2 sur 12

Re: Développement Shoot them up

Publié : lun. 05 oct. 2015 20:08
par Hero_Tonma
Salut Touko, on m'a dit beaucoup de bien de toi.
Tu peux m'appeler Tonma :D

Je me lance directement dans l'asm. J'utilise pceas v3.22
Je me connais, je suis assez feignant en code alors si je prends le C, j'aurais du mal à évoluer alors tant qu'à faire. Tout le monde me dit que le C est pas rapide. Je vais essayer de faire un scroll déjà pour voir si la vitesse tiens la route avec quelques sprites. Alors toute aide est la bienvenu. MooZ m'aide beaucoup en me donnant des conseils sur les bases mais j'ai encore un peu de mal à tout mettre en place.

Pour l'instant, j'arrive à afficher plusieurs sprites et des déplacements automatiques. Ainsi que l'affichage de tiles en BackGround avec une boucle de ma conception (hum hum)

Mes prochains objectifs : scroller le background, ajouter le contrôle du pad, gérer les priorités (pour l'instant j'ai juste le BG0 et le SP0, j'arrive pas à écrire sur le BG1 et SP1!!) et surtout les collisions. Ca va pas être de la tarte tout ça.

Merci encore à MooZ, vous suivre ici mes petits débuts : http://pcedev.blockos.org/viewtopic.php?f=5&t=109

J'ai fait ça aujourd'hui en code pur asm : :mrgreen:
Image

Re: Développement Shoot them up

Publié : lun. 05 oct. 2015 20:32
par touko
Ca avance :D ..
Oui huc n'est pas rapide, néanmoins on peut faire des belles choses avec, bien sur pour tirer vraiment partie de la console le passage à l'ASM est obligatoire .
Heureusement l'asm des 65xx est assez simple .
j'arrive pas à écrire sur le BG1 et SP1
tu entends quoi par BG1 ??, celui de la SGX ??

Re: Développement Shoot them up

Publié : lun. 05 oct. 2015 21:02
par Hero_Tonma
Non, je pense aux sprites avec priorité pour passer entre un background de tile et le fond. Mais j'ai peut-être mal compris l'infos.

Comme cet exemple dans la doc trouvé chez notre ami MooZ:

|***********| <-- BG color 0 plane
| |
| |***********| <-- low priority sprites
| | |
| | |***********| <-- BG plane
| | | |
| | | |***********| <-- high priority sprites
|**| | | |
| | | |
|**| | |
| | |
|**| |
| |
|***********|

Quand je test mon jeu sous mednafen et que je cache les plans, mes tiles sont en BG0 et sprites en low priority sprites. Je peux cacher les autres plans, y a rien dedans. Et debugguer la zone mémoire de la vram, mes sprites sont bien en low sprite plan et tile en BG0. Pourtant j'utilise la routine

Code : Tout sélectionner

spr_set #0,satb
   spr_x sx
   spr_y sy
   spr_pattern #TONMA
   spr_ctrl  #SIZE_MASK,#SIZE_16x16
   spr_ctrl  #FLIP_MASK,#NO_FLIP
   spr_pri   #1
Mais spr_pri à #0 ou #1, c'est pareil. Et j'ai le même soucis pour le Background plane.

L'assembleur est assez facile car juste ce qu'il faut d'instructions. Mais j'ai encore du mal à tout ingérer, j'ai commencé que la semaine dernière et je vais encore chercher pour comprendre la gestion de mémoire et les overlay pour les CD, SCD

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 09:07
par touko
ta syntaxe à l'air bonne (j'utilise pas pceas),si tu peux mettre ta rom à dispo je regarderai .
par contre ça:

Code : Tout sélectionner

spr_ctrl  #SIZE_MASK,#SIZE_16x16
spr_ctrl  #FLIP_MASK,#NO_FLIP
Tu peux l'écrire comme ça:

Code : Tout sélectionner

spr_ctrl  #(SIZE_MASK | FLIP_MASK) , #(SIZE_16x16 | NO_FLIP)

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 09:38
par Hero_Tonma
Merci,

Tu utilises quoi comme assembleur ?

J'ai fais un fichier source avec le minimum pour les tests : https://www.dropbox.com/s/n9nytek8s7icwmk/tonma3.zip

Il y a le code source, les images, la rom compilé et le fichier source en asm avec la macro spr_pri.

Code : Tout sélectionner

; spr_pri(#flag)
; ----
; flag, new priority (1 = in foreground, 0 = in background)

	.macro spr_pri
	 ldy   #6
	 lda   [_si],Y
	 and   #$7F
	 ldx   \1
	 beq   .x\@
	 ora   #$80
.x\@:
	 sta [_si],Y
	.endm
Tu sais comment on change de plan pour le background ?

Merci d'avance.

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 09:48
par touko
Tu utilises quoi comme assembleur ?
J'ai un custom de huc (pour le bankage auto des données) et je code tout en asm dedans .

Donc après test de ta rom, le sprite est bien en priorité high par rapport au bgnd .
Tu sais comment on change de plan pour le background ?
Un fond est composé de 2 choses .
1 - Le tilemap: qui contient les adresses VRAM des tiles à afficher et la palette à utiliser pour chaque tile .
Chaque tile représente 2 octets dans le tilemap son adresse en VRAM (bit 0 -> 11), et le numéro de la palette (bit 12 à 15).
Le tilemap commence toujours à l'adresse $0000 en VRAM, et sa taille dépend de la taille du tilemap choisie (32x32,32x64,64x32,etc ..)
2 - Les datas graphiques des tiles en VRAM.

Sous pceas je crois qu'il faut utiliser .incchr

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 09:56
par Hero_Tonma
Comment tu peux voir vérifier sa priorité. Quand je debug avec mednafen, il me place le sprite en spr0 et les tiles dans le background color (BG0) on le voit à la couleur sur tout l'écran.

Image

Parce que si j'utilise spr_pri #0, je suis toujours devant le background.

Tu peux m'indiquer comment écrire les tiles sur le BG1 pour tester la position du sprites, ça m'aiderait bien pour comprendre. Parce que ton explication met fait penser qu'il n'y a qu'un background et un plan pour les sprites.
Ok je vais regarde du côté de .incchr

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 09:59
par touko
ctrl+1 affiche/cache le BG0 (qui est le bg de la PCE le BG1 est celui de la SGX)
ctrl+2 affiche/cache les SPR0(qui sont les sprites de la PCE)
Et tu verras que ton sprite est bien au dessus du BG donc de priorité HIGH .
Parce que ton explication met fait penser qu'il n'y a qu'un background et un plan pour les sprites.
Mais c'est exactement ça . :D si tu codes sur PCE .
La priorité des sprites fait que soit il est affiché sur le BG soit derrière et visible que si le BG a des pixels transparents .
Tu ne peux pas définir des priorités sur chaque tile, ça concerne le BG entier .

Vu que j'utilise pas les macros de pceas, je peux que te donner un exemple d'une demo de ccovell, je pense que mooz pourra mieux te renseigner que moi .

Code : Tout sélectionner

; PICTURE DATA 

	.data

	; pictures can contain up to 256 colors, but as you know the
	; PC-Engine can display only 16 colors per 8x8 tile, so be careful
	; when making pictures. And also take care of the color alignment,
	; a tile can use, for example, color 0 to 15, but not color 4 plus
	; color 26 plus color 125, all the colors used in a tile must
	; belong to the same sub-palette (colors 0 - 15, 16 - 31, etc...)
        ;
	; if you have problems making such pictures, use only 16 colors
	; PCX files, you will have less problems

PIC_BANK .func (((\1)*6)+MAIN_BANK+1)	; a little function to help
					; referencing banks

PIC	.macro			; hmm a macro could be handy too...
	 .bank PIC_BANK(\1)
	 .org  $8000
	 .incchr \2,40,32
	 .bank PIC_BANK(\1)+5
	 .org  $8000
	 .incpal \2
	 .org  $8200
	 .incbat \2,$1000,40,32
	.endm

	PIC 0,"grid.pcx"	; what would we do without macros? :)
Le chargement de l'image se fait comme ça :

Code : Tout sélectionner

; ----
; load_pic
; ----
; upload a whole pic in VRAM
; ----

load_pic:
	lda   <pic		; get the current pic number

	asl   A			; mul it by 6 (each picture takes six banks,
	sta   <_al		; five for the graphics and one for the BAT
	asl   A			; and the palette)
	add   <_al

	add   #2		; add 2 - our pictures are stored starting
				; from bank 2

	sta   <_ah		; store the bank index

	; load the graphic in VRAM, one bank at a time
	
	lda   <_ah		; first bank
	tam   #4
	vload $1000,$8000,#$1000
	inc   <_ah		; second bank
	lda   <_ah
	tam   #4
	vload $2000,$8000,#$1000
	inc   <_ah		; third bank
	lda   <_ah
	tam   #4
	vload $3000,$8000,#$1000
	inc   <_ah		; fourth bank
	lda   <_ah
	tam   #4
	vload $4000,$8000,#$1000
	inc   <_ah		; fifth bank
	lda   <_ah
	tam   #4
	vload $5000,$8000,#$1000

	; vsync before setting the palette, to avoid snow

	vsync

	; now set the palette

	inc   <_ah
	lda   <_ah
	tam   #4
	set_bgpal #0,$8000,#16
	set_sprpal #0,$8000,#16

	; and finaly copy the BAT

	batcpy $0001,\
	       $8200,\	       
	       #40,\
	       #32

	; ok, done

	rts
J'espère que ça pourra t'aider :?

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 10:13
par Hero_Tonma
Ok. Donc je confondais la couleur de l'arrière plan et le background en lui même. Et j'avais oublié que Mednafen gérait aussi la supergrafx

Je viens de re-tester en changeant la priorité du sprite et je suis bien derrière le background mais au dessus de la couleur. C'est assez spéciale mais maintenant j'ai compris.

Maintenant je vais passer au contrôle par pad et le scroll surtout (avec modifications des tiles pour un niveau en entier + tard)

Pour remplir le background, je vais regarder du côté de bmp2pce, ça propose un fichier map que je devrais pourvoir lire. Plus qu'a regarder dans les includes pour les macros.
Merci pour le code, tu écris plus vite que mes réponses ... :mrgreen:

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 10:18
par touko
Oui la couleur 0 du BG0 est définie soit par la couleur 0 de la palette 0 du fond, ou la couleur 0 de la palette 0 des sprites si aucune palette 0 des tiles n'est définie, c'est ton cas ici puisque c'est surement la couleur 0 de ta planche de sprites .
Cependant comme la couleur 0 sert à la transparence, les sprites ne peuvent pas être derrière cette couleur,et seule la couleur 0 de la palette 0 des tiles est visible, celle des sprites concerne l'overscan, donc invisible, sauf si aucune palette de 0 de tiles n'est définie,c'est celle des sprite (si définie) qui devient la couleur de fond .

Ensuite je pense que tu as confondu le BG0 et BG1 comme priorité, alors qu'il s'agit des VDC de la PCE (VDC0 => SPR0,BG0) et celui de la SGX (VDC1=>SPR1,BG1). :wink:
Donc un sprite qu'il soit de priorité haute ou pas, serra toujours dans la VRAM du VDC0 (soit SPR0) dans le cas de la PCE,c'est juste à l'affichage que le VDC va le mettre devant ou derrière le fond en tenant compte de cette priorité .
Pour remplir le background, je vais regarder du côté de bmp2pce,
Je l'utilise aussi, il est très bon, mais n'oublies pas que les fichiers à inclures deviennent des .bin et plus un .pcx, donc .incchr et .incbat ne sont plus valables normalement .
Merci pour le code, tu écris plus vite que mes réponses ... :mrgreen:
LOL de rien, c'est parce que j'édite quand j'ai des idées de où trouver des exemples "simples", c'est pour ça que j'ai pas parlé de bmp2pce,simple à utiliser, mais faut déjà bien avoir les notions de tilemap et de tile en tête .

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 10:37
par Hero_Tonma
Effectivement c'est plus claire. maintenant je vais faire des tests.

Pour bmp2pce, ça devrait aller, j'utilise pas .incchr et .incbat. Je vais faire un tilmap avec tiled, après d'après la doc de bmp2pce, il me fait une map et les tiles non répétés dans le tilemap. Ce qui me restera à voir c'est l'affichage avec scroll.

Une autre question, comment tu fais pour afficher du texte à l'écran ? Tu utilises le font.inc de huc, ou tu fais des tiles à la main. Et surtout pour l'affichage, tu affiches du texte directement sur le BG, même lors d'un scrolling. Parce que vu la limitation des sprites par ligne, ça serait impossible d'utiliser des sprites.

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 10:50
par touko
Une autre question, comment tu fais pour afficher du texte à l'écran ? Tu utilises le font.inc de huc, ou tu fais des tiles à la main.
Ca dépend si j'ai pas besoin de fontes particulieres, ou juste pour débuguer j'utilise celui de huc/pceas,sinon j'en prends sur le net .
Et surtout pour l'affichage, tu affiches du texte directement sur le BG, même lors d'un scrolling. Parce que vu la limitation des sprites par ligne, ça serait impossible d'utiliser des sprites.
Oui, cependant l'affichage classique étant composé de tiles il scrollera avec ton fond si tu scrolles .
Avec des sprites, à part pour des trucs particuliers, ils sont à éviter, de plus des fontes en 8x8 avec des sprites de 16x16 minimum, c'est pas simple à gérer,et à part gâcher de la bande passante, ça te servira à rien dans 99% des cas ..

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 13:55
par Hero_Tonma
Alors j'ai testé en ajoutant ma propre font et j'ai vérifié en vram avec le debugger. J'ai bien ma font et je peux écrire à l'écran.
Maintenant je sais lire l'emplacement mémoire et ajouter la palette en même temps.

Image

Le problème, on le voit sur l'image. A gauche j'affiche mon texte (en tile 8*8 ligne 19)) en dessous de ma tile de background (ligne 18). Mais si je veux écrire au même endroit qu'une tile existente, le caractère remplace entièrement la tile (cf à droite de l'image).
J'ai du mal comprendre. Je pensais que ça pouvait rajouter une tile transparent mais ça me parait logique d'écraser entièrement.

On doit faire comment, prévoir un espace vide pour le texte, prévoir des tiles avec le bon background ou utiliser des spites ?

Bon je me réponds moi, comme je me douter. J'ai tester avec airzonk et pckid. Le texte à soit un emplacement, soit il s'agit de sprite. En même temps je sais pas comment on pourrait faire autrement. 8)

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 14:44
par touko
Tu as raison, comme le texte n'est généralement composé que de tiles, il remplace celles du fond car on a qu'un seul plan .
Donc si tu vois du texte avec de la transparence, c'est effectivement fait avec des sprites, le hud en surimpression de air zonk par exemple .
C'est pour ça aussi que sur certains jeux, quand le hud est fait de tile, on utilise une interruption H-sync (interruption générée à une ligne précise) pour scroller l'écran après le hud .

En tout cas tu progresses vite :wink:

Re: Développement Shoot them up

Publié : mar. 06 oct. 2015 17:05
par Hero_Tonma
touko a écrit : En tout cas tu progresses vite :wink:
Merci. Pour l'instant c'est juste du code que j'ajoute, ça va être plus chaud quand je vais devoir tout faire cohabiter.

J'ai ajouté la possibilité de déplacer le sprite avec les flèches/pad gauche et droite. Je me demande si y a pas de perte de synchro, par moment ça saute légèrement. Je fais juste un vsync et je test seulement sur emul donc je peux pas voir un vrai résultat.

Pourrais tu m'expliquer l'histoire de H-sync avec une ligne, ça veut dire qu'il faut tester la synchro à chaque ligne écrite par le soft ? Quand tu auras du temps bien sûr :wink:

Comme après il va me rester les gros morceaux : scrolling (à plusieurs niveaux !! comme airzonk) et les tests de collisions, je pense que le H-sync va m'aider. Il me restera aussi le son et la gestion du CD/SCD que je verrais en temps voulu.

Pour ceux qui veulent tester, j'ai mis à jour le lien sur mon premier post avec la dernière démo). Et je le reposte ici au cas où : https://www.dropbox.com/s/f8iexf3ia4s86f7/tonma.zip