libvisual-devel

[Libvisual-devel] Ideas and plans for the upcoming weeks.

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

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

Re: [Libvisual-devel] Ideas and plans for the upcoming weeks.

[Vitaly V. B. <vi...@ma...>]

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

Re: [Libvisual-devel] Ideas and plans for the upcoming weeks.

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

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

Re: [Libvisual-devel] Ideas and plans for the upcoming weeks.

[Vitaly V. B. <vit...@uk...>]

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

Re: [Libvisual-devel] Ideas and plans for the upcoming weeks.

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

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