Re: GUERRE ST-AMIGA, FIGHT !!!

[Invité]

Cela ne change pas le fait qu'il n'était pas destiné au départ pour le jeu. C'est le marché qui a fait que des nombreux jeux ont été édités sur cette machine.

Même si je suis d'accord avec toi, atari avait une image très orientée jeux et non de machines pros,contrairement à apple par exemple .

[Zarnal]

Alors quand, sur ce topic, certains Stistes nous disent que ce n'est pas un jeu mais une démo injouable, ça me fait rire : la version ST a une jouabilité moins bonne que la version mig, est moche et saccadée, n'a pas la bande son de l'original et s'est pourtant bien vendue...

Comme beaucoup de jeux adaptés sur ST.

ben c'est normal, la vocation première du st n'est pas le jeu......

si les jeux, la facilité de les copiés etaientt l'atout principal d'achat d'un st......et combien de jeux sortis? plus de 10000? lol

Cela ne change pas le fait qu'il n'était pas destiné au départ pour le jeu. C'est le marché qui a fait que des nombreux jeux ont été édités sur cette machine.

Donc doit on alors en conclure que le marché ne s'intéressait pas aux progiciels du ST ? Le marché ce sont les entreprises et les particuliers. S'ils n'adhèrent et/ou n'achètent pas il doit bien y avoir une raison, non ?

[ryosaeba]

Très bonne conclusion....

[Blondin]

Cela ne change pas le fait qu'il n'était pas destiné au départ pour le jeu. C'est le marché qui a fait que des nombreux jeux ont été édités sur cette machine.

Même si je suis d'accord avec toi, atari avait une image très orientée jeux et non de machines pros,contrairement à apple par exemple .

Atari c'est avant tout une société de jeux (arcade et console), c'est ce qui lui à permis de se développer.
La partie informatique d'Atari, c'est ce qui l'a fait disparaître... 
Commodore, c'est tout l'inverse...

[Templeton]

Seb: Je comprends mieux ce sentiment d'injouabilité, 4 vbl c'est vraiment hardcore niveau contrôles.

Oui tu as raison, il y avait une sacré latence, ça n’arrangeait vraiment pas les choses. En plus d'être plus fluide et rapide, la version IIGS devait être plus jouable.

cryodav76: oui il est impressionnant pour de l'apple2gs , mais il a eté fait plus de 20ans plus tard que la version amiga,
 qui eté l'un des premiers jeux correct sur amiga, depuis il y a eu bien mieux sur amiga en gestion de gros sprites je pense notamment a fighting spirit

Faux! La démo sur AppleIIGS est sortie la même année que la version Amiga. La version GS n'a donc pas bénéficié des techniques de coding avancées d'aujourd'hui. 
 
Le Jeu Affiche jusqu'à 5 personnages à l'écran avec parfois un bon gros scroll Diff. Fighting Spirit n'affiche que 2 personnages plus petit et pas de scroll différentiel, ce n'est pas comparable. Tu ne pourras jamais faire touner Sword Amiga en 1VBL comme Fighting, c'est impossible.

La version Amiga est moins fluide, moins rapide et moins jouable mais reste quand même ma préféré. Quitte à jouer à un mauvais jeu, autant prendre la plus belle version.

stapha92 : si le jeu tourne à 4 vbl et utilise un scrolling au pixel, cela signifie qu'il faudrait plus de 25 secondes pour que le décor scroll sur toute la largeur de l'ecran ! (320 pixels * 4 vbl / 50 i/s)

Je ne remet pas en cause tes affirmations. Mais ne pourrait-il pas y avoir une subtilité qui nous échappe ?

Attention! Quand je parle de scroll au pixel, je parle du pas de déplacement minimum. 
Quand le scroll se recentre lentement sur le personnage à l’arrêt, le décor bouge d'1 pixel toutes les 4 ou 5 frames.
Quand le joueur avance et accroche le scrolling, le pas de déplacement est alors de 3 ou 4 pixels toutes les 4 ou 5 frames.

stapha92: Je dis ça car même en programmant le mig n'importe comment et en blittant l'ecran en entier à chaque frame, je ne vois pas comment ça peut être aussi lent. Peut-être que le jeux utilise des sprites compressés qui sont décompressés à la volée ?
Ce qui expliquerait la différence de mémoire utilisée malgré la réso et le nombre de couleurs plus élevés, ainsi que l'utilisation d'un double-buffer.

C'est hypothèse de décompression pourrait être possible, mais il faut garder à l'esprit la taille énorme des Bob (très nombreux) en 5biplans. C'est rare des sprites avec plus de 16 couleurs sur Amiga et en plus aussi gros, généralement ils sont en 3 ou 4 biblans (voir 2 parfois). 
En plus, ces dernier masquent des décors également en 5 biplans avec en sus un scroll diff fabriqué au Blitter (masquant toujours 5 plans). 
Le Blitter de l'amiga est bon (contrairement à ce que disait le programmeur de Shadow of the beast...) mais ne peut pas faire des miracles avec un tel volume de data à transférer (surtout si le scroll est fait au Blitter en plus).
Quand à la version GS, le fait qu'elle nécessite plus de mémoire avec un volume de data plus faible à transférer que sur amiga, pourrait s'expliquer par du code généré  ou des datas "préshiftés" (seulement 2 frames pour la marche des personnages!). Il faudrait questionner son programmeur car cette version GS malgré ses défauts est quand même terriblement impressionnante.

