Cross-Platform Civ3 Editor

Cross-Platform Editor for Conquests now available! 1.51

Could it be that a bigger resources.pcx is the reason why the map screen gets sometime stuck when I scroll the map? It happens on a resources heavy portion of the map. Support for larger than 6 rows sheet would be appreciated as I tend to add more rows than lines.
 
Ok, I will just reformat my resources.pcx from 24 to 6 columns then - I need to do that to get around the shadow* resource problem anyway (I make use of a lot of bonus resources, but not quite that many - heh).

Btw, why not just make the format require the width of the resources.pcx to be divisible by 50 instead of a specific number of columns?


EDIT: I do ofc mean phantom/ghost* resource problem

That's what I plan to do to increase compatibility. It's the way it is now due to me programming it based on the standard art files originally, which had 6 columns. Apparently, all the scenarios I've opened with it, and probably all the ones in my Scenarios folder, use 6-column resources as well.

Could it be that a bigger resources.pcx is the reason why the map screen gets sometime stuck when I scroll the map? It happens on a resources heavy portion of the map. Support for larger than 6 rows sheet would be appreciated as I tend to add more rows than lines.

:hmm: Possibly. By "stuck" do you mean that you can't get it to scroll farther over, or that it stops drawing the map altogether? It certainly sounds like there's an error of some sort, and on the map tab, it's likely to be a graphics issue. But it's hard to say without seeing it myself. Is it a mod/scenario that's available on CFC/Apolyton/SOE?
 
It only stops drawing the map. I can still move it around : if I blindly scroll around and then click on the map, I'll get information about a tile that's obviously not the one drawn. I'll send you the .biq and the .pcx in a day or two, if you would be kind enough to check it. Definitely no rush.
 
That does sound like it's getting tripped up on the graphics somewhere. Go ahead and send me the .biq and .pcx, and I'll investigate.
 
Version 0.84 is now available! Grab it from the usual place. There are a number of changes here, primarily focused on map functionality.

