I'll be gone for a few (more) days. I have just gotten done with finals,
and now the parents want me to help finish their house, so don't expect me
till at least sometime next week.
Ed Ray
--
Ed@...
ICQ: 2271040

Hi everyone. I've just finished version 0.01 of a linux devpack. It
weighs in at a slender 2.2K, however I had to make 15K's worth of
patches to get things to compile :-) It's up at
http://james.is.never.wrong.nu/xenocide/ - installation notes are at the
bottom of this mail.
Just off the top of my head, here are some things that I changed:
Unix #define symbol. Traditionally, it's unix, or _unix, or __unix -
_USE_POSIX means something else. I've opted for "unix", because I think
it looks cute.
Changed stuff like "thirdparty/opengl/gl.h" to <GL/gl.h>
Removed all the uses of the Index type. I think that comparing different
types is going to *really* trip us up in the future, even if they happen
to be the same size right now.
Made a common/posix/common.cpp and added itoa() to it. (Yes, unix
traditionally doesn't have itoa().)
Fixed a couple of friend declarations that were just completely wrong. I
have no idea how they ever got into the repository unless the Borland
compiler is really lax :-/
Here are some things that I haven't done:
Made an alternative to xenoengine/kernel/win32.
Got any of the xenoengine examples to build. (The utility ones build
fine.)
I think both of these are OK as we're now pretty much using the same
shared codebase. With respect to xenoengine/kernel/<platform>, I was
wondering if I should implement xenoengine/kernel/sdl rather than
xenoengine/kernel/linux. That way someone could test the windows version
of that and the windows version could be quietly dropped when the sdl
version was mature enough.
You need (at the very least) autoconf and automake to make this work. I
used version 1.7 of automake and 2.53 ( I think ) of autoconf.
How to install - grab the latest version from cvs into the directory
xenocide. Put both the zipfiles there, and unpack them both. Run `patch
-p1 < ./linux-compile.patch` - this will patch your source tree so that
it can compile under linux. Then go into working, and run `sh import.sh
../` - this will set up a directory structure that's much more
unix-friendly. Then run `aclocal && autoconf && automake` - you'll get a
bunch of errors about files missing. All the ones in uppercase you can
just create (`touch NEWS`, for example), all the ones in lowercase you
should copy out of your auto{conf,make} data directory - usually
/usr/share/automake-VERSION/. Try `aclocal && autoconf && automake`, fix
until it doesn't whinge. Then do ./configure && make - hopefully you
should build most of the source tree. Hoorah!
If you do try this, please, please, PLEASE email me and tell me if you
got it to work and what distribution/version you're using, and
especially if you didn't get it to work so I can fix it for you. After
I've had a few hours of feedback I'll put a post up on the forums, until
then I'd prefer to keep it semi-quiet so that I don't get 2000 identical
bug reports at the same time. :-)
Now I can get to work on the model loading :-)
james.
P.S. I don't know if this still applies, but is there any chance of
someone making me a member of this mailinglist? I joined, but I think I
need to be added by a moderator.
--
When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. - Jonathan Swift

On Tue, Aug 12, 2003 at 10:05:04PM -0500, mamutas wrote:
> I got a feeling that James has answered Red Knight's questions, but the
> answers did not make to the mailing list. So, I will try to answer
> them and James will correct me if I am wrong, ok?
*ahem* :-) Sorry, my bad. I've resent it.
> 1) Type checking in XML could be enforced via using of XML schemas
> instead of DTDs. But I guess that was not meant for 'country-namegroup' link.
> This issue could be resolved by using references to an element.
> 4) Namespaces could be specified in the DTD or XML header (or again,
> in XML schemas).
It can be done with DTD's. The problem is that I didn't want to alter
the XML *too* much, which precludes strict enough type-checking. But
yes, in general Schemas are a powerful alternative to DTD's.
Namespaces should be specified in the top-level element you want them to
apply to - in this case, the root element.
> That is what I remember so far without digging through my memory since
> it was about 2 years I worked with XML.
>
> In my understanding, if we are going to use proper XML for our
> datafiles, then we should pick up some open source XML parser. I do not have
> preferences whether it will DOM or SAX so far, it all depends on what
> memory management we are going to have for those DBs.
You're absolutely right. I've used QT's SAX2 implementation so far, but
as QT is problematic to use on Windows I'd suggest fixing on Xerxes -
http://xml.apache.org/#xerces.
> mamutas
james.

