> while POV license says clear:
>
>   You must provide all support for all users who use your custom version.

I'm just saying this stuff is prototype material; obviously
I'm not going to spend time fixing someone's use of the code
unless it happens to dovetail with my ongoing patch work.
Chris's note is well taken; I think POVLEGAL would phrase
it better to say "The POV-Team is not responsible for supporting
custom versions, and patch developers must not claim or imply
that it is." because that's the spirit of the agreement.



>   If  your  custom  version  contains  any  feature  that  would cause a
>   POV-Ray   scene  source  file  that  works  on your version to fail...

Yeah, that should be in.



> BTW 1, it would be great if in TER patch some sample TER file could be
attached
> with sample scene.

There's a sample Leveller TER available at
http://www.daylongraphics.com/products/leveller/download/testdoc.zip


> BTW 2, are you sure that all exe files listed in INTRODUCTION section of
> readme's are fully available ?

pvengine_daylon_ogl.exe isn't currently available,
but the intro section only lists what packages
might exist, not which ones actually exist.
The functionality is in pvengine_daylon.exe,
and the full source for all patches is always available.
It's not efficient for me to sit here and build
every possible permutation, especially when the
code is changing day by day.



> BTW 3, your changes in sources are nicely documented but would it be
possible to
> change naming of switches to something with PATCH string? See
> http://megapov.inetart.net/manual/internals.html#markup for details.

"DAYLON" is a standard mod identifier prefix my company uses.
I have tools that grep for it through several other
projects, etc. so it's not going to change.

At the end of the day, it's just a patch. I'm on information overload,
and not to belittle things, but I really can't cross every T and dot every
I.



> BTW 4, there is a note in TER patch description: "Since the xxx_FILE
constants
> in frame.h have no room for additional filetypes (not if each type has to
be a
> bitmask, anyway), the patch works by loading the TER file and then
pretending
> that it loaded a PNG grayscale file. It's inelegant, but it works."
> Look for MPEG_PORT_PATCH in MegaPOV 1.0 sources. This is probably more
'elegant'
> and expected solution.

Yeah, they've gone and shifted the bitmasks for several other
macros over to make room. But ultimately there's only so much room.
The filetype IDs should really be enum ordinals instead of bitmasks;
hopefully they'll do that in 4.0.

What I really wanted to do was patch POV so that it didn't
bother retaining filetype info after texture loading anyway,
because it's unnecessary. The pixels are converted into a
generic internal representation anyway. Instead of testing
all the filetypes in a big switch block during texture access,
it'd be better to just skip to the high-level Image struct attributes
like IS16GRAYIMAGE and go on that. Only the texture I/O code
should care about the filetype; it makes adding/removing filetypes
much easier. If they wanted to differentiate between different
texture types they should have constants like IS_MOVIE, IS_HEIGHTFIELD,
IS_MASK, or better still, just make an abstract CTexture or CImagemap
base class and subclass it to CMovie, CHeightfield, CMask, etc.
Then you have a base factory class like CTextureIO which
returns a base CTexture reference to a specific CTexture subclass
that it made when loading the bitmap e.g.:

   CTextureIO txIO(pszFilename);
   CTexture* pTexture = txIO.Read();


and CTextureIO::Read() does something like:

   // Create an object to handle the image format (bmp, jpeg, etc.).
   CImageFormatHandler* pFormatHandler =
     CTextureIOFactory::Instance(GetFileType(m_pszFilename));

   // Make a texture of the right type (grayscale, hf, rgb, indexed, etc.)
   CTexture* pTexture =
     CTextureFactory::Instance(pHandler->GetImageType());

   // Have the format handler load the texture.
   pFormatHandler->ReadInto(pTexture);
   delete pFormatHandler;

   return pTexture;


So now all the switch(filetype) stuff is in factory classes,
the format details are encased in specific IO classes,
and the rest of the code can work on an abstract level.
I'd also abstract filenames to a CFileID type, since
Macs use FSSpec records, but you see what I mean.


> BTW 5, are:
> #pragma comment(lib, "opengl32")
> #pragma comment(lib, "glu32")
> and
> #include "gl\gl.h"
> #include "gl\glu.h"
> part of larger library or just win32 specific components ? Don't you think
it is
> worth to list this library in banners like for LibPNG etc?

No. OGL is OEM stock included on Win32, so mentioning it
would be like mentioning gdi32.exe. On Linux, mentioning Mesa
might be proper, since it's a third-party lib.

Ray

Post a reply to this message