goom-devel — All the things about goom...

[Goom] Re: goom2k4 - port gtk2 :)

[Jeko <je...@io...>]

To goom-devel list: sorry for this french only email...

Salut,
Je m'occupe d'essayer d'integrer tout ca dans la distribution officielle=20
: avec compilation conditionnelle du plugin bmp et de la version gtk2.
Je vais faire confiance a ton code du configure.in pour l'instant, on=20
verra si les gens s'en plaignent ;-)
Merci de ta contribution, si t'as d'autres bonnes idees comme ca,=20
n'hesite pas!
-- JC



iOS - Gyom wrote:

> Bonjour S=E9ven\ et merci beaucoup pour ta participation. Je transmet l=
e=20
> message =E0 Jeko qui s'occupe des choses relatives =E0 Linux.
>
> A bient=F4t,
>
> -Gyom
>
> Le 10 janv. 05, =E0 00:36, slm a =E9crit :
>
>> Bonjour,
>>
>> j'ai cod=E9 un petit port GTK2 de sdl-goom pour pouvoir l'utiliser
>> avec mon lecteur mp3 pr=E9f=E9rr=E9 (beep media player).
>>
>> Voici donc le r=E9sultat de mon d=E9veloppement du week-end :
>>
>> - goom2 en gtk2
>> - un plugin pour bmp
>> - un configure.in loin d'etre parfait :p
>>
>> En esp=E9rant, que vous tiendrez compte de ce mail, j'attends de vos=20
>> nouvelle
>> et je joins l'archive des sources.
>>
>>
>> S=E9ven Le Mesle <se...@fr...>
>> <goom2K4-gtk2.tar.bz2>
>

[Goom] Goom2k4-RC2

[Jeko <je...@io...>]

Hi there,

here comes a little mail to inform you that Release Candidate #2 of goom 
2k4 is available for download on goom's website 
(http://www.ios-software.com/)
You may also like to know that the CVS on sourceforge is back, check 
sourceforge's project page for details 
(http://sourceforge.net/projects/goom).

I hope I'll get some good feedback! But if something goes wrong let me 
know as well.

See ya,

Jean-Christophe "jeko" Hoelt

Re: [Goom] Re: GOOM segfault in zoom_filter_mmx.c

[John L. <jo...@ni...>]

On Fri, 2004-12-10 at 00:44 +0100, Jeko wrote:
> Hi John,
>=20
> Goom 1.99 is becoming quite old now, if I remember well the buffer=20
> allocation policy has been changed in goom 2k4 because it may have been=20
> a cause for this kind of segfault. So probably this is not the assembly=20
> code which is bad but something before.
>=20

I was thinking the assembly code error might be a dead end, particularly
since the problems crops up after resizing the window.

> Anyway, goom 2k4 fixes many known bugs of goom 1.99 and probably bring=20
> some new ones. I think it can be used for production, but not everything.
>=20
> If you followed the development, the package now contains 3 things:
>=20
> - libgoom: goom shared library which can be used to access the core=20
> functions of goom (libvisual uses it if available for instance)
> - sdl-goom: a standalone program using libgoom, display things with SDL,=20
> get sound datas from stdin.
> - xmms-goom: the xmms plugin.
>=20
> - libgoom can be used in production: maybe let me remove first some=20
> testing things from it which make it less nice that it should be.
> - xmms-goom is crap: it should not be used (personnally I use goom=20
> through libvisual now)

I understand if the direct XMMS plugin is being depreciated, but
switching over to libvisual in Debian would require quite a bit of work.

I'm maintaining the Goom, Jess and Infinity plugins already, and the
others supported by libvisual aren't in Debian yet, but to do the
transition properly I'd have to package up:

libvisual
libvisual-dev
xmms-libvisual (requires libvisual)
libvisual-goom (requires xmms-libvisual)
libvisual-jess
libvisual-infinity
libvisual-whatever
libvisual-plugins

An end user would just install xmms-libvisual and libvisual-plugins to
get everything they need.

xmms-infinity has a new active upstream author (he's on the libvisual
team)

http://infinity-plugin.sourceforge.net/

xmms-jess has a dead upstream.  No problem there.

http://arquier.free.fr/

The next release of Debian is supposedly right around the corner though,
and I'm not allowed to make uploads directly into Debian until after the
release takes place (I have to relay my uploads through another Debian
developer.)

I'd rather not switch anything over until Sarge releases.  At that point
it shouldn't be a problem if an upload breaks things that are currently
working.

If you don't think 2k4's XMMS plugin has been tested properly, it might
be better to stay with 1.99.4 for now and either track down the bug or
lock the window to the fixed sizes available through +/-

Actually, now that I'm thinking about it, that's probably the route I
should go.  I'll file a bug to let other Debian developers know that I'm
packaging up libvisual, get all the packages working over the next month
or two and put it into Debian once Sarge releases.

I might be able to port the other two xmms plugins I have, bumpscope and
synaesthesia, over to libvisual since the upstream for these doesn't
seem to be active any more.

> - sdl-goom: not very useful for mortals...
>=20
> Depending if you are in a hurry or not, we can try to quickly make a=20
> cleaner package with goom 2k4 (by hiding things that should not be seen=20
> by the user). You can also wait a few weeks : after monthes I started=20
> just 3 days ago to work again on goom, I'll prepare something for=20
> chrismas, before goom 2k4 have to be replaced by goom 2k5 ;-)
>=20

There's really no hurry.  I will not have much time to work on it until
the end of this month regardless.  If you think the XMMS plugin in 2k4
is ready by Christmas I'll switch over to it.  If not, I'll try to fix
or work around the bug in the current version.

> Let me know, best regards,
>=20
> -- Jean-Christophe

Thanks for the rapid feedback.  Sorry I haven't been more active with
Goom.  I should have packaged up 2k4 and libvisual months back.

John

[Goom] Re: GOOM segfault in zoom_filter_mmx.c

[Jeko <je...@io...>]

Hi John,

Goom 1.99 is becoming quite old now, if I remember well the buffer 
allocation policy has been changed in goom 2k4 because it may have been 
a cause for this kind of segfault. So probably this is not the assembly 
code which is bad but something before.

Anyway, goom 2k4 fixes many known bugs of goom 1.99 and probably bring 
some new ones. I think it can be used for production, but not everything.

If you followed the development, the package now contains 3 things:

- libgoom: goom shared library which can be used to access the core 
functions of goom (libvisual uses it if available for instance)
- sdl-goom: a standalone program using libgoom, display things with SDL, 
get sound datas from stdin.
- xmms-goom: the xmms plugin.

- libgoom can be used in production: maybe let me remove first some 
testing things from it which make it less nice that it should be.
- xmms-goom is crap: it should not be used (personnally I use goom 
through libvisual now)
- sdl-goom: not very useful for mortals...

Depending if you are in a hurry or not, we can try to quickly make a 
cleaner package with goom 2k4 (by hiding things that should not be seen 
by the user). You can also wait a few weeks : after monthes I started 
just 3 days ago to work again on goom, I'll prepare something for 
chrismas, before goom 2k4 have to be replaced by goom 2k5 ;-)

