Re: GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée)

[touko]

ah ben alors ? on retourne sa veste humide ? 1990 ce n'est déjà plus le boom du full sample inventé par Amiga ?

Arrêtes avec tes pirouettes à 2 balles, tes contradictions ne font rire que toi mon pauvre .
Le pire c'est que tu te rends compte que tes propos sont à l'ouest et que tu réinventes le softsynth, qui n'est autre qu'un "sample" généré au CPU, mais reste un sample .
Je te l'ai dit 50 fois, c'est pas parce que tu rajoutes 580 smiley stupides que tu en es plus crédible .

ok donc le YM2149 est selon toi full PCM....merci de ta confirmation

Bon écoute je perds plus mon temps avec toi, tu es décidément trop con .

[stapha92]

Accélération matériel avec un CPU 8 bits pas du tout fait pour ça...

C'est aussi (surtout) à cause de la lenteur des opérations de décalage sur un 68000 que le Blitter de l'Amiga est intéressant car lui ne prend pas plus de temps pour décaler ses sources A & B

Je dis pas que le blitter n'est pas interessant sur un Amiga à 7,09 mhz  .  Par contre, plutot de se casser le cul à concevoir un blitter  et d'engager des couts la dedans  ... pour au final avoir une puce specifique ne pouvant tourner qu'a une certaine fréquence.  Et qu'il faudra redesigner pour la faire evoluer. 

il aurait peut etre été plus judicieux de concevoir directement l'Amiga avec un 68000 à 16mhz .    Ou de mettre un second processeur .    Mais bon pour ca, il aurait fallu avoir l'intention de faire un Micro  qui pourrait evoluer ... pas une console avec un hardware one shot.

Ah bon ? Un 68000 2 fois plus rapide aurait meilleur ? Ben non : un 68020 4 fois plus rapide ne l'est pas.

Je crois que tu inverses mon brave Youki. Parce qu'en terme d'évolution cpu, c'est le ST qui a de gros problèmes :
- Pour tourner à 16 Mhz, les megaSTE sont équipé d'une mémoire cache de 16 Ko qui permet de récupérer une partie des cycles inutilisables par le CPU car "collés".
- Pour aller au delà, il a fallu reconcevoir une machine (le TT) en copiant le principe de fast ram de l'Amiga. Dommage que ça n'est pas été fait dès le début car il faut un os et des programmes programmes prévus pour si on veut en tirer parti...

Même au niveau de l'OS, les évolutions posent problèmes :
- Utilisation de la line A. Interdite par Motorola car incompatible avec les futurs évolutions du cpu.
- incompatibilité 32 bits. Dommage : tous les cpu après le 68000 le sont...
- "Tricherie" sur le calcul de l'adresse lors des accès aux registres. Le 68030 du Falcon est obligé d'initialiser sa MMU pour corriger ça...

Je pourrais continuer mais ça suffit car l'Amiga n'a aucun de ces problèmes car lui est prévu pour évoluer. Colle un cpu hyper rapide dans un A500 et tu peux jouer à Quake...

Et tous les amiga ont un ou plusieurs ports permettant d'upgrader le cpu ou autres. Et le ST a un port cartouche...

Lequel est le one shot ?

Edit : tu l'as peut-être oublié, mais les Amiga avec plusieurs cpu ont existé avec des cartes PowerPC + 680x0. La beauté de l'OS, c'est que pleins de programmes non prévus en tiraient parti. Surtout pour la FPU puisque l'OS propose des librairies pour ça...

[stapha92]

Euh... Oui : 1 68000 + 1 blitter est bien plus rapide que 2 68000. Y a pas photo...

En plus le FM7 a un affichage par bitplans. Ce qui oblige le cpu à faire des décalages avec retenues et assemblages. Donc ça n'arrive pas à la cheville d'un blitter. Mais alors pas du tout...
D'ou le Space Harrier ou tout les objets sont alignés sur des multiples de 8 pixels. Faut dire qu'un STiste le verra pas : eux sont habitués au multiples de 16 pixels...

En plus le FM7, c'est 2 6809 à 2Mhz qui, à eux deux, sont plus lent qu'un 68000...
ça continue à être ridicule ce topic...


blablalblalazaaaaaaaaa

