How are you? Let us get down to business.
http://www.djmania.com.hr/pilspharmnew1029361.php?nugaolID=52

             Sun, 1 Jan 2012 6:34:46
__________________
"To his surprise their injuries proved to be only skin deep.I was in the ticket
office when I heard the shriek and ran out in time to see the train hands
carrying the two boys to the platform." (c) Kymberly vso3ug9z

Hi,

I'm trying to understand the FCW file format, and I'm using the existing FCW to
SVG source code (from the attachments area) as a base.  Sadly, it's making me
very confused, and I was hoping that clear things up for me.

I get the overall structure of the code -- my question is a really nitty-gritty.

When I process each block in the source, I'm able to see the size and type of
each block.  For example, a type 6 block seems to map to a basic circle (the
structure of which is defined in the header.h file).  The common header of each
block takes about 28 bytes.  In addition to the common header, there are three
float values, indicating the x, y, and radius of the circle.

The part that confuses me is that when I try to run this code against some FCW
maps, the circle blocks are consistently identifying themselves as 36 byte
blocks, whereas the struct seems to be defining a 40-bytes construct.

Am I somehow miscounting this?  (I've done all the obvious things, I think --
I've sizeof'ed Cir2 and double-checked the logic in the file.

Is this just something that never worked correctly in the original code?  Or was
the code written against a version of the file format that's no longer valid?

Any help would be appreciated.

BC

--- In cc2-dev-l@yahoogroups.com, Joseph Slayton <waldronate@...> wrote:
>
> Make sure that your compiler is honoring the #pragma pack() that
> defines the structure packing. Also make sure that it's not padding
> the structure to the next packing boundary (for example, natural
> packing for Pentium Pro and later processors is 8-byte or 16-byte
> cache lines; some compilers will pack a 36-byte structure to 40
> bytes to force 8-byte alignment in some cases).


Thanks for the reply!

I actually figured out my problem: the format appears to have changed.  The file
I was working with was an old version (the dbVer in the fileId was '21'),
whereas the same block type (6) in version '24' is the correct 40 bytes long.

I have another question: the existing code doesn't support from block types. 
I've noticed type 5 (which appears to be the type for text labels) and type 0x81
(metadata?).  Does anyone know the structure for these types?

BC

> I have another question: the existing code doesn't support [for
> some] block types.  I've noticed type 5 (which appears to be the
> type for text labels) and type 0x81 (metadata?).  Does anyone
> know the structure for these types?

I've looked into "reverse engineering" the format for the text labels, and
figured out this much:

0x00 - 0x1B : standard block header
0x1C - 0x1D : ??
0x1E - 0x25 : Coordinate
0x26 - 0x3A : ??
0x3B - varies : null-terminated String text

I'm sure I can figure out the reference to font id and font size.

Supporting text introduces a new weirdness, however.  CC3's coordinate system is
different from SVG's.  CC3 uses a "natural" coordinate system, with the largest
numbers in the upper right hand corner.  SVG uses the (horrible, icky)
coordinate system where the largest numbers are in the bottom right hand corner.
You'd think it'd be easy to just transform (flip) the entire SVG group, except
that makes the text appear upside-down.  Le sigh.

BC

On 12-02-20 5:22 PM, Joseph Slayton wrote:
>
> {
>  short Font;
>  GPOINT2 Origin;
>  float Hght;
[...]
> }TXT2;

Oh, awesomecakes!  That's tremendously helpful!

I'll poke around on the web site for the XP development kit.

BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

On 12-02-20 5:35 PM, L. Lee Saunders wrote:
>
> The latest XP development Kit code (for CC3) is available for
> download on Peter Olsen's site:

Thanks bunches!  I wasn't having much luck finding the kit on the
ProFantasy site.

BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

Thanks for all the help, guys.  I've made some progress, and the XP
development kit headers have done a lot to clarify the file structure.

I'm currently pulling my hair out trying to figure out how I'm going to
handle brush pattern fill styles, but it's been a fun learning experience.

BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

Mike can't post via yahoo groups, so he asked me to forward this:

Entity type 5 is 2d Text. The "as built" reference is the ESTRUC.CPY file in
the XP toolkit.
ESTRUCO.CPY describes some older version entity structures.