Changes:

  • Added the ability to create a Civ3 map from a bitmap image (see below).
  • Bonus grassland is now displayed.
  • You can now paint the map with snow-capped mountains, pine forests, and bonus grassland.
  • You can now display food and shields on the map.
  • Added a bonus grassland redistributor.
  • Added the ability to change x/y wrapping, polar ice caps (note: these don't display in the editor), and the ostensible size of already-created maps (not as exciting as it might sound; see below).
  • Performance improvement on map so that it now uses up to 78% less CPU power when drawing the map.
  • Fix so that starting locations once again appear in civ-appropriate colors (broken in 0.82).
  • Zoom is now properly enabled after creating a new custom map.
  • Fix in the zoom code so the panel on the right side of the map is the intended size after program start (in 0.83, it could be wider than intended).
  • Added ability to view memory usage info within the editor.

The first feature is the big one - creating a map from a BMP. This is presently possible using BMP2BIC. However, this works rather differently. The major differences:

  • In BMP2BIC, you have, more or less, 1 pixel = 1 tile. Here, the program analyses a large number of pixels to create 1 tile.
  • In BMP2BIC, you map each pixel to a terrain. Here, you map colors to terrains, but the BMP itself is a map of the world that you find somewhere on the Internet (such as Wikipedia or nasa.gov).
  • BMP2BIC only supports certain map sizes, up to 256x256. Here, you can use any map size you want, as long as it matches up with your BMP's dimensions and will result in a map with no more than 65,536 tiles.

You'll still have a fair amount of work to do on the map once it's imported, but it should get you up and running with more-or-less established coastlines, and terrains somewhat corresponding with what you'd infer from the source image. Think of it more as getting over the initial hurdle of staring at a blank map, not as instantly creating a perfect map.

You can read more about this in the help file (accessable via the ? icon in the editor), including information about the type of BMP required. The ability to import a map via a BMP lives under the new "!" icon.

Note: If using GIMP 2.8 or later to convert to 16-color .BMP, you'll need to check the "do not write colorspace information" when saving the .BMP prior to importing it into the editor. In earlier versions of GIMP, this is the default and there is no check box. In a future update, the editor will handle both of these variations. With version 0.85, you can use up to 256-color BMP files, and you don't need to check that box if using GIMP.

(Side note: does anyone know where a proper BMP2BIC thread lives, whether here or on Apolyton)

The "special" terrains of bonus grassland, pine forest, and snow-capped mountains also have support. Of special note is that you can now paint landmark pine forest and bonus grassland, whereas in Firaxis's editor you could only have landmark regular forest and landmark regular grassland. Landmark snow-capped mountains still are non-snowy (though they gain snow if you un-check the landmark option). You can select these terrains just like any other - there is now an option for these "special" options when you choose Grassland, Forest, or Mountains.

The ability to change world size, which resides within the polar ice cap option under the new "!" button, doesn't actually change the world size. What it changes is what WSIZ the map thinks it is. For example, the Rise of Rome conquest thinks it's on a Large map. If you change this to Small, it will now think it is on a Small map. This affects optimal city number, among other factors on the WSIZ tab. It may be easier to change this here than changing it on the WSIZ tab - particularly if you didn't know what size the BIQ thought its map was in the first place.
 
Creating from bmp to bic/bix/biq format? XD!!! I will try this out.
 
There are a number of changes here, primarily focused on map functionality.
...
the big one - creating a map from a BMP.
...
You'll still have a fair amount of work to do on the map once it's imported, but it should get you up and running ...
grumpcatwork.jpg


(Side note: does anyone know where a proper BMP2BIC thread lives, whether here or on Apolyton)
Not sure what's a "proper" thread. I can probably either answer any questions or have the answers bookmarked.
 
I should probably have at least a bit of a preview of what a map may look like when created from a BMP. So here's one:

attachment.php


This is what the (Firaxis) Minimap shows on a map I created using a pre-release of version 0.84, without any editing done after the import. There's still quite a bit to be done, particularly in Asia, western North America, and wherever there are mountains, but it shows the coastlines and picks up on several of the larger deserts, jungles, and tundra. This is with an Equirectangular (Plate-Carée) projection, and no continents enlarged or shrunk. I did cut off the northernmost and southernmost parts of the map before importing it.

One other note, if you are letting GIMP auto-choose the colors, it often chooses noticeably different colors if you scale the image to the size the editor needs and then change the palette, versus changing the palette and then scaling the image. Sometimes it's better the first way, sometimes the second. I was a bit surprised at first, but I figure it's just a side effect of how those algorithms work in the GIMP. This sort of difference can also result in slightly different borders between terrain (including coasts) when importing the map.

Edit: Here's another, closer-up view of the Mediterranean region:

attachment.php


With a couple exceptions such as Italy and the southern part of the Red Sea, I think the coastlines are generally decent as a starting point (the island east of Norfolk was in the BMP). Scandinavia might have had more tundra, but lost nearly all of it because tundra can only border grassland and coast (as base terrains) in Civ3. Asia clearly has a surplus of plains in this map.

Another consideration when choosing the image is the time of year it's from. The colors I tend to be kinder to Australia, Africa, and South America than Asia and North America, but my source image also was from May, just prior to monsoon season in India, exacerbating the problem. Doing the same process with a December map source resulted in a wetter Asia and more tundra in the north, as well as different forest covering and slightly different coasts due to varying colors. It's a good example of why it isn't possible to get a perfect map from one image.

Creating from bmp to bic/bix/biq format? XD!!! I will try this out.

:D Glad to see the interest! I'd thought about creating a whole map first to go along with this first, but figured others with more map-making experience might be able to make use of it (and the other changes) in the meantime.

grumpcatwork.jpg


Not sure what's a "proper" thread. I can probably either answer any questions or have the answers bookmarked.

:)

I figured at some point there probably was an initial thread where BMP2BIC was released, and that would be the most appropriate thread to link to. But I don't know where it might be, and I don't really expect anyone else does either.
 
I figured at some point there probably was an initial thread where BMP2BIC was released, and that would be the most appropriate thread to link to. But I don't know where it might be, and I don't really expect anyone else does either.
There was. But the thread mostly consisted of people asking for the dead dl link to be restored. The thread where it was reposted actually has more useful info in it.

