xenocide-programming — The Programming Xenocide Mailing List

RE: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[Ed R. <Ed...@tu...>]

At 11:14 PM 8/3/2003 -0500, you wrote:

I was planning on writing a style guide for the coders here, using bits of
wisdom gleaned from conversations very similar to this. Of course, that is
in addition to the other work I already have.

On the plus side, I am fairly close to getting done with the text renderer.
I am writing cpp code now, and testing it as I go along. It should be fully
compatible with the old renderer code, and I will mark any backwards
compatibility code that should be removed once the old code is taken out.

A problem I have encountered is: I am working on a MSVC devpack, and for
some unknown reason (to me as of right now), the geoscape's logic works
differently from Borland to MSVC. There has been a problem where the MS
compiler does not execute the RTTI type statments quite correctly, or at
least they are different from borland's, because I am not sure what the
proper functionality is, I just know how each of them work. That is a
problem that I found out how to bypass, but I am running into another
problem that I have not found out the reason behind yet, and I decided not
to until I am done at least with the text renderer. Essentially, when you
click the mouse, the mousedown events go in the correct order, but the
mouseup events are not executing right. Specifically, the object that does
most of the stuff is setting the mouse button down value to false before it
can ever execute any useful statements.

Anyway, yeah, I'll find out why those are happening and propose ways to
patch the problem.

I had one question: I use a const static variable in my program, and I was
wondering whether I should name it as per the #defined stuff (_DEFAULT),
since it is only being used for the exact reason stated below, or if I
should name it as per a normal variable (default).



>Thanks for the reply.
>
>I am not going to argue about naming convention. There will never be a
>winner in such argument.
>
>As for performance issues, I agree with what is said below. It is not
>something I did not hear before. And it makes sense. I just thought that
>such issues must be taken care of by compiler, but I guess we cannot count
>that all compilers do that.=20
>
>As an afterthought about such discussion, I guess we need to come up with
>some basic rules for code optimization which every programmer must follow.
>We could have a FAQ or something on Sourceforge. What do you say?
>
>-----Original Message-----
>From: xen...@li...
>[mailto:xen...@li...] On Behalf Of
>Federico Andr=E9s Lois
>Sent: Sunday, August 03, 2003 5:40 PM
>To: xen...@li...
>Subject: Re: [Xenocide-programming] Fritz here, Font/Text renderer header
>files.
>
>
>Well the point with using defines instead of const int for that, do not=
 have
>a big impact on code writability, however, from the perspective of
>readability check this two codes...
>
>-----------------------------------------
>const Real pi =3D 3.1416
>
>Real f ( Real argument )
>{
>    return (2 * pi * argument );
>};
>-----------------------------------------
>#define _PI 3.1416
>
>Real f (Real argument )
>{
>    return (2 * _PI * argument);
>};
>-----------------------------------------
>Now from the point of view of static code analysis, using our conventions
>you can see that in the second case 2 * _PI is a constant that will be
>precalculated by the compiler. In the first one, you can be misleaded to
>think that pi is a variable (even though pi is not, you can find real life
>names that will) or worst a global variable. So if you can diferenciate=
 them
>in code via names, you are making a more readable code... Now you can argue
>that we can use a naming convention similar for that kind of constants,
>then: What is the difference between a const Real in a function and a
>conventional constant const Real?
>
>>From the compiled code point of view, when you use the define the 2 *=20
>>_PI
>instruction is optimized by the compiler as 6,2832 and then the compiled
>code looks like this:
>
>(I will take some poetic license here creating a special symbolic=
 assemblet,
>but it works to show the point)
>
>S - Stack Frame Pointer (where the function begins)
>
>MOV register0, S[argumentOffset];
>MULT register0, register0, 6,2832;
>MOV S[returnOffset], register0;
>
>in the second place you need an optimizing compiler to get that, however,
>because C++ have to support separate compilation if the constant you are
>using is defined and initialized in another file (module) then the compiler
>cannot know the real value (even though it wont be changed). So because of
>that limitations the best code you will get will look like this.
>
>MOV register0, S[argumentOffset];
>MOV register1, [piAddress];
>MULT register0, register0, 2;
>MULT register0, register0, register1;
>MOV S[returnOffset], register0;
>
>So If there is not a need to use complex structures, like in the case of
>vectors or matrices, where all identity ones are already defined as the
>latest kind of constants (because of a performance issue that I will=
 explain
>below) you should use defines... The case with that objects for instance is
>the next:
>
>We have some MiscRGBAColor objects already created. So we have
>miscColorBlack, miscColorRed and so on... now you have created n objects
>codifing colors. You can use defines too, suppose you want to define the=
 red
>color..
>
>#define _REDRGBACOLOR MiscRGBAColor (1,0,0,0);
>
>So for every place you have _REDRGBACOLOR in your code you are creating a
>new object instance. But there is something more sinister in this. The=
 scope
>of MiscRGBAColor is validated by the inclusion of an include statement, and
>the #define is not, because that is a precompiler macro... so that can
>create some difficult to diagnose compilation problems. So appart from the
>performance issues, there is some other problems that have to be
>addressed...
>
>Now, when to use defines and when to use const values? Easy, you have to=
 use
>defines when the type of the expression you used can be known by the
>compiler on compilation like characters, strings, integers, real numbers,
>etc.... You cant use them with user defined objects, so for that you have
>const values...
>
>Greetings
>Red Knight
>
>
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
>=20
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Xenocide-programming mailing list
>Xen...@li...
>https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>

Ed Ray
--
Ed...@tu...
ICQ: 2271040

RE: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[mamutas <ma...@pr...>]

Thanks for the reply.

I am not going to argue about naming convention. There will never be a
winner in such argument.

As for performance issues, I agree with what is said below. It is not
something I did not hear before. And it makes sense. I just thought that
such issues must be taken care of by compiler, but I guess we cannot =
count
that all compilers do that.=20

As an afterthought about such discussion, I guess we need to come up =
with
some basic rules for code optimization which every programmer must =
follow.
We could have a FAQ or something on Sourceforge. What do you say?

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Federico Andr=E9s Lois
Sent: Sunday, August 03, 2003 5:40 PM
To: xen...@li...
Subject: Re: [Xenocide-programming] Fritz here, Font/Text renderer =
header
files.


Well the point with using defines instead of const int for that, do not =
have
a big impact on code writability, however, from the perspective of
readability check this two codes...

-----------------------------------------
const Real pi =3D 3.1416

Real f ( Real argument )
{
    return (2 * pi * argument );
};
-----------------------------------------
#define _PI 3.1416

Real f (Real argument )
{
    return (2 * _PI * argument);
};
-----------------------------------------
Now from the point of view of static code analysis, using our =
conventions
you can see that in the second case 2 * _PI is a constant that will be
precalculated by the compiler. In the first one, you can be misleaded to
think that pi is a variable (even though pi is not, you can find real =
life
names that will) or worst a global variable. So if you can diferenciate =
them
in code via names, you are making a more readable code... Now you can =
argue
that we can use a naming convention similar for that kind of constants,
then: What is the difference between a const Real in a function and a
conventional constant const Real?

>From the compiled code point of view, when you use the define the 2 *=20
>_PI
instruction is optimized by the compiler as 6,2832 and then the compiled
code looks like this:

(I will take some poetic license here creating a special symbolic =
assemblet,
but it works to show the point)

S - Stack Frame Pointer (where the function begins)

MOV register0, S[argumentOffset];
MULT register0, register0, 6,2832;
MOV S[returnOffset], register0;

in the second place you need an optimizing compiler to get that, =
however,
because C++ have to support separate compilation if the constant you are
using is defined and initialized in another file (module) then the =
compiler
cannot know the real value (even though it wont be changed). So because =
of
that limitations the best code you will get will look like this.

MOV register0, S[argumentOffset];
MOV register1, [piAddress];
MULT register0, register0, 2;
MULT register0, register0, register1;
MOV S[returnOffset], register0;

So If there is not a need to use complex structures, like in the case of
vectors or matrices, where all identity ones are already defined as the
latest kind of constants (because of a performance issue that I will =
explain
below) you should use defines... The case with that objects for instance =
is
the next:

We have some MiscRGBAColor objects already created. So we have
miscColorBlack, miscColorRed and so on... now you have created n objects
codifing colors. You can use defines too, suppose you want to define the =
red
color..

#define _REDRGBACOLOR MiscRGBAColor (1,0,0,0);

So for every place you have _REDRGBACOLOR in your code you are creating =
a
new object instance. But there is something more sinister in this. The =
scope
of MiscRGBAColor is validated by the inclusion of an include statement, =
and
the #define is not, because that is a precompiler macro... so that can
create some difficult to diagnose compilation problems. So appart from =
the
performance issues, there is some other problems that have to be
addressed...

Now, when to use defines and when to use const values? Easy, you have to =
use
defines when the type of the expression you used can be known by the
compiler on compilation like characters, strings, integers, real =
numbers,
etc.... You cant use them with user defined objects, so for that you =
have
const values...

Greetings
Red Knight



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
=20

Re: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[<fl...@ma...>]

Well the point with using defines instead of const int for that, do not have
a big impact on code writability, however, from the perspective of
readability check this two codes...