Let me know, best regards,

-- Jean-Christophe



John Lightsey wrote:

>Hi there,
>
>One of the Debian users of XMMS-Goom reported a segfault in the
>zoom_filter_mmx() assembly code.  The bug report indicates that the
>segfault occurs after manually resizing the visualization window.
>
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284341
>
>The version of this code in Goom2k4 looks like it has been substantially
>updated, so I'd rather not spend time trying to isolate and fix the
>problem if it has already been addressed.  What I'm really asking is if
>Goom2k4 is ready as a replacement for 1.99.4?
>
>If not, is there any chance you'll do a bugfix release of 1.99?  The
>patches I'm applying against 1.99.4 in Debian are already substantial.
>
>
>Thanks
>
>John
>  
>

[Goom] goom (fwd)

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

---------- Forwarded message ----------
Date: Thu, 19 Aug 2004 23:18:06 -0700
From: chris niewiarowski <pou...@ho...>
To: je...@io...
Subject: goom

just want to say you guys ar e doing a great! job on goom and i cant wait for a 
good stable version of goom2 keep up the great job relay this message to the 
rest of your team too. great job guys.
-chris

_________________________________________________________________
Get ready for school! Find articles, homework help and more in the Back to 
School Guide! http://special.msn.com/network/04backtoschool.armx

Re: [Goom] patch from goom integration into xine

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

Hi,
I applied the patch, it still work at home so it's good. You sent it just 
at the right time: i planned to release a development snapshot today. So I 
do it now. [...]
That's it!
http://www.ios-software.com/index.php3?page=projet&quoi=1&where=goom/devel/index.html
for more informations.
Thank you very much,
Best Regards,
JC

On Thu, 19 Aug 2004, Michael Roitzsch wrote:

> Hi,
>
>> I have to look into the inline assembler compilation problems anyway.
>
> Attached is a patch that hopefully fixes all remaining assembler problems.
> * The #ifdef HAVE_MMX I forgot fixes compilation on non-IA32 systems like PPC.
>  Sorry about that.
> * The assembler constraints for some MMX commands were wrong. "X" matches
>  anything, so when compiling with newer GCC versions for Pentium4, the
>  compiler tries to use SSE registers there, which fails at the assembler
>  stage.
>
> Michael
>
> -- 
> printk("CPU[%d]: Sending penguins to jail...",smp_processor_id());
> 	2.4.8 arch/sparc64/kernel/smp.c
>

Re: [Goom] patch from goom integration into xine

[Michael R. <mr...@us...>]

Hi,

> I have to look into the inline assembler compilation problems anyway.

Attached is a patch that hopefully fixes all remaining assembler problems.
* The #ifdef HAVE_MMX I forgot fixes compilation on non-IA32 systems like PPC.
  Sorry about that.
* The assembler constraints for some MMX commands were wrong. "X" matches
  anything, so when compiling with newer GCC versions for Pentium4, the
  compiler tries to use SSE registers there, which fails at the assembler
  stage.

Michael

-- 
printk("CPU[%d]: Sending penguins to jail...",smp_processor_id());
	2.4.8 arch/sparc64/kernel/smp.c

Re: [Goom] patch from goom integration into xine

[Michael R. <mr...@us...>]

Hi

> The patch was applied successfuly! (except for the lex/yacc files. Since
> I'm currently doing many changes in them on a "forked" tree, I think you
> can wait a bit before making patch for them).

Wow, that was fast! Of course I can wait with the rest of the patch. I have to 
look into the inline assembler compilation problems anyway.

> I applied by hand the 'anonymous union' patch anyway.

Thanks. :)
And thanks also for renaming the files from goom_script_scanner.tab.[ch] to 
goom_script_yacc.[ch], because automake will delete *.tab.c on distclean.

> Updated tarball (dev18) is now on sourceforge.

xine-lib CVS now includes dev18. Thanks.

Michael

-- 
"UNIX is an operating system, OS/2 is half an operating system, Windows
 is a shell, and DOS is a boot partition virus."
	-Peter H. Coffin

Re: [Goom] patch from goom integration into xine

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

