Super Dan

[Invité]

Ben je le poste ici , vu qu'il y'a eu beaucoup de débat MD vs SNES ,et effectivement il est vrai que la SNES souffre du manque de shmup et en plus certain d'entre eux rame pas mal.

Du coup j'ai fait une démo pour voir si c'était possible de faire un manic shooter sur SNES (oui certain sont fou ).

Alors ben voici  les résultats :





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

La première vidéo , c'est un test pour voir si un boss en BG , ça passe bien + Bullet
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  mais avec une vitesse constante cette fois ci (pas le cas du premier).
Et tout ça sans ramer

Certain me conseille de le continuer , moi je voulais juste tester rapidement si c’était possible (la démo ne date que de quelque jours) , mais bon ça me trottait tellement dans la tète que j'ai voulu le mettre en pratique.
Du coup je vais tenter de faire un niveau jouable pour le moment c'est un bac à sable et j'ai pas beaucoup d'idée de pattern (enfin si , mais en faire des jolies et facile à prog , c'est pas évident ).

Voilà voila

[Urbinou]

Je n'ai aucun intérêt dans la SNES (j'en ai pas), mais ce serait dommage de s'arrêter en si bon chemin

[ace76]

Jamais vu autant de bullets sur une Snes,par contre elles vont pas bien vite.
Comme quoi.

[Invité]

Merci de vos retours

Jamais vu autant de bullets sur une Snes,par contre elles vont pas bien vite.
Comme quoi.

ça troll deja
Je peux augmenter la vitesse des bullets , cela n'a aucun impact sur les perfs.
On m'avait fait une blague , où je devais expliquer pourquoi les bullets sont long, sinon les gens croiront que c'est parce que la SNES est lente

Alors la plupart des shmup sur consoles 8/16 bits augmente la vitesses des bullets justement parce qu'il peuvent pas en gérer beaucoup
Donc si tu préfère vitesse de bullets rapide = jeux a la ramasse niveau optimisation

Ben oui s'il je les fait rapidement , y'a moins de bullet à l'écran logique :)
Et c'est moins incroyable de dire je gère 50 bullets  que 100 (parce que pour que 100 bullets reste à l'écran ils doivent pas quitter l'écran trop rapidement).

Après pour un jeux réel à  voir , mais je pense que pour les boss , des bullets nombreux et long , c'est plus facile pour esquiver

[ace76]

Non,je trolle pas,c'est du beau travail .COMME QUOI,quand la bécane est bien codée....

[Tryphon]

Je demande à voir avec les collisions (pour l'instant tu ne testes que les collisions avec le joueur, ça fait un test par bullet ennemie)

D'ailleurs, tu testes toutes les frames ? (ça m'étonnerait vue la vitesse des sprites).

Même si tu dois réduire le nombre de bullet, ça resterait très au-dessus en terme de densité du STU SNES classique.

J'avais essayé une démo MD où les bullets seraient des "sprites softs" (juste un tracé sur un plan, vu comme un framebuffer) pour pouvoir atteindre 100 bullets, mais c'était clairement pas assez rapide.

Peut-être qu'on peut utiliser le multiplexing, ou alors afficher les bullets une frame sur deux (au prix d'un effet de clignotement).

C'est cool de voir ça sur SNES

[Invité]

@ace76 Oh ok excuse moi alors
Oui effectivement , quand on la code bien on peut faire de jolie chose :)
Apres il y'a pas mal de jeux qui était bien codé , c'était plus rare pour le shmup (mais Super Aleste montre bien que le shmup sur SNES était largement faisable ).

Ben la vidéo date un peu , mais j'ai fait le code avec les bullets/ennemis , ça monte vers 65% de CPU
(Mais je peux encore optimiser certaine partie).

Je ne fait qu'un test sur deux (vu le nombre de bullet , un peu obligé) , mais bon la contrainte est pas énorme , il faudrait une vitesse d'un bullet de 16px ou plus pour que ça "bug"

[Tryphon]

16px c'est la taille de la hitbox du vaisseau ?

[Invité]

Non , 8 pixel la hitbox du ship et 8 pixel la box du bullet

[Tryphon]

Je pensais que les bullets étaient des points...

[Invité]

Ah oui par rapport a ce que j'avais dit avant je suppose ?
(que je fais des test point/rectangle ?)
Pour que les tests point/rectangle soit équivalent à un rectangle/rectangle , il faut agrandir la hitbox.

Donc oui en interne il fait du 1/16 , c'est peut être un peu complexe , mais j'ai juste fait une fonction qui marche d'un point de vue extérieur à du rect/rect , puis elle convertie ça pour du point /rectangle ^^

Parce que bon , c'est plus facile pour moi (ou pour d'autre qui voudrait utiliser ma lib) de raisonner en rect/rect , même sur Super Papi ou mon A-RPG quand j'ai une collision 16x16/32x32 par exemple , j'indique à ma fonction 16x16/32x32 ,et en interne elle ne fais que du point/rectangle (comme je l'ai dit ça calcul la bonne hitbox qui est équivalente à un rect/rect).

[Invité]

Non,je trolle pas,c'est du beau travail .COMME QUOI,quand la bécane est bien codée....

Bon c'est pas faute de l'avoir dit 50 fois, mais bon 
Par contre faut aussi arrêter de pense que sur snes seul le CPU est le fautif, kannagi l'expliquera mieux que moi, mais tu perds aussi pas mal de CPU à gérer la mauvaise organisation des sprites au niveau hard, donc forcement avec un CPU à 2.6 mhz c'est pas top .

Au fait kannagi, c'est en slow rom ta démo ??

[Invité]

Exact Touko

Oui c'est en slow rom , je devrais un jour testé en fast rom pour voir la dif de performance un jour (mais c'est pas évident de faire une fastrom sur SNES)

[Invité]

Sinon c'est clair qu'il faut que tu continues (plus facile à dire   ), faire un caravan sympa ne prend pas autant de temps qu'un vrai shoot, après c'est toujours plus délicat qd tu as la vie de tous les jours plus d'autres projets en cours .

[White Ninja]

Il s'agit d'un très beau projet que nous suivons de très près @Kannagi et même s'il y a encore beaucoup d'éléments et de fonctionnalités à intégrer au moteur, c'est déjà très impressionnant de voir autant de sprites sur Super Nintendo.

Nous avons hâte de découvrir les prochaines avancées de ton moteur et bien évidement, tu peux compter sur notre soutient.

[Invité]

Merci pour ton soutiens

Voilà ce que ça donne avec 12 ennemis :


On va atteindre bientôt les 128 sprites par contre

Et je pense que c'est jouable pour faire un jeu , je pense

[Invité]

Voilà le résultat actuel :


J'ai fait pas mal de modif en interne , réduction de la hitbox , animation des bullets et collisions du lasers.

Ah bien sur j'ai optimiser pas mal , je tombe donc à 56%

Et je vous met la démo disponible !
Pour les touches :
A pour tirer
B pour le Laser
Y pour refaire vivre les ennemis
Select pour être invincible
Start pour la pause
L/R pour le up/down de l'arme

Lien : https://www.mediafire.com/file/ue3yujp7703xd67/SuperDan.zip/file

[Invité]

56%, t'as gagné 10%, c'est pas mal du tout ça .. 

[Invité]

Oui sacré optimisation.

J'ai rajouté un nouveau tir a la Raiden :


Sinon , pas trop de nouvelle niveau code mais je bosse sur le driver sonore.

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 test
(ne pas utiliser ZSNES qui ne lis pas vraiment bien mon driver lol )
Je vois les grands spécialiste de musique d'ici , alors avant toute chose c'est une version beta qui a encore besoin d’être debugger

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
Donc 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 à intégrer 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

[White Ninja]

Cela semble très différent du fonctionnement sur Mega Drive, mais c'est du très bon boulot ! Le gain de taille est énorme surtout quand on sait que les musiques d'un jeu peuvent rapidement occuper de la mémoire ROM quand elles se font nombreuses.

En espérant te voir continuer à améliorer ton driver et aussi continuer le développement de Super Dan qui s'annonce vraiment très prometteur.

[Invité]

Good job dude 

[lincruste]

Je viens de tester avec bsnes. Ça m'impressionne.

[Invité]

Merci pour vos retours
Oui le fonctionnement du son sur MD est totalement différents

Je met le lien de la dernière maj ici : SuperDan

Ça m'impressionne.

Je m'en rend pas compte pour moi c'est limite normal , même si je sais qu'il y'a pas d'équivalent sur SNES ^^