ce qui est ridicule ce sont les gens comme toi qui répondes à des propos qu'ils inventent, juste pour le plaisir d'étaler leur science. 
Qui a dit ici que le FM7 était avec son 6809 était plus puissant qu'un Amiga ?  Qui a dit que l'animation 4096 couleurs était super fluide ?  tu aimes juste venir comme un poil de bite dans la soupe...Apprends à lire, prend tes cachets pour l'hyperactivité, et va refaire le monde en MP avec babsinov ..
tu peux aussi participer, mais alors prend la peine de lire

Ce qui est ridicule c'est de ramener le FM7 dans ce débat (en nous faisant croire que c'est une bonne machine)...
Ce qui est ridicule, c'est d'affirmer que 2 68000 c'est mieux qu'un 68000+blitter en sortant des concepts qui veulent rien dire...
Ce qui est ridicule, c'est de se prendre la tête avec tout le monde tout le temps, y compris des STistes.

Toi qui nous traite de platistes régulièrement, tu te dis quoi en ce moment ? Qu'on a tous tort (Y compris le Guardian quand il parle de l'influence de Paula sur la musique des années 90) et que toi tu as raison ? C'est pas le comportement d'un platiste ça ?

Sinon, j'ai pris la peine de te lire. Toi tu devrais te relire par contre...

[rocky007]

Bon écoute je perds plus mon temps avec toi, tu es décidément trop con .

Ah tu vois , dès que tu parles insultes , tout de suite ton message est plus consistant , la on voit la maîtrise du sujet

[touko]

@youki: Un 68000 @16mhz tu aurais juste atteint les perfs du blitter en simple copie de données.Pour les blits complexes (avec plusieurs sources, modulo, copie rectangulaire) le 68000 serait à la rue .
Sans parler du coût d'un 68k @16mhz par rapport à un blitter et de l'impact qu'il aurait avec le chipset.

[rocky007]

Ah et pour tracer une fonte vectorielle , dessiner un cercle , le blitter c’est bien ?

[dlfrsilver]

Accélération matériel avec un CPU 8 bits pas du tout fait pour ça...

C'est aussi (surtout) à cause de la lenteur des opérations de décalage sur un 68000 que le Blitter de l'Amiga est intéressant car lui ne prend pas plus de temps pour décaler ses sources A & B

Je dis pas que le blitter n'est pas interessant sur un Amiga à 7,09 mhz  .  Par contre, plutot de se casser le cul à concevoir un blitter  et d'engager des couts la dedans  ... pour au final avoir une puce specifique ne pouvant tourner qu'a une certaine fréquence.  Et qu'il faudra redesigner pour la faire evoluer. 

il aurait peut etre été plus judicieux de concevoir directement l'Amiga avec un 68000 à 16mhz .    Ou de mettre un second processeur .    Mais bon pour ca, il aurait fallu avoir l'intention de faire un Micro  qui pourrait evoluer ... pas une console avec un hardware one shot.

La technologie basée sur "on fait tout au CPU bourdel", c'est obsolète dès le départ ! 

A partir du moment ou tu crées des logiciels pour tourner sur un CPU qui tourne à une cadence donnée, ensuite t'es coincé ! Si tu mets une carte accélératrice avec un CPU qui tourne plus vite, tes applications deviennent inutilisables, car conçues pour un clock d'horloge de 16mhz. avec une horloge qui tourne à 50mhz, tes applications tu peux les reprogrammer ! 

Regarde combien de logiciels PC étaient plus utilisables (ex: un soft fait pour 286, tu passes au 486, ton soft tourne en accéléré ou alors plante lamentablement). 

Regarde un exemple simple : les jeux ST patchés pour tourner sur Falcon par exemple : le ST tourne à 8mhz, le Falcon030 à 16mhz, tout de suite, les jeux en terme de vitesse ça devient du n'importe quoi ! 

C'est tout l'inconvénient de tout faire en soft. Tu prends l'Amiga, le chipset est le même partout, et t'es pas emmerdé avec les softs qui changent de vitesse fonction de la vitesse du CPU (ou alors quand c'est le cas, c'est tout à fait minime).

Pourquoi tu crois qu'aujourd'hui les PCs ont pour chaque partie d'un logiciel un CPU ou un GPU dédié ? C'est exactement pour cette raison. ça limite quand tu avances dans le temps les incompatibilités.

S'il te plait Silver,  fait nous plaisir,  ne parle pas technique , tu n'y pige rien.