After a quick look at the help text: No mountains? No hills? Since the editor is getting a 16 color bmp as input & the colors are mapped by choice why would they be any more of a problem than plains or forest? I'll still produce bmp's the same way I did for bmp2bic. That 16 color palette has room for both hills & mountains. I'd gladly sacrifice seas/oceans, marshes - even jungles - in exchange for pre-drawn mountains/hills. Similarly, imho it would be mistake to limit jungle placement to some arbitrary algorithm such as latitude. As an option, sure, but please not as the only one.
 
There was. But the thread mostly consisted of people asking for the dead dl link to be restored. The thread where it was reposted actually has more useful info in it.

After a quick look at the help text: No mountains? No hills? Since the editor is getting a 16 color bmp as input & the colors are mapped by choice why would they be any more of a problem than plains or forest? I'll still produce bmp's the same way I did for bmp2bic. That 16 color palette has room for both hills & mountains. I'd gladly sacrifice seas/oceans, marshes - even jungles - in exchange for pre-drawn mountains/hills. Similarly, imho it would be mistake to limit jungle placement to some arbitrary algorithm such as latitude. As an option, sure, but please not as the only one.

That's an impressive mapmaking process. I'd read some of your posts about your BMP2BIC palette before, but hadn't seen that post. It sounds like this may be a process that makes hills/mountains workable.

So without further ado, I've remixed the editor a bit to add the ability to select jungles, hills, mountains, and since it was easy enough from there, marshes and volcanoes as terrains that colors can map to (see attachment to this post). Separating sea/ocean from water in general, while still keeping the ability to have the editor do that on its own, is a bit more involved so I haven't done it just yet. I might in the future, but wanted to do the other options quickly to start with.

Edit: The help file will still be the same in the attached .zip, but the options when mapping colors to terrain do include the new options.
 
Separating sea/ocean from water in general, while still keeping the ability to have the editor do that on its own, is a bit more involved so I haven't done it just yet. I might in the future, but wanted to do the other options quickly to start with.
Can't speak for anyone else. But frequently I leave all the water coast until I'm doing detail work in the editor. Keeps BMP2BIC from arbitrarily making islands / isthmus / peninsulas go wonky. It's simple enough the "paint" the sea/ocean in the editor. IMHO it generally doesn't need the same precision for map accuracy or playabilty as the various land terrains. I'm happy with what you've provided re mapping. I'm sure there are a lot of other aspects of the editor you can work on. Thanks again for your continued hard work on this project.
 
Spent the morning experimenting with the latest version - strictly to test importing from bmps. Both extremely frustrating & rewarding.

The rewards outweigh the frustrations. Some of the frustrations are things other than the input/outcome process itself.

Overall I like the outcome a lot more than what BMP2BIC gave. The flow from creating an image based on an accurate map to an editable biq is now a lot smoother. Side by side images make it clear why -
Spoiler :

Click on the image to link to a larger version.

The map used is the one from 7Ronin's Asoka scenario. The small inset is the actual size required by BMP2BIC. Which was shrunk down from the one on the right - used to import directly into your editor. The bmps have been rescaled to approximate the size of the biq screenshots. Makes the jaggedness of bmp2bic brutally apparent.

It's so nice to have the fluid lines & smooth coasts a larger image provides. Not having to edit & redo small details such as mountain passes, islands, etc. is great as well.



Frustrations not directly related to import/conversion
  • Still having the problem with part of the drop down list blanking when selecting which folder to open from.
  • I had to go through several iterations of the process to get the kinks out. It's extremely frustrating to have to start at the top level and work down from selecting a volume through the whole directory structure every single time I want to open a bmp. Opening a new biq brings up the last folder used. Wish this did the same.
  • In the map window the scroll bars disappear unpredictably. Seems to be correlated to changing zoom, but that's all I know.

Frustrations with the process itself
  • It'll take some getting used to the formulas for image sizes. I'll probably make myself a little chart so I don't have to use a calculator every time I make a new map or want to adjust the size of an old one.
  • It's not enough to get a 16 color palette bitmap with proper dimensions. Kept having the editor just sit there. Found that the compatibility option "do not write colorspace information" had to be checked. At least for me - using GIMP 2.8.2 under OsX 10.6.8 .

