Maps available

[Gandalf Parker]

Originally posted by mercurycs:
ok, about the size of maps,
SOME ARE HUGE!!!!
but what would be the difference in taking the map's tga file and converting it to jpg and post the jpg. people can download the jpg and then convert it to tga on their own computer so they can use it. there are freeware image converters out there that can be downloaded. I have been running tests on my computer and can see no loss in image quality between jpg and tga so that isn't an issue. a 35 meg tga file is just over 2 megs in jpg format.

Interesting. Id never considered that. But it would be almost the same as zipping the files. On the one hand, more people probably have unzippers than have graphic converters. On the other hand, it would be easier to display the maps for download on a website. Hmmm no come to think of it making the maps viewable on a website isnt really a problem so ZIP would probably be better.

[Strages Sanctus]

Ello ello,

How does 'Dominions II' know where each province is? Does it look for the single white pixel and simply go from top left to bottom right scanline style. Numbering each pixel as a province, as it goes along?

Does this mean that the border-line graphic is just for human ease of use, rather than of any use data-wise to the software? In other words; there is no edge detection routine necessary.

Just trying to figure this out so I can make a map definition tool (it would not be pan-platform since I would be working in lingo). I want to put together a tool that will generate names based on racial themes, terrain etc... and provides for supplying an external name list. Also drop down terrain definitons and other applicable dropdowns for creating the .map file. It would be gui driven of course.


EDIT: The only place I can see borders being needed would be for auto-neighbour detection...

Thanks in advance.

[ January 09, 2004, 18:59: Message edited by: Strages Sanctus ]

[Gandalf Parker]

Originally posted by Strages Sanctus:
How does 'Dominions II' know where each province is? Does it look for the single white pixel and simply go from top left to bottom right scanline style. Numbering each pixel as a province, as it goes along?

Single white would be nice but its any white (255,255,255 RGB) so mapmakers need to avoid using total white for things like snowy mountaintops. The numbers was UpperLeft to LowerRihgt for Dom1 but seems to be LowerLaft to UpperRight for Dom2

Does this mean that the border-line graphic is just for human ease of use, rather than of any use data-wise to the software? In other words; there is no edge detection routine necessary.

Im not sure. I think Dom2 uses the boundarys less than Dom1 did. I think I also remember something about red being a good ingrediant in border lines for something. Maybe Kristoffer will jump in on that.

Just trying to figure this out so I can make a map definition tool (it would not be pan-platform since I would be working in lingo).

sorry for my ignorance but what platform would that be then?

I want to put together a tool that will generate names based on racial themes, terrain etc... and provides for supplying an external name list.

I did some work on that if you want to look at it. Nothing fancy but it was workable. Basic though. Look at the .bas files here http://www.techno-mage.com/~dominion/
and examples of the output are here.
http://www.techno-mage.com/~dominion/maps/

Also drop down terrain definitons and other applicable dropdowns for creating the .map file.

That would be nice but if I could make a request I think that an option to automatically do things then offer editing would be helpful. Even if it did bad guessing as to terrain from colors used, bad guessing on neighbors, bad naming, anything. I just find it easier to see it and fix it than to tackle it manually. In fact, I think Id rather edit manually using notepad and paint than use an editor that didnt try to fill things in. Just IMHO.

It would be gui driven of course.

Oh rats. Even if it was linux I prefer my linux boxes GUI-less.

There is a map generator that was done for Dom1 and the source is available. But its in C. Would that be helpful?

[mercurycs]

Quote "Interesting. Id never considered that. But it would be almost the same as zipping the files. On the one hand, more people probably have unzippers than have graphic converters. On the other hand, it would be easier to display the maps for download on a website. Hmmm no come to think of it making the maps viewable on a website isnt really a problem so ZIP would probably be better."

Gandalf Parker, I have to disagree about it being almost the same. jpegs are around 1/4 the size of a zipped tga file. here is my findings:
tga 1: 26,065,978 compressed to 8,781,802 zip file
tga 1: 26,065,978 converted to jpg : 2,891,790

tga 2: 39,233,987 compressed to a 12,103,218 zip file
tga 2: 39,233,987 converted to a 4,785,664 jpg

Big difference for dial up people, and a free graphics converter can be found at
http://www.softpile.com/Multimedia/I...830_index.html
I have dsl and the map files arent a problem, but i do remember my dial-up days. anyway, food for thought

[Strages Sanctus]

Lingo is Director's internal development language.

It runs on mac and windows, shockwave is the web product created from it. It also creates stand-alone executables for mac and windows.

It would be easy enough if there are only single white pixels (as being the only pure white in the image) defining each province ALONG WITH true red borders defining each province area. (the borders could be removed once the map data file was generated).

This would enable the code to find a single white pixel and then find the entire area around it that is within in the confines of a true red border (I have fill code similar to this).

It could then look at the color of the pixels in that area to define the territory or multiple-territory types (like mountain/forest or mountain/waste). It could then look at a set of teerain lists and generate a name for that province(your bas files is exactly the type of thing I am talking about.)

Even without the red borders it could expand out in its detection process only a certain range and generate its data that way. But then neighbour detection would be very haphazard since it would have no way of knowing its relationship to other provinces except for proximity to the other province indicating white pixels.

Edge detection for both the above process and the process of determing adjacent neighbours is much easier when you have a set of defined points from which to 'expand' from out to a definied color border(in this case the single pixels of true white and a border of true red.)

I think for the first run I would do this, and then see if it is possible to incoporate some kind of ability to automate blocked off borders (the double thick borders in current maps).