Si justement. Et ce que je dis, n'importe qui peut le constater. La méthode tout au CPU ça vaut que dalle.

[dlfrsilver]

Accélération matériel avec un CPU 8 bits pas du tout fait pour ça...

C'est aussi (surtout) à cause de la lenteur des opérations de décalage sur un 68000 que le Blitter de l'Amiga est intéressant car lui ne prend pas plus de temps pour décaler ses sources A & B

Je dis pas que le blitter n'est pas interessant sur un Amiga à 7,09 mhz  .  Par contre, plutot de se casser le cul à concevoir un blitter  et d'engager des couts la dedans  ... pour au final avoir une puce specifique ne pouvant tourner qu'a une certaine fréquence.  Et qu'il faudra redesigner pour la faire evoluer. 

il aurait peut etre été plus judicieux de concevoir directement l'Amiga avec un 68000 à 16mhz .    Ou de mettre un second processeur .    Mais bon pour ca, il aurait fallu avoir l'intention de faire un Micro  qui pourrait evoluer ... pas une console avec un hardware one shot.

Ah bon ? Un 68000 2 fois plus rapide aurait meilleur ? Ben non : un 68020 4 fois plus rapide ne l'est pas.

Je crois que tu inverses mon brave Youki. Parce qu'en terme d'évolution cpu, c'est le ST qui a de gros problèmes :
- Pour tourner à 16 Mhz, les megaSTE sont équipé d'une mémoire cache de 16 Ko qui permet de récupérer une partie des cycles inutilisables par le CPU car "collés".
- Pour aller au delà, il a fallu reconcevoir une machine (le TT) en copiant le principe de fast ram de l'Amiga. Dommage que ça n'est pas été fait dès le début car il faut un os et des programmes programmes prévus pour si on veut en tirer parti...

Même au niveau de l'OS, les évolutions posent problèmes :
- Utilisation de la line A. Interdite par Motorola car incompatible avec les futurs évolutions du cpu.
- incompatibilité 32 bits. Dommage : tous les cpu après le 68000 le sont...
- "Tricherie" sur le calcul de l'adresse lors des accès aux registres. Le 68030 du Falcon est obligé d'initialiser sa MMU pour corriger ça...

Je pourrais continuer mais ça suffit car l'Amiga n'a aucun de ces problèmes car lui est prévu pour évoluer. Colle un cpu hyper rapide dans un A500 et tu peux jouer à Quake...

Et tous les amiga ont un ou plusieurs ports permettant d'upgrader le cpu ou autres. Et le ST a un port cartouche...

Lequel est le one shot ?

Edit : tu l'as peut-être oublié, mais les Amiga avec plusieurs cpu ont existé avec des cartes PowerPC + 680x0. La beauté de l'OS, c'est que pleins de programmes non prévus en tiraient parti. Surtout pour la FPU puisque l'OS propose des librairies pour ça...

MDR et après le Youki il vient me faire la leçon sur la technique, ahaha, mais quel boloss   

Les softs qui tournent au CPU foirent dès que le clock d'horloge change, soit ça crashe, soit ça tourne trop vite et c'est inutilisable...... tu confirmes Stapha ? 

[rocky007]

donc tu voudrais dire que ce serait cool d'avoir un Calamus sur Falcon 060 qui tournerait à vitesse d'un ST  ?

[stapha92]

Accélération matériel avec un CPU 8 bits pas du tout fait pour ça...

C'est aussi (surtout) à cause de la lenteur des opérations de décalage sur un 68000 que le Blitter de l'Amiga est intéressant car lui ne prend pas plus de temps pour décaler ses sources A & B

Je dis pas que le blitter n'est pas interessant sur un Amiga à 7,09 mhz  .  Par contre, plutot de se casser le cul à concevoir un blitter  et d'engager des couts la dedans  ... pour au final avoir une puce specifique ne pouvant tourner qu'a une certaine fréquence.  Et qu'il faudra redesigner pour la faire evoluer. 

il aurait peut etre été plus judicieux de concevoir directement l'Amiga avec un 68000 à 16mhz .    Ou de mettre un second processeur .    Mais bon pour ca, il aurait fallu avoir l'intention de faire un Micro  qui pourrait evoluer ... pas une console avec un hardware one shot.

Ah bon ? Un 68000 2 fois plus rapide aurait meilleur ? Ben non : un 68020 4 fois plus rapide ne l'est pas.

