Re: Amiga vs consoles (Snes, Md, Pc Engine,.......)

par dlfrsilver Jeu 25 Sep 2014 - 19:01

TotOOntHeMooN a écrit:
dlfrsilver a écrit:Wing commander est déjà compatible 1200.
Il était lent et en 16 couleurs... Avec son patch, ça a permis de l'avoir en 256 couleurs, installable sur disque dur et avec un affichage bien plus rapide.
D'ailleurs, je ne serai pas surpris que son code ait été utilisé à l'époque pour la version CD32.
(en tout cas, c'est toujours dispo sur Aminet)

Le jeu est sorti en 2 version : 1 version en 32 couleurs pour Amiga, compatible toute machine (j'ai l'original), et une version CD32 en 256 couleurs officielle. Celle-ci a été hackée par les pirates de l'époque pour tourner sur A1200 (ce qui n'était pas prévu au départ).

par Invité Jeu 25 Sep 2014 - 19:41

Effectivement mais encore une fois je pense que le jeu est très light en logique, 2 persos à afficher et à gérer, même avec du merde c'est le genre de jeu qui va bien tourner, la seule difficulté, c'est la bande passante pour la mise à jour du sprite.

Oui bien sur c'est pas un shoot ou un BTU ..

Effacer la VRAM ? pourquoi faire ??
Sinon justement je n'ai pas vu ce genre de code (memset, memcpy en gros), en même temps je n'ai pas regardé longtemps...
Effectivement s'il simule des move plutot que de faire du txx ou de la copie de bloc (mais la copie de bloc c'est génant pour les digits j'imagine...) c'est malheureux.

Aucune idée, j'ai vu une fonction qui faisait ça, je peux pas te dire le pourquoi du comment ..
Comme il manque le programme principal et pas mal d'autres routines, je peux pas dire ce qui est réellement utilisé de ce qui ne l'est pas .
Les txx c'est gênant jusqu'à un certain point des chunks de 32 octets ou 64 pour être safe et c'est sans problème .

Oui oui enfin là pour le coup, même sur 68000 c'est plus rapide, c'est pour ça que je disais que le code 68000 n'était pas particulièrement optimisé, on sent que le développer a privilégié la lisibilité... et surtout s'il en avait pas besoin il a bien eu raison.
D'ailleurs une question tout conne, c'est quoi du code lisible sur 6502 ? non parce-que vu l'architecture du CPU j'ai du mal à imagine un code propre et lisible... rapidement tu as beaucoup de ligne de code pour faire peu d'instruction, ça doit forcément être un peu plus fouillis.

Après ce sont que des exemples pris dans des fonctions, mais je suppose que de ton côté c'est pas nouveau non plus sur 68000 tu a du voir du code merdique aussi, ou le coup des multiple transferts DMA sur SF2 ..

Piur la lisibilité, mon code l'est largement mieux, bien indenté+coloration syntaxique (bon faut vivre avec son temps) c'est propre .
Bon pas comme du code 68K faut pas rêver non plus mais très lisible pour un codeur (enfin je pense) ..
Les macros rajoutent bcp à la lisibilité au détriment de la vitesse hélas .
Réellement le 6280 est un CPU qui te donnera satisfaction si tu aimes l'optimisation extrême avec un gain de vitesse important, mais au détriment de la lisibilité et de la taille du code .
Je l'apprécie pour ça,je l'aime bcp moins qd il s'agit de faire du mapping de données .

Ouais je sais, mais j'ai regardé le jeu, et au moment du zoom tu noteras que le jeu utilise plusieurs frames pour mettre à jour la map et les sprites, après ça passe plutot bien mais ça fait quand même une petite pause dans le jeu.

Normal, comme il ne s'agit pas d'un vrai zoom, tu as que 2 étapes, donc passer de l'une à l'autre à la frame ne doit pas faire joli .

Le 68000 doit passer les instructions du 6502 en 1:1, après effectivement vu le débit d'instruction sur la PCE, ça ne tiendrait pas sans optimisation spécifique

Voilà, tu peux tirer bcp du 6280 à condition de coder pour,et pas faire du 68000 ou même du 6502 dessus, c'est un peu comme faire du 68000 en utilisant peu les registres .

sur SNES je me demande

J'ai regardé un peu les instructions du 65816 et elles sont plus nombreuses et plus puissantes que celle du 6280 (a première vu) .
Je parle du 65816 classique, celui de la snes avec sa ram lente + son bus et le fait qu'il doit faire du 3 mhz en moyenne avec de la fast rom, plus tout les cycles que tu dois perdre quand tu veux gérer les sprites (c'est une cata sur snes), bah faut le pousser à fond en terme de code optimisé, ce que peu de dev savaient faire je pense .
Bon je parle que du CPU, sans parler des contraintes moisies sur les tailles .

Ca montre quand même que le 68000 est relativement puissant puisque le code est clairement pas optimisé pour son architecture et en plus il gère une surcouche d'émulation :

Oui, mais aussi il est tellement simple à coder que tu peux facilement faire quelque chose de bien sans te casser le cul, même si pour moi tu peux faire moins d'optimisations à cause justement de ses instructions puissantes, mais figées, forcement elles font pleins de choses .
Tu rajoutes ça à la conception bien pensée de la MD, le 68000 n'a pas à gaspiller des cycles pour rien, en plus aidé par le Z80 ..
La PCE est pareille, elle aussi bien conçu que la MD, dans le sens ou y'a rien de tordu, et encore plus simple à programmer, c'est pour ça que le CPU peut donner tout ce qu'il à pour le jeu, comme sur MD .

PS: je vais lire l'article, mais il est long Wink

Oui bien sur, c'est la raison pour laquelle je dis que c'est n'importe quoi de comparer les cycles des différentes instructions des CPU.

Je suis d'accord, logiquement il faudrait comparer tout sur un pied d'égalité en matière de code, j'entends par des codeurs spécialisé sur chacune des archis .
C'est pour ça qu'en fait comparer des jeux de l'époque ne veux rien dire .

Un vrai comparatif c'est d'implémenter le même algo sur chaque CPU en prenant soin de correctement les utiliser et ensuite de comparer le résultat.

C'est vrai, mais c'est toujours pareil quel algo ??
Tu peux avoir des algos plus performants sur une archi et d'autres sur l'autre .
Mais dans l'absolu je pense aussi, ou alors prendre un jeu sur une machine qui n'a rien à voir, et faire une adaptation sur les 3 ..
Les 65xx sont très root, et ne peuvent donner leur max qu'en assembleur, ils ne sont fait que pour ça, en plus du temps qu'il faut pour les maitriser complètement .
Le 68000 n'a pas ça, il est à l'aise aussi bien en ASM qu'en C par exemple, et pour l'industrie du jeu y'a pas photo tu coderas bien plus vite avec un code plutôt efficace même si le codeur n'est pas un tueur .
Sur 65xx c'est makash, si tu codes mal, c'est sanction directe en perfs,par contre si tu codes bien c'est pur bonheur ..

EDIT:je viens de lire l'article, c'est pas mal du tout même si c'est mario bros qui est émulé .
Tomaithéous lui émule directement la rom nes d'origine sur PCE, bien sur le code natif 6502 aidant ça soulage, cependant il émule tout le reste à la volée, PPU,IO,SON etc ..

par **TotOOntHeMooN** Jeu 25 Sep 2014 - 20:21

dlfrsilver a écrit:Le jeu est sorti en 2 version : 1 version en 32 couleurs pour Amiga, compatible toute machine (j'ai l'original), et une version CD32 en 256 couleurs officielle. Celle-ci a été hackée par les pirates de l'époque pour tourner sur A1200 (ce qui n'était pas prévu au départ).

