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.

[<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
>
>

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.

[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...>]

I am glad to hear that you are busy with Xenocide coding and that you =
are
doing progress. Keep it going!

As for the style question, I would treat static const variable same as
defines, so I would use define style to name it, that is _DEFAULT.

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of =
Ed
Ray
Sent: Sunday, August 03, 2003 11:58 PM
To: xen...@li...
Subject: RE: [Xenocide-programming] Fritz here, Font/Text renderer =
header
files.


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=20
>winner in such argument.
>
>As for performance issues, I agree with what is said below. It is not=20
>something I did not hear before. And it makes sense. I just thought=20
>that such issues must be taken care of by compiler, but I guess we=20
>cannot count that all compilers do that.
>
>As an afterthought about such discussion, I guess we need to come up=20
>with some basic rules for code optimization which every programmer must =

>follow. We could have a FAQ or something on Sourceforge. What do you=20
>say?
>
>-----Original Message-----
>From: xen...@li...
>[mailto:xen...@li...] On Behalf Of=20
>Federico Andr=E9s Lois
>Sent: Sunday, August 03, 2003 5:40 PM
>To: xen...@li...
>Subject: Re: [Xenocide-programming] Fritz here, Font/Text renderer=20
>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=20
>conventions you can see that in the second case 2 * _PI is a constant=20
>that will be precalculated by the compiler. In the first one, you can=20
>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=20
>you can diferenciate them in code via names, you are making a more=20
>readable code... Now you can argue that we can use a naming convention=20
>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=20
>compiled code looks like this:
>
>(I will take some poetic license here creating a special symbolic=20
>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,=20
>however, because C++ have to support separate compilation if the=20
>constant you are using is defined and initialized in another file=20
>(module) then the compiler cannot know the real value (even though it=20
>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=20
>of vectors or matrices, where all identity ones are already defined as=20
>the latest kind of constants (because of a performance issue that I=20
>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=20
>miscColorBlack, miscColorRed and so on... now you have created n=20
>objects codifing colors. You can use defines too, suppose you want to=20
>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.=20
>The scope of MiscRGBAColor is validated by the inclusion of an include=20
>statement, and the #define is not, because that is a precompiler=20
>macro... so that can create some difficult to diagnose compilation=20
>problems. So appart from the performance issues, there is some other=20
>problems that have to be addressed...
>
>Now, when to use defines and when to use const values? Easy, you have=20
>to use defines when the type of the expression you used can be known by =

>the compiler on compilation like characters, strings, integers, real=20
>numbers, etc.... You cant use them with user defined objects, so for=20
>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=20
>Data Reports, E-commerce, Portals, and Forums are available now.=20
>Download today and enter to win an XBOX or Visual Studio .NET.=20
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_0
>1/01
>_______________________________________________
>Xenocide-programming mailing list
>Xen...@li...
>https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>

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