Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Forum Ti68K » Programmation C » Article : Régulation de la vitesse d'un jeu (33 réponse(s))
./REPRISE DU POST PRECEDENT (post n°19)   Marquer comme non lu.
LionelA Ecrit le: Samedi 15 janvier 2005 à 23:16 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Alors il semblerait que cette méthode qui consiste à executer beaucoup de code dans le handler d'interruption ne soit pas une bonne chose (probleme de design).
Pourtant je l'utilise depuis presque un an sans jamais avoir eu le moindre problème :)

Donc je ne sais pas s'il vaut mieux retirer ou non cet article. A vous de voir...
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°20   Marquer comme non lu.
Kevin Kofler Ecrit le: Dimanche 16 janvier 2005 à 00:59 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Oui, une solution plus propre ressemble à ça:
#define SHOW_FPS 0 // 0 : don't show, 1 : show fps
#define GAME_SPEED 10 // 0 : the fastest

INT_HANDLER OldInt1 = NULL;
#if SHOW_FPS == 1
char fpsStr[10];
#endif
char hwVersion;
volatile char quit = 0;
char modifying = 0;
char nextModif = 0;
short timeCount = 0;
volatile short fCount = 0;
void (*display_Modif)();
short showFPS = 0;

void Display();

// [Thanks to Geogeo from www.tigen.org for this code]
#define HARDWARE_FREQUENCY        20970
static volatile unsigned short counter_hardware=0;

DEFINE_INT_HANDLER (SceneModif)
{
  ExecuteHandler (OldInt1);
  //HARDWARE VERSION 1.0 
  if (hwVersion==1)
  {
    //Incrémentation
    counter_hardware+=HARDWARE_FREQUENCY;
  
    //Execution interrupotion
    if (counter_hardware<=32768 )
      return;
    //Remise à zéro
    counter_hardware-=32768;        
  }
// [/Thanks to Geogeo from www.tigen.org for this code]
  timeCount++;
  if (timeCount == (256))
  {
    timeCount = 0;
#if SHOW_FPS == 1
    showFPS = 1;
#endif
  }
  
  if (!modifying && !nextModif)
  {
    modifying = 1;
    nextModif = GAME_SPEED;
  }
  if(nextModif)
    nextModif--;
}


void SetLoopFunc(void (*modifFunc)())
{
  display_Modif = modifFunc;
}


void LoopInit()
{
  quit = 0;
  modifying = 0;
  timeCount = 0;
  fCount = 0;
  hwVersion = HW_VERSION;
  OldInt1 = GetIntVec (AUTO_INT_1);
}

void LoopEnd()
{
  SetIntVec (AUTO_INT_1, OldInt1);  
}

void MainLoop()
{
  SetIntVec (AUTO_INT_1, SceneModif);
  while(!quit)
  {
    Display();
#if SHOW_FPS == 1
    fCount++;    
    if (showFPS) {
      PortSet(Plane0,239,127);
      DrawStr (0, 0, "          ", A_REPLACE);
      sprintf (fpsStr, "%d", fCount);
      DrawStr (0, 0, fpsStr, A_REPLACE);
      PortRestore();
      fCount = 0;
    }
#endif
    if (modifying) {
      display_Modif();
      modifying = 0;
    }
  }  
}

void LoopQuit()
{
  quit = 1;
}

Tu vois qu'il n'y a pas d'attente dans le vide, le CPU est toujours utilisé. Et avec cette adaptation, tu ne fais plus un DisplayModif pendant ton Display (une très mauvaise idée!).
-Edité le Dimanche 16 janvier 2005 à 01:01 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°21   Marquer comme non lu.
LionelA Ecrit le: Dimanche 16 janvier 2005 à 10:39 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Je suis bien d'accord que si le code qui se trouve à l'interieur d'une interruption doit être vraiment très rapide c'est la meilleure solution mais voila les 3 raisons pour lesquelles je dois utiliser cette méthode dans FZero :

