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 » grayscale bug ? (11 réponse(s))
./POST DE DEPART (post n°0)   Marquer comme non lu.
LionelA Ecrit le: Dimanche 15 août 2004 à 19:33 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


J'ai pris l'habitude d'utiliser les niveaux de gris avec double buffer dans tigcc et je me suis aperçu d'un truc bizarre :
L'image clignote bizarrement lorsqu'on touche au clavier, même si on a redirigé l'autoint1

Le mieux est de voir par soi meme, donc voila un petit bout de code :


// C Source File
// Created 15/08/2004; 19:13:36


#include <tigcclib.h>

// Main Function
void _main(void)
{
  unsigned char * buff;
  
  buff = (unsigned char *)malloc(GRAYDBUFFER_SIZE);
  
  if (!GrayOn ())
    return;
    
  GrayDBufInit (buff);
  while(1)
  {
    PortSet (GrayDBufGetHiddenPlane (LIGHT_PLANE), 239, 127);
    ClrScr ();
    ScrRectFill (&(SCR_RECT){{20,20,40,40}}, ScrRect, A_NORMAL);
    ScrRectFill (&(SCR_RECT){{80,20,100,40}}, ScrRect, A_NORMAL);
    PortSet (GrayDBufGetHiddenPlane (DARK_PLANE), 239, 127);
    ClrScr ();
    ScrRectFill (&(SCR_RECT){{50,20,70,40}}, ScrRect, A_NORMAL);
    ScrRectFill (&(SCR_RECT){{80,20,100,40}}, ScrRect, A_NORMAL);
    GrayDBufToggleSync ();
  }
  
  GrayOff ();

}


lorsque l'on appuie sur une touche ca fait le truc bizarre, et en réappuyant ca redevient normal parfois.

A essayer sur VTI, car sur la vraie TI on ne le voit pas (rafraîchissement de l'écran lent ?)

Voila j'aimerais savoir si c'est bien un bug et d'ou il pourrait venir.

Est-ce que beaucoup d'entre vous utilisent le double buffering ?
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°1   Marquer comme non lu.
Fisch2 Ecrit le: Dimanche 15 août 2004 à 20:16 Déconnecté(e)    Voir le profil de Fisch2 Envoyer un email à Fisch2 Envoyer un message privé à Fisch2  

J'ai remarqué aussi le signal transitoire de double-buffering de frappe sur VTI, mais puisque il n'apparaît pas sur un véritable calc, j'ai supposé que c'était juste un problème avec VTI et pas le code de double-buffering. VTI v2.05 est su pour avoir plusieurs problèmes d'émulation, donc ne ceci ferait pas sans aucun doute suprise me.

Que ferait-il l'éclat du code ci-dessus mentionné est étrangement que vous avez besoin d'appeler GrayWaitNSwitches(2) ; si le calc est HW1 (et VTI est HW1). Pour faire ce plus facile, en utilisant le double-buffering, j'utilise le suivre au lieu de GrayDBufToggleSync () ;

#définir Safe_Toggle () {GrayDBufToggleSync() ; \ if (HW1) \ GrayWaitNSwitches(2) ;}

Aussi, (bien que ceci est juste un prog de test) vous devez ajouter un contrôle pour s'assurer que l'allocation de mémoire a travaillé et le besoin de libérer la mémoire à la fin.

Le vous de d'entre de beaucoup de que de >>Est-ce utilisent le buffering double ? Le soutien de double-buffering de TIGCC paraît souvent les formes plus agréables qu'autres de double-buffering (puisque il est synchronisé avec l'inverser d'avion en noir et blanc), mais puisque il doit attendre les avions en noir et blanc pour inverser avant de basculer les avions cachés et actifs, c'est aussi plus lent. , Juste utilisant parfois FastCopyScreen du caché aux tampons actifs (sans inaugure le double-buffering de TIGCC) peut amener une poussée de vitesse significative, surtout si votre prog est tilemap-basé. Personnellement, je préfère ne pas utiliser l'a incorporé le soutien de double-buffering.

---

I have also noticed the keypress double-buffering glitch on VTI, but since it doesn't appear on an actual calc, I assumed that it was just a problem with VTI and not the double-buffering code. VTI v2.05 is known to have several emulation issues, so this definitely wouldn't suprise me.

What would make the above code flash strangely is that you need to call GrayWaitNSwitches(2); if the calc is HW1 (and VTI is HW1). To make this easier, when using double-buffering, I use the following instead of GrayDBufToggleSync ();

#define Safe_Toggle() {GrayDBufToggleSync(); \
if (HW1) \
GrayWaitNSwitches(2);}