I am glad to see that we are on the same page. I have used Xerces (the Java
implementation, however) and I found it stable, powerful and straight
forward to use.
Regards,
Mamutas
-----Original Message-----
From: James Harlow [mailto:james@...]
Sent: Tuesday, August 12, 2003 10:33 PM
To: mamutas
Subject: Re: [Xenocide-programming] names.xml
On Tue, Aug 12, 2003 at 10:05:04PM -0500, mamutas wrote:
> I got a feeling that James has answered Red Knight's questions, but
> the answers did not make to the mailing list. So, I will try to answer
> them and James will correct me if I am wrong, ok?
Sorry, my bad. I've resent it.
> 1) Type checking in XML could be enforced via using of XML schemas
> instead of DTDs. But I guess that was not meant for
> 'country-namegroup' link. This issue could be resolved by using
> references to an element.
> 4) Namespaces could be specified in the DTD or XML header (or again, in
XML
> schemas).
It can be done with DTD's. The problem is that I didn't want to alter the
XML *too* much, which precludes strict enough type-checking. But yes, in
general Schemas are a powerful alternative to DTD's.
Namespaces should be specified in the top-level element you want them to
apply to - in this case, the root element.
> That is what I remember so far without digging through my memory since
> it was about 2 years I worked with XML.
>
> In my understanding, if we are going to use proper XML for our
> datafiles, then we should pick up some open source XML parser. I do
> not have preferences whether it will DOM or SAX so far, it all depends
> on what memory management we are going to have for those DBs.
You're absolutely right. I've used QT's SAX2 implementation so far, but as
QT is problematic to use on Windows I'd suggest fixing on Xerxes -
http://xml.apache.org/#xerces.
> mamutas
james.
---
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

redknight@... wrote:
>> Hi everyone. I'm going to be doing the modelling code, and while I
>> was getting to know the project, I thought I'd take the liberty of
>> cleaning up names.xml into proper xml with a DTD (document type
>> declaration) so it validates.
>>
>
> It was me who made it, and it was supposed to be XML like, not strict
> XML (cause I never had done it). The idea was having a simple database
> to store the names to be used in the random name generation, in a
> simple fashion. However, the changes are not dramatical and I think it
> [wouldn't] complicates too much the parsing (less if we can use a
> proper XML parser to do that)... So good job.
>
I should stress that I wasn't in any way criticising, I'm sure it was
just something that was just quickly laid out to get something "on
paper" - I do that all the time.
>> 1. Improve the type-checking in the DTD. Most of the data isn't
>> checked at all, and it could be - for example the <probability
>> group="country"> could be checked to make sure country was a country
>> that had been defined in <namegroups>.
>>
>
> And how you do that? Excuse my maybe lame questions, but Ive never
> done XML, DB and Bussiness applications are not my strong point...
>
Heh, me neither, XML is just something I picked up.
You could alter the DTD so that it specified that all of the values of
the attribute "origin" in the element "group" were unique. Then you
could specify that all the values of the attribute "group" of the
element "probability" referred to either these unique values or the
value "default". This isn't possible at the moment because we have more
than one <group origin="spanish"> and because the attribute "group" in
the element "probability" doesn't mean much.
>> 3. Write a tool so that designers don't have to edit the XML
>> manually. It's my opinion that the only people who ever see text
>> files should be programmers, everyone else should have tools.
>>
>
> Yes all agree on that, and the tools we are doing comes from that
> philosofy. For instance the PAQ Explorer and the repository are just 2
> of them...
>
Cool. I've finished my first pass of a reader - the source is at
http://james.is.never.wrong.nu/files/names-reader.tar.gz. It's just a
quick mockup, almost, you can't write to it, save, and it doesn't really
handle the <continents> element. It uses QT, which has a windows port -
get it from http://www.trolltech.com/download/qt/noncomm.html or
http://www.trolltech.com/forms/noncommevalform.html.
[update : lordt has done an excellent web frontend at
http://xenocide.ru/temp/names/ - see the forum thread
http://www.xcomufo.com/forums//index.php?showtopic=1929&st=0&#entry35415
for more info.]
>> 4. Add a namespace. All our XML should be put in our own namespace,
>> eventually.
>>
>
> Again, how?
>
<database xmlns="http://www.projectxenocide.com/names"&gt;
james.

