Grx

grx@gnu.de

559 discussions

GRX user's manual 4
by Mariano Alvarez Fernandez 24 Aug '00

24 Aug '00

Another part * Pattern filled graphics primitives The library also supports a pattern filled version of the basic filled primitives described above. These functions have similar parameter passing conventions as the basic ones with one difference: instead of the color value a pointer to an union of type 'GrPattern' has to be passed to them. The 'GrPattern' union can contain either a bitmap or a pixmap fill pattern. The first integer slot in the union determines which type it is. Bitmap fill patterns are rectangular arrays of bits, each set bit representing the foreground color of the fill operation, and each zero bit representing the background. Both the foreground and background colors can be combined with any of the supported logical operations. Bitmap fill patterns have one restriction: their width must be eight pixels. Pixmap fill patterns are very similar to contexts. The relevant structure declarations (from "grx20.h"): /* * BITMAP: a mode independent way to specify a fill pattern of two * colors. It is always 8 pixels wide (1 byte per scan line), its * height is user-defined. SET THE TYPE FLAG TO ZERO!!! */ typedef struct _GR_bitmap { int bmp_ispixmap; /* type flag for pattern union */ int bmp_height; /* bitmap height */ char *bmp_data; /* pointer to the bit pattern */ GrColor bmp_fgcolor; /* foreground color for fill */ GrColor bmp_bgcolor; /* background color for fill */ int bmp_memflags; /* set if dynamically allocated */ } GrBitmap; /* * PIXMAP: a fill pattern stored in a layout identical to the video RAM * for filling using 'bitblt'-s. It is mode dependent, typically one * of the library functions is used to build it. KEEP THE TYPE FLAG * NONZERO!!! */ typedef struct _GR_pixmap { int pxp_ispixmap; /* type flag for pattern union */ int pxp_width; /* pixmap width (in pixels) */ int pxp_height; /* pixmap height (in pixels) */ GrColor pxp_oper; /* bitblt mode (SET, OR, XOR, AND, IMAGE) */ struct _GR_frame pxp_source; /* source context for fill */ } GrPixmap; /* * Fill pattern union -- can either be a bitmap or a pixmap */ typedef union _GR_pattern { int gp_ispixmap; /* nonzero for pixmaps */ GrBitmap gp_bitmap; /* fill bitmap */ GrPixmap gp_pixmap; /* fill pixmap */ } GrPattern; This define group (from "grx20.h") help to acces the 'GrPattern0 menbers: #define gp_bmp_data gp_bitmap.bmp_data #define gp_bmp_height gp_bitmap.bmp_height #define gp_bmp_fgcolor gp_bitmap.bmp_fgcolor #define gp_bmp_bgcolor gp_bitmap.bmp_bgcolor #define gp_pxp_width gp_pixmap.pxp_width #define gp_pxp_height gp_pixmap.pxp_height #define gp_pxp_oper gp_pixmap.pxp_oper #define gp_pxp_source gp_pixmap.pxp_source Bitmap patterns can be easily built from initialized character arrays and static structures by the C compiler, thus no special support is included in the library for creating them. The only action required from the application program might be changing the foreground and background colors as needed. Pixmap patterns are more difficult to build as they replicate the layout of the video memory which changes for different video modes. For this reason the library provides three functions to create pixmap patterns in a mode-independent way: GrPattern *GrBuildPixmap(char *pixels,int w,int h,GrColorTableP colors); GrPattern *GrBuildPixmapFromBits(char *bits,int w,int h, GrColor fgc,GrColor bgc); GrPattern *GrConvertToPixmap(GrContext *src); 'GrBuildPixmap' build a pixmap from a two dimensional ('w' by 'h') array of characters. The elements in this array are used as indices into the color table specified with the argument 'colors'. (This means that pixmaps created this way can use at most 256 colors.) The color table pointer: typedef GrColor *GrColorTableP; should point to an array of integers with the first element being the number of colors in the table and the color values themselves starting with the second element. NOTE: any color modifiers (GrXOR, GrOR, GrAND) OR-ed to the elements of the color table are ignored. The 'GrBuildPixmapFromBits' function builds a pixmap fill pattern from bitmap data. It is useful if the width of the bitmap pattern is not eight as such bitmap patterns can not be used to build a 'GrBitmap' structure. The 'GrConvertToPixmap' function converts a graphics context to a pixmap fill pattern. It is useful when the pattern can be created with graphics drawing operations. NOTE: the pixmap pattern and the original context share the drawing RAM, thus if the context is redrawn the fill pattern changes as well. Fill patterns which were built by library routines can be destroyed when no longer needed (i.e. the space occupied by them can be freed) by calling: void GrDestroyPattern(GrPattern *p); NOTE: when pixmap fill patterns converted from contexts are destroyed, the drawing RAM is not freed. It is freed when the original context is destroyed. Fill patterns built by the application have to be destroyed by the application as well (if this is needed). The list of supported pattern filled graphics primitives is shown below. These functions are very similar to their solid filled counterparts, only their last argument is different: void GrPatternFilledPlot(int x,int y,GrPattern *p); void GrPatternFilledLine(int x1,int y1,int x2,int y2,GrPattern *p); void GrPatternFilledBox(int x1,int y1,int x2,int y2,GrPattern *p); void GrPatternFilledCircle(int xc,int yc,int r,GrPattern *p); void GrPatternFilledEllipse(int xc,int yc,int xa,int ya,GrPattern *p); void GrPatternFilledCircleArc(int xc,int yc,int r,int start,int end, int style,GrPattern *p); void GrPatternFilledEllipseArc(int xc,int yc,int xa,int ya,int start,int end, int style,GrPattern *p); void GrPatternFilledConvexPolygon(int numpts,int points[][2],GrPattern *p); void GrPatternFilledPolygon(int numpts,int points[][2],GrPattern *p); void GrPatternFloodFill(int x, int y, GrColor border, GrPattern *p); Strictly speaking the plot and line functions in the above group are not filled, but they have been included here for convenience. * Patterned line drawing The custom line drawing functions introduced above also have a version when the drawn sections can be filled with a (pixmap or bitmap) fill pattern. To achieve this these functions must be passed both a custom line drawing option ('GrLineOption' structure) and a fill pattern ('GrPattern' union). These two have been combined into the 'GrLinePattern' structure: typedef struct { GrPattern *lnp_pattern; /* fill pattern */ GrLineOption *lnp_option; /* width + dash pattern */ } GrLinePattern; All patterned line drawing functions take a pointer to this structure as their last argument. The list of available functions: void GrPatternedLine(int x1,int y1,int x2,int y2,GrLinePattern *lp); void GrPatternedBox(int x1,int y1,int x2,int y2,GrLinePattern *lp); void GrPatternedCircle(int xc,int yc,int r,GrLinePattern *lp); void GrPatternedEllipse(int xc,int yc,int xa,int ya,GrLinePattern *lp); void GrPatternedCircleArc(int xc,int yc,int r,int start,int end, int style,GrLinePattern *lp); void GrPatternedEllipseArc(int xc,int yc,int xa,int ya,int start,int end, int style,GrLinePattern *lp); void GrPatternedPolyLine(int numpts,int points[][2],GrLinePattern *lp); void GrPatternedPolygon(int numpts,int points[][2],GrLinePattern *lp);