Hi Michael,
The patch was applied successfuly! (except for the lex/yacc files. Since 
I'm currently doing many changes in them on a "forked" tree, I think you 
can wait a bit before making patch for them). I applied by hand the 
'anonymous union' patch anyway.
Updated tarball (dev18) is now on sourceforge.
Regards,
JC

On Tue, 20 Jul 2004, Michael Roitzsch wrote:

> Hi Jeko,
>
> Sorry for the delay, university kept my quite busy the last weeks...
>
> So here comes the next patch: This one fixes almost all compiler warnings when
> compiling goom with the xine-lib CFLAGS.
> * It adds a lot of "static", which should also help the compiler to optimize
>  more aggressively.
> * Some function prototypes are moved to different header files, so that the
>  same prototype is available when the function is defined or used. This
>  ensures that the compiler sees any inconsistencies. (It actually happened:
>  The zoom_filter_mmx() and zoom_filter_xmmx() functions were used with a
>  different signature than they were defined with.)
> * Some functions were declared as name(), but this should be name(void).
> * We also had to change the NodeType structure in goom_script_scanner.h.
>  Older compilers do not support anonymous unions. This also means changing
>  all the places were this union is used.
>
> Ok, enough nitpicking for today. ;)
>
> I hope you can use some of this. I tried not to modify any flex/bison
> generated files, but modified the originating files instead.
>
> After fixing all the warnings (just some left which are introduced by
> flex/bison and are not our problem to fix), there is one last issue:
> gcc 3.4 does not like some of the inline assembler when compiling with
> -march=pentium4 -msse2. I will look into this.
>
> Michael
>
> --
> Linux is much like an Indian tent:
> no Gates, no Windows and Apache inside
>

Re: [Goom] patch from goom integration into xine

[Michael R. <mr...@us...>]

Hi Jeko,

> I applied this patch as well, and uploaded an updated tarball on the
> website
> http://www.ios-software.com/index.php3?page=projet&quoi=1&where=goom/devel/
>index.html in this version you can also see an early-stage function support
> into the goom scripting language (see the goom control center -> brigh
> flash). Any other patch are welcome.

Sorry for the delay, university kept my quite busy the last weeks...

So here comes the next patch: This one fixes almost all compiler warnings when 
compiling goom with the xine-lib CFLAGS.
* It adds a lot of "static", which should also help the compiler to optimize
  more aggressively.
* Some function prototypes are moved to different header files, so that the
  same prototype is available when the function is defined or used. This
  ensures that the compiler sees any inconsistencies. (It actually happened:
  The zoom_filter_mmx() and zoom_filter_xmmx() functions were used with a
  different signature than they were defined with.)
* Some functions were declared as name(), but this should be name(void).
* We also had to change the NodeType structure in goom_script_scanner.h.
  Older compilers do not support anonymous unions. This also means changing
  all the places were this union is used.

Ok, enough nitpicking for today. ;)

I hope you can use some of this. I tried not to modify any flex/bison 
generated files, but modified the originating files instead.

After fixing all the warnings (just some left which are introduced by 
flex/bison and are not our problem to fix), there is one last issue:
gcc 3.4 does not like some of the inline assembler when compiling with
-march=pentium4 -msse2. I will look into this.

Michael

-- 
Linux is much like an Indian tent:
no Gates, no Windows and Apache inside

Re: [Goom] patch from goom integration into xine

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

Hi Michael,
I applied this patch as well, and uploaded an updated tarball on the website
http://www.ios-software.com/index.php3?page=projet&quoi=1&where=goom/devel/index.html
in this version you can also see an early-stage function support into 
the goom scripting language (see the goom control center -> brigh flash).
Any other patch are welcome.
See ya,
Jeko

Michael Roitzsch wrote:

