On Tue, 28 May 2013 15:15:24 +0100, Robert Osfield wrote:
The changes are now provided below. Could you test out svn/trunk and
let me know if this works fine with your datasets now.
Hi Robert,
I tested the trunk version and it works fine with rectangular textures.
Don't see any other
Hi Marcin,
I have now got on to do a second review your proposed changes for
osg::computeImageSizeInBytes(..) and have now merged these with a some
small changes to retain some of the original functionality - such as
catching dimensions such as 0 and below. This is would produce
different
Hi Robert,
sorry for not submitting second version as I promised but I had
extremely busy and complicated life last couple of months.
I'll try to test your submit this week and give you feedback.
Regards,
Marcin
On Tue, 28 May 2013 15:15:24 +0100, Robert Osfield wrote:
Hi Marcin,
I have
Hi Robert Marcin,
Just a little note: The submission called DDS - Crash fixes, improved handling of
S3TC-DXTC has something related with this topic. I guess both should not interfere,
but they may be complementary.
--
Sukender
PVLE - Lightweight cross-platform game engine -
Hi Marci,
On 6 February 2013 14:57, Marcin Prus p...@ai.com.pl wrote:
Robert,
problem I found is different from the one discussed about math/cmath/log
etc. and I can confirm it still exists in current version.
Algorithm is wrong, computation doesn't take block nature of some
compressions
On Fri, 8 Feb 2013 16:41:42 +, Robert Osfield wrote:
Hi Marci,
On 6 February 2013 14:57, Marcin Prus p...@ai.com.pl wrote:
Robert,
problem I found is different from the one discussed about
math/cmath/log
etc. and I can confirm it still exists in current version.
Algorithm is wrong,
HI Marcin,
On 5 February 2013 14:28, Marcin Prus p...@ai.com.pl wrote:
I've sent fix to submission list early january. Was it rejected? Or is it
still pending on your list?
I haven't posted a osg-submissions fix for this issue. Looking at
other threads about this issue it looks like using the
Robert,
problem I found is different from the one discussed about math/cmath/log
etc. and I can confirm it still exists in current version.
Algorithm is wrong, computation doesn't take block nature of some
compressions into account and fails for last mipmaps in non square
textures (size
Robert,
I've sent fix to submission list early january. Was it rejected? Or is
it still pending on your list?
Best,
Marcin Prus
W dniu 2013-01-07 15:12, Robert Osfield pisze:
HI Marcin,
Have you come up with a fix? I have plenty of stuff to get through so
any assistance on resolving this
HI Marcin,
Have you come up with a fix? I have plenty of stuff to get through so
any assistance on resolving this bug would be appreciated.
Thanks,
Robert.
On 28 December 2012 12:57, Marcin Prus p...@ai.com.pl wrote:
Hi all,
there's a bug in Image::computeImageSizeInBytes(int width,int
10 matches
Mail list logo