Je crois que tu inverses mon brave Youki. Parce qu'en terme d'évolution cpu, c'est le ST qui a de gros problèmes :
- Pour tourner à 16 Mhz, les megaSTE sont équipé d'une mémoire cache de 16 Ko qui permet de récupérer une partie des cycles inutilisables par le CPU car "collés".
- Pour aller au delà, il a fallu reconcevoir une machine (le TT) en copiant le principe de fast ram de l'Amiga. Dommage que ça n'est pas été fait dès le début car il faut un os et des programmes programmes prévus pour si on veut en tirer parti...

Même au niveau de l'OS, les évolutions posent problèmes :
- Utilisation de la line A. Interdite par Motorola car incompatible avec les futurs évolutions du cpu.
- incompatibilité 32 bits. Dommage : tous les cpu après le 68000 le sont...
- "Tricherie" sur le calcul de l'adresse lors des accès aux registres. Le 68030 du Falcon est obligé d'initialiser sa MMU pour corriger ça...

Je pourrais continuer mais ça suffit car l'Amiga n'a aucun de ces problèmes car lui est prévu pour évoluer. Colle un cpu hyper rapide dans un A500 et tu peux jouer à Quake...

Et tous les amiga ont un ou plusieurs ports permettant d'upgrader le cpu ou autres. Et le ST a un port cartouche...

Lequel est le one shot ?

Edit : tu l'as peut-être oublié, mais les Amiga avec plusieurs cpu ont existé avec des cartes PowerPC + 680x0. La beauté de l'OS, c'est que pleins de programmes non prévus en tiraient parti. Surtout pour la FPU puisque l'OS propose des librairies pour ça...

MDR et après le Youki il vient me faire la leçon sur la technique, ahaha, mais quel boloss   

Les softs qui tournent au CPU foirent dès que le clock d'horloge change, soit ça crashe, soit ça tourne trop vite et c'est inutilisable...... tu confirmes Stapha ? 

Ça dépend : si ce qui est sensible à la vitesse est fait sous interruption, il n'y a pas de problème. Si c'est un Kernel comme on faisait avec les 8 bits par contre, ça ne marche plus...

Par exemple : les 48 couleurs par lignes sont impossibles sous interruptions. Du coup Spectrum 512 ne marcherait plus...
Autre exemple : Idem pour jouer un sample à 48 Khz par cpu sur ST. Il faut un Kernel.

Ce genre de système n'est pas utilisé sur l'Amiga (et lui peut jouer un sample au cpu à 48 Khz sous interruptions : il s'en sort toujours mieux..).

Après, que le ST utilise une technique 8 bits ne me gêne pas. Il n'était pas destiné à recevoir autre chose qu'un 68000 à 8 Mhz. Donc c'est une optim acceptable. C'est ce qui est affirmé ici qui rend tout ça ridicule.

On utilise ce genre de programmation sur C64 ou A800 tout le temps et ce n'est pas gênant pour les mêmes raisons.

En tout cas, j'attends qu'un des éminents spécialistes présent ici écrive un code 68000 qui fait une simple copie avec décalage (Même pas besoin d'opération logique ou autre...). Il sera rendra compte de l'écart alors qu'il n'aura pas écrit le 1/4 du code...

[Yastuna Lynx]

Les softs qui tournent au CPU foirent dès que le clock d'horloge change, soit ça crashe, soit ça tourne trop vite et c'est inutilisable...... tu confirmes Stapha ? 

Bah non.
Les softs qui partent du principe qu'ils vont toujours tourner sur la même machine avec un hardware fixe auront des problèmes.
Ca a été le cas sur ST et Amiga.

Et les softs bien programmés n'avaient pas ce soucis (certains sur ST tiraient même profit de choses qui n'existaient pas lors de leur conception comme les résolutions étendues)

Il y a probablement eu plus de dégats plus sur ST car Atari a mis beaucoup trop de temps à faire évoluer les machines et n'a pas voulu casser la compatibilité en sortant le STE.
Mais si le Mega ST avait été à 16mhz et si le STE avait intégré d'autres modes vidéo, le massacre aurait été moindre au moment du Falcon car les softs auraient été plus propres.

[dlfrsilver]

Les softs qui tournent au CPU foirent dès que le clock d'horloge change, soit ça crashe, soit ça tourne trop vite et c'est inutilisable...... tu confirmes Stapha ? 

Bah non.
Les softs qui partent du principe qu'ils vont toujours tourner sur la même machine avec un hardware fixe auront des problèmes.
Ca a été le cas sur ST et Amiga.

Et les softs bien programmés n'avaient pas ce soucis (certains sur ST tiraient même profit de choses qui n'existaient pas lors de leur conception comme les résolutions étendues)