>Hi Jeko,
>
>  
>
>>I applied your patch which worked.
>>    
>>
>
>Thanks a lot. :)
>
>  
>
>>The flex/bison changes will not be kept anyway: files to edit are 
>>goom_script_scanner.lex / .yacc If you open them, you will see that it's 
>>mainly C code.  
>>    
>>
>
>I see. The attached patch should port my changes to these files. Is that ok?
>
>I am afraid this won't be the last patch. New changes will arrive here 
>shortly.
>
>There is one other thing a couple of xine developers noticed: goom2k4 always 
>starts with the same effect, no matter what file xine plays. It is a circular 
>wave visualization that washes out to all white, stays almost totally white 
>for a while, which looks a bit strange, before moving on to the next effect. 
>Could there be some problem with random initialization?
>
>  
>
>>I'll put a new tarball with your changes online soon, I added support
>>for sub-functions in the embedded scripting language of goom: so I've
>>just a few things to finish there before.
>>    
>>
>
>Btw, is there a public CVS of goom somewhere?
>
>Michael
>
>  
>
>------------------------------------------------------------------------
>
>--- goom2k4-dev15/src/goom_script_scanner.lex	Sa Mär 27 18:15:05 2004
>+++ goom2k4-dev15/src/goom_script_scanner.lex	Do Jul  1 13:55:18 2004
>@@ -695,7 +695,9 @@
> 
> void goom_script_scanner_compile(GoomScriptScanner *_currentScanner, PluginInfo *pluginInfo, const char *script) {
> 
>+#ifdef VERBOSE
>     printf("\n=== Starting Compilation ===\n");
>+#endif
>     currentScanner = _currentScanner;
>     reset_scanner(currentScanner);
>     currentScanner->pluginInfo = pluginInfo;
>@@ -706,7 +708,9 @@
> 
>     calculate_labels(currentScanner->iflow);
>     
>+#ifdef VERBOSE
>     printf("=== Compilation done. # of lines: %d. # of instr: %d ===\n", currentScanner->num_lines, currentScanner->iflow->number);
>+#endif
> }
> 
> void goom_script_scanner_execute(GoomScriptScanner *scanner) {
>--- goom2k4-dev15/src/goom_script_scanner.y	Sa Mär 27 18:15:05 2004
>+++ goom2k4-dev15/src/goom_script_scanner.y	Do Jul  1 13:53:22 2004
>@@ -38,7 +38,9 @@
>     }
>     static void commit_set(NodeType *set) {
>         precommit_node(set->opr.op[1]);
>+#ifdef VERBOSE
>         printf("set.f %s %s\n", set->opr.op[0]->str, set->opr.op[1]->str);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "set.f", INSTR_SETF, 2);
>         commit_node(set->opr.op[0]);
>         commit_node(set->opr.op[1]);
>@@ -51,7 +53,9 @@
>         return fld;
>     }
>     static void commit_float(NodeType *var) {
>+#ifdef VERBOSE
>         printf("float %s\n", var->opr.op[0]->str);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "float", INSTR_INT, 1);
>         commit_node(var->opr.op[0]);
>     }
>@@ -63,7 +67,9 @@
>         return intd;
>     }
>     static void commit_int(NodeType *var) {
>+#ifdef VERBOSE
>         printf("int %s\n", var->opr.op[0]->str);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "int", INSTR_INT, 1);
>         commit_node(var->opr.op[0]);
>     }
>@@ -102,7 +108,9 @@
>         }
> 
>         /* add op2 to tmp */
>+#ifdef VERBOSE
>         printf("%s %s %s\n", type, stmp, expr->opr.op[toAdd]->str);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, type, instr_id, 2);
>         commit_node(new_var(stmp));
>         commit_node(expr->opr.op[toAdd]);
>@@ -167,7 +175,9 @@
> 
>         /* jzero.i <expression> <endif> */
>         sprintf(slab, "|eif%d|", allocateLabel());
>+#ifdef VERBOSE
>         printf("jzero.i %s %s\n", node->opr.op[0]->str, slab);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "jzero.i", INSTR_JZERO, 2);
>         commit_node(node->opr.op[0]);
>         instr_add_param(currentScanner->instr, slab, TYPE_LABEL);
>@@ -175,7 +185,9 @@
>         /* [... instrs of the if ...] */
>         commit_node(node->opr.op[1]);
>         /* label <endif> */
>+#ifdef VERBOSE
>         printf("label %s\n", slab);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "label", INSTR_LABEL, 1); 
>         instr_add_param(currentScanner->instr, slab, TYPE_LABEL);
>     }
>@@ -245,7 +257,9 @@
>                     case OPR_SET:           commit_set(node); break;
>                     case OPR_IF:            commit_if(node); break;
>                     case OPR_BLOCK:         commit_block(node); break;
>+#ifdef VERBOSE
>                     case EMPTY_NODE:        printf("NOP\n"); break;
>+#endif
>                 }
> 
>                 commit_node(node->opr.next); /* recursive for the moment, maybe better to do something iterative? */
>  
>

Re: [Goom] patch from goom integration into xine

[Guillaume B. <gb...@fr...>]

On Jul 1, 2004, at 12:58 PM, Michael Roitzsch wrote:

> Btw, is there a public CVS of goom somewhere?

There will be one soon on SourceForge.

-Gyom

Re: [Goom] patch from goom integration into xine

[Michael R. <mr...@us...>]

Hi Jeko,

> I applied your patch which worked.

Thanks a lot. :)

> The flex/bison changes will not be kept anyway: files to edit are 
> goom_script_scanner.lex / .yacc If you open them, you will see that it's 
> mainly C code.  

I see. The attached patch should port my changes to these files. Is that ok?

I am afraid this won't be the last patch. New changes will arrive here 
shortly.

There is one other thing a couple of xine developers noticed: goom2k4 always 
starts with the same effect, no matter what file xine plays. It is a circular 
wave visualization that washes out to all white, stays almost totally white 
for a while, which looks a bit strange, before moving on to the next effect. 
Could there be some problem with random initialization?

> I'll put a new tarball with your changes online soon, I added support
> for sub-functions in the embedded scripting language of goom: so I've
> just a few things to finish there before.

Btw, is there a public CVS of goom somewhere?

Michael

-- 
I am Bill of Borg. Resistance izkx GPF 0x5654 8820 Application
RESIST.EXE has performed an illegal operation and will be shut down.

Re: [Goom] patch from goom integration into xine

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

I applied your patch which worked. The flex/bison changes will not be 
kept anyway: files to edit are goom_script_scanner.lex / .yacc If you 
open them, you will see that it's mainly C code.
If some small things need to be made inside
#ifdef XINE
#endif
Dont hesitate to submit a patch for that as well, so that your job will 
be easier.

I'll put a new tarball with your changes online soon, I added support 
for sub-functions in the embedded scripting language of goom: so I've 
just a few things to finish there before.
 
Regards,
Jeko

Michael Roitzsch wrote:

>Hi goom team,
>
>I hope this is the right list for my mail. If not, please tell me, where to 
>turn to.
>
>This is Michael Roitzsch from the xine team. As you might know, xine is using 
>goom to present those nifty effects of yours for audio-only files. Since it 
>is our policy to make installation easy for the user, we included a copy of 
>the goom code into xine-lib. Unfortunately, this copy received some patches 
>and fixes and was starting to drift from the original version, making future 
>merges of new goom releases more difficult. To resolve this, I decided to 
>include the current goom2k4-dev15 into xine-lib and ported all the patches to 
>this new version.
>
>Now I would like to ask, if some, maybe even all of these changes could be 
>applied to your official goom tree. I attached a patch containing all our 
>changes to far. It fixes three things:
>* make goom silent
>  This is the biggest and probably most unimportant part of the patch. It
>  wraps those printfs I saw when running goom in xine, because xine-lib should
>  be silent on the console.
>  This part of the patch might be a problem, because some of the files I
>  modified appear to be the output of flex/bison, so one actually has to patch
>  the input files to these tools. But since I know next to nothing about
>  flex/bison (I know just enough to avoid it... ;) ), I did not try that.
>* fix goom on AMD64
>  On several occasions, goom casts pointers to int. This is bad, because it
>  breaks AMD64 and other 64 bit platforms. We fixed these by using a C99
>  inttype.
>* fix a memleak
>  The free_ifs() added in ifs.c fixes a memory leak.
>
>If there is a chance that this patch could find its way into the official 
>tree, I would like to start work on yet another patch: Goom compilation 
>inside xine-lib emits quite a lot of compiler warnings which I would like to 
>fix.
>
>Michael
>
>  
>
>------------------------------------------------------------------------
>
>--- config_param.c	2004-06-20 15:07:37.000000000 +0200
>+++ config_param.c	2004-06-20 14:42:31.000000000 +0200
>@@ -96,7 +96,9 @@
> 
> void set_list_param_value(PluginParam *p, const char *str) {
>     int len = strlen(str);
>+#ifdef VERBOSE
>     printf("%s: %d\n", str, len);
>+#endif
>     if (LVAL(*p))
>         LVAL(*p) = (char*)realloc(LVAL(*p), len+1);
>     else
>--- convolve_fx.c	2004-06-20 15:07:37.000000000 +0200
>+++ convolve_fx.c	2004-06-20 14:42:54.000000000 +0200
>@@ -104,7 +104,9 @@
> 	iff = (unsigned int)(ff * 256);
> 
>     if (!goom_script_scanner_is_compiled(data->script)) {
>+#ifdef VERBOSE
>         printf("setting default script for dynamic brightness\n");
>+#endif
>         goom_script_scanner_compile(data->script, info, DEF_SCRIPT);
>     }
>     
>--- filters.c	2004-03-27 18:15:05.000000000 +0100
>+++ filters.c	2004-06-20 15:16:20.000000000 +0200
>@@ -18,6 +18,7 @@
> #include <stdlib.h>
> #include <math.h>
> #include <stdio.h>
>+#include <inttypes.h>
> 
> #include "goom_filters.h"
> #include "goom_graphic.h"
>@@ -571,13 +572,13 @@
>         
>         data->mustInitBuffers = 0;
>         data->freebrutS = (signed int *) calloc (resx * resy * 2 + 128, sizeof(unsigned int));
>-        data->brutS = (gint32 *) ((1 + ((unsigned int) (data->freebrutS)) / 128) * 128);
>+        data->brutS = (gint32 *) ((1 + ((uintptr_t) (data->freebrutS)) / 128) * 128);
>         
>         data->freebrutD = (signed int *) calloc (resx * resy * 2 + 128, sizeof(unsigned int));
>-        data->brutD = (gint32 *) ((1 + ((unsigned int) (data->freebrutD)) / 128) * 128);
>+        data->brutD = (gint32 *) ((1 + ((uintptr_t) (data->freebrutD)) / 128) * 128);
>         
>         data->freebrutT = (signed int *) calloc (resx * resy * 2 + 128, sizeof(unsigned int));
>-        data->brutT = (gint32 *) ((1 + ((unsigned int) (data->freebrutT)) / 128) * 128);
>+        data->brutT = (gint32 *) ((1 + ((uintptr_t) (data->freebrutT)) / 128) * 128);
>         
>         data->buffratio = 0;
>         
>--- goom_core.c	2004-03-27 18:15:05.000000000 +0100
>+++ goom_core.c	2004-06-20 15:16:41.000000000 +0200
>@@ -11,6 +11,7 @@
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>+#include <inttypes.h>
> 
> #include "goom.h"
> #include "goom_tools.h"
>@@ -45,8 +46,8 @@
>     goomInfo->conv = (Pixel *) malloc (buffsize * sizeof (guint32) + 128);
>     bzero (goomInfo->conv, buffsize * sizeof (guint32) + 128);
>     
>-    goomInfo->p1 = (Pixel *) ((1 + ((unsigned int) (goomInfo->pixel)) / 128) * 128);
>-    goomInfo->p2 = (Pixel *) ((1 + ((unsigned int) (goomInfo->back)) / 128) * 128);
>+    goomInfo->p1 = (Pixel *) ((1 + ((uintptr_t) (goomInfo->pixel)) / 128) * 128);
>+    goomInfo->p2 = (Pixel *) ((1 + ((uintptr_t) (goomInfo->back)) / 128) * 128);
> }
> 
> /**************************
>@@ -84,7 +85,7 @@
>     goomInfo->screen.size = resx * resy;
>     
>     init_buffers(goomInfo, goomInfo->screen.size);
>-    goomInfo->gRandom = goom_random_init((guint32)goomInfo->pixel);
>+    goomInfo->gRandom = goom_random_init((uintptr_t)goomInfo->pixel);
>     
>     goomInfo->cycle = 0;
>     
>--- goom_script_scanner.c	2004-06-20 15:07:37.000000000 +0200
>+++ goom_script_scanner.c	2004-06-20 14:45:07.000000000 +0200
>@@ -2412,7 +2412,9 @@
> 
> void goom_script_scanner_compile(GoomScriptScanner *_currentScanner, PluginInfo *pluginInfo, const char *script) {
> 
>+#ifdef VERBOSE
>     printf("\n=== Starting Compilation ===\n");
>+#endif
>     currentScanner = _currentScanner;
>     reset_scanner(currentScanner);
>     currentScanner->pluginInfo = pluginInfo;
>@@ -2423,7 +2425,9 @@
> 
>     calculate_labels(currentScanner->iflow);
>     
>+#ifdef VERBOSE
>     printf("=== Compilation done. # of lines: %d. # of instr: %d ===\n", currentScanner->num_lines, currentScanner->iflow->number);
>+#endif
> }
> 
> void goom_script_scanner_execute(GoomScriptScanner *scanner) {
>--- goom_script_scanner.tab.c	2004-06-20 15:07:37.000000000 +0200
>+++ goom_script_scanner.tab.c	2004-06-20 14:50:07.000000000 +0200
>@@ -108,7 +108,9 @@
>     }
>     static void commit_set(NodeType *set) {
>         precommit_node(set->opr.op[1]);
>+#ifdef VERBOSE
>         printf("set.f %s %s\n", set->opr.op[0]->str, set->opr.op[1]->str);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "set.f", INSTR_SETF, 2);
>         commit_node(set->opr.op[0]);
>         commit_node(set->opr.op[1]);
>@@ -121,7 +123,9 @@
>         return fld;
>     }
>     static void commit_float(NodeType *var) {
>+#ifdef VERBOSE
>         printf("float %s\n", var->opr.op[0]->str);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "float", INSTR_INT, 1);
>         commit_node(var->opr.op[0]);
>     }
>@@ -133,7 +137,9 @@
>         return intd;
>     }
>     static void commit_int(NodeType *var) {
>+#ifdef VERBOSE
>         printf("int %s\n", var->opr.op[0]->str);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "int", INSTR_INT, 1);
>         commit_node(var->opr.op[0]);
>     }
>@@ -172,7 +178,9 @@
>         }
> 
>         /* add op2 to tmp */
>+#ifdef VERBOSE
>         printf("%s %s %s\n", type, stmp, expr->opr.op[toAdd]->str);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, type, instr_id, 2);
>         commit_node(new_var(stmp));
>         commit_node(expr->opr.op[toAdd]);
>@@ -237,7 +245,9 @@
> 
>         /* jzero.i <expression> <endif> */
>         sprintf(slab, "|eif%d|", allocateLabel());
>+#ifdef VERBOSE
>         printf("jzero.i %s %s\n", node->opr.op[0]->str, slab);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "jzero.i", INSTR_JZERO, 2);
>         commit_node(node->opr.op[0]);
>         instr_add_param(currentScanner->instr, slab, TYPE_LABEL);
>@@ -245,7 +255,9 @@
>         /* [... instrs of the if ...] */
>         commit_node(node->opr.op[1]);
>         /* label <endif> */
>+#ifdef VERBOSE
>         printf("label %s\n", slab);
>+#endif
>         currentScanner->instr = instr_init(currentScanner, "label", INSTR_LABEL, 1); 
>         instr_add_param(currentScanner->instr, slab, TYPE_LABEL);
>     }
>@@ -315,7 +327,9 @@
>                     case OPR_SET:           commit_set(node); break;
>                     case OPR_IF:            commit_if(node); break;
>                     case OPR_BLOCK:         commit_block(node); break;
>+#ifdef VERBOSE
>                     case EMPTY_NODE:        printf("NOP\n"); break;
>+#endif
>                 }
> 
>                 commit_node(node->opr.next); /* recursive for the moment, maybe better to do something iterative? */
>--- ifs.c	2004-03-27 18:15:05.000000000 +0100
>+++ ifs.c	2004-06-20 15:19:09.000000000 +0200
>@@ -454,6 +454,7 @@
> static void release_ifs (IfsData *data)
> {
> 	if (data->Root != NULL) {
>+		free_ifs (data->Root);
> 		(void) free ((void *) data->Root);
> 		data->Root = (FRACTAL *) NULL;
> 	}
>--- plugin_info.c	2004-06-20 15:07:37.000000000 +0200
>+++ plugin_info.c	2004-06-20 14:51:22.000000000 +0200
>@@ -44,17 +44,23 @@
> 
> #ifdef CPU_X86
> 	if (cpuFlavour & CPU_OPTION_XMMX) {
>+#ifdef VERBOSE
> 		printf ("Extented MMX detected. Using the fastest methods !\n");
>+#endif
> 		p->methods.draw_line = draw_line_mmx;
> 		p->methods.zoom_filter = zoom_filter_xmmx;
> 	}
> 	else if (cpuFlavour & CPU_OPTION_MMX) {
>+#ifdef VERBOSE
> 		printf ("MMX detected. Using fast methods !\n");
>+#endif
> 		p->methods.draw_line = draw_line_mmx;
> 		p->methods.zoom_filter = zoom_filter_mmx;
> 	}
>+#ifdef VERBOSE
>         else
>             printf ("Too bad ! No SIMD optimization available for your CPU.\n");
>+#endif
> #endif /* CPU_X86 */
> 	
> #ifdef CPU_POWERPC
>  
>

[Goom] patch from goom integration into xine

[Michael R. <mr...@us...>]

Hi goom team,

I hope this is the right list for my mail. If not, please tell me, where to 
turn to.

This is Michael Roitzsch from the xine team. As you might know, xine is using 
goom to present those nifty effects of yours for audio-only files. Since it 
is our policy to make installation easy for the user, we included a copy of 
the goom code into xine-lib. Unfortunately, this copy received some patches 
and fixes and was starting to drift from the original version, making future 
merges of new goom releases more difficult. To resolve this, I decided to 
include the current goom2k4-dev15 into xine-lib and ported all the patches to 
this new version.

Now I would like to ask, if some, maybe even all of these changes could be 
applied to your official goom tree. I attached a patch containing all our 
changes to far. It fixes three things:
* make goom silent
  This is the biggest and probably most unimportant part of the patch. It
  wraps those printfs I saw when running goom in xine, because xine-lib should
  be silent on the console.
  This part of the patch might be a problem, because some of the files I
  modified appear to be the output of flex/bison, so one actually has to patch
  the input files to these tools. But since I know next to nothing about
  flex/bison (I know just enough to avoid it... ;) ), I did not try that.
