Re: ggi2dDrawArc, ggi2dFillArc
On Fri, Mar 10, 2000 at 03:18:15PM +0100, Christoph Egger wrote: On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote: Hi ! At least, I know I will need _exactly_ these drawing functions to have _all_ the rendering capabilities required for the OpenAmulet GUI library. Could you give an API wishlist ? I might attack reimplementing LibGGI2D in a way that makes it more consistent with the other extensions and allowing to HW-Accelerate much of it. I wish to have: int ggiStrechCrossBlit(ggi_visual *src, int sx, int sy, int sw, int sh, ggi_visual *dst, int dx, int dy, int dw, int dh); It should does the same as ggiCrossBlit, except it also performs streching. i haven't followed the discussion, but ... Streching with or without CrossBlit comes down to the same accel on some gfx-cards. it would save one accel if we would have such a combined command. But I think, this should go into libggi and not libggi2d... Comments? Christoph Egger E-Mail: [EMAIL PROTECTED] thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: Silly Ideas?
"Brian S. Julin" [EMAIL PROTECTED] writes: On Fri, 3 Dec 1999, Ketil Froyn wrote: Second, and maybe a little more realistic, I was wondering about a 'sample' target. This could for example be an extension to file, where the screen is drawn to different files at the specified frequency. Would be excellent for grabbing screens to make animations. There is a sample "extension" in the libedemo directory. I think he meant sample as in sampling images, not sample as in example. ;) Doesn't the file target provide the capability to write several images already btw? //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
On Sat, 11 Mar 2000, teunis wrote: [on reimplementation of libGGI2D] On Fri, 10 Mar 2000, Andreas Beck wrote: [clip] - There is an urgent need for 2D drawing functionality by several groups. - LibGGI2D is unmaintained and doesn't carry the usual GGI License. So please - those who need it: Get together and rewrite it. Specify all your needs and make a header-style proposal. A few proposals to get you started: - ROP 256 What's this mean? Microsoft's Win32 ROP256 standard. Look in any windows programming book. - arbitrary length patterns for lines and background. - ggi2D equivalents of all LibGGI drawing primitives that obey the extended markups above. - triangles, trapezoids (PM2 can accelerate aligned trapezoids) polygons, arbitrarily positioned ellipses and arcs - rounded-edge rectangles ? special case of circle draw. Really quite simple. - spline/bezier shapes ? Okay a little more complicated. Okay a lot. Look how Java 2.0 handles this one it's not too bad... - streched (Cross-)blitting. Frequently accelerated. BITBLT's are almost -always- accelerated though. I would -love- to see a pipeline proposal: how to handle rendering pipeline. AKA OpenGL's specs :) You have already seen mine, it is LibGGI3D I'm not saying OpenGL is the best way of looking at things... but that style's quite suitable to most accels + most libs. something like: [complex command] - handle clipping; can insert "stencil" bitop to for this...; - [select bitop] - [run series of render-ops] I dunno. The GL state-machine thing is designed the way it is because it was designed to be embedded into hardware. 2D hardware acceleration is not nearly as consistently designed as 3D hardware, usually it is a crazy-quilt of different ways to do things. The only stuff that's really common is the 8514/A style 2D accel set. What this all means is that, unlike GL, we don't have a nice abstraction of a rendering pipeline to stuff everything into. We have to tune the nature of the pipeline code to the hardware in order to optimize it, and having one standard type of 2D graphics pipeline would be too restrictive. X is a good example of why this is bad. bitop - eg. AND/XOR/OR/... + bitmasks... renderops - simpler render commands that are usually acceled. Like lines. And points. And rectangular fills... And BITBLT's. Multisource blits with generic and extensible ROPs can take care of most of that stuff. (and the only request I have for clipping is... Be able to handle stencils and rectangular clipping regions and be able to draw onto stencils :) Sure. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
New (next) problem...
With a new cvs extraction and build I get the following:
Making all in gg
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..
-DBUILDING_LI
BGG -I../include -I../include -I/usr/local/include
-I/usr/local/include -g -
O2 -D_REENTRANT -D_THREAD_SAFE -g -Wall -c misc.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -DBUILDING_LIBGG -I../include
-I../include -I/u
sr/local/include -I/usr/local/include -g -O2 -D_REENTRANT
-D_THREAD_SAFE -g -Wal
l -Wp,-MD,.deps/misc.pp -c -DDLL_EXPORT -DPIC misc.c -o misc.lo
misc.c:68: #error You need to implement ggUSleep() for this system
misc.c:72: #error You need to implement ggCurTime() for this system
this comes from these lines in misc.c
#ifndef GG_USLEEP_DEFINED
#error You need to implement ggUSleep() for this system
#endif
#ifndef GG_CURTIME_DEFINED
#error You need to implement ggCurTime() for this system
#endif
GG_USLEEP_DEFINED and GG_CURTIME_DEFINED are in acconfig.h.
/* Define if ggUSleep is a #define in ggi/system.h */
#undef GG_USLEEP_DEFINED
/* Define if ggCurTime is a #define in ggi/system.h */
#undef GG_CURTIME_DEFINED
So both ggUSleep and ggCurTime are "undefined"
However, from ggi/system.h
__BEGIN_DECLS
#define ggUSleep(val) do {struct timeval tv; tv.tv_sec=(val)/100;
tv.tv_usec=(val)%100; select(0, NULL, NULL, NULL, tv);} while(0);
__END_DECLS
__BEGIN_DECLS
#define ggCurTime(tv) do{ SYSTEMTIME stim; GetSystemTime(stim);
(tv)-tv_sec = stim.wSecond;tv)-tv_usec = stim.wMilliseconds*1000;
}while(0)
__END_DECLS
However, even after I #defined these values it didn't work. This is
because I can find no file which includes acconfig.h anywhere.
Any ideas??
John
Re: ggi not working over X?
Randolph Chung [EMAIL PROTECTED] writes: Hi all, I ran into an odd problem today. I wrote a simple ggi-based program that draws 1e6 boxes to the screen and time how long it takes (hey, it's my first ggi program :P) Strangely enough, it works locally, but not if I run it on another machine and do a remote X display to my box. What happens? What OSes/machines are involved? Full GGI_DEBUG=255 log would be useful. Is this intentional/a known problem? No, it works fine, and should do so with 2.0 beta2.1 as well. I tried running with GGI_DEBUG=255... one thing that seems odd: LibGGI: X: Creating shm image #0 LibGGI: X: shmat success at 0x401e1000. LibGGI: X: XShmAttach failed - trying without shm does that matter? No, it's just normal behaviour when running remote. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
New 2D Spec
"Jon M. Taylor" wrote: So please - those who need it: Get together and rewrite it. Specify all your needs and make a header-style proposal. Will do, just gimme some time over the weekend OK? Cool. If Jon is willing to provide the vision on a new 2D spec, I am willing to provide some of the grunt programming labor. And in case you can't guess my most important requirement for any new 2D library... it needs a fast, fexible blit function that can handle transparancy. :-) Later, Thad
Re: gui stuff
Ian Molton [EMAIL PROTECTED] writes: Also, I think (if it doesnt already) libGGI2d should support all of its drawing types in antialiased variants as well. Antialiased drawing is farther away from normal 2D drawing than OpenGL is, and should definitely go into a separate library. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
"Jon M. Taylor" [EMAIL PROTECTED] writes: Sure. I'll try to collect all the ideas from the mailing list archives and come up with a proposal over the weekend. Is there still any interest in the LibXMI idea, or should I assume that we are trying to design the ideal 2D library from the ground up? LibXMI is a rasterization library, not a drawing library. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: gui stuff
On 11 Mar 2000, Marcus Sundberg wrote: Ian Molton [EMAIL PROTECTED] writes: Also, I think (if it doesnt already) libGGI2d should support all of its drawing types in antialiased variants as well. Antialiased drawing is farther away from normal 2D drawing than OpenGL is, and should definitely go into a separate library. hey - can ya -prove- this statement? :) Antialiasing is required by a lot of font software... ... now it'd be reasonable to just use the font software's own antialiasing (thinking freetype family here). I'm not actually sure that antialiasing is all that in use outside of fonts and some imaging apps. Comments? G'day, eh? :) - Teunis
Re: gui stuff
teunis wrote: Antialiasing is required by a lot of font software... ... now it'd be reasonable to just use the font software's own antialiasing (thinking freetype family here). I'm not actually sure that antialiasing is all that in use outside of fonts and some imaging apps. Comments? Can you think of a font engine *not* doing the anti aliasing itself ? Font engines will do the rasterization internally (to get the hinting right for example) so I don't know when this can be outsourced into an external drawing library... Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: gui stuff
teunis [EMAIL PROTECTED] writes: On 11 Mar 2000, Marcus Sundberg wrote: Ian Molton [EMAIL PROTECTED] writes: Also, I think (if it doesnt already) libGGI2d should support all of its drawing types in antialiased variants as well. Antialiased drawing is farther away from normal 2D drawing than OpenGL is, and should definitely go into a separate library. hey - can ya -prove- this statement? :) Antialiasing is required by a lot of font software... ... now it'd be reasonable to just use the font software's own antialiasing (thinking freetype family here). I'm not actually sure that antialiasing is all that in use outside of fonts and some imaging apps. Comments? Well, fonts do not belong in LibGGI2D. And antialiased drawing doesn't belong there it is not hardware accelerated (on most hardware, IIRC I've heard about next generation 3D-cards supporting antialiased edges), and because the software implementations would be very different from normal 2D drawing. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: DLLEXT problems
John Fortin [EMAIL PROTECTED] writes:
It gives i386-mingw32 for ${target}
configure --host=i386-mingw32 --build=i386-mingw32 --target=i386-mingw32
--without-x \
--enable-directx --prefix=e:/usr/local --with-gii=/usr/local \
--with-extra-libs=/usr/local/lib
--with-extra-includes=/usr/local/include
With the above command I get the following...
checking host system type... i386-pc-mingw32
checking build system type... i386-pc-mingw32
Why isn't ${target} converted to i386-pc-mingw32??
I changed the dllext.m4 macro to test for *-mingw* | *-cygwin* and it
works. But I don't want to commit it until I understand the above
question.
It was really a mistake on my side - please change ${target} to
${host} and it should work. target is only for things like binutils,
gcc and gdb.
I'll commit this as soon as CVS is back up.
//Marcus
--
---+
Marcus Sundberg| http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: DLLEXT problems
Marcus Sundberg wrote:
John Fortin [EMAIL PROTECTED] writes:
It gives i386-mingw32 for ${target}
configure --host=i386-mingw32 --build=i386-mingw32 --target=i386-mingw32
--without-x \
--enable-directx --prefix=e:/usr/local --with-gii=/usr/local \
--with-extra-libs=/usr/local/lib
--with-extra-includes=/usr/local/include
With the above command I get the following...
checking host system type... i386-pc-mingw32
checking build system type... i386-pc-mingw32
Why isn't ${target} converted to i386-pc-mingw32??
I changed the dllext.m4 macro to test for *-mingw* | *-cygwin* and it
works. But I don't want to commit it until I understand the above
question.
It was really a mistake on my side - please change ${target} to
${host} and it should work. target is only for things like binutils,
gcc and gdb.
I'll commit this as soon as CVS is back up.
OK, thanks,
John
Re: DLLEXT problems
configure --host=i386-mingw32 --build=i386-mingw32 --target=i386-mingw32
...
With the above command I get the following...
checking host system type... i386-pc-mingw32
checking build system type... i386-pc-mingw32
Why isn't ${target} converted to i386-pc-mingw32??
I assume because you explicitly give it on the commandline which probably
takes precedence over any autoprobed value.
CU, ANdy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
- triangles, All flat, no perspective stuff? trapezoids (PM2 can accelerate aligned trapezoids) So can Trio64 and up. polygons, Should this be different from triangles? We'll have to decompose the polygons into triangles or triangle fans in many cases anyway, in order to accelerate them efficiently with some hardware. DrawPolygon(vis, triangle, ...) is just a degenerate case of this. Same for triangle strips. ATI 128 cards support these. - spline/bezier shapes ? What hardware accelerates these? Infinite Reality engines. I think SGI visual workstations did as well. Can't remember.
Re: DLLEXT problems
Andreas Beck wrote:
configure --host=i386-mingw32 --build=i386-mingw32 --target=i386-mingw32
...
With the above command I get the following...
checking host system type... i386-pc-mingw32
checking build system type... i386-pc-mingw32
Why isn't ${target} converted to i386-pc-mingw32??
I assume because you explicitly give it on the commandline which probably
takes precedence over any autoprobed value.
That is what I initially thought. However, host and build got converted
from i386-mingw32 to i386-pc-mingw32
and I gave them on the command line, also.
Seems inconsistent to me.
John
