MSX Village forum

Bonjour a tous ,
lors de la reunion du 25 septembre a Orleans, Herve a fait un petit passage pour nous montrer des démos sur Amstrad qui sont franchement pas mal
Il nous a demandé si il y avait des bonnes demos sur MSX mais personne n'en avait....
Cela fait 2 fois qu'il vient a la reunion MSX d'Orleans et a chaque fois on a rien de concret a lui montrer
Je n'y connais pas grand chose en demos sur MSX
Pourriez vous m'indiquer des bon titres a telecharger pour lui montrer a la prochaine reunion que le MSX est plus balaise qu'un Amstrad
Ne laissons pas croire aux "crocodiles" que leur CPC est superieur a notre MSX (je compte sur vous)


A+ Edité par msx45 Le 17/10/2010 à 11h29

La plus aboutie est sans doute UNKNOW REALITY, réalisée par N.O.P. Mais je lui avais déjà montré il y a 2 ans.

Ce sont les clubs hollandais qui ont réalisé le plus de démos :
- Compjoetania (surtout en musiques)
- Fony
- I.O.D. (et son célèbre ludique Metal Limit)
- N.W.O. (surtout des images)

La majorité des groupes proposent surtout des démos musicales, utilisant le Music-Module, la FM PAC, voir les 2 en même temps.
Certaines disquettes affichaient des messages dirigés, de salutations, ou de provocations sur les capacités en programmation d'autres clubs.

J'ai toujours trouvé les démos techniques frustrantes : des gens aussi habilent pour faire des tours de magie avec le VDP, et qui malheureusement n'ont produit aucun jeu.

C'est un peu vrai sur toutes les plateformes.



Il y a quelques exceptions à la rêgle, comme par exemple l'excellent Jazz Jackrabbit 2, qui avait été produit par un groupe de démos. Il y avait une utilisation intelligente d'effets demos (comme un pseudo plasma pour rendre le fond, ou des effets de fondu, de lumières... intéressants pour un jeu de plateformes en 2D).



Mais la plupart du temps, les programmeurs de démos sont incapables d'écrire un vrai programme, c'est à dire un programme "universel". Le programmeur de démo s'arrange toujours pour placer son programme dans le cas idéal, qui va lui permettre de mettre en valeur l'effet présenté, tout en négligeant toute possibilité de généralisation dudit effet.

Cela conduit à toutes sortes de simplifications, et à un manque de test d'un programme généralement bourré de bugs dès qu'on s'écarte du "cas idéal" présenté dans la démo.



Ca se retrouve même à tout les niveaux: un driver ATI était "optimisé" pour suivre le path d'un déplacement d'objet dans 3DMark (un bench 3D très utilisé à l'époque pour tester les perfs des cartes 3D PC). Le driver détectait la démo, puis la scène, et plaçait ses frustums comme un goret pour rester dans le champs du déplacement précalc, et gagner des frames au score final. Cela a été découvert car il y avait un mode "free flight" caché dans la démo, qui permettait de varier le déplacement d'origine. Du coup, on voyait très clairement les occlusions sauvages opérées par le driver. Cela était d'autant plus grave que gagner des frames dans un cas bien précis se faisait au détriment du cas général.

En général, les drivers des cartes 3D sont optimisés pour les moteurs 3D les plus courants (Cry, Unreal, Quake ..). C'est généralement admis, mais ça n'en reste pas moins de droles de méthodes.



Pour en revenir aux démos, il arrive qu'on observe un effet qui rendrait bien dans un jeu. Malheureusement, plus l'effet est rare, et plus cela signifie qu'il tire sur le hard ou sur le matos.

Certaines machines permettaient par exemple des changements de palette au cours de la construction de l'écran. En général, cela était observé uniquement dans les démos où le timing était sous controle, sans intervention externe d'un utilisateur. Autrement, il est délicat de "couper" l'écran à une ligne particulière, sans hard spécifique (le coup du changement de palette en cours de jeu ou d'utilisation (comme Photon Paint sur Amiga par exemple, qui permettait d'avoir 4096 couleurs au lieu de 32) nécessite du hard spécifique, ou un gros gaspillage de ressources si on fait du polling sur le raster (je l'ai cependant déja vu faire sur Amstrad ou MSX, mais on sentait que la machine peinait et ça scintillait).



Pour en revenir aux démos proprement dits, j'ai vu une démo MSX-1 qui ne "trichait pas" en utilisant des extensions (elle tournait avec le hard d'origine). Il faudrait que je la retrouve. Elle n'est pas très vieille et a dû être codée il y a deux ou trois ans. Il y avait les effets classiques dedans, mais c'était bien codé. On peut peut être la retrouver sur pouet.org, je l'avais vu par hasard sur un site généraliste, donc elle a dû sortir à une grosse partie.



Pour les démos MSX-2, je n'y crois pas trop. Le hard est très similaire au MSX-1, et les résolutions "intéressantes" tirent trop sur le matériel. Mais je ne demande qu'à changer d'avis Edité par Visiteur Le 17/10/2010 à 12h32