* fix goom on AMD64
  On several occasions, goom casts pointers to int. This is bad, because it
  breaks AMD64 and other 64 bit platforms. We fixed these by using a C99
  inttype.
* fix a memleak
  The free_ifs() added in ifs.c fixes a memory leak.

If there is a chance that this patch could find its way into the official 
tree, I would like to start work on yet another patch: Goom compilation 
inside xine-lib emits quite a lot of compiler warnings which I would like to 
fix.

Michael

-- 
"Unix? What's that? Is that like Linux?" 

Re: [Goom] Re: [Patch] Goom 1.99.4 memleaks, gcc 3.x, warnings

[Carsten R. <cr...@da...>]

Hi all,

did you have a closer look to the patches now ?
Did my last comments help you ?

Regards,
Carsten

Re: [Goom] Re: [Patch] Goom 1.99.4 memleaks, gcc 3.x, warnings

[Jean-Christophe H. <je...@fr...>]

Some memory leak fixes are ok. I saw the grid3d one which we should=20
apply to 2k4.
Anyway, the patch is still full of just "indentation changes" lines...=20
so do not be abused by them!

Carsten, maybe you can point us to the main changes you made ?

JC


Guillaume Borios wrote:

> I already have had a *very quick* look at it. Some things are OK,=20
> while others are not (e.g.: new globals variables added, since we try=20
> to get rid of them...). Maybe we can apply it to the 1.99.x branch "as=20
> is", but we'll have to take a deeper analysis to merge this in the 2k4=20
> branch. Jeko?
>
> -Gyom
>
> Le 3 juin 04, =E0 17:30, Jean-Christophe HOELT a =E9crit :
>
>> Hello,
>>
>> Someone (probably me) will take a look at your patch to include the=20
>> changes you made in the development version.
>> Thanks,
>>
>> Jeko
>>
>>
>> Carsten Rietzschel wrote:
>>
>>> Hello Jeko / IOS Team,
>>>
>>> while playing around with your great goom plugin I found some=20
>>> failures & fixed them (afaik).
>>> Mainly is solves:
>>> - gcc 3.x compilation
>>> - some (big) mem leaks
>>> - fixed some compiler warning (prototypes etc.)
>>>
>>> I attached two patches:
>>> 1) cr7-real-changes:
>>> There you can see the changes I made to the source to fix the=20
>>> mentioned fixes.
>>> The bad is - it doesn't apply to your "official" release as it as,=20
>>> because I indented my files (via indent -bli 0). So patch failes :/
>>>
>>> 2) full-patch:
>>> There for  I added a patch, which aplies to your release as is, but=20
>>> indents your code an is bigger.
>>>
>>> Feel free to use this patches :)
>>> Regards,
>>> Carsten
>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the new InstallShield X.
>> From Windows to Linux, servers to mobile, InstallShield X is the one
>> installation-authoring solution that does it all. Learn more and
>> evaluate today! http://www.installshield.com/Dev2Dev/0504
>> _______________________________________________
>> Goom-devel mailing list
>> Goo...@li...
>> https://lists.sourceforge.net/lists/listinfo/goom-devel
>>
>
>

