Grx November 2011

grx@gnu.de

5 participants
6 discussions

How to use "mouse wheel" in GRX
by jhliu 08 Dec '11

08 Dec '11

Dear Sir, Thanks for GRX provides lot of powerful and useful mouse event handling functions, But it seems to does not support using of the “mouse wheel”. Is there any alternate method to enable the mouse wheel in GRX ? Thanks in advanced. Regards, JH

2 3

Re: GRX, gpc version 20060325, based on gcc-3.4.4 demo programs for problem
by Maurice Lombardi 21 Nov '11

21 Nov '11

Le 19/11/2011 21:43, T.D. Telford a écrit : > Hello, > > The patch worked fine on the demo programs, and on the chess program > that I am converting. > > A question on a different subject: The chess program reads the chess > piece images by using GetImage, where the images were created under > turbo pascal. I get a segment violation when I try to read these images > on gpc/grx. I suspect that the header information for the image created > by turbo pascal is not compatible with the grx image header information. > > Do you know how these turbo pascal images could be read? No. I have only the sources of the BP RTL, but apparently they do not contain sources of the BGI system. May be somebody reading this list ? Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 4

Re: GRX, gpc version 20060325, based on gcc-3.4.4 demo programs for problem
by Maurice Lombardi 19 Nov '11

19 Nov '11

Le 17/11/2011 20:40, T.D. Telford a écrit : > Thank you for the reply. I have attached 2 programs. > > The first, diagonal.pas, draws a line diagonal, but it is not completely > drawn. If you uncomment the code to draw the second diagonal, then the > first diagonal is completely drawn, while the second one is not complete. > > The second program, circle.pas, draws a filled circle. Then getImage and > putImage are used to draw a second filled circle. The second circle is > not displayed. If you uncomment the code to draw the third filled > circle, then the second circle is displayed, but not the third. > > I have had the same problem with writing text to the graphics window. > The last part of the text is not displayed. If I write some additional > text (in the background color), then all of the original text is displayed. > > I am using grx 2.4.8 on a linux fedora 15 x86_64 system, gpc version > 20060325, based on gcc-3.4.4 (which I compiled). > Please apply to grx 2.4.8 the attached patch which defines a GrFlush procedure and recompile grx. It solves the problem for your two demo programs in x11 if you add GrFlush just before the final readln. Try on your other programs. For other systems the function is defined to keep compatibility, but dummy, because I have found that your demo programs do not need it. Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Re: GRX, gpc version 20060325, based on gcc-3.4.4 questions
by Maurice Lombardi 15 Nov '11

15 Nov '11

Le 14/11/2011 03:58, T.D. Telford a écrit : > I appreciate the test programs with grx, since the gpc documentation is > not great. > > Using grx, it appears that there is a flush problem, since the last item > to be displayed is not displayed. If a dummy item to be displayed is > executed, then the previous item is displayed. This seems to be true for > both text and graphical shapes. This is for bgi calls. ??? could you provide an example ? > My console programs use black text on a light yellow background. When I > run the bgi type programs, I get a graphics window and a console window, > with the latter having a black background and a light gray text, which > is not easy to read. Any suggestions? grx works mainly on the graphics window. It can simply restore the focus on the console window with RestoreCrtMode. To have full control of the console window you should use the crt unit. Please experiment with the attached testBGI program which uses both graph and crt. Parameters are for a mingw compiler, but it works also on DJGPP and on Linux X11 Basically it writes equivalents things with corresponding foreground and background colors, first in the graphics window, then in the console window. If you uncomment the RestoreCrtMode instruction in the middle, the window switches between graphics and console. Otherwise both windows are simultaneously visible. Please note the differences in writing the displayed parameters, using equivalent functions in both units. In addition: - Colors are prefixed with graph. and crt. to disambiguate, because both exist with the same name in both units. - In the console window background color turns from yellow to brown because the crt background color is limited to the first eight colors: this is to reproduce original BP BGI behavior. Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 2

Re: GRX 2.4.8 yield patch
by Maurice Lombardi 12 Nov '11

12 Nov '11

