From: Russell Marks (russell.marks@dtn.ntl.com)
Date: Mon 14 Feb 2000 - 19:32:33 IST
Matan wrote: > On Sun, 13 Feb 2000, ghazanhaider wrote: > > > what is exactly the difference between ggi and svgalib? what is > > svgalib's equivalent in DJGPP and is there an svgalib (for CGA or MDA) > > for ELKS?? > > About ggi - look at the svgalib faq that is distributed in the svgalib > package (Q7). Just out of interest, what do people think about ggi these days? I ask from the perspective of not knowing much more about it than that FAQ says. :-) I understand the `wrapper' to convert svgalib programs to ggi ones isn't so hot though. > About djgpp - I don't think there is an equivalent. Much of the > complication in svgalib is in virtual console coherency and background > execution, which is irrelevant in dos. True, but to be fair, I think the poster may have meant "is there a graphics library for DJGPP?" - I'd suggest looking at what MAME uses (is it Allegro, or something? I'm really not sure). Failing that, I wrote something crude for djgpp 1.x (!) for nc100d which could be a starting point if you wanted to roll your own. > About cga and mda cards, svgalib has no support for them. It does not > make sense to add support, as no current svgalib program will work, With respect, while svgalib should certainly not have *anything* to do with CGA/MDA (*shudder*), it might be nice if something like this was available *for ELKS* as the poster said, since that's intended for 8086/286 machines. In fact, I have an old Amstrad 2086 - an 8086 with VGA, believe it or not. So who knows, maybe some maniac could try porting svgalib (!), or more realistically, the original VGAlib. I'm being careful not to volunteer myself here. :-) FWIW though, in case it's relevant, I should point out you have virtually zero chance of existing svgalib programs running in ELKS, even if you could port svgalib or VGAlib - they're too big. Last I heard ELKS programs were 64k code + 64k data max, rather like real mode Minix. I don't think they have shared libraries either (?), so you'd want to keep any library small. But something crude to switch to CGA mode and do CGA stuff may not be that nasty from ELKS. It would have the old svgalib problem of leaving you in graphics mode if it got kill -9'd, and if they have virtual consoles that could be a problem, but it sounds like a neat little project. But I don't really know enough about this as it's *ages* since I last checked out ELKS, so I'll shut up now. :-) > since svgalib has no 2 bit color modes. If you design a library for Are you sure? From vga.h: > #define G640x480x2 9 vmanpg uses this, for example. :-) > console graphics on CGA, it might make sense to have an API similar to > svgalib, to facilitate porting of programs (such as ghostscript, > tmview). ghostscript!? I think you really must have missed the ELKS bit. It's just too big, alas (and the slowness would be mind-blowing). Not sure about tmview, but that seems fairly unlikely too. And FWIW, zgv is *right out*. :-) I hate to say it, but if you really want to run `big' graphics-using programs on a pre-386 machine, your best bet is probably DOS of some sort. I *think* I remember running ghostscript on a 286, for example, some years back (probably 1991/2). You could try FreeDOS, but I wasn't too impressed with that when I tried it recently. (I found it pretty slow, and not just off floppies. Also, I filled my DOS partition by accident while installing, and it *went past the end of the partition* (never seen an OS do that before) into my Linux swap - I'm glad I happened to decide not to put the root partition there. ;-)) -Rus.
This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:23 IST