1 0

GRX user's manual 3
by Mariano Alvarez Fernandez 23 Aug '00

23 Aug '00

Hi, attached the part 3, any comments? * Graphics primitives The screen, the current context or the current clip box can be cleared (i.e. set to a desired background color) by using one of the following three functions: void GrClearScreen(GrColor bg); void GrClearContext(GrColor bg); void GrClearClipBox(GrColor bg); Thanks to the special 'GrColor' definition, you can do more than simple clear with this functions, by example with: GrClearScreen( GrWhite()|GrXOR ); the graphics screen is negativized, do it again and the screen is restored. The following line drawing graphics primitives are supported by the library: void GrPlot(int x,int y,GrColor c); void GrLine(int x1,int y1,int x2,int y2,GrColor c); void GrHLine(int x1,int x2,int y,GrColor c); void GrVLine(int x,int y1,int y2,GrColor c); void GrBox(int x1,int y1,int x2,int y2,GrColor c); void GrCircle(int xc,int yc,int r,GrColor c); void GrEllipse(int xc,int yc,int xa,int ya,GrColor c); void GrCircleArc(int xc,int yc,int r,int start,int end,int style,GrColor c); void GrEllipseArc(int xc,int yc,int xa,int ya, int start,int end,int style,GrColor c); void GrPolyLine(int numpts,int points[][2],GrColor c); void GrPolygon(int numpts,int points[][2],GrColor c); All primitives operate on the current graphics context. The last argument of these functions is always the color to use for the drawing. The 'HLine' and 'VLine' primitives are for drawing horizontal and vertical lines. They have been included in the library because they are more efficient than the general line drawing provided by 'GrLine'. The ellipse primitives can only draw ellipses with their major axis parallel with either the X or Y coordinate axis. They take the half X and Y axis length in the 'xa' and 'ya' arguments. The arc (circle and ellipse) drawing functions take the start and end angles in tenths of degrees (i.e. meaningful range: 0 ... 3600). The angles are interpreted counter-clockwise starting from the positive X axis. The style argument can be one of this defines from "grx20.h": #define GR_ARC_STYLE_OPEN 0 #define GR_ARC_STYLE_CLOSE1 1 #define GR_ARC_STYLE_CLOSE2 2 'GR_ARC_STYLE_OPEN' draws only the arc, 'GR_ARC_STYLE_CLOSE1' closes the arc with a line between his start and end point, 'GR_ARC_STYLE_CLOSE1' draws the typical cake slice. This routine: void GrLastArcCoords(int *xs,int *ys,int *xe,int *ye,int *xc,int *yc); can be used to retrieve the start, end, and center points used by the last arc drawing functions. The polyline and polygon primitives take the address of an n by 2 coordinate array. The X values should be stored in the elements with 0 second index, and the Y values in the elements with a second index value of 1. Coordinate arrays passed to the polygon primitive can either contain or omit the closing edge of the polygon -- the primitive will append it to the list if it is missing. Because calculating the arc points it's a very time consuming operation, there are two functions to pre-calculate the points, that can be used next with polyline and polygon primitives: int GrGenerateEllipse(int xc,int yc,int xa,int ya, int points[GR_MAX_ELLIPSE_POINTS][2]); int GrGenerateEllipseArc(int xc,int yc,int xa,int ya,int start,int end, int points[GR_MAX_ELLIPSE_POINTS][2]); The following filled primitives are available: void GrFilledBox(int x1,int y1,int x2,int y2,GrColor c); void GrFramedBox(int x1,int y1,int x2,int y2,int wdt,GrFBoxColors *c); void GrFilledCircle(int xc,int yc,int r,GrColor c); void GrFilledEllipse(int xc,int yc,int xa,int ya,GrColor c); void GrFilledCircleArc(int xc,int yc,int r, int start,int end,int style,GrColor c); void GrFilledEllipseArc(int xc,int yc,int xa,int ya, int start,int end,int style,GrColor c); void GrFilledPolygon(int numpts,int points[][2],GrColor c); void GrFilledConvexPolygon(int numpts,int points[][2],GrColor c); Similarly to the line drawing, all of the above primitives operate on the current graphics context. The 'GrFramedBox' primitive can be used to draw motif-like shaded boxes and "ordinary" framed boxes as well. The 'x1' through 'y2' coordinates specify the interior of the box, the border is outside this area, 'wdt' pixels wide. The primitive uses five different colors for the interior and four borders of the box which are specified in the 'GrFBoxColors' structure: typedef struct { GrColor fbx_intcolor; GrColor fbx_topcolor; GrColor fbx_rightcolor; GrColor fbx_bottomcolor; GrColor fbx_leftcolor; } GrFBoxColors; The 'GrFilledConvexPolygon' primitive can be used to fill convex polygons. It can also be used to fill some concave polygons whose boundaries do not intersect any horizontal scan line more than twice. All other concave polygons have to be filled with the (somewhat less efficient) 'GrFilledPolygon' primitive. This primitive can also be used to fill several disjoint nonoverlapping polygons in a single operation. The function: void GrFloodFill(int x, int y, GrColor border, GrColor c); flood-fills the area bounded by the color 'border' using 'x','y' like the starting point. The current color value of any pixel in the current context can be obtained with: GrColor GrPixel(int x,int y); and: GrColor GrPixelC(GrContext *c,int x,int y); do the same for any context. Rectangular areas can be transferred within a context or between contexts by calling: void GrBitBlt(GrContext *dest,int x,int y,GrContext *source, int x1,int y1,int x2,int y2,GrColor op); 'x','y' is the position in the destination context, and 'x1','y1','x2',y2' the area from the source context to be transfered. The 'op' argument should be one of supported color write modes (GrWRITE, GrXOR, GrOR, GrAND, GrIMAGE), it will control how the pixels from the source context are combined with the pixels in the destination context (the GrIMAGE op must be ored with the color value to be handled as transparent). If either the source or the destination context argument is the NULL pointer then the current context is used for that argument. * Non-clipping graphics primitives (not recomended to use!) There is a non-clipping version of some of the elementary primitives. These are somewhat more efficient than the regular versions. These are to be used only in situations when it is absolutely certain that no drawing will be performed beyond the boundaries of the current context. Otherwise the program will almost certainly crash! The reason for including these functions is that they are somewhat more efficient than the regular, clipping versions. ALSO NOTE: These function do not check for conflicts with the mouse cursor. (See the explanation about the mouse cursor handling later in this document.) The list of the supported non-clipping primitives: void GrPlotNC(int x,int y,GrColor c); void GrLineNC(int x1,int y1,int x2,int y2,GrColor c); void GrHLineNC(int x1,int x2,int y,GrColor c); void GrVLineNC(int x,int y1,int y2,GrColor c); void GrBoxNC(int x1,int y1,int x2,int y2,GrColor c); void GrFilledBoxNC(int x1,int y1,int x2,int y2,GrColor c); void GrFramedBoxNC(int x1,int y1,int x2,int y2,int wdt,GrFBoxColors *c); void GrBitBltNC(GrContext *dst,int x,int y,GrContext *src, int x1,int y1,int x2,int y2,GrColor op); GrColor GrPixelNC(int x,int y); GrColor GrPixelCNC(GrContext *c,int x,int y); * Customized line drawing The basic line drawing graphics primitives described previously always draw continuous lines which are one pixel wide. There is another group of line drawing functions which can be used to draw wide and/or patterned lines. These functions have similar parameter passing conventions as the basic ones with one difference: instead of the color value a pointer to a structure of type 'GrLineOption' has to be passed to them. The definition of the 'GrLineOption' structure: typedef struct { GrColor lno_color; /* color used to draw line */ int lno_width; /* width of the line */ int lno_pattlen; /* length of the dash pattern */ unsigned char *lno_dashpat; /* draw/nodraw pattern */ } GrLineOption; The 'lno_pattlen' structure element should be equal to the number of alternating draw -- no draw section length values in the array pointed to by the 'lno_dashpat' element. The dash pattern array is assumed to begin with a drawn section. If the pattern length is equal to zero a continuous line is drawn. Example, a white line 3 bits wide and pattern 6 bits draw, 6 bits nodraw: unsigned char mydash[2] = { 0xFC,0x00 }; GrLineOption mylineop; ... mylineop.lno_color = GrWhite(); mylineop.lno_width = 3; mylineop.lno_pattlen = 12; mylineop.lno_dashpat = mydash; The available custom line drawing primitives: void GrCustomLine(int x1,int y1,int x2,int y2,GrLineOption *o); void GrCustomBox(int x1,int y1,int x2,int y2,GrLineOption *o); void GrCustomCircle(int xc,int yc,int r,GrLineOption *o); void GrCustomEllipse(int xc,int yc,int xa,int ya,GrLineOption *o); void GrCustomCircleArc(int xc,int yc,int r, int start,int end,int style,GrLineOption *o); void GrCustomEllipseArc(int xc,int yc,int xa,int ya, int start,int end,int style,GrLineOption *o); void GrCustomPolyLine(int numpts,int points[][2],GrLineOption *o); void GrCustomPolygon(int numpts,int points[][2],GrLineOption *o);