Le 10/11/2011 22:12, borg(a)uu3.net a écrit : > First, please redownload the patch. > I added GrYield() in places you montioned long time ago. > (diff later in email). > > Okey, I will try to write small program to demostrate issue > when I will find some time. Not easy tho, because zeth > worked fine from time to time, and then had lag.. This is all > about race conditions here and there. > > % git diff HEAD^^^ HEAD^^ > diff --git a/src/mouse/w32keys.c b/src/mouse/w32keys.c > index 55ab4ee..9013cb2 100644 > --- a/src/mouse/w32keys.c > +++ b/src/mouse/w32keys.c > @@ -37,8 +37,10 @@ GrKeyType GrKeyRead(void) > int i, key; > > if (!_GrIsKbdEnabled()) { > - while (_nkeysw32pool< 1) > + while (_nkeysw32pool< 1) { > + GrYield(); > _GrUpdateInputs(); > + } > key = _keysw32pool[0]; > for (i = 0; i< _nkeysw32pool; i++) > _keysw32pool[i] = _keysw32pool[i + 1]; > @@ -51,6 +53,7 @@ GrKeyType GrKeyRead(void) > GrMouseEventEnable(1, 0); > } > for (;;) { > + GrYield(); > GrMouseGetEvent((GR_M_EVENT | GR_M_NOPAINT),&ev); > if (ev.flags& GR_M_KEYPRESS) { > return (ev.key); > OK adding this patch make the test programs which wait on GrKeyRead(), GrKeypressed() to work without any change. Exception is mousetst which waits for mouse events. But the correct behaviour is restored by replacing GrGetEventT and GrSleep in the waiting loop by GrGetEvent (without T i.e. no tempo) and GrYield, which is more consistent with your point of view. I would still be more convinced to introduce those inconsistent changes (needing changes in user's programs) if you could provide a test program which would enable a better justification for these changes. In fact I am convinced that there do are problems due to race conditions, because I see that a series of programs of mine which use the same graphical output module based on grx sometimes miss a refreshing of the screen with a new graphics, while running still correctly underneath, even printing correctly the new graphics. But this is not corrected by your changes, and I have not found the point until now. Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Re: GRX 2.4.8 yield patch
by Maurice Lombardi 08 Nov '11

08 Nov '11

Le 02/11/2011 19:13, borg(a)uu3.net a écrit : > YES! and thats what exacly im speaking about. > Honestly, GrMouseGetEventT() is quite fuzzy. > It is called in interfactive applications quite many times > and this exacly leads to problem im describing, because > GrMouseGetEventT() and _GrUpdateInputs() try to sleep > where they shouldnt, because they dont have idea what application > is actualy doing. Thats why GrYield() pops in, to handle > sleep where there is really no stuff to do (apps want to sleep and > GRX library have empty queue too). > > As speaking about painter issue, its simple. > WM_PAINT is called when any changes need to be repainted > and actual repain is done in Window Message thread. > Its pefectly ok, however, on SMP systems it is possible > that each thread runs on different CPU, so in fact they run > concurently. This means that WM_PAINT worker read from changeable > memory, and this leave artifacts on screen im speakng about. > > I tried to make those calls in sync with each other, but failed. > Either I had lag or excessive CPU usage that is not acceptable too. > > I added InvalidateRect(hGRXWnd,0,0) in GrYield() when there is no > stuff to do (app want to sleep and GRX queue is empty) > This little hack fixed it pefectly. No CPU load and no lag. The problem for me is that I have no example to be sure of what you say. I have tried to run several of my own programs, as well as the grx test programs, either with grx248 (with all patches contained in the "more things" section) and after appliying to it your patch, while looking to the task manager to see CPUs load. I first supposed that I had found the problem when seeing that in the test program compiled with your patch, but with no introduction of GrYield() in the calling program, the CPU load remained high when waiting for an input. When changing the wait instructions (GrReadkey() or a GrKeyPressed() loop usually in the test programs) to introduce a waiting loop with a GrYield() inside, it remained high, but when modifying GrYield() with your InvalidateRect() instruction above, the CPU load disappears. However when compiling with the original patched grx248, there is no CPU load when waiting in the original test programs (nor in my own programs which use more complex loops to catch both keyboard and mouse inputs). Running step by step with a gdb debugger (in fact insight, which is a graphics interfacing of gdb) I found that the problem came for the suppressing of the Sleep(1) instruction within DequeueW32Event(), which is there to enable to yield, seen as a refreshing of the graphics when it had been overwritten by moving an other window above it. I summary, can you provide to me a working minimal example program, may be based on one of the test programs, which displays your problems. Maurice BTW in my own programs I use GrMouseGetEvent without T, i.e. without tempo, in the waiting loop. -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

Grx November 2011