Il y a probablement eu plus de dégats plus sur ST car Atari a mis beaucoup trop de temps à faire évoluer les machines et n'a pas voulu casser la compatibilité en sortant le STE.
Mais si le Mega ST avait été à 16mhz et si le STE avait intégré d'autres modes vidéo, le massacre aurait été moindre au moment du Falcon car les softs auraient été plus propres.

Comme je l'ai dis, tu passes un soft fait pour un ST à 8mhz sur un Falcon à 16mhz, et ça tourne trop vite !

[youki]

La plus part des jeux sont synchronisé sur le balayage écran qui ne change pas quelque soit la fréquence du processeur.

[Copper]

Certes mais pas les bidouilles au cycle près avec des tempo à base de NOP par exemple

[youki]

Certes mais pas les bidouilles au cycle près avec des tempo à base de NOP par exemple

Oui, mais bon même pour ca, beaucoup font en sorte de rester a vitesse constante quelque soit la vitesse du proc. Notemment pour certainnes machines qui ont une fréquence d'horloge differente entre les modèle PAL et NTSC.

Et sur PC a part pour vraiment les tout premiers soft où effectivement il arrivait qu'ils passaient en mode "vitesse démesurée" (quizz: a quoi je fais référence?)  , aucun jeu ou logiciel post 84 n'a ce type de problème je pense.  Pourtant c'est tout au processeur.    La vitesse au contraire améliore le jeu .. surtout pour les jeux 3D.  

Ce qui est important , c'est de garde la vitesse constante au niveau du scan des controles et de se synchroniser sur le balayage écran et généralement d'ailleur tu sychronise le pull des controles sur le balayge ecran aussi.

Pour en revenir à spectrum 512   ,  je sais pas , mais est ce qu'il marche sur un Mega STE 16Mhz?  C'est bien possible malgrès la difference de fréquence.

[rocky007]

en mode "vitesse démesurée" (quizz: a quoi je fais référence?) .

[Yastuna Lynx]

Les softs qui tournent au CPU foirent dès que le clock d'horloge change, soit ça crashe, soit ça tourne trop vite et c'est inutilisable...... tu confirmes Stapha ? 

Bah non.
Les softs qui partent du principe qu'ils vont toujours tourner sur la même machine avec un hardware fixe auront des problèmes.
Ca a été le cas sur ST et Amiga.

Et les softs bien programmés n'avaient pas ce soucis (certains sur ST tiraient même profit de choses qui n'existaient pas lors de leur conception comme les résolutions étendues)

Il y a probablement eu plus de dégats plus sur ST car Atari a mis beaucoup trop de temps à faire évoluer les machines et n'a pas voulu casser la compatibilité en sortant le STE.
Mais si le Mega ST avait été à 16mhz et si le STE avait intégré d'autres modes vidéo, le massacre aurait été moindre au moment du Falcon car les softs auraient été plus propres.

Comme je l'ai dis, tu passes un soft fait pour un ST à 8mhz sur un Falcon à 16mhz, et ça tourne trop vite !

Je n'ai jamais trouvé que Degas Elite, GFA, Pure C, Interface 2, ... tournaient trop vite sur le Falcon...
Encore heureux qu'ils profitaient du surcroit de puissance, non ?
A moins que sur Amiga, les opérations de calcul & co sur un 4000 devaient prendre le même temps que sur un 500 car les softs étaient bien programmés ?

Après, si ta seule motivation, c'était les jeux, alors oui ça pouvait poser problème (mais pour certains softs 3D comme Elite 2, c'était bienvenu), mais d'un autre coté, tu n'achetais pas de Falcon dans ce cas là.

A noter que même Nintendo a le même problème avec le Super GB qui n'est pas cadencé à la même fréquence que les GB.
Et sur les consoles de salons, la différence était flagrante entre les 50 et 60hz, il n'y avait pas que le processeur en cause...

[Copper]