1 0

GRX user's manual 2
by Mariano Alvarez Fernandez 20 Aug '00

20 Aug '00

Hi, attached to this mail the second part, color management. Coments will be welcome (really I don't know GRX internals a lot). M.Alvarez Color management GRX defines the type 'GrColor' for color variables. 'GrColor' it's a 32 bits integer. The 8 left bits are reserved for the write mode (see below). The 24 bits right are the color value. The library supports two models for color management. In the 'indirect' (or color table) mode, color values are indices to a color table. The color table slots will be allocated with the highest resolution supported by the hardware (EGA: 2 bits, VGA: 6 bits) with respect to the component color intensities. In the 'direct' (or RGB) mode, color values map directly into component color intensities with non-overlapping bitfields of the color index representing the component colors. Color table model is supported until 256 color modes. The RGB model is supported in 256 color and up color modes. In RGB mode the color index map to component color intensities depend on the video mode set, so it can't be assumed the component color bitfields (but if you are curious check the GrColorInfo global structure in "grx20.h"). After the first 'GrSetMode' call two colors are always defined: black and white. The color values of these two colors are returned by the functions: GrColor GrBlack(void); GrColor GrWhite(void); GrBlack() is guaranteed to be 0. The library supports five write modes (a write mode descibes the operation between the actual bit color and the one to be set): write, XOR, logical OR, logical AND and IMAGE. These can be selected with OR-ing the color value with one of the following constants declared in "grx20.h": #define GrWRITE 0UL /* write color */ #define GrXOR 0x01000000UL /* to "XOR" any color to the screen */ #define GrOR 0x02000000UL /* to "OR" to the screen */ #define GrAND 0x03000000UL /* to "AND" to the screen */ #define GrIMAGE 0x04000000UL /* BLIT: write, except given color */ The 'GrIMAGE' write mode only works with the 'bitblt' function. By convention, the no-op color is obtained by combining color value 0 (black) with the XOR operation. This no-op color has been defined in "grx20.h" as: #define GrNOCOLOR (GrXOR | 0) /* GrNOCOLOR is used for "no" color */ The write mode part and the color value part of a 'GrColor' variable can be obtained OR-ing it with one of the following constants declared in "grx20.h": #define GrCVALUEMASK 0x00ffffffUL /* color value mask */ #define GrCMODEMASK 0xff000000UL /* color operation mask */ The number of colors in the current graphics mode is returned by the: GrColor GrNumColors(void); function, while the number of unused, available color can be obtained by calling: GrColor GrNumFreeColors(void); Colors can be allocated with the: GrColor GrAllocColor(int r,int g,int b); function (component intensities can range from 0 to 255), or with the: GrColor GrAllocCell(void); function. In the second case the component intensities of the returned color can be set with: void GrSetColor(GrColor color,int r,int g,int b); In the color table model both 'Alloc' functions return 'GrNOCOLOR' if there are no more free colors available. In the RGB model 'GrNumFreeColors' returns 0 and 'GrAllocCell' always returns 'GrNOCOLOR', as colors returned by 'GrAllocCell' are meant to be changed -- what is not supposed to be done in RGB mode. Also note that 'GrAllocColor' operates much more efficiently in RGB mode, and that it never returns 'GrNOCOLOR' in this case. Color table entries can be freed (when not in RGB mode) by calling: void GrFreeColor(GrColor color); The component intensities of any color can be queried using the function: void GrQueryColor(GrColor c,int *r,int *g,int *b); Initially the color system is in color table (indirect) model if there are 256 or less colors. 256 color modes can be put into the RGB model by calling: void GrSetRGBcolorMode(void); The color system can be reset (i.e. put back into color table model if possible, all colors freed except for black and white) by calling: void GrResetColors(void); The function: void GrRefreshColors(void); reloads the currently allocated color values into the video hardware. This function is not needed in typical applications, unless the display adapter is programmed directly by the application. This functions: GrColor GrAllocColorID(int r,int g,int b); void GrQueryColorID(GrColor c,int *r,int *g,int *b); are inlined versions (except if you compile GRX with 'GRX_SKIP_INLINES' defined) to be used in the RGB model (in the color table model they call the normal routines). Portable use of a few colors People that only want to use a few colors find the GRX color handling a bit confusing, but it gives the power to manage a lot of color deeps and two color models. Here are some guidelines to easily use the famous 16 ega colors in GRX programs. We need this GRX function: GrColor *GrAllocEgaColors(void); it returns a 16 GrColor array with the 16 ega colors alloced (really it's a trivial function, read the source "src/setup/colorega.c"). We can use a construction like that: First, in your C code make a global pointer, and init it after set the graphics mode: GrColor *egacolors; .... int your_setup_function( ... ) { ... GrSetMode( ... ) ... egacolors = GrAllocEgaColors(); ... } Next, add this to your main include file: extern GrColor *egacolors; #define BLACK egacolors[0] #define BLUE egacolors[1] #define GREEN egacolors[2] #define CYAN egacolors[3] #define RED egacolors[4] #define MAGENTA egacolors[5] #define BROWN egacolors[6] #define LIGHTGRAY egacolors[7] #define DARKGRAY egacolors[8] #define LIGHTBLUE egacolors[9] #define LIGHTGREEN egacolors[10] #define LIGHTCYAN egacolors[11] #define LIGHTRED egacolors[12] #define LIGHTMAGENTA egacolors[13] #define YELLOW egacolors[14] #define WHITE egacolors[15] Now you can use the defined colors in your code. Note that if you are in color table model in a 16 color mode, you have exhausted the color table. Note too that this don't work to initialize static variables with a color, because 'egacolors' is not initialized.