(tout est la faute de la fonction display qui est lente)

1) comme la fonction display fait le rendu d'une frame de mode7 elle met environ 83ms à s'executer, alors que l'autoint 1 occure toutes les 3ms. Avec ma méthode l'environnement (position de la camera, positions des sprites) est modifié toutes les GAME_SPEED * 3ms = 30ms même s'il n'est affiché que toutes les 83ms. Cela permet de faire des tests de collisions smooth et d'avoir une réponse au clavier quasi immediate (c'est trop saccadé de tester le clavier à chaque 83ms)

2) l'execution de display sur HW1 met encore plus de temps (100ms) donc avec ta méthode on teste le clavier et modifie l'environnement toutes les 100ms, ce qui fait que le déroulement du jeu se passe au ralenti sur une HW1 par rapport à une HW2, dans un jeu de reflexe et rapidité ca va se ressentir sur les temps réalisés en Time Attack.

3) puisqu'on est sûrs que l'interruption aura occuré durant un calcul d'une frame, la régulation ne sert plus du tout, car la variable modifying sera obligatoirement égale à 1 lors du test en fin de boucle.

Conclusion si votre fonction d'affichage est beaucoup plus rapide que 1/256 * GAME_SPEED secondes (normallement c'est la cas pour la plupart des jeux) utilisez le source de Kevin Kofler, sinon utilisez le mien :)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°22   Marquer comme non lu.
Kevin Kofler Ecrit le: Dimanche 16 janvier 2005 à 17:09 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Et si tu faisais comme la routine de gris, c'est-à-dire de n'afficher qu'un tiers d'écran (ou un quart, cinquième, ...) à chaque fois?

Et franchement, j'ai bien peur que modifier l'environnement pendant l'affichage peut causer pas mal de "race conditions" qui font boguer le tout. Personnellement, je ne permettrais jamais à une interruption de modifier de manière pratiquement incontrollée les données que je suis en train de lire, ça ne peut entraîner que des ennuis. Quand tu auras des bogues aléatoires et incompréhensibles (ce qui est à mon avis inévitable avec cette méthode), tu te rappelleras de ce paragraphe...
-Edité le Dimanche 16 janvier 2005 à 17:09 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°23   Marquer comme non lu.
RHJPP Ecrit le: Lundi 6 juin 2005 à 10:00 Déconnecté(e)    Voir le profil de RHJPP Envoyer un email à RHJPP Envoyer un message privé à RHJPP  


Avec le code de LionelA la vitesse est stabilisée même pour les ti overclockées pour les quelle on ne connaît pas la vitesse du processeur ?
    
./Post n°24   Marquer comme non lu.
Folco Ecrit le: Lundi 6 juin 2005 à 13:20 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


A priori, les méthodes d'overclock utilisées couramment ne modifient pas la fréquence des interruptions.
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°25   Marquer comme non lu.
RHJPP Ecrit le: Lundi 6 juin 2005 à 16:39 Déconnecté(e)    Voir le profil de RHJPP Envoyer un email à RHJPP Envoyer un message privé à RHJPP  


>> Martial Demolins : A priori, les méthodes d'overclock utilisées couramment ne modifient pas la fréquence des interruptions.
Ok, je ne savais pas !
-Edité le Lundi 6 juin 2005 à 16:41 par Thepro-
    
./Post n°26   Marquer comme non lu.
geogeo Ecrit le: Lundi 6 juin 2005 à 17:20 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Sur HW1? Les interruptions sont basées sur le processeur non?
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°27   Marquer comme non lu.
LionelA Ecrit le: Lundi 6 juin 2005 à 17:31 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Non, enfin pas AUTO_INT_1 car j'ai un pote qui a une 89HW1 overclockée et F-ZERO tourne a la meme vitesse de jeu que sur les autres calc (mais il a bcp plus de fps :p)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°28   Marquer comme non lu.
Sasume Ecrit le: Lundi 6 juin 2005 à 17:55 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

