GUERRE ST-AMIGA, FIGHT !!!

rocky007 a écrit:

babsimov a écrit:
Bref, après les explications en détails sur les défauts hardware et logiciels du ST, il faut quand même être un beau fanboy pour ne pas admettre que le ST était très très loin d'être la machine "parfaite et sans défaut" que tu prétendais au début.

on n'a jamais prétendu que le ST était parfait, juste le meilleur ordinateur 16 bits en 1985-88

Mais, non il ne l'était pas justement. L'Amiga était bien là.

Ce que tu ne comprends pas, c'est que vous expliquez que le Blitter était prévu dès l'origine dans les ST mais que, pour une raison de temps, probablement, il n'a pas pu être intégré. Ca veut dire que dès le départ son architecture n'était pas adaptée à un blitter. 

le blitter sert à faire des certaines opérations plus rapidement que le 68000.  c'est ce qu'il fait dans le ST, en // ou non.  en // c'est mieux, mais le fait qu'il ne le soit pas n'est pas une preuve de mauvaise intégration.

Ben non, c'est sur que c'est pas une preuve de mauvaise intégration ! Un coprocesseur qui est sensé justement aider le processeur pendant que celui ci fait autre chose, sur le ST il le fait pas, pire il bloque le processeur (qui du coup ne peut rien faire d'autre). C'est VRAIMENT ce qu'on appel une mauvaise intégration. Surtout si c'était un coprocesseur soit disant voulu dès le départ. Surtout que j'ai bien lu, il y a quelques pages qu'il y avait une solution qui aurait pu éviter ce blocage, mais qu'ils ne l'ont pas choisit !

Tu auras beau tourner la question dans tous les sens, l'intégration du blitter dans le ST est un ratage.

Les pressions etc... un excellent ingénieur sait dire non aux pressions et faire ce qui doit être fait. Chuck Peddle et Jay Miner on su faire ça. Ils sont partit quand la direction n'a pas voulu les écouter et ont fondé leur boite pour pouvoir travailler comme ils l'entendaient.

et à doigt deux l'amiga n'aurait jamais existé pour cause de faillite d'amiga... l'amiga existe uniquement grâce à la chance...et commodore

Même si l'Amiga n'avait pas existé, le prototype montre bien que Jay Miner était un bien meilleur ingénieur. Toute l'architecture est pensée avec élégance.

Désolé, mais, je doute qu'il ait les mêmes capacités d'innovation que Jay Miner. Parce que Jay Miner en a fait preuve pendant toute sa carrière. Il y a une marge énorme entre eux je trouve.

je rencontre souvent des génies de l'informatique, des as de la programmation ou de l'éléctronique, mais qui pourtant reste dans l'ombre faute d'un environnement adéquat.  heureusement internet et la forum, youtube et kickstarter et co on changé un peu la donne.
en fait j'en ai rien à foutre de défendre un plutôt que l'autre, ce n'est pas du tout parce qu'il est la papa de l'atari, je dis juste que sans le connaître personnellement, tu ne sais pas s'il n'avait pas le génie nécessaire pour créer qq chose de mieux que l'amiga.

Disons juste que vu le nombre de "défauts" de conception qu'il a placé dans le ST, le niveau de son interview, j'ai quand même des doutes. Mais, on ne sait pas, peut être qu'il avait l'idée d'un super ordinateur dans sa tête, mais qu'il n'a pas eu l'occasion de le réaliser... En tout cas, avec les années de recul, il a pas fait beaucoup parler de lui.

Mais, je pense qu'on a fait le tour au sujet de cette série et qu'il est inutile de revenir la dessus. C'est une bonne série, mais qui n'a rien de crédible pour ce qui concerne les machines de l'époque (hormis de montrer les modèles à peu près au moment de leur sortie). Comme caution "historique".

tu as raison, le troll a suffisamment duré

Nous sommes d'accord.

Les versions disquettes étaient même parfois dans le circuit avant la mise en vente de l'original. Alors, oui une années complète avant qu'il puisse y avoir un début de marché parallèle (mais moindre au début que du côté des disquettes), c'est beaucoup. Surtout qu'il faut modifier physiquement sa console (plus de garantie).

pas avec l'action replay

Je connais pas l'action replay pour playstation, elle se branchait comment ?

Oui, normal, car en 1995 c'est encore pas trop abordable un graveur et seule une minorité en aura. Le support CDR coûte aussi très cher. Il n'est pas rentable de copier avant un certain temps.

le CDR au début coutait +-50 FF.. c'était toujours moins que le 300-400FF d'un jeu

Dans mon souvenir les jeux, à l'époque, c'était plus 150 à 200 frs, voir 250 fr pour les gros jeux.

Il était neuf ce modem, il venait de l'acheter avec un pilote Windows 95 sur la disquette d'installation. Mais, pour Windows 95 il n'arrivait pas à dialoguer avec le modem, qu'il ne voyait soit pas du tout, soit comme un modem 9600 bauds, soit comme une autre marque et finalement dialoguait avec lui, mais disait que ce n'était pas de cette marque. On a pensé à tout, le cable, pleins de paramètres. Y avait toujours un truc qui passait pas, alors qu'il y avait le manuel d'installation et la disquette fournie pour Windows 95. 
Tu comprends bien que passé une heure du matin, après 4 heures le voir galérer avec le PC, j'en ai eu marre. En 5 minutes le même modem a été connecté à sa vitesse maximale (56k) sur internet, en utilisant l'Amiga. Et là le PCiste a pu faire ce qu'il avait à faire sur internet.

 si c'est un modem qui nécessite des drivers, c'est qu'il était en carte, tu n'aurais donc pas pu le connecteur sur un Amiga.  Donc si tu l'a connecté sur l'amiga, c'est que c'était un modem externe via port série.  Hors le port série du PC était forcément déjà configuré avec le bon driver ( ou alors ton pote n'avais jamais correctement installé son PC ), il n'y avait pas besoin de driver pour un modem série.

C'était bien un modem externe et il avait un pilote qui était demandé par Windows 95. Tu n'étais pas là ce soir là. Tu vas me dire que tu sais mieux que moi ?
Je t'assures que je pensais pas non plus que ça lui prendrait autant de temps pour ne pas arriver à connecter le modem à Internet, alors que dès le début je lui avais proposé d'utiliser l'Amiga (pour lui éviter de déplacer son PC). Mais, il voulait absolument le faire avec son PC. Contrairement à ce que tu penses, il savait installer un PC, il n'avait connu que le PC depuis des années.
Bref, au final le modem a fonctionné du premier coup sur l'Amiga.
C'est surement ma faute ?

C'est dingue, vous vous lassez pas? :)

rocky007 a écrit:


ah oui le scrolling 1 pixel, tu veux quoi de plus ? un scrolling 0,5 pixel ?
16 couleurs, moi j'en vois bien plus...ton moniteur grésille aussi au niveau des couleurs ?

pour WOD on compare pas avec les shoot amiga à ce que je sache, tu es encore à coté de la plaque...si tu veux on compare ton project X avec le shoot sur falcon

Fais pas genre t'as rien capté, Mr Motorolière :)

Le scroll hard de ce jeu est lent et pas au niveau de celui de l'amiga. Oui le scroll est en 1 pixel, mais sa vitesse est loin d'estomaquer. C'est la qu'on voit que le STE il mange le caca des autres 

Si si WOD on peut comparer avec Project-X. WOD n'exploite absolument pas l'Amiga, c'est une émulation du jeu ST avec en plus la musique d'intro dont le driver musical est buggé (il aura fallu 2016 pour que ça soit corrigé ! Abusé ! :/). 

Je compare pas un simple jeu A500 avec un jeu pour Falcon surgonflé, faut arrêter de raconter des aneries un peu, ça nous changera 

rocky007 a écrit:

Zarnal a écrit:200 sprites à 2-3 fps

Ou bien ils parlent des étapes d'animation(s) ?

ben je suppose puisqu'ils parlent de perfs , c'est le nombre de sprite simultané, et non le total de sprites dans le jeu.
( ce qui a peu d'importance puisque cela n'a aucun exploit d'avoir 5000 sprites sur 20 disquettes )

C'est le nombre de sprites différents dans tout le jeu. Le jour ou un ST arrivera à faire ça, c'est qu'il aura un accélérateur avec un 68040 au cul voir carrément un sérieux add-on graphique.

Seb a écrit:C'est dingue, vous vous lassez pas? :)

De prendre du bon temps ? Ah non jamais, et toi ? 

rocky007 a écrit:le record de sprites CPU sur ST en 16x16 est + de 300, en 50 FPS.  je ne vois donc pas pourquoi cela ne pourrait pas être possible 200 à 3 FPS ou finalement tout le cpu est presque libre puisque le scrolling est hardware, que blitter aide les sprites, et que pour les tirs, on est sur probablement du 4x4

Balance un nom, j'adorerais voir ça de mes yeux. Dans 96% des jeux ST, dès que t'as 5 sprites à l'écran, ça ralenti tellement que ça donne l'impression que la machine est en train de mourir...........

rocky007 a écrit:http://leonard.oxg.free.fr/record16/record16.html

oui elle a l'impression de mourir quand le scroll est fait au CPU, ici ce n'est pas le cas

Ohhhhh des vectorballs Ou pas.

le record de sprites CPU sur ST en 16x16 est + de 300, en 50 FPS.  je ne vois donc pas pourquoi cela ne pourrait pas être possible 200 à 3 FPS ou finalement tout le cpu est presque libre puisque le scrolling est hardware, que blitter aide les sprites, et que pour les tirs, on est sur probablement du 4x4

Au hasard, parce qu'il y a aussi toute la logique du jeu à faire tourner, la map à mettre à jour, les tests de collisions, parce que les sprites ne sont pas tous identiques, en 3 couleurs et en 16x16 pixels comme les simples bobs dans la démo ??, tu vois tout les trucs qu'il faut pour faire un jeu quoi !! 

TOUKO a écrit:

le record de sprites CPU sur ST en 16x16 est + de 300, en 50 FPS.  je ne vois donc pas pourquoi cela ne pourrait pas être possible 200 à 3 FPS ou finalement tout le cpu est presque libre puisque le scrolling est hardware, que blitter aide les sprites, et que pour les tirs, on est sur probablement du 4x4

Au hasard, parce qu'il y a aussi toute la logique du jeu à faire tourner, la map à mettre à jour, les tests de collisions, parce que les sprites ne sont pas tous identiques, en 3 couleurs et en 16x16 pixels comme de simples bobs dans la démo ??, tu vois tout les trucs qu'il faut pour faire un jeu quoi !! 

Comme par exemple ce jeu qui ne dispose que de 100 sprites/blobs lui le pauvre...



16 couleurs comme WOD et LXC

ah je croyais que c'était le joystick qui faisait ça

Bah non sur une console c'est le joypad .

Meditating Guru a écrit:

stapha92 a écrit:Je reviens sur la documentation Atari. Voici un extrait d'une doc sur le blitter rédigée par des expert du ST :

      If an interrupt service however cannot be completed in 64 cycles
      and should not be stalled by the BLiTTER again, Atari states that
      it is possible to "stall" the BLiTTER by writing Bit 7 to zero -
      But Atari points out in the official documentation that it needs
      to be set to the original state before end-of-interrupt is reached:
      
        move.b  $FFFF8A3C.w,-(sp)     ; Write register to stack
        bclr.b  #7,$FFFF8A3C.w        ; unset busy bit
        nop                           ; BLiTTER might interfere here
        
       
        
        move.b (sp)+,$FFFF8A3C.w      ; restore original register
        
      Unfortunately, this does not work at all and is not mentioned in
      other documentation regarding the BLiTTER i have read so far.
      This seems to origin from the internal state handling. The CPU
      reads a "1" in the BLiT-busy bit when reading out the register,
      even though internally it is a "0" because the BLiTTER is pausing
      for 64 cycles. Writing through a "0" will not have any effect and
      not stop the internal state handler to set it back to "1" internally
      after 64 cycles. The BLiTTER will only write a "0" if it is done
      copying data (i.e. the line counter turns "0"). There does not seem
      to be any other way of stalling the BLiTTER on request.

Donc on nous explique que la méthode donnée par Atari pour arrêter le blitter dans le cas ou on veut s'assurer que le traitement d'une interruption parviendra à aller jusqu'au bout ne marche pas ! Pire, il s'avère qu'il est impossible d’empêcher le blitter de repartir ! 

Un stagiaire aurait fait mieux je vous dit !

Après ça, ces expert donnent une autre façon de faire qui, elle, fonctionne totalement et est plus efficace (surtout dans le cas de petites lignes).  C'est celle qui a été raillée par Guru (c'est dans cette doc que je l'avais lu). En ce moquant de moi, il a raillé le travail d'un groupe ST qui a fait du super boulot... 

A part ça le ST était un ordinateur pro et était préféré pour le développement ...

Je me moquais plus de ton idée "4 cycles pour le blitter, 1 cycle pour le CPU".
Il convient de recouper ce que dit cet "expert". A première vue, si ce qu'il dit est correct, il me semble possible de pauser le blitter en changeant le compteur de lignes (mais n'est-ce pas ce qu'il dit aussi?).
Ce serait donc un autre problème de doc, à vérifier. Pas étonnant, à l'époque du STE, je serais le premier à le reconnaître, Atari avait baissé (sans atteindre le niveau de Commodore).

Ca m'embête de contredire une nouvelle fois le dieu vivant des fanboys Amiga, mais suivant mon propre conseil, j'ai recoupé ce que dit cet expert (un bon demomaker).
D'abord, voici la doc Atari:

Code:

     *
     * (Interrupt service routines may explicitly halt the BLiTTER
     * during execution time critical sections by clearing the BUSY flag.
     * The original BUSY flag state must be restored however, before
     * termination of the interrupt service routine.)

Une routine d'interruption peut pauser le blitter en mettant le bit BUSY à 0.
L'expert prétend que ça ne marche pas.

Voici une routine "timer B" de Lethal Xcess avec mon commentaire:

Code:

(PC 014D8C sur STE 4MB)
 move.w $8a3c.W,$612.w                            ; sauver registre blitter
 clr.w $8a3c.W                                    ; mettre à zero pour stopper 
 movem.l D0-7/A0,-(a7)                            ; vu que la routine est longue
 movea.l $-17672(pc),a0 {$010894}                 ; (conformément doc Atari)
 movem.l (a0),D0-7                                ; 
 lea $8209.w,a0                                   ; 
 clr.w d7                                         ; 
 move.b (a0),d7                                   ; 
 sub.b (a0),d7                                    ; 
 bne.s -6 {$014DA8}                               ; attendre fin affichage ligne
 movem.l D0-7,$8242.W                             ; changer palettes pour ligne suivante
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 clr.b $fa1b.W                                    ; programmation timer B suivant
 move.b #$9,$fa21.w                               ;  
 move.b #$8,$fa1b.w                               ; 
 move.l $-504(pc),$120.w {$014BDE}                ; 
 movem.l (a7)+,D0-7/A0                            ; 
 move.w $612.W,$8a3c.w                            ; restaurer registre blitter
 rte                                              ;

Autrement dit, cette routine fait EXACTEMENT ce qui est préconisé par Atari, et visiblement ça marche.
Donc SVP attendez un peu avant de critiquer les ingénieurs Atari.

Une routine d'interruption peut pauser le blitter en mettant le bit BUSY à 0.
L'expert prétend que ça ne marche pas.

Et comment tu fais ça puisque pendant le blit ton CPU est bloqué !!

Autrement dit, cette routine fait EXACTEMENT ce qui est préconisé par Atari, et visiblement ça marche.
Donc SVP attendez un peu avant de critiquer les ingénieurs Atari. 

 
Mais tu as vu une peu le nombre de cycles que tu gaspilles dans ta routine, plus les 64 de l'interruption .
Et tu fais quoi si en plus tu utilises le DMA son du STE ??
et puis même question que plus haut, comment le CPU prend l'interruption si il est bloqué par le blitter ??
Donc pour moi l'expert a raison,tu ne peux pas interrompre le blitter via une interruption car le CPU est locké .
A mon avis, ça doit marche que pendant le hblank, où le blitter est inopérant,et le CPU peut prendre la main, mais pas pendant l'affichage. .

None, but each has its own advantages and disadvantages.
In "hog"-mode, the BLiTTER will not waste cycles reserving the bus
(up to 7 cycles) and therefore run as quickly as possible. Using the
timing table quoted in the first chapter it is possible to calculate
the time after which the BLiTTER will release the bus again. However,
during this time, the CPU will not have any access to the bus, not
even for highly critical interrupts, potentially making it miss
some interrupts that occured.

In "blit"-mode the CPU will gain access after 64 cycles for 64
cycles, but the BLiTTER will have to reserve the bus afterwards and
therefore delay its copying by up to 7 cycles per turn. Nevertheless,
the CPU will have a chance of reacting to interrupts with a delay of
64 cycles but the interrupt service routine should finish in less
than 64 cycles, otherwise it is potentially stalled by the BLiTTER
again.

Faut pas se louper quoi !!
L'instruction en cours ne doit pas prendre plus de 20 cycles.

D'abord, voici la doc Atari:

Y'a moyen d'avoir la doc complète sur le blitter ??

TOUKO a écrit:

Une routine d'interruption peut pauser le blitter en mettant le bit BUSY à 0.
L'expert prétend que ça ne marche pas.

Et comment tu fais ça puisque pendant le blit ton CPU est bloqué !!

Autrement dit, cette routine fait EXACTEMENT ce qui est préconisé par Atari, et visiblement ça marche.
Donc SVP attendez un peu avant de critiquer les ingénieurs Atari. 

 
Mais tu as vu une peu le nombre de cycles que tu gaspilles dans ta routine, plus les 64 de l'interruption .
Et tu fais quoi si en plus tu utilises le DMA son du STE ??
et puis même question que plus haut, comment le CPU prend l'interruption si il est bloqué par le blitter ??
Donc pour moi l'expert a raison,tu ne peux pas interrompre le blitter via une interruption car le CPU est locké .
A mon avis, ça doit marche que pendant le hblank, où le blitter est inopérant,et le CPU peut prendre la main, mais pas pendant l'affichage. .

D'abord, voici la doc Atari:

Y'a moyen d'avoir la doc complète sur le blitter ??

Tu réagis trop vite. Prend le temps de lire. C'est une routine de Lethal Xcess, je ne l'ai pas inventée. Bien sûr, ça marche. Le blitter est en mode blit, donc le CPU a la main la moitié du temps, c'est à ce moment qu'il bloque le blitter le temps de l'interruption.


http://www.atari-wiki.com/?title=Blitter_manual

Faut pas se louper quoi !!
L'instruction en cours ne doit pas prendre plus de 20 cycles.

Il faut faire x4, l'expert oubliait de le dire, c'est pourquoi je parlais de 256 cycles.

Tu réagis trop vite. Prend le temps de lire. C'est une routine de Lethal Xcess, je ne l'ai pas inventée. Bien sûr, ça marche. Le blitter est en mode blit, donc le CPU a la main la moitié du temps, c'est à ce moment qu'il bloque le blitter le temps de l'interruption.

Nan mais sérieux, je vais être méchant ,mais je me demande si tu te rends compte de ce que tu dis ??
Ok le CPU prend la main la moitié du temps, mais il fait comment si une interruption claque pendant l'autre moitié où il n'a pas la main ??

Ah oui, il va interrompre le blitter via une interruption  .
enfin bref quoi !!

je cite encore la doc de paradox sur le blitter atari:

If an interrupt service however cannot be completed in 64 cycles
and should not be stalled by the BLiTTER again, Atari states that
it is possible to "stall" the BLiTTER by writing Bit 7 to zero -
But Atari points out in the official documentation that it needs
to be set to the original state before end-of-interrupt is reached:

move.b $FFFF8A3C.w,-(sp) ; Write register to stack
bclr.b #7,$FFFF8A3C.w ; unset busy bit
nop ; BLiTTER might interfere here



move.b (sp)+,$FFFF8A3C.w ; restore original register

Unfortunately, this does not work at all and is not mentioned in
other documentation regarding the BLiTTER i have read so far.
This seems to origin from the internal state handling. The CPU
reads a "1" in the BLiT-busy bit when reading out the register,
even though internally it is a "0" because the BLiTTER is pausing
for 64 cycles. Writing through a "0" will not have any effect and
not stop the internal state handler to set it back to "1" internally
after 64 cycles. The BLiTTER will only write a "0" if it is done
copying data (i.e. the line counter turns "0"). There does not seem
to be any other way of stalling the BLiTTER on request.

Sur une autre doc:

Bit 6  -  Blit-Mode Register
              Decides wether to copy in BLIT Mode (0) or in
              HOG Mode (1). In Blit Mode (also known as cooperative),
              CPU and Blitter get 64 clockcycles in turns, in Hog
              Mode, the Blitter reserves and hogs the bus for as long
              as the copy takes, CPU and DMA get no Bus access.

Donc en mode blit, les 2 ont chacun la main tout les 64 cycles,et non 256.
Etant donné que la prise d'interruption fait 44 cycles, plus les cycles de l'instruction en cours+les cycles pour arrêter le blitter,ça devient chaud patate qd même .
Et j'imagine même pas avec le STE et le son DMA .

La doc de Paradox ne fait pas autorité, je viens de le prouver.

L'interruption doit attendre que le CPU ait repris la main. C'est le but du mode blit.

Il faut faire x4, ne l'ai-je pas mentionné?
Pour s'en rendre compte, il faut lire la doc Atari attentivement. 7 cycles bus, ça veut dire 28, c'est le temps pris par les instructions de l'exemple pour relancer le blitter. 64 cycles, comme tu l'as remarqué toi-même, ce serait ridicule.
La confusion vient du fait qu'ils parlent de "bus cycle", pas "CPU cycle".

Et tout ça marche parfaitement sur Lethal Xcess, qui utilise aussi le son DMA.

Car comme on l'a déjà expliqué maintes fois, le blitter ne prendra jamais un cycle DMA sur le STE, ce n'est pas comme l'Amiga.

Meditating Guru a écrit:

Ca m'embête de contredire une nouvelle fois le dieu vivant des fanboys Amiga, mais suivant mon propre conseil, j'ai recoupé ce que dit cet expert (un bon demomaker).
D'abord, voici la doc Atari:

C'est rocky ton expert ?

je connaissais pas ce jeu





une cuillere a soupe de SotB, une cuillere a soupe d'ivanhoe

la version ST est pas dégueu je trouve.

Clair la version ST s'en tire bien

rocky007 a écrit:http://leonard.oxg.free.fr/record16/record16.html

oui elle a l'impression de mourir quand le scroll est fait au CPU, ici ce n'est pas le cas

Dave, franchement, avec tout le respect du à Leonard (qui est un des meilleurs codeurs du ST), ton exemple est clairement biaisé.

Tu nous balance une démo alors qu'on parle d'un jeu avec du scrolling, une IA, de vrais sprites d'une certaine taille et ainsi de suite. 

Mega Typhoon présenté par Zarnax est un vrai jeu, c'est le petit raiden de l'Amiga (dans le principe). 

Et les sprites sont dignes de ceux d'une machine d'arcade :) Le tout en 50 images secondes.

tu ne connaissais pas warth of the demon! un classic  et c'est vrai pour du st c'est vraiment bien je dirai 18/20,sur amiga c'est juste pas mal 14/20( c'est au dessus de la version st quand meme)

Y a eu un certain travail de fait, et c'est certain par Ulrich Doewich, le mec qui a porté le jeu sur CPC (note: c'était avant tout un programmeur CPC bien traps).