1 0

Re: GRX user's manual
by Mariano Alvarez Fernandez 18 Aug '00

18 Aug '00

richard(a)stardate.bc.ca escribió: > On 18 Aug 2000, at 2:26, Mariano Alvarez Fernandez wrote: > > Just a couple of minor (English) corrections at the end of the text. > > > Note that GrDestoryContext know if grc was automatically malloced or no!! > > Should be ...... > Note that GrDestoryContext knows if grc was automatically malloced or > not!! > > > Using GrCreateSubContext is the same, except it didn't need the > > buffer, because it uses the parent buffer. > > Should be...... > Using GrCreateSubContext is the same, except it doesn't need the > buffer, because it uses the parent buffer. > Thanks! > > I like what you have done with the example code. When you get to that > part, the 'GrLineOption' could use some example code. I t took me > quite a while to catch on to how to use it. Actually a better > description of what the variables in the structure do. > I will try to do. > > I am constanly amazed at how well you and many others write in > English when it is not your first language. I do not speak a second > language and have more than enough trouble with just English. Really?, I think my english write is very bad (my speek english is worse). If the english doc is fine, is because I'm using the Csaba doc. I will prefer to use my own language :-), but is a fact that english is the common Internet language. Thanks again for the corrections. M.Alvarez

1 0

