Re: topic officiel Project Y - Paprium

[Stef]

On s'en fout complètement pour plusieurs raisons :

1- Le jeu devait faire à la base 48Mb (32Mb + 16Mb)
2- Le jeu fait aujourd'hui 80Mb (64Mb + 16Mb)
3- La techno utilisée permet de stocker l'équivalent d'un jeu de 128/256Mb
4- Il n'a jamais été indiqué que la ROM faisait 80Mb (non compressé)

Insister sur ce détail plutôt que jouer, c'est branler des mouches.

Je pense que ça résume un peu le fond de la pensée de la plupart d'entre nous :p

J'ai relu certains de mes échanges avec Fonzie *après* l'interview (je l'avais fait rapidement avant mais je n'avais pas tout parcouru). Et s'il m'avait bien dit que les PCM étaient dans une bank de 16 Mb séparée (et c'est ce dont je me souvenais), il m'avait pas non plus forcément mentionné que c'était de la ROM ou de la RAM... donc encore une fois, ne pas prendre tous ce que je dis dans cette interview comme argent comptant (c'est aussi pour ça que je sais précisait que c'était de l'hypothèse).
Depuis j'ai retrouvé un mail (datant de 2013) avec les specs du DSP qui laisse plutot entendre que c'est plutot bien 64 Mb de ROM + 16 Mb de RAM en effet (avec les samples décompressées dans ces 16 MB de RAM).
Je pense que l'interview de Fonzie éclaircira (ou pas) ces points de détail, moi j'avoue que c'est pas ça qui m'importe mais plutot de savoir réellement ce que fait le DSP dans le jeu et à quel point il soulage le travail du 68000. Aussi pour l'histoire des 94 sprites, il semblerait qu'il s'agisse effectivement du multiplexing (ça reste une performance car c'est pas simple à utiliser dans ce genre de jeu, mais ce n'est donc pas de la magie noire ^^).

[xinyingho]

Je pense que ça résume un peu le fond de la pensée de la plupart d'entre nous :p

Je pense pas vu le ton aggressif qu'il y a sur ce thread (y compris de TotOOntHeMooN malgré ce qu'il dit). Mais merci d'avoir pris le temps d'éclaircir ce petit point technique. Sur ce, je vais vivre ma vie ailleurs, Paprium est un sujet qui met trop de gens en rogne...

[Stef]

En fait il faut admettre que certaines vidéos qui parlent du jeu (et notamment celle de Wahwah) sont clairement à charge, contenant quelques de vraies informations certes mais noyées dans du bullshit (les histoires du jeu qui ne tournait pas sur Megadrive, qui a fallu alléger les animations, réduire le taille des sprites... pour que ça passe).
Et conclure que le jeu n'avait rien d'une prouesse car avec une grosse ROM c'est facile 
Enfin bref.. on va pas s'éterniser là-dessus, c'est juste qu'il faut faire la part des choses dans les différentes vidéos qu'on entend. Le jeu est clairement au top techniquement de ce que peut faire la Megadrive, ça reste donc une prouesse technique quoiqu'on en dise. Et pour ne rien gacher, le jeu en lui-même est bon (avec ses défauts quand même), c'est le principal je pense.

[kawickboy]

Quand on n'a pas eu son petit jeu cadeau parce que l'on se prend pour un people, on se venge comme on peut. Même Edge qui après avoir annulé avec pertes et fracas (et incendie de kakemono) a recommandé sans s'en vanter jusqu'à sa vidéo des éditions limitées.

[suisseretrogaming]

Une question technique, je ne connais pas la prog sur console.

Par rapport a fait que la MD je gère pas la transparence.
C'est possible de remplacer des tiles à la volé ?
Lorsqu'on dit que la Megadrive ne gère pas la transparence. Supposons qu'il y a une vitre et le personnage passe derrière, n'est-t 'il pas possible de remplacer les tiles du perso par des tiles plus foncés pour simuler qu'il est derrière ?
Je suppose qu'on me dira que non car le perso peut se retrouver à n'importe quelle position faisant n'importe quel mouvement derrière la vitre, donc ça ferait des milliers de combinaison de tiles possibles donc à stocker dans la cartouche. C'est bien pour ça que ce n'est pas possible ?
Et là j'interviens, ne serait-il pas possible d'ajouter une puce additionnelle à la cassette qui génère des tiles plus foncé en fonction de la position du perso dans le décors ?

[Hpman]

Aussi pour l'histoire des 94 sprites, il semblerait qu'il s'agisse effectivement du multiplexing (ça reste une performance car c'est pas simple à utiliser dans ce genre de jeu, mais ce n'est donc pas de la magie noire ^^).

N'oublies pas les mentions légales :

** A supposer que l'on observe effectivement 94 sprites

