Grx October 2002

grx@gnu.de

7 participants
14 discussions

grxio
by alexbodn＠012.net.il 31 Oct '02

31 Oct '02

----- Original Message ----- From: Dimitar Zhekov <jimmy(a)is-vn.bg> To: <alexbodn(a)012.net.il> Sent: Wednesday, October 30, 2002 9:44 AM Subject: Re: contribution > > i have a small contribution to make for grx: it's a conio emulation. it > > What do we need this for? GRX works in graphics mode and has a sufficient > set of functions to change modes, display text in color etc. I see that > the files attached #include <conio.h> - that will only work with some (not > all) MSDOS and WIN32 systems, and will fail with all Unix-es. > > E-gards: Jimmy > > > > conio is a well-known screen text api, that supports lots of software packages, of them i dare enumerating turbo-vision and d-flat windowing systems.letting those packages act natively in graphics mode using grxio, will allow extending those windowing systems support for graphics objects. like tvbgi? the same, bgigrx has been made to support existing code relying on bgi. the mode changing functions have not [yet] been implemented, because there really is enough support for them in native grx, while they are not too cardinal for conio. i have purposely not included conio.h, to demonstrate that any system that provides conio in text mode may be used in graphics mode through grxio. text mode conio (thus conio.h) might be found on various dos systems, netware, linux, and the hard part of porting software is providing functionality, not copying the include files (which are open even on comercial systems). anyway, a very good conio implementation is free, and included in djgpp. re-gards, alex

2 1

Re: contribution
by Dimitar Zhekov 30 Oct '02

30 Oct '02

> i have a small contribution to make for grx: it's a conio emulation. it What do we need this for? GRX works in graphics mode and has a sufficient set of functions to change modes, display text in color etc. I see that the files attached #include <conio.h> - that will only work with some (not all) MSDOS and WIN32 systems, and will fail with all Unix-es. E-gards: Jimmy

2 1

contribution
by alexbodn＠012.net.il 30 Oct '02

30 Oct '02

hi pals, i have a small contribution to make for grx: it's a conio emulation. it still lacks a few features, like cprintf, cscanf (i took them in a hurry from djgpp, but are not working correctly for me), textmode and set_screen_lines (don't seem of much interest for now). feel free to check, use and distribute as usual with free copyrighted software. sincerely yours, Alex Bodnaru

1 0

bug in grx
by alexbodn＠012.net.il 26 Oct '02

26 Oct '02

hi pals, i've found a bug in the decision for the biggest graphics. it came, that while the call for _gr_selectmode had found a highly impressive mode of 1280*1024*4 (4 is the default color number for vga/vesa), in the inherited drivers it would settle for a best of 320*200*4 mode, because this is the first mode to match the colors number. i've changed the _gr_selectmode function in src/setup/setmode.c, so that instead of accepting any mode returned for the drv->inherit, this returned mode will be compared to the existing best features. remove: if (mp)best = mp; replace by if (mp && (best->bpp < mp->bpp || (best->bpp == mp->bpp && best->width + best->height < mp->width + mp->height))) best = mp; the mode i have received is 1280*1024*8bpp, which is realy the best for my card, and better than the default 4bpp. best wishes, alex

2 1

bug in grx
by alexbodn＠012.net.il 26 Oct '02

26 Oct '02

hi pals, i've found a bug in the decision for the biggest graphics. it came, that while the call for _gr_selectmode had found a highly impressive mode of 1280*1024*4 (4 is the default color number for vga/vesa), in the inherited drivers it would settle for a best of 320*200*4 mode, because this is the first mode to match the colors number. i've changed the line in _gr_selectmode from # define ERROR(des,act) ((des > act) ? ((des - act) + 20000) : (act - des)) to # define ERROR(des,act) ((des >= act) ? ((des - act) + 20000) : (act - des)) and it apears no to settle for less. it will be better tested in an environment where the driver may find a better match in the inherited modes. please test it further, if you know there is such environment. nb: i'm asking for further testing, since it got late and i can't concentrate. but the algorithm is somewhat error prone. best wishes, alex

1 0

small bugfixes in grx
by alexbodn＠012.net.il 25 Oct '02

25 Oct '02

Dear grx pals, I have revised the problems I've found in grx, and there is a test program to reproduce them (bugtest.c). It should be linked to libgrx, and the additional bugfix files intermitently linked in the program, to allow you to observe the problems and their proposed solutions. n.b: sorry, no diff submit yet My best regards, Alex

3 2

changes in printer driver
by alexbodn＠012.net.il 24 Oct '02

24 Oct '02