Reading assembly data structures is not very different from C structures -
real4 for float, real8 for double, dword for int/unsigned int, word for
short, and byte for char/unsigned char.

Type 0x80 contains plot assembly data, and type 0x81 is the NOTE entity
structure Types 0x80 and above are non-drawing entities.

Brush fills are part of the Fill Style InfoBlock (See FSTYIB.CPY and
FSTYLES.CPY).
There is no direct service for adding a fill style from a program - you will
need to understand and modify the Fill Style InfoBlock record. (EType = 0)
(IBType = 7).

Mike

-----Original Message-----
From: cc2-dev-l@yahoogroups.com [mailto:cc2-dev-l@yahoogroups.com] On Behalf
Of BC Holmes
Sent: 21 February 2012 04:26
To: cc2-dev-l@yahoogroups.com
Subject: Re: [cc2-dev-l] Re: FCW format and existing FCW->SVG code


Thanks for all the help, guys.  I've made some progress, and the XP
development kit headers have done a lot to clarify the file structure.

I'm currently pulling my hair out trying to figure out how I'm going to
handle brush pattern fill styles, but it's been a fun learning experience.

BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been  more
specific." -- Lily Tomlin


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

To Post a message, send it to:   cc2-dev-l@eGroups.com
To Unsubscribe, send a blank message to:
cc2-dev-l-unsubscribe@...! Groups Links

I feel like I'm making interesting progress on this exercise.  I'm able
to tackle a number of features that the original C sample code couldn't
handle.

Here's a sample output:

(SVG)
http://bcholmes.org/maps/TownOf%20Greenheight.svg

(PNG)
http://bcholmes.org/maps/TownOf%20Greenheight.png

These are both based on this map, here:

http://www.profantasy.com/library/default.asp?Keyword=greenheight&PP=9&Start=1&I\
mage=0&OrderBy=


Here are some things I've had to figure out:

1. include text labels
2. remapping the points into SVG's coordinate-space, rather than just
rely on a "flip" because text labels would be upside-down
3. handling fonts (although this example doesn't appear to have found
the right fonts)
4. applying the different drawing items to Inkscape layers
5. rotation on symbols so that the end result is oriented correctly

Here are things I'm still fighting with:

1. Fills: I've figured out a lot about fills -- different fill types,
for example (brush pattern, cross-hatch, etc.), but I still think I'm
missing some details about fills.

In this example, my water (upper right hand corner) isn't correctly
filled (since I assumed that non-closed areas aren't filled).  There are
some trees that aren't properly filled, too.  And a house in map section
E00.

I also sometimes get shapes that are filled when it appears that they
shouldn't be.  For example, I had to manually correct the beige text box
on the right -- there's a black border that was filled in when it
shouldn't have been.

2. Splines: My paths are all straight-line edges.  I've found the
references to "smoother types" in the header files.  I just need to have
an a-ha moment to figure out how to implement these.

3. In this example, I somehow ended up with an entity referring to a
non-existing layer.  That might just boil down to a bug I hafta find.


Here are things I know how to do, but don't yet support:

4. Brush patterns -- I finally understood the idea of the 8x8 bit pattern.

5. Line styles


In general, I think I'm quite pleased with how much this has all fallen
into place.

Thus far, I've just been trying to understand the format.  My code's
been written in Java (since that's the language I'm fastest with).  But
what I ultimately would like to do is create a simple viewer for the
Mac.  (I've basically stopped using my Windoze machine, and never get to
fire up CC3 any more).  My final result will probably be in Objective-C.

BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

On 12-02-24 3:18 AM, Peter Olsson wrote:
>
> Fills:
>
> The black outline has fill style set to solid, but it also has line width
> set to 1.5. This means that the outline is actually two boxes and the space
> between them should be filled.


Ooo!  That's extremely helpful.  Thanks!


> Splines:
>
> You are looking for Cubic B-Splines. There seems to be something in the SVG
> standard: “The "C" portion of the path describes a cubic spline“.
>
> CC3 supports parabolic splines and Bezier curves as well, but they are less
> common.


*nod*

I'd noticed (and Mike also pointed this out to me in email -- thanks
Mike!) the parts of the headers that refer to "Smoother Types" and
"Smoother Resolution" (and start and end points).  I just need to figure
out the math of splines well enough to know how to translate that into
SVG's notion of "control points".  My learning is happening on multiple
fronts!


BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

I'm a bit confused about if SVG uses Cubic B-splines or Bezier functions.

There are conversions between the two though. Google turned up this paper:
http://i33www.ibds.uni-karlsruhe.de/papers/Buchauswahl.pdf
See 5.10 on PDF-page 44 (number 72 on the page)

Since it is possible there ought to be more practical references as well.

Peter

-----Ursprungligt meddelande-----
Från: cc2-dev-l@yahoogroups.com [mailto:cc2-dev-l@yahoogroups.com] För BC
Holmes
Skickat: den 24 februari 2012 15:33
Till: cc2-dev-l@yahoogroups.com
Ämne: Re: [cc2-dev-l] FCW to SVG Progress

On 12-02-24 3:18 AM, Peter Olsson wrote:
>
> Fills:
>
> The black outline has fill style set to solid, but it also has line
> width set to 1.5. This means that the outline is actually two boxes
> and the space between them should be filled.


Ooo!  That's extremely helpful.  Thanks!


> Splines:
>
> You are looking for Cubic B-Splines. There seems to be something in
> the SVG
> standard: “The "C" portion of the path describes a cubic spline“.
>
> CC3 supports parabolic splines and Bezier curves as well, but they are
> less common.


*nod*

I'd noticed (and Mike also pointed this out to me in email -- thanks
Mike!) the parts of the headers that refer to "Smoother Types" and
"Smoother Resolution" (and start and end points).  I just need to figure
out the math of splines well enough to know how to translate that into
SVG's notion of "control points".  My learning is happening on multiple
fronts!


BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been  more
specific." -- Lily Tomlin


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

To Post a message, send it to:   cc2-dev-l@eGroups.com
To Unsubscribe, send a blank message to:
cc2-dev-l-unsubscribe@...! Groups Links

----- Original Message -----

From: Peter Olsson

To: cc2-dev-l@yahoogroups.com

Sent: Thursday, February 23, 2012 8:34 PM

Subject: Re: [cc2-dev-l] CC3 Directory

 

The easiest is to use RSC_OurPath to get a pointer:

 

char *pMyPath = RscAdr(RSC(RSC_OurPath));

 

Peter

 

Från: cc2-dev-l@yahoogroups.com [mailto:cc2-dev-l@yahoogroups.com] För L. Lee Saunders
Skickat: den 23 februari 2012 16:45
Till: cc2-dev-l@yahoogroups.com
Ämne: RE: [cc2-dev-l] CC3 Directory

 

From the FCW32.TXT file:

 

;               ===============================================================

;               GetOurPath - Get path to FCW32.EXE into RSC_OurPath

;               ---------------------------------------------------------------

;               On exit:

;                               RSC_OurPath contains our load path ending with \ NULL

;               ===============================================================

 

Is that what you are looking for?

 

BTW, RSC_OurPath  is defined in the file _RSCID.H

                    #define RSC_OurPath                         3059     // path to FCW32.EXE (ends with \)

 

Since I do not see a “glue routine” that wraps a C call around a ASM call to GetOurPath, you will have to write your own. 

 

Or, if Peter reads this, he may be able to help you do it.  I’ve not written a Glue routine in maybe 10 years, sorry.

 

Lee

 

From: cc2-dev-l@yahoogroups.com [mailto:cc2-dev-l@yahoogroups.com] On Behalf Of Joachim de Ravenbel
Sent: Thursday, February 23, 2012 8:34 AM
To: cc2-dev-l@yahoogroups.com
Subject: [cc2-dev-l] CC3 Directory

 

Help please!

 

I need to get the CC3 Directory full path for an XP.

What I want to do is something like :

 

string ^FilePath = GetCC3MainDirectory() + "\newfolder\";

saveFileDialog1.InitialDirectory = FilePath;

 

Is there a command like GetCC3MainDirectory ?

 

I saw a RSC_GetOurPath int but didn't managed to use it.

RscAdr(RSC_GetOurPath) doesn't work...

 

By the way, what does RSC mean ? I guess it's not the Rotten Squeezed Cucumber my frustration made it :)

 

Thanks,

Joachim de Ravenbel

