Re: GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée)

[touko]

Seulement faire passer une question sur un bullet hell snes pour voir ce que la snes peut gérer comme sprites dans un shoot avec bcp de sprites,et faire passer ça pour une question sur un algo de test, chapeau, dans le style t'es une merde, tu fais fort là ..

Je réponds à une question qui m'était posée, et non je pose la question .

Donc oui, t'es clairement une merde 

[rocky007]

Donc oui, t'es clairement une merde 

olàlàlàààà  ..tu pleures maintenant ?


allez tiens encore pour toi, qu'ils sont cons tous ces gens qui racontent n'importe quoi :

https://www.vogons.org/viewtopic.php?t=79558

The SPC700 does not need an introduction for most folks, given how popular the SNES and Super Famicom continue to be. The SPC700 was first released with the Super Famicom in late 1990. It is a 16-bit wavetable synth that supports up to 8 channels of audio, and handles PCM digital sound playback as well. Unlike most sound chips of the day, the SPC700 is in reality a specialized 6502 CPU + DSP combination with a small amount of its own RAM. It meant that programmers could upload a song to its memory, send the play command, and then the music would play without any more intervention from the main CPU. The Super Famicom cost as much all together as a typical PC sound card did alone, so assuming Sony would have been willing to sell the SPC700 to anyone other than Nintendo, it would have been a very compelling sound card at a reasonable price in 1990!

 ou carrément mieux :

Le Sony SPC700 est un coprocesseur audio de 8 bits conçu par Ken Kutaragi et utilisé dans le Super Nintendo Entertainment System (SSN) du système de signalisation numérique (DSP) ainsi qu'un processeur de signal numérique (DSP). Le SPC700, avec sa DSP 16 bits associé, a été développé et fabriqué par Sony. Pour l'époque (1990), le SPC700 était très avancé et peut même être comparé à des cartes sons de synthétiseur Wavetable.

et là c'est génant, car c'est la page Wiki : https://de.wikipedia.org/wiki/SPC700

je serais toi, va vite corriger le Wiki, apparemment tu es le seul au mnnde à avoir la vérité sur ce Paula 8 voies badgé Nintendo

mais continuons :

Well, the SPC700 does have a 16-bit DSP attached.  This DSP functions much like the wave table sound cards today, capable of mixing 8 voices simultaneously at various pitch and volume. 

http://snesmusic.org/files/readme.html

( tu crois le codeur SPC tool assez compétent ? )
tu trouveras aussi dans sa doc les mots suivants ( si ça te rappelle qq chose ) 

4. Waveforms

4.1 The Wave Table

[touko]

olàlàlàààà  ..tu pleures maintenant ?

donc tu en es carrément à mentir sur des propos comme un gros con ??
Bah putain, t'es vraiment tombé bas pour essayer de discréditer les gens .Franchement bravo, on savait que tu n'étais qu'un abruti, mais là tu me scotches .
Aller jusqu'à mentir ouvertement en pensant que ça passerait et que je trouverais pas le post original, ça montre jusqu'à quel point tu es près à aller .
Franchement tu crains sérieux, c'est presque à se demander finalement quel âge tu as pour jouer à ça . 
C'est misérable et pathétique comme manoeuvre .

Maintenant que que c'est clair, tu vas me dire quoi que tu plaisantais ? 

[rocky007]

Maintenant que que c'est clair, tu vas me dire quoi que tu plaisantais ? 

moi pas comprendre...
relaxes toi coco, je vois que tu es sur les nerfs, tu bégaies en écrivant    tu es à 2 doigts de la rupture d’anévrisme

[touko]

Bien sur, je constate juste que t'es près à mentir comme un porc, mais à part ça moi ça va, c'est juste que tu démontres simplement ce qu'on pense de toi, donc rien de gênant en soit . 

Sinon tes tests sur un .png, ça avance ?? 