RE: Graphical resolution with GPC
by Klaus Friis Østergaard 18 Aug '00

18 Aug '00

Hello, again, Peter Gerwinski, writes that: ... Nope. It depends on your graphics card, your operating system and your setup which resolution you can get. ... If I have a windows 98 system with a graphic controller and monitor capabal of a resolution of 1280x1024 x256 colors on a intel 586 pc, then I should be able to run this mode with grx and gpc (cygwin). But only if the windows98 is set to 1280x1024 resolution? kind regards, klaus -----Original Message----- From: Peter Gerwinski [mailto:peter@gerwinski.de] Sent: 8. august 2000 21:55 To: =?iso-8859-1?Q?Klaus_Friis_=D8stergaard_=3CKFO=40LASERTECH=2EDK=3E?=@esm eralda.gerwinski.de Cc: GPC; GRX Subject: Re: Graphical resolution with GPC Hello, everyone, Klaus Friis Østergaard wrote: > I need to convert a program written in turbo pascal version 7.0 which uses a > resolution of 1024x768 pixels. > When I look at the GRX packed it seems like the high resolution is 640x400 > standard svga is this right? Nope. It depends on your graphics card, your operating system and your setup which resolution you can get. > I need to use a mouse to control something in the program. GRX has mouse support - please have a look at the functions `GrMouseGetEvent' and `GrMouseGetEventT'. > Would it be possible to convert this program/ make a new program that uses > GPC, with grx and a graphical interface at 1024x768 or maybe 1280x1024, I > only need 16 colours? Yes. No problem. > I have the newest gpc-alpha version compiled on a red-hat linux and also a > cygwin working on Windows, the primary end platform for the program should > be Windows (unfortunately). > > If it is possible to get a resolution of 1024X768 or greater it would be > great if there was a sample code on how to initialise/invoke the graphics > rather than a YES this can be done. GrSetMode (GR_width_height_color_graphics, 1024, 768, 256, 0, 0); Hope this helps, Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-20000808 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: http://www.gerwinski.de/pubkeys/ - AntiSpam: http://spam.abuse.net