Differences from BMP2BIC that are minor frustrations
  • No distinction between plains & grassland forests
  • No distinction between floodplains & desert
  • Found several times that I had to go back and redo the import because I missed changing the terrain for one color. Or chose the wrong one. In the picture above tundra can be seen where there should be marsh.

Rewards (which definitely outweigh all but the most frustrating problems)
  • Larger bmp means more natural looking terrain transitions on finished map. More finesse to minor details as well.
  • There's a closer relationship between the original source map(s) and the finished biq.
  • Looking at the bmp while creating it is very close to what the final map will look like. Easier to make effective creative decisions.
  • It should be simple to make minor adjustments to the bmp & reimport. Doing that with BMP2BIC was just too unpredictable.
  • I like the way the water is coming out - successive bands of coast & sea followed by substantial ocean. I actually like the idea of extending coastal and sea tiles while thinking about game play in the editor.

I know the interface issues are already on the to do list since they came up earlier in the thread.

Wish List - understood that these fall in the maybe later maybe never pile
  • Being able to make a preset color/terrain list would be a very nice feature. Knowing ahead of time what palette to work with really streamlined making bmps for BMP2BIC. Not everyone will want identical choices for your editor. But being able to set up an individual standard for our own purposes would be helpful.
  • I understand the coding reasons for 16 color choices. In a perfect world that number would be expanded to include all the terrain types available. The choices available in the firaxis editor, plus the variations such as plains/grass forest and also the addition lm terrains found by embryodead & others.
  • Short of that maybe a consensus on what terrains should fill up the 5 empty slots in the list would help you?

I'm very happy with the progress in the usefulness of the mapping functions. Hopefully these notes both confirm that and provide some help in knowing what fine tuning to do further down the road.
 
That is quite helpful. Some take-aways I have:

- I need to test this on a Mac again. The drop-down list blanking issue is one I haven't seen, and that may be because it's platform-dependent. At some point in the next few months I may be able to pick up a second-hand Mac laptop for testing.
- The scroll bars appear to need more testing. I've seen them slightly squished, and I know a few places where they need to be finessed. I'm not sure I've seen them completely disappear.
- I need to test this with GIMP 2.8. I've been using GIMP 2.4.7, mainly because it's the one I learned all the palette stuff with Kyriakos's excellent tutorial, and they rearranged all the menus in 2.6 :(. :c5moves: Update: Found out that GIMP 2.8 uses a more recent bitmap format than what the editor understands. This will be updated in the future. In the meantime, either using GIMP 2.6 or earlier will work, or checking the "do not write colorspace information" option in GIMP will cause it to save in the format the editor currently understands.
- The rewards you mentioned are pretty much what I was aiming for. You're right about making minor adjustments, as long as you've already got the image at the full size for the import and already have set the palette before adjusting it. Areas of the map that you don't change should be re-imported exactly as they were before.

Some follow-ups:

- The directory structure issue is likely one that can be fixed on 0.85 without much hassle.
- Perhaps I could add a quick utilty for image sizes. I've been using a calculator to do them, but it would be handier if you could just say, "I want a 300x150 map, what dimensions do I need?" in the editor.
- Plains/tundra forest is one of the areas I want to improve painting abilities on in general.
- I probably could add flood plains, although it would be more difficult to add flood plains and rivers at the same time. Not necessarily impossible, but it'd require some playing around with to see if the results were helpful over flood plains without rivers.
- One of the things I'd like to do is have the ability to import the map several times (including possibly from different bitmaps), allowing the user to slightly change the color->terrain mappings, and select the map that they like best. This would also make it easier to fix an improper selection. This would require a fair bit more testing as doing this several times could cause the program to run out of memory.

Wish List Follow-Up

- I could probably add a preset color/terrain feature. It would certainly be nice - I did enough matching up colors and terrains in testing to see that.
- I think there are a few options for allowing more colors/terrain options. I could simply add every possible combination to the list, but some may find that unwieldy - and it wouldn't solve the issue of possibly wanting more than 16 at once. Here's one idea:

Idea said:
For the terrain selection, have the current (or current + flood plains) "standard" mode, and have a check box that lets you change it to "advanced" mode. "Advanced" mode would let you specify colors for LM Desert, Tundra Forest, and pretty much any other land terrain possibility.

Also include an option to import BMPs with 256 colors instead of 16. This would allow having one color (or more) to every terrain... so if you had 40 colors you wanted, you could do it. To keep this from being overwhelming, the editor could ask how many of the 256 colors you were using. You'd then map those to terrains (or let the preset list fill them in, if added... it probably would be first if this option were), and the editor would ignore any other colors in its calculations (hopefully you'd have the BMP limited to however many colors you said were there to begin with).

The first part of the idea is more likely to happen, and more likely to happen sooner, than the second part; would that be a better alternative than just adding five more terrains? I'm hesitant to try to decide on a "best 16" terrains. Flood plains would be a shoo-in, probably plains forest, maybe tundra forest or snow-capped mountains. That would be 13 or 15, depending on the last two. But I'm not sure how much of a consensus can be reached, and 16 still seems somewhat arbitrary. I reckon it's also more difficult to decide on a "best 16" than a "best 12" (current + flood plains).
 
That is quite helpful.
Glad the notes are useful.

- I need to test this on a Mac again. The drop-down list blanking issue is one I haven't seen, and that may be because it's platform-dependent. At some point in the next few months I may be able to pick up a second-hand Mac laptop for testing.
If there's anything specific you want me to try let me know.

- The scroll bars appear to need more testing. I've seen them slightly squished, and I know a few places where they need to be finessed. I'm not sure I've seen them completely disappear.
I'll try to pay closer attention next time I'm in the program.


- I need to test this with GIMP 2.8.
Checking that one box meant that the editor could handle the bmp. It also meant that GraphicConverter could open it rather than seeing it as a corrupted file. Don't remember this ever being a problem before. There was some sort of team shake-up in the process of developing the latest version(s) of GIMP for OsX. Don't know if that means some non-standard implimentation. Like the default being the reverse of what it was in earlier versions.:dunno: In a weird way this may also be a platform-dependent problem.

- I probably could add flood plains, although it would be more difficult to add flood plains and rivers at the same time. Not necessarily impossible, but it'd require some playing around with to see if the results were helpful over flood plains without rivers.
In my map-making process I use flood-plains to mark the general course of rivers on the bmp. When fine tuning in the editor I can make more exacting choices about what tile edges to make rivers & where to replace floodplain with other terrains.


- I could probably add a preset color/terrain feature. It would certainly be nice - I did enough matching up colors and terrains in testing to see that.
A simple check box - so that if I'm adjusting & reimporting the same bmp the program already knows how I want the colors matched to terrain? This reminds me of another thing I noticed: To import the bmp need a random-map biq open. Once the bmp is imported it's no longer a random biq. Kind of complicates the process of reimporting.

If there's a limited set of terrain colors: Floodplains would be very useful. Distinguishing the 3 forests as well - maybe even more than floodplains. There certainly tend to be more of them on a map. A compromise between 3 forest colors & only one might be to add a color for pine forest. This is how the Firaxis editor handles it - but it doesn't have to determine a base terrain from the forest. Balthasar knows a lot more about how forests get handled by the editor/game than I do. His advice is worth seeking. Volcanos & snow-capped mountains I tend to place one by one so they're of less concern when importing a bmp.

Idea mentioned 256 v. 16 color bmps. BMP2BIC requires certain colors to be in the image but doesn't care about what's in the colormap beyond that. The current version of this importer doesn't care what the colors are but requires a specific number of colors. I'm curious about the reasons for choosing one method over the other.

I like the idea of a basic/advanced option for importing additional terrains. Especially once the additional landmarks are added.
 