La version Amiga date de 1992 alors que la version CD32 est arrivée en 1994...
Je te parle de cette première version qu'il a patché à l'époque pour qu'elle soit en 256 couleurs, etc.

En suite, il a fait un crack pour utiliser la version CD32 directement dans un A1200 ou A4000.
Ca utilise la Fast RAM et une routine C2P perso qui permet d'être 5x plus rapide à l'affichage.
(ce que tu appels un pirate de l'époque...)

par dlfrsilver Jeu 25 Sep 2014 - 21:11

TotOOntHeMooN a écrit:
dlfrsilver a écrit:C'est tout sauf de la bidouille, faut savoir faire mieux que ça pour reprendre un jeu tel que celui-là de A à Z. Recoder EOB I et II ça lui a pris 8 mois !
8 mois, je suis quand même surpris... Hormis s'il a effectivement recodé tout le jeu.

Passer un jeu OCS/ECS en AGA, ça nécessite de patcher le mode graphique pour qu'il soit en 8 bitplan au lieu de 4/5 bitplan et substituer les anciennes resources avec les nouvelles. (gfx et texte dans ton cas)
Un amis avait fait quelque chose de semblable avec WingCommander, pour l'utiliser sur A1200 à l'époque.

Pour EOB, non seulement retoucher le moteur graphique, mais surtout comprendre ce que fait le code (et ça c'est carrément pas de la tarte ! surtout quand tu n'as pas les lignes de code commentée d'origine), et il suffit pas de dire on passe en 8 bitplans depuis 4/5, ça entraine d'autres modifs dans le code, c'est carrément coton.

par dlfrsilver Jeu 25 Sep 2014 - 21:20

TotOOntHeMooN a écrit:
dlfrsilver a écrit:Le jeu est sorti en 2 version : 1 version en 32 couleurs pour Amiga, compatible toute machine (j'ai l'original), et une version CD32 en 256 couleurs officielle. Celle-ci a été hackée par les pirates de l'époque pour tourner sur A1200 (ce qui n'était pas prévu au départ).
La version Amiga date de 1992 alors que la version CD32 est arrivée en 1994...
Je te parle de cette première version qu'il a patché à l'époque pour qu'elle soit en 256 couleurs, etc.

En suite, il a fait un crack pour utiliser la version CD32 directement dans un A1200 ou A4000.
Ca utilise la Fast RAM et une routine C2P perso qui permet d'être 5x plus rapide à l'affichage.
(ce que tu appels un pirate de l'époque...)

Si c'est le cas, je ne l'ai jamais vue, ni sur FTP, ni dans le TOSEC, ni dans les collections de jeux piratés des BBS de la belle époque (et j'en ai une sacré palanquée sur DVD pleins à craquer....).

Wing commander pour A500 patché pour être utilisé en 256 couleurs ? Tu confonds les deux. Impossible de reprendre la version A500 pour la transformer en version 256 couleurs (la raison est simple, pour arriver à faire ça, il aurait fallu qu'il accède aux données de la version PC, et coder un décrypteur/décompresseur pour extraire les données, et les réencoder pour la version amiga.

Non c'est la version CD32 de 1994 qu'il a patché, j'ai trouvé son patch sur aminet :

Le nom de ton pote c'est Antoine Chavasse si j'ai bien compris ? Son patch sert à faire tourner la version CD32 officielle sur A1200 sans le support akiko de la CD-32.

(Mais je t'en veux pas, tout le monde peut se tromper et puis la mémoire hein, si on pouvait tout retenir MDR

ça se saurait.)

"
Short: Fix & Patch 4 Wing Commander CD .
Author: CdBS Software
Uploader: morb nef surle net (Antoine Chavasse)
Type: game/patch
Version: 2.1
Replaces: game/patch/WCPatch*
Requires: AGA, OS3.0+
Architecture: m68k-amigaos

UTILISEZ WING COMMANDER CD³² SUR UNE MACHINE AGA SANS AKIKO

Modifie WC pour marcher avec de la FastRAM, remplace le C2P pour de meilleures
performances (accélère l'affichage jusqu'à 5 fois). Trainer Optionnel.

**** Supporte maintenant les fichiers compressés et la version allemande ****

1997-1998, CdBS Software.

Docs en Français et Anglais seulement.

Credits: Project Manager ........... Toxico Nimbus
Patch & C2P code .......... MORB
Argument parsing .......... Toxico Nimbus & MORB
Word of the Gods .......... Toxico Nimbus
ß-Test .................... Jan Vieten (especially german version)
Toxico Nimbus: · A4k + 060@50 + 604@200
· A1200 + 4Mo Fast
MORB: · A1200 + DKB 030@50
Troll: · A1200 + Blizzard 040@40

par **TotOOntHeMooN** Jeu 25 Sep 2014 - 22:09

dlfrsilver a écrit:Son patch sert à faire tourner la version CD32 officielle sur A1200 sans le support akiko de la CD-32.
(Mais je t'en veux pas, tout le monde peut se tromper et puis la mémoire hein, si on pouvait tout retenir ça se saurait.)

Oui, j'étais au lycée avec lui et je faisais parti de CdBS.
Et si je te parles de deux patchs, c'est bien qu'il y en a deux et pas un seul...
Celui que tu me montre, c'est le second. (au final c'est le mieux à utiliser)
Pour le premier, je ne le voit effectivement pas sur Aminet. Après, j'ai envie de dire que tu ne peux pas non plus tout avoir... A l'époque on avait pas Internet, on se passait des boites de disquettes, puis des CD à la récré. De plus, il m'avait fait voir ça chez lui.

par Stef Jeu 25 Sep 2014 - 23:05

TOUKO a écrit:
Après ce sont que des exemples pris dans des fonctions, mais je suppose que de ton côté c'est pas nouveau non plus sur 68000 tu a du voir du code merdique aussi, ou le coup des multiple transferts DMA sur SF2 ..

Le problème de multiple DMA sur SF2, c'est même pas vraiment un problème avec le code "bas niveau" mais carrément l'algo complet... comment se fait-il que la logique puisse être amené à faire 2 fois le transfert d'un même sprite ?? D'ailleurs je ne pas s'il transfère la même data, ça se trouve il commence pas transférer la prochaine frame "attendue" et dans certains cas la frame attendue est modifiée du coup il retransfère les données (car j'ai remarqué que le double transfert ne se fait pas à chaque fois)... enfin bref y'a vraiment un soucis quelque part.
Ca montre plus un problème de structuration du code, d'ailleurs dans le même genre encore mieux : à chaque fois que tu rentres dans le menu des options le pointeur de pile "augmente" (surement un goto en place d'un RTS quelque part), ça signifie que théoriquement en rentrant beaucoup de fois dans le menu des options tu pourrais finir par faire planter le jeu ! Bien sur ça n'arrive pas car tu ne fais jamais ce genre de chose mais ça démontre à quel point la structure du code n'est pas solide...

Piur la lisibilité, mon code l'est largement mieux, bien indenté+coloration syntaxique (bon faut vivre avec son temps) c'est propre .
Bon pas comme du code 68K faut pas rêver non plus mais très lisible pour un codeur (enfin je pense) ..
Les macros rajoutent bcp à la lisibilité au détriment de la vitesse hélas .

Alors là j'ai du mal à comprendre, au contraire les macros c'est ce qui te permet d'être rapide !
Si on parle bien de macros et pas de fonctions ça te permet de rendre ton code plus lisible tout en restant performant.

Réellement le 6280 est un CPU qui te donnera satisfaction si tu aimes l'optimisation extrême avec un gain de vitesse important, mais au détriment de la lisibilité et de la taille du code .

Perso je ne suis pas pour la "sur optimisation" qui complexifie énormément ton code (en le rendant plus gros aussi) pour des gains minimes, bien sur dans certains cas tu n'as pas le choix mais quand ça m'est possible je privilégie la lisibilité même si ça doit être un peu plus lent.
Mais il ne faut pas croire le 68000 a une grosse marge d'optimisation aussi,

J'ai regardé un peu les instructions du 65816 et elles sont plus nombreuses et plus puissantes que celle du 6280 (a première vu) .
Je parle du 65816 classique, celui de la snes avec sa ram lente + son bus et le fait qu'il doit faire du 3 mhz en moyenne avec de la fast rom, plus tout les cycles que tu dois perdre quand tu veux gérer les sprites (c'est une cata sur snes), bah faut le pousser à fond en terme de code optimisé, ce que peu de dev savaient faire je pense .
Bon je parle que du CPU, sans parler des contraintes moisies sur les tailles .

Qu'elles soient plus puissantes ça me parait normal, c'est un CPU 16 bits malgré tout (enfin 8/16) et tu as donc accès aux opérations 16 bits mais je pense que le 68000 doit quand même toutes les traduire en 1:1 de ce que je m'en souviens. Puis le débit est un peu plus lent, tu te prends souvent 1 cycle de pénalité (un peu comme sur le 6280 il me semble).

Oui, mais aussi il est tellement simple à coder que tu peux facilement faire quelque chose de bien sans te casser le cul, même si pour moi tu peux faire moins d'optimisations à cause justement de ses instructions puissantes, mais figées, forcement elles font pleins de choses .
Tu rajoutes ça à la conception bien pensée de la MD, le 68000 n'a pas à gaspiller des cycles pour rien, en plus aidé par le Z80 ..
La PCE est pareille, elle aussi bien conçu que la MD, dans le sens ou y'a rien de tordu, et encore plus simple à programmer, c'est pour ça que le CPU peut donner tout ce qu'il à pour le jeu, comme sur MD .

Non mais justement dans le cas présent c'était de la bête traduction d'instruction 6502 en 68000 donc autant dire que le 68000 était hyper mal utilisé (plein d'accès mémoire, zero utilisation des registres et travaille en 8 bits uniquement) et pourtant ça tourne quand même tout en gérant la petite couche d'émulation. Et pour le moins d'optimisations je ne suis pas d'accord, un instruction set plus riche te donne *forcément* plus de possibilités, pas sur une opération en particulier, mais sur un algo... ne serait que le fait de faire tenir toutes les variables de travail en registre. C'est un niveau d'optimisation qui n'existe pas sur le 6502...

EDIT:je viens de lire l'article, c'est pas mal du tout même si c'est mario bros qui est émulé .
Tomaithéous lui émule directement la rom nes d'origine sur PCE, bien sur le code natif 6502 aidant ça soulage, cependant il émule tout le reste à la volée, PPU,IO,SON etc ..

Ouais sur PCE le code est quand même natif c'est autre chose, les ~4.5 Mhz de plus (car il faut surement un 6280 à 2.5 Mhz pour un 6502 à 1.8 Mhz ?) permette l'émulation du PPU, IO & APU. Sur MD c'est la même chose sauf que le code 68000 généré est sous efficace pour ce type de CPU...

par Invité Ven 26 Sep 2014 - 9:41

Le problème de multiple DMA sur SF2, c'est même pas vraiment un problème avec le code "bas niveau" mais carrément l'algo complet... comment se fait-il que la logique puisse être amené à faire 2 fois le transfert d'un même sprite ?? D'ailleurs je ne pas s'il transfère la même data, ça se trouve il commence pas transférer la prochaine frame "attendue" et dans certains cas la frame attendue est modifiée du coup il retransfère les données (car j'ai remarqué que le double transfert ne se fait pas à chaque fois)... enfin bref y'a vraiment un soucis quelque part.
Ca montre plus un problème de structuration du code, d'ailleurs dans le même genre encore mieux : à chaque fois que tu rentres dans le menu des options le pointeur de pile "augmente" (surement un goto en place d'un RTS quelque part), ça signifie que théoriquement en rentrant beaucoup de fois dans le menu des options tu pourrais finir par faire planter le jeu ! Bien sur ça n'arrive pas car tu ne fais jamais ce genre de chose mais ça démontre à quel point la structure du code n'est pas solide...

