Grx

grx@gnu.de

559 discussions

SDL driver progress & proposition
by Dimitar Zhekov 10 Feb '04

10 Feb '04

Hi. As of today: - GrMouseDetect() always succeeds. Well, not a show stopper if you ask me. - SDL key to GRX key translation has been completed, non-US languages are supported. - mp->lineoffset, ep->frame and (fullscreen only) ep->cpos and ep->cpres are set in setmode; that's OK. - 8/15/16/24/32bpp are supported in fullscreen mode; only the desktop depth is supported in windowed mode. - windowed modes are supported; an arbitary resolution windowed mode is not implemented yet. - pressing the switch language key combination under does the switch and doesn't hang the application. --- Under Win~1, the windowed drivers are much slower than the native windows driver. The fullscreen drivers are very fast, of course, they're LFB. The native Win~1 drived doesn't buffer the keys pressed if not waiting for an event. The Win~1 SDL driver does. --- My current proposition is to create a set of sdl-win~1 makefiles and include them as windows fullscreen GRX varianth with a SYSTAG of 8. RFC. The Win~1 windowed modes always have window decorations. If we agree on the above proposition, I'll add some __WIN32__ specific decoration-handling code. My next plans are to test the SDL driver under X11. It will be slower than the XWIN driver (which has no back- buffering), but the speed may be acceptable to replace it. It'll be interesting to see if the fullscreen modes have the well-known DGA problems or not. RFC. P.S. the speedtst batch mode has been extended a bit. -- E-gards: Jimmy

1 0

Re: SDL support (beta) [RFC]
by Josu Onandia 09 Feb '04

09 Feb '04

Hi, Nice work, Dimitar! As you have requested comments, here is mine: >>- only fullscreen LFB modes are supported. As of me, GRX >>in a window is abomination. I don't make a complete application, but an OCX control that is inserted in a window as part of the application. You'll understand that I absolutely NEED grx in a window. Under Linux I use the LFB driver (here in full-screen mode), and the performance is a concern for me bacause is an embedded product with little CPU power. Do you think that the SDL driver could affect performance? Best regards, Josu Onandia

2 1

Shared libraries for GRX under Windows
by Demmer, Thomas 09 Feb '04

09 Feb '04

Hi all, I have revised and slightly rewritten the DLL-support for GRX. The main trick for making the DLL and the import-lib is the option gcc -shared -Wl,--export-all -Wl,--out-implib= libgrx.dll.a -o GRX.dll $(ALL_O) $(ADDON_LIBS) and linking the application against libgrx.dll.a Linking an application directly against the DLL is currently not possible because constructs like struct foo * const FooInfo = &_FooInfo; struct foo _FooInfo = { ... }; Accessing _FooInfo in the DLL works OK, but FooInfo poins to some distant stars. To fix this one would need dllimport/dllexport decorations for FooInfo that clutter up the source code. For other changes see the changelog below. Ths systag naming conflicts with Dimitar's patches from friday :-( Ciao Tom <<thdgrx.zip>> * include/grx20.h: Added define for __CYGWIN32__ and removed the old equality __CYGWIN32__ is also __WIN32__. This is required to have the X11 driver in cygwin. * makedefs.grx: Added systags for CYGWIN and MinGW with CYGWIN compiler. * src/fdriver/ftable.c: Added "ifdef" for native driver in Cygwin * src/include/grxdebug.h: Is __GNUC__ stil in use for any gcc? Added __CYGWIN32__ and __MINGW32__, but another test may make more sense. * src/utils/dbgprint.c: dito * src/mouse/input.h : Replaced __WIN32__ by __WIN32__||W32NATIVE_DRIVER * src/vdrivers/vtable.c: Replaced __WIN32__ by __WIN32__||W32NATIVE_DRIVER * src/vdrivers/vd_win32.c: Revised reset(). Neiter PostMessage, nor PostThreadMessage could convince the windowThread to terminate. TerminateThread() does. Not elegant, but effecient. Made windowThread static. * src/include/libwin32.h: Removed windowThread. * test/demogrx.c: Added C32 for version=...386_CYG32 * test/speedtst.c: Removed inclusion of <values.h> because it prevailed compilation under Cygwin and file is empty for the MinGW compiler. * test/keys.c: Also the W32 windows drivers need a graphics mode to initialize keyboard and mous functions. TODO: Move Library names to makedefs.grx. Best regards / Mit freundlichen Grüssen, Thomas Demmer Kraft Foods R&D Inc. Chocolate WW Process Development Tel.: +49 (0)89 62738-6302 Fax: +49 (0)89 62738-86302 Thought of the day People who claim they don't let little things bother them have never slept in a room with a single mosquito.

