Hi, try the attached patch. Note that the number of regions is arbitrary, the real limit is the total spu data (see http://web.archive.org/web/20020309020308/http://members.aol.com/mpucoder/DV...), but that's more difficult to foresee (anyway, in case it's reached the dxr3 plugin won't send any data to the spu). Note also that the plugin doesn't check the maximum number of sections (I've added a warning but it will probably segfault in case too many sections are added). I still couldn't find the cause of color bleeding: both the color manager (apart from the error fixed by the patch) and the spu encoder seems ok to me.
Bye
Luca Olivetti wrote:
I still couldn't find the cause of color bleeding: both the color manager (apart from the error fixed by the patch) and the spu encoder seems ok to me.
I found it and now it's gone :-) Apply the attached patch, additional to the previous one. Apart from the name change of a couple of variables, it only removes the bogus optimization that avoided calculating the index if the color hadn't changed (but since it might be in a different region/section it could well have a different index even if it's the same color).
Bye
Luca Olivetti wrote:
I still couldn't find the cause of color bleeding: both the color manager (apart from the error fixed by the patch) and the spu encoder seems ok to me.
I found it and now it's gone :-) Apply the attached patch, additional to the previous one. Apart from the name change of a couple of variables, it only removes the bogus optimization that avoided calculating the index if the color hadn't changed (but since it might be in a different region/section it could well have a different index even if it's the same color).
Bye
Hi !
Could you please resend the patch as I'm not able to apply it neither to branch HEAD nor branch vdr-dxr3-0-2 of current cvs (Something around line 212 in dxr3colormanager.c goes wrong, I messed around trying to solve it... but lost my nerves after 30min :), yeah I suck) ! BTW. I also applied the patch you sent in earlier.
Thank you !
Martin Cap wrote:
Luca Olivetti wrote:
I still couldn't find the cause of color bleeding: both the color manager (apart from the error fixed by the patch) and the spu encoder seems ok to me.
I found it and now it's gone :-) Apply the attached patch, additional to the previous one. Apart from the name change of a couple of variables, it only removes the bogus optimization that avoided calculating the index if the color hadn't changed (but since it might be in a different region/section it could well have a different index even if it's the same color).
Bye
Hi !
Could you please resend the patch as I'm not able to apply it neither to branch HEAD nor branch vdr-dxr3-0-2 of current cvs (Something around line 212 in dxr3colormanager.c goes wrong, I messed around trying to solve it... but lost my nerves after 30min :), yeah I suck) ! BTW. I also applied the patch you sent in earlier.
Maybe I made some modifications in between :-/ You can try the revised patch attached or the complete dxr3colormanager.[ch] also attached. Sorry for the problems.
Bye
Luca Olivetti wrote:
Maybe I made some modifications in between :-/ You can try the revised patch attached or the complete dxr3colormanager.[ch] also attached.
Great job. Two thumbs up.
I have no tearing-colors anymore, although the whole OSD-thing feels a little slower now (?), but - from what I did so far - there's still a couple of things that could be done different regarding OSD in the plugin (maybe faster then).
Most text2skin-skins also work (some make VDR crash the way they always did, I must remove logos there).
Sorry for the problems.
Bye
No prob. As long as the results are good as this ;) .
Martin Cap wrote:
Great job. Two thumbs up.
Thanks :-)
I have no tearing-colors anymore, although the whole OSD-thing feels a little slower now (?)
Yes, removing the "optimization" makes performance suffer, but I think a working osd is better than a fast one. Next time I'll try to optimize it a bit.
Bye
Ville Skyttä wrote:
On Sun, 2005-04-10 at 21:29 +0200, Martin Cap wrote:
Great job.
Seconded, and applied (a version without the unrelated changes) to the vdr-dxr3-0-2 branch in CVS.
Ok, so that you don't get bored ;-) , here's an "optimized" version (to apply over the previous one). The style isn't exactly what I like but it takes about half the time to do the color encoding than the previous one. Oh, and it also avoids doing it many times for the same screen ;-)
Bye
Luca Olivetti wrote:
Ok, so that you don't get bored ;-) , here's an "optimized" version (to apply over the previous one). The style isn't exactly what I like but it takes about half the time to do the color encoding than the previous one. Oh, and it also avoids doing it many times for the same screen ;-)
Brilliant :). Works like a charm.
Thank you !
Luca Olivetti wrote:
Ville Skyttä wrote:
On Sun, 2005-04-10 at 21:29 +0200, Martin Cap wrote:
Ok, so that you don't get bored ;-) , here's an "optimized" version (to apply over the previous one). The style isn't exactly what I like but it takes about half the time to do the color encoding than the previous one. Oh, and it also avoids doing it many times for the same screen ;-)
Hi,
Just a quick info what I've noticed: have you tried the recent "solitaire"-plugin? Bleeding colors sadly still appear there.
Martin Cap wrote:
Luca Olivetti wrote:
Ville Skyttä wrote:
On Sun, 2005-04-10 at 21:29 +0200, Martin Cap wrote:
Ok, so that you don't get bored ;-) , here's an "optimized" version (to apply over the previous one). The style isn't exactly what I like but it takes about half the time to do the color encoding than the previous one. Oh, and it also avoids doing it many times for the same screen ;-)
Hi,
Just a quick info what I've noticed: have you tried the recent "solitaire"-plugin? Bleeding colors sadly still appear there.
No, I didn't. With or without the "optimized" patch?
Bye
Luca Olivetti wrote:
Martin Cap wrote:
Luca Olivetti wrote:
No, I didn't. With or without the "optimized" patch?
Bye
Hi, well, I tried it with the optmizations. Must be due to the bitmaps used for the cards, all in all more than 16 colors, I guess. Thus, not the dxr3-plugins' fault ;).
Martin Cap wrote:
Luca Olivetti wrote:
Ville Skyttä wrote:
On Sun, 2005-04-10 at 21:29 +0200, Martin Cap wrote:
Ok, so that you don't get bored ;-) , here's an "optimized" version (to apply over the previous one). The style isn't exactly what I like but it takes about half the time to do the color encoding than the previous one. Oh, and it also avoids doing it many times for the same screen ;-)
Hi,
Just a quick info what I've noticed: have you tried the recent "solitaire"-plugin? Bleeding colors sadly still appear there.
Ok, I downloaded it and I'm afraid there's not much to do: it stretches the limit of the spu format (btw, I'd like to try some of the stuff the guys that designed this standard smoked, it must have been very strong stuff). The cards need too many regions (too many different adjacent colors for the jack, queen and king). I tried with MAX_REGIONS 120 in dxr3colormanager.h and it seems to work now *but* it could cause the spu data to grow to big, hence no picture at all. And it isn't too stable.
Bye
Martin Cap wrote:
Luca Olivetti wrote:
Martin Cap wrote:
Luca Olivetti wrote:
No, I didn't. With or without the "optimized" patch?
Bye
Hi, well, I tried it with the optmizations. Must be due to the bitmaps used for the cards, all in all more than 16 colors, I guess.
See my other message, but actually the limit of the spu unit is *4* simultaneous colors, the plugin achieves 16 by playing with highlight regions (each region can use 4 color different than the standard ones and different in each region, up to the palette limit of 16 colors). Each vertical region can have no more than 15 horizontal sections (each with different colors). It seems there is no limit in the number of regions but there's a limit in the total size of the data you can send the spu. If only there was a way to send the dxr3 the raw picture data....
Thus, not the dxr3-plugins' fault ;).
f<censored>g sigma design :-(
Bye
-
Luca Olivetti -
Martin Cap -
Ville Skyttä