-----------------------------------------
const Real pi = 3.1416

Real f ( Real argument )
{
    return (2 * pi * argument );
};
-----------------------------------------
#define _PI 3.1416

Real f (Real argument )
{
    return (2 * _PI * argument);
};
-----------------------------------------
Now from the point of view of static code analysis, using our conventions
you can see that in the second case 2 * _PI is a constant that will be
precalculated by the compiler. In the first one, you can be misleaded to
think that pi is a variable (even though pi is not, you can find real life
names that will) or worst a global variable. So if you can diferenciate them
in code via names, you are making a more readable code... Now you can argue
that we can use a naming convention similar for that kind of constants,
then: What is the difference between a const Real in a function and a
conventional constant const Real?

From the compiled code point of view, when you use the define the 2 * _PI
instruction is optimized by the compiler as 6,2832 and then the compiled
code looks like this:

(I will take some poetic license here creating a special symbolic assemblet,
but it works to show the point)

S - Stack Frame Pointer (where the function begins)

MOV register0, S[argumentOffset];
MULT register0, register0, 6,2832;
MOV S[returnOffset], register0;

in the second place you need an optimizing compiler to get that, however,
because C++ have to support separate compilation if the constant you are
using is defined and initialized in another file (module) then the compiler
cannot know the real value (even though it wont be changed). So because of
that limitations the best code you will get will look like this.

MOV register0, S[argumentOffset];
MOV register1, [piAddress];
MULT register0, register0, 2;
MULT register0, register0, register1;
MOV S[returnOffset], register0;

So If there is not a need to use complex structures, like in the case of
vectors or matrices, where all identity ones are already defined as the
latest kind of constants (because of a performance issue that I will explain
below) you should use defines... The case with that objects for instance is
the next:

We have some MiscRGBAColor objects already created. So we have
miscColorBlack, miscColorRed and so on... now you have created n objects
codifing colors. You can use defines too, suppose you want to define the red
color..

#define _REDRGBACOLOR MiscRGBAColor (1,0,0,0);

So for every place you have _REDRGBACOLOR in your code you are creating a
new object instance. But there is something more sinister in this. The scope
of MiscRGBAColor is validated by the inclusion of an include statement, and
the #define is not, because that is a precompiler macro... so that can
create some difficult to diagnose compilation problems. So appart from the
performance issues, there is some other problems that have to be
addressed...

Now, when to use defines and when to use const values? Easy, you have to use
defines when the type of the expression you used can be known by the
compiler on compilation like characters, strings, integers, real numbers,
etc.... You cant use them with user defined objects, so for that you have
const values...

Greetings
Red Knight


----- Original Message ----- 
From: "mamutas" <ma...@pr...>
To: <xen...@li...>
Sent: Saturday, August 02, 2003 11:44 PM
Subject: FW: [Xenocide-programming] Fritz here, Font/Text renderer header
files.


> Also, why do we use defines for style flags? Why not to use static const
int
> instead? See sample of code below.
>
> // RED KNIGHT: Modify this names to be consistent with new code
convention,
> that was old code so dont use it that way. If we are going to break the
> code, then break it completly and we will make things look better.
>
> // OLD CONVENTION: _STYLE<something>
> // NEW CONVENTION: _FS<something> (FS stand for FONTSTYLE)
>
> #define _STYLENONE 0
> #define _STYLEITALIC 1
> #define _STYLEUNDERLINE 2
> #define _STYLESTRIKEOUT 4
>
> Regards,
> mamutas
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
>

FW: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[mamutas <ma...@pr...>]

Also, why do we use defines for style flags? Why not to use static const int
instead? See sample of code below.

// RED KNIGHT: Modify this names to be consistent with new code convention,
that was old code so dont use it that way. If we are going to break the
code, then break it completly and we will make things look better. 

// OLD CONVENTION: _STYLE<something> 
// NEW CONVENTION: _FS<something> (FS stand for FONTSTYLE) 

#define _STYLENONE 0 
#define _STYLEITALIC 1 
#define _STYLEUNDERLINE 2 
#define _STYLESTRIKEOUT 4

Regards,
mamutas

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
 

RE: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[mamutas <ma...@pr...>]

I am not quite sure why do we want to print string to fit specific =
height
and width. Does it mean, that if string is too long, it will be shrinked =
and
if the string is too short, it will be stretched? I don't think we want =
such
functionality. I would rather expect string to be printed in its 'real' =
font
with given height, weight, etc.

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Federico Andr=E9s Lois
Sent: Tuesday, July 29, 2003 12:45 PM
To: xen...@li...
Subject: Re: [Xenocide-programming] Fritz here, Font/Text renderer =
header
files.


OK I've done some corrections (mostly point out what needs to be =
changed). I
will put the code here for archival purposes but I also attach it. Look
where it sais RED KNIGHT REVIEW...

textrenderer.h

#include <utility/common.h>
#include <utility/misc.h>
#include "fonts.h"

namespace XenoEngine
{

//  RED KNIGHT REVIEW: Do not indent the classes... this is an example =
of
how it should look /////..................

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
=20

Re: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[Ed R. <Ed...@tu...>]

At 04:37 PM 8/1/2003 -0300, you wrote:
>Hi Ed,
>
>> Found a logic error with the Lazy Evaluation, makes life a little slower
>> and alot simpler now.
>I just have one question about the callback function. Can you gives us an
>example of how it works in code?. As far as I can see you need a plain C
>function to use it, and that can disrupt everything cause you wont have
>access to the object... In that case is preferable to create a Callback
>object with a virtual method...

It is meant to be used with static functions, but I figured out that it
really isn't needed for what I am doing, but the functionality is still
there, so I left it. You can also use function adapters to access the data
inside. It would be easy to take out.

>> Decided since the XeFont was the only thing that will ever be able to
>> access the XeFontData, to neglect getters and setters, and instead just
>> make the class a friend.
>Use them even if the object is a data structure, because if you for a reason
>decide to change the internal representation to make it more space or speed
>efficient you will have to change in a lot of places... instead using
>methods you can always inline the stuff for speed or if you are space
>optimizing get that information from the OS instead of cache it in the
>object...

Done. No worries about that, found out that I needed it anyway.

>Just another simple thing:
>
>Where you wrote:
>
>    //! Height from baseline to top of highest character
>    Int32 getAscent() const;
>    //! Height from baseline to bottom of lowest character
>    Int32 getDescent() const;
>    //! Maximum character width
>    Int32 getMaxCharWidth() const;
>    //! Average Character Width
>    Int32 getAveCharWidth() const;
>    //! Space before a character
>    Int32 getInternalLeadingSpace() const;
>    //! Space after a character
>    Int32 getExternalLeadingSpace() const;
>    //! Get the overhang of a font
>    //! /note Overhang is the little bit at the end of an italicised string
>that goes beyond the actual string width
>    Int32 getOverHang() const;
>    //! Get the Default Character (used for characters not in the font)
>    Int8 getDefaultCharacter() const;
>    //! Get the character to use for line padding
>    Int8 getSpaceCharacter() const;
>
>
>Those are not platform specific, the fact that W32 API let you retrieve them
>in a simple call using a TEXTMETRIC structure nothing have to do with
>platform dependencency... That parameters are needed by any text engine to
>position and render the fonts, what should be hidden is how you get those
>parameters from the font or the OS.

Right, I thought I had not commented those as platform specific, but
apparently they still are... Will fix that. I am also storing the variables
in the FontData so they will be easily accessable, and not have to make
platform specific calls every time they need to be accesssed.

>Greetings
>Red Knight
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Xenocide-programming mailing list
>Xen...@li...
>https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>

Ed Ray
--
Ed...@tu...
ICQ: 2271040

Re: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[<fl...@ma...>]

Hi Ed,

> Found a logic error with the Lazy Evaluation, makes life a little slower
> and alot simpler now.
I just have one question about the callback function. Can you gives us an
example of how it works in code?. As far as I can see you need a plain C
function to use it, and that can disrupt everything cause you wont have
access to the object... In that case is preferable to create a Callback
object with a virtual method...

> Decided since the XeFont was the only thing that will ever be able to
> access the XeFontData, to neglect getters and setters, and instead just
> make the class a friend.
Use them even if the object is a data structure, because if you for a reason
decide to change the internal representation to make it more space or speed
efficient you will have to change in a lot of places... instead using
methods you can always inline the stuff for speed or if you are space
optimizing get that information from the OS instead of cache it in the
object...

Just another simple thing:

Where you wrote:

    //! Height from baseline to top of highest character
    Int32 getAscent() const;
    //! Height from baseline to bottom of lowest character
    Int32 getDescent() const;
    //! Maximum character width
    Int32 getMaxCharWidth() const;
    //! Average Character Width
    Int32 getAveCharWidth() const;
    //! Space before a character
    Int32 getInternalLeadingSpace() const;
    //! Space after a character
    Int32 getExternalLeadingSpace() const;
    //! Get the overhang of a font
    //! /note Overhang is the little bit at the end of an italicised string
that goes beyond the actual string width
    Int32 getOverHang() const;
    //! Get the Default Character (used for characters not in the font)
    Int8 getDefaultCharacter() const;
    //! Get the character to use for line padding
    Int8 getSpaceCharacter() const;


Those are not platform specific, the fact that W32 API let you retrieve them
in a simple call using a TEXTMETRIC structure nothing have to do with
platform dependencency... That parameters are needed by any text engine to
position and render the fonts, what should be hidden is how you get those
parameters from the font or the OS.

Greetings
Red Knight

Re: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[Ed R. <Ed...@tu...>]

At 02:45 PM 7/29/2003 -0300, you wrote:

Take 3 of the header files. 

Found a logic error with the Lazy Evaluation, makes life a little slower
and alot simpler now.

Decided since the XeFont was the only thing that will ever be able to
access the XeFontData, to neglect getters and setters, and instead just
make the class a friend.

Re: [Xenocide-programming] Fritz here, Font/Text renderer header files.

[<fl...@ma...>]

OK I've done some corrections (mostly point out what needs to be changed). I
will put the code here for archival purposes but I also attach it. Look
where it sais RED KNIGHT REVIEW...

textrenderer.h

#include <utility/common.h>
#include <utility/misc.h>
#include "fonts.h"

namespace XenoEngine
{

//  RED KNIGHT REVIEW: Do not indent the classes... this is an example of
how it should look
//////// Indent Example //////////
class XeTextRenderer
{
public:
 //! Prints a string to the screen.
   //! /note 0 on the font pointer means use what we got set.
   void printString(Real x, Real y, Real z, const char* string, XeFont* font
= 0, Utility::Misc::MiscColorRGB color = Utility::Misc::MiscColorRGB(0,0,0),
bool vertical = false, Real angle = 0.0);
/////// End Indent Example ////////

        //! Prints a string to fit a width/height.
        //! RED KNIGHT REVIEW: reference shouldnt be = 0, use = NULL
instead... and please use a more readable name.
        //! RED KNIGHT REVIEW: For the color in Utility::Misc add a using
namespace clause at the beginning and avoid using the fully qualified name
in here cause it is detrimental to readability.
        //! RED KNIGHT REVIEW: I suggest if you are using defaults in Color
to add some entries in the utility package of constant objects like
colorBlack, colorWhite and the like.
        void printStringToScale(Real x, Real y, Real z, Real width, Real
height, const char* string, Utility::Misc::MiscColorRGB color =
Utility::Misc::MiscColorRGB(0,0,0), XeFont* reference = 0, bool vertical =
false, Real angle = 0.0);

        //! Set the font to a stored version
        void setFont(const XeFont& font);

        //! Create a font and return it for referencing later.
        //  RED KNIGHT REVIEW: Get is not a proper name, even though you are
not creating the font after a call... use createFont instead
        //  RED KNIGHT REVIEW: Add an String overloaded function too.
        //  RED KNIGHT REVIEW: Weight is of type FONTWEIGHT, bold, italic
and understrike are toghether an Int32 under the type FONTSTYLE.
        //  RED KNIGHT REVIEW: You are missing the Quality argument.
        XeFont getNewFont(const char* name, int size, int weight, bool
bold=false, bool italic=false, bool underline=false, bool strikeout=false);

        //! Return the default font.
        XeFont getDefaultFont();

        //  RED KNIGHT REVIEW: You are missing the getCurrentFont method.
(it is pretty useful)
        //  RED KNIGHT REVIEW: You can add a pushFont and popFont like the
pushMatrix and popMatrix in OpenGL. They are pretty useful.

    protected:
        friend class XeOpenGLRenderer;

        //! Constructor
        //! /remark May only be called by the XeOpenGLRenderer
        XeTextRenderer();

        //! Destructor
        //! /remark May only be called by the XeOpenGLRenderer
        ~XeTextRenderer();

    private:
        //! The current font being used.
        //! RED KNIGHT REVIEW: Do not use underscores for variables or
methods names, only on enum values and at the beginning.
        XeFont m_currentfont;
        //! The default font.
        //! RED KNIGHT REVIEW: Do not use underscores for variables or
methods names, only on enum values and at the beginning.
        XeFont m_defaultfont;
    };
}// XenoEngine Namespace





fonts.h

#include <utility/common.h>
#include <utility/misc.h>

namespace XenoEngine
{

// RED KNIGHT: Modify this names to be consistent with new code convention,
that was old code so dont use it that way. If we are going to break the
code, then break it completly and we will make things look better.
// OLD CONVENTION: _STYLE<something>
// NEW CONVENTION: _FS<something> (FS stand for FONTSTYLE)
#define _STYLENONE 0
#define _STYLEITALIC 1
#define _STYLEUNDERLINE 2
#define _STYLESTRIKEOUT 4

    class XeFontData;

    class XeFont
    {
    public:
        enum FONTWEIGHT { _FWDONTCARE = 0, _FWNORMAL = 400, _FWBOLD = 700,
_FWBLACK = 900 };
        enum FONTQUALITY { _FQPROOF = 6470, _FQDRAFT, _FQNONANTIALIASED,
_FQDEFAULT, _FQANTIALIASED };

        // ADDED BY RED KNIGHT
        typedef Int32 FONTSTYLE;

        virtual ~XeFont ();

        String getFontName ();
        FONTWEIGHT getWeight ();
        FONTQUALITY getQuality ();
        Int32 getSize ();

        //! Returns the base address of the compiled list where the fonts
are stored.
        UInt32 getBaseList ();

        Bool isItalic ();
        Bool isUnderline ();
        Bool isStrikeout ();

        Bool isValid ();

        //! Returns the horizontal size of the string in the screen in
pixels.
        UInt32 getStringHorizontalSize (String string);
        //! Returns the vertical size of the string in the screen in pixels.
        //! /note The vertical is how tall the string would be if displayed
vertically.
        UInt32 getStringVerticalSize (String string);
        //! Returns the vertical size of a horizontally displayed string in
pixels.
        UInt32 getStringHeight(String string);

    protected:

        friend class XeTextRenderer;

        //! The Contructor
        //! /remark This must only be called by the XeTextRenderer
        //! RED KNIGHT: style type have to change from Int32 to FONTSTYLE
        XeFont (String& font, Int32 size, FONTWEIGHT weight, Int32 style,
FONTQUALITY quality);

        //! Returns the horizontal size vector to be filled by the
XeTextRenderer after creating the font.
        //! /remark This must only be called by the XeTextRenderer
        std::vector<UInt8>& getHorizontalSizeVector ();

        //! Sets the vertical size of the font.
        //! /remark This must only be called by the XeTextRenderer
        //! RED KNIGHT REVIEW: If you add the information showed below you
wont need that.
        void setVerticalRealSize (Int32 realSize);

        //! Platform dependent font creator
        void createFont ();

    private:
        //! The functions below is the tracking mechanism for fonts. It
makes sure that
        //! no more than one GLlist is created and maintained for each font.
It does all
        //! of this transparently.

        //! Lazy Evaluated Font Data
        //! /note Lazy Evaluation is a one-to-many data-to-object way of
saving memory.
        //! RED KNIGHT REVIEW: Do not use underscores for variables or
methods names, only on enum values and at the beginning.
        LazyEvaluation<XeFontData> m_fontdata;

        //! This data vector keeps track of all font instances
        static std::vector<LazyEvaluation<XeFontData>*> fonts;

        //! Creates(Reuses) a tracked lazy evaluation of the font data.
        //! /remark Used in the constructor to create a non-unique version
of the font if possible.
        static LazyEvaluation<XeFontData> createTrackedFontData(const
XeFontData& reference);

        //! Destroys the font list, and removes the lazy evaluation from the
fonts vector.
        static void destroyTrackedFontData(const LazyEvaluation<XeFontData>&
value);
    };

    //! This class is used to store all the information about a font.
    class XeFontData
    {
    public:
        XeFontData& operator=(const XeFontData& obj);

        //! RED KNIGHT REVIEW: Change obj2 to sourceObject and obj1 to
destinationObject
        friend bool operator==(const XeFontData& obj1, const XeFontData&
obj2);

        //! RED KNIGHT REVIEW: If this means that you are going to check for
less than, you need a CRC Number or something cause it wont work with simple
attributes because there is not a real algebraic order. If the symbol is
intended to be use in something different dont use operators cause it cause
readability problems.
        //! RED KNIGHT REVIEW: Change obj2 to sourceObject and obj1 to
destinationObject
        friend bool operator<(const XeFontData& obj1, const XeFontData&
obj2);

//! RED KNIGHT REVIEW: Implement the setters and getters for the values if
needed, however most of the information will have to be queried from the
platform in a platform specific call. Define a standard function to that
platform dependant stuff and implement it on a cpp file in the \win32
directory under the current one...
//! RED KNIGHT REVIEW: If you use inlines, put them under the \inline
directory

    protected:

        friend class XeFont;


        String fontName;
        Int32 size;

        //! RED KNIGHT REVIEW: After the changes this MUST be
XeFont::FONTSTYLE.
        Int32 style;

        XeFont::FONTQUALITY quality;
        XeFont::FONTQUALITY weight;