Hi guys,
First, make sure when you reply the post it goes to
Xenocide-programming@... address.
I got a feeling that James has answered Red Knight's questions, but the
answers did not make to the mailing list. So, I will try to answer them =
and
James will correct me if I am wrong, ok?
1) Type checking in XML could be enforced via using of XML schemas =
instead
of DTDs. But I guess that was not meant for 'country-namegroup' link. =
This
issue could be resolved by using references to an element.
4) Namespaces could be specified in the DTD or XML header (or again, in =
XML
schemas).
That is what I remember so far without digging through my memory since =
it
was about 2 years I worked with XML.
In my understanding, if we are going to use proper XML for our =
datafiles,
then we should pick up some open source XML parser. I do not have
preferences whether it will DOM or SAX so far, it all depends on what =
memory
management we are going to have for those DBs.
Regards,
mamutas
-----Original Message-----
From: xenocide-programming-admin@...
[mailto:xenocide-programming-admin@...] On Behalf Of
redknight@...
Sent: Thursday, August 07, 2003 3:15 PM
To: James Harlow
Subject: Re: [Xenocide-programming] names.xml
Hi,
Quoting James Harlow <james@...>:
> Hi everyone. I'm going to be doing the modelling code, and while I was
> getting to know the project, I thought I'd take the liberty of =
cleaning=20
> up names.xml into proper xml with a DTD (document type declaration) so =
> it validates.
It was me who made it, and it was supposed to be XML like, not strict =
XML=20
(cause I never had done it). The idea was having a simple database to =
store=20
the names to be used in the random name generation, in a simple fashion. =
However, the changes are not dramatical and I think it would complicates =
too
much the parsing (less if we can use a proper XML parser to do that)... =
So=20
good job.
> 2. XML Comments. XML comments go like this: <!-- this is a comment=20
> -->.
> Technically they're a little more involved than this, but everyone I=20
> know thinks that using complex comments is a bad idea. C and C++=20
> comments are not valid.
Part of XML like desitions.
> 1. Improve the type-checking in the DTD. Most of the data isn't=20
> checked
> at all, and it could be - for example the <probability =
group=3D"country">=20
> could be checked to make sure country was a country that had been=20
> defined in <namegroups>.
And how you do that? Excuse my maybe lame questions, but Ive never done =
XML,
DB and Bussiness applications are not my strong point...
> 3. Write a tool so that designers don't have to edit the XML manually.
> It's my opinion that the only people who ever see text files should be =
> programmers, everyone else should have tools.
Yes all agree on that, and the tools we are doing comes from that =
philosofy.
For instance the PAQ Explorer and the repository are just 2 of them...
> 4. Add a namespace. All our XML should be put in our own namespace,=20
> eventually.
Again, how?
> 5. (And I'm an idiot for forgetting to do this) Put a version=20
> attribute
> in the <database> element.
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 =
Xenocide-programming@...
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

> >>Hi everyone. I'm going to be doing the modelling code, and while I was
> >>getting to know the project, I thought I'd take the liberty of cleaning
> >>up names.xml into proper xml with a DTD (document type declaration) so
> >>it validates.
> >It was me who made it, and it was supposed to be XML like, not strict XML
> >(cause I never had done it). The idea was having a simple database to store
> >the names to be used in the random name generation, in a simple fashion.
> >However, the changes are not dramatical and I think it would complicates too
> >much the parsing (less if we can use a proper XML parser to do that)... So
> >good job.
> >
> I should stress that I wasn't in any way criticising, I'm sure it was
> just something that was just quickly laid out to get something "on
> paper" - I do that all the time.
Dont worry it was supposed to say: "and I think it wouldNT complicates too
much the parsing", my mistake.
Greetings
Red Knight

Hi,
Quoting James Harlow <james@...>:
> Hi everyone. I'm going to be doing the modelling code, and while I was
> getting to know the project, I thought I'd take the liberty of cleaning
> up names.xml into proper xml with a DTD (document type declaration) so
> it validates.
It was me who made it, and it was supposed to be XML like, not strict XML
(cause I never had done it). The idea was having a simple database to store
the names to be used in the random name generation, in a simple fashion.
However, the changes are not dramatical and I think it would complicates too
much the parsing (less if we can use a proper XML parser to do that)... So
good job.
> 2. XML Comments. XML comments go like this: <!-- this is a comment -->.
> Technically they're a little more involved than this, but everyone I
> know thinks that using complex comments is a bad idea. C and C++
> comments are not valid.
Part of XML like desitions.
> 1. Improve the type-checking in the DTD. Most of the data isn't checked
> at all, and it could be - for example the <probability group="country">
> could be checked to make sure country was a country that had been
> defined in <namegroups>.
And how you do that? Excuse my maybe lame questions, but Ive never done XML,
DB and Bussiness applications are not my strong point...
> 3. Write a tool so that designers don't have to edit the XML manually.
> It's my opinion that the only people who ever see text files should be
> programmers, everyone else should have tools.
Yes all agree on that, and the tools we are doing comes from that philosofy.
For instance the PAQ Explorer and the repository are just 2 of them...
> 4. Add a namespace. All our XML should be put in our own namespace,
> eventually.
Again, how?
> 5. (And I'm an idiot for forgetting to do this) Put a version attribute
> in the <database> element.
Greetings
Red Knight

Hi everyone. I'm going to be doing the modelling code, and while I was
getting to know the project, I thought I'd take the liberty of cleaning
up names.xml into proper xml with a DTD (document type declaration) so
it validates. I uploaded it to the patches area (
http://sourceforge.net/tracker/index.php?func=detail&aid=784360&group_id=67048&atid=516699
) - partly because I don't have CVS access and partly because I don't
know the project well enough to make fairly major changes like that.
There are a few things I'd like to note:
1. XML is case- and whitespace-sensitive. The author of this file has
done a good job here, so they obviously know this. Nonetheless I think
it's worth pointing out in any introduction to XML, because most people
don't expect it to be either (I guess because html isn't).
2. XML Comments. XML comments go like this: <!-- this is a comment -->.
Technically they're a little more involved than this, but everyone I
know thinks that using complex comments is a bad idea. C and C++
comments are not valid.
3. Elements vs. Attributes. There are no hard and fast rules on when to
use attributes and when to use elements. (An element is a tag -
<element>, and an attribute is a key-value pair in the element -
<element key="value">.) I think it makes sense to use attributes over
elements only when the attribute is a fundamental property of the
element that is guaranteed to only have one value. For example, in an
email XML, the <to> structure would be a bad candidate for being an
attribute as you often want to send email to more than one person. On
the other hand, in a bottle of wine XML, the vintage would be a good
candidate: <wine vintage="1986">.
Here's a rundown of the things I changed to names.xml (roughly in order
of top to bottom):
1. Put a DTD in. All XML documents require a DTD - it serves roughly the
same purpose as a C/C++ header file.
2. Put a root element in. All XML documents require exactly one root
element. I decided to make this <database>, with an attribute type
called "type". This way we can write a tool that can operate on any of
our XML files, check what type they are, and display them appropritately.
3. Seperated the document out into two logical sections - a name
database and country rules. There didn't seem to me to be any reason to
define names inside continents. English names are English names,
wherever you are - if America uses different names, then they should be
called American names.
4. Removed the quantity attribute on group. I couldn't see any point for it.
Here are some things I'd like to do with names.xml, but didn't:
1. Improve the type-checking in the DTD. Most of the data isn't checked
at all, and it could be - for example the <probability group="country">
could be checked to make sure country was a country that had been
defined in <namegroups>.
2. Change the probability structures. At the moment they're very
difficult to parse. However as the document is just a place to put names
and there are no tools that use it, this wasn't necessary.
3. Write a tool so that designers don't have to edit the XML manually.
It's my opinion that the only people who ever see text files should be
programmers, everyone else should have tools.
4. Add a namespace. All our XML should be put in our own namespace,
eventually.
5. (And I'm an idiot for forgetting to do this) Put a version attribute
in the <database> element.
If you're interested in learning more about XML and DTD's and so forth,
there are good tutorials at http://www.w3schools.com. The parser I used to
check names.xml is at http://www.stg.brown.edu/service/xmlvalid/.
james.

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: xenocide-programming-admin@...
[mailto:xenocide-programming-admin@...] On Behalf Of =
Ed
Ray
Sent: Sunday, August 03, 2003 11:58 PM
To: xenocide-programming@...
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: xenocide-programming-admin@...
>[mailto:xenocide-programming-admin@...] On Behalf Of=20
>Federico Andr=E9s Lois
>Sent: Sunday, August 03, 2003 5:40 PM
>To: xenocide-programming@...
>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
>Xenocide-programming@...
>https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
Ed Ray
--
Ed@...
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 =
Xenocide-programming@...
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

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: xenocide-programming-admin@...
>[mailto:xenocide-programming-admin@...] On Behalf Of
>Federico Andr=E9s Lois
>Sent: Sunday, August 03, 2003 5:40 PM
>To: xenocide-programming@...
>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
>Xenocide-programming@...
>https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
Ed Ray
--
Ed@...
ICQ: 2271040

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: xenocide-programming-admin@...
[mailto:xenocide-programming-admin@...] On Behalf Of
Federico Andr=E9s Lois
Sent: Sunday, August 03, 2003 5:40 PM
To: xenocide-programming@...
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

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" <mamutas@...>
To: <xenocide-programming@...>
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
> Xenocide-programming@...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
>

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

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: xenocide-programming-admin@...
[mailto:xenocide-programming-admin@...] On Behalf Of
Federico Andr=E9s Lois
Sent: Tuesday, July 29, 2003 12:45 PM
To: xenocide-programming@...
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

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
>Xenocide-programming@...
>https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
Ed Ray
--
Ed@...
ICQ: 2271040

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

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.