1 0

SDL support (beta) [RFC]
by Dimitar Zhekov 07 Feb '04

07 Feb '04

Hi. If somebody still doesn't beleive that the software lives it's own life, here is a proof. What I started as Windows DirectDraw driver became an any-OS SDL driver... It's mainly finished, with the following exceptions: - GrMouseDetect() always succeeds. If you know how to query mouse existence under SDL, please assist. - SDL key to GRX key translation may be incomplete or slightly incorrect. - mp->lineoffset is initialized in setmode() instead of build_video_mode() - is this a problem? - only the current desktop depth is supported (8, 15, 16, 24 and 32L/32H bpp). I'll fix this. - only fullscreen LFB modes are supported. As of me, GRX in a window is abomination. - pressing the switch language key combination under Win~1 blocks the application! Please assist. The makefiles are currently "multi OS" set up to build under Win~1 (rm -f required), but should work under Linux as well (not tested). IMHO, we should replace the Win~1, X11 and Linux drivers with SDL fullscreen and (sigh) SDL windowed. RFC. When we reach an agreement, I'll rewrite the makefiles etc. P.S. converted test/keys.c into a standard test program. -- E-gards: Jimmy

2 1

pre-alpha DirectDraw driver
by Dimitar Zhekov 02 Feb '04

02 Feb '04

Hi. A very raw-pre-alpha of the DirectDraw driver is ready. Supports 15+ bpp. Doesn't support 8bpp and DirectInput. Hope to finish it this week. Not worth a .diff yet. -- E-gards: Jimmy

1 0

win32 setmode() clear screen problem?
by Dimitar Zhekov 30 Jan '04

30 Jan '04

Hi. The following code: #include <grx20.h> int main(void) { GrLoadFont("d:/media/grx247p1/fonts/char30b.fnt"); GrSetMode(GR_width_height_bpp_graphics, 640, 480, 8); Sleep(1000); return (0); } at least when run in 16/32bpp, results in a green screen (or window, depending in the resolution) on my system. I had this issue with fontdemo; both work properly [black screen/window] without the GrLoadFont() call. The problem seems to be with vd_win32.c:setmode(). It creates an 8bpp DIB and then uses a solid color 0 brush to clear it. But while the chances are color 0 (in 8bpp) will be RGB 0, that's not granted. Shortly after init the GRX window is updated, the DIB is copied into it, and so it's filled with some non-black color (usually a nice one, I must admit :-) Now, I fixed this by setting the DIB color index 0 to 0, and to be 101% sure, used a BitBlt(hDC, hDCMem) instead of FillRect() to initially clear the GRX window in 8bpp. It doesn't seem to matter, as the GRX window is updated (almost) immediately, and thus fixing the DIB color 0 is enough. Even removing BitBlt() and FillRect(hDC) makes no visual difference for what I've tested. But anyway... -- E-gards: Jimmy

1 0

Testing GRX
by Peter Williams 24 Jan '04

24 Jan '04

Hello I have just begun trying to use GRX. I can compile everything OK using Djgpp. However I am having difficulty running the test programs demogrx and bccbgi on my Windows XP and W2000 machines. I have read the very useful information given in the correspondence by Toby Ewing #185 and Mariano Fernandez #351. I have tied setting SET GRX20DRV = STDVGA then running demogrx 640 480 4. This works fine on my XP machine. But not on my W2000 laptop. The bgi test program does not work on either XP or W2000. Should it not be modified to take command line arguments for its parameters like demogrx? Although, this would not help for the W2000 laptop, I suspect. -- Pete Williams peter.williams173(a)ntlworld.com

5 5

Some patches to build GRX2.4.6 under Cygwin
by Demmer, Thomas 23 Jan '04

23 Jan '04