La doc de Paradox ne fait pas autorité, je viens de le prouver.

Tu n'as rien prouvé, tu te bases sur la doc d'atari, paradox aussi, mais juste que ce qu'atari dit, dans les faits ça marche pas .
Et même si ça marche, 64 cycles pour prendre une interruption et arrêter le blitter c'est bcp trop limite pour le 68k,et c'est sur que tu vas en rater .

L'interruption doit attendre que le CPU ait repris la main

Oui elle reste active tant que le CPU ne l'a pas acquittée, mais tu es au courant que pour jouer un sample par exemple, il faut envoyer les données de façon continue sans quoi la qualité devient dégradée .
Le scrolling par exemple sur le STE, si tu peux changer le scroll mid scanline, rater le bon moment peut être une cata,et je parle même pas du code timé qui est impossible à faire .
Et sur ST ou les timing CPU sont la base pour faire quelque chose de potable, c'est même pas la peine .

Et tout ça marche parfaitement sur Lethal Xcess, qui utilise aussi le son DMA.

Je te dis pas que sur STE c'est impossible, juste que c'est impossible d'utiliser le hardware au max dans ces conditions,je vois rien d'extraordinaire dans la version STE,à part une utilisation basique du scrolling hard, et du son DMA(même pas au niveau de l'amiga en plus) .
La preuve ce jeu est une plaisanterie pour les joueurs amiga face aux gros shoot de la machine,jeu sympa mais sans plus .

Car comme on l'a déjà expliqué maintes fois, le blitter ne prendra jamais un cycle DMA sur le STE, ce n'est pas comme l'Amiga.

Voilà, c'est la différence entre une archi pensée autour d'un chipset, et le bricolage du STE .

dlfrsilver a écrit:

rocky007 a écrit:http://leonard.oxg.free.fr/record16/record16.html

oui elle a l'impression de mourir quand le scroll est fait au CPU, ici ce n'est pas le cas

Dave, franchement, avec tout le respect du à Leonard (qui est un des meilleurs codeurs du ST), ton exemple est clairement biaisé.

Tu nous balance une démo alors qu'on parle d'un jeu avec du scrolling, une IA, de vrais sprites d'une certaine taille et ainsi de suite. 

Mega Typhoon présenté par Zarnax est un vrai jeu, c'est le petit raiden de l'Amiga (dans le principe). 

Et les sprites sont dignes de ceux d'une machine d'arcade :) Le tout en 50 images secondes.

