Discussion :

[Kannagi]

Le commencement de ce projet était sur des forum/FB/autre qui disait que la SNES ne pouvait pas faire de shmup.
Il est vrai que comparé à sa concurrente la Mega Drive, elle on a pas eu beaucoup , c'est surtout à cause de de Gradius qui lag pas mal sur SNES.
(Mais on a Super Aleste qui montre le contraire entre autre).

Du coup je me suis dit au lieu de faire un shmup classic , il faut faire la version "évolué" donc un manic shooter (c'est un shoot mais avec plein de bullet).

Voici la démo en vidéo :

Attention , il y'a 100 bullet max à l'écran
Je vous évite le blabla technique pour atteindre cette perf , mais c'est pas mal de code et d'algo optimisé :p
J'ai galérer pour faire des bullets qui vise le joueur , sur une SNES c'est pas le truc le plus évident au monde

La première vidéo , c'est un test pour voir si un boss en BG , ça passe bien + Bullets
La deuxième , j'ai rajouté 12 ennemis pour voir combien ça prend en CPU et j'ai fait que les tir ennemis vise le joueur
Et tout ça sans ramer

Mon dernier screen , changer les bullets+animation des bullets , + optimisation (je suis à 58% max de CPU) :


Pour les bullets j'ai départagé comme ceci 24 pour le joueur et 76 pour les ennemis.
Et 28 pour le reste , ça sera sûrement un des rares jeux SNES qui utilise la totalité des sprites (la SNES a 128 sprites hard).
(Petit rappel la SNES ne fait que 2,68 MHz)
Je vise les 2Mo en ROM , ça devrait pouvoir le faire !

[jwar0]

C'est pas du java !!
J'avais Super Aleste sur cette console, un bon souvenir.

[LittleWhite]

Bien joué !
Je trouve que la résolution en hauteur fait un peu courte pour un danmaku .

[Kannagi]

@jwar0
Oui , c'est pas du java , je confirme
Pareil j'ai adoré Super Aleste mais c'est sûrement le meilleur shmup de la console !

@LittleWhite
Oui , je trouve aussi , mais la SNES à une résolution "carré" donc 256*224 !
Les Danmaku certain se jouait en mode tate (donc il fallait tournait son téléviseur pour pouvoir y jouer) vu que la résolution a était pendant longtemps du 320*240.
Donc on tournant votre fameuse télé cathodique on avait un genre de 240*320 niveau résolution

Mais bon ça peut marcher que sur borne d'arcade (ou console 32 bits),parce que si on utilise la largeur ça veut dire que le ship+bullet+ennemi peuvent se trouver sur la même ligne mais la SNES ne peut supporter que 272 pixels par ligne (pour les sprites) , alors qu'une neogeo supportait 96 sprites par ligne (soit 1536 pixel par ligne)

[ohnomorejmmings]

Attention , il y'a 100 bullet max à l'écran

C'est déjà pas mal. Des idées pour exploser ce nombre ? J'ai pensé à exploiter des composants comme le processeur sonore et justement l'article Super Aleste — Wikipédia mentionne que c'est ce qui avait été fait à l'époque pour fluidifier l'animation. Après je sais pas si ça permettrait aussi d'augmenter le nombre de sprites !

Je vous évite le blabla technique pour atteindre cette perf , mais c'est pas mal de code et d'algo optimisé :p
J'ai galérer pour faire des bullets qui vise le joueur , sur une SNES c'est pas le truc le plus évident au monde

Ah non justement c'est la nourriture de beaucoup d'entre nous. Peut-être un zest de virgule fixe ? Derrière le fameux Mode 7 il doit y avoir des trucs Super Sexy à exploiter !!

Pour les bullets j'ai départagé comme ceci 24 pour le joueur et 76 pour les ennemis.
Et 28 pour le reste , ça sera sûrement un des rares jeux SNES qui utilise la totalité des sprites (la SNES a 128 sprites hard).

Ça serait pas possible de remplacer les 24 du joueur par un plan avec un laser à la DonPachi ? En le défilant ou je ne sais quoi ça pourrait donner l'impression qu'il est constitué de sprites. Quant aux 28 bah j'afficherai que le joueur et les ennemis !

Je trouve que la résolution en hauteur fait un peu courte pour un danmaku .

C'est vrai que la majorité est étirée verticalement mais quand la jouabilité est adaptée ça fonctionne par exemple très bien avec Mars Matrix.

Mais bon ça peut marcher que sur borne d'arcade (ou console 32 bits),parce que si on utilise la largeur ça veut dire que le ship+bullet+ennemi peuvent se trouver sur la même ligne mais la SNES ne peut supporter que 272 pixels par ligne (pour les sprites) , alors qu'une neogeo supportait 96 sprites par ligne (soit 1536 pixel par ligne)

La contrainte prise de tête ! Donc pour des sprites de 8*8 ça en fait seulement 34 sur une ligne ? Il se passe quoi si les calculs en conduisent plus à être présents ?! Le 35e et les suivants sont ignorés ?! Enfin une trentaine c'est déjà pas mal puis en être créatif on doit pouvoir s'en sortir…

Sympa ce projet bidouiller sur SNES c'est un rêve puis les shmups… Un cauchemar jouissif ! Bon courage !!

[Kannagi]

Alors pour te répondre ^^

Je préviens , je compte de répondre de façon complète donc y'aura un gros pavé

Oui Super Aleste utilisait apparemment le proc sonore pour aider le CPU principal , et cela m'étonnera toujours !
Le proc sonore (le SPC700) et le proc principal (un 65816) ne sont pas synchronisé , donc si tu veux recup des données (ou envoyer des données) , il va falloir que le proc principal attende
Franchement il faut vraiment de gros calcul (qui aurait l’intérêt d’être attendu) et une bonne syncro pour que cette méthode soit efficace.
Bien sur pendant l'attende on peut faire quelque calcul mais tu vois l'idée
Techniquement 'il y'a que 4 ports (de 8 bits) pour la communication entre ces deux procs , pour mon driver sonore j'ai fait ceci :
Port0 : Synchronisation
Port1 : Commande
Port2&3 : Data

Bien sur c'est arbitraire , chaque driver sonore fonctionne différemment

Pour les autres machines par exemple la Megadrive , le bus du proc sonore et principal était partagé , ce qui causait pas mal de souci , notamment des bugs hardware quand les deux était utilisait en même temps , donc les programmeurs faisait soit l'un soit l'autre ,ce qui n’améliorait pas la qualité sonore

Pour la Neo Geo , c'est la plus simple , la communication ne va que dans un sens proc principal vers proc sonore , et ça causait juste une interruption sur le proc sonore avec récupération possible d'un port 8 bits.
Le but c'était juste de lancer des commandes (lancer tel musique , lancer tel SFX etc etc).
Mais bon , la NG était spécial , vu que le proc sonore avait sa propre ROM (techniquement deux) , un pour le code + quelque data du proc sonore et le deuxième pour les samples.
Du coup pas besoin d'une grosse communication , vu que le proc sonore était autonome.

Maintenant je vais parler des contraintes SNES niveau sprite :
Alors oui cela fait 34 sprites de 8x8 par ligne max , mais j'avais lu que la limite était de 30 sprites.
Si tu dépasse les 272 pixel par ligne (ou 30 sprites),ben ils ne sont pas affiché tout simplement , le programmeur peut décider de faire clignoter les sprites (ce qui était courant sur la Nes).
J'ai l'impression que sur la gen des consoles 16 bits cela était moins acceptable donc on limitait souvent les sprites pour ne pas dépasser la limite.
Sinon le max est bel et bien de 128 sprites max impossible de dépasser cette limite et sprite software quasi impossible (le cpu est trop long et pas de framebuffer , et les data des sprites sont encodé beaucoup trop bizarrement pour avoir un truc rapide)

Maintenant pourquoi je ne peux pas afficher plus que 100 bullets !
Tout simplement parce que j'ai prévu de faire ceci :
-100 sprites pour les bullets
-12 sprites pour les ennemis
-4 sprites pour le ship (le ship principal , je compte faire deux petit module + 1 autre pour les effets genre un bouclier)
-12 sprites pour les bonus (techniquement 3 bonus)
Pourquoi 12 sprites pour les bonus ?
La SNES à un défaut d'une volonté de compatibilité de la Nes , ce qui cause qu'au final qu'ils se sont trouvé à court de bit (sans mauvais jeux de mots hein ) pour pouvoir définir toutes les combinaisons possibles.
En gros on peut avoir que des pairs genre 8x8/16x16,8x8/32x32,16x16/32x32 etc etc
Et dans mon cas j'ai choisi le 8x8/32x32 et comme les bonus feront du 16x16 et que je peux pas en faire ,je suis obligé de faire de ce qu'on appelle un metasprite donc 4 sprites de 8x8 pour un bonus
Donc au final je ne peux pas vraiment augment ce chiffre significativement de 100 bullets.
Pour les bullets ,tu me parle de laser , j'en ai fait un (voir la première vidéo ou ma démo a la fin de mon pavé)

Alors je ne compte pas utiliser le Mode 7 c'est un mode très contraignant , le mode le plus utilisé est le Mode 1 (celui que j'utilise) , il permet d'avoir 3 Backgrounds !
2 Background de 16 couleurs et le 3 eme de 4 couleurs (qui sert plus souvent de Hud , mais sert aussi pour certain effet comme la pluie dans Zelda).
Je précise quand je dis 16 couleur pour un BG je parle d'un tiles.
Le BG à 8 palettes de 16 couleurs donc techniquement max on peut avoir 128 couleur niveau BG (les 128 autres sont pour les sprites).
Mais mon moteur est configurer pour faire du 112 couleurs pour les BG1&2 (soit 7 palettes) , la dernière palette sert pour le Hud.