Hi all, I have hacked some Makefiles so that GRX builds cleanly under Cygwin. The attached patch does the following: ./makedefs.grx: * Add WIN32_GCC_i386_CYGWIN (cygwin native) and WIN_GCC_i386_CYGMING (MinGW) as systags 007 and 008. 008 really is 006, just using the Cygwin environment to build a MinGW target. * Appended a CYGMING specific section Added makefile.cyg in ./, ./src, ./test/bgi and ./test. The system then creates the static and shared libraries. Cygwin specific if CC = gcc MinGW version if you say CC = gcc -mno-cygwin in makedefs.grx Default installation path for the static libraries is /usr/local/lib/[mingw] for the header files /usr/local/include/grx20 The DLLs do not get installed, as I have no clue where to install them :-) The cygwin one should probably go to /bin. I set default font-path to "/usr/local/lib/fonts/grx", you may want to change this to your needs. Further minor fixes: test/demogrx.c: * Added test for Cygwin in the_info(). BTW, is there a reason for not having this as switch( GrGetLibrarySystem() ){ ... }? * Small workaround for spawning the test programs. in pev_command(), mostly "\" vs. "/" related. The real error is in grx20.h, where "__WIN32__" gets defined if the compiler is cygwin. This is not a good idea and prevails building an X11 version with cygwin at the moment. I think I have stupidly introduced that myself :-) I am currently thinking about how to fix that, and what a fix really is. It basically should be possible to build a library that uses the native drivers or the X11 drivers, depending if the DISPLAY variable is set (just like rxvt under Cygwin). Any ideas and comments are appreciated :-) Other than that, the only program that thoroughly fails so far is keys.exe, I have not yet tried to actually *use* the DLLs, so be warned :-) Have fun, Ciao Tom <<grx246_ptd1.pat.gz>> Best regards / Mit freundlichen Grüssen, Thomas Demmer Kraft Foods R&D Inc. Tel.: +49 (0)89 62738-6302 Fax: +49 (0)89 62738-86302 mailto:tdemmer@krafteurope.com <mailto:> Thought of the day Love at first sight is one of the greatest labor-saving devices the world has ever seen.

1 0

fontdemo -Y fix
by Dimitar Zhekov 16 Jan '04

16 Jan '04

Obvious typo. -- E-gards: Jimmy

1 0

[PATCH] grx246: Fix for unresolved references using graphresult() from C++
by Andris Pavenis 08 Jan '04

08 Jan '04

After upgrade to grx-2.4.6 found that using graphresult() from C++ programm causes unresolved references. Moving actual check to __gr_graphresult() and changing graphresult() to call __gr_graphresult() fixes problem. Checked now for Linux X11 build only Andris --- grx246/src/bgi/graphres.c~1 2001-01-12 19:35:12.000000000 +0200 +++ grx246/src/bgi/graphres.c 2004-01-08 12:19:42.000000000 +0200 @@ -25,5 +25,7 @@ #include "bccgrx00.h" int __gr_graphresult(void) { - return graphresult(); + int res = (__gr_INIT ? __gr_Result : grNoInitGraph); + __gr_Result = grOk; + return res; } --- grx246/include/libbcc.h~1 2002-07-30 00:33:46.000000000 +0300 +++ grx246/include/libbcc.h 2004-01-08 12:22:31.000000000 +0200 @@ -557,7 +557,7 @@ int getvisualpage(void); #define getmaxmode() (__gr_set_up_modes(), __gr_MaxMode) #define getmoderange(gd, lomode, himode) \ __gr_getmoderange((gd),(lomode),(himode)) -/* graphresult() uses local variable res */ +#define graphresult() __gr_graphresult() #define getx() (__gr_X+0) #define gety() (__gr_Y+0) #define moveto(x, y) do { __gr_X = (x); __gr_Y = (y); } while(0) @@ -638,9 +638,7 @@ void (getmoderange)(int gd, int *lomode, /* ----------------------------------------------------------------- */ int (graphresult)(void) { - int res = (__gr_INIT ? __gr_Result : grNoInitGraph); - __gr_Result = grOk; - return res; + return __gr_graphresult(); } /* ----------------------------------------------------------------- */

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
56
Older →

Jump to page:

2025

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