Grx

grx@gnu.de

559 discussions

Re: problem compiling GRX 2.4
by Norberto Alfredo Bensa 10 Apr '01

10 Apr '01

This is weird... I changed the line back to read like the original file found in the grx24s.zip package, and it compiles with no complains. So I suspect an 'invisible' char in that line that was confusing gcc. Viewing the original file through a hex viewer didn't show anything. Then I unzipped and recompiled the original package again... everything went ok. I don't know what to say... I feel so dumb... Best regards, Norberto

1 0

Re: problem compiling GRX 2.4
by Mariano Alvarez Fernandez 10 Apr '01

10 Apr '01

Norberto Alfredo Bensa escribió: > Hello, > > I got an 'unterminated character constant' error while compiling GRX 2.4, > but I can see the problem (!). I'm using gcc 2.95.3. Any clues? (I recall > compiling GRX 2.3.4 with no problem under gcc 2.95.2) > > Thanks in advance, > Norberto > > % make -f makefile.dj2 > c:/djgpp/bin/make.exe -C src -f makefile.dj2 > make.exe[1]: Entering directory `e:/djgpp/contrib/grx24/src' > gcc -c -O6 -Wall -fomit-frame-pointer -I. -I./include -I../include -I../addo > ns/print -I../addons/bmp pnm/ctx2pnm.c -o pnm/ctx2pnm.o > pnm/ctx2pnm.c:180: unterminated character constant > make.exe[1]: *** [pnm/ctx2pnm.o] Error 1 > make.exe[1]: Leaving directory `e:/djgpp/contrib/grx24/src' > make.exe: *** [libs] Error 2 This is the offending line: if( c == '#' ) // it's a comment I don't know if it must be '\#' or it is a gcc 2.95.3 bug, Andris?

2 1

Clearing out GCC code
by Hartmut Schirmer 09 Apr '01

09 Apr '01

Hi, while trying to get the WIN32 port running, MS-VC++ pointed out several problems with the GRX code, mostly in the BGI part. See attached patch. Hartmut PS: I gave up, couldn't get DJGPP-make passing long command lines to MS link

2 3

Compile GRX with Mingw
by Mariano Alvarez Fernandez 08 Apr '01

08 Apr '01

Hi. These is a how-to for people who want to make the GRX win32 version, but don't know about the mingw compiler: 1.- First, download the mingw distribution: ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2/ gcc-2.95.2-msvcrt.exe ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2/ mingw32-docs-html.exe ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2/fixes/ quote-fix-msvcrt.exe 2.- Create a \MINGW dir and decompress the three files on it (The files are not instalers, only auto-decompress files) 3.- Create a \MINGW\SETVAR.BAT file with the line: SET PATH=C:\MINGW\BIN;%PATH% 4.- Open a DOS window and execute \MINGW\SETVAR 5.- Go to the dir you have the GRX 2.4 distribution. Go to the src subdir and execute "make -f makefile.w32" Go to the test subdir and execute "make -f makefile.w32" Go to the test\bgi subdir and execute "make -f makefile.w32" Hope this help, M.Alvarez

1 0

Fwd: Re: -O2 versus -O3
by Hartmut Schirmer 08 Apr '01

08 Apr '01

Hmm, returned. 2nd try ---------- Forwarded Message ---------- Subject: Re: -O2 versus -O3 Date: Tue, 27 Mar 2001 19:08:35 +0200 From: Hartmut Schirmer <hartmut.schirmer(a)arcormail.de> On Mon, 26 Mar 2001, Maurice Lombardi wrote: > [...] >Hope this helps > Not really. On first view everything looks as expected. Could you try and set the realmode banking ? This can be done using the environment and appending ::r (?) after the driver specs, IIRC. Hartmut

3 5

-O2 versus -O3
by Mariano Alvarez Fernandez 26 Mar '01

26 Mar '01

Hi These are benchmarks with a selected videomodes group on DOS: using -O2 Graphics driver: "VESA" Driver readp drawp line hline vline block v2v v2r r2v LFB8 640x 480 1.47 1.52 1.88 6.64 1.69 6.63 2.85 7.13 6.65 LFB8 800x 600 1.40 1.52 1.87 6.65 1.67 6.64 2.87 7.27 6.65 LFB8 1024x 768 1.40 1.49 1.87 6.67 1.68 6.67 2.87 7.21 6.68 LFB16 640x 480 1.40 1.46 1.85 3.37 1.67 3.36 1.50 3.98 3.36 LFB16 800x 600 1.40 1.46 1.84 3.34 1.64 3.34 1.50 3.98 3.34 LFB16 1024x 768 1.33 1.44 1.82 3.32 1.62 3.32 1.49 3.93 3.31 LFB24 640x 480 1.17 0.79 0.87 2.21 0.79 2.21 0.94 2.38 2.21 LFB24 800x 600 1.17 0.79 0.86 2.21 0.78 2.20 0.95 2.40 2.20 LFB24 1024x 768 1.17 0.78 0.85 2.18 0.77 2.17 0.94 2.38 2.17 RAM8 640x 480 7.00 6.79 16.34 161.54 9.28 236.21 143.64 0.00 0.00 RAM8 800x 600 5.60 6.22 16.67 212.66 9.17 246.14 148.97 0.00 0.00 RAM8 1024x 768 5.60 6.22 12.92 196.87 7.10 165.46 106.94 0.00 0.00 RAM16 640x 480 7.00 6.22 14.89 121.15 8.44 121.13 71.82 0.00 0.00 RAM16 800x 600 7.00 6.22 12.50 91.14 7.11 85.61 54.17 0.00 0.00 RAM16 1024x 768 7.00 6.22 10.09 65.62 5.49 58.98 44.51 0.00 0.00 RAM24 640x 480 5.60 5.74 9.21 53.85 6.79 61.35 36.32 0.00 0.00 RAM24 800x 600 5.60 5.33 8.12 45.57 5.81 47.16 31.18 0.00 0.00 RAM24 1024x 768 5.60 5.74 7.19 41.45 5.24 40.06 28.69 0.00 0.00 using -O6 -fomit--frame-pointer Graphics driver: "VESA" Driver readp drawp line hline vline block v2v v2r r2v LFB8 640x 480 1.40 1.59 1.88 6.64 1.68 6.63 2.85 7.13 6.64 LFB8 800x 600 1.47 1.59 1.87 6.65 1.68 6.64 2.87 7.27 6.65 LFB8 1024x 768 1.47 1.59 1.87 6.67 1.67 6.67 2.87 7.20 6.67 LFB16 640x 480 1.40 1.46 1.85 3.37 1.67 3.36 1.50 3.99 3.36 LFB16 800x 600 1.40 1.46 1.84 3.36 1.65 3.34 1.50 3.99 3.34 LFB16 1024x 768 1.40 1.44 1.83 3.32 1.63 3.32 1.49 3.93 3.31 LFB24 640x 480 1.22 0.77 0.88 2.22 0.79 2.21 0.94 2.38 2.21 LFB24 800x 600 1.17 0.76 0.87 2.21 0.78 2.20 0.95 2.40 2.20 LFB24 1024x 768 1.17 0.75 0.85 2.18 0.77 2.17 0.94 2.38 2.17 RAM8 640x 480 7.00 7.46 16.34 161.54 9.28 236.21 143.64 0.00 0.00 RAM8 800x 600 7.00 6.79 16.25 212.66 9.41 238.68 144.94 0.00 0.00 RAM8 1024x 768 5.60 6.79 12.92 157.50 7.21 165.46 106.94 0.00 0.00 RAM16 640x 480 9.33 6.79 14.89 121.15 8.44 121.13 73.49 0.00 0.00 RAM16 800x 600 9.33 6.22 12.74 79.75 7.11 85.61 53.63 0.00 0.00 RAM16 1024x 768 7.00 6.22 10.09 65.62 5.43 59.26 44.51 0.00 0.00 RAM24 640x 480 5.60 6.22 9.93 60.58 6.63 62.16 36.32 0.00 0.00 RAM24 800x 600 5.60 5.74 8.90 45.57 5.90 47.45 31.18 0.00 0.00 RAM24 1024x 768 5.60 5.33 7.95 41.45 5.36 40.19 28.69 0.00 0.00 The differences are very small, so I think we can use -O2 by default. Incidentally, speedtst crash my computer using the Vesa driver in 16 color. Can any body confirms that? I suspect there is a bug in the framedriver. M.Alvarez

3 4

GrMouseGetEventT problem in linux
by Mariano Alvarez Fernandez 25 Mar '01

25 Mar '01

Hi In the svgalib driver, GrMouseGetEventT doesn't set the ev->dtime correctly. The problem is that CLOCKS_PER_SEC reports 1000000 !! despite it is 100 really. This extract is from /usr/include/bits/time.h: -------------------- /* ISO/IEC 9899:1990 7.12.1: <time.h> The macro `CLOCKS_PER_SEC' is the number per second of the value returned by the `clock' function. */ /* CAE XSH, Issue 4, Version 2: <time.h> The value of CLOCKS_PER_SEC is required to be 1 million on all XSI-conformant systems. */ # define CLOCKS_PER_SEC 1000000 # ifndef __STRICT_ANSI__ /* Even though CLOCKS_PER_SEC has such a strange value CLK_TCK presents the real value for clock ticks per second for the system. */ # define CLK_TCK 100 # endif -------------------- The workarround is to use CLK_TCK instead of CLOCKS_PER_SEC, but really I don't understand the issue (why sets linux an incorrect value for it?)