Maintenant pour les techniques d'optimisation !
Déjà la technique que je fais (mais qu'on le fait du coup plus en asm) , c'est de déplier la boucle donc ça évite pas mal de calcul ^^
L'autre étant qu'un bullet est toujours afficher , je ne fais pas de différence entre un sprite à l'intérieur et un à l’extérieur de l'écran, ça évite la aussi encore pas mal de test.
Mes bullets "avance toujours" (dans le sens ou j'additionne toujours une vitesse).
Pour les bullets qui sort de l'écran , j'utilise astucieusement la résolution de la SNES , elle fait 256*224 du coup au lieu de faire 4 tests pour un bullet qui sort de l'écran (haut ,bas ,droite,gauche) , je n'en fait que 2 grâce à un and (gauche/droite et haut/bas).
L'autre point qui est spécifique à la SNES et qui causait pas mal de soucis de perf , c'est de gérer le 9 eme bits pour la position x , ce 9 eme bits pour le gérer est vraiment lourd (mais parfois indispensable) , sur un bullet je n'en vois pas l’intérêt donc je ne gère pas ce 9 eme bits.
Du coup si vous êtes attentif , vous remarquerez que les sprites "disparaît" quand ils sont au bord.

L'autre point qui sont les collisions.
On remarque deux choses tout les bullets font 8x8 (pour les ennemis) et que le ship à une collision de 10x10 (ou un truc du genre).
Donc je transforme ces deux hitbox rect/rect à un point/rectangle (ce qui réduit énormément le nombre de test) , et ensuite la aussi en dépliant la boucle , je fais le test de mes 76 bullets ennemis.

Je fais pareil pour les tir joueurs/ ship ennemis.
En terme de code , ça permet de faire un code assez rapide/concis (j'ai rajouter les commentaire pour y voir plus clair) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
	;collision de Y Haut/Bas	
	lda LKS_BULLET.Y+1+(2*\1),x
	and #$FF
	cmp MEM_TEMP+0
	bmi +
 
	cmp MEM_TEMP+2
	bpl +
 
	;collision de X droite/gauche	
	lda LKS_BULLET.X+1+(2*\1),x
	and #$FF
	cmp MEM_TEMP+4
	bmi +
 
	cmp MEM_TEMP+6
	bpl +
 
	;collision renvoi la valeur x qui indique quel est le bullet qui a eu la collision
	stz MEM_RETURN+0
	stx MEM_RETURN+2
	ldx #(2*\1)
	stx MEM_RETURN+4
 
 
	rts
	+:

Pour finir , j'utilise bien sur des nombres à virgules fixe , deux type un 14.2 (pour les sprites en général , genre ship/ennemis) et un 8.8 pour les bullets.
Et pour l'anecdote , la PS1 faisait la 3D seulement avec des nombres à virgules fixe 16 bits du 12.4
La PS2 aussi utilisait les nombre à virgule fixe 16 bits (12.4 ,8.8 et du 1.15) mais pas pour les calculs seulement pour compresser les données et donc envoyer le moins possible .

Je vous met la démo disponible ici : https://www.mediafire.com/file/fyzwx...erDan.zip/file
C'est beau mon zip ne fait que 29 ko !
touche A pour tirer , B pour le Laser , Y pour faire revenir tout les ennemis , L/R pour Up/Down votre arme , select pour être invincible.
Si ma ROM fait actuellement 512ko ce n'est pas parce que j'ai rempli tout , mais juste que mon Linker (le machin qui me permet de tester sur la vrai SNES) ne supporte pas les ROM inférieur à 512 ko
Je dirais que je n'ai que 80ko rempli pour le moment

Voilà , ben merci pour ceux qui on eu le courage de tout lire

[ohnomorejmmings]

le programmeur peut décider de faire clignoter les sprites (ce qui était courant sur la Nes).

Hé ça arrive pas plutôt quand on vient de se faire toucher dans The Legend of Zelda ou Metroid ?!

sprite software quasi impossible (le cpu est trop long et pas de framebuffer , et les data des sprites sont encodé beaucoup trop bizarrement pour avoir un truc rapide)

J'avais même pas posé la question même si ça me démangeait. C'est à ce prix que la SNES a permis de nous servir d'aussi belles perles !

Donc au final je ne peux pas vraiment augment ce chiffre significativement de 100 bullets.

Certes mais si c'était vraiment nécessaire de passer ce mur tu aurais quand même un peu de marge. Par exemple contre un boss tu en gagnes 12 des ennemis. Enfin si c'est juste un plan en réalité ! Après maintenant que j'ai essayé la démo quand il y en a 40-50 à l'écran on se sent déjà en enfer.

Pour les bullets ,tu me parle de laser , j'en ai fait un (voir la première vidéo ou ma démo a la fin de mon pavé)

Efficace mais son rendu est pas terrible. Trop pixelisé ? Peut-être aussi trop large dès le début mais c'est peut-être parce que je ramène tout à DonPachi !! Sinon c'est bien un plan alors ?!

le mode le plus utilisé est le Mode 1 (celui que j'utilise) , il permet d'avoir 3 Backgrounds !

Et le Mode 5 ? Ça permettrait de passer en "haute résolution" donc de se rapprocher du fameux mode TATE des bornes d'arcade. Après peut-être que les contraintes deviennent trop nombreuses mais 2 plans c'est déjà pas mal car le plus important c'est l'arrière-plan même si un au-dessus ça fait plus classe. Après dans un manic la priorité c'est la lisibilité non ??

le ship à une collision de 10x10 (ou un truc du genre).

Habitude oblige c'est l'un des premiers trucs que j'ai vérifié. Pourquoi 10 et pas 8 ? Sinon ça serait pas mal de dessiner la hitbox plus clairement.

Je vous met la démo

Sympa ! Testée sous ZSNES :

• Son : J'en ai pas eu mais j'imagine que c'est normal à ce stade.
• Bug : Je me suis mis en face du dernier ennemi afin de tester la trajectoire de ses boulettes et elles passaient juste à ma gauche sans me toucher. Bizarre car la précision de ta virgule fixe est élevée.
• Boulettes clignotantes : Je suis pas fan c'est trop psychédélique. Lisibilité ! Par contre pour les bonus ça sera utile afin de les repérer au milieu du déluge…
• On peut pas changer la puissance du laser comme celle du tir
• Si le laser interrompt le tir pourquoi pas utiliser un seul bouton ? On laisse appuyer et on passe en mode laser… Désolé c'est encore du DonPachi mais j'ai laissé les 2 boutons appuyés car je suis très vicieux !!
• Cool le petit détail des tirs s'éloignant les uns des autres

Merci pour tous ces détails et ça m'a rendu curieux au point que j'ai découvert ton super article : Programmer sur SNES. Petite session de rattrapage pour les personnes passées à côté !

[Kannagi]

Alors effectivement pour le moment je trouve que avec 40-50 bullets , ça rempli deja bien l'écran (sûrement à cause de la petite résolution).
Avec 76 , ça rend les choses assez compliqué

Pour le Laser c'est temporaire , je l'ai fait en 5 min sut GIMP , j'en ferais un plus beau et j'utiliserai probablement l’animation par palette pour lui donner un meilleur effet !
Le Laser n'est pas un plan , c'est plusieurs sprites

Alors le Mode 5 augmente la résolution que du BG mais pas des sprites
Ce qui est pas forcément très utile dans notre cas.

Je pense modifier le sprite de ship pour voir plus clairement la hitbox , après vérification j'ai fait comme ceci : hitbox de 7x7 pour le ship et du 3x3 pour les bullets.

Pour le bug , ce n'est pas vraiment un , disons que ce n'est pas évident de faire un calcul de trajectoire sur une machine pareil.
Disons que j'ai un peu trop privilégier la vitesse constante des bullets au détriment de la précisions.
Je compte bien sur faire plusieurs puissance de laser de 1 à 4 et comme Dodonpachi , je tenterai de faire un mega Laser
Content que tu aime l'effet de tir qui s’éloigne ^^

Mon article ,après quelque années , j'ai un peu honte de quelque passage qui ont un peu approximatif
Mais dans les grandes lignes , il est correct

PS: Ah oui , je m'inspire bien de Dodonpachi du mieux que je peux en tout cas

[ohnomorejmmings]

Pour le Laser c'est temporaire , je l'ai fait en 5 min sut GIMP , j'en ferais un plus beau et j'utiliserai probablement l’animation par palette pour lui donner un meilleur effet !

L'astuce pourrait bien rendre ! Sinon le laser bleu de Raiden est plutôt sympa surtout à pleine puissance. Quand on se déplace ça le découpe en morceaux.

Alors le Mode 5 augmente la résolution que du BG mais pas des sprites
Ce qui est pas forcément très utile dans notre cas.

Certes mais ça permettrait de simuler une résolution verticale non ? Puis si vraiment les boulettes deviennent trop microscopiques, ce dont je doute, il y a toujours ta super technique des métasprites. Euh non ça réduirait considérablement leur nombre… Enfin je n'ai pas souvenir d'être tombé sur un titre SNES en HD alors il doit y avoir une raison.

Content que tu aime l'effet de tir qui s’éloigne ^^

Si tu parviens à reproduire la pluie du tir de base à pleine puissance dans Raiden je milite pour qu'on te remplisse ta 6e étoile sur le forum !!

PS: Ah oui , je m'inspire bien de Dodonpachi du mieux que je peux en tout cas

Elle est dingue cette série et encore je ne connais que très peu de ses titres ! Comme aucun n'est sorti sur SNES et que ceux sur PSX ramaient c'est d'autant plus un défi ton projet. Supa Dan ! Supa Dan !!

[Kannagi]

L'astuce pourrait bien rendre ! Sinon le laser bleu de Raiden est plutôt sympa surtout à pleine puissance. Quand on se déplace ça le découpe en morceaux.

Je note ça

Certes mais ça permettrait de simuler une résolution verticale non ? Puis si vraiment les boulettes deviennent trop microscopiques, ce dont je doute, il y a toujours ta super technique des métasprites. Euh non ça réduirait considérablement leur nombre… Enfin je n'ai pas souvenir d'être tombé sur un titre SNES en HD alors il doit y avoir une raison.

Tu n'as pas compris ah ah , non la taille des sprite ne changera pas mais celle du BG oui (qui sera elle bel et bien en 512*448).
En général c'était utilisé pour les menu, une image faut mille mots donc voici un exemple :

(le perso reste un sprite , je crois que c'est un 16x32)

Si tu parviens à reproduire la pluie du tir de base à pleine puissance dans Raiden je milite pour qu'on te remplisse ta 6e étoile sur le forum !!

Cela m’intéresse , je tenterai ça !
La semaine prochaine , vu que cette semaine , je suis débordé ^^'

Elle est dingue cette série et encore je ne connais que très peu de ses titres ! Comme aucun n'est sorti sur SNES et que ceux sur PSX ramaient c'est d'autant plus un défi ton projet. Supa Dan ! Supa Dan !!

Ce qui est assez étonnant pour une PSX , elle avait de quoi gérer des sprites en hardware (et non comme de nos jours des triangle ou tri_strip pour faire un sprite), mais surtout que c'était beaucoup plus puissant qu'une borne d'arcade (d'ailleurs l'arcade a perdu pas mal d’intérêt après la PS1).
Le système de cave en borne d'arcade était assez semblable à une Neo Geo (enfin légèrement plus puissant)
Pour te donner une idée :
CPU M68000 de 16 Mhz (celui de la Neo geo fait 12MHz ),64 ko de RAM , un Z80 pour le proc sonore.
Possède quand même 3 BG en hardware (la Neo Geo en a aucun , enfin sauf un pour le hud donc aucun scrolling possible dessus et il est associer à une petite rom de 128ko) et comme la NG il gère 4096 couleurs (sûrement 256 palettes).
Après la borne est sorti en 1994 , la Neo Geo en 1989 et la PSX en décembre 1994
La PS1 c'est un proc MIPS de 33MHz (et donc plus performant qu'un M68000 à fréquence égal , alors si il y'a le double) , il avait aussi un co-processeur pour gérer les calculs 3D, 2 Mo de RAM et 1 mo de VRAM.

Donc ce n'est pas forcément possible de faire un DonPachi sur SNES , mais je tente de faire du mieux que je peux deja parce que Donpachi affiche de plus gros sprite de 32x32 et qu'il y'a plus de 100 bullets à l'écran

Et merci encore pour ton soutient et ton intérêt sur mon projet

[Kannagi]

Voilà quelque news , j'ai intégrer le tir style Raiden :

Je trouve que ça rend bien

Sinon actuellement je travaille sur mon driver sonore , en gros le SPC700 qui gère le son ne possède que 64Ko , et dans ces 64 ko comprend le code du driver ,sa RAM , les track (la partition si vous voulez) et les samples des musiques et les SFX

J'ai compresser pas mal pour avoir au final :
-240 octet de RAM
-un peu moins d'un ko pour le header et les pointeurs sur les samples
-4ko de code pour le driver
-11ko réservé pour le track
-48ko pour les Samples (16 pour les music et 32 pour les SFX , cela peut être légèrement modifiable)

J'avais fait un premier test ici :
music_sfc.zip
(ne pas utiliser ZSNES qui ne lis pas vraiment bien mon driver lol )

Pour résumé :
Zelda et SoM sont en .xm
Zelda GB et thunderforce sont en .mod
Castlevania du .s3m
World of Demon du .it

Pour les tailles nous avons :
Zelda SNES: 4.4 Ko
SoM: 8.6 Ko
Zelda GB: 0.8 Ko
Thunder Force: 3.8 Ko
Castlevania: 2.7 Ko
WoD: 2.7 Ko
Et pour le .it , certain sample sont compressé (quand ça ne l'ai pas , c'est facile c'est du PCM standard ) , et même en copiant le code source de certain tracker , ben ça décompresse toujours pas

Sinon après quelque debug, le .mod et le .it sont assez mal lu , j'ai régler le souci mais j'ai pas refais une ROM du coup
Du coup vous avez une ancienne version
J'ai intégrer qu'on puisse jouer des SFX pendant la music , ça n'a l'air de rien comme ça mais c'est pas forcément évident vu que les SFX et la musique partage les même canaux !
Les SFX sont gérer de façon dynamique , en gros par défaut le SFX est joué sur le canal 8 , si le canal 8 est occupé , il le joue sur le 7 , si 7 occupé alors le 6 etc etc

Actuellement me reste les différents effets à integrer donc j'ai fait un petit texte ce que je compte mettre :

0 Appregio
1 Tone porta
2 Vibrato
3 Tremolo
4 porta up
5 porta down
6 Volume slide
7 Tone porta+Volume slide
8 Vibrato+Volume slide
9 panning
A finetune
B
C
D
E
F

J'ai donc créer un tools de conversion .mod/.xm/.s3m/.it qui convertie sur un format SNES.
Le tools peut même faire une sortie d'une ROM SNES pour pouvoir écouter sur un émulateur

NT : le .mod/.xm/.s3m/.it sont des "anciens" format pour jouer des partitions ,ils sont assez semblable au midi mais ils contiennent des info en plus + les Samples associés

[Kannagi]

J'ai fait une vidéo dernièrement sur l'avancement du projet :

Ce qui est fait en plus :
-j'ai fait la compression de map vu que j'ai une map de 16x1024 tiles , soit 256x16384 pixels !
En brut (avec des tiles de 16x16) cela fait 32ko (sur MD cela ferait 128ko sans meta-tiles) , mais 32ko c'est beaucoup quand meme , donc j'ai compressé la map et elle me donne 8ko ! ^^
pareil pour la map de collision , en brut elle donne 16ko , en compressant elle me fait que 300 octets ! :p
(bon aussi y'a pas grand chose mais ça donne une idée ).

-rajout du scrolling me coûte quasiment rien (moins de 1% CPU) , sachant qu'il est update en VRAM.

-j'ai mis les collisions bullets/tiles donc ça demande un update en RAM et en VRAM , mais j'ai de bonne perf quand même
(pour des soucis de perf ,j'upload qu'une ligne par frame) , de nos jours on se fait pas autant hciser pour effacer un truc à l'écran ! xD

-pour les collisions cela donne donc 220 test/frame , sacré chiffre n'est ce pas ?

-Je suis passé en FastROM (donc la SNES cadencé à 3,58 MHZ sur certaine instruction) donc de 61% je passe à 50% (dans la vidéo y'a 51% mais j'ai rajouté quelque truc entre temps) , d'ailleurs si j’enlève l'attende de la fin du VBlank , je tombe à 42% ^^
Mais content d'avoir autant de % , parce que je doute que les pattern ennemi (qui est du precalculer) va me prendre beaucoup en %CPU , je me demande ce que je pourrais rajouter pour exploiter la SNES sur ce coup lol
Pour ça que j'ai rajouté les collisions bullet/tiles , mais ça me prend au mieux 2-3% en plus au max
Je pense que j'utiliserais les 50% CPU restant pour faire des patterns plus élaboré ^^
D'un coté je suis content ,de l'autre un peu déçu , je pensais exploiter la SNES à fond avec un Danmaku

-d’après mes calculs , je pense que la ROM final pourra rentrer dans 1 Mo !
(vu que les map sont compresser et que les tracks ne prendra quasiment rien entre 4-8 ko)

Et pour finir voilà l'éditeur Tiled que j'ai personnalisé pour pouvoir faire une map + gestion des collisions + gestion des ennemis
https://2img.net/image.noelshack.com...2-screensd.png

[LittleWhite]

Bah, il y a toujours la possibilité d'ajouter des bullets

[Kannagi]

Pas vraiment non , je suis à la limite de la SNES niveau affichage.

Je suis actuellement à :
-100 bullets (100 sprites)
-12 ennemis (12 sprites)
-le ship principal donc 1 sprite
Donc 113 sprites sur 128 dispo.

Je suis en mode 8/32 (sprite de 8x8 ou 32x32), donc pour faire des sprites 16x16 je suis obligé de faire un meta sprite et je veux en avoir 3 minimun donc cela va me prendre 12 sprites pour les bonus.
Je comptais utilisé les 3 derniers pour quelque GFX :p

On peut toujours tenté de rogner un peu sur tout et de monter avec quelque bullet en plus , mais c'est pas ça qui fera un gros changement niveau visuel.
(pas sur que de passer de 100 à 104-107 bullet soit quelque chose de fou lol).

[ohnomorejmmings]

Désolé pour le retard…

Voilà quelque news , j'ai intégrer le tir style Raiden : […] Je trouve que ça rend bien

Sympa ! Par contre forcément c'est une contrainte en plus des boulettes. Avec le vaisseau bleu de DonPachi la nuée de tirs est encore pire car au maximum ça recouvre quasiment tout l'écran. En plus ils sont beaucoup plus gros alors techniquement c'est sans doute impossible à reproduire avec les sprites de la SNES. Sinon pour les puristes je crois que tu ne t'es pas reposé sur la version arcade de Raiden. Non ? Enfin le portage SNES est très bon je crois !!

J'avais fait un premier test ici : […] (ne pas utiliser ZSNES qui ne lis pas vraiment bien mon driver lol )

Au premier essai avec Snes9x 1.51 j'ai eu que 3 notes de Zelda mais après aucun problème. La lecture est plutôt fidèle et c'est sympa d'entendre l'opus GB ! Comme autre titre je te conseille aussi le cultissime Donkey Kong Country. Un vrai chef d'œuvre idéal pour éprouver ton code !!

Idées :

• Supporter le maintien de l'appui sur un bouton question d'accélérer les réglages
• Compléter l'aide pour indiquer que L et R permettent de changer de musique

J'ai donc créer un tools de conversion .mod/.xm/.s3m/.it qui convertie sur un format SNES.
Le tools peut même faire une sortie d'une ROM SNES pour pouvoir écouter sur un émulateur

J'ai pas compris la 2e phrase. Ça extrait la musique d'une ROM ? Sinon bonne idée la conversion depuis un module. J'avais lu des trucs intéressants sur le sujet. Comment notamment la musique de DKC avait été créée. C'était pas rien à l'époque car il fallait composer et coder !

Sinon ta dernière démo en jète. J'adore quand tu déclenches le tir Raiden et que ça explose toutes les tuiles. Par contre avec la vidéo quand le vaisseau se fait toucher comme il clignote on le perd un peu. Pour repousser les limites de la SNES ça serait fou de viser 200 boulettes à l'écran ? J'ai bien compris tes explications mais autant se taper un délire. Après en effet pourquoi pas des motifs plus élaborés. J'ai aussi pensé à des boulettes de couleurs différentes voire même de tailles !

Bravo et bon courage !!

PS : Je profite d'avoir des musiques de shmup dans la tête pour m'interroger sur l'impact de la lecture d'une musique et des sons sur les performances justement… Hein hein oh yeah !!

[LittleWhite]

Je vois, c'est du temps CPU que vous avez en trop, mais pas de l'affichage. Y a pas moyen d'utiliser le CPU pour faire des effets graphiques (dans le style de ce qui se ferait avec un shader de nos jours). Cela pourrait être utilisé pour faire un rendu d'eau sur la map, ou déformer le rendu autour des explosions ou je ne sais quoi.

[Kannagi]

Merci de tes réponses complètes

Désolé pour le retard…
Sympa ! Par contre forcément c'est une contrainte en plus des boulettes. Avec le vaisseau bleu de DonPachi la nuée de tirs est encore pire car au maximum ça recouvre quasiment tout l'écran. En plus ils sont beaucoup plus gros alors techniquement c'est sans doute impossible à reproduire avec les sprites de la SNES. Sinon pour les puristes je crois que tu ne t'es pas reposé sur la version arcade de Raiden. Non ? Enfin le portage SNES est très bon je crois !!

Oui la SNES ne peut pas reproduire la version arcade , pour le tir j'ai tenté d’être le plus proche possible ^^'

Au premier essai avec Snes9x 1.51 j'ai eu que 3 notes de Zelda mais après aucun problème. La lecture est plutôt fidèle et c'est sympa d'entendre l'opus GB ! Comme autre titre je te conseille aussi le cultissime Donkey Kong Country. Un vrai chef d'œuvre idéal pour éprouver ton code !!

Idées :

• Supporter le maintien de l'appui sur un bouton question d'accélérer les réglages
• Compléter l'aide pour indiquer que L et R permettent de changer de musique

J'ai pas compris la 2e phrase. Ça extrait la musique d'une ROM ? Sinon bonne idée la conversion depuis un module. J'avais lu des trucs intéressants sur le sujet. Comment notamment la musique de DKC avait été créée. C'était pas rien à l'époque car il fallait composer et coder !

Je tenterais de faire ces MAJ pour le prochain lecteur
Pour les musics ,je note si je trouve la music de DKC
Cela veut dire que par exemple mon tools transforme par exemple le.mod en une ROM SNES (où un .midi si tu préfère), c'est plus pratique pour voir ce que ça donne pour le compositeur ^^
Mais ouais à l'époque c'était moins évident , de nos jours on a plus de tools pour ça

Désolé pour le retard…

Sinon ta dernière démo en jète. J'adore quand tu déclenches le tir Raiden et que ça explose toutes les tuiles. Par contre avec la vidéo quand le vaisseau se fait toucher comme il clignote on le perd un peu. Pour repousser les limites de la SNES ça serait fou de viser 200 boulettes à l'écran ? J'ai bien compris tes explications mais autant se taper un délire. Après en effet pourquoi pas des motifs plus élaborés. J'ai aussi pensé à des boulettes de couleurs différentes voire même de tailles !

Bravo et bon courage !!

PS : Je profite d'avoir des musiques de shmup dans la tête pour m'interroger sur l'impact de la lecture d'une musique et des sons sur les performances justement… Hein hein oh yeah !!

Merci , comme je l'ai dit la SNES ne peut pas afficher plus de 128 bulelts, c'est sa limite max !
De plus si je ne les fait pas plus gros, c'est que la SNES est limité à 272 pixels/line au delà ça s'efface (le programmeur peut choisir que ça clignote , mais ça bouffe du temps CPU ).
Le truc c'est que bon des bullets qui s'efface ,c'est vraiment problématique
Pour cela que même si techniquement c'est faisable de faire plus gros , dans les faits on aura plein de truc qui va clignoter ou s'effacer :/

Alors sur les consoles 8 bits les musiques avait des impacts sur les perf du jeu , mais les consoles 16 bits toute ont un processeur dédié pour le son, la SNES à le SPC700 (un proc assez proche d'un 6502 cadencé à 1 Mhz) c'est un processeur qui communique avec le chip audio , il a sa propre RAM/ROM donc fonctionne en parallèle à celui de la SNES.
Donc pour te répondre : les musics/son n'ont aucun impact sur les perfs
La plus grosse difficulté ,c'est de casser tout le bouzin sur 64ko (driver+RAM+Musique+SFX)

Je vois, c'est du temps CPU que vous avez en trop, mais pas de l'affichage. Y a pas moyen d'utiliser le CPU pour faire des effets graphiques (dans le style de ce qui se ferait avec un shader de nos jours). Cela pourrait être utilisé pour faire un rendu d'eau sur la map, ou déformer le rendu autour des explosions ou je ne sais quoi.

Exact , malheureusement on ne peut pas vraiment utiliser ce temps CPU pour modifie le rendu , et on ne peut pas vraiment faire du sprite software avec
C'est un peu comme Atari ST vs Amiga , l'Amiga ne faisait que très peu de 3D parce que c'est un bitplane et la SNES aussi donc faire une mofif pixel par pixel prend trop de temps CPU ! :p

Je compte pour le moment tenter de finir un stage + pattern complexe (qui prend pas mal de temps CPU vu que ça se fait sur chaque bullet) , apres je regarderais ce que je peux faire avec ce qui me reste

[ohnomorejmmings]

Y a pas moyen d'utiliser le CPU pour faire des effets graphiques (dans le style de ce qui se ferait avec un shader de nos jours). Cela pourrait être utilisé pour faire un rendu d'eau sur la map, ou déformer le rendu autour des explosions ou je ne sais quoi.

J'ai repêché cette info postée avant :

sprite software quasi impossible (le cpu est trop long et pas de framebuffer , et les data des sprites sont encodé beaucoup trop bizarrement pour avoir un truc rapide)

Quasiment donc mais sans accès direct aux pixels je vois pas comment on pourrait afficher ne serait-ce qu'un sprite supplémentaire. Après peut-être que j'ai mal compris. J'espère !

Pour de l'eau comme solution il y a les plans transparents avec des tuiles animées. D'où la lave de Super Metroid, les nuages incroyables de nombreux titres… Quant à une déformation c'est une bonne idée mais il faudrait pouvoir manipuler les pixels ou alors bidouiller quelque chose avec des tuiles spéciales ou je ne sais quoi.

Oui la SNES ne peut pas reproduire la version arcade , pour le tir j'ai tenté d’être le plus proche possible ^^'

Je voulais parler du sprite pas du motif ! Ce dernier est très bien. À vérifier mais je me souviens de couleurs plus flamboyantes. Du rouge au jaune ?!

Pour cela que même si techniquement c'est faisable de faire plus gros , dans les faits on aura plein de truc qui va clignoter ou s'effacer :/

Quand même un pourcentage raisonnable de boulettes de 16x16 ça me semble possible ! 10% ? 20% ?? Qui dit plus ?! 272 pixels par ligne ça laisse de la marge car 34 boulettes de 8x8 peuvent être affichées !!

Exact , malheureusement on ne peut pas vraiment utiliser ce temps CPU pour modifie le rendu , et on ne peut pas vraiment faire du sprite software avec

Grrr j'aime pas du tout cette réponse !!!

C'est un peu comme Atari ST vs Amiga , l'Amiga ne faisait que très peu de 3D parce que c'est un bitplane et la SNES aussi donc faire une mofif pixel par pixel prend trop de temps CPU ! :p

Ah non même sur 500 on pouvait faire des choses incroyables en optimisant bien. Comme sur ST la liberté de traitement des pixels était totale !

[FlashLogic]

Salut Kannagi

Pas de souci sur le côté technique, tu as l'air de clairement maîtriser ton sujet

Maintenant il faut développer pour les joueurs. Une bonne technique ne suffit pas pour créer un bon jeu. Le joueur ne va pas compter le nombre de boulettes à l'écran. Le joueur est du côté émotionnel.

Ayant en tête de faire un shoot moi même, j'avais analysé de grands shoots (R-type, Last Resort, Blazing Star...) pour voir les grands traits qui ressortaient (voir fichier en PJ).

Je m'étais fait un poster avec plein de type de tirs différents.



Plein de captures d'écran de jeux à des moments épiques pour tenter d'analyser pourquoi ces scènes étaient épiques (ambiance, décors, couleurs...)

J'ai regardé beaucoup de vidéos GDC pour apprendre le game design, notamment cette conf de Mark Rosewater (que je regarde encore) et qui reste pour moi une énorme claque:

Bref changer de casquette, changer d'état d'esprit.

Hâte de voir la suite

[ohnomorejmmings]

Maintenant il faut développer pour les joueurs. Une bonne technique ne suffit pas pour créer un bon jeu. Le joueur ne va pas compter le nombre de boulettes à l'écran. Le joueur est du côté émotionnel.

Ah mais si dans ce cas en particulier la quantité est essentielle ! Non seulement parce qu'il s'agit d'un danmaku mais aussi parce que c'est un défi technique à relever. Pour les émotions ça dépend ce que t'entends car par exemple en jouant à des titres cultes comme DonPachi on se marre, s'énerve, se fait des sueurs froides… La variété est au rendez-vous ! J'ai même pleuré de joie en atteignant le niveau 2 sans perdre de vie pour la première fois !!

Pour ton projet merci de partager avec nous mais pourquoi ne pas lui dédier une discussion ? Ça serait dommage qu'il reste un peu perdu, même si en bonne compagnie, alors que t'as déjà une vision et des ressources de travail… D'autres pourraient y contribuer en plus rien qu'en postant.

Bon courage à tous les deux et vive les shmups !!