2 1

Graphical resolution with GPC
by Klaus Friis Østergaard 08 Aug '00

08 Aug '00

Hi Everyone at GPC/GRX I need to convert a program written in turbo pascal version 7.0 which uses a resolution of 1024x768 pixels. When I look at the GRX packed it seems like the high resolution is 640x400 standard svga is this right? I need to use a mouse to control something in the program. Would it be possible to convert this program/ make a new program that uses GPC, with grx and a graphical interface at 1024x768 or maybe 1280x1024, I only need 16 colours? I have the newest gpc-alpha version compiled on a red-hat linux and also a cygwin working on Windows, the primary end platform for the program should be Windows (unfortunately). If it is possible to get a resolution of 1024X768 or greater it would be great if there was a sample code on how to initialise/invoke the graphics rather than a YES this can be done. Thanks Klaus F. Østergaard farremosen(a)mail.tele.dk

2 1

subscribe
by Allan Kugel 31 Jul '00

31 Jul '00

subscribe grx kugel@ruccs

1 0

GrCreateContext
by richard＠stardate.bc.ca 28 Jul '00

28 Jul '00

If GrCreateContext(); is mallocing the memory space and malloc fails, does the returned GrContext variable == NULL or what else would indicate a failure? Cheers Richard

3 3

Re: grx-2.3.1
by Nathalie Jarosz 11 Jul '00