Très souvent tu avais un jeu plus rapide en NTSC qu'en PAL

Ce n'est pas suffisant de se synchroniser sur le balayage il faut aussi que le déplacement des objets tienne compte de la fréquence de balayage donc tu temps écoulé entre 2 affichage (ce qu'on fait de nos jours avec un paramètre du genre Time.deltaTime dans Unity ou delta dans Godot)

A mon avis, si la bidouille Spectrum 512 marche c'est certainement qu'il y a eu une nouvelle version pour gérer cette machine entre temps

[youki]

Très souvent tu avais un jeu plus rapide en NTSC qu'en PAL

Ce n'est pas suffisant de se synchroniser sur le balayage il faut aussi que le déplacement des objets tienne compte de la fréquence de balayage donc tu temps écoulé entre 2 affichage (ce qu'on fait de nos jours avec un paramètre du genre Time.deltaTime dans Unity ou delta dans Godot)

A mon avis, si la bidouille Spectrum 512 marche c'est certainement qu'il y a eu une nouvelle version pour gérer cette machine entre temps

Ca c'etait surtout parce que c'etait synchronisé sur la fréquence de balayage.  50hz PAL et 60hz NTSC  , ca venait pas de la difference de vitesse du proc.

Ben tu compte le nombre de synchro pour gerer les deplacement ,  enfin moi c'est ce que j'ai toujours fait . Pas besoin de delta..

Dans mes jeux j'ai des objets qui se deplacent chaque vbl ,  d'autre toutes les 2 vbl  ou 4 .etc.. en fonction de la vitesse auquel je veux qu'ils bougent.

[touko]

La plus part des jeux sont synchronisé sur le balayage écran qui ne change pas quelque soit la fréquence du processeur.

Pour la simple logique d'un jeu oui, mais du code sous interruption ou timés c'est la cata, vu que les timing liés aux instructions ne sont plus les mêmes et donc la synchro est perdue .

[youki]

La plus part des jeux sont synchronisé sur le balayage écran qui ne change pas quelque soit la fréquence du processeur.

Pour la simple logique d'un jeu oui, mais du code sous interruption ou timés c'est la cata, vu que les timing liés aux instructions ne sont plus les mêmes et donc la synchro est perdue .

ca influe pas vraiment le timing au instructionsi tu es synchronisé sur le balayage ou un timer.

Meme si par exemple ton image va se construire plus vite en memoire  , vu que tu va la blitter en memoire video toujours au meme moment , ca change rien.   Pareil pour les controles vu que tu tester ton joystick toujours meme rytme ,  et que tu va reagir de la meme facon  , ton jeu ira toujours a la meme vitesse.