stapha92: Y a-t-il une version IIGS avec un double-buffer ?

Je crois qu'il n'y a aucun jeu sur IIGS avec un double-buffer, la machine de base n'avait que 256 ko mémoire vive à l'origine, en plus il y avait sur cette machine (si je me souvient bien) un problème d'accès mémoire (fast et lente) ou d'adressage sur le buffer d'affichage.
En tout cas je n'ai jamais vu autant de déchirure écran sur une machine (à par sur l'Amstrad CPC).

stapha92: Sinon, le scrolling sur 2 pixel du IIGS confirme que c'est le proc qui blitte le décor sans utiliser de décalage (précalculé ou non) et en travaillant sur des octets. Belle performance !

Tu as sans doute raison, c'est bluffant !

[cryodav76]

Faux! La démo sur AppleIIGS est sortie la même année que la version Amiga. La version GS n'a donc pas bénéficié des techniques de coding avancées d'aujourd'hui. 
 
Le Jeu Affiche jusqu'à 5 personnages à l'écran avec parfois un bon gros scroll Diff. Fighting Spirit n'affiche que 2 personnages plus petit et pas de scroll différentiel, ce n'est pas comparable. Tu ne pourras jamais faire touner Sword Amiga en 1VBL comme Fighting, c'est impossible.

La version Amiga est moins fluide, moins rapide et moins jouable mais reste quand même ma préféré. Quitte à jouer à un mauvais jeu, autant prendre la plus belle version.

autant pour moi j'ai cru que c'etait 2010 
il y a pratiquement pas de jeux de ce style sur micro 
quand je vois les progres entre le debut de l'amiga(a part hybris et sotb) et les jeux a partir de 1992-93(elfmania,btl,shadows fighter etc) je me dis qu'aujourd'hui on pourrai avoir quelque chose de bien plus fluide

[Invité]

stapha92: Sinon, le scrolling sur 2 pixel du IIGS confirme que c'est le proc qui blitte le décor sans utiliser de décalage (précalculé ou non) et en travaillant sur des octets. Belle performance !

Encore plus bluffant sachant que la page graphique est accédée à seulement 1Mhz .

[stapha92]

Tu ne pourras jamais faire touner Sword Amiga en 1VBL comme Fighting, c'est impossible.

Je suis certain du contraire :

Chaque niveau ne fait que 4 ou 5 écrans de large. On peut donc le stocker entièrement et copier avec le blitter la partie visible.

Pour appliquer le décor, le blitter travaillera avec une seule source et une destination : dans ce mode il peut transférer plus de 70 Ko par frame. Le transfert du décor complet en 320x200x32 l'oblige à manipuler 40 Ko. Il mettra donc moins de 60% de la frame pour le faire.

Le blitter doit faire du cookie-cut pour dessiner les sprites. ça impose 3 sources et une destination. Dans ce mode il peut traiter 35 Ko par frame. Vu ce qu'il lui reste après le traitement du décor, cela fait 15 Ko à peu près.
Comme il semble que lorsqu'il y a 5 sprites, ce ne sont pas les plus gros qui sont utilisés, ça devrait suffire.

