goom-devel Mailing List for goom
Brought to you by:
jchoelt
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
(6) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(17) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2003 |
Jan
(11) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
(16) |
Apr
(1) |
May
(2) |
Jun
(6) |
Jul
(6) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jeko <je...@io...> - 2005-01-10 12:57:02
|
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> > |
From: Jeko <je...@io...> - 2005-01-04 20:48:58
|
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 |
From: John L. <jo...@ni...> - 2004-12-10 04:58:08
|
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 |
From: Jeko <je...@io...> - 2004-12-09 23:45:00
|
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 > > |
From: Jean-Christophe <je...@fr...> - 2004-08-20 07:37:26
|
---------- 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 |
From: Jean-Christophe <je...@fr...> - 2004-08-19 13:27:02
|
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 > |
From: Michael R. <mr...@us...> - 2004-08-19 11:08:20
|
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 |
From: Michael R. <mr...@us...> - 2004-07-21 14:19:46
|
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 |
From: Jean-Christophe <je...@fr...> - 2004-07-20 23:29:27
|
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 > |
From: Michael R. <mr...@us...> - 2004-07-20 17:08:20
|
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 |
From: Jean-Christophe <je...@io...> - 2004-07-01 22:09:34
|
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? */ > > |
From: Guillaume B. <gb...@fr...> - 2004-07-01 20:40:11
|
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 |
From: Michael R. <mr...@us...> - 2004-07-01 19:58:41
|
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. |
From: Jean-Christophe <je...@io...> - 2004-06-29 09:23:00
|
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 > > |
From: Michael R. <mr...@us...> - 2004-06-27 12:22:46
|
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?" |
From: Carsten R. <cr...@da...> - 2004-06-16 18:05:13
|
Hi all, did you have a closer look to the patches now ? Did my last comments help you ? Regards, Carsten |
From: Jean-Christophe H. <je...@fr...> - 2004-06-03 17:16:42
|
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 >> > > |
From: Guillaume B. <gb...@fr...> - 2004-06-03 16:55:15
|
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 > |
From: Jean-Christophe H. <je...@fr...> - 2004-06-03 15:32:33
|
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 > > |
From: Dennis S. <sy...@yo...> - 2004-05-12 22:39:01
|
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 |
From: Benjamin O. <in...@pu...> - 2004-05-04 01:54:41
|
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 |
From: Jean-Christophe H. <je...@fr...> - 2004-04-15 19:26:21
|
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 |
From: Dennis S. <sy...@yo...> - 2004-03-31 19:09:25
|
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. |
From: Guillaume B. <gb...@fr...> - 2004-03-31 18:57:30
|
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 > |
From: Guillaume B. <gb...@fr...> - 2004-03-31 18:25:55
|
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 > |