EeeeH , mais j'y pensse, j'avais mis dans un de mes Fanzines (un des premiers je crois) , une petite demo tournant probablement sur un MSX1 sous la forme d'une Video noire et blanc tournant en Boucle (si si ) contenu dans un fichier Binaire 16 ou 32Ko executable sous Basic, mettant en scene une bataille entre deux dinos dont un volant, tous simplement incroyable pour l'époque, un bon debut comme demo Non (asser bluffant meme) . Bon la il va vraiment falloire que je les retrouve ces discs M rde alors ! Edité par TurboSEB Le 17/10/2010 à 13h30

impressionnante ces demos sur C64, un bemole tout de meme, le controleur du lecteur de disc (un 16bits) est probablement utilisé dans cette demo comme un calculateur (c'est connu chez les Fans du C64 , ce qui n'enleve a rien la prouesse, mais la relativise quand meme ) ,et si on veux comparer, il faudrait greffé un R800 comme second processeur de calcule a un MSX1 Edité par TurboSEB Le 17/10/2010 à 14h54

Je ne pense pas que ce soit une erreur de conception.



Il vaut mieux une mémoire video à part, qui évite le partage du bus entre le processeur et son gpu. Sur Amiga, qui avait une chip ram accessible par le 68000 (les premiers 512ko étaient partagés sur le 500), l'exécution des programmes était plus rapide avec une extension mémoire: on l'appellait de la "fast ram", car seul le cpu y avait accès, du coup on pouvait multiplexer les accès cpu/coprocs.



Par contre, c'est effectivement souvent plus long de transférer les données, puisqu'il y a deux copies (une première dans l'espace utilisateur, et la seconde en videoram). Cependant, c'est plus avantageux si on peut charger toutes les données en ram video, car ensuite, ce n'est plus que de la copie vram->vram pour composer l'écran.

Pour ton exemple de scrolling, tu vas composer l'écran avec des tuiles qui seront de toutes façon en videoram, donc pas besoin de transfert avec la ram principale. Et souvent, tu évites les copies en travaillant sur un écran un peu plus grand et un décalage de l'adresse de départ de l'affichage, et tu ne modifie les bordures que quand tu sors de ton cadre de composition. Si les scrollings sont moches sur MSX-1, c'est bien à cause des limitations du VDP en lui même, et pas à cause de son mode d'accès.



D'ailleurs même aujourd'hui avec nos vitesses de bus hallucinantes, il est plus intéressant de garder beaucoup de mémoire embarquée sur la carte video. Les cartes actuelles les moins performantes embarquent très peu de mémoire video. Et pourtant, on pourrait penser le contraire vu le taux de transfert d'un port pci-express, et la nécessité de faire du traitement sur les vertices par le cpu (le support géométrique/rendu de la carte n'intervient que dans des transformations plus tardives, même si sur les modèles les plus récents, le gpu en fait de plus en plus).

Je suis d'accord Venom, je ne suis pas technique.

il me semblait que le Z80, un 8 bits cadencé 3.4 mhz,
était plus sollicité pour les transferts vram / ram
par rapport à la concurrence C64 / CPC / Spectrum
(l'Amiga ce n'est plus du 8 bits).

Sur Turbo-R on a l'inverse, le R800 attend que le VDP
(bien trop lent) traite les informations.

Est-ce la raison pour laquelle il faut un msx à 7mhz pour
une adaptation Spectrum tel que Ghost'n Goblins

Le 6510 du C64 tournait à 1mhz. La C64, c'est la génération d'avant le MSX (il est sorti deux ou trois ans avant).

Malgré tout, il se plaçait assez bien. Alors tu vas me dire que c'était la preuve que c'était mieux de partager un bus plutot qu'accéder à une VRAM séparée.

Mais non

C'est plutot la preuve que son proc video était canon











C'est un autre problème

Effectivement, si il y a un trop gros décalage entre le cpu et les coprocs, ce n'est pas bon du tout. Mais ce n'est plus lié au fait d'avoir de la video ram ou pas.

Par exemple sur l'Amiga 1200, le blitter était toujours capable de tracer les lignes, mais on le faisait avec le cpu, car c'était devenu une méthode plus rapide.

Des fois, ça tourne au mystique: sur les pentium, il était plus rapide de faire une copie d'un buffer vers le segment video en utilisant le FPU (on empilait des données de 64 bits de large, ce qui était plus rapide que le "rep movsd" utilisé jusque là et qui copiait par paquet de 32 bits).









J'ai été voir la page de l'adaptation, et je pense la même chose que Galine.





Sinon, j'ai retrouvé la démo que je cherchais!

Invasion of the Big Pixels , pour MSX-1

Celle-ci m'a épaté, pas de précalc à foison comme dans Sphere.



http://www.youtube.com/watch?v=SMOXgTA48BM



Je serais curieux de la voir tourner sur un vrai MSX-1 (je pense que la capture de la démo a été faite sur émulateur).