Moi ca me parait un bordel sans nom à faire (mettre à jour la SAT pendant l'affichage, sans la corrompre), mais je veux bien laisser planer le doute pour l'instant 

[Stef]

Ca serait trop compliqué de remplacer les tiles à la volée, déjà ça consommerait une place dingue pour pas grand chose, ensuite ça boufferait pas de la bande passante DMA, et même au niveau de la construction des sprites ça poserait problème. Bref ce n'est vraiment pas réaliste (assistance ou pas).
Pour cette histoire de transparence, c'est juste que la photo a été prise sur un CRT ou les pixels adjacent se mélangent, d'où l'effet de transparence avec un simple mesh de pixel (surtout si celui-ci est alterné à chaque frame). Dans le manuel du jeu c'est d'ailleurs indiqué de jouer de préférence sur un CRT pour profiter de ces effets de transparence à base de mesh.

[Hpman]

Une question technique, je ne connais pas la prog sur console.

Par rapport a fait que la MD je gère pas la transparence.
C'est possible de remplacer des tiles à la volé ?
Lorsqu'on dit que la Megadrive ne gère pas la transparence. Supposons qu'il y a une vitre et le personnage passe derrière, n'est-t 'il pas possible de remplacer les tiles du perso par des tiles plus foncés pour simuler qu'il est derrière ?
Je suppose qu'on me dira que non car le perso peut se retrouver à n'importe quelle position faisant n'importe quel mouvement derrière la vitre, donc ça ferait des milliers de combinaison de tiles possibles donc à stocker dans la cartouche. C'est bien pour ça que ce n'est pas possible ?
Et là j'interviens, ne serait-il pas possible d'ajouter une puce additionnelle à la cassette qui génère des tiles plus foncé en fonction de la position du perso dans le décors ?

Si il est complètement derrière tu peux éventuellement changer sa palette du perso mais à ce niveau c'est pas la fête sur MD (il ne faut pas qu'un autre objet partage cette palette avec lui).

Tu peux éventuellement utiliser le mode shadow si le setup de la scene le permet. Le perso apparaitra plus sombre. Paprium l'utilise dans les égouts par exemple.

[Stef]

** A supposer que l'on observe effectivement 94 sprites

Moi ca me parait un bordel sans nom à faire (mettre à jour la SAT pendant l'affichage, sans la corrompre), mais je veux bien laisser planer le doute pour l'instant 

Vu le nombre de sprites à l'écran, ça me parait pas déconnant. Car même sans parler de la limite par ligne, tu peux avoir parfois 10 persos à l'écran, des items, des élements de fond et d'avant plan en sprites (potentiellement) et le HUD qui consomme pas mal non plus. Sur les sprites des persos tu es obligé d'utiliser un certain nombre de petits sprites pour ne pas exploser le budget tile/VRAM, la bande passante du DMA et la limite par ligne. J'avais fait des tests et avec des persos de cette taille, j'oscillais entre 6 et 12 sprites par perso en fonction des animations en découpant de manière assez optimisée. Y'a moyen de faire mieux mais même en optimisant au mieux ça me parait diffcille de descendre en dessous de 7-8 sprites par perso "en moyenne" donc la limite des 80 est vite problématique quand même.

Y'a pas de possibilité de corrompre la table de sprite en l'écrivant pendant l'affichage, pour le coup le VDP de la MD est assez safe, y'a un FIFO, tu as des slots libre pendant la période active et y'a un cache partiel de la SAT (en write through) dans le VDP. Il faut juste faire attention à ne pas écrire des sprites actuellement en cours d'affichage. L'idée c'est d'avoir plusieurs SAT virtuelles en interne (2 au moins) qui splittent les sprites selon leur position Y. Pour maximiser le multiplexing, tu as obligé d'avoir quelques doublons dans les SAT mais ici y'a que 14 sprites supplémentaires et à priori c'est ceux du HUD qui sont recyclés donc c'est assez facile dans un sens.

[Hpman]

** A supposer que l'on observe effectivement 94 sprites

Moi ca me parait un bordel sans nom à faire (mettre à jour la SAT pendant l'affichage, sans la corrompre), mais je veux bien laisser planer le doute pour l'instant 

Vu le nombre de sprites à l'écran, ça me parait pas déconnant. Car même sans parler de la limite par ligne, tu peux avoir parfois 10 persos à l'écran, des items, des élements de fond et d'avant plan en sprites (potentiellement) et le HUD qui consomme pas mal non plus. Sur les sprites des persos tu es obligé d'utiliser un certain nombre de petits sprites pour ne pas exploser le budget tile/VRAM, la bande passante du DMA et la limite par ligne. J'avais fait des tests et avec des persos de cette taille, j'oscillais entre 6 et 12 sprites par perso en fonction des animations en découpant de manière assez optimisée. Même en optimisant au mieux ça me parait diffcille de descendre en dessous de 8 sprites par perso "en moyenne" donc la limite des 80 est vite problématique quand même.

Ca me parait clair que le découpage est fait pour consommer le moins de sprites possibles au détriment de la vram, contrairement aux SOR par ex. Un perso de paprium utilise moins de sprites qu'un perso de SOR2, pourtant plus petit.

C'est la question de la mise en œuvre qui me fait tiquer sur la question, car pour passer d'une SAT avec HUD à une SAT sans HUD (ce serait le setup ici), ca va te prendre au doigt mouillé 15 lignes d'affichage pour tout corriger, temps pendant lequel une partie des attributs seront fatalement incorrects.
Ca marche sur sonic2 qui interromps l'affichage au milieu, mais y'a pas de coupure ici. 

[TotOOntHeMooN]

J'ai relu certains de mes échanges avec Fonzie *après* l'interview (je l'avais fait rapidement avant mais je n'avais pas tout parcouru). Et s'il m'avait bien dit que les PCM étaient dans une bank de 16 Mb séparée (et c'est ce dont je me souvenais), il m'avait pas non plus forcément mentionné que c'était de la ROM ou de la RAM... donc encore une fois, ne pas prendre tous ce que je dis dans cette interview comme argent comptant (c'est aussi pour ça que je sais précisait que c'était de l'hypothèse).

C'est avec beaucoup de plaisir que j'ai écouté l'interview, surtout ce que tu nous apprends concernant le mode audio compatible. J'ai vraiment été surpris d'apprendre son existence lorsque le jeu est sorti, car avant je pensais qu'avoir intégré l'audio dans la cartouche permettait d'économiser au niveau de la bande passante... Et là, boom, en fait l'audio transite quand même par le port cartouche pour une histoire de compatibilité, je n'ai pas bien compris le délire... Car dans ce cas, cela veut dire que le jeu aurait pu sortir sans FPGA et juste avoir le MPU pour la décompression des data. Aussi, comme toi j'avais de longue date entendu parler que 16Mb étaient pour la ROM audio (ce qui pouvait se comprendre).

[Stef]

Ca me parait clair que le découpage est fait pour consommer le moins de sprites possibles au détriment de la vram, contrairement aux SOR par ex. Un perso de paprium utilise moins de sprites qu'un perso de SOR2, pourtant plus petit.

Tu ne peux pas trop pousser non plus car je pense qu'il y a pas mal de stream de données (et c'est peu dire) et donc il faut garder l'usage des tiles réduits, et vu les BG, tu dois aussi clairement optimiser la VRAM. C'est un fin équilibre à trouver... c'est presque certain qu'avec 80 sprites (sans multiplexing) tu aurais plus d'effacement sur les scènes chargées (et je parle bien d'effacement de bloc complet, pas ceux dus à la limite par ligne). Il me semble que déjà dans certaines scènes il peut y avoir un ou 2 sprites qui sautent.

