SuperDan

[Invité]

Je l'avais deja représenté sur un autre topic , mais je vais le présenté ici dans la partie prog pour parler des détails techniques

Donc je suis en train de faire un danmaku sur SNES , 100 bullet à l'écran 12 ennemis et 1 ship pour un total de 113 sprites !  
(cela fera 128 sprites à la fin vu que je rajouterais les bonus + quelque effet )

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


Avec un tir à la Raiden , on voit mieux le nombre de bullet disponible

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 bcp 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 ).

-le 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).

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

-Je suis passé en FastROM 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% ^^
Je vais croire que la SNES à un blast processing intégrer
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’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

[Invité]

C'est nul le 65816 

[drfloyd]

énorme !!!!!

[Ricco59_59]

oui, ENORME

[mic]

Dit comme ça On dirait presque que c'est facile en faites

[Invité]

Merci beaucoup pour vos retours

Oui comme on dit ,sur le papier c'est toujours plus simple lol

Il faudra que je finisse la gestion de map pour les ennemis, après faudra coder un petit tools pour gérer les patterns ennemi ^^'

[Invité]

C'est toujours plaisant d'avoir des gens qui s'intéressent à la snes, et surtout qui montrent autres choses que des pongs codés en C .

PS: Je n'ai rien contre les pongs codés en C, mais bon au bout du 10 ieme, on zappe .

[drfloyd]

tu devrais nous en faire un Touko de Pong en C sur PC Engine... Car on attends toujours depuis 27 ans ton Chuck No Rice sur PC Engine CDROM 2  T'as temrné l'ecran d'accueil ?

(je plaisante)

quoi que 

[Invité]

tu devrais nous en faire un Touko de Pong en C sur PC Engine... Car on attends toujours depuis 27 ans ton Chuck No Rice sur PC Engine CDROM 2  T'as temrné l'ecran d'accueil ?

(je plaisante)

quoi que 

On est en phase de tests sur le vrai hardware, et quelques bugs à corriger hélas (alors que tout était bon sur émulateur), et du coup comme j'ai rien pour tester les CD (pour le moment) c'est assez fastidieux à corriger .

[drfloyd]

Le membre 'Touko' a effectué l'action suivante : Lancer de dés !

---

'SUPPOS DE LA FORTUNE' :

Résultat :

[Invité]

Je comprend mieux pourquoi tu voulais le linker qui fait CD du coup

Mais c'est pas une bonne idée de dev sur une machine sans pouvoir faire de vrai test sur le hard ! ^^'

[Invité]

Je comprend mieux pourquoi tu voulais le linker qui fait CD du coup

Mais c'est pas une bonne idée de dev sur une machine sans pouvoir faire de vrai test sur le hard ! ^^'

Bah ouai c'est ça ..

[lincruste]

@Kannagi
Désolé de pourrir ton topic avec cette question mais je pense que c'est pas très éloigné du sujet :
Est-ce que -avec ton expérience de programmation de la SNES- il te semble possible techniquement de réaliser une rom de test qui permettrait d'exécuter des fonctions visant un composant en particulier ?

Attention, je ne te demande pas du tout de faire ce travail, seulement si c'est possible techniquement avec l'architecture de la SNES.

Je te demande ça parce que pour l'instant quand une SNES tombe en panne, on ne peut que tester chaque élément individuellement : CPU, WRAM, VRAM,SPPU1,SPPU2.
Il y a bien une rom de test officielle de Nintendo qui circule, mais elle ne permet pas de préciser d'où vient la panne physiquement, d'où ma question.
Désolé encore pour le HS.

[Invité]

Salut,
Alors c'est un problème pour toute les consoles il n y'a rien pour test les composants (il n'ya pas de gestion d'erreur du hardware ).

Le seul truc qu'on peut test c'est la WRAM (lire/écrire et voir si y'a les bonnes valeurs).

[lincruste]

Ha mince. Bon ça explique pourquoi personne n'a fait de rom de test dans ce sens. En gros il reste que la sonde logique et les yeux pour pleurer.
Merci beaucoup pour ta réponse et encore désolé du HS.

[Invité]

@Kannagi
Désolé de pourrir ton topic avec cette question mais je pense que c'est pas très éloigné du sujet :
Est-ce que -avec ton expérience de programmation de la SNES- il te semble possible techniquement de réaliser une rom de test qui permettrait d'exécuter des fonctions visant un composant en particulier ?

Attention, je ne te demande pas du tout de faire ce travail, seulement si c'est possible techniquement avec l'architecture de la SNES.

Je te demande ça parce que pour l'instant quand une SNES tombe en panne, on ne peut que tester chaque élément individuellement : CPU, WRAM, VRAM,SPPU1,SPPU2.
Il y a bien une rom de test officielle de Nintendo qui circule, mais elle ne permet pas de préciser d'où vient la panne physiquement, d'où ma question.
Désolé encore pour le HS.

Il me semble que FFVIman utilise une rom de tests que nintendo utilisait, ça test pas mal de choses niveau hardware .
Une recherche rapide :
https://tcrf.net/SNES_Test_Program

[vingazole]

En brut (avec des tiles de 16x16) cela fait 32ko (sur MD cela ferait 128ko sans meta-tiles) , mais 32ko c'est bcp 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 ).

RLE ?

[Invité]

Oui ,c'est une compression RLE

[vingazole]

Tu es en haute résolution j'ai l'impression, coordonnées en 16 bits sur les deux axes du coup, non ?

[Invité]

Non même pas , je suis en basse résolution (256x224).
Mais j'utilise du 16 bits pour les virgules fixes :)
J'en utilise deux tout ce qui vaisseau/ennemi etc etc c'est de 14.2 et les bullets du 8.8.


D’ailleurs la compression RLE est facilement faisable sur SNES grâce à sa grande capacité de RAM (j'utilise 80 ko rien que pour 2 map + collision ).

[vingazole]

J'en utilise deux tout ce qui vaisseau/ennemi etc etc c'est de 14.2 et les bullets du 8.8.

C'est un peu chiant pour les collisions bullets/(vaisseau|ennemi), tu es obligé de décaler pour normaliser avant de comparer, non ?

[Invité]

Oui pour cela que j'ai fait des virgules fixe seulement avec 2 bits de virgule , pour réduire le coût du décalage.
Et pour les bullets , j'ai les 8 bits d'entier donc pas besoin de décalage.