LOL, c'est pire que ce que je pensais en fait ..
Mais tu vois, les mecs se sont dit, bon ça marche pas trop mal on laisse comme ça .
Comme le driver Z80 original de SF2 pour les samples, j'ai vu le source que tu as publié, il est nul on dirait qu'il a été codé par un débutant, même moi j'aurait fait mieux lol .
Mais surtout les problèmes de deadline (encore et toujours eux) ,ont fait que ça sorte avec des digits merdiques sans trop avoir mauvaise conscience, et le pire c'est qu'ils ont gardé quasiment le même driver pour SSF2.

Alors là j'ai du mal à comprendre, au contraire les macros c'est ce qui te permet d'être rapide !
Si on parle bien de macros et pas de fonctions ça te permet de rendre ton code plus lisible tout en restant performant.

Oui pour coder, mais pas en terme d'efficacité, car elles sont génériques, donc pas optimales .
Tu penses trop code 68k là, n'oublies pas qu'une instruction 68000 qui fait 5 choses par exemple, bah tu peux pas lui faire faire juste 3 choses parce que les 2 autres te servent à rien, une macro c'est pareil, alors que justement les instructions simples des 65xx te permettent ce genre de trucs qui font gagner des cycles .

Perso je ne suis pas pour la "sur optimisation" qui complexifie énormément ton code (en le rendant plus gros aussi) pour des gains minimes, bien sur dans certains cas tu n'as pas le choix mais quand ça m'est possible je privilégie la lisibilité même si ça doit être un peu plus lent.
Mais il ne faut pas croire le 68000 a une grosse marge d'optimisation aussi,

Voilà on entre dans le choix de ce que l'on veut faire .
Si tu veux faire prog rapide et code propre ,facilement maintenable tu prend le 68000, si tu cherches la perf pure, aux dépend du reste c'est 65xx .
Je ne dit pas que le 68000 n'a pas d'optimisations, mais elle s'arrête à tes instructions qui sont certe puissantes mais figées .
Un exemple basique, le fait de travailler sur des var en 8 bit ne te font rien gagner contrairement au 65xx,en plus les var 16 bit ne te pénalises pas non plus car tu peux encore optimiser leur traitement justement par un traitement 8 bit de ces variables .
Les vars 32 bit, perso sur PCE c'est complètement inutile, j'en utilise jamais .
Les optimisations 68000 sont dans la majorité applicables aussi sur les autres CPU,et comme je te disais je parle seulement pour les jeux 2D ce que je connais, la demo ou la 3D faut voir ça avec les gourous du 65xx qui eux pourront vraiment te dire les perfs que tu peux attendre de ces CPU, et en l'occurrence du 6280 @7,16 mhz .
Parce qu'il y a un monde entre un codeur intermédiaire comme moi et des experts comme eux .

Qu'elles soient plus puissantes ça me parait normal, c'est un CPU 16 bits malgré tout (enfin 8/16) et tu as donc accès aux opérations 16 bits mais je pense que le 68000 doit quand même toutes les traduire en 1:1 de ce que je m'en souviens. Puis le débit est un peu plus lent, tu te prends souvent 1 cycle de pénalité (un peu comme sur le 6280 il me semble).