Le premier plan utilisé par le scroll parallaxe peut être dessiné avec des sprites (les motifs se répètent : c'est le cas le plus simple à gérer) : quasiment aucun cout.

Conclusion : Même sans utiliser les sprites pour le parallaxe et en codant avec les pieds, je ne vois pas comment on peut dépasser 2 vbl pour ce jeu...


Et il y a d'autres optimisations qui peuvent être apportées comme utiliser le scroll hardware (la méthode de scroll par copie est une hérésie sur le mig...) : le blitter n'a plus besoin de copier l'écran en entier à chaque frame. Il ne copie que les parties à restaurer, il devra continuellement stocker une copie de la partie du décor à l'écran mais, vu la vitesse à laquelle il défile, cela l'obligera à copier très peu de données pour la maintenir à jour (2000 octets chaque fois que le décor scrolle de 16 pixels, donc 125 octets par frame...).

Donc non seulement ce jeu pourrait tourner en 1 vbl sur un A500 mais, en plus, il pourrait être bien plus beau : le décor ne doit pas forcément être défini à partir de tiles mais être un dessin libre. On a vu des dessins bien plus beaux en 32 couleurs...

On peut même utiliser un scroll ligne à ligne (à la "Street Fighter") sur le bas de l'ecran pour avoir un effet de profondeur bien plus réussi que le parallaxe (tout en le conservant). Là aussi le surcout est négligeable.

On peut aussi utiliser le copper pour redéfinir des couleurs à chaque ligne. Comme le scrolling est uniquement horizontal, la copperlist serait définie uniquement au début de chaque niveau. Il est inutile sur Amiga d'utiliser 32 couleurs si certaines ne sont utilisées qu'a certaines position verticales...
Cette dernière remarque est vrai pour le IIGS : il peut choisir une palette de 16 couleurs différente à chaque ligne. Comme il dispose de 16 palettes, cela fait 256 couleurs en tout...

En comparaison, SOTB utilise jusqu'à 6 bitplans, a des sprites bien plus gros (mais moins colorés) ou plus nombreux et ne souffre pas de cette lenteur.

Idem pour Unreal (produit par une petite équipe sans moyen...) : ce dernier utilise le même type de scrolling qui ne s'appuie pas sur des tiles mais cette fois en 64 couleurs. Et ça ne lui pose pas de problème...

[Invité]

Petites infos supplémentaires sur le son de l'archie :

As I remember it, the audio hardware basically just saw the buffer as if it were one channel, and each logical channel was just interleaved in that buffer. The only reason for claiming 8 channels was that the stereo positioning could be set independently for each consecutive sample up to a maximum of 8; but otherwise it was essentially just playing PCM from one channel. Doubling the number of logical channels doubled the sample rate, hence 8 channel sound being so CPU intensive (to fill an audio buffer with a 6us sample period). This is also why:

• 8 channels was quieter, because each channel formed just 1/8th of the data of the sample
  
• Acorn added a low-pass filter, to remove the high frequency noise that could result from the multiplexing of up to 8 interleaved logical channels in a single physical channel (incidentally, cheap CD players also do this - to filter out the high frequency tones which result from using a 1 bit DAC - but it works better than Acorn's solution)
  

Donc s'arrêter à juste du log+8 channels ne veut vraiment rien dire si on pousse pas plus loin .

[stapha92]

Petites infos supplémentaires sur le son de l'archie :

As I remember it, the audio hardware basically just saw the buffer as if it were one channel, and each logical channel was just interleaved in that buffer. The only reason for claiming 8 channels was that the stereo positioning could be set independently for each consecutive sample up to a maximum of 8; but otherwise it was essentially just playing PCM from one channel. Doubling the number of logical channels doubled the sample rate, hence 8 channel sound being so CPU intensive (to fill an audio buffer with a 6us sample period). This is also why:

• 8 channels was quieter, because each channel formed just 1/8th of the data of the sample
  
• Acorn added a low-pass filter, to remove the high frequency noise that could result from the multiplexing of up to 8 interleaved logical channels in a single physical channel (incidentally, cheap CD players also do this - to filter out the high frequency tones which result from using a 1 bit DAC - but it works better than Acorn's solution)
  

Donc s'arrêter à juste du log+8 channels ne veut vraiment rien dire si on pousse pas plus loin .

Et oui ça me rapelle ce que je disais :
Sur Amiga on annonce 4 canaux 8 bits et on a 4 vrais DAC + 4 volumes sur 6 bits + des fréquences indépendantes, ce qui fait qu'on en a plus que ce qui est annoncé...

Sur les autres machines, on a l'impression qu'on s'est plus occupé de l'argument marketing que des possibilités techniques.
Je me souviens des pubs pour le STE : "son DMA stéreo à 50 Khz" ouaouh ! sauf qu'à l'utilisation, ben on est loin du mig...

Commodore n'a même pas communiqué sur le fait qu'à partir de l'ECS, le son du mig passe à 57 Khz, tout comme ils n'ont jamais communiqué sur la possibilité d'avoir 2 canaux 14 bits...

Quand au log, j'ai déjà expliqué pourquoi je préfère le linéaire. J'ai donné un exemple ou la différence entre 16 bits et 8 bits linéaire est difficilement perceptible alors que la version log se repérait tout de suite...

Je referais la même chose avec un wav normalisé (c'est à dire avec une courbe qui exploite toute l'amplitude disponible)...

[cryodav76]

Petites infos supplémentaires sur le son de l'archie :

As I remember it, the audio hardware basically just saw the buffer as if it were one channel, and each logical channel was just interleaved in that buffer. The only reason for claiming 8 channels was that the stereo positioning could be set independently for each consecutive sample up to a maximum of 8; but otherwise it was essentially just playing PCM from one channel. Doubling the number of logical channels doubled the sample rate, hence 8 channel sound being so CPU intensive (to fill an audio buffer with a 6us sample period). This is also why:

• 8 channels was quieter, because each channel formed just 1/8th of the data of the sample
  
• Acorn added a low-pass filter, to remove the high frequency noise that could result from the multiplexing of up to 8 interleaved logical channels in a single physical channel (incidentally, cheap CD players also do this - to filter out the high frequency tones which result from using a 1 bit DAC - but it works better than Acorn's solution)
  

Donc s'arrêter à juste du log+8 channels ne veut vraiment rien dire si on pousse pas plus loin .

Et oui ça me rapelle ce que je disais :
Sur Amiga on annonce 4 canaux 8 bits et on a 4 vrais DAC + 4 volumes sur 6 bits + des fréquences indépendantes, ce qui fait qu'on en a plus que ce qui est annoncé...

Sur les autres machines, on a l'impression qu'on s'est plus occupé de l'argument marketing que des possibilités techniques.
Je me souviens des pubs pour le STE : "son DMA stéreo à 50 Khz" ouaouh ! sauf qu'à l'utilisation, ben on est loin du mig...

Commodore n'a même pas communiqué sur le fait qu'à partir de l'ECS, le son du mig passe à 57 Khz, tout comme ils n'ont jamais communiqué sur la possibilité d'avoir 2 canaux 14 bits...

Quand au log, j'ai déjà expliqué pourquoi je préfère le linéaire. J'ai donné un exemple ou la différence entre 16 bits et 8 bits linéaire est difficilement perceptible alors que la version log se repérait tout de suite...

Je referais la même chose avec un wav normalisé (c'est à dire avec une courbe qui exploite toute l'amplitude disponible)...

on pourrait s'amuser sur atari st comme sur amiga a cité tout ce qui n'a pas eté prévu au départ, oubien des "bug" qui ont améliore la capacité sonore et/ou graphique de ces machines

[Invité]

on pourrait s'amuser sur atari st comme sur amiga a cité tout ce qui n'a pas eté prévu au départ, oubien des "bug" qui ont améliore la capacité sonore et/ou graphique de ces machines

oui c'est un peu ce que dit stapha aussi, CAD que les specs ne veulent pas souvent dire grand chose si on regarde pas autour,que ce soit sur archie, st ou amiga(mode HAM) .
concernant l'archie ça confirme ce que je disais, à savoir que c'est à la base un son 1 voix bidouillée pour en faire 8,et que le multiplexage, c'est pourri,pas cher, mais pourri pour des samples(les synthés en souffrent très peu) .

[babsimov]

Tu ne pourras jamais faire touner Sword Amiga en 1VBL comme Fighting, c'est impossible.

Je suis certain du contraire :

Chaque niveau ne fait que 4 ou 5 écrans de large. On peut donc le stocker entièrement et copier avec le blitter la partie visible.

Pour appliquer le décor, le blitter travaillera avec une seule source et une destination : dans ce mode il peut transférer plus de 70 Ko par frame. Le transfert du décor complet en 320x200x32 l'oblige à manipuler 40 Ko. Il mettra donc moins de 60% de la frame pour le faire.

Le blitter doit faire du cookie-cut pour dessiner les sprites. ça impose 3 sources et une destination. Dans ce mode il peut traiter 35 Ko par frame. Vu ce qu'il lui reste après le traitement du décor, cela fait 15 Ko à peu près.
Comme il semble que lorsqu'il y a 5 sprites, ce ne sont pas les plus gros qui sont utilisés, ça devrait suffire.

Le premier plan utilisé par le scroll parallaxe peut être dessiné avec des sprites (les motifs se répètent : c'est le cas le plus simple à gérer) : quasiment aucun cout.

Conclusion : Même sans utiliser les sprites pour le parallaxe et en codant avec les pieds, je ne vois pas comment on peut dépasser 2 vbl pour ce jeu...


Et il y a d'autres optimisations qui peuvent être apportées comme utiliser le scroll hardware (la méthode de scroll par copie est une hérésie sur le mig...) : le blitter n'a plus besoin de copier l'écran en entier à chaque frame. Il ne copie que les parties à restaurer, il devra continuellement stocker une copie de la partie du décor à l'écran mais, vu la vitesse à laquelle il défile, cela l'obligera à copier très peu de données pour la maintenir à jour (2000 octets chaque fois que le décor scrolle de 16 pixels, donc 125 octets par frame...).

Donc non seulement ce jeu pourrait tourner en 1 vbl sur un A500 mais, en plus, il pourrait être bien plus beau : le décor ne doit pas forcément être défini à partir de tiles mais être un dessin libre. On a vu des dessins bien plus beaux en 32 couleurs...

On peut même utiliser un scroll ligne à ligne (à la "Street Fighter") sur le bas de l'ecran pour avoir un effet de profondeur bien plus réussi que le parallaxe (tout en le conservant). Là aussi le surcout est négligeable.

On peut aussi utiliser le copper pour redéfinir des couleurs à chaque ligne. Comme le scrolling est uniquement horizontal, la copperlist serait définie uniquement au début de chaque niveau. Il est inutile sur Amiga d'utiliser 32 couleurs si certaines ne sont utilisées qu'a certaines position verticales...
Cette dernière remarque est vrai pour le IIGS : il peut choisir une palette de 16 couleurs différente à chaque ligne. Comme il dispose de 16 palettes, cela fait 256 couleurs en tout...

En comparaison, SOTB utilise jusqu'à 6 bitplans, a des sprites bien plus gros (mais moins colorés) ou plus nombreux et ne souffre pas de cette lenteur.

Idem pour Unreal (produit par une petite équipe sans moyen...) : ce dernier utilise le même type de scrolling qui ne s'appuie pas sur des tiles mais cette fois en 64 couleurs. Et ça ne lui pose pas de problème...

Ca ne te dirais pas d'essayer de refaire le niveau 1 du jeu (en rippant les graphismes) avec les optimisations que tu proposes, pour voir ce que ça donnerais en terme de rapidité ?

[Seb]

Et il y a d'autres optimisations qui peuvent être apportées comme utiliser le scroll hardware (la méthode de scroll par copie est une hérésie sur le mig...) : le blitter n'a plus besoin de copier l'écran en entier à chaque frame. Il ne copie que les parties à restaurer, il devra continuellement stocker une copie de la partie du décor à l'écran mais, vu la vitesse à laquelle il défile, cela l'obligera à copier très peu de données pour la maintenir à jour (2000 octets chaque fois que le décor scrolle de 16 pixels, donc 125 octets par frame...).

J'ai lu vite fait en diagonal, j'ai peut être loupé un truc mais dans ce cas il y aurait beaucoup à restaurer vue la taille des sprites non ? Sans compter qu'ils s'overlap, donc il y a plus à restaurer que la zone entourée car certains pixels seraient restaurés 2 ou 3 fois, à moins de se taper un algo pour éviter ca.

[Invité]

Très décrié sur MD (et pour cause), j'espérais qu'il était mieux sur micro... et... bon c'est vraiment une bouse, un hymne à la laideur.

[Invité]

Très décrié sur MD (et pour cause), j'espérais qu'il était mieux sur micro... et... bon c'est vraiment une bouse, un hymne à la laideur.

C'est vrai qu'aujourd'hui il reste plus grand choses,mais je peux t'assurer qu'il avait fait grand bruit à sa sortie,et la version amiga est qd même meilleure que sur MD .
C'est fou comme certains jeux vieillissent mal 

[dlfrsilver]

Très décrié sur MD (et pour cause), j'espérais qu'il était mieux sur micro... et... bon c'est vraiment une bouse, un hymne à la laideur.

C'est vrai qu'aujourd'hui il reste plus grand choses,mais je peux t'assurer qu'il avait fait grand bruit à sa sortie,et la version amiga est qd même meilleure que sur MD .
C'est fou comme certains jeux vieillissent mal 

Salut Touko, en fait, un jeu comme sword of sodan aurait pu bien vieillir, malheureusement, et c'est mon avis personnel, le sprite du perso principal est raté. Je parle même pas de nombre d'étape d'animation, mais bel et bien de cohérence et de proportion au niveau des jambes, ça ne va pas du tout. C'est hyper moche.

C'est ça qui donne ce côté mal foutu et vieillot à ce jeu.

[Invité]

Très décrié sur MD (et pour cause), j'espérais qu'il était mieux sur micro... et... bon c'est vraiment une bouse, un hymne à la laideur.

C'est vrai qu'aujourd'hui il reste plus grand choses,mais je peux t'assurer qu'il avait fait grand bruit à sa sortie,et la version amiga est qd même meilleure que sur MD .
C'est fou comme certains jeux vieillissent mal 

Oui hô bah la version MD... elle fait aussi du bruit, mais pour d'autres raisons... un sale bruit !

[Invité]

Cela ne change pas le fait qu'il n'était pas destiné au départ pour le jeu. C'est le marché qui a fait que des nombreux jeux ont été édités sur cette machine.

Même si je suis d'accord avec toi, atari avait une image très orientée jeux et non de machines pros,contrairement à apple par exemple .

Atari c'est avant tout une société de jeux (arcade et console), c'est ce qui lui à permis de se développer.
La partie informatique d'Atari, c'est ce qui l'a fait disparaître... 
Commodore, c'est tout l'inverse...

c'est a peu près ca, bien vu

[Invité]

Oui hô bah la version MD... elle fait aussi du bruit, mais pour d'autres raisons... un sale bruit ! 

 
Oui mais ça c'est inclu, ça devient une feature maintenant .

[Zarnal]

Très décrié sur MD (et pour cause), j'espérais qu'il était mieux sur micro... et... bon c'est vraiment une bouse, un hymne à la laideur.

C'est vrai qu'aujourd'hui il reste plus grand choses,mais je peux t'assurer qu'il avait fait grand bruit à sa sortie,et la version amiga est qd même meilleure que sur MD .
C'est fou comme certains jeux vieillissent mal 

Rien que l'effet sur sa page de présentation, cela en donnait...

[Invité]

C'et vrai, en plus c'est un effet des plus simple à faire ..

Zarchos wrote:That's much better than the Amiga !

The standard Amiga can generate 14 bit stereo linear, using some software tricks not entirely dissimilar to what my code is doing, but you must bear in mind most human ears will not be able to tell the difference between 14 bit and 15 bit dynamic range.

However the sound filter makes a very noticeable difference here and the Amiga can disable this in software. Sadly the Archimedes loses out here, because without bypassing the filter there's very little point in expanding the dynamic range as the filter muffles the output. 

 
Donc sans mod hardware impossible que sa sonne aussi bon que sur le mig .

Pour info ca bouffe 4 voix pour un sample mono 15 bits .

[stapha92]

Ca ne te dirais pas d'essayer de refaire le niveau 1 du jeu (en rippant les graphismes) avec les optimisations que tu proposes, pour voir ce que ça donnerais en terme de rapidité ?

Honnêtement, faire tout ce travail pour obtenir le défilement fluide d'un décor moche... Bof...
A la limite, si je me monte un environnement de dev (ce que je pourrais faire pour aider l'un des intervenants de ce topic qui voulait faire un jeu) et si quelqu'un s'occupe du rip, je veux bien coder un truc vite fait...

J'ai lu vite fait en diagonal, j'ai peut être loupé un truc mais dans ce cas il y aurait beaucoup à restaurer vue la taille des sprites non ? Sans compter qu'ils s'overlap, donc il y a plus à restaurer que la zone entourée car certains pixels seraient restaurés 2 ou 3 fois, à moins de se taper un algo pour éviter ca.

Tu as tout a fait raison. mais même avec 5 sprites, il y aurait beaucoup moins à restaurer que le blit d'un écran en entier. N'oublie pas que la restauration utilise une copie simple et que lorsqu'il est utilisé pour ça, le blitter peut traiter 70 Ko par frame.

En fait, l'utilisation du blitter est plus avantageuse pour des gros sprites que pour des petits par nature. De plus les gros sprites permettent des optims.

Par exemple, on peut éviter la majeure partie des restauration. En effet, lorsque l'on fait du cookie cut, l'une des 3 source correspond à la destination mais rien n'empeche d'utiliser la copie écran qui sert à la restauration à la place. Du coup, le cookie-cut et la restauration se feront en même temps et cette dernière sera gratuite : seules les parties qui ne seront pas recouvertes devront être restaurées.
Bien sur, cela implique de traiter les sprites par colonnes de 16 pixels : si une colonne n'a pas déjà reçue une partie de sprite on prend la copie de restauration comme source sinon on prend l'ecran (pour ne pas supprimer le sprite précédemment déssiné). C'est cette gestion qui rend cette méthode sans interet pour des petits sprites

Encore une fois : pas besoin de tout ça pour avoir un résultat fluide...

Zarchos wrote:That's much better than the Amiga !

The standard Amiga can generate 14 bit stereo linear, using some software tricks not entirely dissimilar to what my code is doing, but you must bear in mind most human ears will not be able to tell the difference between 14 bit and 15 bit dynamic range.

However the sound filter makes a very noticeable difference here and the Amiga can disable this in software. Sadly the Archimedes loses out here, because without bypassing the filter there's very little point in expanding the dynamic range as the filter muffles the output. 

 
Donc sans mod hardware impossible que sa sonne aussi bon que sur le mig .

C'est pire que ça Touko :

IL N'Y A PAS DE MODE 15 BITS !!!

Non, c'est un mode 10 bits logs. Mode qui a une dynamique équivalente à du 15 bits mais qui n'en a pas du tout la qualité ! En fait j'ai montré pourquoi un mode 10 bits log pouvait avoir une qualité moins bonne bonne que du 10 bits linéaire.

D'ailleurs, l'auteur ne parle pas de mode 15 bits mais de mode à dynamique 15 bits. Il explique aussi qu'on ne voit pas la différence avec du 14 bits réels. Je ne suis pas du tout d'accord avec ça (tu te souviens de l'extrait que j'ai posté : on n'entend pas beaucoup la différence entre du 16 bits et du 8 bits linéaire, par contre le 8 bits log est catastrophique...). Perso, à résolution équivalente, je préfère un mode linéaire que du log. Et je ne suis pas le seul : ce n'est pas un hasard si le log n'a pas percé et n'est utilisé que pour la téléphonie...

Et ce que dit l'auteur sur le filtre est curieux : ce dernier est là précisément pour gommer l'effet créé par le multiplexage. Je ne vois pas en quoi cela est genant. Pire, j'aurai tendance à penser que le son serait moins bon sans. Mais je dois sans doute me tromper.
Par contre, il se trompe quand il parle du filtre du mig. Car le mig en possède 2 et seul le plus bas est désactivable. Il y en a un autre bien plus haut (au même niveau à peu près que celui de l'archi) qui est toujours actif et ne pose aucun problème...

Pour info ca bouffe 4 voix pour un sample mono 15 bits .

Ben oui : la méthode consiste cumuler 4 voix pour créer les valeurs intermédiaires. Par exemple si une voix restitue un volume de 9 et les 3 autres un volumes de 10, cela fera un volume moyen de 9,75. On a donc une résolution 4 fois plus précise (et encore : pas tout à fait mais passons...) ce qui correspond à 2 bits supplémentaires...

C'est juste incomparable avec le mode 14 bits de Paula.
En plus cela oblige à stocker chaque sample sur 32 bits pour en restituer 10 (ou à faire la conversion en temps réel, ce qui prend du cpu...). Avec le mode 14 bits de Paula, on stocke les samples sur 16 bits pour en restituer 14.
Moins de cpu, moins de place, meilleur qualité sonore, pas de modif hardware : Paula l'emporte encore...  

A propos, tu as vu qui s'enthousiasme en disant que la qualité est "bien meilleure" que le mig ? C'est notre ami archiforever !

[Invité]

Et ce que dit l'auteur sur le filtre est curieux : ce dernier est là précisément pour gommer l'effet créé par le multiplexage. Je ne vois pas en quoi cela est genant. Pire, j'aurai tendance à penser que le son serait moins bon sans. Mais je dois sans doute me tromper.

D'après l'auteur le filtre est là pour les samples de faibles fréquences d'échantillonnages(un peu comme le filtre du mig désactivable), donc à mon avis très mauvais quand les samples sont de bonnes qualités .
Mais tu as un peu raison aussi, car ce filtre est sensé aussi atténuer le souffle induit par le multiplexage.

D'ailleurs, l'auteur ne parle pas de mode 15 bits mais de mode à dynamique 15 bits

Exact.

. Il explique aussi qu'on ne voit pas la différence avec du 14 bits réels.

Je pense que c'était pour couper court à l'enthousiasme d'archieforever qui sort direct "c'est bien mieux que sur amiga" .

A propos, tu as vu qui s'enthousiasme en disant que la qualité est "bien meilleure" que le mig ? C'est notre ami archiforever ! 

Oui, et tu as vu comme il moufte plus après la réponse de steve3000, qui est le créateur de QTM .
De toutes façon même sur ce forum, qui est pro acorn il se fait remettre souvent en place à toujours dénigrer l'amiga,et même certains codeurs archimedes et à parler de ses supers routines(bugées) de la mort qui vont faire de l'archie une neogeo depuis 92 alors qu'il à toujours rien montré en 2017 .

[Seb]

Stapha92: Interessant. Je reste vraiment surpris que ça tourne en 4 vbl. Je connais le graphiste mais il ne se souvient plus du framerate, il m'a répondu qu'il pense que c'est "every 2 frames" ou un truc du genre, ce qui ne colle pas avec ce qu'on semble voir. Je vais essayer de voir si il est encore en contact avec le coder pour lui demander car ça m'intrigue

[stapha92]

D'après l'auteur le filtre est là pour les samples de faibles fréquences d'échantillonnages(un peu comme le filtre du mig désactivable), donc à mon avis très mauvais quand les samples sont de bonnes qualités .
Mais tu as un peu raison aussi, car ce filtre est sensé aussi atténuer le souffle induit par le multiplexage.

Il m'a semblé avoir lu que le filtre était à 20 Khz, soit à peu près la même chose que le 2eme filtre du mig (celui qui ne se désactive pas). Il ne me semble pas qu'il y ait quelque chose pour les samples à faibles fréquences comme le mig.

Je pense que c'était pour couper court à l'enthousiasme d'archieforever qui sort direct "c'est bien mieux que sur amiga" .

il explique quand même que le 10 bits log est aussi bien que le 14 bits linéaires. Mais c'est son droit de le penser...

Oui, et tu as vu comme il moufte plus après la réponse de steve3000, qui est le créateur de QTM .
De toutes façon même sur ce forum, qui est pro acorn il se fait remettre souvent en place à toujours dénigrer l'amiga,et même certains codeurs archimedes et à parler de ses supers routines(bugées) de la mort qui vont faire de l'archie une neogeo depuis 92 alors qu'il à toujours rien montré en 2017 .

Je n'ai pas lu le topic, seulement vu l'extrait que tu as produit.

Oui toujours rien... Et en plus pourquoi faire ? Prouver que l'archi pouvait égaler le mig en 2D ? Comme si cela avait un interet...
Ou prouver que les codeurs archi étaient nuls (ce qu'il affirme et qui est faux bien sur) ? Sans interet non plus...

Il y a des domaines dans lequels l'archi est largement meilleur que le mig, notamment grace à son mode chunky. Il y a donc moyen de faire des choses jamais faites sur archi et infaisables sur un A500. Il ferait mieux de se concentrer sur ça au lieu de toujours critiquer les codeurs archimedes...

Le pire : il ne m'a jamais pris au sérieux quand je lui ai dit que je lui donnerait volontier l'optim dont je lui avait parlé (et qu'il croyait spécifique au mig parce que j'étais un "imbécile incapable de raisonner avec les spécificités de l'archimedes") s'il faisait juste la démarche de la demander...

Dommage pour lui : l'optim utilise les spécificités de l'archi, les forces de l'arm et permet de contourner les contraintes des accès mémoires. On est loin des sprites pré-shités avec accès 32 bits dans un code généré et déroulé qu'il prend pour une révolution...
Il pourrait chercher pendant des années qu'il ne trouverait pas.

Ahhh, si on m'avait proposé de m'expliquer une optimisation du même genre quand je débutait j'aurai sauté sur l'occasion. ! Faut vraiment être imbu pour refuser...

Interessant. Je reste vraiment surpris que ça tourne en 4 vbl. Je connais le graphiste mais il ne se souvient plus du framerate, il m'a répondu qu'il pense que c'est "every 2 frames" ou un truc du genre, ce qui ne colle pas avec ce qu'on semble voir. Je vais essayer de voir si il est encore en contact avec le coder pour lui demander car ça m'intrigue 

Tout à fait d'accord. ça m'étonne aussi : il est facile de le faire en 2 vbls et donc avoir quelque chose de très fluide sans se casser la tête...
Mais je ne critiquerai pas le codeur : peut-être y a-t-il des contraintes qui nous sont inconnues ?

[Seb]

Interessant. Je reste vraiment surpris que ça tourne en 4 vbl. Je connais le graphiste mais il ne se souvient plus du framerate, il m'a répondu qu'il pense que c'est "every 2 frames" ou un truc du genre, ce qui ne colle pas avec ce qu'on semble voir. Je vais essayer de voir si il est encore en contact avec le coder pour lui demander car ça m'intrigue 

Tout à fait d'accord. ça m'étonne aussi : il est facile de le faire en 2 vbls et donc avoir quelque chose de très fluide sans se casser la tête...
Mais je ne critiquerai pas le codeur : peut-être y a-t-il des contraintes qui nous sont inconnues ?

Clair. C'est très facile de critiquer sur papier sans avoir essayé soi-même, sans parler des contraintes qu'on ne connait pas (financières, techniques etc) qu'une demo n'aurait pas, donc je ne me permettrai pas de critiquer le boulot du gars :)

En plus le jeu date de 1988, ça serait trop facile d'arriver 20 ans après en disant "c'est mal fait", on saurait faire mieux. Les connaissances et les techniques évoluent. Mais j'avoue que ca m'intrigue depuis qu'on en parle

Est-ce que le fait de devoir tourner sur 0.5 meg aurait pu être un problème et donner ce genre de perfs ?

[upsilandre]

Très décrié sur MD (et pour cause), j'espérais qu'il était mieux sur micro... et... bon c'est vraiment une bouse, un hymne à la laideur.

Sur MD le perso est un layer background.

[Invité]

Il m'a semblé avoir lu que le filtre était à 20 Khz, soit à peu près la même chose que le 2eme filtre du mig (celui qui ne se désactive pas). Il ne me semble pas qu'il y ait quelque chose pour les samples à faibles fréquences comme le mig.

C'est un filtre passe bas .
Le topic originel est là :
http://stardot.org.uk/forums/viewtopic.php?f=29&t=10874

il explique quand même que le 10 bits log est aussi bien que le 14 bits linéaires. Mais c'est son droit de le penser...

Là je peux pas donner mon avis, donc je te fais confiance .
Après es ce que la différence est sensible à l'oreille ??

Oui toujours rien... Et en plus pourquoi faire ? Prouver que l'archi pouvait égaler le mig en 2D ? Comme si cela avait un interet...
Ou prouver que les codeurs archi étaient nuls (ce qu'il affirme et qui est faux bien sur) ? Sans interet non plus...

En fait y'a pas mal d'infos ici (faut avoir envie de tout lire):
http://stardot.org.uk/forums/viewforum.php?f=29

et un topic plus probant ici :
http://stardot.org.uk/forums/viewtopic.php?f=29&t=10723

D'ailleurs un codeur archimedes dans un des topics lui dit bien que la théorie c'est bien, les cas d'école comme ça démo aussi, cependant c'est un peu plus compliqué dans un vrai jeu .

Il y a des domaines dans lequels l'archi est largement meilleur que le mig, notamment grace à son mode chunky. Il y a donc moyen de faire des choses jamais faites sur archi et infaisables sur un A500. Il ferait mieux de se concentrer sur ça au lieu de toujours critiquer les codeurs archimedes...

Effectivement, le problème de l'archie, je pense c'est que les codeurs ont essayé de faire de l'amiga au lieu de faire de l'archimedes avant tout .
De plus qd je parle de codeurs, ce sont des mecs qui ont fait des jeux, pas juste des concepts . 

Le pire : il ne m'a jamais pris au sérieux quand je lui ai dit que je lui donnerait volontier l'optim dont je lui avait parlé (et qu'il croyait spécifique au mig parce que j'étais un "imbécile incapable de raisonner avec les spécificités de l'archimedes") s'il faisait juste la démarche de la demander...
Dommage pour lui : l'optim utilise les spécificités de l'archi, les forces de l'arm et permet de contourner les contraintes des accès mémoires. On est loin des sprites pré-shités avec accès 32 bits dans un code généré et déroulé qu'il prend pour une révolution...
Il pourrait chercher pendant des années qu'il ne trouverait pas.

C'est son problème, toujours sur la défensive, mais je te rassure, il n'a pas changé .
il faisait le malin sur une video comparative de pacmania (amiga vs archie), avec toujours la même rengaine, et à un moment un com de ce mec arrive:

Well sucks for you chap, because YOU are wrong, but its not the first time.

Pac-Mania on the Amiga is in DUAL PLAYFIELD mode, so its NOT in 4 bitplanes. Its in 2x Playfields with 3 bitplanes each. Pacman is a 16 colour hardware sprite.

I have no idea why Shaun Hollingsworth and Pete Harrap opted to code the game like this, a lack of programming experience back in 1988 is the likely reason, because this game could EASILY have been done in 32 colours 5 bitplane mode and the Amiga wouldn't even have been breaking a sweat either moving 5 ghost bobs at a time.

As for describing the co-processors in the Amiga as weak, a bold claim indeed, but those 'weak' processors enabled games the Archimedes couldn't hope to achieve.

The overscan scrolling in Pac-Mania, the Amiga does in its sleep with not much of a hit at all.

I note with humoured disinterest that you opted to disable comments on your Shaun Hollingsworth video when I corrected you about your falsehoods before.

Its here now, and you can't hide from it you coward, feel free to chime in with something snappy any time you like, your information on Amiga Pac-Mania is wrong, and Shaun Hollingsworth sure a hell doesn't remember much of what he did in 1988, especially as Pete Harrap would have done the bulk of the coding in any case.

Now, show me where the Archimedes can do Lionheart, Elfmania, Shadow of the Beast, Jim Power, to the same abilities as the lowly Amiga A500... and then tell me again how 'weak' its co-processors are lol

je pense que tu dois savoir qui c'est 

En plus le jeu date de 1988, ça serait trop facile d'arriver 20 ans après en disant "c'est mal fait", on saurait faire mieux. Les connaissances et les techniques évoluent. Mais j'avoue que ca m'intrigue depuis qu'on en parle 

Entièrement d'accord, et puis faut pas oublier non plus les probables contrainte de temps que l'on a pas aujourd'hui en hombrew .

@upsilandre: marrant je m'attendais pas à ça, mais bon quand on y repense ça parait normal pour éviter le clignotement .

[upsilandre]

@upsilandre: marrant je m'attendais pas à ça, mais bon quand on y repense ça parait normal pour éviter le clignotement .

Et meme avec ca y a deja de l'overflow sur le gif.

[Invité]

Bah avec la taille des sprites fallait un peu s'y attendre,cependant il semble qd même assez contenu et discret .