Snap to 64+1 & plus painting question

[Cash on Wheels]

Does anyone have a clue to the pros and cons of NOT using the "Snap to 64+1" option? This is in the mapbuilder.

Like why to use it and what happens if you do use it. IIRC a long time ago I chose not to use the 64+1 option and the game reverted from 560x560 to 512x512 during the build.

Also how did the paint job for Cold War Colorado appear in your computer screen? I asked this because, despite all of the warnings about Painting your map early I still do it in this order.

1. Precise map geo features/ Boarders
2. Precise city placements
3. Set & seed regions
4. Seed cities
5. Bare minimum paint job
6. 1 test run
7. Paint rest of map
8. Place rivers ( ignore the arrogant river junctions)
9. Multiable test runs
10. Script events
11. more test runs
12.Beta
13.Confront remaining river junctions! & spelling
14.Off to archives!

[RulerofRails]

Never used the mapbuilder, so can't comment about that.

Cold War Colorado appears fine on my machine.

On the topic of degradation, there doesn't seem to be a clear consensus on the definition of what is being described. I have seen some older maps which have completely warped paint jobs (all the ones in the archives have now been fixed). The most definite evidence could be what Hawk (couldn't find it quickly) documented: a loss in file size after each load-save cycle even when no physical changes were made to the map.

On my old machine (Win 7, 32-bit) in which the game runs straight from the box (Hardware T&L disable doesn't need to be checked), when I load the map British Isles in the editor and then save it without making any changes I get this:

Degradation size loss.jpg (3.71 KiB) Viewed 7783 times

For me, repetition doesn't make a difference, the 2nd, 3rd... all are the same reduced size. It's clear that something is being lost here, but the resolut. I haven't researched it extensively for example looking at the files in the hex editor, but I'm pretty confident it's "bmp" (painting) data getting lost from the end of the gmp file.


On my new machine (Win 8.1, 64-bit, running with dgVoodoo 2) when I repeat the test I have an identical file size for the re-save. Both are "9,244KB".

The type of "degradation" I happen to see on the old machine is seen on the coast-lines (bear in mind, no one else has reported seeing the same thing). The Good copy from the new machine on the left with the Bad one from the old machine on the right.

I did a direct view, but when shadows are highlighted with the lighting it's more obvious/annoying.

Your maps looked ok so your machine is probably safe. However, to be really safe you could always keep a backup of the map from step #7 (final paint). If you get problems later, just peruse these instructions to figure out how to find the start of the "bmp" section of the backup gmp file, then use that data to overwrite the "bmp" section in your final gmp file (obviously there's no problem if file length is extended).

[Gumboots]

Interesting that you're not getting degradation on 64 bit with Voodoo. I'm intrigued and will have to run some tests. If it's now possible to avoid serious graphics degradation I could actually get interested in mapmaking. I've had ideas for scenarios for ages, but the problem of RT3 wanting to trash my work as I go has put me off making any.

[Gumboots]

Just ran a few quick tests.

Note: Before anyone even thinks of it I do not want to hear the old myth about "if you change the map name it doesn't degrade". Not only is it illogical, but I have tested it before and it does not work if you are running without Voodoo and (consequently) with Hardware T&L disabled.

Having got that out of the way....

---------------------------------------------------------------------
First test:

Open default Rhodes Unfinished map.
Save with no map or event changes, but with a new name.

Result: same byte count as original map.

---------------------------------------------------------------------
Second test:

Open default Rhodes Unfinished map.
Un-check campaign option, no other map or event changes.
Save with a new name.

Result: same byte count as original map.

---------------------------------------------------------------------
Third test:

Open default Rhodes Unfinished map.
Paint a few random white stripes in various places.
No other map or event changes.
Save with a new name.

Result: byte count fractionally reduced compared to original map.
---------------------------------------------------------------------

The fractional reduction in byte count for the third test makes sense, because the random white stripes should require less information to code than the (more complex) pattern that was there originally.

The relevant point being that, at least so far, it seems that running Voodoo + Hardware T&L may allow editing of maps without graphics degradation.

Which is not entirely silly. Since the Voodoo stuff fixes known graphics problems with RT3, it may well be that it fixes the known editor degradation problem too.

Will do some more testing and see what happens.

[OilCan]

Does anyone have a clue to the pros and cons of NOT using the "Snap to 64+1" option? This is in the mapbuilder.

Like why to use it and what happens if you do use it. IIRC a long time ago I chose not to use the 64+1 option and the game reverted from 560x560 to 512x512 during the build.

The RT3 map editor only accepts map dimensions in units of 64, starting with 65 (65, 129, 193, 257, and so on up to 1025). The editor will automatically resize a map to the closest fit. That's why your 560 dimensions were adjusted to 512.

If you check the snap to 64+1, then mapbuilder will provide a proper dimension map for the RT3 map editor. It will not be adjusted by RT3 - unless a dimension exceeds 1025.

But the most important thing about mapbuilder is to correct the projection (distortion) of the map. The further away from the equator you go in mapbuilder, the more distorted the map will be.

(1) Mapbuilder gives the proper scale when the map is created (note the dimensions for the proper projection circled):

(2) Use a photo editor (I like GIMP) to resize mapbuilder's TGA (targa). Enter in the dimensions provided by mapbuilder.

(3) Resize the TGA, save it, and use this map in RT3 editor. (You may have to resize again to the closest dimensions of 64 units.) As you can see in this example, correcting the projection makes the British Isles look more realistic.

[Cash on Wheels]

Thanks, Every time I tried to build a solo Florida map I had delete because of the eye sores it gave me. Now I can build that map some time in the future.

[Cash on Wheels]

Turkey & syria painted! Now that I've got thr ball rolling again I should be able to beta it by the end of july.

Its werid that there does not seem to be much north-south compression on this one- (above)

[Gumboots]

It's not really north-south compression. It's more east-west stretching. The way it works is that DEM's use what's called a cylindrical projection, which as you'd probably guess treats the spherical Earth as if it was a cylinder. This is done because a/ it's seamless and b/ you can lay out a consistent grid for latitude and longitude on it and c/ it works reasonably well for most of the latitudes were people live.

Anyway, since the Earth tapers towards the poles but cylinders don't taper at all, a cylindrical projection stretches the area east to west as you move away from the equator. The amount of stretching is purely dependent on the latitude, so if your map "seems to be" less stretched than you'd expect this would be an illusion. It's probably just less obvious due to the shape of the landmass you're working on.