        UInt32 baseList;
        Int32 realSize;
        std::vector<UInt8> horizontalCharSize;
    };
}; // XenoEngine Namespace

//! RED KNIGHT REVIEW: There is lots of infomation that you can add here
that will make text management far easier, specially when you have to do
something difficult.
//! This is taken from the W32 SDK but it will give you some idea of what
else you can add to this.

/*
The TEXTMETRIC structure contains basic information about a physical font.
All sizes are given in logical units; that is, they depend on the current
mapping mode of the display context.

tmHeight : Specifies the height (ascent + descent) of characters.
tmAscent : Specifies the ascent (units above the base line) of characters.
tmDescent : Specifies the descent (units below the base line) of characters.
tmInternalLeading : Specifies the amount of leading (space) inside the
bounds set by the tmHeight member. Accent marks and other diacritical
characters may occur in this area. The designer may set this member to zero.
tmExternalLeading : Specifies the amount of extra leading (space) that the
application adds between rows. Since this area is outside the font, it
contains no marks and is not altered by text output calls in either OPAQUE
or TRANSPARENT mode. The designer may set this member to zero.
tmAveCharWidth : Specifies the average width of characters in the font
(generally defined as the width of the letter x). This value does not
include the overhang required for bold or italic characters.
tmMaxCharWidth : Specifies the width of the widest character in the font.
*/




lazyevaluation.h

#include <utility/common.h>

namespace Utility
{

    //! Lazy evaluation allows you to create a single copy of an item
    //! that is referenced by multiple instances of an object
    template <class T>
    class LazyEvaluation
    {
    public:
        //! RED KNIGHT REVIEW: Do not use 0 when what you need is NULL.
        //! RED KNIGHT REVIEW: initial in not the better name for it, i
guess that initial is and instance, am I right?. Use identifiers as much
bigger as you need to make the code readable.
        LazyEvaluation(const T& initial,void (*destroy)(T& todestroy) = 0);

        LazyEvaluation(const LazyEvaluation& obj);

        ~LazyEvaluation();

        LazyEvaluation& operator=(const LazyEvaluation& obj);

        T& operator*();

        T& operator->();

    private:

        LazyEvaluation();