11 Jul '00

Hi all! Thanks Anja for the grx.pas... >From: Anja Drewitz <anja(a)maeh.theo-phys.uni-essen.de> >To: "Nathalie Jarosz" <jarosz_n(a)hotmail.com> >Subject: Re: grx-2.3.1 >Date: Mon, 10 Jul 2000 19:09:38 +0200 >If you write "include GRX;" as in >Peter's example it must have the name "grx.pas", I think. In grx-2.3.1/include, I have something named "grx20.h"?... So, I have put grx.pas where I want to compile fgraph.pas but, it still not working... gpc --automake -o fgraph fgraph.p -lgrx20X -lX11 fgraph.p:37: module/unit interface `Grx' could not be imported When I compiled grx.pas, I have grx.o and grx20.gpi. So, I tried to renamed grx20.gpi in grx.gpi and now the message is: gpc --automake -o fgraph fgraph.p -lgrx20X -lX11 ld: fatal: library -llibgrx20X: not found ld: fatal: File processing errors. No output written to fgraph collect2: ld returned 1 exit status Thanks for your help, Nathalie ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

Re: grx-2.3.1
by Nathalie Jarosz 11 Jul '00

11 Jul '00

>From: Peter Gerwinski <peter(a)gerwinski.de> >To: grx(a)gnu.de >Subject: Re: grx-2.3.1 >Date: Tue, 11 Jul 2000 11:24:17 +0200 > >Nathalie Jarosz wrote: > > > gpc -L /usr/local/src/grx/lib/unix --automake \ > > > -o fgraph fgraph.p -lgrx20X -lX11 > > Even with the right path, the compilation failed... libgrx20X.a*really > > exists in this path... > >Okay, please try this: > >gpc --automake -o fgraph fgraph.p /usr/local/src/grx/lib/unix/libgrx20.a >-lX11 the library is still not found... Is it normal that the message says:"ld: fatal: library -llibgrx20X: not found" instead of "-libgrx20X"?... Nathalie ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

2 1

← Newer
1
...
43
44
45
46
47
48
49
...
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