C'est la question de la mise en œuvre qui me fait tiquer sur la question, car pour passer d'une SAT avec HUD à une SAT sans HUD (ce serait le setup ici), ca va te prendre au doigt mouillé 15 lignes d'affichage pour tout corriger, temps pendant lequel une partie des attributs seront fatalement incorrects.
Ca marche sur sonic2 qui interromps l'affichage au milieu, mais y'a pas de coupure ici. 

Je ne vois pas ce qui te pose problème ou alors tu as une mauvaise représentation de la SAT de la MD.
Tu ne vas pas mettre à jour l'intégralité de la SAT, grâce au champ link tu peux facilement modifier qu'une portion de la SAT en gardant une cohérence sur les priorités. Ici y'a au plus 14 entrées à modifier + des champs links et si on utilise le multiplexing que sur les sprites en bas en avant plan ou dans l'arrière plan (décor) alors c'est plus simple au niveau de la gestion de la priorité (et je pense que c'est utilisé ainsi). Tu as un pas dans l'écriture VRAM, par exemple tu peux ne modifier que le champ link/size des sprites si besoin.
Si tu dilues les écritures sur plusieurs scanlines (et via la hint) tu ne consommes vraiment pas beaucoup de CPU pour faire ça.

Le jeu dont je t'avais parlé qui utilise le multiplexing pour faire de la neige, utilise 4 sprites pour en afficher 80 (dans ces eaux là) à l'écran. C'est plus intense mais l'effet sy' prête bien on va dire, et surtout ça tourne sans problème sur une vraie MD, pas de corruption/clignotement de sprite ni de ralentissements particuliers durant cette phase.

[Hpman]

Ca me parait clair que le découpage est fait pour consommer le moins de sprites possibles au détriment de la vram, contrairement aux SOR par ex. Un perso de paprium utilise moins de sprites qu'un perso de SOR2, pourtant plus petit.

Tu ne peux pas trop pousser non plus car je pense qu'il y a pas mal de stream de données (et c'est peu dire) et donc il faut garder l'usage des tiles réduits, et vu les BG, tu dois aussi clairement optimiser la VRAM. C'est un fin équilibre à trouver... c'est presque certain qu'avec 80 sprites (sans multiplexing) tu aurais plus d'effacement sur les scènes chargées (et je parle bien d'effacement de bloc complet, pas ceux dus à la limite par ligne). Il me semble que déjà dans certaines scènes il peut y avoir un ou 2 sprites qui sautent.

C'est la question de la mise en œuvre qui me fait tiquer sur la question, car pour passer d'une SAT avec HUD à une SAT sans HUD (ce serait le setup ici), ca va te prendre au doigt mouillé 15 lignes d'affichage pour tout corriger, temps pendant lequel une partie des attributs seront fatalement incorrects.
Ca marche sur sonic2 qui interromps l'affichage au milieu, mais y'a pas de coupure ici. 