Re: [Goom] Re: [Patch] Goom 1.99.4 memleaks, gcc 3.x, warnings

[Guillaume B. <gb...@fr...>]

I already have had a *very quick* look at it. Some things are OK, while=20=

others are not (e.g.: new globals variables added, since we try to get=20=

rid of them...). Maybe we can apply it to the 1.99.x branch "as is",=20
but we'll have to take a deeper analysis to merge this in the 2k4=20
branch. Jeko?

-Gyom

Le 3 juin 04, =E0 17:30, Jean-Christophe HOELT a =E9crit :

> Hello,
>
> Someone (probably me) will take a look at your patch to include the=20
> changes you made in the development version.
> Thanks,
>
> Jeko
>
>
> Carsten Rietzschel wrote:
>
>> Hello Jeko / IOS Team,
>>
>> while playing around with your great goom plugin I found some=20
>> failures & fixed them (afaik).
>> Mainly is solves:
>> - gcc 3.x compilation
>> - some (big) mem leaks
>> - fixed some compiler warning (prototypes etc.)
>>
>> I attached two patches:
>> 1) cr7-real-changes:
>> There you can see the changes I made to the source to fix the=20
>> mentioned fixes.
>> The bad is - it doesn't apply to your "official" release as it as,=20
>> because I indented my files (via indent -bli 0). So patch failes :/
>>
>> 2) full-patch:
>> There for  I added a patch, which aplies to your release as is, but=20=

>> indents your code an is bigger.
>>
>> Feel free to use this patches :)
>> Regards,
>> Carsten
>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> =46rom Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Goom-devel mailing list
> Goo...@li...
> https://lists.sourceforge.net/lists/listinfo/goom-devel
>

[Goom] Re: [Patch] Goom 1.99.4 memleaks, gcc 3.x, warnings

[Jean-Christophe H. <je...@fr...>]

Hello,