Also, (even though this is just a test prog) you should add a check to make sure that the memory allocation worked and need to free the memory at the end.

>>Est-ce que beaucoup d'entre vous utilisent le double buffering ?
TIGCC double-buffering support often looks nicer than other forms of double-buffering (since it is synchronized with the grayscale plane flipping), but since it must wait for the grayscale planes to flip before toggling the hidden and active planes, it is also slower. Sometimes, just using FastCopyScreen's of the hidden to active buffers (without initiating TIGCC's double-buffering) can bring a significant speed boost, especially if your prog is tilemap-based. Personally, I prefer not to use the built in double-buffering support.
Bah
    
./Post n°2   Marquer comme non lu.
LionelA Ecrit le: Dimanche 15 août 2004 à 20:37 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Ok thank you very much !
I will try to use FastCopyScreen instead and code my own double buffering system.
In f-zero I use tigcc double-buffering support but with GrayDbufToggle () and not GrayDbufToggleSync (), will the fastcopyscreen method make an improvement to the fps ?
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°3   Marquer comme non lu.
geogeo Ecrit le: Dimanche 15 août 2004 à 20:49 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


J'ai constaté ce genre de chose dans Arkanoid quand l'auto int n°1 est surchargé. Ici ça n'a pas l'air d'être le cas.

I noted this kind of thing in Arkanoid when the auto int n°1 is overloaded. Here that does not seem to be the case.
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°4   Marquer comme non lu.
Benjy Ecrit le: Dimanche 15 août 2004 à 21:32 Déconnecté(e)    Voir le profil de Benjy Envoyer un email à Benjy Visiter le site WEB de Benjy Envoyer un message privé à Benjy  


Mais Lionel, dans ton code la, l'int1 n'est pas redirige?
Le langage C y'a pas mieux!!!
    
./Post n°5   Marquer comme non lu.
LionelA Ecrit le: Dimanche 15 août 2004 à 21:34 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


ben non ! mais qu'il le soit ou pas c'est le même effet
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°6   Marquer comme non lu.
Fisch2 Ecrit le: Dimanche 15 août 2004 à 21:52 Déconnecté(e)    Voir le profil de Fisch2 Envoyer un email à Fisch2 Envoyer un message privé à Fisch2  

Je suis maintenant presque complètement certain que le clignoter étrange sur VTI que ne vous avez pas décrit est en raison du double-buffering de TIGCC. J'ai essayé tenant une clef en bas dans un des menus d'Hockey sur glace (qui n'utilise pas le double-buffering de TIGCC) et j'éprouve clignoter le signal transitoire pareil. Ceci fait me pense que ceci doit être un signal transitoire avec VTI.

>>I will try to use FastCopyScreen instead and code my own double buffering system.
Si vous aimeriez les exemples de programmes qui utilisent cette approche, vérifier la source d'Hockey sur glace et de Excitebike (n'essayant pas de faire de la publicité pour ou n'importe quoi)

>>will the fastcopyscreen method make an improvement to the fps ?
Je sais qu'il ferait sans aucun doute si vous changiez de l'utilisation de GrayDbufToggleSync () à FastCopyScreen, mais je pense qu'il serait seulement un très petit changer de gain de GrayDbufToggle (). A mon avis, la seule bonne raison pour utiliser l'a incorporé le soutien de double-buffering sera obligé à utiliser GrayDbufToggleSync () faire les graphiques regardent parfois un petit plus agréable (bien que la plupart du temps vous ne remarquerez pas n'importe quel « les effets de déformation »). Quelques jeux aiment votre jeu de fzero, cependant, gagnera beaucoup plus de quelques-uns extra-fps.

---

I am fairly certain that the strange flashing on VTI you described is not due to the TIGCC double-buffering. I tried holding a key down in one of the menues of Ice Hockey (which does not use the TIGCC double-buffering) and I experience the same flashing glitch. This makes me think that this has to be a glitch with VTI.

>>I will try to use FastCopyScreen instead and code my own double buffering system.
If you would like examples of programs which use this approach, check the source of Ice Hockey and Excitebike (not trying to advertise or anything)

>>will the fastcopyscreen method make an improvement to the fps ?
I know that it definitely would if you were switching from using GrayDbufToggleSync () to FastCopyScreen's, but I think that it would only be a very small gain changing from GrayDbufToggle (). In my opinion, the only good reason to use the built in double-buffering support is to use GrayDbufToggleSync () to make the graphics sometimes look a little nicer (although most of the time you won't notice any "distortion effects"). Some games like your fzero game, however, will gain a lot more from a few extra fps.
Bah
    
./Post n°7   Marquer comme non lu.
Lionel Debroux Ecrit le: Lundi 16 août 2004 à 10:17 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

Doublebuffering makes graphics better, but it's a major speed waster on HW1. The waste is reduced by using an interrupt-based game (which will also make the framerate more constant and hardware-independent), like you did.

Isn't this flicker when pressing keys related to AI2 ?
Lionel Debroux - membre de TICT.
    
./Post n°8   Marquer comme non lu.
Fisch2 Ecrit le: Lundi 16 août 2004 à 15:41 Déconnecté(e)    Voir le profil de Fisch2 Envoyer un email à Fisch2 Envoyer un message privé à Fisch2  

>>Doublebuffering makes graphics better
Yes, but since he was only using GrayDbufToggle(), the graphics will be no less synchronized when switching to FastCopyScreen_R's.

Oui, mais puisque il utilisait seulement GrayDbufToggle (), les graphiques seront aucun a synchronisé moins en changeant à FastCopyScreen_R.
Bah
    
./Post n°9   Marquer comme non lu.
LionelA Ecrit le: Lundi 16 août 2004 à 16:24 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Pour ce qui est de l'AI2, j'ai essayé en redirigeant et ca continue a faire l'effet bizarre.
Sinon FastCopyScreen_R fait baisser le fps dans f-zero quand il remplace GrayDBufToggle donc je laisserai le double buffering sans synchro...

Even if you set AI2 to a dummy handler, the bizar effect still appears.
In f-zero I tried to replace GrayDbufToggle by the FastCopyScreen method and it results in a fps decreasing so I'll keep tigcc double buffer without synchro...
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°10   Marquer comme non lu.
Lionel Debroux Ecrit le: Mardi 17 août 2004 à 10:03 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

> Pour ce qui est de l'AI2, j'ai essayé en redirigeant et ca continue a faire l'effet bizarre.
OK.
> In f-zero I tried to replace GrayDbufToggle by the FastCopyScreen_R method and it results in a fps decrease
That's natural, I guess you have a HW2 calculator. HW2 grayscale routines are more optimized from the copy point of view than FastCopyScreen_R. Not because of the algorithm (which is similar and leads to similar speed), but because FastCopyScreen_R copies two complete planes (2*LCD_SIZE), while the grayscale routines copy planes by thirds (LCD_SIZE/3) only when it is necessary.
Lionel Debroux - membre de TICT.
    
./Post n°11   Marquer comme non lu.
Kevin Kofler Ecrit le: Mercredi 18 août 2004 à 22:14 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  


But waiting for the grayscale routine to synchronize takes very long.
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 » grayscale bug ? (11 réponse(s))
Pages : 1/1     « [1] » »|

.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 54.85ms avec 18 requetes