Je ne vois pas ce qui te pose problème ou alors tu as une mauvaise représentation de la SAT de la MD.
Tu ne vas pas mettre à jour l'intégralité de la SAT, grâce au champ link tu peux facilement modifier qu'une portion de la SAT en gardant une cohérence sur les priorités. Ici y'a au plus 14 entrées à modifier + des champs links et si on utilise le multiplexing que sur les sprites en bas en avant plan ou dans l'arrière plan (décor) alors c'est plus simple au niveau de la gestion de la priorité (et je pense que c'est utilisé ainsi). Tu as un pas dans l'écriture VRAM, par exemple tu peux ne modifier que le champ link/size des sprites si besoin.
Si tu dilues les écritures sur plusieurs scanlines (et via la hint) tu ne consommes vraiment pas beaucoup de CPU pour faire ça.

Le jeu dont je t'avais parlé qui utilise le multiplexing pour faire de la neige, utilise 4 sprites pour en afficher 80 (dans ces eaux là) à l'écran. C'est plus intense mais l'effet sy' prête bien on va dire, et surtout ça tourne sans problème sur une vraie MD, pas de corruption/clignotement de sprite ni de ralentissements particuliers durant cette phase.

Les BG c'est pas un trop gros souci, tu stream les tiles nécessaires au fur et à mesure que ca scrolle.



Je pense qu'on a pas le même setup en tête, effectivement si c'est juste recycler les sprites du HUD pour faire passer un perso en avant plan en bas de l'écran c'est relativement simple mais je suis déçu la . J'étais sur un setup recycler les sprites du HUD pour afficher du perso, donc avec le Z order c'est l'enfer.

Parce que si j'ai pas tourné fou, pour passer une liste de genre 1>2>3>4 à 1>3>2>4 il faut changer 3 attributs link, et donc à un instant T la liste est bien incohérente vu qu'on ne peut editer qu'un octet à la fois 

La neige c'est simple car la SAT ne change pas d'ordre, juste les coordonnées de ces 4 sprites à update.


La Hint est vraisemblablement déjà prise pour le BG scroll BTW.

Enfin je dit ca, sur le dump du minijeu qu'on a ca utilise 0 interruptions, vblank à la mano. Ca code en C mais ca veut pas perdre le temps de l'interruption, va comprendre charles 

[suisseretrogaming]

Merci à vous de m'avoir répondu!

[TaMa]

Vidéo très intéressante,
Merci Yannosh ! Après avoir eu le plaisir d'entendre Luis Martins, c'est au tour de Stef !
Super :)

[gatchan]

On s'en fout complètement pour plusieurs raisons :

1- Le jeu devait faire à la base 48Mb (32Mb + 16Mb)
2- Le jeu fait aujourd'hui 80Mb (64Mb + 16Mb)
3- La techno utilisée permet de stocker l'équivalent d'un jeu de 128/256Mb
4- Il n'a jamais été indiqué que la ROM faisait 80Mb (non compressé)

Insister sur ce détail plutôt que jouer, c'est branler des mouches.

Je pense que ça résume un peu le fond de la pensée de la plupart d'entre nous :p

J'ai relu certains de mes échanges avec Fonzie *après* l'interview (je l'avais fait rapidement avant mais je n'avais pas tout parcouru). Et s'il m'avait bien dit que les PCM étaient dans une bank de 16 Mb séparée (et c'est ce dont je me souvenais), il m'avait pas non plus forcément mentionné que c'était de la ROM ou de la RAM... donc encore une fois, ne pas prendre tous ce que je dis dans cette interview comme argent comptant (c'est aussi pour ça que je sais précisait que c'était de l'hypothèse).
Depuis j'ai retrouvé un mail (datant de 2013) avec les specs du DSP qui laisse plutot entendre que c'est plutot bien 64 Mb de ROM + 16 Mb de RAM en effet (avec les samples décompressées dans ces 16 MB de RAM).
Je pense que l'interview de Fonzie éclaircira (ou pas) ces points de détail, moi j'avoue que c'est pas ça qui m'importe mais plutot de savoir réellement ce que fait le DSP dans le jeu et à quel point il soulage le travail du 68000. Aussi pour l'histoire des 94 sprites, il semblerait qu'il s'agisse effectivement du multiplexing (ça reste une performance car c'est pas simple à utiliser dans ce genre de jeu, mais ce n'est donc pas de la magie noire ^^).