Au fait mon écran fait 512 pixels, et expliques moi hormis la première salve comment tu organises tes sprites dans ta liste .
Tu vas partir du principe que les objets sont triés, donc tu vas faire comment pour insérer une nouvel objet dans ta liste ? et qd un objet est détruit.

Et expliques moi aussi en prenant 512 pixels et exactement les tests que tu fais et comment tu les fais .

[rocky007]

[touko]

Bon expliques alors, je t'écoutes tu veux parler sérieux, on y va .

[rocky007]

Bon expliques alors, je t'écoutes tu veux parler sérieux, on y va .

ah ? ce n'était pas encore le cas ?

[touko]

Expliques moi en détail ta solution .

Je te donne juste une explication d'un codeur (qui est connu) et qui ma fois explique ce que tout le monde fait dans un shoot :

About the spatial grid system; it isn't free. There's overhead for every single object. I realize this is a bullet hell demo, and the enemy bullets have a 1x1 collision box (are the player shots 1x1 as well??)... so this helps since it doesn't need to span two or more grid boxes. But you have to check which box your bullet is in for any given movement, and potentially remove itself from the old slot and install itself in the new slot. I'm not convinced this is optimal over traditional (with early opt out) collision detection (and definitely not if the collision box is larger than 1x1), unless you have something like player bullets destroying enemies bullets ( something like O(n^2) compare).

[rocky007]

pourquoi tu ne demandes pas aux experts de snesdev ?
tu sais, j'y connais rien, en plus ça a pas l'air coton comme truc

[touko]

Bon finalement c'est bien ce que je pensais .

[rocky007]

oui, c'est bien mieux de faire 650 test collisions...


tiens je remets l'image, ça fera rire Youki..parce c'est vrai , comment éviter ces 650 tests de collisions..ça pas l'air simple

[touko]

Donc t'as que ça à dire ? 
T'as peur d'expliquer ou quoi ? pourtant je te demande rien de compliqué non .
Juste une explication détaillée de comment tu gères ça 

[rocky007]

comme les 500 questions auxquelles tu n'as jamais répondu

la seule différence c'est que moi ,je peux te répondre... mais ce sera comme au poker, tu paies pour voir mon jeu.

je t'ai proposé un challenge à 10000€, tu t'es dégonflé, mais il est toujours d’actualité tu sais.  tu paies, et tu auras le source code qui t'expliqueras comment faire