Quick follow-up before I head out (may edit this post later): GIMP 2.8 updated their default .BMP format to a newer version, which is what tripped up the editor, and probably GraphicConverter as well. I've added a note to the version 0.84 post with the two easiest workarounds: that check box, or using GIMP 2.6 or earlier. I'll update the .bmp support at some point so the editor supports GIMP 2.8 bitmaps (might be 0.85 but I'm not sure how complex it will be to update).
 
Since you're including an image-to-map feature, I think it'd be very useful to have a map-to-image feature as well. Do you think that'd be feasible?
 
Spoiler Follow-Up for Blue Monkey and others interested :
If there's anything specific you want me to try let me know.

What you're doing now is great. The difficult part is that in cases like where the file-opener isn't working quite as expected, it's really difficult to figure out why without being able to test it on a Mac myself. Hence why I'm probably going to try to acquire a used one (though probably not until summer, with travel and other life plans).

In my map-making process I use flood-plains to mark the general course of rivers on the bmp. When fine tuning in the editor I can make more exacting choices about what tile edges to make rivers & where to replace floodplain with other terrains.

Makes sense. Flood plains will be one of the "regular" terrains in the next version.

A simple check box - so that if I'm adjusting & reimporting the same bmp the program already knows how I want the colors matched to terrain? This reminds me of another thing I noticed: To import the bmp need a random-map biq open. Once the bmp is imported it's no longer a random biq. Kind of complicates the process of reimporting.

Excellent point about the random-map requirement. That means I probably ought to first make it possible to undo the "Custom Map" option, and from there re-importing should be an easy addition. Some sort of remembering option will be added. I'm not sure whether it'll end up being per-BMP or overall.

If there's a limited set of terrain colors: Floodplains would be very useful. Distinguishing the 3 forests as well - maybe even more than floodplains. There certainly tend to be more of them on a map. A compromise between 3 forest colors & only one might be to add a color for pine forest. This is how the Firaxis editor handles it - but it doesn't have to determine a base terrain from the forest. Balthasar knows a lot more about how forests get handled by the editor/game than I do. His advice is worth seeking. Volcanos & snow-capped mountains I tend to place one by one so they're of less concern when importing a bmp.

I may end up doing floodplains, tundra forest, plain forest, and (grassland? tundra?) pine forest as regulars. It will likely take some time to gather opinions on what the "standard" as opposed to "advanced" terrains are.

Idea mentioned 256 v. 16 color bmps. BMP2BIC requires certain colors to be in the image but doesn't care about what's in the colormap beyond that. The current version of this importer doesn't care what the colors are but requires a specific number of colors. I'm curious about the reasons for choosing one method over the other.

In part because I hadn't thought of a good method to get around 256 colors being a lot of match up with terrains. The ability to specify how many you want used solves that (hopefully, depending on how GIMP saves the palette... with 16 colors, they aren't saved in the same order as the way you specify them in GIMP, or at least they weren't for me. which was why I added the RGB values).

The other main reason for starting with 16 was simplicity. It was easier both to program and to use initially with fewer colors. Likely to be less important was that 16-color bmps are half the size of 256-color bmps.

I like the idea of a basic/advanced option for importing additional terrains. Especially once the additional landmarks are added.

That is likely coming.


EDIT: The GIMP 2.8 issue is now fixed. Compatibility options will no longer be necessary in 0.85.

Since you're including an image-to-map feature, I think it'd be very useful to have a map-to-image feature as well. Do you think that'd be feasible?

Hmm... so you can get a big picture of the whole map? That'd be kind of cool. Off the top of my head, I think that would be feasible.
 
Since you're including an image-to-map feature, I think it'd be very useful to have a map-to-image feature as well. Do you think that'd be feasible?
Hmm... so you can get a big picture of the whole map? That'd be kind of cool. Off the top of my head, I think that would be feasible.
Like a screenshot for maps that are too big for a screenshot even with max zoom? Is that what you meant?
 
A big picture of the whole map? Yes. If I export a map, change *one* colour in GIMP or whatever image editing program, and import it again, I just might have changed all mountains into hills instead of painfulyl doing a tile-by-tile change. The same applies to rescaling maps. I can scale an image up by 25% instead of having to recalculate grid overlays and spending half the night working out exactly how many extra tiles of mountains there should be, etc. etc. I'll write more on this tomorrow, it's waaaay past midnight now.
 
Back
Top Bottom