I use the latest official. I don't do enough with it to be on the bleeding
edge, but I like the cross platform stability.
I recently used/am using it, to create a 3D drawing package for a class I am
taking. So far so good :).
>
> TNX. Do you use the latest official releases or the CVS version?
> box.c: In function `GGI_ati_mach64_fillscreen':
> box.c:49: warning: unused variable `yadd'
>
> All such warnings should be easy to fix. Remove the unused variable, or
> stick a yadd = 0; in there somewhere so it stops complaining.
This sort of warnings procudes gcc < 3, too.
> crossblit.c:
nic scheduling with a hard guarantee
and reclaiming timeslices when tasks are canceled. (Of course, our
"time" axis doesn't actually progress, so any features of
an algorithm that carry state during time progression don't really
help us. :-)
BTW, Eric has had a go at implementing a basic first cut.
--
Brian
On Tue, 16 Oct 2001, Brian S. Julin wrote:
> On Tue, 16 Oct 2001, Rodolphe Ortalo wrote:
> > That's pretty much "sidestepping the problem" as you say - but I'm still
> > wondering if a general algorithm has been published to address the problem
> > of "bidimensional" memory allocation in one sho
On Tue, 16 Oct 2001, Rodolphe Ortalo wrote:
> That's pretty much "sidestepping the problem" as you say - but I'm still
> wondering if a general algorithm has been published to address the problem
> of "bidimensional" memory allocation in one shot.
Well, mathwise it is a similar problem to rate m
On Mon, 15 Oct 2001, Brian S. Julin wrote:
[...]
> > [2] E.g.: texture allocation deserves to be done cleanly
>
> Here you hit the nail on the head.
Yep, allocation is a very annoying issue when you want to manage all the
details (pitch != width, and the like).
[...]
> Hopefully we can finis
On Mon, 15 Oct 2001, Rodolphe Ortalo wrote:
> Specifically, the complexity of the design and the fact that it prevents
> people from trying to help on a specific area annoys me (especially as,
> sometimes, I share this feeling also). But I don't really know how this
> could
but it's
probably *not* very clever to do it too early [2].
On the other hand, it's true that external opinions on GGI should be taken
into account.
Specifically, the complexity of the design and the fact that it prevents
people from trying to help on a specific area annoys me (especial
I'm nibbling away at learning GGI and writing display targets - might
even write some accelerated targets for the lowlevel libs soon.
On Fri, 2001-10-12 at 10:12, Christoph Egger wrote:
>
> Hi!
>
>
> This mail is more or less a cry for more help! As you can see, Brian, E
y work on MesaGGI would be a help to tide 3D applications over.
--
Brian
On Sat, 13 Oct 2001, Jos Hulzink wrote:
> On Sat, 13 Oct 2001, Brian S. Julin wrote:
>
> > Heya,
> >
> > Just throwing this to the gallery for comments.
> >
> > We have three new lowlevel libraries which (along with LibGGIMISC)
> > will be forming the core of the intermediate API for the GGI Pro
On Sat, 13 Oct 2001, Brian S. Julin wrote:
> Heya,
>
> Just throwing this to the gallery for comments.
>
> We have three new lowlevel libraries which (along with LibGGIMISC)
> will be forming the core of the intermediate API for the GGI Project,
> LibBuf, LibBlt, and LibOvl.
Great... Congratulat
On Sat, 13 Oct 2001, Andreas Beck wrote:
> > I got more and more mails from users, who are crying for static linking
> > support, for accelerated extension-targets and more. They slowly tend to
> > categorize missing features - such these - as bugs!
>
> Please forward such requests here. I'll try
> I got more and more mails from users, who are crying for static linking
> support, for accelerated extension-targets and more. They slowly tend to
> categorize missing features - such these - as bugs!
Please forward such requests here. I'll try to have a look when I have a
minute.
CU, Andy
--
GI API. It
could help on this one (with a GGI+KGI combination), when it stops hanging
my kernel of course...
Rodolphe
Hi!
This mail is more or less a cry for more help! As you can see, Brian, Eric
and I can do a lot - and it's a great work - , but we can NOT do
everything! We all are overloaded with a big TODO list!
I got more and more mails from users, who are crying for static linking
support
> > dviv program uses simply put pixel routines to write into framebuffer
> If you use the X-target then everything is unaccelerated, because the
> X-target emulates a framebuffer.
> Try the Xlib-target. You can force each ggi program to use a certain
> target by setting the environment variable G
On Sat, 15 Sep 2001, Ingo Krabbe wrote:
> I would appreciate a little bit of help in using ggi. Since I bought my
> real fast Server with a Pixelview GTS2 Pro super fast rendering chip the
> example program dviv I compiled against ggi is working fine but slow. The
> dviv program use
I would appreciate a little bit of help in using ggi. Since I bought my
real fast Server with a Pixelview GTS2 Pro super fast rendering chip the
example program dviv I compiled against ggi is working fine but slow. The
dviv program uses simply put pixel routines to write into framebuffer
memory
I've had a commit pending for two hours now,
"ggidcvs" is locking the archive.
--
Brian
> > You are correct--I meant 0xFF.
> 0xFF == 255, so that would still be black. Are you sure you don't
> mean 65535 aka 0x ?
To make it absolutely clear, you might want to point out, that GGI color
values are always 16 Bit, thus needing a range of 0-65535 for 0-100% of
a color ...
CU, ANdy
Randall <[EMAIL PROTECTED]> writes:
> >
> > > map.r = 0x00; map.b = map.g = 0;
> > > color = ggiMapColor(*(sceenBuf), &map);
> >
> > This is all black.
> >
> > > ggiPutPixel(*(screenBuf), 20, 20, color);
> > > map.b = 255; map.r = map.g = 0;
> >
> > This is also black on practicly
>
> > map.r = 0x00; map.b = map.g = 0;
> > color = ggiMapColor(*(sceenBuf), &map);
>
> This is all black.
>
> > ggiPutPixel(*(screenBuf), 20, 20, color);
> > map.b = 255; map.r = map.g = 0;
>
> This is also black on practicly all supported hardware.
> You don't happen to mean map.b
Randall <[EMAIL PROTECTED]> writes:
> My name is Randall Barber,
> [EMAIL PROTECTED]
>
> I have two open visuals on Linux 6.2 X-Windows. I use one for drawing
> primitives too and the other I use as an interactive color chooser (or I
>
> will). They are named respectively, "screenBuf" and "co
My name is Randall Barber,
[EMAIL PROTECTED]
I have two open visuals on Linux 6.2 X-Windows. I use one for drawing
primitives too and the other I use as an interactive color chooser (or I
will). They are named respectively, "screenBuf" and "colorBuf". The
code follows that I use to open them:
Hi !
> I'm new to GGI. I have some question.
You're welcome.
> Where can I find the information of GGI?
Mainly on the website, and more in-depth information is of course in the
source packages available there.
> Will Libggi work, if I don't install KGI?
Yes. LibGGI will use any g
On Thu, 9 Mar 2000, Angus Chen wrote:
> Hi! everyone:
> I'm new to GGI. I have some question.
> Where can I find the information of GGI?
Go to http://www.ggi-project.org/ and follow the Faqs/Documentation link
at the bottom.
> Will Libggi work, if I don't install KGI?
Yes.
>
Hi! everyone:
I'm new to GGI. I have some question.
Where can I find the information of GGI?
Will Libggi work, if I don't install KGI?
What are the relations between GGI, KGI and XGGI?
ps: I'm not good in speaking or writing English. If I seems to be impolit,
I'm sorry.
> sorry in advance, but we have only one person on aros team (www.aros.org)
> that is handle the x86 port, and it apears some trouble now, it's not
> polite to invite developers on other projects, but i read this list for a
> while and maybe there is someone who here who coul
hi,
sorry in advance, but we have only one person on aros team (www.aros.org)
that is handle the x86 port, and it apears some trouble now, it's not
polite to invite developers on other projects, but i read this list for a
while and maybe there is someone who here who could help us in this
> I downloaded all the stuff and I started to build it all. First I tried
> to build GGI but it moaned about not being able to find GII so then I
> built GII. This library built and installed OK (I can see the correct
> files in /usr/local) but GGI still wouldn't ./configure correctly.
This is
Hi,
I'm looking for a graphics library that can do full 2D accelleration for
my G200 under Linux and I think GGI sounds like the ideal solution.
I downloaded all the stuff and I started to build it all. First I tried
to build GGI but it moaned about not being able to find GII so then I
built GI
> UNIX has some ancient thing called "job control". Programs started as
> _background_ processes (e.g. from a main program) are denied access to
> the TTY (i.e. the VT), they can't write to it or get input. I suppose
> the idea was, programs could be spawned and they shouldn't mess up the
> mai
* Andrew Apted ([EMAIL PROTECTED]) [000131 00:07]:
> Cesar Crusius writes:
>
> > Well people, here's the situation:
> >
> > * I have a gnuplot driver that works in X but fails when in console mode.
> >
> > * I hacked dvgt, so that now *I CAN SEE DVI FILES WITH GGI*. It works in X,
> >
Cesar Crusius writes:
> Well people, here's the situation:
>
> * I have a gnuplot driver that works in X but fails when in console mode.
>
> * I hacked dvgt, so that now *I CAN SEE DVI FILES WITH GGI*. It works in X,
>but then again, IT DOESN'T WORK IN THE CONSOLE!!! And that, of cours
* Marcus Sundberg ([EMAIL PROTECTED]) [000130 02:03]:
> > I believe the error comes from the error message (unable to open shared
> > library genkgi.o) that is sent to the console and garbles everything. But I
> > can't be sure. And I don't have time!
>
> That is not a problem.
I should expect
is what I wanted the dvi viewer for.
>
> HELP!
>
> I believe the error comes from the error message (unable to open shared
> library genkgi.o) that is sent to the console and garbles everything. But I
> can't be sure. And I don't have time!
>
> Can any kind so
'T WORK IN THE CONSOLE!!! And that, of course,
> is what I wanted the dvi viewer for.
>
> HELP!
>
> I believe the error comes from the error message (unable to open shared
> library genkgi.o) that is sent to the console and garbles everything. But I
> can't be sur
viewer for.
HELP!
I believe the error comes from the error message (unable to open shared
library genkgi.o) that is sent to the console and garbles everything. But I
can't be sure. And I don't have time!
Can any kind soul get the sources for dvgt I hacked and figure out how to
mak
equences and poke characters in video memory. The output
> > half now lacks only virtual consoles, scrollback and beeping.
>
> Sounds good. Had you told earlier that you make such a steady progress,
> I probably would not have spent the last days to get the linux console
> wo
> GGI Folks:
>
> A few Hurd folks are making noises about porting KGI/GGI onto the Hurd.
> At one time a few of you were somewhat interested in this, but didn't
> make much progress.
I was, I even have hurd sleeping on my hard drive, but no chance yet
to investigate the possiblities to get KGI p
Brent Fulgham wrote:
> A few Hurd folks are making noises about porting KGI/GGI onto the Hurd.
> At one time a few of you were somewhat interested in this, but didn't
> make much progress.
>
> Can a kind, knowledgable soul join our "debian-hurd" mailing list and
> provide some technical support?
told earlier that you make such a steady progress,
I probably would not have spent the last days to get the linux console
working.
(Are you subscribed to bug-hurd? You must have noticed my screams for help
:)
> > What you mean should probably be handled by a device similar to
framebuffer
> &
43 matches
Mail list logo
