Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
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

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

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

Membre: Visiteur

Messages: 27

Membre n°46

Inscrit le 10 février 2004

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

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

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 ?

./Post n°3 Marquer comme non lu.

geogeo

Ecrit le: Dimanche 15 août 2004 à 20:49

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

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

Membre: Maître Ultime

Groupe: Omega staff

Messages: 1156

Membre n°91

Inscrit le 09 mars 2004

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

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

ben non ! mais qu'il le soit ou pas c'est le même effet

./Post n°6 Marquer comme non lu.

Fisch2

Ecrit le: Dimanche 15 août 2004 à 21:52

Membre: Visiteur

Messages: 27

Membre n°46

Inscrit le 10 février 2004

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

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

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

Membre: Visiteur

Messages: 27

Membre n°46

Inscrit le 10 février 2004

>>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

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

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...

./Post n°10 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mardi 17 août 2004 à 10:03

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> 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

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

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!