«De la plupart». Mais il y en a d’autres qui veulent connaître le côté technique plus que le jeu lui-même. Et même si ça peut être pour vous un détail, je sais que pour les gens comme moi (et ils se reconnaîtront sur ce topic ), les détails ont de l’importance.
C’est ce que tu n’arrives pas à comprendre TotOOntHeMooN, tu passes vraiment pour un fanboy aveuglé par le saint Fonzie. Tu te contredis d’ailleurs entre tes points 2 et 4. Si le jeu fait 80 Mbits, la Rom, fait aussi 80Mbits. J’ai du mal à comprendre comment on peut compter les «données compressées» comme taille du jeu. Ça n’a jamais été fait. Et comme dit dans la vidéo de Wahwah, 99% des jeux SNES ou Megadrive possèdent des données compressées.
Mais quand «Saint Fonzie» marque «80 Mbits» sur la boite, et au démarrage du jeu, cela veut dire «mais on compte aussi la RAM, même si elle est vide, parce qu’après, les données sont décompressées dedans».
Est-ce qu’on compte les 512 Kbits de Dezaemon sur SNES ? Non, c’est de la SRAM qui est vide lors du premier lancement du jeu. Stef, toi qui connais tout ça, tu ne peux pas cautionner une telle pirouette.
TotOOntHeMooN, Tu n’as pas l’air d’y connaître grand chose côté technique, je pense que tu devrais t’abstenir à l’avenir de t’aventurer sur un sujet que tu ne maîtrises pas du tout.

En fait il faut admettre que certaines vidéos qui parlent du jeu (et notamment celle de Wahwah) sont clairement à charge, contenant quelques de vraies informations certes mais noyées dans du bullshit (les histoires du jeu qui ne tournait pas sur Megadrive, qui a fallu alléger les animations, réduire le taille des sprites... pour que ça passe).
Et conclure que le jeu n'avait rien d'une prouesse car avec une grosse ROM c'est facile 
Enfin bref.. on va pas s'éterniser là-dessus, c'est juste qu'il faut faire la part des choses dans les différentes vidéos qu'on entend. Le jeu est clairement au top techniquement de ce que peut faire la Megadrive, ça reste donc une prouesse technique quoiqu'on en dise. Et pour ne rien gacher, le jeu en lui-même est bon (avec ses défauts quand même), c'est le principal je pense.

Ce qui m’intéresse, c’est le côté technique. Et jusqu’à maintenant, ni toi, ni Luis n’a pu contredire les données et hypothèses techniques données par Mister X. Je me fiche de ce qu’à pu dire Wahwah, ce qui m’intéresse, c’est la technique. J’attends avec impatience la vidéo avec Fonzie, si elle arrive un jour.
Et la vidéo de Yanoosh est clairement «putaclic», en mettant en avant le débat «80 Mbits ou 64 Mbits?», alors que Stef, tu le dis toi même lors de l’interview : tu n’en sais rien.
Mais sinon, tout ce dont tu parles à propos du développement du driver sonore est très intéressant.

[TotOOntHeMooN]

@gatchan t'es gentil, mais quand tu ne sais pas tu t'abstiens de porter des jugements fondés sur autre chose que ta méconnaissance en voulant relever des incohérences qui ne le sont que pour toi.

[Stef]

C'est avec beaucoup de plaisir que j'ai écouté l'interview, surtout ce que tu nous apprends concernant le mode audio compatible. J'ai vraiment été surpris d'apprendre son existence lorsque le jeu est sorti, car avant je pensais qu'avoir intégré l'audio dans la cartouche permettait d'économiser au niveau de la bande passante... Et là, boom, en fait l'audio transite quand même par le port cartouche pour une histoire de compatibilité, je n'ai pas bien compris le délire... Car dans ce cas, cela veut dire que le jeu aurait pu sortir sans FPGA et juste avoir le MPU pour la décompression des data. Aussi, comme toi j'avais de longue date entendu parler que 16Mb étaient pour la ROM audio (ce qui pouvait se comprendre).