Sur celui de la snes tu prends des pénalités en accédant à la WRAM, mais tu fais plus travailler ton accumulateur qui est 16 bit, comme les registres d'index .
Sur les accès WRAM il a les même cycles que le 6280, alors qu'en temps normal il a les mêmes que le 6502(c'est juste 1 cycles en moins), par contre il fait des opérations avec l'accumulateur sur 16bit en 4 cycles, et tu as pas mal de pénalités qui sautent aussi en mode 16 bit, comme tout les branchements qui passent à 2 cycles branchement ou pas .

Non mais justement dans le cas présent c'était de la bête traduction d'instruction 6502 en 68000 donc autant dire que le 68000 était hyper mal utilisé (plein d'accès mémoire, zero utilisation des registres et travaille en 8 bits uniquement) et pourtant ça tourne quand même tout en gérant la petite couche d'émulation. Et pour le moins d'optimisations je ne suis pas d'accord, un instruction set plus riche te donne *forcément* plus de possibilités, pas sur une opération en particulier, mais sur un algo... ne serait que le fait de faire tenir toutes les variables de travail en registre. C'est un niveau d'optimisation qui n'existe pas sur le 6502...

C'est justement à cause de ça qu'on à du mal à se mettre d'accord .
Car tu pense toujours 68000, c'est justement au niveau instructions que la différence se fait tu utilises des instructions puissantes mais pas optimisables en tant qu'instructrion .
Un exemple: comment tu fais un incrément de 256 sur une var 16 bit avec le 68000 ??
C'est un exemple courant car ça correspond à un changement de pattern sur un sprite 32x32 pixels .

Ouais sur PCE le code est quand même natif c'est autre chose, les ~4.5 Mhz de plus (car il faut surement un 6280 à 2.5 Mhz pour un 6502 à 1.8 Mhz ?) permette l'émulation du PPU, IO & APU. Sur MD c'est la même chose sauf que le code 68000 généré est sous efficace pour ce type de CPU...

Oui mais tout les reste sur 68000 est traduit, là sur 6280 tout le reste, est fait à la volée, su 68000 tu émules le 6502, sur 6280 tu as le ppu, le proc son, les IO.
Après ça reste pas mal pour le 68000, faut juste voir avec un recca ou blade buster, donc avec du code optimisé 6502 Wink

par cryodav76 Ven 26 Sep 2014 - 13:04

oua vous etes barré grave je comprend plus rien
Very Happy

sinon on est d'accord l'amiga ce defend quand meme bien,meme fasse a la megadrive et snes il peu etre surprenant quand on l'a connu avant les année 90 ,il y a eu de grand progres niveau programmation a parti de 1990 quand l'atari st a decliner et qu'il y a eu des exclusivités

par dlfrsilver Ven 26 Sep 2014 - 13:40

oui c'est certain. Les programmeurs avaient l'habitude de porter directement le code 68000 sans faire usage de l'accélération matérielle proposée par l'amiga (=programmé comme un ST=jeux lents et mous)

par Stef Ven 26 Sep 2014 - 19:07

TOUKO a écrit:
LOL, c'est pire que ce que je pensais en fait ..
Mais tu vois, les mecs se sont dit, bon ça marche pas trop mal on laisse comme ça .
Comme le driver Z80 original de SF2 pour les samples, j'ai vu le source que tu as publié, il est nul on dirait qu'il a été codé par un débutant, même moi j'aurait fait mieux lol .
Mais surtout les problèmes de deadline (encore et toujours eux) ,ont fait que ça sorte avec des digits merdiques sans trop avoir mauvaise conscience, et le pire c'est qu'ils ont gardé quasiment le même driver pour SSF2.

Oui tu vois le driver son de SF2, c'est quand même exagéré sachant l'attente qu'il pouvait y avoir autour de ce jeu... Un minimum d'effort aurait permis de faire mieux, là vraiment le driver est écrit de la manière la plus naïve qui soit (comme tu as pu t'en rendre compte).
Allez en étant large, le gars a peut être mis 2/3 jours a désigner et écrire son driver, et ce, en partant de zéro et sans aucune expérience sur le hardware son de la machine... franchement allouer 2/3 jours à cette partie, c'est malheureux sachant l'impact final sur le jeu.
Avec mon expérience j'ai mis environ 2/3 jours pour écrire le driver qui corrige le problème, sachant que j'ai du gérer la retro-compatibilité avec le driver d'origine et que je suis nul en programmation Z80 (j'avoue je déteste ce CPU MDR

)...

Oui pour coder, mais pas en terme d'efficacité, car elles sont génériques, donc pas optimales .
Tu penses trop code 68k là, n'oublies pas qu'une instruction 68000 qui fait 5 choses par exemple, bah tu peux pas lui faire faire juste 3 choses parce que les 2 autres te servent à rien, une macro c'est pareil, alors que justement les instructions simples des 65xx te permettent ce genre de trucs qui font gagner des cycles .

En général je fais des macros assez optimales avec des paramètres pour ignorer les parties inutiles par ex...
Enfin pour moi les macros c'est justement pour la rapidité tout en conservant de la lisibilité... Sinon comment tu fais ? tu écris chaque ligne de ton code assembleur ?

Voilà on entre dans le choix de ce que l'on veut faire .
Si tu veux faire prog rapide et code propre ,facilement maintenable tu prend le 68000, si tu cherches la perf pure, aux dépend du reste c'est 65xx

Haha tu sous entends que le 65XX est plus perf lol
A mon sens le 65XX ne t'offre pas le choix, si tu veux que le code tourne bien tu es obligé d'avoir une écriture un peu tricky et d'avoir des structures de données vraiment adaptées au CPU quitte à perdre en lisibilité.

Un exemple basique, le fait de travailler sur des var en 8 bit ne te font rien gagner contrairement au 65xx,en plus les var 16 bit ne te pénalises pas non plus car tu peux encore optimiser leur traitement justement par un traitement 8 bit de ces variables .
Les vars 32 bit, perso sur PCE c'est complètement inutile, j'en utilise jamais .
Les optimisations 68000 sont dans la majorité applicables aussi sur les autres CPU,et comme je te disais je parle seulement pour les jeux 2D ce que je connais, la demo ou la 3D faut voir ça avec les gourous du 65xx qui eux pourront vraiment te dire les perfs que tu peux attendre de ces CPU, et en l'occurrence du 6280 @7,16 mhz .
Parce qu'il y a un monde entre un codeur intermédiaire comme moi et des experts comme eux .

Oui mais justement ça marche dans les 2 sens le coup du 8 bits, comme le 68000 gère le 16 bits gratuitement ben une partie de l'optimisation est de faire du SIMD quand c'est possible (tu traites 2 data 8 bit en une seule instruction, voire 4), c'est pour ça que pour moi le 68000 te permettra d'aller bien plus loin quoiqu'il arrive... vraiment je pense que tu n'as pas assez d’expérience sur le 68000 pour te rendre compte. Et franchement tu peux m'appeler tout les gourous du 65XX sur le forum, à mon avis ils auront bien du mal à me convaincre que tu as plus de marge d'optimisation sur ce CPU :p Je veux bien comprendre qu'elles (les optis) soient plus accès sur les tricks (instruction non documentée...) mais vu la richesse du l'instruction set du 68000 tu pourras toujours aller plus loin quand il s'agit des traitements de masse (les "bottlenecks").

C'est justement à cause de ça qu'on à du mal à se mettre d'accord .
Car tu pense toujours 68000, c'est justement au niveau instructions que la différence se fait tu utilises des instructions puissantes mais pas optimisables en tant qu'instructrion.

On peut dire que sur 68000 y'a un level optimal d'optimisation c'est vrai : 4 cycles par opérations 16 bits + 4 cycles par accès mémoire 16 bits, Évidemment tu n'es jamais à ces valeurs mais le but c'est de t'en approcher en adaptant ton code... et crois moi quand tu te rapproches de ces valeurs théoriques ton 6280, même à 7 Mhz aura bien du mal à lutter !
Sur le 6280 aussi tu as des valeurs théoriques, je dirais 2/3 cycles par op 8 bits + 3 cycles par accès mémoire 8 bits, certes moins de cycles mais 8 bits seulement :-/

Un exemple: comment tu fais un incrément de 256 sur une var 16 bit avec le 68000 ??
C'est un exemple courant car ça correspond à un changement de pattern sur un sprite 32x32 pixels .

Oui mais tu vois, pour moi cet exemple ne veut rien dire... tu ajoutes 256 à une variable en mémoire, dans un registre ??
en registre : 4 cycle (le minimum sur un 68000)
en mémoire : 12 cycles ... forcément : 4 cycles pour lire l'instruction, 4 cycles de lecture en mémoire + 4 cycles d'écriture en mémoire.
Mais voilà ce genre d'opération en mémoire pris de manière isolé n'a aucun intérêt... toi avec ton CPU tu vas toujours travailler en mémoire car tu n'as pas le choix, sur 68000 tu vas charger les données pertinentes de ton sprite dans les registres, tu vas les "traiter" et ensuite les renvoyer en mémoire. Et là le calcul devient tout à fait différent !

Oui mais tout les reste sur 68000 est traduit, là sur 6280 tout le reste, est fait à la volée, su 68000 tu émules le 6502, sur 6280 tu as le ppu, le proc son, les IO.
Après ça reste pas mal pour le 68000, faut juste voir avec un recca ou blade buster, donc avec du code optimisé 6502

Sur 68000 aussi il utilise une couche d'émulation pour le PPU, seul le son est directement traduit...

par Invité Sam 27 Sep 2014 - 20:03

Oui tu vois le driver son de SF2, c'est quand même exagéré sachant l'attente qu'il pouvait y avoir autour de ce jeu... Un minimum d'effort aurait permis de faire mieux, là vraiment le driver est écrit de la manière la plus naïve qui soit (comme tu as pu t'en rendre compte).
Allez en étant large, le gars a peut être mis 2/3 jours a désigner et écrire son driver, et ce, en partant de zéro et sans aucune expérience sur le hardware son de la machine... franchement allouer 2/3 jours à cette partie, c'est malheureux sachant l'impact final sur le jeu.
Avec mon expérience j'ai mis environ 2/3 jours pour écrire le driver qui corrige le problème, sachant que j'ai du gérer la retro-compatibilité avec le driver d'origine et que je suis nul en programmation Z80 (j'avoue je déteste ce CPU )...

Et tu imagines que c'est mecs ont quand même l'habitude du Z80, tu peux aisément imaginer le massacre sur un CPU comme le 65816 qu'ils ne connaissaient pas .

En général je fais des macros assez optimales avec des paramètres pour ignorer les parties inutiles par ex...

Tu peux pas toujours faire ce genre de truc si tu veux des macros génériques, si c'est pour multiplier les macros pour des cas particuliers, autant coder directement .
Et puis dans bcp de jeux les mecs se font pas chier, les macros étaient pourries, AOF le montre bien.

Enfin pour moi les macros c'est justement pour la rapidité tout en conservant de la lisibilité... Sinon comment tu fais ? tu écris chaque ligne de ton code assembleur ?

Oui moi aussi, donc rien n'empêche d'utiliser des macros sur des parties non critiques, ou tout dépend des macros
une macro style:
stw #$2000 , mar_var elle ferra
lda #LOW($2000)
sta ma_var
lda #HIGH($2000)
sta ma_var + 1

par exemple, ne posera pas de problème, même si dans ce cas là tu gagneras en faisant:
stz ma_var
lda #HIGH($2000)
sta ma_var + 1

Oui mais justement ça marche dans les 2 sens le coup du 8 bits, comme le 68000 gère le 16 bits gratuitement ben une partie de l'optimisation est de faire du SIMD quand c'est possible (tu traites 2 data 8 bit en une seule instruction, voire 4), c'est pour ça que pour moi le 68000 te permettra d'aller bien plus loin quoiqu'il arrive... vraiment je pense que tu n'as pas assez d’expérience sur le 68000 pour te rendre compte. Et franchement tu peux m'appeler tout les gourous du 65XX sur le forum, à mon avis ils auront bien du mal à me convaincre que tu as plus de marge d'optimisation sur ce CPU :p Je veux bien comprendre qu'elles (les optis) soient plus accès sur les tricks (instruction non documentée...) mais vu la richesse du l'instruction set du 68000 tu pourras toujours aller plus loin quand il s'agit des traitements de masse (les "bottlenecks").

Non, car par exemple pour l'incrémentation 16 bit je ferrais juste un
inc 6 cycles, pas d'init rien, et tu applique ça à plein de cas, et sur un jeu rien que ça, ça te fait un gain non négligeable .
J'ai pas à me casser le cul à organiser mes variables,j'utilise bcp de 8 bit, et peu de 16 bit car j'en est aucune utilité sauf pour les pointeurs
et là aussi le 6280 est performant .
Avec les lut est les modes indéxés performants tu crées du code pas compact certe mais très rapide .
Tu me dis que j'ai pas assez d'expérience pour comprendre, mais toi non plus Wink

..
Et comme exemple je prends toujours RR², un maitre du 6502 aux commandes et pour son premier jeu sur snes c'est impressionnant .

Après je cherches pas à te convaincre, puisque je sais bien que c'est peine perdue, mais bon même avec les exemples de la PCE tu es hermétique malgré tout ce que je te montre ..

Oui mais tu vois, pour moi cet exemple ne veut rien dire... tu ajoutes 256 à une variable en mémoire, dans un registre ??
en registre : 4 cycle (le minimum sur un 68000)
en mémoire : 12 cycles ... forcément : 4 cycles pour lire l'instruction, 4 cycles de lecture en mémoire + 4 cycles d'écriture en mémoire.
Mais voilà ce genre d'opération en mémoire pris de manière isolé n'a aucun intérêt... toi avec ton CPU tu vas toujours travailler en mémoire car tu n'as pas le choix, sur 68000 tu vas charger les données pertinentes de ton sprite dans les registres, tu vas les "traiter" et ensuite les renvoyer en mémoire. Et là le calcul devient tout à fait différent !

On va dire en mémoire, faut bien que tu change les pattern de tes sprites dans la SAT par exemple, alors tu fais comment ??
Moi même dans un reg c'est
lda inc A
voilà 6 cycles et 2 si je compte pas l'init.. Razz

Et y'a bien un moment ou il faut que tu le sauve ton increment dans le reg non ..

par Stef Sam 27 Sep 2014 - 22:06

TOUKO a écrit:Non, car par exemple pour l'incrémentation 16 bit je ferrais juste un
inc <ptr+1
6 cycles, pas d'init rien, et tu applique ça à plein de cas, et sur un jeu rien que ça, ça te fait un gain non négligeable .
J'ai pas à me casser le cul à organiser mes variables,j'utilise bcp de 8 bit, et peu de 16 bit car j'en est aucune utilité sauf pour les pointeurs
et là aussi le 6280 est performant .
Avec les lut est les modes indéxés performants tu crées du code pas compact certe mais très rapide .
Tu me dis que j'ai pas assez d'expérience pour comprendre, mais toi non plus ..
Et comme exemple je prends toujours RR², un maitre du 6502 aux commandes et pour son premier jeu sur snes c'est impressionnant .

Après je cherches pas à te convaincre, puisque je sais bien que c'est peine perdue, mais bon même avec les exemples de la PCE tu es hermétique malgré tout ce que je te montre ..

Ouais mais 6 cycles c'est toujours plus que 4, j'avoue que je ne comprend pas ton blocage là dessus mais passons...
Et franchement à aucun moment je n'ai vu de truc hyper impressionnant où je me suis dit "Ah ouais le CPU en a quand meme dans le ventre !" avec tout ce que tu m'as montré sur PCE... Tu me trouvera toujours des comparaisons foireuses ou le jeu tourne mieux sur PCE que sur MD (mais l'inverse existe aussi) mais voilà, en prenant les jeux les plus impressionnants techniquement sur le PCE et ben y'a pas photo, je les trouve un cran en dessous ce qu'on trouve de mieux sur MD en terme d'animation de charge de sprite en général. Par exemple Shapphire, si tu lui enlèves les boss superbement animés, la fausse 3D précalculée grace au stockage infini du CD ben je le trouve pas si impressionnant que ça. Certes c'est speed mais en terme d'animation il reste assez basique, pas des tonnes de sprites, des explosions simples... 1941 est un peu plus chargé en comparaison mais clairement toujours un cran en dessous de ce que tu peux voir sur MD. Et je t'ai déjà dit, je considère que le 6280 à 7 Mhz peut être aussi performant que le 68000 quand il n'est pas dans des cas défavorables (calcul mathématique, grosse données à traiter...), c'est déjà pas mal non ? :p

Pour le 65816 de la SNES, vraiment à la fréquence à laquelle il tourne ça vaut aps grand chose :p Quand tu vois R², certes pour un jeu SNES il gère beaucoup d'ennemis (wahoo une 15aine à l'écran !) mais que de faiblesses à côté de ça, pas d'animation, très peu de variété de sprites et c'est inerte au possible de manière général... Le gars a eu beau coder comme un dieu son 65816, il est quand même limité par la faiblesse du CPU, même en utilisant de la fast rom.

On va dire en mémoire, faut bien que tu change les pattern de tes sprites dans la SAT par exemple, alors tu fais comment ??
Moi même dans un reg c'est
lda <ma_var + 1
inc A
voilà 6 cycles et 2 si je compte pas l'init..
Et y'a bien un moment ou il faut que tu le sauve ton increment dans le reg non ..

Ce que je veux dire c'est que tu vas aussi modifier la position X et Y de ton sprite dans la SAT bien souvent en même temps ?
sur 68000 tu fais un load des valeurs qui t'intéressent (X pos, Y pos, tile addr soit 3x16 bits sur la SAT MD)

read : 8+4*3 = 24 cycles
update X pos : 4 cycles
update Y pos : 4 cycles
update tile addr : 4 cycles
write : 12+4*3 = 24 cycles

soit 60 cycles pour mettre le sprite à jour, et encore c'est parce que là je me contente de gérer que 3 valeurs (plus tu en gères en même temps, plus le gain sera intéressant) et en 16 bits (tu peux tout passer en 32 bits pour gagner encore quelques cycles).

Dans ton cas tu es bien d'accord que selon les cas de figure tu mettras plus ou moins de cycles pour mettre à jour toutes ces valeurs, c'est ridicule d'isoler à chaque fois une instruction comme tu le fais pour comparer :p

par cryodav76 Dim 19 Oct 2014 - 18:12

tient je viens de me procurer un snes pas chere ,je la branche et je me dis a moi les joie de mario kart,j'ai vite dechanté c'est quoi cet afichage! la ou mon amiga1200 c'etait precis la ça bave,ça clignote et la resolution est trop trop faible..
bon du coup je l'ai revendu parce que parfaitement injouable,par contre mon amiga surement grace au rvb + plus grande resolution passe tres bien,les pixel son lissés et le mode 720*512 est désentrelacé par la tv.

par pckid Dim 19 Oct 2014 - 18:48

L'amiga 500 ne possède qu'un bouton pour le tire et le saut c'est une galère,

C'est la plus grosse contrainte de l'amiga, avec les editeurs qui sont trop euro ou us.

Sinon cela aurait pu être le top du top face aux consoles, mais elles ont bénéficié d'une ludotheque incroyable, avec un gameplay sympatique. Malgrè leur gros point faible, c'est la cartouche qui n'etait pas copiable, elles ont reussi à s'imposer.

par Invité Mer 22 Oct 2014 - 12:09

Une demo de transparence en temps réel de tomaitheous/malducci sur PCE que j'ai retrouvé ..

Elle est faite en utilisant le CPU+VDC,et est largement faisable dans un jeu,j'essayerai de voir pour l'intégrer dans mon shoot si j'arrive à comprendre comment ça marche tongue

..

par airdream Jeu 23 Oct 2014 - 2:32

C'est en effet une belle performance!
Existe t-il des jeux PCE utilisant deja ce procede?

La methode du dithering utilise sur MD est aujourd'hui une horreur si on utilise un cable RGB ou TV de grande taille. (LCD, Plasma...)
Pour la MD preferez un bon cable compisite et une TV 36 cm CRT!!!
Explication ici :
[url=http://retro-sanctuary.com/comparisons - differing.html]http://retro-sanctuary.com/comparisons%20-%20differing.html[/url]

par Invité Jeu 23 Oct 2014 - 8:49

C'est en effet une belle performance!
Existe t-il des jeux PCE utilisant deja ce procede?

Non hélas, comme sur toutes les machines il s'agit d'un effet trouvé par une étude poussée de la machine, ce que faisait rarement les devs consoles de l'époque .

Un peu comme les samples sur MD .

La methode du dithering utilise sur MD est aujourd'hui une horreur si on utilise un cable RGB ou TV de grande taille. (LCD, Plasma...)

Oui le RGB c'est top, sauf que ça montre au grand jour les défauts, car le video composite par sa mauvaise qualité, fait une sorte de blur/antialising qui adoucit bcp les contours et les dégradés .

par cryodav76 Jeu 23 Oct 2014 - 9:10

TOUKO a écrit:
C'est en effet une belle performance!
Existe t-il des jeux PCE utilisant deja ce procede?
Non hélas, comme sur toutes les machines il s'agit d'un effet trouvé par une étude poussée de la machine, ce que ne faisait rarement les devs consoles .

Un peu comme les samples sur MD .

La methode du dithering utilise sur MD est aujourd'hui une horreur si on utilise un cable RGB ou TV de grande taille. (LCD, Plasma...)
Oui le RGB c'est top, sauf que ça montre au grand jour les défauts, car le video composite par sa mauvaise qualité, fait une sorte de blur/antialising qui adoucit bcp les contours et les dégradés .

non pour avoir tester recement une snes en composite c'est vraiment moche sur un plasma , mon amiga est juste 100 fois mieux et c'est aussi lissé comme sur un tube cathodique, evidement il faut pas ce mettre tout pret et le mode entrelacé est desentrelacé par la tv
ça doit dependre de la tv,de la source surement que certain couple fonctionnent mieux que d'autre

par Invité Jeu 23 Oct 2014 - 9:34

Le dithering ressort bcp plus en RVB qu'en composite, peut importe l'écran (sauf si c'est un tube tout flou lol) ..

Après pour l'aspect pixelisé, tout dépend du scaler de l'écran .

par Stef Jeu 23 Oct 2014 - 10:32

TOUKO a écrit:
C'est en effet une belle performance!
Existe t-il des jeux PCE utilisant deja ce procede?
Non hélas, comme sur toutes les machines il s'agit d'un effet trouvé par une étude poussée de la machine, ce que faisait rarement les devs consoles de l'époque .

Un peu comme les samples sur MD .

Je trouve la comparaison avec les samples du MD un peu foireuse, on a quand même eu (fort heureusement) beaucoup de jeux MD avec des samples corrects :p Il n'y a pas besoin d'une étude poussée de la machine pour comprendre ce qu'il faut faire Wink

Par contre je veux bien que tu m'explique le procédé de l'effet de transparence sur PCE si tu le connais car ça m'interesse. Est-ce que ça utilise massivement les palettes ? Ou est-ce une bidouille sur le blend des plans des 2 VDP ?

par Stef Jeu 23 Oct 2014 - 10:36

TOUKO a écrit:Le dithering ressort bcp plus en RVB qu'en composite, peut importe l'écran (sauf si c'est un tube tout flou lol) ..

Après pour l'aspect pixelisé, tout dépend du scaler de l'écran .

J'ai un LCD qui upscale plutot bien (sans trop flouter non plus) mais vraiment 256 pixels sur un écran HD de 1m de diagonale, ben tu vois les pixels quoiqu'il arrive Confused

Et je peux te dire que tu sens la différence entre le 320 et le 256 à ce niveau Wink

par Invité Jeu 23 Oct 2014 - 10:49

Je suis pas sur que tu fasses la diff sur du 256 et 320 upscalé en full HD, sauf si tu compares sur une sortie en compo et l'autre en RVB .

Par contre je veux bien que tu m'explique le procédé de l'effet de transparence sur PCE si tu le connais car ça m'interesse. Est-ce que ça utilise massivement les palettes ? Ou est-ce une bidouille sur le blend des plans des 2 VDP ?

Non je sais pas du tout comment il est arrivé à faire ça, je sais juste que l'effet est en temps réel et qu'il utilise le CPU et le VDC pour faire un effet sur les BP comme sur amiga .
Par contre ca tourne sur une simple PCE et non la SGX,donc 1 seul VDC .

Je trouve la comparaison avec les samples du MD un peu foireuse, on a quand même eu (fort heureusement) beaucoup de jeux MD avec des samples corrects :p Il n'y a pas besoin d'une étude poussée de la machine pour comprendre ce qu'il faut faire

C'est vrai que c'était pas un exemple super, mais tu en conviendras que bcp plus de jeux ont des samples pourris que le contraire, alors qu'aujourd'hui vous connaissez bien la méthode pour que ça sorte correctement, normal vu tout les topics qui ont été écrits sur le sujet Razz

.
Même sega n'a pas été foutu de sortir un sample correct sur ses gros jeux, donc si le principe était connu, il ne l'était pas pour sega,capcom et konami par contre .. Wink

par **drfloyd** Jeu 23 Oct 2014 - 10:56

pckid a écrit: Malgrè leur gros point faible, c'est la cartouche qui n'etait pas copiable, elles ont reussi à s'imposer.

non au contraire c'etait le point fort la cartouche....

Le piratage total des micro Amstrad, St, Amiga a tué le marché du jeu vidéo sur ces supports. Tous les editeurs sont vite revenus sur console.

par Stef Jeu 23 Oct 2014 - 11:09

TOUKO a écrit:Je suis pas sur que tu fasses la diff sur du 256 et 320 upscalé en full HD, sauf si tu compares sur une sortie en compo et l'autre en RVB .

Heu je te garantie que tu vois largement la différence, et j'utilise une sortie RGB (tu me prends pour qui MDR

).
En 256 les pixels sont juste encore plus gros et surtout ils ne sont plus carrés mais rectangulaire (ou tu forces le ratio et tu as de belle bandes noires sur chaque côté). Donc définitivement la différence est vraiment notable !

Non je sais pas du tout comment il est arrivé à faire ça, je sais juste que l'effet est en temps réel et qu'il utilise le CPU et le VDC pour faire un effet sur les BP comme sur amiga .
Ca tourne sur une simple PCE et non la SGX .

Ah ça tourne sur une simple PCE (avec un seul VDP) et ça utilise le CPU... mouais du coup je suis beaucoup moins convaincu sur la faisabilité in-game. Vu le nombre de pixels modifiés ça doit forcément beaucoup prendre sur le CPU :-/

C'est vrai que c'était pas un exemple super, mais tu en conviendras que bcp plus de jeux ont des samples pourris que le contraire, alors qu'aujourd'hui vous connaissez bien la méthode pour que ça sorte correctement, normal vu tout les topic qui ont été écrits sur le sujet .
Même sega n'a pas été foutu de sortir un sample correct sur ses gros jeux .

Les premiers jeux Sega comme Space Harrier 2 ou Altered Beast avaient des voix digits nickels. Et beaucoup d'autres jeux n'ont pas de problème non plus (Mega Turrican qui est bourré d'actions et donc qui doit beaucoup utiliser le DMA a des digits nickels)...
Pour les jeux Sega comme SOR franchement ça me posent pas de problèmes car les digits sont juste "des cris", pour SF2 c'était vraiment différent...

par cryodav76 Jeu 23 Oct 2014 - 11:18

drfloyd a écrit:
pckid a écrit: Malgrè leur gros point faible, c'est la cartouche qui n'etait pas copiable, elles ont reussi à s'imposer.

non au contraire c'etait le point fort la cartouche....

Le piratage total des micro Amstrad, St, Amiga a tué le marché du jeu vidéo sur ces supports. Tous les editeurs sont vite revenus sur console.

ce n'est pas le seul facteur,il y a aussi simplement l'evolution l'amstrad le st etant completement largué par les 16b et l'amiga souffrant de l'image de la guerre st/amiga encore aujourd'hui!
oui l'amiga est au niveau des console 16bit,pas le st.
ce n'est pas le piratage qui est la cause exclusive du déclin d'ailleurs suffit de voir le succes mondial de la ps1 et wii massivement piraté.

par Invité Jeu 23 Oct 2014 - 11:22

Heu je te garantie que tu vois largement la différence, et j'utilise une sortie RGB (tu me prends pour qui ).
En 256 les pixels sont juste encore plus gros et surtout ils ne sont plus carrés mais rectangulaire (ou tu forces le ratio et tu as de belle bandes noires sur chaque côté). Donc définitivement la différence est vraiment notable !

Ah oui, mais c'est normal aussi tu passes du 256 4/3 en 16/9 forcement ça déforme plus que du 320 ..
Si tu garde la ration je suis pas sur que la différence se voit .

Ah ça tourne sur une simple PCE (avec un seul VDP) et ça utilise le CPU... mouais du coup je suis beaucoup moins convaincu sur la faisabilité in-game. Vu le nombre de pixels modifiés ça doit forcément beaucoup prendre sur le CPU :-/

Je sais pas si ça prend bcp de CPU, mais cette demo à été vite faite d'après tom, pas optimisé et pas finie, donc je pense pas que ça consomme énorme en CPU,faudra que je lui demande ..

Les premiers jeux Sega comme Space Harrier 2 ou Altered Beast avaient des voix digits nickels

Oui mais ils utilisaient pas le DAC mais le PSG il me semble ..
Pour SOR moi ça me gêne quand tu te tapes plein d'ennemis à la suite, les cris te tapent sur le système,surtout quand tu joues avec un ampli .
Et si sega n'était pas foutu de faire de bonnes digits via le DAC,et ni treasure d'ailleurs qui pourtant maitrisait bien la Md (celles d'AS sont pas crad, mais limites je trouve), on pouvait pas blâmer les autres de faire de même ..

par Stef Jeu 23 Oct 2014 - 12:46

Ah oui, mais c'est normal aussi tu passes du 256 4/3 en 16/9 forcement ça déforme plus que du 320 ..
Si tu garde la ration je suis pas sur que la différence se voit .

Ah bah oui si tu gardes le ratio les pixels ont effectivement la même taille mais du coup tu te retrouves avec des super bandes noires sur le côté, dans un cas comme dans l'autre tu vois qu'il y a moins de pixels Wink

Je sais pas si ça prend bcp de CPU, mais cette demo à été vite faite d'après tom, pas optimisé et pas finie, donc je pense pas que ça consomme énorme en CPU,faudra que je lui demande ..

Ouais enfin ça reste une démo là, au début je pensais que ça utilise un trick hardware avec les 2 plans, mais maintenant que je sais que ça se joue au CPU avec les bitplans, nécessairement plus y'a de transparence affichée et plus ça doit consommer sur le CPU... alors sur un jeu léger y'a tet moyen d'en mettre un peu mais sur un jeu plus lourd ça sera difficile :-/ Et surtout ça signifie que l'effet est probablement reproduisible sur d'autres machines (comme la MD en modifiant le code) et que ce n'est pas forcément propre aux specs de la PCE.

Oui mais ils utilisaient pas le DAC mais le PSG il me semble ..
Pour SOR moi ça me gêne quand tu te tapes plein d'ennemis à la suite, les cris te tapent sur le système,surtout quand tu joues avec un ampli .
Et si sega n'était pas foutu de faire de bonnes digits via le DAC,et ni treasure d'ailleurs qui pourtant maitrisait bien la Md (celles d'AS sont pas crad, mais limites je trouve), on pouvait pas blâmer les autres de faire de même ..

Qu'ils utilisent le PSG (Space Harrier 2 uniquement) ou pas ça ne change rien au problème du DMA.
Après oui il fallait fournir plus d'efforts sur MD pour avoir des voix claires, ça c'est une réalité, après y'a des jeux où effectivement ce n'était pas bien grave mais d'autres (on revient encore à SF2) où vraiment les développeurs auraient du y passer un peu plus de temps (c'est pas comme si j'y avais passé 6 mois pour corriger le problème :p ).
On peut aussi effectivement blamer Sega de ne pas avoir fourni un driver gérant le problème de base (je comprends que les premiers drivers ne soient pas totalement au point mais au moins en milieu de vie de la machine ça n'aurait pas été du luxe Wink

)

par **leZone** Jeu 23 Oct 2014 - 13:32

pckid a écrit:L'amiga 500 ne possède qu'un bouton pour le tire et le saut c'est une galère,

pas d'accord
tu as 2 boutons
tu pouvais même utiliser un paddle de megadrive dessus, car c'est une prise standard au format atari d sub 9 (et d'autres joysticks, crayon optique, souris ...)

mais très peu de jeux utilisaient les 2 boutons, et certains utilisent aussi le clavier en plus du joystick!
à l'époque on jouait avec des joysticks et pas des paddles, et le saut se faisait avec le joystick vers le haut, c'était l'usage habituel depuis des années et ça venait principalement du monde de l'arcade
ce n'est qu'avec les consoles et leurs paddles qui bousillaient les pouces, que le saut est passé sur un bouton à part

et pour finir, une liste des jeux 2 boutons sur Amiga : http://eab.abime.net/showthread.php?t=57540

par Invité Jeu 23 Oct 2014 - 13:39

Ah bah oui si tu gardes le ratio les pixels ont effectivement la même taille mais du coup tu te retrouves avec des super bandes noires sur le côté, dans un cas comme dans l'autre tu vois qu'il y a moins de pixels

Oui même si je suis d'accord que les bandes c'est merdique,mais le résultat ne doit pas être trop différent .

Ouais enfin ça reste une démo là, au début je pensais que ça utilise un trick hardware avec les 2 plans, mais maintenant que je sais que ça se joue au CPU avec les bitplans, nécessairement plus y'a de transparence affichée et plus ça doit consommer sur le CPU... alors sur un jeu léger y'a tet moyen d'en mettre un peu mais sur un jeu plus lourd ça sera difficile :-/ Et surtout ça signifie que l'effet est probablement reproduisible sur d'autres machines (comme la MD en modifiant le code) et que ce n'est pas forcément propre aux specs de la PCE.

Je lui ai demandé pour voir le CPU que ça prend .
Et non c'est pas faisable sur Md puisqu'on joue sur les BP est la Md n'a pas ce type d'affichage .
Ca serrait peut être faisable, mais surement plus compliqué et encore plus consommateur en CPU.

Après comme je te dis, je connais que les grandes lignes sur la technique employée, je verrai si tom m'en dis un peu plus sur le procédé .

On peut aussi effectivement blamer Sega de ne pas avoir fourni un driver gérant le problème de base (je comprends que les premiers drivers ne soient pas totalement au point mais au moins en milieu de vie de la machine ça n'aurait pas été du luxe )

C'est surtout qu'en tant que constructeur/dev tu es quand même l'ambassadeur de ton hardware, faire des digits pourris peut être interprété comme un aveu de faiblesse de la console .

stef:Je zieutais la doc MD au sujet du DMA, comment tu fais pour savoir quand le DMA est fini ??
Il semble qu'elle génère pas d'interruption lorsque c'est fait !!

par Stef Jeu 23 Oct 2014 - 15:03

Je lui ai demandé pour voir le CPU que ça prend .
Et non c'est pas faisable sur Md puisqu'on joue sur les BP est la Md n'a pas ce type d'affichage .
Ca serrait peut être faisable, mais surement plus compliqué et encore plus consommateur en CPU.

Après comme je te dis, je connais que les grandes lignes sur la technique employée, je verrai si tom m'en dis un peu plus sur le procédé .

Oui si tu as des infos dessus ça m'interesse aussi...j'ai quand même des doutes sur le fait que l'effet joue uniquement sur les bitplan, après tout tu es limité à 16 couleurs par bloc de 8x8. Si encore à la base il avait pris des plans en 4 couleurs là effectivement avec une astuce assez simple tu y arrives mais puisqu'il a utilisé les graphismes de TF4 je pense qu'il y a bien les 16 couleurs de base et là du coup ça me semble plus tricky pour y arriver.

stef:Je zieutais la doc MD au sujet du DMA, comment tu fais pour savoir quand le DMA est fini ??
Il semble qu'elle génère pas d'interruption lorsque c'est fait !!

C'est logique qu'il n'y ai pas d'interruption car de toute manière le 68000 est à l'arrêt pendant un DMA qui nécessite le BUS, pour les autre DMA (internes au VDP) tu as un flag qui t'indique si le DMA est terminé ou pas. Sinon pour le Z80, tu pourrais très bien l'indiquer à partir du 68000 en écrivant une valeur dans la mémoire du Z80 mais pour m'éviter ça j'évite simplement d'accéder au BUS du 68000 pendant tout le vblank (normalement tout les DMA se font durant le vblank). Si tu as un jeu mal programmé qui fait un DMA en dehors du vblank alors ça va foirer avec mon driver, mais franchement je me préoccupe pas de ce genre de cas :p