The automated process could of course all be done gui-less. The gui would come in for doing things manually.

It would be also be neat to consider it being able to look at other graphic data to do more complex automation of things (a graduated color overlay indicating neutral areas, racial make-up of neutral provinces, strength etc...) this would work really well with something like your randomizing routines.

Edit: it's and its (grammar is evil)

[ January 09, 2004, 19:48: Message edited by: Strages Sanctus ]

[Tiltowait]

"what would be the difference in taking the map's tga file and converting it to jpg and post the jpg. people can download the jpg and then convert it to tga on their own computer so they can use it."

In my experience, when you convert to jpg (or gif, or any format) if you degrade the picture in any way then when you expand it back to tga size the single-pixel captials can change color and sometimes expand to 2 pixels. 2 pixels means you have 2 provinces basicly on top of each other, a bad thing.

"How does 'Dominions II' know where each province is? Does it look for the single white pixel and simply go from top left to bottom right scanline style. Numbering each pixel as a province, as it goes along?"

Yes, but bottom left to top right scanline. Borders are just eye candy (maybe they are used for guessing provinces, but guessing does not work well). When I make a map, all that counts are where the single pixel 255 255 255 capitals are, I then rename some other .map file, delete all the #neighboors, point it to the right .tga and use the Load Map command on it and manually set the borders.

When making a map, place the captials Last, right after you filter the image to remove all other pure white (I use Filter > adjust color > levels and set output level maxing at 254, which works fine.)

BTW, since borders do not matter, you should be able to open up Dominions I maps, remove the single white pixel hidden in the top left corrner, copy another .map file and edit it to point to the dom1 tga, set the borders and be done.

[Saber Cherry]

You can use lossless formats, like lossless JPG or PNG. But never use lossy compression on an image where non-visual data is stored in the image file. Lossless formats do not compress nearly as well as lossy ones, of course.

The freeware program IrfanView can interconvert all common graphics formats, and you can specify quality on lossy formats. It is the best freeware program I have ever used.

-Cherry

[PhilD]

Originally posted by Saber Cherry:
You can use lossless formats, like lossless JPG or PNG. But never use lossy compression on an image where non-visual data is stored in the image file. Lossless formats do not compress nearly as well as lossy ones, of course.

Will Dom2 accept to load non-TGA image files? I was assuming not...

One solution (to excessive download size) would be to offer the .tga files in a variety of resolution - the person making up the map should be able to do that with little hassle.

[Arralen]

what will not work with DOM2:

• using any other format than .tga, at least unless the developer add support for it with a patch. I#m not shure, but I think the SDL library supports other formats as well, but than there's still the problem that other routines have to read the graphic file as well.
• compressing/resampling/resizing the map pics with any paiting programm, unless doing lots of work by hand or maybe someone could write a script for Gimp
  This is because provinces are detected (and flag graphics shown) by pure white pixels (255,255,255/1x1). Making a .jpg from the .tga will result in artifacts, which will shurely kill some of these pure white dots here and produce some more there .. provinces screwed up badly. Resizing/resampling will do basically the same ..
• changing the resolution. In fact, the resolution set in the graphics file doesn't matter at all. (You may set it to 72 dpi or 305 dpi, however you wish. DOM works based on pixels, not graphic size in mm. Changing the number of pixels is [i]resizing/-sampling[/] and will screw up the map. (see above)

What will work is :

• using sufficient size (in pixels) for each province so that everything on the map is displayed where it belongs, and leaving out any non-map/province areas from the file
• using few (256) colours when making the map. Using big, flat single-color areas doesn't look that neat, but keeps the file size very low, especially as the RLE compression works better the more uniform an image is.

I resized and modified my old DOM1 map, so I have gone through all this hassle before. BTw., did anyone check this map out? Despite being 1600 pixels wide, it's only 1,6 MB big ... . I'm working on an extended Version at the moment, I'll post it (link) when it's finished.

A.

[Arralen]

what will not work with DOM2:

• using any other format than .tga, at least unless the developer add support for it with a patch. I#m not shure, but I think the SDL library supports other formats as well, but than there's still the problem that other routines have to read the graphic file as well.
• compressing/resampling/resizing the map pics with any paiting programm, unless doing lots of work by hand or maybe someone could write a script for Gimp
  This is because provinces are detected (and flag graphics shown) by pure white pixels (255,255,255/1x1). Making a .jpg from the .tga will result in artifacts, which will shurely kill some of these pure white dots here and produce some more there .. provinces screwed up badly. Resizing/resampling will do basically the same ..
• changing the resolution. In fact, the resolution set in the graphics file doesn't matter at all. (You may set it to 72 dpi or 305 dpi, however you wish. DOM works based on pixels, not graphic size in mm. Changing the number of pixels is resizing/-sampling and will screw up the map. (see above)

What will work is :

• using just sufficient size (in pixels) for each province so that everything on the map is displayed where it belongs, and leaving out any non-map/province areas from the file
• using few (256) colours when making the map. Using big, flat single-color areas doesn't look that neat, but keeps the file size very low, especially as the RLE compression works better the more uniform an image is.

I resized and modified my old DOM1 map, so I have gone through all this hassle before. BTw., did anyone check this map out? Despite being 1600 pixels wide, it's only 1,6 MB big ... . I'm working on an extended Version at the moment, I'll post it (link) when it's finished.

A.

edited: code & spelling, but it doesn't help much..

[ January 10, 2004, 06:36: Message edited by: Arralen ]