dear pals, here is an annotated printer driver for grx. the documentation has not been updated, but if you understand the idea, it's easy to activate by consulting the include file. there is a function to query the printer driver possibilities (width, height and number of colors). using this information, a graphics context printable on the specific printer may be created. the doprinting and printtofile will print from the current context to the printer. return -1 on failure. enjoy, alex

1 0

Re: small bugfixes in grx
by Josu Onandia 24 Oct '02

24 Oct '02

Hi Mariano and Alex, I've been looking at the bug reported by Alex in the function GrBitBlt1bpp. I believe that the patch proposed by Alex is completely right. Sorry for the delay, but this has taken some mental rewind :-) I'm happy to see that Grx continues growing and getting better, and hope to contribute again in the future. Regards Josu Onandia > -----Mensaje original----- > De: Mariano Alvarez Fernandez [SMTP:malfer@telefonica.net] > Enviado el: martes 22 de octubre de 2002 22:15 > Para: alexbodn(a)012.net.il > CC: grx(a)gnu.de > Asunto: Re: small bugfixes in grx > > Hi, Alex. > > - About the drawstrg bug. > > It isn't (and if it were a bug the correct place to check is in the > fdriver, because it must know how to get the color from a GrColor > variable). > > The problem is in the test program. GrAllocEgaColors must be placed > _after_ GrSetMode. > > - About the bitblt1 bug. > > Yes, thanks, I now see the bug. I will apply your patch: > > --- bitblt1b.old Sat Apr 14 03:56:00 2001 > +++ bitblt1b.c Tue Oct 22 21:43:58 2002 > @@ -50,7 +50,9 @@ > > (dst->gc_driver->drawbitmap)((dx + dst->gc_xoffset),(dy + > dst->gc_yoffset), > (x2 - x1 + 1),(y2 - y1 + 1),src->gc_baseaddr[0],src->gc_lineoffset, > > - ((dx - oldx1) + ((dy - oldy1) * (src->gc_lineoffset << 3))),fg,bg); > > + /*alex:the offset should anyway be the x1,y1 point in src, as > clipped*/ > + (x1 + (y1 * ((dx - oldx1) + ((dy - oldy1) * (src->gc_lineoffset << > 3))), > + fg,bg); > > mouse_unblock(); > } > > (Are you here Josu?, do you think is ok?) > > - About the 1024*768*4bpp problem > > I can't reproduce it in none of my PC's, they all work well. Have > you checked the modetest program?. What about if you set GRX20DRV=VESA? > > Thanks a lot for your work Alex. > > Regards, M.Alvarez >

1 0

small bug: bin/dummy is empty
by Dimitar Zhekov 23 Oct '02

23 Oct '02

When using .tar.gz format and WinZip32, directories containing only an empty file are not created at all (probably applies to another Win32 archivers too). That's why the other dummy files are non-empty, and so should be bin/dummy. E-gards: Jimmy

2 1

Re: small bugfixes in grx
by Mariano Alvarez Fernandez 23 Oct '02

23 Oct '02

Hi, Alex > > - About the drawstrg bug. > > > > It isn't (and if it were a bug the correct place to check is in the > > fdriver, because it must know how to get the color from a GrColor > > variable). > > > > The problem is in the test program. GrAllocEgaColors must be placed > > _after_ GrSetMode. > > > the problem is in the test program indeed. the bug appears when printing to > a > ram context, as in the example i submit here now. > the order between the 2 function calls is irrelevant, examine > GrAllocEgaColors. At last I can see the bug. You are correct. The bug only occurs in 4bpp mode, so this is why I didn't see it before, and why I thought it was the GrAllocColor order. Try: egacolors = GrAllocEgaColors(); GrSetMode(GR_width_height_bpp_graphics, 640, 480, 24); to see what happen. But the line ctx = GrCreateFrameContext(GR_frameRAM4, w * 16, h * 16, NULL, NULL); in your second test clearly identify the problem. (By the way this code is not safe, you must use GrCreateContext in normal programs). The bug is in src/fdrivers/ram4.c, here is a patch to solve it: --- ram4.old Mon Nov 6 03:41:18 2000 +++ ram4.c Wed Oct 23 22:28:22 2002 @@ -58,7 +58,7 @@ offs = FOFS(x,y,CURC->gc_lineoffset); mask = 0x80 >> (x &= 7); cval = (unsigned int)color << (7 - x); - switch(op = C_OPER(color)) { + switch(op = C_OPER(color) & 3) { case C_WRITE: case C_AND: CURC->gc_baseaddr[0][offs] &= ((cval ) | ~mask); Thanks a lot Alex Regards, M.Alvarez

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