        //! RED KNIGHT REVIEW: Do not use underscores for variables or
methods names, only on enum values and at the beginning.
        //! RED KNIGHT REVIEW: Please document what is the meaning of this
and why you did it this way, that is because is difficult to read, we should
do that for every construct that can become ambiguous or not show its
meaning and use on a first glance.
        void (*m_destroy)(T& todestroy);
        //! RED KNIGHT REVIEW: Do not use underscores for variables or
methods names, only on enum values and at the beginning.
        UInt32& m_count;
        //! RED KNIGHT REVIEW: Do not use underscores for variables or
methods names, only on enum values and at the beginning.
        T& m_value;
    };
}


Greetings
Red Knight







----- Original Message ----- 
From: "Ed Ray" <Ed...@tu...>
To: <xen...@li...>
Sent: Tuesday, July 29, 2003 5:16 AM
Subject: [Xenocide-programming] Fritz here, Font/Text renderer header files.


> At 05:59 PM 7/28/2003 -0300, you wrote:
>
> I have the header files done for the text renderer, as well as the new
font
> control. Of course, since they are untested header files, they are sure to
> be full of errors, though I ran a surface compiler through them to get rid
> of any syntax/container errors.
>
> Let me know what you think. I'm going to head to bed now. :-)
>
> >And  I recommend to tag those methods with the \deprecated (or something
> >like that) in the doxygen documentation too. And with a descriptive
> >description of how it is done in the new system...
> >
> >Greetings
> >Red Knight
> >
> >----- Original Message ----- 
> >From: "mamutas" <ma...@pr...>
> >To: <xen...@li...>
> >Sent: Saturday, July 26, 2003 11:34 PM
> >Subject: RE: [Xenocide-programming] Fritz here, Font/Text engine makeover
> >proposal.
> >
> >
> >> Hi Ed,
> >>
> >> Welcome to the team.
> >>
> >> You plan looks very reasonable and well thought through. I am in
> >aticipation
> >> to see its results.
> >>
> >> As a suggestion about deprecated functions, I recommend to insert an
> >> assertion call in each of them. Thus every time the depricated function
> >will
> >> be called, the entry will be put in the log indicating that. Those
> >functions
> >> are defined in QA library, advanceassert.h.
> >>
> >> Regards,
> >> mamutas
> >>
> >>
> >> -----Original Message-----
> >> From: xen...@li...
> >> [mailto:xen...@li...] On Behalf Of
Ed
> >> Ray
> >> Sent: Saturday, July 26, 2003 1:44 AM
> >> To: xen...@li...
> >> Subject: [Xenocide-programming] Fritz here, Font/Text engine makeover
> >> proposal.
> >>
> >>
> >> Howdy all, new programmer on the team here, and it seems my first job
is
> >to
> >> improve our font/text engine's capabilities. Without further ado, here
> >goes.
> >>
> >> Current issues with the displaying of text:
> >>
> >> Text functions are currently scattered within the XeOpenGLRenderer and
> >> various other functions. Fonts are free-floating objects, with no
current
> >> management, which is not good as they are very resource-hungry.
Font/Text
> >> interaction has very limited flexability without being done by hand.
Fonts
> >> have few tools to make life easier, only width/height checking.
> >>
> >> Solution:
> >> Create XeTextRenderer, make it accessable through the XeOpenGLRenderer.
> >> Encapsulate all text drawing functionality into the XeTextRenderer.
> >> Encapsulate font management into the XeTextRenderer.
> >>
> >> The XeTextRenderer will have the following capability:
> >> -Create, manage, and select fonts
> >> -Deal with rotation, vertical vs horizontal drawing.
> >> -Scale or style fonts/strings to fit inside restrictive boxes (So
> >> the text fits in the button).
> >> -Draw text on a 2d surface.
> >> -Draw text in 3d, if necessary.
> >> -Be accessible through XeOpenGLRenderer.
> >>
> >> Text drawing is extremely simple, and there should not be any problem
> >> implementing the XeTextRenderer functions anywhere, as it will be a
simple
> >> call away from the renderer. The only issue will be obsoleting all the
> >> previous functions.
> >>
> >> The font memory management would probably best be done using a fairly
> >simple
> >> font handling technique. When you want a handle to a font, you tell the
> >> TextRenderer to build it, and it will use a lazy-evaluation class (ala
STL
> >> strings, one copy, many references to it) to produce the font lists.
There
> >> will of course be a way to define a default text, if you just want to
> >write
> >> something and have it be the same as "everything else". The lists are
the
> >> big memory-hog anyway, so having the handles use the same lists, but
> >> different 'other variables' (everything not defined when the font is
> >> created, eg: verticality, color) should be fine.
> >>
> >> The big 'issue' is that fonts are currently used in quite a few
different
> >> places in the code. I'll go ahead and keep everything backwards
compatible
> >> for now, because the only place that it is heavily used is in the
> >> WinToolkit, which I hear is geared for a heavy makeover. I'll comment
the
> >> functions as being obsolete in the code that are remaining for
backwards
> >> compatibility.
> >>
> >> I'll go ahead and wait till tomorrow to start drawing up the .h files,
to
> >> see if there are any concerns.
> >>
> >>
> >> Ed Ray
> >> --
> >> Ed...@tu...
> >> ICQ: 2271040
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >Data
> >> Reports, E-commerce, Portals, and Forums are available now. Download
today
> >> and enter to win an XBOX or Visual Studio .NET.
> >>
>
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> >> _______________________________________________
> >> Xenocide-programming mailing list
> >Xen...@li...
> >> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> >>
> >>
> >> ---
> >> Incoming mail is certified Virus Free.
> >> Checked by AVG anti-virus system (http://www.grisoft.com).
> >> Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
> >>
> >>
> >> ---
> >> Outgoing mail is certified Virus Free.
> >> Checked by AVG anti-virus system (http://www.grisoft.com).
> >> Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >> Data Reports, E-commerce, Portals, and Forums are available now.
> >> Download today and enter to win an XBOX or Visual Studio .NET.
> >>
>
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> >> _______________________________________________
> >> Xenocide-programming mailing list
> >> Xen...@li...
> >> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> >>
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >Data Reports, E-commerce, Portals, and Forums are available now.
> >Download today and enter to win an XBOX or Visual Studio .NET.
>
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> >_______________________________________________
> >Xenocide-programming mailing list
> >Xen...@li...
> >https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> >


----------------------------------------------------------------------------
----


>
>
> Ed Ray
> --
> Ed...@tu...
> ICQ: 2271040

[Xenocide-programming] Fritz here, Font/Text renderer header files.

[Ed R. <Ed...@tu...>]

At 05:59 PM 7/28/2003 -0300, you wrote:

I have the header files done for the text renderer, as well as the new font
control. Of course, since they are untested header files, they are sure to
be full of errors, though I ran a surface compiler through them to get rid
of any syntax/container errors.

Let me know what you think. I'm going to head to bed now. :-)

>And  I recommend to tag those methods with the \deprecated (or something
>like that) in the doxygen documentation too. And with a descriptive
>description of how it is done in the new system...
>
>Greetings
>Red Knight
>
>----- Original Message ----- 
>From: "mamutas" <ma...@pr...>
>To: <xen...@li...>
>Sent: Saturday, July 26, 2003 11:34 PM
>Subject: RE: [Xenocide-programming] Fritz here, Font/Text engine makeover
>proposal.
>
>
>> Hi Ed,
>>
>> Welcome to the team.
>>
>> You plan looks very reasonable and well thought through. I am in
>aticipation
>> to see its results.
>>
>> As a suggestion about deprecated functions, I recommend to insert an
>> assertion call in each of them. Thus every time the depricated function
>will
>> be called, the entry will be put in the log indicating that. Those
>functions
>> are defined in QA library, advanceassert.h.
>>
>> Regards,
>> mamutas
>>
>>
>> -----Original Message-----
>> From: xen...@li...
>> [mailto:xen...@li...] On Behalf Of Ed
>> Ray
>> Sent: Saturday, July 26, 2003 1:44 AM
>> To: xen...@li...
>> Subject: [Xenocide-programming] Fritz here, Font/Text engine makeover
>> proposal.
>>
>>
>> Howdy all, new programmer on the team here, and it seems my first job is
>to
>> improve our font/text engine's capabilities. Without further ado, here
>goes.
>>
>> Current issues with the displaying of text:
>>
>> Text functions are currently scattered within the XeOpenGLRenderer and
>> various other functions. Fonts are free-floating objects, with no current
>> management, which is not good as they are very resource-hungry. Font/Text
>> interaction has very limited flexability without being done by hand. Fonts
>> have few tools to make life easier, only width/height checking.
>>
>> Solution:
>> Create XeTextRenderer, make it accessable through the XeOpenGLRenderer.
>> Encapsulate all text drawing functionality into the XeTextRenderer.
>> Encapsulate font management into the XeTextRenderer.
>>
>> The XeTextRenderer will have the following capability:
>> -Create, manage, and select fonts
>> -Deal with rotation, vertical vs horizontal drawing.
>> -Scale or style fonts/strings to fit inside restrictive boxes (So
>> the text fits in the button).
>> -Draw text on a 2d surface.
>> -Draw text in 3d, if necessary.
>> -Be accessible through XeOpenGLRenderer.
>>
>> Text drawing is extremely simple, and there should not be any problem
>> implementing the XeTextRenderer functions anywhere, as it will be a simple
>> call away from the renderer. The only issue will be obsoleting all the
>> previous functions.
>>
>> The font memory management would probably best be done using a fairly
>simple
>> font handling technique. When you want a handle to a font, you tell the
>> TextRenderer to build it, and it will use a lazy-evaluation class (ala STL
>> strings, one copy, many references to it) to produce the font lists. There
>> will of course be a way to define a default text, if you just want to
>write
>> something and have it be the same as "everything else". The lists are the
>> big memory-hog anyway, so having the handles use the same lists, but
>> different 'other variables' (everything not defined when the font is
>> created, eg: verticality, color) should be fine.
>>
>> The big 'issue' is that fonts are currently used in quite a few different
>> places in the code. I'll go ahead and keep everything backwards compatible
>> for now, because the only place that it is heavily used is in the
>> WinToolkit, which I hear is geared for a heavy makeover. I'll comment the
>> functions as being obsolete in the code that are remaining for backwards
>> compatibility.
>>
>> I'll go ahead and wait till tomorrow to start drawing up the .h files, to
>> see if there are any concerns.
>>
>>
>> Ed Ray
>> --
>> Ed...@tu...
>> ICQ: 2271040
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data
>> Reports, E-commerce, Portals, and Forums are available now. Download today
>> and enter to win an XBOX or Visual Studio .NET.
>>
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>> _______________________________________________
>> Xenocide-programming mailing list
>Xen...@li...
>> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>>
>>
>> ---
>> Incoming mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
>>
>>
>> ---
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>>
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>> _______________________________________________
>> Xenocide-programming mailing list
>> Xen...@li...
>> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Xenocide-programming mailing list
>Xen...@li...
>https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>

Re: [Xenocide-programming] Fritz here, Font/Text engine makeover proposal.

[<fl...@ma...>]

And  I recommend to tag those methods with the \deprecated (or something
like that) in the doxygen documentation too. And with a descriptive
description of how it is done in the new system...

Greetings
Red Knight

----- Original Message ----- 
From: "mamutas" <ma...@pr...>
To: <xen...@li...>
Sent: Saturday, July 26, 2003 11:34 PM
Subject: RE: [Xenocide-programming] Fritz here, Font/Text engine makeover
proposal.


> Hi Ed,
>
> Welcome to the team.
>
> You plan looks very reasonable and well thought through. I am in
aticipation
> to see its results.
>
> As a suggestion about deprecated functions, I recommend to insert an
> assertion call in each of them. Thus every time the depricated function
will
> be called, the entry will be put in the log indicating that. Those
functions
> are defined in QA library, advanceassert.h.
>
> Regards,
> mamutas
>
>
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of Ed
> Ray
> Sent: Saturday, July 26, 2003 1:44 AM
> To: xen...@li...
> Subject: [Xenocide-programming] Fritz here, Font/Text engine makeover
> proposal.
>
>
> Howdy all, new programmer on the team here, and it seems my first job is
to
> improve our font/text engine's capabilities. Without further ado, here
goes.
>
> Current issues with the displaying of text:
>
> Text functions are currently scattered within the XeOpenGLRenderer and
> various other functions. Fonts are free-floating objects, with no current
> management, which is not good as they are very resource-hungry. Font/Text
> interaction has very limited flexability without being done by hand. Fonts
> have few tools to make life easier, only width/height checking.
>
> Solution:
> Create XeTextRenderer, make it accessable through the XeOpenGLRenderer.
> Encapsulate all text drawing functionality into the XeTextRenderer.
> Encapsulate font management into the XeTextRenderer.
>
> The XeTextRenderer will have the following capability:
> -Create, manage, and select fonts
> -Deal with rotation, vertical vs horizontal drawing.
> -Scale or style fonts/strings to fit inside restrictive boxes (So
> the text fits in the button).
> -Draw text on a 2d surface.
> -Draw text in 3d, if necessary.
> -Be accessible through XeOpenGLRenderer.
>
> Text drawing is extremely simple, and there should not be any problem
> implementing the XeTextRenderer functions anywhere, as it will be a simple
> call away from the renderer. The only issue will be obsoleting all the
> previous functions.
>
> The font memory management would probably best be done using a fairly
simple
> font handling technique. When you want a handle to a font, you tell the
> TextRenderer to build it, and it will use a lazy-evaluation class (ala STL
> strings, one copy, many references to it) to produce the font lists. There
> will of course be a way to define a default text, if you just want to
write
> something and have it be the same as "everything else". The lists are the
> big memory-hog anyway, so having the handles use the same lists, but
> different 'other variables' (everything not defined when the font is
> created, eg: verticality, color) should be fine.
>
> The big 'issue' is that fonts are currently used in quite a few different
> places in the code. I'll go ahead and keep everything backwards compatible
> for now, because the only place that it is heavily used is in the
> WinToolkit, which I hear is geared for a heavy makeover. I'll comment the
> functions as being obsolete in the code that are remaining for backwards
> compatibility.
>
> I'll go ahead and wait till tomorrow to start drawing up the .h files, to
> see if there are any concerns.
>
>
> Ed Ray
> --
> Ed...@tu...
> ICQ: 2271040
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data
> Reports, E-commerce, Portals, and Forums are available now. Download today
> and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Xenocide-programming mailing list
Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>

RE: [Xenocide-programming] Fritz here, Font/Text engine makeover proposal.

[mamutas <ma...@pr...>]

Hi Ed,

Welcome to the team.

You plan looks very reasonable and well thought through. I am in =
aticipation
to see its results.

As a suggestion about deprecated functions, I recommend to insert an
assertion call in each of them. Thus every time the depricated function =
will
be called, the entry will be put in the log indicating that. Those =
functions
are defined in QA library, advanceassert.h.

Regards,
mamutas


-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of =
Ed
Ray
Sent: Saturday, July 26, 2003 1:44 AM
To: xen...@li...
Subject: [Xenocide-programming] Fritz here, Font/Text engine makeover
proposal.


Howdy all, new programmer on the team here, and it seems my first job is =
to
improve our font/text engine's capabilities. Without further ado, here =
goes.

Current issues with the displaying of text:

Text functions are currently scattered within the XeOpenGLRenderer and
various other functions. Fonts are free-floating objects, with no =
current
management, which is not good as they are very resource-hungry. =
Font/Text
interaction has very limited flexability without being done by hand. =
Fonts
have few tools to make life easier, only width/height checking.

Solution:
Create XeTextRenderer, make it accessable through the XeOpenGLRenderer.
Encapsulate all text drawing functionality into the XeTextRenderer.
Encapsulate font management into the XeTextRenderer.

The XeTextRenderer will have the following capability:
	-Create, manage, and select fonts
	-Deal with rotation, vertical vs horizontal drawing.
	-Scale or style fonts/strings to fit inside restrictive boxes (So
the text fits in the button).
	-Draw text on a 2d surface.
	-Draw text in 3d, if necessary.
	-Be accessible through XeOpenGLRenderer.

Text drawing is extremely simple, and there should not be any problem
implementing the XeTextRenderer functions anywhere, as it will be a =
simple
call away from the renderer. The only issue will be obsoleting all the
previous functions.

The font memory management would probably best be done using a fairly =
simple
font handling technique. When you want a handle to a font, you tell the
TextRenderer to build it, and it will use a lazy-evaluation class (ala =
STL
strings, one copy, many references to it) to produce the font lists. =
There
will of course be a way to define a default text, if you just want to =
write
something and have it be the same as "everything else". The lists are =
the
big memory-hog anyway, so having the handles use the same lists, but
different 'other variables' (everything not defined when the font is
created, eg: verticality, color) should be fine.

The big 'issue' is that fonts are currently used in quite a few =
different
places in the code. I'll go ahead and keep everything backwards =
compatible
for now, because the only place that it is heavily used is in the
WinToolkit, which I hear is geared for a heavy makeover. I'll comment =
the
functions as being obsolete in the code that are remaining for backwards
compatibility.

I'll go ahead and wait till tomorrow to start drawing up the .h files, =
to
see if there are any concerns.


Ed Ray
--
Ed...@tu...
ICQ: 2271040


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including =
Data
Reports, E-commerce, Portals, and Forums are available now. Download =
today
and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
_______________________________________________
Xenocide-programming mailing list =
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
=20

[Xenocide-programming] Fritz here, Font/Text engine makeover proposal.

[Ed R. <Ed...@tu...>]

Howdy all, new programmer on the team here, and it seems my first job is to
improve our font/text engine's capabilities. Without further ado, here goes.

Current issues with the displaying of text:

Text functions are currently scattered within the XeOpenGLRenderer and
various other functions.
Fonts are free-floating objects, with no current management, which is not
good as they are very resource-hungry.
Font/Text interaction has very limited flexability without being done by hand.
Fonts have few tools to make life easier, only width/height checking.

Solution:
Create XeTextRenderer, make it accessable through the XeOpenGLRenderer.
Encapsulate all text drawing functionality into the XeTextRenderer.
Encapsulate font management into the XeTextRenderer.

The XeTextRenderer will have the following capability:
	-Create, manage, and select fonts
	-Deal with rotation, vertical vs horizontal drawing.
	-Scale or style fonts/strings to fit inside restrictive boxes (So the text
fits in the button).
	-Draw text on a 2d surface.
	-Draw text in 3d, if necessary.
	-Be accessible through XeOpenGLRenderer.

Text drawing is extremely simple, and there should not be any problem
implementing the XeTextRenderer functions anywhere, as it will be a simple
call away from the renderer. The only issue will be obsoleting all the
previous functions.

The font memory management would probably best be done using a fairly
simple font handling technique. When you want a handle to a font, you tell
the TextRenderer to build it, and it will use a lazy-evaluation class (ala
STL strings, one copy, many references to it) to produce the font lists.
There will of course be a way to define a default text, if you just want to
write something and have it be the same as "everything else". The lists are
the big memory-hog anyway, so having the handles use the same lists, but
different 'other variables' (everything not defined when the font is
created, eg: verticality, color) should be fine.

The big 'issue' is that fonts are currently used in quite a few different
places in the code. I'll go ahead and keep everything backwards compatible
for now, because the only place that it is heavily used is in the
WinToolkit, which I hear is geared for a heavy makeover. I'll comment the
functions as being obsolete in the code that are remaining for backwards
compatibility.

I'll go ahead and wait till tomorrow to start drawing up the .h files, to
see if there are any concerns.


Ed Ray
--
Ed...@tu...
ICQ: 2271040

RE: [Xenocide-programming] always PAQ

[mamutas <ma...@pr...>]

I think that we should still put the code in CVS. That is a reliable =
storage
available to masses. If the code is compilable, does not crash and =
provide
necessary functionality, it should be put in CVS.

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Ermete Gaudenzi
Sent: Saturday, July 19, 2003 5:01 PM
To: xen...@li...
Subject: Re: [Xenocide-programming] always PAQ


Hi to all again.

I've finished the PAQ Manager implementation. YEP!
Now I'm going to review the code, optimize it, comment it better and so =
on..
Today I finally finished the developers table manager and I improved the
speed in the addFile methods.
I changed the insertion algorithm from -append to the end then sort all-
into -binary search the right place and insert there-.
The code is a bit more difficult to understand but the speed is really
better !!
I tried to add the entire filenames of my hard disk into the archive =
with
full path (of course without the real file data). There was 19079 =
files...
whoops
Elapsed time: 32927 milli-seconds
I'm impressed... and I run the test in debug mode... let's try in =
release
speed-optimized mode...
Elapsed time: 24466 milli-seconds
Even better !!! It's near the 1-file-per-millisecond limit :-))
This of course adding the file data (1byte), file descriptor and =
filename.

Future issues are:
- more comments and cleaner code
- improve the error handling (currently it's poor)
- make it a library instead of a class (ouch... I can't do this for now
since I don't have the BCB)
- writing a test utility (the one I used is not serious)
- writing a command-line utility (really needed?)
- writing the PAQ Explorer. I never worked with GUI so I may not be the
right person doing it

I suggest to do not put this code in the CVS yet, it's better to wait =
until
at least the error handling has become serious.
I updated the task in sourceforge, incremented % complete to 70%
In the attached code I included the test utility... just for who is =
curious.
Anyway that is really a mess, so be careful to don't gain a head ach =
reading
it !!

Critics and comments are *ALWAYS* wellcome.

regards
exio82=20


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003





---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
=20

Re: [Xenocide-programming] always PAQ

[<fl...@ma...>]

Dont worry about optimizing it too much, I am more interested to make =
sure it works how it is supposed to work. And move to another task, we =
can always profile and optimize later... 1% of the code gets you 99% of =
the bang. The other important stuff to consider is code readability, I =
didnt have much problem to understand it, however there are still some =
deviations from the coding standard that you had followed almost =
flawlessly in this version of the code...

The use of the { in an improper place like in the virtual file like this

 switch (startingPoint){

 // If invalid value, assume default and continue
 default:
  advAssert(0,"Unknown starting point. _STINITIALPOSITION assumed");
};

It should be like this:

switch (startingPoint)
{

 // If invalid value, assume default and continue
 default:
    {
       advAssert(0,"Unknown starting point. _STINITIALPOSITION =
assumed");
    }
};

By the way try not to use the switch continuation unless you really need =
to, the semantics of that structure is pretty difficult to follow for =
non seasoned C++ programmers. And it is easy to overlook its =
implications when debugging.

Ex:

switch (pepe)
{
case 1:
    { pepe--; };
case 2:=20
    {
        pepe++;=20
        break;
    };
};

I had saw too some unneeded uses of the continue keyword at the =
paqdeveloperstable.cpp file..
Ex:
 // Binary search
 while(max >=3D min)
 {
  mid=3Dmin + (max-min)/2;

  if ( mid->filenameHash =3D=3D crcNumber )
  {
   this->namesList.erase(mid);
   return;
  }
  else if (mid->filenameHash > crcNumber)
   { max =3D mid-1; continue; } // sx
  else=20
   { min =3D mid+1; continue; } // dx
 }

It should be:

 // Binary search
 while(max >=3D min)
 {
  mid=3Dmin + (max-min)/2;

  if ( mid->filenameHash =3D=3D crcNumber )
  {
   this->namesList.erase(mid);
   return;
  }
  else if (mid->filenameHash > crcNumber)
   { max =3D mid-1; } // sx
  else=20
   { min =3D mid+1; } // dx
 }

As stated above try to avoid using that kind of dynamic semantic rules =
(they are hidden gotos) that make pretty difficult the readability of =
the code... Read this as: "If there is another way to do it (more =
clearly) use it, if not we will have to live with that".

About the library stuff, dont worry I will do that personally. And no, =
we dont need a command line utility, that is what PAQ Explorer is for. =
About the PAQ Explorer if anyone reading this mail wants to take that =
task, you are welcome to raise your hand... By the way if you never used =
VCL it is not difficult at all (promise), in fact it is the easies way =
arround any GUI related programming problem, if you have a GUI to do in =
C++ consider use Borland to do that. It is amazing what it can do, by =
the way if you already know Delphi, it is the same library :D=20

Greetings
Red Knight
  ----- Original Message -----=20
  From: Ermete Gaudenzi=20
  To: xen...@li...=20
  Sent: Saturday, July 19, 2003 7:01 PM
  Subject: Re: [Xenocide-programming] always PAQ


  Hi to all again.

  I've finished the PAQ Manager implementation. YEP!
  Now I'm going to review the code, optimize it, comment it better and =
so on..
  Today I finally finished the developers table manager and I improved =
the speed in the addFile methods.
  I changed the insertion algorithm from -append to the end then sort =
all- into -binary search the right place and insert there-.
  The code is a bit more difficult to understand but the speed is really =
better !!
  I tried to add the entire filenames of my hard disk into the archive =
with full path (of course without the real file data). There was 19079 =
files... whoops
  Elapsed time: 32927 milli-seconds
  I'm impressed... and I run the test in debug mode... let's try in =
release speed-optimized mode...
  Elapsed time: 24466 milli-seconds
  Even better !!! It's near the 1-file-per-millisecond limit :-))
  This of course adding the file data (1byte), file descriptor and =
filename.

  Future issues are:
  - more comments and cleaner code
  - improve the error handling (currently it's poor)
  - make it a library instead of a class (ouch... I can't do this for =
now since I don't have the BCB)
  - writing a test utility (the one I used is not serious)
  - writing a command-line utility (really needed?)
  - writing the PAQ Explorer. I never worked with GUI so I may not be =
the right person doing it

  I suggest to do not put this code in the CVS yet, it's better to wait =
until at least the error handling has become serious.
  I updated the task in sourceforge, incremented % complete to 70%
  In the attached code I included the test utility... just for who is =
curious. Anyway that is really a mess, so be careful to don't gain a =
head ach reading it !!

  Critics and comments are *ALWAYS* wellcome.

  regards
  exio82=20


-------------------------------------------------------------------------=
-----

Re: [Xenocide-programming] always PAQ

[Ermete G. <ex...@li...>]

I made a new benchmark with random seek position and read.
The archive was composed of 100 files of 1Mb size, filled with 
insignificant data.
These are the results.

Benchmark: "10000 times: reading exactly 10Kb from a random file at a 
random position"
Elapsed time: 7571 milli-seconds
- This one was done after few time elapsed from the archive creation. The 
OS may had some data in its cache

Benchmark: "10000 times: reading at max 10Kb from a random file at a random 
position"
Elapsed time: 9123 milli-seconds
- This one is done after lots of time the archive was created.
- Note: I observed that the reading process is pretty slow in the beginning 
1000-2000 tries..
then it becomes very quick

I completed the defragmentation process too... now the only thing missing 
is the developers table.

Implementation notes:
For now, the PAQSolidFile does NOT keep track of the opened files. Once a 
file is opened, it is forgotten until it asks for a manipulator. If we want 
a secure library I think we must keep track of opened files and close them 
when we call the lockSolidFile. (remember that if we add a file after 
another one is opened, the first one may become corrupted = crash or 
corrupted data)
But the game engine does not mind of changing a PAQ file, so the "lock" and 
"release" functions are never called. So we can ignore this if we want 
"pure speed".

I've attached the source zip containing all the code, except the test utility.
Anyway, how can I istantiate the first PAQManager class? I've not 
understood it yet... I have the static member, then?
In my tests I changed the constructor from protected to public to make the 
things work.

I'll update the task in sourceforge as soon as I become a "project developer".

Regards
exio82

Re: [Xenocide-programming] always PAQ

[Federico A. L. <fl...@ma...>]

> Hi guys,

> The SolidFile class has been temporary modified to accept CRC insteadof 
> String filenames. (With the strings the thing is pretty slower).
I dont have the code here, but the SolidFile is supposed to be supporting 
opening VirtualFiles by Strings and CRC alike. 

> The bad point is the speed of the addFile method, which can be improved.
> We can change the "append to table then sort" algorithm into something 
> quicker, like a mergesort. So we don't need the heavy reordering of the 
> entire table.
Dont worry too much about the addFile it will be used offline so the ones that 
have to be lighting fast are open-read-seek-close... open-read-close looks 
like they are lighting fast, try doing some random seek to see how much it 
takes.

> My implementation for now does not support the developers table, the 
> solidFileManipulator buffering (I discovered that the stdlib files have an 
> internal buffer too.. so we can avoid to build a second buffer) and the 
> defragmentation.
Better if you are using the stdlib internal buffer.

> Soon I'll release the entire packet.
Looking forward for it.

> Benchmark: "lock-release PAQSolidFile, 100 times"
> Elapsed time: 490 milli-seconds

> Benchmark: "add 5000 files (1byte length) with different crc numbers"
> Elapsed time: 2073 milli-seconds

> Benchmark: "deleting the 5000 previous created files"
> Elapsed time: 581 milli-seconds
Dont worry about the time it takes on these.


> Benchmark: "opening 1000 different files"
> Elapsed time: 10 milli-seconds

> Benchmark: "reading 1byte from every previous opened file"
> Elapsed time: 20 milli-seconds

> Benchmark: "closing the 1000 previous opened files"
> Elapsed time: 0 milli-seconds

These are the important ones. And pretty good figures I must say. Good job, as 
a suggestion try to use random accesses and random size reads, so you can 
check for more or less real time conditions.

Greetings
Red Knight

[Xenocide-programming] always PAQ

[Ermete G. <ex...@li...>]

Hi guys,
I'm near to finish a first implementation of the library. With my work done 
so far I've done a benchmark test. The code was compiled with the speed 
optimization of MS-VC++6.

The SolidFile class has been temporary modified to accept CRC insteadof 
String filenames. (With the strings the thing is pretty slower).
The bad point is the speed of the addFile method, which can be improved.
We can change the "append to table then sort" algorithm into something 
quicker, like a mergesort. So we don't need the heavy reordering of the 
entire table.

My implementation for now does not support the developers table, the 
solidFileManipulator buffering (I discovered that the stdlib files have an 
internal buffer too.. so we can avoid to build a second buffer) and the 
defragmentation.
Soon I'll release the entire packet.

Here's the results of the benchmark

Starting archive has 0 files

Benchmark: "lock-release PAQSolidFile, 100 times"
Elapsed time: 490 milli-seconds

Benchmark: "add 5000 files (1byte length) with different crc numbers"
00005000
Elapsed time: 2073 milli-seconds

Benchmark: "opening 1000 different files"
00001000
Elapsed time: 10 milli-seconds

Benchmark: "reading 1byte from every previous opened file"
00001000
Elapsed time: 20 milli-seconds

Benchmark: "closing the 1000 previous opened files"
00001000
Elapsed time: 0 milli-seconds

Benchmark: "deleting the 5000 previous created files"
00005000
Elapsed time: 581 milli-seconds

Ending archive has 0 files
Press any key to continue
Windows error: any key not found.

Re: [Xenocide-programming] PAQ Files latest corrections

[Federico A. L. <fl...@ma...>]

> - add:
> PAQSolidFileManipulator::setEndOfFile to change file size (trunc 
> 
> useless data to do not waste space)
> 
> This was intented to be used only by the .FAT manager to truncate the
> file if the size of the new saved one is smaller than before. But this
> can be ignored till we do the defragmentation... so ok this function if
> useless ^_^

> I've not understood why the use of the pair is forbidden... what are
> public attributes?
Public attributes are public variables like the one that you are using in the 
pair from the STL. Not in your code, but I prefer do not let anyone use that to 
be consistent. If you want you can make a new pair template with a 
setFirstArgument and getFirstArgument, and the same for the second one.

> I think I have made a mistake posting the .cpp files so early. The code
> is pretty young, it is intended only to show a sort of work-flow of the
> functions, to clearify what they do.
Dont worry about it, better to make that now, after the design is more or less 
polished, dont get discourage you will have to change lots of things now, what 
it sounded fine when designing wont look that good when implementing, but that 
happens all the time... So you would ask why to design the headers first, 
because you setup the working policy and phylosophy doing that, so you end up 
with a better system when implementing. In short you design the most deseable 
and implement something a little worse, but that is just the way of the world. 

> I personally think the second code if more clear, expecially with the
> searching. But a person who doesn't know STL may find it difficult to
> understand. Tell me what you think about it.

Dont be so sure, cause inside you are using a for but when you read the code 
you are not aware of the control flow. The design should be the best you can 
do, and the implementation the most readable and self explaining that you can. 
If you have a loop control flow you need to see it to know that what you are 
doing is right, besides you dont need an extra knowledge (Know STL by heart, in 
fact i just use the vector and string class cause they are very well designed 
not the rest, cause some parts of it are very dificult to understand).

> I'd like to say something on the networklib... but I had a quick read at
> the headers and I found nothing missing :-)

Dont be afraid, I make mistakes too and I can bet that I commited lots, in fact 
the actual one (not posted yet) had changed a lot to make it easier to code and 
understand... We had missed in some points, so we went an step backwards and 
revised all the work and found better ways to do some things, so the new one 
will have some new things (and documentation)...

Greetings
Red Knight

Re: [Xenocide-programming] PAQ Files latest corrections

[Ermete G. <ex...@li...>]

<html>
<blockquote type=cite class=cite cite>- add:
PAQSolidFileManipulator::setEndOfFile to change file size (trunc <br>
useless data to do not waste space)</blockquote><br>
This was intented to be used only by the .FAT manager to truncate the
file if the size of the new saved one is smaller than before. But this
can be ignored till we do the defragmentation... so ok this function if
useless ^_^<br><br>
I've not understood why the use of the pair is forbidden... what are
public attributes?<br>
The variables are set to private, which are not visible in derived
classes too..<br><br>
I think I have made a mistake posting the .cpp files so early. The code
is pretty young, it is intended only to show a sort of work-flow of the
functions, to clearify what they do.<br>
Later in development I'll revise all the code and I am intentioned to try
to remove the for() cycles for searching etc. and replace them with the
STL templates, if this will be enough clear in the code. For 
example<br>
<b>Before:<br>
</b><i><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>UInt32
size;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>size =
this-&gt;freeSolidFileManipulators.size();<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>for(Index
i=0;i&lt;size;i++)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>delete
this-&gt;freeSolidFileManipulators[i];<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>this-&gt;freeSolidFileManipulators.clear();<br>
</i><b>After:<br>
</b><i><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>vector&lt;PAQSolidFileManipulator
*&gt;::iterator begin,end;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>begin =
this-&gt;freeSolidFileManipulators.begin();<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>end =
this-&gt;freeSolidFileManipulators.end();<br>
</i><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><i>std::for_each(begin,end,deleteSolidManipulator());<br><br>
</i>The disadvantage is that I have to write additional things to make it
work. In the previous example I must add too:<br>
<i><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>struct
deleteSolidManipulator : public
std::unary_function&lt;PAQSolidFileManipulator *,void&gt;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>{<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>deleteSolidManipulator::result_type
operator()(deleteSolidManipulator::argument_type x) { delete x; };<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>};<br>
</i>I personally think the second code if more clear, expecially with the
searching. But a person who doesn't know STL may find it difficult to
understand. Tell me what you think about it.<br><br>
Anyway, the modifications you posted has been applied.<br>
Thanks<br><br>
I'd like to say something on the networklib... but I had a quick read at
the headers and I found nothing missing :-)<br><br>
Exio82<br>
</html>

[Xenocide-programming] PAQ Files latest corrections

[Federico A. L. <fl...@ma...>]

These are the most relevant corrections up to now.

//////////////////////////////////////  

[7 july 2003]

- add: PAQSolidFileManipulator::setEndOfFile to change file size (trunc 
useless data to do not waste space)


This method is not suitable for read only. In addition, if you want to use 
something like this in write mode (i.e. for the PAQ Explorer), you should use 
the defrag.


//////////////////////////////////////


//////////////////////////////////////
In paqmanager.cpp

PAQSolidFile * PAQManager::openPAQFile(std::string filename)
{
	PAQSolidFile *newSolidFile;
	std::string tempFilename;
	
	register UInt32 vectorSize = this.solidFileList.size();

	// is more readable than your code
	for (Index i = 0; i < vectorSize; i++)
	{
		if (filename.compare (this.solidFileList[i]->getFilename()) == 
0)
		{
			// the second parameter must be incremented! (you have 
modified
			// it on the closePAQFile, but not here)
			this->solidFileList[i].second++;
			return (PAQSolidFile*)(this.solidFileList[i]);
		};
		
			
	};
	// creates new file and add to internal list
	newSolidFile = new PAQSolidFile(filename);
	this->solidFileList.push_back( InternalSolidFileDescriptor
(newSolidFile,1) );

	return newSolidFile;
};

Anyway, the pair object is not the best solution because it uses public 
attributes, something we forbid explicitly. Because public attributes can be 
changed without any control from the holder class, posibly introducing serious 
defects on the software.

//////////////////////////////////////


Note 1: when you begin a new block of code, the "{" must be on the next line.
For example:

for (;;)
{
};

instead of

for (;;){
};

note 2: another issue is the naming of the enum. It should be "enum 
FILEACCESS" instead of "enum PAQFILEACCESS"


Greetings
Red Knight and Papo

[Xenocide-programming] PAQ Management update

[Ermete G. <ex...@li...>]

#include <utility/qa.h>
#include <paqmanager.h>



PAQManager::PAQManager()
{
}


PAQManager::~PAQManager()
{
}


//! This is intended to save a small amount of .PAQ files (less than 10 for example)
//! so the code is far from being optimized
PAQSolidFile * PAQManager::openPAQFile(std::string filename)
{
	PAQSolidFile *newSolidFile;
	std::string tempFilename;

	// Search list of already opened files
	InternalSolidFileVector::iterator it;
	for(it = this->solidFileList.begin(); it<this->solidFileList.end(); it++){
		it->first->getFilename(tempFilename);
		if (tempFilename == filename)
			return (PAQSolidFile*)(it->first);
	}

	// creates new file and add to internal list
	newSolidFile = new PAQSolidFile(filename);
	this->solidFileList.push_back( InternalSolidFileDescriptor(newSolidFile,1) );

	return newSolidFile;
}


void PAQManager::closePAQFile(PAQSolidFile *solidFile)
{
	std::string tempFilename,solidFilename;
	solidFile->getFilename(solidFilename);

	// Search internal list
	InternalSolidFileVector::iterator it;
	for(it = this->solidFileList.begin(); it<this->solidFileList.end(); it++)
	{
		it->first->getFilename(tempFilename);

		// If file was already opened, decrement opencounter
		if (tempFilename == solidFilename)
		{
			it->second--;

			if (it->second > 0)
				return;
		}
	}

	delete solidFile;
}

[Xenocide-programming] RK new design

[Ermete G. <ex...@li...>]

Hi red, I'm sorry your review on my code took 4 hours of your time !!
As you said, you took an hard look on it.
I've just viewed your new design, I'll do my best. It's the first time for 
me working in team, today I learned a big lesson on how different ideas can 
be, inside two different brains. Definitely they are the same but... 
different. :huh:

Coming back to work, I have some things to say.
I agree with you that the names I used for classes were not completely 
clear; we can also rename PAQFile into PAQVirtualFile to finally resolve 
the confusion.
Then, PAQFile::onInvalidateFileManipulator() is noted "called from 
PAQFile", you ment PAQSolidFile?

The idea of using a PAQSolidFileManipulator is very good!! However I have 
not clear how the PAQSolidFile::lockFile() will work. Will it remove all 
manipulators and build only one manipulator write-enabled? Or will it 
destroy every PAQFile object previously created without notify the application?

Anyway, I suggest the manipulator class to be derived from IIAbstractFile
[CODE]
class PAQSolidFileManipulator : public IIAbstractFile
{
protected:
   PAQSolidFileManipulator ();
   virtual ~PAQSolidFileManipulator();
private:
   FILE *solidFileHandle;
};
[/CODE]

I'll post it on the list too..

regards
exio82

[Xenocide-programming] PAQ Files Management

[Federico A. L. <fl...@ma...>]

Hi Exio, what I promise is debt. I took a hard look on your design, it has 
improved a lot. However we rewrote the whole stuff based on your initial 
design. It was a 4 hours design effort and we think it is a good start, the 
idea was define the Services that the objects whould give you, however 
everybody make mistakes so if you find anything when implementing let me know.

Your design had some quirks, like for example you cannot handle multiple open 
files without having one file handler for each file (you you still do the fopen 
for each file, so we dont win anything from the PAQ File), we had added a proxy 
object called PAQFileSolidManipulator that would encapsulate that very same 
file handler. Another thing was some class names, it was pretty difficult to 
understand because name overloading for example PAQFile (what it is? A .PAQ 
File or a File inside the PAQ), seeing that we added the notion of a SolidFile 
(that is the .PAQ File). 

We went further on the Files, we added an Interface IIAbstractFile, but it wont 
be included in the PAQ File, it will be included in another package. The idea 
is in some time (when we need them) implement memory mapped files and other 
derived classes from it.

Another important thing was that we do not permit access to the user for the 
things that only the PAQ Manager have access to. In fact the user (developer) 
only have a View, it wont have the complete command set available to be used. 
We used a friend class for that, if you know of a better way to improve that, 
let me know cause it is pretty useful (if only C++ had Selective Export like 
Eiffel).

One far less important issue was misplaced use of the virtual keywork on some 
methods, but nothing to worry about YET.

The headers we are sending are not complete in implementation details, we 
though that you could handle that better so we add as less as we could (for 
example we didnt define the class PAQFileDescriptor and left deliveratly 
incomplete the IIAbstractFile and PAQFile classes). The same for attributes 
inside the classes. We tried to document everything so you wouldnt have a hard 
time reading it. Dont worry mamutas the docs from the Network Lib are on the 
way :D ...

Nice work overall, you will learn our style and write the things right from the 
start that just only requires practice. Now that you are going to start to 
implement it, try to give as much feedback as you can about your progress. The 
same if you find problems in the definition of some services, in short just 
drop an email and we will try to resolve the issue.

Greetings
Red Knight

RE: [Xenocide-programming] PAQ File manager

[mamutas <mam...@ho...>]

Hi there,

Here are my comments.

1) I really liked that doxygen documentation was used. This is something
that we all must do.
2) All enums should have names (second in paqfiles.h does not have it).
Also, enum constants should have prefixes as suggested by RK.
3) String should be used whereever information is a text, for example,
fileName in paqfile.h.
4) 	//! Current file pointer
	Char *ptr;
And all other pointers to file data should not use Char*, but Int8*. =
This is
mostly for clarity.
5) Several method names in PAQFileAllocationTable class are confusing, =
for
example:
	nameResolutionAddFilename(Char *filename);
	nameResolutionRemoveFilename(Char *filename);
	nameResolutionRemoveFilename(UInt32 filenameHash);
Method name must start with a verb to indicate an action.
6) Char *nameResolutionStringArray; in PAQFileAllocationTable class =
should
have the type of array or something, but not char*.
7) filename in PAQFilenameResolutionDescriptor class should be a string, =
not
char*.
8) I did not understand the function the isFileUpdated method in
paqmanager.h file will be performing. What update is it checking?
9) Bool should be used instead of bool.

In general, it really looks allright. As you have noticed I had very few
comments on the method functionality.

I guess you will also provide an executable to work with the PAQ file as
well as used switches and options.

Regards,
mamutas

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003
=20