et sinon, depuis mes dernières citations ( https://www.gamopat-forum.com/t122422p390-guerre-st-amiga-fight-mauvaise-foi-assuree#3738861 ) , tu rebondis plus sur ton Paula 8 voies ? ne vient pas me dire que tu baisses les bras ?

[touko]

Bien sur 

Bref du flan, merci de confirmer . 

[rocky007]

tu veux pas gagner 10000 € ? si t'es si malin, pourquoi hésites tu une seconde, 10k € pour du flan c'est bien payé non ?

[touko]

Oui t'as raison, j'en ai tellement rien à branlé de ton explication vaseuse, donc soit tu expliques et on en discute, soit tu te la garde et tu l'ouvres plus .
mais franchement tu fais pitié avec ton image, surtout qd t'expliques rien pour pas qu'on te mette en défaut .

Explique en détail, et si t'as raison je l'admettrais, sinon c'est toi qui admettras que tu as tors .

[Jacques Atari]

10k€, ça doit en faire des travelos ça...

[touko]

plein si t'aimes payer pour ça, moi pas en tous cas .

[rocky007]

Explique en détail, et si t'as raison je l'admettrais

rooh oui, on a eu une belle démonstration encore aujourd'hui

mais franchement tu fais pitié avec ton image, surtout qd t'expliques rien pour pas qu'on te mette en défaut .

tu veux dire un peu comme quand j’explique en détail, source à l'appui en quoi le SPC700 fait de la synthèse et que tu refuses de répondre à la simple question "quel est ta définition de synthèse basé sur samples ?" 

[touko]

Donc 0 explications du coup ? 
Qd tu seras décidé, préviens moi, sur ce, je vais dormir .

Ps: Très mignon ton snapshot . 

[rocky007]

t'as pas les 5000 € pour parier ?    fais un cagnotte sur snesdev pour te financer 

j'ai tellement rien à branlé

oui ça je m'en doute tu dois pas être gâté par la nature

[youki]

oui, c'est bien mieux de faire 650 test collisions...


tiens je remets l'image, ça fera rire Youki..parce c'est vrai , comment éviter ces 650 tests de collisions..ça pas l'air simple

Rocky et Moi en ce moment ....

[touko]

Bon je vais démonter point par point les arguments de notre cher ami rocky qui pense que faire des copier/coller de google qd on parle d’un sujet pour faire croire qu’il sait de quoi il parle, et surtout qu’il maitrise le sujet, d’arnaque qui caractérise le personnage .
D’abord un peu de présentation :
Qu’est ce que la puce audio de la snes ? c’est une puce PCM qui utilise la compression ADPCM BRR appelée S-SMP qui permet de jouer des samples 16 bits 32khz (fréquence d’échantillonnage fixe) sur 8 voix .
Elle est composée de :


1 – CPU, le SPC700 (un 6502 custom @ 2mhz)
2- Un DSP, c’est lui qui fait tout le job de jouer les samples et d’effectuer les traitements en temps réel.
3- 64 ko de RAM


POINT 1 : La RAM de 64ko.
Avec 64ko on pourrait mettre jusqu’à 4s de samples 16 bits 32khz.
Alors, du fait de la compression, 64ko suffisent ils ?, clairement non et pour plusieurs raisons.D’abord il faut garder à l’esprit que dans les 64ko on ne stocke pas seulement les samples, mais aussi le code pour le driver, les données pour la/les musique(s) et pour les sfx, à cela s’ajoute un espace mémoire réservé pour les ports,les io, et la RAM du dsp et du SPC700, au final on se retrouve avec 54/50 ko de dispo pour les samples, soit entre 15 et 22% de RAM en moins .Ensuite 4s(a condition d’avoir la totalité de la RAM dispo) c’est vraiment très peu,surtout si il faut avoir une musique et des sfx dans une phase de GP.
Le joueur a souvent aussi lasurprise de sample écourtés comme dans SF2, ou carrément moins de SFX que chez le concurrent SEGA(qui pourtant pas doué pour les samples)
Ensuite, voyons dans les faits, déjà rien que le fait de mettre les samples dans le format ADPCM BRR réduit leur qualité, car pour avoir ce taux de compression l’algo de compression est dit « avec perte », donc même en full rés, les samples seront dégradés .
Que dit la scène à ce sujet ?

The audio is always lossy compressed in the SPC700. The hardware decompress it just in time when it extract samples from BRR encoded data. 

Mais pk les specs annoncent du 16 bit 32khz (soit proche de la qualité CD), mais dans les faits on en est loin ? .
Simplement parce que la conclusion est que 64ko global est bcp trop peu et donc largement insuffisants.
Donc pour palier ce problème évident de taille de RAM, les dev dégradent encore les samples en réduisant leur fréquence d’échantillonnage au maximum car le hardware permet du fait de sa fréquence fixe, de resampler automatiquement le sample et d’appliquer 1 ou plusieurs filtre à la volée et une interpolation qui dégradent énormément la qualité de lecture .Il en résulte ce que les possesseurs/utilisateurs de snes ont tous remarqué pad en main, un son plus ou moins étouffé voire ajoute en plus un effet d’écho ou de reverb pour masquer encore plus la mauvaise qualité de certains samples(ces filtres sont bien sur détournés de leur vraie utilisation) bien connus des joueurs snes
Comme un exemple est toujours plus parlant, voilà un exemple de la lecture d’un sample en natif, soit 16 bits 32khz (ce qui désactive les traitements), le résultat est sans appel par rapport à ce que tout utilisateur de snes est habitué à avoir :



Cette démo a été faite il y a quelques années, et utilise le stream et 100% du CPU, ce qui nous amène au second point .

[touko]

POINT 2 : Le STREAM
Voilà le point 2 de l’argument de notre génie national ,le stream de données vers la RAM audio .Avant d’expliquer comment ça marche, il faut visualiser le contexte et le positionnement de la partie audio par rapport au reste de la console.Le chipset audio est totalement isolé du reste du hardware, c’est-à-dire que le CPU,le DSP et la RAM ne sont pas vu des autres puces, ni même du CPU principal .Cependant il faut pouvoir envoyer les données dans la RAM audio pour que la partie son puisse fonctionner .Il n’y aucun moyen via DMA comme on le ferait pour la partie vidéo, pour envoyer les données au S-SMP.
Un moyen existe et est composé de 4 ports 8 bits dans lesquels le CPU (donc le codeur) doit mettre les données que le scp700 va ensuite récupérer et placer en RAM .Et bien sur le CPU principal doit attendre que le scp700 soit prêt à recevoir de nouvelles données avant d’en mettre de nouvelles sous peine d’écrasement des données courantes .


C’est un processus très lent de synchronisation, qui consomme bcp de CPU du fait qu’il passe plus de temps à attendre le SPC700, qu’à envoyer les données .Donc cela rend le processus inutilisable in-game.
Donc rocky va nous dire (en commençant par 50 smileys) mais le cpu peut faire autres choses pendant ce temps au lieu d’attendre comme un teubé, comme avec l’intro de tales of phantasia, mégagigalololol,c’est du in-game ça (suivit de 50 smiley).


Mr rocky qui est un expert google et qui techniquement est aussi bon que mon testicule droit, ne comprend pas d’1 ce que veut dire in-game,et c’est pas pendant une intro, mais en plein gameplay .


Rocky007 : Mais pk c’est pas pareil ? (suivit de 50 smiley)


Simplement que dans une intro, qui est totalement scriptée, faire de la synchro en comptant les cycles est bien plus simple, on sait exactement où le CPU en est, et donc on peut savoir combien de cycles sont utilisés pour chaque moment pendant l’intro et la synchro devient plus jouable,et sans rupture de flux .De plus retarder l'affichage des gfx, entre chaque partie,ne nuit en rien au déroulement de l'intro puisque c'est le flux audio qui doit être ininterrompu, le joueur ne s'en rend même pas compte qu'on a perdu des frames .
Dans une phase de game play, insérer ce genre de technique alors que la position du CPU dans le code est totalement aléatoire du fait des actions du joueurs, c’est totalement imprédictible et surtout ingérable, car le CPU s’occupe de la logique du jeu en réagissant aux actions du joueur,doit piloter le son, gérer les interruptions, les effets,le transfert des données en VRAM via DMA qui stope le CPU principal. et ne peut pas se permettre de faire une pause en pleine action pour envoyer les datas dans l’ARAM(audio RAM) .
Que dit la scène à ce sujet ? :

With the SNES, the S-CPU and the S-SMP have a much more restricted means of communication: there are exactly four boxes, each of which can hold a single number between 0 and 255. They can't know when the other side put a new number in: they can only see that the number has changed since the last time they checked.

Streaming uncompressed 32kHz stereo 16-bit audio requires transmitting approximately 128000 bytes per second. But the exact rate is determined by the S-SMP's clock, which isn't a constant speed relative to the S-CPU. (Because the S-SMP originally used a lower-precision "ceramic resonator", it can drift by up to 0.1% from what's intended, while the S-CPU uses a calibrated quartz crystal)

So the S-CPU not only has to push 128000 bytes per second through this cramped communication path, but it has to ask the S-SMP whether it needs more data yet. And the S-SMP has other things it has to do, too, namely copy the data from the S-CPU to the DAC (which is complicated, but we'll ignore that for now)

One major problem for SPU/CPU sync is that both runs on completely separate crystals, unlike, say, the CPU and PPU in the NES, where they run at different rates, but based on different divisors of the same crystal.

Communication between the two processors (the main CPU and the audio CPU) is accomplished by means of I/O ports that hold persistent values. You write to a port, with either processor, and the value you wrote shows up on the other side for all time, or until the system is turned off, or until the port is written again from the same side (values read from these ports are always the values that were written from the other side).

"Sync" in this case doesn't mean cycle-alignment. It means making sure that (a) the S-CPU doesn't write a new value before the S-SMP has read the previous one, and (b) the S-SMP doesn't read an old value again and mistake it for new data. (Also (c) the S-SMP doesn't end up with corrupted data due to reading during an S-CPU write, or reading the top port after the bottom two ports were written in rapid succession. See the link above for descriptions of these two hardware bugs.) There are lots of ways to accomplish this, from two-way handshake protocols for each byte (slow but reliable in a variety of situations; the SPC700's boot ROM does this) to semi-free-running timed code loops (fast but require intermittent sync protocol to account for the fact that the clock ratio is not reliable). N-Warp Daisakusen's audio streaming uses multi-line HDMA bursts on the S-CPU side and a cycle-counted read loop on the S-SMP side, but its peak bandwidth is limited by the fact that it dumps the data on the stack and copies it to the desired location after the burst. My own (untested) attempt at HDMA streaming uses self-modifying code to pass the data straight to the desired location during the read loop, which should in principle allow much higher bandwidth. (Again, my code is totally untested; for all I know, d4s' method could be the best you can do with HDMA...)

De plus un autre problème survient, c’est que la partie audio est elle-même occupée à jouer les SFX+musique et donc ne peut pas risquer d’avoir une coupure de son en plein GP .Ensuite streamer un son dans une intro, ou le buffer est linéaire (on part du début-> et à la fin on boucle) contrairement à des sons qui sont de tailles différentes et disposés de façon non uniforme dans l'ARAM, et les remplacer est encore plus dur et délicat.


Donc compenser la faible quantité de ARAM via la stream in-game est il viable ? : clairement non, trop difficile et surtout catastrophique .Certains se souviennent des phases de jeux, surtout avant et entre les niveaux, où on a une impression de loading ?, et bien cela est du au transfert des données en ARAM la plupart du temps,voire + une éventuelle décompression en sus .
Comme ici aussi un exemple vaut 1000 mots, le cas de SF2 alpha qui fait partie des derniers jeux de la snes (sorti en 1996),soit après tales of .




On peut bien voir ce que le chargement des samples en plein GP implique.

3-LE WAVE SYNTHETISER :

Je dirai juste une chose :

Like the Amiga and the Apple IIgs, the main synthesizer chip (the S-DSP) is fundamentally a wavetable synthesis system. However, it offers twice the channels of the Amiga and allows full stereo balancing on each channel individually, effectively matching the Apple IIgs running 16 channels at once. Furthermore, it does not suffer clock rate slowdown the way the Apple does when playing multiple samples.

https://bumbershootsoft.wordpress.com/2023/11/18/snes-digital-audio-playback/
C'est finalement la seule chose de correcte que tu ais dite, et malheureusement aussi celle qui dans les faits n'a aucune espèce d'importance ni la moindre utilité .Dommage . 

[Copper]

C'est marrant parce que le chip son de la Nintendo DS à l'air plus proche de celui de l'Amiga que de celui de la SNES au niveau du fonctionnement.

[touko]

Il me semble qu'il est assez simple de conception et dans mes souvenirs tout se fait au CPU.

[youki]

tout au CPU , il n'y a rien de mieux!

[Copper]

Le CPU il ne faut pas qu'il passe son temps à modifier le volume pour simuler un sample par contre...

[rocky007]

Bon je vais démonter point par point les arguments de notre cher ami rocky qui pense que faire des copier/coller de google qd on parle d’un sujet pour faire croire qu’il sait de quoi il parle, et surtout qu’il maitrise le sujet, d’arnaque qui caractérise le personnage .

vraiment magnifique post, une plume exceptionnelle... hier quand tu nous a dit que tu allais coucher à 23h00 et qu'on rigolerait bien aujourd'hui, tu nous a caché que tu as passé ta nuit à rédiger ce pavé...complètement inutile, cela aurait été plus simple de poster le wiki   En tous cas, je vois qu'enfin tu a compris comment utiliser google.  J'adore tous ces mecs comme toi ou babsy qui disent des millions d'aberations, et me reprochent de faire des recherches google, pour au final pondre des recherches google.


surtout qu'au final ? que nous apprends tu ? ben rien...en quoi cela me contredit il ? rien non plus :

Point 1 LA RAM : pavé totalement inutile, je n'ai jamais abordé la question de la qualité des samples.  Personnellement cela ne choque pas, car cela ne fait qu'apporter de l'eau à mon moulin : ce chip était conçu et basé pour la synthèse, comme le Korg Wavestation et certainement pas comme bête player de sample PCM comme le Paula ferait.  Pour info, le Korg stock ses 365 samples sur 2MB ( ça fait 5ko par instrument ). ça te donne un idée de la différence entre un synthétiseur et un échantillonneur ( Paula )

Point 2 LE STREAM :  tu ne fais que confirmer ce que je dis, que la limitation des 64ko peut être dépassée.  Tu postes comme preuve une demo 16bit 32khz qui prend 100% du CPU ( c'est toi que le prétend, je n'ai pas vérifié ).  Demo, qui rappelons le utilise les dernières optimisation et trick que SF2 ne possédait pas.   Donc un stream d'une voix en 8khz ( et je pense que celle de Tales of Phantasy est encore plus basse ) prendrait logiquement ( je simplifie ) 25% du CPU.  75% de libre pour jeu, c’est pas mal non ? Ça en fait des collisions    Donc oui, on peut donc bien outrepasser la limitation de 64ko, à réfléchir au cas par cas selon les contraintes.

3-LE WAVE SYNTHETISER : donc tu admets enfin que le SPC700 fait de la synthèse ? et ton équipe de snesdev qui devait m'apprendre la vie ?   par contre, ta citation est fausse et absurde  "Like the Amiga and the Apple IIgs, the main synthesizer chip (the S-DSP) is fundamentally a wavetable synthesis system." .  A ce que je sache,  l'Amiga n'a pas de DSP pour modifier le sample en temps réel et n’est pas autonome via un processeur dédié,  il faudra nécessairement le CPU.  Tu vas me sortirque Paula permet de moduler une piste avec un autre, mais bon...soyons sérieux )

Je te rappelle la définition d'un échantillonneur :

Échantillonneur (Sampler)

Capture et lecture de sons enregistrés. Les échantillonneurs sont conçus pour enregistrer des sons réels (comme des voix, des instruments, des bruits ambiants) et permettre leur réutilisation musicale en les jouant à différentes hauteurs ou vitesses

Ah ben merde c’est la définition de Paula

Bref je suis content qu’en 24h je t’ai appris tout ce que tu ne savais pas en 40 ans sur la SNES

[touko]

Et bien tu trouves encore le moyen de la ramener et de sortir encore plus d'âneries après le double fist que je viens te de mettre 
Bon 1 chose de faite, maintenant si tu veux que je te fasse un 2nd trou du cul,tu mets ton explication bidon sur les collisions et je me ferais un plaisir de te démonter encore un fois .

Ps: du coup tu nous remets 50 fois tes liens vers le "WAVE TABLE SYNTHETISER" de la snes ou pas ?