1 0

GRX-2.4 and gcc-3.0 20010314 (prerelease)
by pavenis＠lanet.lv 22 Mar '01

22 Mar '01

Tried to build grx-2.4 for DJGPP using gcc-3.0 20010314. After modifying src/bgi/text7.c (gcc-3.0 20010314 miscompiles it with -O3 -fomit-frame-pointer) to workaround problem, all seems to work. Some comments about results. It seems that it's better to check for __DJGPP__ instead of __GO32__ (I don't know about DJGPP v1, but we're removing support for it anyway). See patch. gcc-3.0 20010314 miscompiles src/bgi/text7 with '-O3 -fomit-frame-pointer' . Do we really need to use -O6 -fomit--frame-pointer to build optimized library? How much we're getting from that? Maybe it would be enough to use simply -O2? I sent bug report about this problem to gcc-bugs mailing list. grx24/makedefs contains definition of default font path (fortunatelly commented out ...) : strcat(getenv(\"DJDIR\"),\"/contrib/grx24/fonts\") which modifies value returned bu getenv() (but it must not be modified). Andris --- grx24/include/grx20.h~1 Sat Mar 10 19:18:50 2001 +++ grx24/include/grx20.h Sat Mar 17 13:55:10 2001 @@ -51,7 +51,7 @@ #endif #ifdef __GNUC__ -#ifdef __GO32__ +#ifdef __DJGPP__ #define GRX_VERSION GRX_VERSION_GCC_386_GO32 #endif #if defined(__linux__) && defined(__i386__) @@ -1468,7 +1468,7 @@ int kbhit(void); int getch(void); #endif -#ifndef __GO32__ +#ifndef __DJGPP__ int getkey(void); int getxkey(void); #endif --- grx24/src/fdrivers/svga16.c~1 Mon Nov 6 00:42:22 2000 +++ grx24/src/fdrivers/svga16.c Sat Mar 17 13:55:58 2001 @@ -153,7 +153,7 @@ } -#if !defined(__WATCOMC__) && (defined(__GO32__) || defined(__TURBOC__)) +#if !defined(__WATCOMC__) && (defined(__DJGPP__) || defined(__TURBOC__)) /* The VGA banked frame buffer must start on a 64k boundary ** for this optimized assembler code. ** Linux: mmap may place the frame buffer on a 4k boundary :( --- grx24/src/fdrivers/svga8.c~1 Mon Nov 6 00:43:14 2000 +++ grx24/src/fdrivers/svga8.c Sat Mar 17 13:57:24 2001 @@ -154,7 +154,7 @@ } -#if !defined(__WATCOMC__) && (defined(__GO32__) || defined(__TURBOC__)) +#if !defined(__WATCOMC__) && (defined(__DJGPP__) || defined(__TURBOC__)) /* The VGA banked frame buffer must start on a 64k boundary ** for this optimized assembler code. ** Linux: mmap may place the frame buffer on a 4k boundary :( --- grx24/src/mouse/input.h~1 Fri Mar 2 20:32:16 2001 +++ grx24/src/mouse/input.h Sat Mar 17 13:52:28 2001 @@ -98,7 +98,7 @@ #define MS_PER_TICK 55 #endif -#ifdef __GO32__ +#ifdef __DJGPP__ #define user_time(tv) do { \ setup_far_selector(LINP_SEL(0x0000046c)); \ (tv) = peek_l_f(LINP_PTR(0x0000046c)); \ --- grx24/src/mouse/dosinput.c~1 Sat Mar 17 13:59:06 2001 +++ grx24/src/mouse/dosinput.c Sat Mar 17 13:59:24 2001 @@ -22,7 +22,7 @@ #include <conio.h> #endif -#ifdef __GO32__ +#ifdef __DJGPP__ #include <pc.h> #endif --- grx24/src/mouse/doskeys.c~1 Mon Nov 6 00:46:22 2000 +++ grx24/src/mouse/doskeys.c Sat Mar 17 13:59:40 2001 @@ -24,7 +24,7 @@ #include "int86.h" #include "memfill.h" -#ifdef __GO32__ +#ifdef __DJGPP__ #include <pc.h> #endif --- grx24/src/bgi/palette.c~1 Fri Jan 12 15:38:20 2001 +++ grx24/src/bgi/palette.c Sat Mar 17 14:00:10 2001 @@ -37,7 +37,7 @@ void __gr_setpalette(int colornum, int color) { -#ifdef __GO32__ +#ifdef __DJGPP__ # include <dpmi.h> # include <go32.h> _go32_dpmi_registers regs; --- grx24/test/keys.c~1 Sat Mar 10 18:12:58 2001 +++ grx24/test/keys.c Sat Mar 17 14:00:40 2001 @@ -39,7 +39,7 @@ /* ***************************************************************************/ #endif /* PENTIUM_CLOCK */ -#ifdef __GO32__ +#ifdef __DJGPP__ #include <conio.h> #include <pc.h> #endif --- grx24/test/linetest.c~1 Mon Jan 29 23:47:26 2001 +++ grx24/test/linetest.c Sat Mar 17 14:01:02 2001 @@ -18,7 +18,7 @@ **/ #include "test.h" -#ifdef __GO32__ +#ifdef __DJGPP__ #include <pc.h> #endif --- grx24/test/modetest.c~1 Sat Mar 10 17:58:42 2001 +++ grx24/test/modetest.c Sat Mar 17 14:01:24 2001 @@ -26,7 +26,7 @@ #include <conio.h> #endif -#ifdef __GO32__ +#ifdef __DJGPP__ #include <pc.h> #endif --- grx24/test/speedtst.c~1 Sat Mar 10 17:58:00 2001 +++ grx24/test/speedtst.c Sat Mar 17 14:01:42 2001 @@ -28,7 +28,7 @@ #else #include <values.h> #endif -#ifdef __GO32__ +#ifdef __DJGPP__ #include <conio.h> #include <pc.h> #endif

4 5

.
by FV21FV67＠YAHOO.COM 21 Mar '01

21 Mar '01

The Internet's Finest and Most Reliable Bulk Email Provider! Since 1996, Tech Data Technologies has provided bulk email service to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced, direct email technology, employed by only a knowledgeable few in the world. We have over 160 million active email addresses, increasing our list at the rate of half a million to one million a month. We will put your product or service instantly and directly into the hands of millions of prospects! You will have instant, guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state, city and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Call us for a free consultation at 323 876 6148 [U.S.A.]. For a limited time, take advantage of our special -- Three million general U.S. emails for just $600 per million! We include, at no cost, a bullet proof email address for 30 days, a $400 value! BULK EMAIL PRICES 750,000........................$562 1,200,000........................$720 1,600,000........................$960 3,000,000........................$1,500 3,000,000+ ...................PLEASE CALL FOR A QUOTE Best of ALL, Tech Data Services can be used as a 100% TAX WRITE OFF for your Business! DON'T WAIT! LET TECH DATA TECHNOLOGIES BE YOUR PARTNER!! Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below).To Remove Yourself From This List: Please email see2meu4(a)yahoo.com with the email address that you would like removed and the word REMOVE in the subject heading.

1 0

Combining and analyzing keyboard events
by Markus Gerwinski 18 Mar '01

18 Mar '01

Hello Folks! Some more questions about GRX in its GNU Pascal interface... AFAIK, every keyboard event in GRX is a single constant like e.g. GrKey_A for keys 'SHIFT' + 'a' GrKey_small_a for key 'a' without modifiers GrKey_Alt_A for keys 'ALT' + 'a' etc. Question: Is there an easy way to split a keyboard event into single key "events"? E.g. GrKey_A = GrKey_small_a + GR_KB_SHIFT GrKey_Alt_A = GrKey_small_a + GR_KB_ALT etc.? Yours Markus P.S.: Maurice, thanks again for your hints concerning "GrKeyRead vs. readln"!

1 0

← Newer
1
...
37
38
39
40
41
42
43
...
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