hey there,
I'm trying to get gem text to work under linux (as I had before w/ older CVS version) and can't get gem to work with gltt.
I'm doing ./configure --without-ftgl --with-gltt
which does return:
checking for open in -lgltt... yes checking for TT_FreeType_Version in -lttf... yes
And while compiling:
c++ -c -g -g -O2 -D__NEW__ -fPIC -mmmx -I../ -I/usr/include/avifile-0.7 -I/usr/include/libmpeg3/ -I/usr/include/gltt/ -I/usr/local/include/ -fno-builtin -O3 -funroll-loops -ffast-math text3d.cpp -o text3d.o
But when I try and use text3d I get:
Gem has been compiled without FONT-support !
Same thing happens with ftgl and without gltt...
I know it was working before, anyone having issues with text3d under linux?
Thanks Ben
Zitiere "B. Bogart" ben@ekran.org:
hey there, I'm doing ./configure --without-ftgl --with-gltt And while compiling:
c++ -c -g -g -O2 -D__NEW__ -fPIC -mmmx -I../ -I/usr/include/avifile-0.7
-I/usr/include/libmpeg3/ -I/usr/include/gltt/ -I/usr/local/include/ -fno-builtin -O3 -funroll-loops -ffast-math text3d.cpp -o text3d.o
Gem has been compiled without FONT-support !
Same thing happens with ftgl and without gltt...
you also have to re-compile the TextBase in Gem/src/Base which is the parent class for all the text-objects and which spits out the warning you get.
mfg.a.sdr IOhannes
I'm doing a make clean each time I compile (make clean && ./configure --with-gltt --without-ftgl && make from src/Gnu), I don't see how TextBase could not be compiling...
I see a TextBase.o in src/Base...
Anything else I can try?
B.
zmoelnig@iem.at wrote:
Zitiere "B. Bogart" ben@ekran.org:
hey there, I'm doing ./configure --without-ftgl --with-gltt And while compiling:
c++ -c -g -g -O2 -D__NEW__ -fPIC -mmmx -I../ -I/usr/include/avifile-0.7
-I/usr/include/libmpeg3/ -I/usr/include/gltt/ -I/usr/local/include/ -fno-builtin -O3 -funroll-loops -ffast-math text3d.cpp -o text3d.o
Gem has been compiled without FONT-support !
Same thing happens with ftgl and without gltt...
you also have to re-compile the TextBase in Gem/src/Base which is the parent class for all the text-objects and which spits out the warning you get.
mfg.a.sdr IOhannes
Zitiere "B. Bogart" ben@ekran.org:
I'm doing a make clean each time I compile (make clean && ./configure --with-gltt --without-ftgl && make from src/Gnu), I don't see how TextBase could not be compiling...
I see a TextBase.o in src/Base...
ok i rather thought that you were just doing a re-configure and afterwards just tried to re-compile the text*-objects. it should run the way you do it.
how do Base/configLinux.h and Base/config.h look like ?
as for versions: gltt: 2.5-5 (debian)
drivers: i am using geforceFX and geforce3 cards with 1.0.5336-drivers and a radeonM6 with the normal X/mesa-drivers.
unfortunately your problem with video-textures reminds me of ales's problem who couldn't texture his quicktime-webcam with Gem installed on a gentoo system. when he finally installed debian on the very same laptop, it just worked.
Thanks for the responce Johannes,
/* ../Base/configLinux.h. Generated automatically by configure. */ /* #undef HAVE_LIBFTGL */ #define HAVE_LIBGLTT 1
/* #undef HAVE_LIBMPEG */ #define HAVE_LIBMPEG3 1 #define HAVE_LIBQUICKTIME 1 #define HAVE_LIBAVIPLAY 1 /* #undef HAVE_LIBAVFORMAT */ /* #undef HAVE_LIBAVCODEC */
#define HAVE_LIBDV 1
#define HAVE_MMX 1
/* ../Base/config.h. Generated automatically by configure. */ #define HAVE_LIBGLUT 1 /* #undef HAVE_LIBFTGL */ #define HAVE_LIBGLTT 1
/* #undef HAVE_LIBMPEG */ #define HAVE_LIBMPEG3 1 #define HAVE_LIBQUICKTIME 1 /* #undef HAVE_LIBAVIPLAY */ /* #undef HAVE_LIBAVFORMAT */ /* #undef HAVE_LIBAVCODEC */
/* #undef HAVE_LIBDV */
/* #undef HAVE_MMX */
I have been having occational GLcore crashes with the nvidia drivers, I should try a newer one soon. I've been doing all my gem stuff in OSX lately, but I really hope I can get gem working on linux when I no longer have mac access...
Thanks for your help.
Ben
zmoelnig@iem.at wrote:
Zitiere "B. Bogart" ben@ekran.org:
I'm doing a make clean each time I compile (make clean && ./configure --with-gltt --without-ftgl && make from src/Gnu), I don't see how TextBase could not be compiling...
I see a TextBase.o in src/Base...
ok i rather thought that you were just doing a re-configure and afterwards just tried to re-compile the text*-objects. it should run the way you do it.
how do Base/configLinux.h and Base/config.h look like ?
as for versions: gltt: 2.5-5 (debian)
drivers: i am using geforceFX and geforce3 cards with 1.0.5336-drivers and a radeonM6 with the normal X/mesa-drivers.
unfortunately your problem with video-textures reminds me of ales's problem who couldn't texture his quicktime-webcam with Gem installed on a gentoo system. when he finally installed debian on the very same laptop, it just worked.
Hey Johannes,
Been busy with other things for some time.
I did have textures working from the CVS in an older version (perhaps only 2 months old) on the same OS with the same libs. This just suddenly stopped working one day when I did a cvs update. I don't think it would be a non-debian specific problem... unless there is something new in the pix_code that the suse gem dependancies don't lile.. but I don't get any errors or warnings, just a complete lack of success! (loading video files of any kind I have around)
I tried recompiling from the lastest CVS todat and still no luck.
As for the font support did my config files help at all?
B.
zmoelnig@iem.at wrote:
unfortunately your problem with video-textures reminds me of ales's problem who couldn't texture his quicktime-webcam with Gem installed on a gentoo system. when he finally installed debian on the very same laptop, it just worked.
hi again
Zitiere "B. Bogart" ben@ekran.org:
Hey Johannes,
Been busy with other things for some time.
well, i have spent one delightful week of holidays too and just returned to work today....
I did have textures working from the CVS in an older version (perhaps only 2 months old) on the same OS with the same libs. This just suddenly
stopped working one day when I did a cvs update. I don't think it would
be a non-debian specific problem... unless there is something new in the
pix_code that the suse gem dependancies don't lile.. but I don't get any
errors or warnings, just a complete lack of success! (loading video files of any kind I have around)
I tried recompiling from the lastest CVS todat and still no luck.
As for the font support did my config files help at all?
i knew i forgot something: the Base/config.h shouldn't be autoconfigured at all. this has changed a while ago and now config.h is the same for all platforms and and includes the apropriate os-specific file.
just a very wild guess: remove Base/config.h check it out again and recompile.
mfg.as.dr IOhannes
Looks like we have all been busy working or vacationing the past week or so, and I think it's time to firm up a release date for GEM. I don't think there are too many issues left to cover - I know some of the Pete's pix_ objects need some work on YUV processing. Anything else to do? Is it possible to get something out next week?
cgc
chris clepper wrote:
Looks like we have all been busy working or vacationing the past week or
ok, sorry; i have been busy up till know.. anyhow, since i have noticed that both you and jamie have fixed some YUV-processing in the last few days, it was probably a good idea to wait that long.
are there any other unresolved issues ?
i guess most problems are really fixed (except for the quickcam4linux), or at least, won't be in this release.
i'd suggest 05th of may.
mfg.a.sdr IOhannes
On May 3, 2004, at 4:49 AM, IOhannes m zmoelnig wrote:
chris clepper wrote:
Looks like we have all been busy working or vacationing the past week or
ok, sorry; i have been busy up till know.. anyhow, since i have noticed that both you and jamie have fixed some YUV-processing in the last few days, it was probably a good idea to wait that long.
are there any other unresolved issues ?
i guess most problems are really fixed (except for the quickcam4linux), or at least, won't be in this release.
...still have a few yuv-processing things to fix: halftone, kaleidoscope, colourreduce, levels, refraction, and backlight...levels and colourreduce don't do anything right (except not crash), but the others may work in a pinch...however, we're focusing on them heavily: but they are sooo confusing!
i'd suggest 05th of may.
...that may be pushing it ;-)
l8r, jamie
Seeing that it's already Cinco de Mayo here I don't see it also being GEM release day as well. One good thing about the title of this mail is that it always points towards a future date. ;)
I had underestimated the amount of time and effort to get Pete's Plugins into working order for YUV, and it looks like there is still a bit to do. Also, I have tentatively scheduled a testing session on a friend's dual G5 for this weekend, which should allow for ironing out any potential problems on that version of GEM.
So 'next week' is really looking like next week.
cgc
On May 3, 2004, at 9:09 AM, James Tittle II wrote:
On May 3, 2004, at 4:49 AM, IOhannes m zmoelnig wrote:
chris clepper wrote:
Looks like we have all been busy working or vacationing the past week or
ok, sorry; i have been busy up till know.. anyhow, since i have noticed that both you and jamie have fixed some YUV-processing in the last few days, it was probably a good idea to wait that long.
are there any other unresolved issues ?
i guess most problems are really fixed (except for the quickcam4linux), or at least, won't be in this release.
...still have a few yuv-processing things to fix: halftone, kaleidoscope, colourreduce, levels, refraction, and backlight...levels and colourreduce don't do anything right (except not crash), but the others may work in a pinch...however, we're focusing on them heavily: but they are sooo confusing!
i'd suggest 05th of may.
...that may be pushing it ;-)
l8r, jamie
chris clepper wrote:
Seeing that it's already Cinco de Mayo here I don't see it also being GEM release day as well. One good thing about the title of this mail is that it always points towards a future date. ;)
I had underestimated the amount of time and effort to get Pete's Plugins into working order for YUV, and it looks like there is still a bit to
ok. i have done a bit of work too, and now the status for these objects is:
[pix_halftone] : works (although it is a bit brighter than rgba/grey due to the usage of "real" luminance) [pix_levels] : seem to work [pix_colorreduce] : works (ok, my hack to make it work is really quick and dirty; it is awfully slow; but as jamie mentioned, it is soooo complicated; if someone finds the time *later* it could be done in a proper way) [pix_refraction] and [pix_backlight] seem to work, although the output is not exactly the same as it would be in rgba
[pix_kaleidoscope]: the only problem remaining (although working halfway, or rather doublewide)
additionally there appeared an issue with the YUV-texturing under linux (just for your information): Mesa seems to have incorporated the GL_APPLE_ycbyr_422 into the newer releases (i haven't yet been able to really test it, but at least the defines are there in the gl.h); unfortunately nvidia's driver do not yet support this. so i have made a runtime check for GL_APPLE_ycbyr_422 to enable/disable YUV2RGBA-conversion.
do. Also, I have tentatively scheduled a testing session on a friend's dual G5 for this weekend, which should allow for ironing out any potential problems on that version of GEM.
fine
mfg.asd.r IOhannes
hey gang,
On May 5, 2004, at 11:22 AM, IOhannes m zmoelnig wrote:
chris clepper wrote:
Seeing that it's already Cinco de Mayo here I don't see it also being GEM release day as well. One good thing about the title of this mail is that it always points towards a future date. ;) I had underestimated the amount of time and effort to get Pete's Plugins into working order for YUV, and it looks like there is still a bit to
..aye eye an "i" or two...
ok. i have done a bit of work too, and now the status for these objects is:
[pix_halftone] : works (although it is a bit brighter than rgba/grey due to the usage of "real" luminance)
...heheh, I almost fainted! I've been working feverishly on this for the last week or so, and finally got a hold on it last night; so my stomach dropped when ya said you got it too work: coulda been doing something else all that time...luckily, after looking at yr solution I realized the only change was the SHIFT_U & SHIFT_V stuff: guess we should've expected endianess like in rgba/argb...
...anyway, I've got it working almost totally correctly (at least we aren't doing the pixel doubling), but there's one sticking point, and it's due to the calculation of the pGreyScaleTable[]...in essence, it creates a 512 place table with 0's from 0-256 and 255's from 383-511...in between, we have 1,3,5,7...up to 255...so I did a little experiment and found the following:
# of pixels nDiff>383 nDiff<257 natural yuv 1369 48703 transformed yuv 1369 48703 transformed RGBA 16 63662
...this tells us two things: 1. "natural" yuv gives us the same values as transformed, so we can remove the transform 2. we get a lot higher bias using yuv luma than a calculated rgb luma
...so, on the one hand we can try to find a "magic number" to subtract from yuv luma to try to get a similar distribution (which I'm fiddling with), or we can recalculate the greyScaleTable (or DotFuncResult) so that it better fits the yuv luma spread...
...any suggestions?
[pix_levels] : seem to work [pix_colorreduce] : works (ok, my hack to make it work is really quick and dirty; it is awfully slow; but as jamie mentioned, it is soooo complicated; if someone finds the time *later* it could be done in a proper way)
...tried this, but it crashed immediately...will look at later...
[pix_refraction] and [pix_backlight] seem to work, although the output is not exactly the same as it would be in rgba
...pix_refraction works fine, haven't tried chris' changes yet...
[pix_kaleidoscope]: the only problem remaining (although working halfway, or rather doublewide)
...this is next on my list...
additionally there appeared an issue with the YUV-texturing under linux (just for your information): Mesa seems to have incorporated the GL_APPLE_ycbyr_422 into the newer releases (i haven't yet been able to really test it, but at least the defines are there in the gl.h); unfortunately nvidia's driver do not yet support this. so i have made a runtime check for GL_APPLE_ycbyr_422 to enable/disable YUV2RGBA-conversion.
do. Also, I have tentatively scheduled a testing session on a friend's dual G5 for this weekend, which should allow for ironing out any potential problems on that version of GEM.
fine
...let's hope we can get it done by then!
l8r, jamie
Zitiere James Tittle II tigital@mac.com:
hey gang,
[pix_halftone] : works (although it is a bit brighter than rgba/grey
due to the usage of "real" luminance)
...heheh, I almost fainted!
oh sorry.
realized the only change was the SHIFT_U & SHIFT_V stuff: guess we should've expected endianess like in rgba/argb...
basically i did expect it (because suddenly something turned green after i cvs upgraded where the log says "at least it isn't green any more;-)"), but i haven't had any possibility to test it. so i just left it there and shifted the problem into the GemPixPete-defines. btw: i do think we should use SHIFT_Y0/Y1 instead of Y1/Y2 (but i committed to soon...)
...anyway, I've got it working almost totally correctly (at least we aren't doing the pixel doubling), but there's one sticking point, and it's due to the calculation of the pGreyScaleTable[]...in essence, it creates a 512 place table with 0's from 0-256 and 255's from 383-511...in between, we have 1,3,5,7...up to 255...so I did a little experiment and found the following:
# of pixels
nDiff>383 nDiff<257natural yuv 1369 48703 transformed yuv 1369 48703 transformed RGBA 16 63662
...any suggestions?
i have had a look at the colour2grey-conversion and there were 2 problems: a) RGBA: Grey=77*Red+50*Green+29*Blue is wrong; it should read: ...150*Green... this boosts the RGBA-luminance significantly b) Greyscale: averaging was done in 4byte-blocks, but only the first 3 values were taken into account (like ignoring the alpha-value of an rgba-tuple)
having fixed this, the halftone-images almost(!) are the same for all color-spaces.
but unfortunately i have found more problems with YUV-endianess in some objects (e.g. [pix_metaimage] swaps chroma and luma on my system) i'll investigate
mfg.as.dr IOhannes
On May 6, 2004, at 7:18 AM, zmoelnig@iem.at wrote:
realized the only change was the SHIFT_U & SHIFT_V stuff: guess we should've expected endianess like in rgba/argb...
basically i did expect it (because suddenly something turned green after i cvs upgraded where the log says "at least it isn't green any more;-)"), but i haven't had any possibility to test it. so i just left it there and shifted the problem into the GemPixPete-defines. btw: i do think we should use SHIFT_Y0/Y1 instead of Y1/Y2 (but i committed to soon...)
...anyway, I've got it working almost totally correctly (at least we aren't doing the pixel doubling), but there's one sticking point, and it's due to the calculation of the pGreyScaleTable[]...in essence, it creates a 512 place table with 0's from 0-256 and 255's from 383-511...in between, we have 1,3,5,7...up to 255...so I did a little experiment and found the following:
# of pixels
nDiff>383 nDiff<257natural yuv 1369 48703 transformed yuv 1369 48703 transformed RGBA 16 63662
...any suggestions?
i have had a look at the colour2grey-conversion and there were 2 problems: a) RGBA: Grey=77*Red+50*Green+29*Blue is wrong; it should read: ...150*Green... this boosts the RGBA-luminance significantly b) Greyscale: averaging was done in 4byte-blocks, but only the first 3 values were taken into account (like ignoring the alpha-value of an rgba-tuple)
having fixed this, the halftone-images almost(!) are the same for all color-spaces.
...just checked out yr new version: very interesting! Of course, it just produced a green image at first, but that's just because you used the SHIFT macros, an on ppc they were shifting to 24 and 16 in a short! I'm still working on U32 pointers with two pixels, and get a fairly different output from you: hard to say who's closer...mine seems to be biased to the high end (fr'instance, the reflection on the pot at the left is very visible), whereas your version is more smoothed out...I'm trying to figure out why we get such different results...
but unfortunately i have found more problems with YUV-endianess in some objects (e.g. [pix_metaimage] swaps chroma and luma on my system) i'll investigate
...yeh, we definitely will need to go back and roll those macros in...
we'll get it eventually!
jamie
James Tittle II wrote:
i have done even more work and got most of pete's plugins working on the pc. however, compiling Gem on mac was a bit disappointing: some things are crashing, but the worst problem is the colour-stoff.
...yeh, we definitely will need to go back and roll those macros in...
i really tried to and somehow i was lost completely somehow.
just for clarification: the rgb-like colourspace (RGBA on other systems) is GL_BGRA even though it is actually ARGB ? is this true ??
how the R/G/B-shifts from GemPixPete can work on PCs i don't know (but they do better than on mac)
mfg.s.dr IOhannes
On May 7, 2004, at 12:50 PM, IOhannes m zmoelnig wrote:
just for clarification: the rgb-like colourspace (RGBA on other systems) is GL_BGRA even though it is actually ARGB ? is this true ??
It's ARGB but submitted as BGRA only reversed using the _REV_ GL flags. Confusing, but I guess concessions to the PC world were needed.
Here's the current state of Pete's plugs for me:
pix_backlight - the output is different between the colorspaces as previously noted.
pix_colorreduce - just crashes on any YUV data I try. It's not a very good solution to do the conversions just to get it to work. Even if it did work, I would vote to just not have it process YUV since it would be so slow.
pix_halftone - doesn't really produce very meaningful output in YUV. It makes the dot patterns but it's not nearly as legible as the RGB. I fixed the shifts for OSX so now it's not just green, but maybe that screws up the x86 code so I put a little ifdef around it.
pix_kaleidoscope - output is different, but hey it's about 3x faster in YUV. Will anyone complain?
pix_levels - doesn't seem to do any sane YUV processing at all. The code obviously just applies RGB transforms without regard to the chroma offset. This needs a rewrite for YUV (it might work for gray as well).
pix_lumaoffset - now crashes religiously when using smooth and YUV (the version I committed did not), and the RGB code crashes no matter what when the offset and gap get too high. Some sort of bounds checking is either not in place or failing.
pix_metaimage - sometimes using YUV and not 'cheap' there is a green edge to the boxes. this is probably an off by one where there is not a proper pixel pair. I don't know where to fix this. Also, when size = 0 CPU load skyrockets and things start to turn into a slideshow. Should that value be trapped and just bypass the effect altogether?
pix_refraction - this seems to work pretty well for both RGB and YUV, but the output is different. Does that matter?
To sum up, the following seem fine:
backlight, kaleidoscope, refraction, and possibly metaimage
The rest need work:
colorreduce - this needs a full reworking in YUV, and I have a hard time understanding how the hell the histogram is made. I would think you need it to hold either 256 slots per channel or one for every possible pixel sampled because they might all be unique. This code seems to do neither? It does sample every 4 pixels which would reduce the array needed for the second method. The sort might be hellish on a 720x480 though.
halftone - I don't know where this one is going wrong.
levels - this one seems easiest to write for YUV. Heck, just a quick multiply for each component would do and skip the rest of it.
lumaoffset - I could have sworn there was some sort of sanity check for pixel coordinates, but now I just don't know. The crash is always at the smoothing conditional and one of the attendant pointer operations. I checked out the version I committed a few days ago and now it crashes and it did not before (or else I wouldn't have committed it).
The real question to me is how much effort do these really warrant? Sure some of them look quite nice, but none of the objects are particularly essential, and the original Pete code performs terribly. Also, I can't recall anyone ever posting about these objects apart from the Linux compile problems caused by kaleidoscope. It's starting to irritate that these are holding up the show.
cgc
chris clepper wrote:
On May 7, 2004, at 12:50 PM, IOhannes m zmoelnig wrote:
It's ARGB but submitted as BGRA only reversed using the _REV_ GL flags. Confusing, but I guess concessions to the PC world were needed.
ah alright. i think i was a bit tired and it had puzzled me (among other things) for hours.
Here's the current state of Pete's plugs for me:
pix_colorreduce - just crashes on any YUV data I try. It's not a very good solution to do the conversions just to get it to work. Even if it did work, I would vote to just not have it process YUV since it would be so slow.
i agree that it is not a good solution. anyhow, it was simple to do, it worked on my PC and (i think) a lot of video-programs use this trick to use effects for images in the "wrong" colourspace (which doesn't make it *any* faster) i have noticed myself that it is so crashy on macs; so i would agree to get it out again. as for slowness: it is slow on both RGBA and YUV-images.
pix_halftone - doesn't really produce very meaningful output in YUV. It makes the dot patterns but it's not nearly as legible as the RGB. I fixed the shifts for OSX so now it's not just green, but maybe that screws up the x86 code so I put a little ifdef around it.
and it still works on x86 ;-)
pix_kaleidoscope - output is different, but hey it's about 3x faster in YUV. Will anyone complain?
fine
pix_levels - doesn't seem to do any sane YUV processing at all. The code obviously just applies RGB transforms without regard to the chroma offset. This needs a rewrite for YUV (it might work for gray as well).
at least the luminance-channel is processed correctly ;-) grayscale works too
pix_lumaoffset - now crashes religiously when using smooth and YUV (the version I committed did not), and the RGB code crashes no matter what when the offset and gap get too high. Some sort of bounds checking is either not in place or failing.
pix_metaimage - sometimes using YUV and not 'cheap' there is a green Also, when size = 0 CPU load skyrockets and things start to turn into a slideshow. Should that value be trapped and just bypass the effect altogether?
yes, i think so.
pix_refraction - this seems to work pretty well for both RGB and YUV, but the output is different. Does that matter?
not for me
halftone - I don't know where this one is going wrong.
hmm, it works on x86. and jamie has been working on this too almost getting it to work on mac (i think).
lumaoffset - I could have sworn there was some sort of sanity check for pixel coordinates, but now I just don't know. The crash is always at the smoothing conditional and one of the attendant pointer operations. I checked out the version I committed a few days ago and now it crashes and it did not before (or else I wouldn't have committed it).
i am not that sure about it (the crashes are there, alright; but why). i have numerous crashes when trying to re-create pete's objects which i cannot track down (debugging is not helpful as crashes appear rather randomly) probably there is a stupid bug like the un-initialized GemState hidden elsewere.
The real question to me is how much effort do these really warrant? Sure some of them look quite nice, but none of the objects are particularly essential, and the original Pete code performs terribly. Also, I can't recall anyone ever posting about these objects apart from the Linux compile problems caused by kaleidoscope. It's starting to irritate that these are holding up the show.
i agree.
mfg.a.dr IOhannes
On May 9, 2004, at 3:10 PM, IOhannes m zmoelnig wrote:
i agree that it is not a good solution. anyhow, it was simple to do, it worked on my PC and (i think) a lot of video-programs use this trick to use effects for images in the "wrong" colourspace (which doesn't make it *any* faster) i have noticed myself that it is so crashy on macs; so i would agree to get it out again. as for slowness: it is slow on both RGBA and YUV-images.
I have placed an #ifdef around the YUV to remove it from the OSX version until a better solution is found.
pix_levels - doesn't seem to do any sane YUV processing at all. The code obviously just applies RGB transforms without regard to the chroma offset. This needs a rewrite for YUV (it might work for gray as well).
at least the luminance-channel is processed correctly ;-) grayscale works too
I see what you tried to do, but I have started to separate the processing into the usual processYUVImage, RGBA etc. I think that is the only way to get it to work decently on all platforms with each colorspace. The 'uniform' adjustment seems to give sensible output for YUV now, but non-uniform still does crazy things though. I've committed what I have so far...
lumaoffset -
i am not that sure about it (the crashes are there, alright; but why). i have numerous crashes when trying to re-create pete's objects which i cannot track down (debugging is not helpful as crashes appear rather randomly) probably there is a stupid bug like the un-initialized GemState hidden elsewere.
To me it looks like a bounds checking is failing and a pointer is shooting off into space. The instant I turn on 'smooth' for YUV or RGBA it crashes (line 559 and 154 which are the same). I guess we could just remove that feature? ;)
FIxing the lumaoffset crash is getting close to complete as far as I'm concerned.
cgc
hi.
chris clepper wrote:
On May 9, 2004, at 3:10 PM, IOhannes m zmoelnig wrote: FIxing the lumaoffset crash is getting close to complete as far as I'm concerned.
ok. so i have finally found a bug that kept most pix-objects crashing on deletion and fixed it. apart from this i noticed the lumaoffset crash once in a while (but i wouldn't say that it appears "religiously when turning smooth on") i haven't tried to fix it, as you seem to have almost done it already.
how are the G5-tests ?
mfg.a.er IOhannes
On May 13, 2004, at 1:51 PM, IOhannes m zmoelnig wrote:
ok. so i have finally found a bug that kept most pix-objects crashing on deletion and fixed it. apart from this i noticed the lumaoffset crash once in a while (but i wouldn't say that it appears "religiously when turning smooth on") i haven't tried to fix it, as you seem to have almost done it already.
I'll check and see how that change works out. I haven't had too many crashes from that code however.
I've limited the valid range for 'offset' in lumaoffset to image.ysize/2 and that seems to have cured the crashes with YUV. RGB still segfaults at a line of pointer chasing around line 240. I'm a bit stumped as I've set up even more bounds checking and moved global variables to local and so on, but I can still crash it 100% of the time. I'm getting tired of trying to figure out what the hell this code does by following a ton of very similarly named pointers around. I might go line by line and comment the thing...
I have one question about imageStruct::reallocate() though. Should the comparison be size != datasize instead of size < datasize? I would expect the buffer to resize whenever there was a need to change it.
how are the G5-tests ?
I'm hoping they will happen this weekend. I'm pretty sure that GEM will run fine on one, but it would be nice to have a metric for performance, and find any glaring bugs as well.
cgc
mfg.a.er IOhannes
chris clepper wrote:
On May 13, 2004, at 1:51 PM, IOhannes m zmoelnig wrote:
I have one question about imageStruct::reallocate() though. Should the comparison be size != datasize instead of size < datasize? I would expect the buffer to resize whenever there was a need to change it.
well, i consider that there is "no need" to change it, if we already have enough memory allocated. i haven't yet run out of memory just because of this. and then there was this memory-alignment work-around (which i have removed for now because i've often got weird results == offsets in image-processing) which would not guarantee that the actual size of the buffer is equal to the requested size (but of course, you should never get less memory than requested).
so there are no real objections against removing the "<"-condition in favour of the "!=", but i am not very convinced that there is a real reason to change it.
mfg.as.dr IOhannes
chris clepper wrote:
On May 13, 2004, at 1:51 PM, IOhannes m zmoelnig wrote:
I've limited the valid range for 'offset' in lumaoffset to image.ysize/2 and that seems to have cured the crashes with YUV. RGB still segfaults at a line of pointer chasing around line 240. I'm a bit stumped as I've set up even more bounds checking and moved global variables to local and so on, but I can still crash it 100% of the time. I'm getting tired of
i just *thought* that i had fixed this now by range-checking (at least my simple crash-patch (turning on fill+smooth and putting the offset-multiplicator to 10000) doesn't crash any more on RGBA/YUV/Gray on our G4, but it still does onmy linux box.
furthermore i have fixed the [pix_dot] on macOS.
and finally i have added a "yuv"-message to the [pix_texture]-object to disable direct YUV-texturing on demand (because our g4 doesn't like em)
so that should be it (?)
nmfg.asd.r IOhannes
Hello all,
I tried sending "FSAA 2" and "FSAA 6" to the gemwin before creating but it seems still not to be AA in the window. Do I have to set an environment variable to tell the NVidia driver to AA?
Thanks Ben
zmoelnig@iem.at wrote:
hi again
Zitiere "B. Bogart" ben@ekran.org:
Hey Johannes,
Been busy with other things for some time.
well, i have spent one delightful week of holidays too and just returned to work today....
I did have textures working from the CVS in an older version (perhaps only 2 months old) on the same OS with the same libs. This just suddenly
stopped working one day when I did a cvs update. I don't think it would
be a non-debian specific problem... unless there is something new in the
pix_code that the suse gem dependancies don't lile.. but I don't get any
errors or warnings, just a complete lack of success! (loading video files of any kind I have around)
I tried recompiling from the lastest CVS todat and still no luck.
As for the font support did my config files help at all?
i knew i forgot something: the Base/config.h shouldn't be autoconfigured at all. this has changed a while ago and now config.h is the same for all platforms and and includes the apropriate os-specific file.
just a very wild guess: remove Base/config.h check it out again and recompile.
mfg.as.dr IOhannes
B. Bogart wrote:
Hello all,
I tried sending "FSAA 2" and "FSAA 6" to the gemwin before creating but it seems still not to be AA in the window. Do I have to set an environment variable to tell the NVidia driver to AA?
whta Gem is actually doing to get fsaa is to set the environment variable "__GL_FSAA_MODE" by itself. so you could try and set the env-variables and if they work (try other apps too), then there is an issue with Gem...
mfg.asdr.a IOhannes
-
B. Bogart -
chris clepper -
IOhannes m zmoelnig -
James Tittle II -
zmoelnig＠iem.at