Je suis toujours en train de me demander si on aurait pu le passer en 32 couleurs et encore l'améliorer sur une version native 1200.

Zarnal a écrit:

dlfrsilver a écrit:

rocky007 a écrit:http://leonard.oxg.free.fr/record16/record16.html

oui elle a l'impression de mourir quand le scroll est fait au CPU, ici ce n'est pas le cas

Dave, franchement, avec tout le respect du à Leonard (qui est un des meilleurs codeurs du ST), ton exemple est clairement biaisé.

Tu nous balance une démo alors qu'on parle d'un jeu avec du scrolling, une IA, de vrais sprites d'une certaine taille et ainsi de suite. 

Mega Typhoon présenté par Zarnax est un vrai jeu, c'est le petit raiden de l'Amiga (dans le principe). 

Et les sprites sont dignes de ceux d'une machine d'arcade :) Le tout en 50 images secondes.

Je suis toujours en train de me demander si on aurait pu le passer en 32 couleurs et encore l'améliorer sur une version native 1200.

on perdrai en vitesse mais comme il est trop rapide
ou alors utiliser le moteur et mieux choisir les couleurs
qu'es que pourrai donné ce moteur sur a1200+ juste un peu de fast?
je le trouve deja super impressionnant pour un jeu qui tourne sur du matos de 85
ce moteur ,celui de mr nutz dans une moindre mesure, les rotations déformation zoom de brian the lion
ça pourrait donné quelques chose de génial

celui de mr nutz

Tu as aussi un sacré effet de zoom sur les boss tout en ayant un scrolling multidirectionnel sur 2 plans, et à 50fps .