The TI89 has two (HW2 has three) separate oscillators, they are refered to
as OSC1 and OSC2 (and OSC3).

OSC1 is the M68000 CPU clock.
  HW1: ~10 MHz
  HW2: ~12 MHz

OSC2 is the timing base for the timers, the link I/O hardware and (HW1 only)
the LCD controller.
  HW1: ~680 kHz - ~770 kHz
  HW2: ??? - (~520 kHz (= 2^19 Hz !)) - ???

===========================================================================
INTERRUPT LEVELS
---------------------------------------------------------------------------
Level 1:
  Triggered at a fixed rate: OSC2/2^11.  See $600015:7/1.
Level 2:
  Triggered when the *first* unmasked key (see $600019) is *pressed*.
  Keeping the key pressed, or pressing another without released the first
  key, will not generate additional interrupts.  The keyboard is not
  debounced in hardware and the interrupt can occasionally be triggered many
  times when the key is pressed and sometimes even when the key is released!
  Write any value to $60001B to acknowledge this interrupt.
Level 3:
  Disabled by default by AMS, early versions crash if it is enabled.  When
  enabled, it is triggered at a fixed rate: OSC2/2^19.  See $600015:2.
Level 4:
  Triggered by the link hardware for various reasons.  Read from $60000C and
  sometimes read/write $60000F to properly acknowledge this interrupt.
Level 5:
  Triggered by the programmable timer.  The default rate (set by AMS on
  reset) is OSC2/(K*2^9), where K=79 for HW1 and K=53 for HW2.  See $600015
  and $600017.
Level 6:
  Triggered when [ON] is pressed.  As with the rest of the keyboard, the
  lack of hardware debouncing sometimes triggers additional interrupts.
  Write any value to $60001A to acknowledge this interrupt.
Level 7:
  If the "vector table write protection" is enabled, this interrupt is
  triggered on a write access to any address below $000120.  The write will
  of course be ignored.  This interrupt is (also) a convenient way to detect
  stack overflows.  See $600001:2.
    
./Post n°29   Marquer comme non lu.
Folco Ecrit le: Lundi 6 juin 2005 à 18:55 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Suffit de regarder le curseur du HOME pour le voir.
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°30   Marquer comme non lu.
LionelA Ecrit le: Jeudi 21 juillet 2005 à 06:24 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Ce soir j'ai effectué des tests et je me suis rendu compte que la fréquence de l'AI1 sur VTI etait carrement fausse.
Ne possedant plus de HW1 j'ai testé sur TIemu qui semble déjà plus rigoureux et la valeur obtenue pour HARDWARE_FREQUENCY est :

#define HARDWARE_FREQUENCY 23967

voilà, j'aimerais bien pouvoir tester sur une vraie HW1 pour m'en assurer, si quelqu'un en a une et veut bien faire des tests, je lui enverrai un petit prog :)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°31   Marquer comme non lu.
LionelA Ecrit le: Jeudi 21 juillet 2005 à 22:27 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Bon en fait ca serait bon ar tiemu m'a donné une fréquence d'AI1 de 350Hz et il parait que c'est la valeur généralement admise par les programmeurs :)

Une question me reste quand même : est ce que l'AI1 est aussi à 256Hz sur HW3 ?
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°32   Marquer comme non lu.
geogeo Ecrit le: Vendredi 22 juillet 2005 à 11:45 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


oui
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°33   Marquer comme non lu.
Kevin Kofler Ecrit le: Vendredi 22 juillet 2005 à 12:37 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


TiEmu a été calibré avec ma HW1, aussi. Donc sauf erreurs de calcul, il fait la bonne chose.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
  :: Index » Forum Ti68K » Programmation C » Article : Régulation de la vitesse d'un jeu (33 réponse(s))
Pages : 2/2     « 1 [2] » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 39.49ms avec 18 requetes