Menu
▾
▴
libvisual-devel — libvisual mailinglist for developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(38) |
May
(22) |
Jun
(92) |
Jul
(101) |
Aug
(18) |
Sep
(286) |
Oct
(180) |
Nov
(73) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(18) |
Feb
(74) |
Mar
(56) |
Apr
(11) |
May
(5) |
Jun
(4) |
Jul
(20) |
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2006 |
Jan
(11) |
Feb
(2) |
Mar
(10) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(24) |
Aug
(11) |
Sep
(5) |
Oct
(16) |
Nov
(25) |
Dec
(8) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|
From: Dennis S. <sy...@yo...> - 2004-04-21 18:34:37
|
On Wed, 2004-04-21 at 19:34 +0300, Vitaly V. Bursov wrote: > patch againts scivi 0.2.0rc3 is here > http://xmms-scivi.sf.net/scivi-to-libvisual.patch.bz2 > > it's a hack and there are few lines of libvisual code. > > > like the idea of modelling our own event system to that off SDL ? > Well, can't say nothing bad about SDL's event system. > > One thing: what kind of events will be passed? You've already "grabbed" > some keyboard keys ('a' and 's' for example) what should be passed to > plugin if 'a' was pressed? plugin gets cleanup request now ;) > It looks logical to make plugin define a list (description) > of events it want to receive. > > List can be composed from event id predefined by libvisual for generic events > like prev/next preset, visualization mode, window resize, etc. or > plugin defined id's. In a last case plugin must supply description, > default binded key for keyboard events. Libvisual then will have > confugurable keyboard bindings which user can change as he/she likes. This might be an idea, however the a and s key are catches in the xmms plugin and not in libvisual, but i think it's a nice idea to have events like 'switch' and being able to bind this to an key. Good idea! > > For the rest my plan of abuse for the upcoming weeks looked good ? > AFAIR, yes. A huge TODO :) Yeah, with some luck i've got loads of time!, i saw at the project-m page that sdl-1.3, or better sdl cvs DOES support off screen render buffers for gl, you might want to check that out. We'll be looking in the whole gl issue after i'am done with the presented TODO list for the upcoming weeks. It's good to have an gl knowit onboard so this gets fixed good :) Cheers, Dennis |
|
From: Vitaly V. B. <vit...@uk...> - 2004-04-21 16:34:31
|
On Wed, 21 Apr 2004 14:45:22 +0200 Dennis Smit <sy...@yo...> wrote: > On Tue, 2004-04-20 at 15:44 +0300, Vitaly V. Bursov wrote: > > I've a kinda ported scivi to libvisual. It runs under libvisual xmms plugin. > > In different window :) All mouse/keyboard events are also ok both for libvisual > > and scivi :-) > Wow that is promising! can i see some code ? :), also how have you been > implementing the key/mouse events in the libvisual window, and do you I haven't, there are two windows. one is libvisual and another scivi :) patch againts scivi 0.2.0rc3 is here http://xmms-scivi.sf.net/scivi-to-libvisual.patch.bz2 it's a hack and there are few lines of libvisual code. > like the idea of modelling our own event system to that off SDL ? Well, can't say nothing bad about SDL's event system. One thing: what kind of events will be passed? You've already "grabbed" some keyboard keys ('a' and 's' for example) what should be passed to plugin if 'a' was pressed? plugin gets cleanup request now ;) It looks logical to make plugin define a list (description) of events it want to receive. List can be composed from event id predefined by libvisual for generic events like prev/next preset, visualization mode, window resize, etc. or plugin defined id's. In a last case plugin must supply description, default binded key for keyboard events. Libvisual then will have confugurable keyboard bindings which user can change as he/she likes. Plugin will not get events like "key 'p' was pressed" but will get SWITCH_PRESET event. > For the rest my plan of abuse for the upcoming weeks looked good ? AFAIR, yes. A huge TODO :) -- Vitaly GPG Key ID: F95A23B9 -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-04-21 12:46:35
|
When sitting on #xmms i saw someone pasting the following link: http://xmms-projectm.sourceforge.net/ It's an milkdrop implementation under linux and it looks very promising, ofcourse i mailed the author and told him about libvisual. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-04-21 12:45:35
|
On Tue, 2004-04-20 at 15:44 +0300, Vitaly V. Bursov wrote: > > This is it for now, after those weeks offline i want to dive into > > openGL problems, and how we can make the framework rock for opengl > > plugin as well, i'll need a lot of help this because i'm basicly > > an opengl clueless person. I think Vitaly might be of great help > > here *hint hint* :) > > I've a kinda ported scivi to libvisual. It runs under libvisual xmms plugin. > In different window :) All mouse/keyboard events are also ok both for libvisual > and scivi :-) Wow that is promising! can i see some code ? :), also how have you been implementing the key/mouse events in the libvisual window, and do you like the idea of modelling our own event system to that off SDL ? > I think that supplying X Window identifier, rendering, position, > viewport size should be sufficient nearly for any purpose. > And of course resize events etc. > > Optionally (or as a general rule) plugin can use some higher level > API (e.g. placed in libvisual) for framebuffer in system ram or some > render-ready OpenGL context. Ok we've got to look into this, i could use some help here admittable ;) For the rest my plan of abuse for the upcoming weeks looked good ? Cheers, Dennis |
|
From: Vitaly V. B. <vi...@ma...> - 2004-04-20 12:47:13
|
On Mon, 19 Apr 2004 21:48:02 +0200 Dennis Smit wrote: > * Random: > - FPS timing and caps helper functions. You may try to use Scivi's FPS controls near fpsctl.c It should be simple to rip it off. > This is it for now, after those weeks offline i want to dive into > openGL problems, and how we can make the framework rock for opengl > plugin as well, i'll need a lot of help this because i'm basicly > an opengl clueless person. I think Vitaly might be of great help > here *hint hint* :) I've a kinda ported scivi to libvisual. It runs under libvisual xmms plugin. In different window :) All mouse/keyboard events are also ok both for libvisual and scivi :-) I think that supplying X Window identifier, rendering, position, viewport size should be sufficient nearly for any purpose. And of course resize events etc. Optionally (or as a general rule) plugin can use some higher level API (e.g. placed in libvisual) for framebuffer in system ram or some render-ready OpenGL context. -- Vitaly |
|
From: Dennis S. <sy...@yo...> - 2004-04-19 19:51:53
|
Heya, Well since i'm in the middle of a move i will be offline for a few weeks starting thursday, maybe friday. I will have access to my computer so development won't stop! I want to discuss a few items that i'd like others to give a thought about before i start implementing during the time offline. * Events: I want to make an event system for several kinds of events. Being user input events like keyboard and mouse and videosize events for now. I want to model the event system like that off SDL. If someone has a better idea on this and/or more suggestions for events that should be included please comment. * Song info: It would be nice to have a system that sets song info like songname, artist, album, time elapsed etc etc, i haven't yet thought about this so if someone can come up with a nice API *Woohoo* :) * Morph plugins: I've already discussed this with JC in private, the general idea around morph plugins is that they allow transistion from one plugin to another, the api is very easy and clean so i won't add much to this, if someone has a comment anyway go ahead. * Internal changes: Currently i let the application developer manage the plugin lists, i want to move this into an visual_init and visual_quit that does this for you, i will add extra api calls that allows the developer to merge multiple plugin paths into one plugin registry list. * Audio: Most notable change to the audio framework is that it'll include both a future and history buffer. * Random: - Function to detect mmx, sse. - FPS timing and caps helper functions. * Auto scheduler: I might start on the effect auto scheduler which provides auto mated mixing, switching and morphing of plugins hinted using the plugin SCHED flags. Not sure how much time i'll put into it at this moment tho, we'll see. * Plugin: More general framework for loading plugins, instead of a plugin framework for every plugin type. This is it for now, after those weeks offline i want to dive into openGL problems, and how we can make the framework rock for opengl plugin as well, i'll need a lot of help this because i'm basicly an opengl clueless person. I think Vitaly might be of great help here *hint hint* :) Please if you have comments comment fast, i'll be offline for a few weeks after this week. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-04-18 21:53:35
|
On Mon, 2004-04-19 at 00:47 +0300, Vitaly V. Bursov wrote: > Sun, 18.04.2004, 23:50, Dennis Smit wrote: > > On Sun, 2004-04-18 at 23:16 +0300, Vitaly V. Bursov wrote: > > > > > Thanks for checking out btw, did you also try libgoom ? > > > > JC hasn't yet uploaded a new snapshot at the goom page > > > > but you could try: > > > > http://www.plasser.nl/synap/libvisual/snapshots/goom2k4-dev15-pre-synap.tar.gz > > > > > > > > for now. > > > Goom segfaults. Can't tell more for now. > > Hmms alright, a stacktrace would be great, also > Looks like removing -O9 from CFLAGS (to build a clean debug-ready > version) solved problem. Suspect a gcc 3.2.3 bug :) > but things are still unstable a bit. > > > on what architecture are you ? > Athlon XP, VIA KT400, GeForce2 MX 400 > Linux 2.6.5 :) > Odd odd, it's working flawless here, and i run it all the time for several weeks already, hope it'll get better over time :) |
|
From: Vitaly V. B. <vi...@ma...> - 2004-04-18 21:46:44
|
Sun, 18.04.2004, 23:50, Dennis Smit wrote: > On Sun, 2004-04-18 at 23:16 +0300, Vitaly V. Bursov wrote: > > > Thanks for checking out btw, did you also try libgoom ? > > > JC hasn't yet uploaded a new snapshot at the goom page > > > but you could try: > > > http://www.plasser.nl/synap/libvisual/snapshots/goom2k4-dev15-pre-syn= ap.tar.gz > > >=20 > > > for now. > > Goom segfaults. Can't tell more for now. > Hmms alright, a stacktrace would be great, also Looks like removing -O9 from CFLAGS (to build a clean debug-ready version) solved problem. Suspect a gcc 3.2.3 bug :) but things are still unstable a bit. > on what architecture are you ? Athlon XP, VIA KT400, GeForce2 MX 400 Linux 2.6.5 :) |
|
From: Dennis S. <sy...@yo...> - 2004-04-18 20:50:42
|
On Sun, 2004-04-18 at 23:16 +0300, Vitaly V. Bursov wrote: > Oh, the problem is that LIBVISUAL_CFLAGS=/prefix/include/libvisual > while it should be LIBVISUAL_CFLAGS=/prefix/include Thanks a lot, fixed locally and will be included in the next snapshot. I'll start importing my local CVS trees into the sourceforge trees soon, however after this week i'll lack internet connectivity for half a month, or more. (Moving to a new house) > > Thanks for checking out btw, did you also try libgoom ? > > JC hasn't yet uploaded a new snapshot at the goom page > > but you could try: > > http://www.plasser.nl/synap/libvisual/snapshots/goom2k4-dev15-pre-synap.tar.gz > > > > for now. > Goom segfaults. Can't tell more for now. Hmms alright, a stacktrace would be great, also on what architecture are you ? Cheers, Dennis |
|
From: Vitaly V. B. <vi...@ma...> - 2004-04-18 20:15:48
|
Sun, 18.04.2004, 21:03, Dennis Smit wrote:
> On Sun, 2004-04-18 at 20:53 +0300, Vitaly V. Bursov wrote:
> > There is a minor problem during compilation process. CFLAGS do not
> > contain -I${prefix_with_libvisual}/include directive, so I have to edit
> > Makefile.am files.
>=20
>=20
> Hmms that is quite odd seen it takes the CFLAGS from pkg-config
>=20
> AC_SUBST(CFLAGS, "-I./ -O3 -rdynamic -ggdb $LIBVISUAL_CFLAGS $GTK_CFLAGS
> -I$prefix/include/xmms $SDL_CFLAGS")
>=20
> If you're able to debug this it would be great!
Oh, the problem is that LIBVISUAL_CFLAGS=3D/prefix/include/libvisual
while it should be LIBVISUAL_CFLAGS=3D/prefix/include
> Thanks for checking out btw, did you also try libgoom ?
> JC hasn't yet uploaded a new snapshot at the goom page
> but you could try:
> http://www.plasser.nl/synap/libvisual/snapshots/goom2k4-dev15-pre-synap.t=
ar.gz
>=20
> for now.
Goom segfaults. Can't tell more for now.
> Does 'a' and 's' keys also work ?
Yes.
--
Vitaly
|
|
From: Dennis S. <sy...@yo...> - 2004-04-18 18:03:32
|
On Sun, 2004-04-18 at 20:53 +0300, Vitaly V. Bursov wrote:
> Sun, 18.04.2004, 19:52, Dennis Smit wrote:
>
> > >PLEASE< test. I haven't yet seen a test report and i'd really
> > like to know how things are working.
> It works.
>
> xmms-1.2.8
> SDL-1.2.5a
>
> There is a minor problem during compilation process. CFLAGS do not
> contain -I${prefix_with_libvisual}/include directive, so I have to edit
> Makefile.am files.
Hmms that is quite odd seen it takes the CFLAGS from pkg-config
AC_SUBST(CFLAGS, "-I./ -O3 -rdynamic -ggdb $LIBVISUAL_CFLAGS $GTK_CFLAGS
-I$prefix/include/xmms $SDL_CFLAGS")
If you're able to debug this it would be great!
Thanks for checking out btw, did you also try libgoom ?
JC hasn't yet uploaded a new snapshot at the goom page
but you could try:
http://www.plasser.nl/synap/libvisual/snapshots/goom2k4-dev15-pre-synap.tar.gz
for now.
Does 'a' and 's' keys also work ?
Cheers,
Dennis
|
|
From: Vitaly V. B. <vi...@ma...> - 2004-04-18 17:53:24
|
Sun, 18.04.2004, 19:52, Dennis Smit wrote:
> >PLEASE< test. I haven't yet seen a test report and i'd really
> like to know how things are working.
It works.
xmms-1.2.8
SDL-1.2.5a
There is a minor problem during compilation process. CFLAGS do not
contain -I${prefix_with_libvisual}/include directive, so I have to edit
Makefile.am files.
--
Vitaly
|
|
From: Dennis S. <sy...@yo...> - 2004-04-18 16:52:23
|
Hello people, I've written most of the xmms libvisual plugin this afternoon and it's available at libvisual.sf.net It'll need the latest snapshots of libvisual and libsdl + the ussual xmms stuff. Resize is borked due to libvisual borkage, will be fixed in the 0.1 release. To switch visual plugins press 'a' or 's' within the plugin window. >PLEASE< test. I haven't yet seen a test report and i'd really like to know how things are working. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-04-16 21:26:38
|
Heya people!
I'd like to have a standard datapath for plugins that install data
files like images, presets, whatever.
I was thinking about
%{prefix}/share/libvisual/plugins/actor/blah/
For settings there'll be a very simple 'registry' system.
This sounds more scary than it'll actually be, however this
is not going to be happen any moment so if someone wants to
write a basic registry system, please do so :)
Please comment with suggestions, and if you agree or disagree
with my plan of approach!
Cheers,
Dennis
|
|
From: Dennis S. <sy...@yo...> - 2004-04-16 19:14:00
|
Thanks for pointing out Gustavo!,
I'm not 100% sure if it's actually in libtool or auto* or in mine
stuff but i have no idea how i could fix it anyway, because all the
build stuff is auto* generated. If someone knows a solution please
tell us!
On Fri, 2004-04-16 at 16:05 -0300, Gustavo Sverzut Barbieri wrote:
> Just to let everybody know, there is a bug in auto* stuff that doesn't let you
> build these packages in a workdir with spaces " " in the filename. It's not
> in libvisual, but in the auto{make, conf} & libtool, but anyway, I had
> problems with that and did take some time to find out. Thanks Dennis for
> helping me find the source of the problem :)
>
> --
> Gustavo Sverzut Barbieri
|
|
From: Gustavo S. B. <gu...@gs...> - 2004-04-16 19:08:10
|
Em Qui 15 Abr 2004 19:43, Dennis Smit escreveu:
> I've released libvisual and libvisual-plugins 0.1-pre3:
>
> What is new ?
>
> Libvisual:
> Some minor buildtree fixes in libvisual.
>
> Libvisual-plugins:
> Major buildtree fixes and cleanups, it's now detecting all
> needed libs, compiling only stuff that it can compile etc etc.
Just to let everybody know, there is a bug in auto* stuff that doesn't let you
build these packages in a workdir with spaces " " in the filename. It's not
in libvisual, but in the auto{make, conf} & libtool, but anyway, I had
problems with that and did take some time to find out. Thanks Dennis for
helping me find the source of the problem :)
--
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
ICQ#: 17249123
GPG: 0xB640E1A2 @ wwwkeys.pgp.net
|
|
From: Dennis S. <sy...@yo...> - 2004-04-16 14:08:56
|
Well, 0.1 pre3 seems to work quite well this far, however people
please test and report on the list ;)!
Gustavo can compile goom2. JC, this was because there was a space
in his build path, not sure why that bugs but everything is auto
generated so i can't do something about that, atleast not that
i know off.
I think it's time to explain the basics about the application API.
This is especially for Gustavo who is going to make python bindings
and freevo support.
_____
Basic application api summary:
Libvisual consists (at this moment) of two 'stacks'.
That is the 'actor' (visual plugin) stack and
the 'input' (pcm data plugin) stack.
The actor consists out of VisActorPlugin which is completely abstracted
in an VisActor. The VisActor type is the high end application type for
an actor. To run an actor on screen you'll also need an VisVideo which
holds data like, width, height, bpp, pointer to screenbuffer, depth.
The input consists out of VisInputPlugin which is also completely
abstracted in VisInput. The VisInput type is the high end application
type for an input plugin. To process audio data you'll also need an
VisAudio which holds the pcm data, fft analyzer data, and some more
stuff like audio energy, in the future it'll contain more audio analyse
data.
To automaticly pump input data to the actor and run both input
plugin and actor plugin you'll need an VisBin. A VisBin is an container
to pack the actor and input in.
API that is needed for an basic app:
VisActor *actor; /* The actor type */
VisVideo *video; /* The video information type */
VisList *actlist; /* The actor plugin list */
VisPalette *pal = NULL; /* Palette for 8 bits mode */
VisInput *input; /* The input type */
VisList *inlist; /* The input plugin list */
VisBin *bin; /* The container type */
____
int depth;
int bpp;
Create an actor plugin:
/* give plugin path or NULL for default
* The actlist should not be destroyed before termination
* of the render pipe, this is because the list contains
* the references to the plugins and the ref count
*/
actlist = visual_actor_get_list (NULL);
/* Load the goom visual into the actor */
actor = visual_actor_new (actlist, "goom");
/* Goom couldn't be loaded */
if (actor->plugin == NULL)
exit (-1);
/* Get the highest supported depth by the plugin */
depth = visual_actor_depth_get_highest (actor);
/* init video before visual_actor_realize
* this is so opengl plugins can do opengl
* init magic in their plugin init function
*/
/* startup the plugin */
visual_actor_realize (actor);
/* Create a new video context information holder */
video = visual_video_new ();
/* Link it to the actor */
visual_actor_set_video (actor, video);
/* Set the depth on the video context */
visual_video_set_opts (video, "depth", depth);
/* Set the size on the video context,
* WARNING: The api for this will change in 0.2 */
visual_video_set_dimension (video, width, height);
/* Negotiate the actor and video, if needed it'll set up
* depth transformation, size transformation here
* Size nego is broken in pre3 tho, so you're warned about that */
if (visual_actor_video_negotiate (actor) == -1)
exit (-1);
/* It's now time to allocate a buffer for the plugin to draw in */
bpp = visual_video_bpp_from_enum (depth);
/* you can also use video->bpp btw */
scrbuf = malloc (video->size * bpp);
memset (scrbuf, 0, video->size * bpp);
/* Connect the buffer to the video */
visual_video_set_buffer (video, scrbuf);
/* Get the input plugin list, same goes for actor, don't free
* the list till destroying all your render stuff */
inlist = visual_input_get_list (NULL);
/* Create the input plugin */
input = visual_input_new (inlist, "esd");
/* Create an container */
bin = visual_bin_new ();
/* Pack the actor and input in the container */
visual_bin_connect (bin, actor, input);
/* Realize the bin and it's childeren, all that already
* is realized won't be realized again */
visual_bin_realize (bin);
/* remember for opengl you need a special case, check
* libvisual-0.1/examples/simplesdl.c how this works */
while (render_eyecandy) {
/* Run the pipeline */
visual_bin_run (bin);
/* Retrieve palette info */
pal = visual_actor_get_pal (actor);
if (pal != NULL)
/* Use your own function here to
* set the pal for your screen target
* pals can be accessed by:
* pal->r[0..255], ->g[0..255], b->[0..255] */
set_pal (pal);
/* Your own function that draws on your screen target
* the image buffer is in video->screenbuffer */
draw_screen (video);
}
On resize:
visual_video_set_dimension (video, width, height);
visual_actor_video_negotiate (actor);
/* Free and malloc the buffer as done on the initialize. */
...
/* And add the new buffer */
visual_video_set_buffer (video, scrbuf);
On exit:
/* Destroy the bin, and it's childeren */
visual_bin_destroy (bin);
/* free the video, you can use visual_video_free_with_buffer
* to free the screenbuffer as well */
visual_video_free (video);
/* Destroy the plugin, and reference lists */
visual_actor_list_destroy (actlist);
visual_input_list_destroy (inlist);
List of actor plugins:
___
VisPluginRef *ref;
VisList *list;
VisListEntry *entry = NULL;
list = visual_actor_get_list (NULL);
while ((ref = visual_list_next (list, &entry)) != NULL) {
printf ("Plugin ref: %s %s %d\n",
ref->file, ref->name, ref->usecount);
}
___
There is also an API to get more info from the plugin like,
author, about, help but the api is not yet set in stone
so wait till 0.2 for that ;)
I hope the explanation is kinda clear, but if there are any
questions just shoot, i'll be glad to answer. Also if there
are comments on the API, things that are rather seen
differently, please comment as well!
Cheers,
Dennis
|
|
From: Dennis S. <sy...@yo...> - 2004-04-15 22:43:10
|
I've released libvisual and libvisual-plugins 0.1-pre3: What is new ? Libvisual: Some minor buildtree fixes in libvisual. Libvisual-plugins: Major buildtree fixes and cleanups, it's now detecting all needed libs, compiling only stuff that it can compile etc etc. __ To compile goom you'll need an not yet released goom version, so wait a few days for that :) *** This needs testing, the build trees won't change much for 0.1 *** Please test and report back how these two packages are doing, they're avaiable at http://libvisual.sf.net Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-04-15 11:58:36
|
Libvisual currently have two plugin types, that is the actor plugins for the visualisation and the input plugins to easily retrieve samples. Also it supports an callback method for the input layer so the application developer can implement his own upload callback I'd like to extend this with Transformation plugins that are special plugins that can morph two actors from one to another, or mix them at any percentage in the morphing process. I haven't yet put a lot of thought in it so i'd like to see some suggestions and what kind of methods would be handy in the plugin. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-04-15 11:54:50
|
Heya JC, Welcome to the list! On Thu, 2004-04-15 at 10:17 +0100, Jean-Christophe Hoelt wrote: > Hi the list ! |
|
From: Jean-Christophe H. <ho...@tc...> - 2004-04-15 09:17:57
|
Hi the list ! |
|
From: Dennis S. <sy...@yo...> - 2004-04-14 17:47:14
|
I've disabled the build of goom2 in the current snapshots, i'll be adding an goom2.pc file to the goom source tree this evening and detect it within libvisual-plugins. Cheers, Dennis On Wed, 2004-04-14 at 14:01 -0300, Gustavo Sverzut Barbieri wrote: > Em Ter 13 Abr 2004 20:58, Dennis Smit escreveu: > > libvisual-plugins build will probably fail while building when > > libgoom2k4-devel-15 isn't present. Either download this or > > work around the error by hand. > > It will fail. Just edit: > > ./plugins/actor/Makefile > > and remove reference to goom2 in SUBDIR line. > > -- > Gustavo Sverzut Barbieri > --------------------------------------- > Engenharia de Computacao 2001 - UNICAMP > GPSL - Grupo Pro Software Livre > Cell..: +55 (19) 9165 8010 > Jabber: gsb...@ja... > ICQ#: 17249123 > GPG: 0xB640E1A2 @ wwwkeys.pgp.net > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Libvisual-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libvisual-devel |
|
From: Gustavo S. B. <gu...@gs...> - 2004-04-14 17:03:33
|
Em Ter 13 Abr 2004 20:58, Dennis Smit escreveu: > libvisual-plugins build will probably fail while building when > libgoom2k4-devel-15 isn't present. Either download this or > work around the error by hand. It will fail. Just edit: ./plugins/actor/Makefile and remove reference to goom2 in SUBDIR line. -- Gustavo Sverzut Barbieri --------------------------------------- Engenharia de Computacao 2001 - UNICAMP GPSL - Grupo Pro Software Livre Cell..: +55 (19) 9165 8010 Jabber: gsb...@ja... ICQ#: 17249123 GPG: 0xB640E1A2 @ wwwkeys.pgp.net |
|
From: Dennis S. <sy...@yo...> - 2004-04-14 01:30:57
|
0.1 pre2 online. Some quick fixes to fix building and compiling! Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-04-13 23:58:39
|
I have put online the 0.1 pre1 snapshots for both libvisual and libvisual-plugins. They can be found at http://libvisual.sf.net Both packages are now almost completely auto* ready and libvisual generates an pkg-config file. To be done before 0.1 libvisual-plugins: More and better library detection to see which plugins can be build. Small bugfixes. libvisual: Fix the transparant size negotation stuff, it's very much broken right now. If you see crashes and weirdness on resizes using some plugins, it's because of this. A bit more auto* stuff. Bugfixes ___ libvisual-plugins build will probably fail while building when libgoom2k4-devel-15 isn't present. Either download this or work around the error by hand. Please test and report back other problems! Cheers, Dennis |
10 messages has been excluded from this view by a project administrator.