Mais c'est sur faut programmer en connaissance de cause.    Si tu t'amuses a faire des trucs basé sur des timings precis synchronisé sur les cycles du processeur... effectivement ca foire... mais tu ne fais pas ça normalement sur un logiciel pour micro que tu va publier  ou lalors quand tu débutes  (j'ai fait ce genre de connerie aussi comme beaucoup au debut)

Sur une demo a la rigueur et  sur  les console de jeu des années 80 où tu savais que la console suivante aurait un hardware completement different.

[touko]

ca influe pas vraiment le timing au instructionsi tu es synchronisé sur le balayage ou un timer.

Une interruption timer n'est pas précise, elle varie en fonctions de l'instruction en cours.
Sur le vsync pas de soucis, on s'en fou la fenêtre est tellement large, mais pour simuler une interruption hsync au timer t'es obligé, en général tu tapes un peu avant la fin de ligne précédente, et tu te synchronises à la mano pour être sur d'être synchro et pas tapper en plein affichage pour éviter les jitters, pour jouer un sample aussi .

Le ST est incapable de se synchroniser de façon automatique avec le balayage écran, hormis le vsync .

mais tu ne fais pas ça normalement sur un logiciel pour micro que tu va publier  ou lalors quand tu débutes 

On est d'accord, un logiciel de base ne le fait pas, mais un spectrum 512 certainement, ou un jeu un peu technique comme goldrunner .

[youki]

ca influe pas vraiment le timing au instructionsi tu es synchronisé sur le balayage ou un timer.

Une interruption timer n'est pas précise, elle varie en fonctions de l'instruction en cours.
Sur le vsync pas de soucis, on s'en fou la fenêtre est tellement large, mais pour simuler une interruption hsync au timer t'es obligé, en général tu tapes un peu avant la fin de ligne précédente, et tu te synchronises à la mano pour être sur d'être synchro et pas tapper en plein affichage pour éviter les jitters, pour jouer un sample aussi .

Le ST est incapable de se synchroniser de façon automatique avec le balayage écran, hormis le vsync .

Oui, c'est vrai , je m'en souviens, je faisais un truc comme ça avec les HBL sur ST.   Mais bon, c'est quand je bidouillais  pour faire une petite crackto.

[touko]

ca influe pas vraiment le timing au instructionsi tu es synchronisé sur le balayage ou un timer.

Une interruption timer n'est pas précise, elle varie en fonctions de l'instruction en cours.
Sur le vsync pas de soucis, on s'en fou la fenêtre est tellement large, mais pour simuler une interruption hsync au timer t'es obligé, en général tu tapes un peu avant la fin de ligne précédente, et tu te synchronises à la mano pour être sur d'être synchro et pas tapper en plein affichage pour éviter les jitters, pour jouer un sample aussi .

Le ST est incapable de se synchroniser de façon automatique avec le balayage écran, hormis le vsync .

Oui, c'est vrai , je m'en souviens, je faisais un truc comme ça avec les HBL sur ST.   Mais bon, c'est quand je bidouillais  pour faire une petite crackto.

Oui si je prends ton exemple du logiciel classique t'en as pas besoin, c'est sur .

[Copper]

Ca c'etait surtout parce que c'etait synchronisé sur la fréquence de balayage.  50hz PAL et 60hz NTSC  , ca venait pas de la difference de vitesse du proc.

Ben tu compte le nombre de synchro pour gerer les deplacement ,  enfin moi c'est ce que j'ai toujours fait . Pas besoin de delta..

Dans mes jeux j'ai des objets qui se deplacent chaque vbl ,  d'autre toutes les 2 vbl  ou 4 .etc.. en fonction de la vitesse auquel je veux qu'ils bougent.

Sauf du coup il ne vont pas à la même vitesse si tu te déplaces d'un pixel 50 fois par seconde ou d'un pixel 60 fois par seconde ce n'est pas la même chose... D’où la nécessité d'avoir un delta...

La plupart des jeux ne géraient même pas ça alors tu penses bien qu'il n'allaient pas gérer un CPU à 16 Mhz pour les bidouilles ou l'on avait besoin de timing précis au cycle près.

[youki]

Ca c'etait surtout parce que c'etait synchronisé sur la fréquence de balayage.  50hz PAL et 60hz NTSC  , ca venait pas de la difference de vitesse du proc.

Ben tu compte le nombre de synchro pour gerer les deplacement ,  enfin moi c'est ce que j'ai toujours fait . Pas besoin de delta..

Dans mes jeux j'ai des objets qui se deplacent chaque vbl ,  d'autre toutes les 2 vbl  ou 4 .etc.. en fonction de la vitesse auquel je veux qu'ils bougent.

Sauf du coup il ne vont pas à la même vitesse si tu te déplaces d'un pixel 50 fois par seconde ou d'un pixel 60 fois par seconde ce n'est pas la même chose... D’où la nécessité d'avoir un delta...

La plupart des jeux ne géraient même pas ça alors tu penses bien qu'il n'allaient pas gérer un CPU à 16 Mhz pour les bidouilles ou l'on avait besoin de timing précis au cycle près.

Enfin moi quand vraiment je veux controller ça , je teste juste au depart si je suis en pal ou en ntsc  , et j'adapte mes constantes en fonction au depart.

[Copper]

C'est une autre façon de faire encore faut-il pouvoir les adapter (en virgule fixe par exemple)

[youki]

en mode "vitesse démesurée" (quizz: a quoi je fais référence?) .

Non ma référence ce n'est pas tesla.

Mais tesla a pris la même référence que moi.

Par contre sur la tesla ,le mode qui fait référence à la même chose que moi, n'est pas le mode inouie.

[rocky007]

Ah ok , donc alors c’est la parodie de Star Wars

Sur tesla , inouïe+ est l’équivalent français de ludicrous

[youki]

Ah ok , donc alors c’est la parodie de Star Wars

Sur tesla , inouïe+ est l’équivalent français de ludicrous

Oui, c est ça

[rocky007]

J’ai gagné qq chose ?