On 12-02-24 3:18 AM, Peter Olsson wrote:
>
> If you describe your problems with text labels, fills, line styles etc we
> might be able to provide more help.


Here's my latest problem with fills.  Take this example; the original
file is over here:

http://www.profantasy.com/library/default.asp?Keyword=fortress&PP=9&Start=1&Imag\
e=6&OrderBy=


Here's my SVG conversion:

http://bcholmes.org/maps/fortress.svg

(and PNG, for good measure):

http://bcholmes.org/maps/fortress.png


This example uses at least three different fill styles.  A solid fill
(on, for example, the red section), a brush fill pattern (the background
"earth" fill) and a symbol background (a barely visible square grid on
the rooms of the map).

Resolving the types of fills is laborious but straight-forward.  I've
got a quick algorithm to construct an 8x8 pattern (although the
temptation here to do something that looks less "low res" is strong) so
I can basically recreate any brush pattern.

The thing I'm not understanding is colour.  The appearance of this map
on the Profantasy site has a light grey colour to the earth fill,
whereas the actual fill color described in the FCW file is almost black.
  Similarly, I end up seeing the square grid as light beige when, again,
the image on the Profantasy site seems like the grid is grey.

What am I not understanding about background colours?


BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

On 12-02-26 12:32 AM, L. Lee Saunders wrote:
>
> Actually the color in the FCW file is #16.  That is a very light grey
> color. It si the first color on the left of the second row. > What am
> I not understanding about background colours? Where are you seeing it
> as black?  Do a list command on the backbround and you get this info:
> 2D Polygon: color 16 () layer 8 (BACKGROUND (MAP))


Oh, interesting.  I took a list of colours from the original FCW->SVG C
code (specifically, in the fcw.c file).  That code specified that colour
number 16 is #100000 (the almost-black that I ended up with).  Serves me
right for just accepting that at face value.


BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

On 12-02-27 4:45 AM, Peter Olsson wrote:
> There is a function called GetPalAdr() which will give you access to the
> current palette with the color values.


Thanks for the pointers!  (Uh, no pun intended).

BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

On 12-02-27 11:10 AM, L. Lee Saunders wrote:
>
> BC, if you write any glue routines, please post them for all to use, OK?


I'm certainly willing to share any code I write, but at the moment, I'm
not writing anything in .Net, so I don't have any glue routines.  The
code I've written so far has been in Java.

I'll probably end up porting my code back to C eventually (my C is rusty
though).

BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

Hey folks!

I continue to have a lot of success making sense of the FCW file format.
  Last night, I was working on multipolys.  A lot has come together, but
a few things still need work.  Here's an example of some multipolys that
aren't quite behaving:


PNG -> http://bcholmes.org/maps/Laxton%20Abbey.png

SVG -> http://bcholmes.org/maps/Laxton%20Abbey.svg


Based on this map, here:

http://www.profantasy.com/library/default.asp?Keyword=laxton&PP=9&Start=1&Image=\
0&OrderBy=


There are two badly-formatted items, here.  First, the green background
doesn't completely fill in (it ends up looking like a green triangle).
Second, the cartouche in the lower right hand corner isn't filled.

I think both problems relate to building the multipoly path.  Currently,
I somewhat simplisticly attach each new path element in the order in
which I find it.  In the case of the green background, the end result
should be a rectangle, but the line segments aren't in the best order.

In essence, my converter draws the bottom of the rectange, left to
right, then moves to the top line, right to left then down, then finally
moves to the right-most line and draws it upward.

I'm sure that I can figure out an algorithm to find the best order for
the path parts, but I was wondering if there's any clues in the file
format that I haven't yet noticed.

One of the other things I sometimes see is that line segments are
described "backwards" -- that is, for the purposes of finding the best
"join", it would be a lot easier if the line were described in the
opposite direction.  Again, not an insurmountable problem.

BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin

On 12-03-06 3:22 PM, Peter Olsson wrote:
>
> You are not missing anything in the file format. The entities are in any
> order.


Thanks for the confirmation, even if it's the sad-making answer :)


BCing you
--
B.C. Holmes             \u2625                http://www.bcholmes.org/
"All my life I've wanted to be somebody; I guess I should've been
  more specific." -- Lily Tomlin