[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
nanoX bugfix v0.4 coming
From: Greg Haerr ####@####.#### Date: 12 May 1999 16:07:31 -0000 Message-Id: <01BE9C5E.ECE21150.greg@censoft.com> I have been working hard to fix all known bugs and get the sample nanoX programs completely running. The sample programs don't work properly without XOR line drawing modes for linedraw, pixel, and fillrect, for instance. This is now fixed. In addition, there are considerable issues with palette management. The v0.3 release didn't properly completely handle type 1 vs type 2 graphics drawline code, which has also been fixed. I think I will be releasing v0.4 very soon, which can be used as a reference port for initial driver work, to have a set of properly working sample programs with which to compare drivers with. BTW, the landmine program is now fun to play! I'm also still working on bitblt and readpixel routines, as well as redesigning driver info interfaces. Unfortunately, this means that the driver api will need to change. So we're not quite ready yet to start writing tons of drivers, although it would be nice to start experimenting. Another issue is that, if we want to implement all this fancy GDK and Mozilla stuff on top of nanoX, the driver layer is going to have to support a HELL of alot more than it does now. This means that it will take longer to create drivers... An example of this is that we will have to support palette management, xor/and/or/set drawing modes, background transparency draw modes, text with transparency, and possibly a nanogui-defined device context structure for each entry point, which will mean that drivers will have to ultimately be designed for nanogui itself for speed. Comments? Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: nanoX bugfix v0.4 coming
From: Alan Cox ####@####.#### Date: 12 May 1999 16:41:17 -0000 Message-Id: <E10hcnW-0000Ki-00@the-village.bc.nu> > would be nice to start experimenting. Another issue is that, if we want to implement > all this fancy GDK and Mozilla stuff on top of nanoX, the driver layer is going to have > to support a HELL of alot more than it does now. This means that it will take Not that much > palette management, xor/and/or/set drawing modes, background transparency Fixed palette is acceptable with gtk, and indeed for LCD screens is a good first model anyway. > draw modes, text with transparency, and possibly a nanogui-defined device context Text just needs to follow the draw modes - or/xor/and/set > structure for each entry point, which will mean that drivers will have to ultimately be > designed for nanogui itself for speed. Comments? I think thats unavoidable. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: nanoX bugfix v0.4 coming
From: Ben Pfaff ####@####.#### Date: 12 May 1999 16:41:39 -0000 Message-Id: <87yaiui67n.fsf@pfaffben.user.msu.edu> Greg Haerr ####@####.#### writes: I'm also still working on bitblt and readpixel routines, as well as redesigning driver info interfaces. Unfortunately, this means that the driver api will need to change. What sorts of bitblt do you need? Do you need screen-to-screen bitblt, or screen-to-buffer, or buffer-to-screen, or all three? The BOGL API has a bmove routine for screen-to-screen bitblt, but it's never been implemented because it turned out that I didn't ever need it. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: nanoX bugfix v0.4 coming
From: Greg Haerr ####@####.#### Date: 12 May 1999 17:54:17 -0000 Message-Id: <01BE9C6D.CD62DFD0.greg@censoft.com> Yes, all three. In our first version, the upper level will use "device-dependent" bitmaps so that the bitblt is identical for all three. In a later version, we'll have upper level formats for bitmaps that can be converted by drivers to their own low level format. In addition, we need to think about patblt, which is another form of bitblt that works from predefined patterns to be used for fill backgrounds. All this can wait for a while though, since bitblt will allow pictures and icons to be drawn. On another note, the pointer draw routine and the low level bitblt routines should probably merge, so that ultimately we have just one bitblt routine for any image, whether its cursor or bitmap. In order to do icons well, the bitblt needs AND and OR drawing modes. I'm working on a spec for all of this as well. Greg On Wednesday, May 12, 1999 10:49 AM, Ben Pfaff ####@####.#### wrote: > Greg Haerr ####@####.#### writes: > > I'm also still working on bitblt and readpixel routines, as well as redesigning > driver info interfaces. Unfortunately, this means that the driver api will need to > change. > > What sorts of bitblt do you need? Do you need screen-to-screen > bitblt, or screen-to-buffer, or buffer-to-screen, or all three? The > BOGL API has a bmove routine for screen-to-screen bitblt, but it's > never been implemented because it turned out that I didn't ever need > it. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ####@####.#### > For additional commands, e-mail: ####@####.#### > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: nanoX bugfix v0.4 coming
From: Ben Pfaff ####@####.#### Date: 12 May 1999 18:01:31 -0000 Message-Id: <87so92i2iv.fsf@pfaffben.user.msu.edu> Greg Haerr ####@####.#### writes: On another note, the pointer draw routine and the low level bitblt routines should probably merge, so that ultimately we have just one bitblt routine for any image, whether its cursor or bitmap. In order to do icons well, the bitblt needs AND and OR drawing modes. I'm working on a spec for all of this as well. Come up with a spec and I'll see what I can do about coding it up. BTW: Are the rest of you getting stuff from the list? I'm not, although I did for a while, and a mail to ####@####.#### (I think that's the address--it's on the webpage) didn't get a response. -- "...dans ce pays-ci il est bon de tuer de temps en temps un amiral pour encourager les autres." --Voltaire, _Candide_ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: nanoX bugfix v0.4 coming
From: Alex Holden ####@####.#### Date: 12 May 1999 18:21:12 -0000 Message-Id: <Pine.LNX.4.04.9905121852030.1171-100000@hyperspace> On Wed, 12 May 1999, Greg Haerr wrote: > Yes, all three. In our first version, the upper level will use "device-dependent" bitmaps > so that the bitblt is identical for all three. In a later version, we'll have upper level > formats for bitmaps that can be converted by drivers to their own low level format. > > In addition, we need to think about patblt, which is another form of bitblt that > works from predefined patterns to be used for fill backgrounds. All this can wait > for a while though, since bitblt will allow pictures and icons to be drawn. > > On another note, the pointer draw routine and the low level bitblt routines should > probably merge, so that ultimately we have just one bitblt routine for any image, > whether its cursor or bitmap. In order to do icons well, the bitblt needs AND and > OR drawing modes. I'm working on a spec for all of this as well. Have you had a look at Allegro? It's a really excellent DOS games library (with Windoze and X ports under way the last time I looked). The license is pretty open: Allegro is swap-ware. You may use, modify, redistribute, and generally hack it about in any way you like, but if you do you must send me something in exchange. This could be a complimentary copy of a game, an addition or improvement to Allegro, a bug report, some money (this is particularly encouraged if you use Allegro in a commercial product), or just a copy of your autoexec.bat if you don't have anything better. If you redistribute parts of Allegro or make a game using it, it would be nice if you mentioned me somewhere in the credits, but if you just want to pinch a few routines that is OK too. I'll trust you not to rip me off. I think there wouldn't be a problem including his code in Nano-X, and there is some really excellent graphics code in there. I actually got into Open Source after reading about Allegro, then getting DJGPP (the DOS port of GCC) in order to use it. http://www.talula.demon.co.uk/allegro/ --------------- Linux- the choice of a GNU generation. -------------- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : -------------------- http://www.linuxhacker.org/ -------------------- | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: nanoX bugfix v0.4 coming
From: Alex Holden ####@####.#### Date: 12 May 1999 19:24:19 -0000 Message-Id: <Pine.LNX.4.04.9905122008560.1171-100000@hyperspace> On Wed, 12 May 1999, Alex Holden wrote: > Have you had a look at Allegro? It's a really excellent DOS games library > (with Windoze and X ports under way the last time I looked). The license > is pretty open: <snip swap-ware license> I just downloaded the latest version of the library, and turns out that it is now totally free. Here's an extrace from the feature list: Supports VGA mode 13h, mode-X (twenty three tweaked VGA resolutions plus unchained 640x400 Xtended mode), and SVGA modes with 8, 15, 16, 24, and 32 bit color depths, taking full advantage of VBE 2.0 linear framebuffers and the VBE/AF hardware accelerator API if they are available. Additional video hardware support is available from the FreeBE/AF project (http://www.talula.demon.co.uk/freebe/). Drawing functions including putpixel, getpixel, lines, rectangles, flat shaded, gouraud shaded, and texture mapped polygons, circles, floodfill, bezier splines, patterned fills, masked, run length encoded, and compiled sprites, blitting, bitmap scaling and rotation, translucency/lighting, and text output with proportional fonts. Supports clipping, and can draw directly to the screen or to memory bitmaps of any size. Hardware scrolling, mode-X split screens, and palette manipulation. FLI/FLC animation player. I think it'd be really great if we could make use of parts of Allegro in Nano-X. Man years of work have gone into the optimised low level primitives and things like the pallete handling code, but it's still extremely clean, small, and _very_ fast. --------------- Linux- the choice of a GNU generation. -------------- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : -------------------- http://www.linuxhacker.org/ -------------------- | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: nanoX bugfix v0.4 coming
From: Ben Pfaff ####@####.#### Date: 12 May 1999 19:35:03 -0000 Message-Id: <87btfqhys2.fsf@pfaffben.user.msu.edu> Alex Holden ####@####.#### writes: On Wed, 12 May 1999, Alex Holden wrote: > Have you had a look at Allegro? It's a really excellent DOS games library > (with Windoze and X ports under way the last time I looked). The license > is pretty open: <snip swap-ware license> I just downloaded the latest version of the library, and turns out that it is now totally free. Here's an extrace from the feature list: [...] Wow, that's pretty impressive. If it's also relatively small and easy to port, then maybe that's what we should use, instead of BOGL. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: nanoX bugfix v0.4 coming
From: Alex Holden ####@####.#### Date: 12 May 1999 19:46:52 -0000 Message-Id: <Pine.LNX.4.04.9905122027010.1171-100000@hyperspace> On 12 May 1999, Ben Pfaff wrote: > Wow, that's pretty impressive. If it's also relatively small and easy > to port, then maybe that's what we should use, instead of BOGL. The main disadvantages with it are that it doesn't have a Linux FB driver, plus some bits of it are hand optimised x86 assembly which would have to have C versions written. It would probably be a better basis than Bogl for non Linux-2.2 platforms though. There was actually also a partial SVGAlib a while back, which was abandoned due to the X port progressing faster. I'm sure there's plenty of stuff we can use in it though. There's even a _very_ tiny widget set in there, which was great for designing game map editors and things. I remember impressing a lecturer with a really flashy looking program graphical units converter I built with it as an example in about an hour once :) Thinking about it, it could be very useful as a basis for a PDA GUI due to it's small size... --------------- Linux- the choice of a GNU generation. -------------- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : -------------------- http://www.linuxhacker.org/ -------------------- | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |