libvisual-devel — libvisual mailinglist for developers

Re: [Libvisual-devel] dangerous free()

[Dennis S. <sy...@yo...>]

Ai, please feel free to fix this by implementing a
flag.


On Thu, 2004-07-01 at 00:14 -0300, Duilio Javier Protti wrote:
> I have removed temporarily the free() call from
> visual_video_free_buffer(), because we don't
> known if this is memory malloc'ed from us (in XMMS
> plugin this point to the pixels field of the
> SDL_ScreenSurface created by SDL on another thread,
> which can be even a hardware surface).
> -- Thanks to valgrind --
> 
> We need some flags inside the VisVideo that
> tells if the screenbuffer was created by us or
> not.
> 
> 
> Bye,
> Duilio.

Re: [Libvisual-devel] dangerous free()

[Gustavo S. B. <gu...@gs...>]

Em Thursday 01 July 2004 00:14, Duilio Javier Protti escreveu:
> I have removed temporarily the free() call from
> visual_video_free_buffer(), because we don't
> known if this is memory malloc'ed from us (in XMMS
> plugin this point to the pixels field of the
> SDL_ScreenSurface created by SDL on another thread,
> which can be even a hardware surface).
> -- Thanks to valgrind --
>
> We need some flags inside the VisVideo that
> tells if the screenbuffer was created by us or
> not.

What about using a garbage collector? There is a good one for gcc (-lgd).
It  runs on any code... it replaces malloc() for a special one and make free() 
have no effect

-- 
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

[Libvisual-devel] xmms plugin icon

[Duilio J. P. <dp...@fc...>]

Now the plugin load the icon on startup, and
can load another one through config file.


Duilio.

[Libvisual-devel] dangerous free()

[Duilio J. P. <dp...@fc...>]

I have removed temporarily the free() call from
visual_video_free_buffer(), because we don't
known if this is memory malloc'ed from us (in XMMS
plugin this point to the pixels field of the
SDL_ScreenSurface created by SDL on another thread,
which can be even a hardware surface).
-- Thanks to valgrind --

We need some flags inside the VisVideo that
tells if the screenbuffer was created by us or
not.


Bye,
Duilio.

[Libvisual-devel] bug in xmms plugin, plugin name show.

[Dennis S. <sy...@yo...>]

Duilio,

When switching from let's say goom, and while switching to jess switch
to oinksie jess keeps set as plugin title.

Cheers,
Dennis

[Libvisual-devel] overlay, param, after 0.1.6

[Dennis S. <sy...@yo...>]

The new overlay function is almost finished, it will look for an alpha
channel when the source is a 32 bits surface and it's capable of
blitting to every depth. It also supports placement offsets. It's not
that special, but it's nice to know that when the webcam plugin lands
it'll enable us to walk in front of visuals. That with alpha chroma
keying enabled (blue screen stuff) rocks :).

I've did some quick thinking about the param stuff, and the UI it will
later include. I came to the following.

The VisParam stuff can be of a few types, ints, strings, 'color', 
filepath.. such things. Ranges can be defined etc.

When we start working on the UI support I think it's good to make
another system VisUIHints and VisUI. VisUIHints includes descriptions
about a user interface  to which params can be linked. VisUI is an
inbuffer UI creator for these hints. But let's start with VisUIHints
and a Gtk config created from this... Btw this is not yet close to
be done :), just ideas and planning...


After 0.1.6 I would like to do an 'extensive' robustness audit, API
audit... I'm starting about this right now so that when you spot
issues that need attention you can write them down and we can
create a list after 0.1.6 and fix them.

Cheers,
Dennis

Re: [Libvisual-devel] Re: libvisual 0.1.6 TODO list

[Dennis S. <sy...@yo...>]

> I suggest three weeks from now ahead.
I think that'll be a nice target date.


> About the xmms plugin TODO list, despite of the major
> bug we known, the features I like (very late, I known:-)):

Not at all, I simply add it to the list! :)

> - Show name of the current plugin on the window title (done).
> - Add plugin configure window, a general one for now, in 
> future we will get per-plugin options, when param interface 
> has be done.

The future per plugin config needs a lot of discussion. I'd like to
include 'ui hints' for options so automatic generated config
dialogs can use the ui hints to generate a nice ui. I also want
support for a inscreenbuffer configuration fallback at some point
that is kinda like that of syneathesia.

> - Show icon on the window title.

Yeah way cool, did you see the icon I've sended to the mailing list ?

> - Add internationalization support. I will make the spanish
> translation, Dennis, do you do the nl part?

Without doubt! :)

Cheers,
Dennis

Re: [Libvisual-devel] Re: libvisual 0.1.6 TODO list

[Gustavo S. B. <gu...@gs...>]

Em Wednesday 30 June 2004 13:42, Duilio Javier Protti escreveu:
> > What would be a nice target date for a 0.1.6 release ?
> - Add internationalization support. I will make the spanish
> translation, Dennis, do you do the nl part?

I do the pt_BR (Brazilian Portuguese).

-- 
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

Re: [Libvisual-devel] endianness

[Dennis S. <sy...@yo...>]

Rockon Duilio, Tho could you rename it to VISUAL_BIG_ENDIAN seen al
the macros start with VISUAL ?, or might it be nicer to have all the
macros start with LV_, I've had this doubt for quite a while.



On Wed, 2004-06-30 at 13:41 -0300, Duilio Javier Protti wrote:
> I have added endianness detection to the
> configure script. For make use of it within
> libvisual itself, just do:
> 
> #include <lvconfig.h>
> 
> void f ()
> {
> 	if (LV_BIG_ENDIAN) {
> 		...
> 	} else if (LV_LITTLE_ENDIAN) {
> 		...
> 	} else {
> 		/* weird machine */
> 		...
> 	}
> }
> 
> Outside libvisual can be used just including
> <libvisual/libvisual.h>.
> 
> I hope will be helpful.
> 
> 
> Duilio.

[Libvisual-devel] Re: libvisual 0.1.6 TODO list

[Duilio J. P. <dp...@fc...>]

> What would be a nice target date for a 0.1.6 release ?
> 
> Cheers,
> Dennis

I suggest three weeks from now ahead.

About the xmms plugin TODO list, despite of the major
bug we known, the features I like (very late, I known:-)):

- Show name of the current plugin on the window title (done).
- Add plugin configure window, a general one for now, in 
future we will get per-plugin options, when param interface 
has be done.
- Show icon on the window title.
- Add internationalization support. I will make the spanish
translation, Dennis, do you do the nl part?


Bye,
Duilio.

[Libvisual-devel] endianness

[Duilio J. P. <dp...@fc...>]

I have added endianness detection to the
configure script. For make use of it within
libvisual itself, just do:

#include <lvconfig.h>

void f ()
{
	if (LV_BIG_ENDIAN) {
		...
	} else if (LV_LITTLE_ENDIAN) {
		...
	} else {
		/* weird machine */
		...
	}
}

Outside libvisual can be used just including
<libvisual/libvisual.h>.

I hope will be helpful.


Duilio.

Re: [Libvisual-devel] xmms plugin app icon

[Dennis S. <sy...@yo...>]

Heya JC!

Duilio is rocking with the xmms plugin, it's rapidly stablizing and
getting more useful! :)

Thanks for your interests !

Cheers,
Dennis


On Wed, 2004-06-30 at 16:48 +0200, Jean-Christophe wrote:
> It is nice.
> 
> Then you ask if I have any idea of things to do for 0.1.6, I don't have any 
> good one for now that you didn't wrote on the TODO list.. I'm just looking 
> for lv_xmms to become stable enough to remove my xmms code from goom. Having 
> less things to maintain inside goom sounds good to me.
> 
> Regards,
> JC

Re: [Libvisual-devel] xmms plugin app icon

[Jean-Christophe <je...@io...>]

It is nice.

Then you ask if I have any idea of things to do for 0.1.6, I don't have any 
good one for now that you didn't wrote on the TODO list.. I'm just looking 
for lv_xmms to become stable enough to remove my xmms code from goom. Having 
less things to maintain inside goom sounds good to me.

Regards,
JC


On Wednesday 30 June 2004 16:26, Dennis Smit wrote:
> Heya
>
> I've attached an icon that might be nice to use as
> app icon within the xmms plugin.
>
> Tell me what you think.
>
> Cheers,
> Dennis

[Libvisual-devel] xmms plugin app icon

[Dennis S. <sy...@yo...>]

Heya

I've attached an icon that might be nice to use as
app icon within the xmms plugin.

Tell me what you think.

Cheers,
Dennis

[Libvisual-devel] visual_video_blit

[Dennis S. <sy...@yo...>]

What do you guys think about naming every semi blitter function
to visual_video_blit_...

Right now we've got a
visual_video_fit_in_video 

and I'm adding an overlay function.

The resulting function names could be:

visual_video_blit_fit
visual_video_blit_overlay

Cheers,
Dennis

[Libvisual-devel] libvisual 0.1.6 TODO list.

[Dennis S. <sy...@yo...>]

Alright I've put a list with TODO items online.

http://libvisual.sourceforge.net/LIBVISUAL_TODO



What would be a nice target date for a 0.1.6 release ?

Cheers,
Dennis

Re: [Libvisual-devel] XMMS plugin

[Dennis S. <sy...@yo...>]

On Tue, 2004-06-29 at 21:12 -0300, Duilio Javier Protti wrote:
> Now the window title is set to the
> name of the current plugin.
> 
> Also, I have added error checking to
> visual_bin_run() and others, and with
> these at least the plugin now doesn't
> hang my terminal on exit, but still
> crashing XMMS.

valgrind during exit:
==8421==
==8421== Thread 4:
==8421== Invalid read of size 1
==8421==    at 0x3C3BC754: strdup (in /lib/tls/libc-2.3.2.so)
==8421==  Address 0x0 is not stack'd, malloc'd or free'd

Segmentation fault

You've probably found a bug in XMMS, please visit
http://bugs.xmms.org and fill out a bug report.


But this one is more interesting:
valgrind during disable through the xmms plugin config window:
libvisual DEBUG: LibVisual XMMS Plugin: lv_xmms_cleanup [(lv_xmms.c,219)]: calling visual_quit()
==8429==
==8429== Invalid free() / delete / delete[]
==8429==    at 0x3C01F918: free (vg_replace_malloc.c:127)
==8429==    by 0x3CF1F402: visual_list_free (in /usr/lib/libvisual.so.0.0.0)
==8429==    by 0x3CF1C59C: visual_plugin_ref_list_destroy (in /usr/lib/libvisual.so.0.0.0)
==8429==    by 0x3CF20412: visual_quit (in /usr/lib/libvisual.so.0.0.0)
==8429==  Address 0x3C79D238 is 0 bytes inside a block of size 12 free'd
==8429==    at 0x3C01F918: free (vg_replace_malloc.c:127)
==8429==    by 0x3CF1F402: visual_list_free (in /usr/lib/libvisual.so.0.0.0)
==8429==    by 0x3CF1F4A7: visual_list_destroy (in /usr/lib/libvisual.so.0.0.0)
==8429==    by 0x3CF1C592: visual_plugin_ref_list_destroy (in /usr/lib/libvisual.so.0.0.0)
==8429==
==8429== Jump to the invalid address stated on the next line
==8429==    at 0x0: ???
==8429==    by 0x3CF20430: visual_quit (in /usr/lib/libvisual.so.0.0.0)
==8429==    by 0x3CF10A65: lv_xmms_cleanup (lv_xmms.c:220)
==8429==    by 0x806537A: enable_vis_plugin (in /usr/bin/xmms)
==8429==  Address 0x0 is not stack'd, malloc'd or free'd
--8429-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--8429-- si_code=1 Fault EIP: 0xB806F382; Faulting address: 0x1F

valgrind: the `impossible' happened:
   Killed by fatal signal
Basic block ctr is approximately 142100000
==8429==    at 0xB802FB60: vgPlain_core_panic (vg_mylibc.c:1230)
==8429==    by 0xB802FB5F: panic (vg_mylibc.c:1226)
==8429==    by 0xB802FB80: vgPlain_core_panic (vg_mylibc.c:1231)
==8429==    by 0xB803653A: vg_sync_signalhandler (vg_signals.c:1756)


Hope this helps!

Have you ever used valgrind ? It's an awesome tool, seriously!!!

Cheers,
Dennis

Re: [Libvisual-devel] plans for 0.1.6

[Dennis S. <sy...@yo...>]

On Tue, 2004-06-29 at 20:22 -0300, Gustavo Sverzut Barbieri wrote:
> Em Tuesday 29 June 2004 16:54, Dennis Smit escreveu:
> > On Tue, 2004-06-29 at 14:21 -0300, Duilio Javier Protti wrote:
> > > > * Fix alphabetic list for functions within doxygen generated docs.
> > > > * Param system, both local and global.
> > >
> > > Do you make this, Dennis, right?
> >
> > I will do the param system. I have looked at the doxygen stuff
> > and I don't understand why it's only alphabeticly listing
> > structures and not functions. Gustavo maybe you can have
> > a look at this ?
> 
> I never used alphabetic listing... I'll try it later (next week)

Rock on! 

> > Issues that I'm not able to solve with current codebase:
> > * When switching actors >REALLY< fast it'll crash because of corruption
> > in the video context pointer. I have no single idea what is causing
> > this.
> 
> Maybe you're using dirty memory (uninitialized)? Or lost pointers? Those are 
> the main point of failures I see.

It must be memory related, Duilio have you been using valgrind to check
it out ?

Cheers,
Dennis

[Libvisual-devel] XMMS plugin

[Duilio J. P. <dp...@fc...>]

Now the window title is set to the
name of the current plugin.

Also, I have added error checking to
visual_bin_run() and others, and with
these at least the plugin now doesn't
hang my terminal on exit, but still
crashing XMMS.


Bye,
Duilio.

Re: [Libvisual-devel] plans for 0.1.6

[Gustavo S. B. <gu...@gs...>]

Em Tuesday 29 June 2004 16:54, Dennis Smit escreveu:
> On Tue, 2004-06-29 at 14:21 -0300, Duilio Javier Protti wrote:
> > > * Fix alphabetic list for functions within doxygen generated docs.
> > > * Param system, both local and global.
> >
> > Do you make this, Dennis, right?
>
> I will do the param system. I have looked at the doxygen stuff
> and I don't understand why it's only alphabeticly listing
> structures and not functions. Gustavo maybe you can have
> a look at this ?

I never used alphabetic listing... I'll try it later (next week)


> > About the VisBin mess that you mention, Can you make a list
> > of all the troubles with the current implementation?
>
> The basic problems are that the code is being a mess, unmaintable and
> even not understandable. I've overseen some issues, and hacked them
> 'right'. The biggest issue is the managed bin. And we really want to
> have that working.
>
> Issues that I'm not able to solve with current codebase:
> * When switching actors >REALLY< fast it'll crash because of corruption
> in the video context pointer. I have no single idea what is causing
> this.

Maybe you're using dirty memory (uninitialized)? Or lost pointers? Those are 
the main point of failures I see.


> * When switching from a 8 bits plugin to a 32 bits plugin then while
> morphing back to the 8 bits plugin will keep the target display in 32
> bits mode.
>
>
> These are the most important user visible problems. But the real problem
> is the code itself and I've got to sit down, write down the requirements
> and design it on paper first. This will have to wait for a while but
> surely will get fixed.
>
> Gustavo, JC do you people have something to add to the list ?
>
> If not I will generate a final 0.1.6 roadmap and add who does
> what information.

I don't have anything special. I'll try to get mplayer plugin working and new 
ebuilds.

I'm entering on unviersity vacation this week (although my 30hs/week work goes 
on) so I will have more free time next.

-- 
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

Re: [Libvisual-devel] plans for 0.1.6

[Dennis S. <sy...@yo...>]

On Tue, 2004-06-29 at 14:21 -0300, Duilio Javier Protti wrote:
> > * Add copyright notice to all the files in every package.
> I will do that on XMMS plugin and all the actor plugins, 
> if you like.

We should make a script that does this for us in every
module. However before doing so. We first have to define
the exact copyright notice header. I also want to include
$id, some info about the authors etc in it.

> > * Use good libtool versioning.
> On these issue, I will do some experiments on my system
> and when all works well, I will submit details to the
> list and after that, if all agree, I will submit to the
> repository.

Very cool, this is really a job for you :) I suck with
build tools so it seems *hehe*.

> Dennis, we will use stable/devel branches, or just an
> unique main line?

For now we use one main line. When the library gets more mature
and requires stable ABI/API compatibility we will start stable
and devel branches.

> > * Fix alphabetic list for functions within doxygen generated docs.
> > * Param system, both local and global.
> Do you make this, Dennis, right?

I will do the param system. I have looked at the doxygen stuff
and I don't understand why it's only alphabeticly listing
structures and not functions. Gustavo maybe you can have
a look at this ?

> > * Timed morph.
> Good!!! Be careful about the system you use to timing, because
> LibVisual is a dynamic library, and the main application could
> be using timers also, and in general we can trash all the thing.
> 
> If we doesn't need high-precision timers, I suggest to make our
> own sleep, using select. I can do it if you want.

That would be good. It would be nice to have it clock screw proof.
Also what timed morphs do is calculating how much the percentage
of morph should be increased to be morphed on time. Doing this
every frame kinda like an FPS limiter but different :)

> > * Method to check if a certain morph requests VisAudio context.
> > * Fix coverart support.
> > * Byte swap helper functions to fix endianess issues (lv_bmp for 
> >   example).
> I can check for endianess on configure script, and then 
> set __LV_IS_LITTLE_ENDIAN and __LV_IS_BIG_ENDIAN macros
> on the lvconfig.h file.

Please do so! Then I will implement byte, word swap functions
like SDL does.

> > Libvisual-plugins:
> > * Include gustavo's mplayer input plugin.
> > * Fixes in some GL plugins that show odd behavior after another GL
> >   plugin has been running (better state setting).
> > * GdkPixbuf image loader (actor).
> > * Webcam plugin (actor).
> Good!!
> 
> > * Fix the 16, 24, 32 bits support for the flash morph.
> > * Infinity updates.
> Oh, work for me.

I meant updates you have been putting in the separated infinity
plugin for xmms.

> > * Loads of cleanups.
> > 
> > Libvisual-nebulus:
> > * Move the textures into a .bmp and use the libvisual bmp loader.
> > 
> > Libvisual-xmms:
> > Duilio you've been playing with the xmms plugin lately so I'm sure you
> > can add some items here :)
> 
> My only wish about XMMS plugin is that it doesn't crash :-)
> I will hunt the bug until catch it.

Very nice :) My personal interest is to (also) have a very good stand
alone version at some point so it is not xmms bound. So it's very cool
that you have more interests in the xmms plugin! :)

> About the VisBin mess that you mention, Can you make a list
> of all the troubles with the current implementation?

The basic problems are that the code is being a mess, unmaintable and
even not understandable. I've overseen some issues, and hacked them
'right'. The biggest issue is the managed bin. And we really want to
have that working.

Issues that I'm not able to solve with current codebase:
* When switching actors >REALLY< fast it'll crash because of corruption
in the video context pointer. I have no single idea what is causing
this.

* When switching from a 8 bits plugin to a 32 bits plugin then while
morphing back to the 8 bits plugin will keep the target display in 32
bits mode.


These are the most important user visible problems. But the real problem
is the code itself and I've got to sit down, write down the requirements
and design it on paper first. This will have to wait for a while but
surely will get fixed.

Gustavo, JC do you people have something to add to the list ?

If not I will generate a final 0.1.6 roadmap and add who does
what information.

Cheers and thanks,
Dennis

Re: [Libvisual-devel] plans for 0.1.6

[Duilio J. P. <dp...@fc...>]

> Aight, now we've released 0.1.5 it's time to make concrete plans for
> 0.1.6.
> 
> On the list are:
> Libvisual:
> * Use sys/types.h instead of stdint.h for portability reasons.
> * video: cleanup the fitter.
> * video: have an overlay function (to be used with webcam stuff).
>   for the overlay we need to use the alpha channel using 
>   VIDEO_DEPTH_32BITS. Tho it should be capable of blitting to
>   every depth. Have arguments to determine positioning, sizing and
>   a flag to disable alpha check.
I'm agree with all that.

> * Add copyright notice to all the files in every package.
I will do that on XMMS plugin and all the actor plugins, 
if you like.

> * Use good libtool versioning.
On these issue, I will do some experiments on my system
and when all works well, I will submit details to the
list and after that, if all agree, I will submit to the
repository.

Dennis, we will use stable/devel branches, or just an
unique main line?

> * Fix alphabetic list for functions within doxygen generated docs.
> * Param system, both local and global.
Do you make this, Dennis, right?

> * Timed morph.
Good!!! Be careful about the system you use to timing, because
LibVisual is a dynamic library, and the main application could
be using timers also, and in general we can trash all the thing.

If we doesn't need high-precision timers, I suggest to make our
own sleep, using select. I can do it if you want.

> * Method to check if a certain morph requests VisAudio context.
> * Fix coverart support.
> * Byte swap helper functions to fix endianess issues (lv_bmp for 
>   example).
I can check for endianess on configure script, and then 
set __LV_IS_LITTLE_ENDIAN and __LV_IS_BIG_ENDIAN macros
on the lvconfig.h file.

> Libvisual-plugins:
> * Include gustavo's mplayer input plugin.
> * Fixes in some GL plugins that show odd behavior after another GL
>   plugin has been running (better state setting).
> * GdkPixbuf image loader (actor).
> * Webcam plugin (actor).
Good!!

> * Fix the 16, 24, 32 bits support for the flash morph.
> * Infinity updates.
Oh, work for me.

> * Loads of cleanups.
> 
> Libvisual-nebulus:
> * Move the textures into a .bmp and use the libvisual bmp loader.
> 
> Libvisual-xmms:
> Duilio you've been playing with the xmms plugin lately so I'm sure you
> can add some items here :)

My only wish about XMMS plugin is that it doesn't crash :-)
I will hunt the bug until catch it.

About the VisBin mess that you mention, Can you make a list
of all the troubles with the current implementation?


Regards,
Duilio.

[Libvisual-devel] VisSongInfo within VisActorPlugin.

[Dennis S. <sy...@yo...>]

Currently there is a pointer to the songinformation in the
VisActorPlugin itself. This is set within VisActor by
doing: actplugin->songinfo = songinfo....

I don't think this is nice, not even when a method
function is used instead of the pointer assignment.

I would rather do plugin->render (plugin, video, audio, songinfo);

Ofcourse most use is encapsulated using the more abstract VisActor
interface but I think this would be a good change.

Do you people agree ?

[Libvisual-devel] plans for 0.1.6

[Dennis S. <sy...@yo...>]

Aight, now we've released 0.1.5 it's time to make concrete plans for
0.1.6.

On the list are:
Libvisual:
* Use sys/types.h instead of stdint.h for portability reasons.
* video: cleanup the fitter.
* video: have an overlay function (to be used with webcam stuff).
  for the overlay we need to use the alpha channel using 
  VIDEO_DEPTH_32BITS. Tho it should be capable of blitting to
  every depth. Have arguments to determine positioning, sizing and
  a flag to disable alpha check.
* Add copyright notice to all the files in every package.
* Use good libtool versioning.
* Fix alphabetic list for functions within doxygen generated docs.
* Param system, both local and global.
* Timed morph.
* Method to check if a certain morph requests VisAudio context.
* Fix coverart support.
* Byte swap helper functions to fix endianess issues (lv_bmp for 
  example).


Libvisual-plugins:
* Include gustavo's mplayer input plugin.
* Fixes in some GL plugins that show odd behavior after another GL
  plugin has been running (better state setting).
* GdkPixbuf image loader (actor).
* Webcam plugin (actor).
* Fix the 16, 24, 32 bits support for the flash morph.
* Infinity updates.
* Loads of cleanups.

Libvisual-nebulus:
* Move the textures into a .bmp and use the libvisual bmp loader.

Libvisual-xmms:
Duilio you've been playing with the xmms plugin lately so I'm sure you
can add some items here :)




People please feel free to add items so I can generate a final list and
put it online and we've got something to work towards.

Cheers,
Dennis

[Libvisual-devel] New libvisual release!!!

[Dennis S. <sy...@yo...>]

Heya everyone!

It's that time again. We've done a new libvisual release!

Thanks to Duilio all our packages are now automake-1.8 ready and
the buildtrees are majorly fixed!

libvisual-0.1.5:
* visual_log does now accept format strings and variable arguments.
* Major cleanups and build tree fixes.

libvisual-plugins-0.1.5:
* Removed the videotest plugin, it was used for early debugging.
* Esound dependency lowered from 0.2.29 to 0.2.28.
* Major cleanups and a new build tree.

libvisual-nebulus-0.1.2:
* Build tree fixes.

libvisual-xmms-0.1.5:
* Debug made optional
* Messages print through visual_log().
* Fullscreen support.
* Frame rate limited and configurable through config file.
* Color depth configurable through config file.

Availability:
http://sourceforge.net/project/showfiles.php?group_id=106542


Cheers,
Dennis