Merci :)
En fait le DSP est quand même nécessaire pour toute la partie son PCM (24 voies PCM stéréo 16 bits à 44 Khz avec du pitching et gestion envelop), ça clairement tu le fais pas sur le Z80 :p Sur le Z80 au mieux tu fais 4 voies PCM mono 8 bit à 16 Khz sans pitching ni gestion de volume. Donc clairement le DSP permet un son nettement plus riche en ce qui concerne le PCM, même si en réalité les 24 voies ne sont pas pleinement utilisées (il me semble que c'est séparé en 12 pour les SFX + 12 pour la musique).
En terme de bande passante, le Z80 ne va récupérer que le buffer PCM final déjà mixé (en mono 8 bit à 16 Khz) donc ça ne représente pas tant que ça, d'ailleurs en réalité même en mode "normal" (non compatibilité) le Z80 va lire ce buffer et l'envoyer dans le DAC du YM (comme en mode compatiblité) sauf que le FM5 fu YM n'est pas mis en mode DAC (il reste en FM) donc on ne l'entend pas...

Les BG c'est pas un trop gros souci, tu stream les tiles nécessaires au fur et à mesure que ca scrolle.

Tu dis ça comme si c'était facile ^^ Vu les sprites qu'il y a à côté ça doit être un sacré équilibre pour tout faire tenir, à la fois en VRAM, et dans le budget DMA (7ko / frame tout compris).

Je pense qu'on a pas le même setup en tête, effectivement si c'est juste recycler les sprites du HUD pour faire passer un perso en avant plan en bas de l'écran c'est relativement simple mais je suis déçu la . J'étais sur un setup recycler les sprites du HUD pour afficher du perso, donc avec le Z order c'est l'enfer.

Parce que si j'ai pas tourné fou, pour passer une liste de genre 1>2>3>4 à 1>3>2>4 il faut changer 3 attributs link, et donc à un instant T la liste est bien incohérente vu qu'on ne peut editer qu'un octet à la fois 

Très honnêtement je pense qu'il recycle le HUD sur les sprites du bas, ça a du sens car non seulement ça évite les possibles chevauchements mais en plus ça permet de laisser les sprites en place (en début de la chaine). Et donc ça peut se transposer à 2 ennemis si ce sont les 2 sprites les plus bas Mais quand bien même le cache de la ligne (avec les 20 sprites max) est fait pendant le hblank (ça commence juste un poil avant et ça prend une bonne partie de hblank) et y'a 0 access slot pendant ce temps donc aucun moyen de faire une écriture partielle à ce niveau. Il faut juste t'arranger pour laisser la SAT dans un état plus ou moins cohérent pour éviter un mauvais affichage entre chaque ligne. Avec les 18 slots par ligne, y'a largement de quoi s'en sortir... mais c'est sûr que c'est plus complexe que se contenter de recycler aux sprites les plus bas.

@gatchan> Effectivement on a jamais compté en considérant la taille décompressée, mais d'un autre côté c'est écrit 80 MB cartridge, c'est pas écrit explicitement 80 MB ROM. Très honnetement moi c'est vraiment pas un truc qui me choque, au début je pensais qu'il y avait effectivement 80 MB de ROM (je trouvais la taille assez surprenante mais avec une séparation de la gestion du son ça pouvait avoir du sens). Alors le Mister X, sur les chips ok il ne dit de bêtises, par contre ce qui pose problème c'est la manière dont cela a été présenté genre "oh le scandale ! on nous a menti !", mais enfin et surtout, c'est le fait qu'il n'a pas contredit, voir même confirmé que la taille de la ROM suffisait à justifier ce qu'on avait à l'écran, et qu'en gros n'importe qui pourrait en faire autant avec une cartouche de même capacité car MD + grosse cartouche = NeoGeo... non mais cette blague ! La MD fonctionne avec de la VRAM, pas la NeoGeo (pas pour les tiles en tout cas) et ça change absolument tout ici.

[TotOOntHeMooN]

En fait le DSP est quand même nécessaire pour toute la partie son PCM (24 voies PCM stéréo 16 bits à 44 Khz avec du pitching et gestion envelop), ça clairement tu le fais pas sur le Z80 :p Sur le Z80 au mieux tu fais 4 voies PCM mono 8 bit à 16 Khz sans pitching ni gestion de volume. Donc clairement le DSP permet un son nettement plus riche en ce qui concerne le PCM, même si en réalité les 24 voies ne sont pas pleinement utilisées (il me semble que c'est séparé en 12 pour les SFX + 12 pour la musique).
En terme de bande passante, le Z80 ne va récupérer que le buffer PCM final déjà mixé (en mono 8 bit à 16 Khz) donc ça ne représente pas tant que ça, d'ailleurs en réalité même en mode "normal" (non compatibilité) le Z80 va lire ce buffer et l'envoyer dans le DAC du YM (comme en mode compatiblité) sauf que le FM5 fu YM n'est pas mis en mode DAC (il reste en FM) donc on ne l'entend pas..

Oui, je comprend bien que le DSP apporte sa valeur ajoutée en terme d'audio multi-canaux PCM dans la version originale de la bande son embarquée dans la cartouche. J'imagine bien que le Z80 est incapable aussi de faire plus que ce que propose ton driver audio du SGDK. Cependant, dès lors que tu as un MPU ARM à 160MHz qui est la pour gérer la décompression des données, on peut aussi imaginer que sans FPGA, il est capable de préparer des données mixées à destination du buffer pour une restitution par le Z80. J'ai vraiment été surpris qu'il y ait au final ce mode retro-compatibilité, mais si comme tu l'expliques bien, il ne coute finalement pas grand chose en bande passante.

[Hpman]

Les BG c'est pas un trop gros souci, tu stream les tiles nécessaires au fur et à mesure que ca scrolle.

Tu dis ça comme si c'était facile ^^ Vu les sprites qu'il y a à côté ça doit être un sacré équilibre pour tout faire tenir, à la fois en VRAM, et dans le budget DMA (7ko / frame tout compris).

Non je pense vraiment, tu load 1 ou 2 tiles par frame, il scrolle pas vite le jeu, et quand ca scrolle c'est que t'as tué les ennemis.

[xinyingho]

En fait il faut admettre que certaines vidéos qui parlent du jeu (et notamment celle de Wahwah) sont clairement à charge, contenant quelques de vraies informations certes mais noyées dans du bullshit (les histoires du jeu qui ne tournait pas sur Megadrive, qui a fallu alléger les animations, réduire le taille des sprites... pour que ça passe).

On est d'accord que Wahwah et d'autres ont voulu se la jouer sur le sensationnel de l'affaire. Et pour le coup, il a clairement montré une sorte de complexe de supériorité mal placé dans sa vidéo (un peu) et dans sa discussion dans les commentaires de sa vidéo avec Luis depuis effacée (beaucoup).

Maintenant, il faut comprendre que ça montre que la communication de Fonzie de manière générale a été plus qu'exécrable et que les YouTubeurs ont fait qu'avec les infos qu'ils avaient c-à-d pas grand chose. C'est pourtant pas compliqué de faire disparaître le bullshit ambiant : il suffit de prendre le temps d'expliquer les choses. Pour le coup, le futur interview de Fonzie devrait enfin éclaircir tout ça... ou pas.                              

C’est ce que tu n’arrives pas à comprendre TotOOntHeMooN, tu passes vraiment pour un fanboy aveuglé par le saint Fonzie.

T'es pas le 1er à lui dire ça sur ce thread. Et en vérité, il s'en bat, c'est le principe 1er de l'attitude du fanboy. Dans ce mode, il n'est plus là pour discuter mais pour déglinguer les gens qui ne font pas parti des admirateurs. Le plus simple est d'ignorer les interventions des personnes qui sont dans cet état sauf si leur comportement porte vraiment à préjudice. Après, TotOOntHeMooN peut être en fait très sympa et lancer des discussions intéressantes dès qu'il sort du mode fanboy, la preuve avec ses derniers échanges avec Stef

[Stef]

Non je pense vraiment, tu load 1 ou 2 tiles par frame, il scrolle pas vite le jeu, et quand ca scrolle c'est que t'as tué les ennemis.

Oui je connais cette technique mais c'est juste que ça demande un sacré design des levels quand c'est fait à ce niveau, de réserver des espaces VRAM pour ça (pour switcher des blocks). Enfin c'est clairement pas simple à mettre en place , c'est ça que je veux dire.

Enfin pour le multiplexing de sprite on verra bien, car on finira bien par savoir.. et si tu parles de 14 sprites pour le HUD, alors clairement ça matche bien ce chiffre de 94 sprites :p

[TotOOntHeMooN]

T'es pas le 1er à lui dire ça sur ce thread. Et en vérité, il s'en bat, c'est le principe 1er de l'attitude du fanboy. Dans ce mode, il n'est plus là pour discuter mais pour déglinguer les gens qui ne font pas parti des admirateurs. Le plus simple est d'ignorer les interventions des personnes qui sont dans cet état sauf si leur comportement porte vraiment à préjudice. Après, TotOOntHeMooN peut être en fait très sympa et lancer des discussions intéressantes dès qu'il sort du mode fanboy, la preuve avec ses derniers échanges avec Stef

Ce que vous ne comprenez pas, c'est que je vous reprend parce que je ne suis pas fanboy et que je n'accepte pas le mépris qui m'est porté, telle une méchanceté gratuite qui n'a pas lieu d'être pour avoir un échange intéressant avec des interlocuteurs. Je méprise cela, car je sais le travail et les contraintes que représente un tel projet et sous prétexte que l'on ne partage pas l'avis de la "masse" on est fanboy... C'est très réducteur et non constructif. Au contraire, je prend plaisir à échanger avec Stef et d'autres sur des aspects techniques tout en veillant à rester lisible par tout le monde car le forum est lu par tous et c'est en quelque sorte ici que j'y trouve le respect d'autrui.

[xinyingho]

Toto : Ben, tu n'as pas toujours été constructif sur ce thread non plus. Mais bon, j'imagine que tout et n'importe quoi a été dit sur les 666 pages que comptent ce thread au total et que ça peut pousser les gens à bout.

Je suis ce thread que depuis les 100 dernières pages et j'ai pourtant vu tous les types d'interventions déjà. Heureusement que, maintenant que le jeu est sorti, il y a bcp moins d'interventions purement négatives et qu'on peut enfin parler de choses intéressantes :)

[gatchan]

@gatchan t'es gentil, mais quand tu ne sais pas tu t'abstiens de porter des jugements fondés sur autre chose que ta méconnaissance en voulant relever des incohérences qui ne le sont que pour toi.

Écoute : depuis le 25 janvier, tu parles, tu parles, mais tu n’avances aucun bout de début d’embryon de preuve de ce que tu avances.
Genre, rien, nada, que dalle.
Je t’ai déjà repris plusieurs fois.
«Aussi je pensais que le FPGA intègre 16Mb de flash qui contient la ROM son, mais je peux me tromper. Je n'ai pas cherché à gratter plus dans ce sens, car au final je m'en balance royalement....», le 25 janvier. Si tu t’en balances, pourquoi tu continues d’essayer de parler technique ?
Tu t’es trompé systématiquement que tu as tenté d’aborder le sujet que tu ne comprends, de toute évidence, pas.
Yanoosh et toi êtes dans la même situation : vous passez pour des fanboys, cherchant à défendre à tout prix Fonzie.

Ce que vous avez du mal à comprendre c’est qu’il n’a pas besoin de personnes pour le défendre. La vidéo de Wahwah ne lui plait pas ? Tant pis, ce n’est pas la première fois qu’il se prend des reproches dans la tête.
Il est attaqué sur la technique ? C’est à lui d’avancer les faits factuels (dédicace à Wahwah ).
Ce qu’il faut comprendre, c’est que moi (et sûrement les autres) ne sommes pas dans la critique de Paprium. J’y ait joué une fois, et je ne l’achèterai pas. Et je n’enlève rien à la prouesse technique que représente le jeu, qui est le meilleur homebrew sur Megadrive, et sûrement l’un des meilleurs homebrews toutes consoles confondues.
Ce qui m’intéresse est le côté technique. Je déteste les imprécisions, et les mensonges, même si au final, ça ne change rien au jeu.

De ce que j’ai vu, sur les différents forums où le sujet Paprium était abordé, ce sont des spécifications techniques de composants, des photos de PCB qui venaient enrichir les connaissances sur le fonctionnement du jeu. Si vous n’avez pas mieux que des phrases creuses, qui n’amènent rien à l’avancée des recherches, je vous conseille de vous abstenir de vous aventurer sur un territoire qui vous est totalement étranger.

[cazorp]

C'est une ROM de 64 Megs, le reste c'est du flan. Vous pouvez éventuellement ajouter les 512Ko de flash du STM32 si ca vous fait plaisir.

C'est dommage d'appuyer sur ce point pour contredire le test d'une autre personne, car pour le coup c'est eux qui ont faux.

Bien sur comme il est impossible que Mr gourou nous ai bourré le mou, nous en somme présentement à changer la façon dont est déterminée la taille d'un jeu cartouche. 


Toi aussi, part à la recherche des 16 megs magiques, bon chance 

question bête (mais j'y vais quand même): c'est quel(s) chip(s) qui contiennent les 64 Mbits?

[gatchan]

Spansion. (indice, : tu as la capacité dans le nom )
ISSI est la RAM (là aussi, la capacité est dans le nom).

[Luke]

J'ai reçu mon OSSC hier soir, du coup j'ai repris Paprium.
Avec Scanline c'est tout de suite plus charmant. Incroyable de se dire que c'est un jeu Mega Drive. Alors on sent le côté homebrew dans certaines choses, comme le manque d'impact, les hitbox un peu floues, ou certains designs moyens... 
Et puis on échappe pas au manque de couleurs de la console. C'est dommage qu'elle ait une telle faiblesse, tout en étant sur d'autres plans assez incroyable en puissance pour une machine de 88, au prix où elle était vendue.

Mais quel jeu. 

Je vois les disputes autour du titre. J'ai pas envie de me ranger dans une case des anti ou pro Fonzie. Je veux rester pragmatique la-dessus. Il a fait un boulot de dingue et recevoir Paprium en janvier 2021 sur notre bonne vieille Mega Drive, c'est top. 
Mais je n'oublierai pas le manque total de communication, juste irrespectueux, quoiqu'il ait comme bonnes raisons autour du dev de cette cartouche. En avril/mai 2020, j'ai cru que c'était fini...
Et j'attends toujours mes versions Limitee(J) et Classic(JUE). Le 2 février, c'est passé d'emballage à expédition en cours. J'y crois encore !  

Bref, le jeu est là. J'espère qu'il apprendra de ses erreurs. Ce mec est doué, y'a pas à chier. J'suis à deux doigts de précommander son autre projet. Y'a des jours je me dis arrête tes conneries, le lendemain j'suis pas loin de PayPal pour passer commande. 
J'aimerais tellement qu'il puisse nous dire : "bon les gars, je dis en fin d'année, mais c'est peut-être pour la mi 2022 voire 2023..." Mais si c'est pour encore attendre 5, 7 ans ou pire dans le flou complet, 150 balles ça me fait chier. 
Mais je suis sur qu'il va réaliser une petite merveille 16 Bit...
Bon, c'est un autre sujet.


Allez Fonzie, j'ai hâte de voir ton interview  


édit : je viens de voir les détails des expéditions de mes trois Paprium. La version investor a été validée de Brest le 21 décembre, les deux autres versions ont été validées le 2 février de Las Vegas 

[cazorp]

Spansion. (indice, : tu as la capacité dans le nom )
ISSI est la RAM (là aussi, la capacité est dans le nom).

thx
et sait-on à quoi servent les LCX257 et LCX245?

[Kurokishi]

Mais quel jeu. 

Je vois les disputes autour du titre. J'ai pas envie de me ranger dans une case des anti ou pro Fonzie. Je veux rester pragmatique la-dessus. Il a fait un boulot de dingue et recevoir Paprium en janvier 2021 sur notre bonne vieille Mega Drive, c'est top. 

Avec le vomi des rageux sur tous les internets, alors qu'il a mis toute son energie pour rattraper la situation je me demande comment il peux trouver l'energie d'aller vers  un autre projet si ce n'est pour payer les dernieres factures et passer a autre chose dans sa vie.

[antifrog]

En s’en battant les couilles et en faisant son taf sans communiquer ou se faire polluer par ce fame game moisi...
Franchement je sais pas si il existe un univers plus sordide que celui des YouTubeurs

Là les clients qui investissent sur le prochain savent a quoi s’attendre, je vois même pas pourquoi il devrait se faire chier à donner une interview ou à expliquer quoi que ce soit à partir du moment où les gens ont eu leur jeu.