Someone (probably me) will take a look at your patch to include the 
changes you made in the development version.
Thanks,

Jeko


Carsten Rietzschel wrote:

>Hello Jeko / IOS Team,
>
>while playing around with your great goom plugin I found some failures & fixed 
>them (afaik).
>Mainly is solves:
>- gcc 3.x compilation
>- some (big) mem leaks
>- fixed some compiler warning (prototypes etc.)
>
>I attached two patches:
>1) cr7-real-changes:
>There you can see the changes I made to the source to fix the mentioned fixes.
>The bad is - it doesn't apply to your "official" release as it as, because I 
>indented my files (via indent -bli 0). So patch failes :/
>
>2) full-patch:
>There for  I added a patch, which aplies to your release as is, but indents 
>your code an is bigger.
>
>Feel free to use this patches :)
>Regards,
>Carsten
>  
>

Re: [Goom] autotools patch

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

Heya Benjamin!

The patch looks good, i had done a patch that included pkgconfig support
but it hadn't yet been put online.

JC, this is the patch to apply, he solves way more issues than my patch
does.

Great work Benjamin! :)

On Tue, 2004-05-04 at 03:54 +0200, Benjamin Otte wrote:
> Hi guys,
> 
> I've cleaned up autotoolization, so it works on my two boxes (one a PPC without
> MMX (d'oh) and the other without libgtk1 or xmms) and I can hack on a GStreamer
> plugin for it/libvisual.
> 
> The patch is against pre15. It also adds pkgconfig support.
> 
> Benjamin

[Goom] autotools patch

[Benjamin O. <in...@pu...>]

Hi guys,

I've cleaned up autotoolization, so it works on my two boxes (one a PPC without
MMX (d'oh) and the other without libgtk1 or xmms) and I can hack on a GStreamer
plugin for it/libvisual.

The patch is against pre15. It also adds pkgconfig support.

Benjamin

[Goom] Re: Updated Win32 patch for Goom2k4 dev15

[Jean-Christophe H. <je...@fr...>]

Fred Howell wrote:

>This patch is smaller, it and doesn't require renamed files in goom
>source folder.  IFS was not working in the last patch I sent.  It works
>now.
>
>Fred
>

Great, thanks,
I'll put it online in a few days. Personnally I'm still quite busy, so 
the goom scripting language is going on very slowly.
Anyway, let's hope we will release a stable version before summer.
About this, I think this should be useful to have some kind of installer 
for the windows counterpart of goom (coz' windows users like that!).
Do you know how to do that ? A simple .batch or something should work I 
guess (but it's a long time since I didn't get to those MS things, maybe 
there are more nice way to do...). Let me know if you've got some time 
(or "ambition") to look into this.

see you,
    JC

Re: [Goom] dev15

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

Oops, i screwed up here, my excuse :), How can we make sure the newly
generated config.h is named goom_config.h and installed in %prefix/
include/goom ?

Cheers,
Dennis

On Wed, 2004-03-31 at 20:57 +0200, Guillaume Borios wrote:
> Allright, got it fixed. The config.h has also been renamed ;) Next time 
> we should remove goom_config.h from the source tree to force it to be 
> generated from scratch. We also should provide a goom_config.h.template 
> for those who don't use the makefile, so that they can manually make
> their own from this template.

Re: [Goom] dev15

[Guillaume B. <gb...@fr...>]

Allright, got it fixed. The config.h has also been renamed ;) Next time=20=

we should remove goom_config.h from the source tree to force it to be=20
generated from scratch. We also should provide a goom_config.h.template=20=

for those who don't use the makefile, so that they can manually make=20
their own from this template.

Le 31 mars 04, =E0 20:25, Guillaume Borios a =E9crit :

> Argh, what did you do with the code??? Even if it still compiles well,=20=

> it now runs sooooooo slowlyyyyy and with a big mess in the RGBA/ARGB=20=

> defines, it seems...
>
> I'll try to fix it.
>
> Le 31 mars 04, =E0 19:55, Jean-Christophe Hoelt a =E9crit :
>
>> Hello,
>>
>> goom2k4-dev15 is online. I think the win32 and mac project will not=20=

>> work anymore with the changes made so I let the previous sources=20
>> online as well.
>> I hope I'll have up-to-date version soon! :-)
>>
>> Enjoy,
>>    JC
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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=3D1470&alloc_id=3D3638&op=3Dc=
lick
>> _______________________________________________
>> Goom-devel mailing list
>> Goo...@li...
>> https://lists.sourceforge.net/lists/listinfo/goom-devel
>>
>
>
>
> -------------------------------------------------------
> 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_id638&op=3Dclick
> _______________________________________________
> Goom-devel mailing list
> Goo...@li...
> https://lists.sourceforge.net/lists/listinfo/goom-devel
>

Re: [Goom] dev15

[Guillaume B. <gb...@fr...>]

Argh, what did you do with the code??? Even if it still compiles well,=20=

it now runs sooooooo slowlyyyyy and with a big mess in the RGBA/ARGB=20
defines, it seems...

I'll try to fix it.

Le 31 mars 04, =E0 19:55, Jean-Christophe Hoelt a =E9crit :

> Hello,
>
> goom2k4-dev15 is online. I think the win32 and mac project will not=20
> work anymore with the changes made so I let the previous sources=20
> online as well.
> I hope I'll have up-to-date version soon! :-)
>
> Enjoy,
>    JC
>
>
>
>
> -------------------------------------------------------
> 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=3D1470&alloc_id=3D3638&op=3Dcl=
ick
> _______________________________________________
> Goom-devel mailing list
> Goo...@li...
> https://lists.sourceforge.net/lists/listinfo/goom-devel
>