Exporting issue

Dahak

As a follow-on to my Larger Export Files subject (and I don't see a dedicated Goblin section), I now have an issue running the script.

I now have a simple test script to export the loaded map to a JPG file.

At a width of 4000 pixels, it works. beyond, it fails.

The simple script:

expWidth = 5000
oDest = "c:\temp\apiexport.jpg"
oMap = GetCurrentMap()
oMap.SaveToGraphic oDest, expWidth, 0, 0, oMap.Width, oMap.Height

MsgBox ( "Image saved to " + oDest )

This fails with a VBScript error.

EOutOfResources: Not enough storage is available to process this command.

The same error occurs when I use the FM8 export function to export to JPG format.

Any thoughts?

(Running Windows XP, 3GB RAM, and the trial version of FM8).

Ed_NBOS

Thats probably the maximum size of a bitmap your video drivers will create. What you can do is tile the images, exporting them in sections and then stitch them back together with some other graphics tool.

Dahak

Ed_NBOS wrote:

Thats probably the maximum size of a bitmap your video drivers will create. What you can do is tile the images, exporting them in sections and then stitch them back together with some other graphics tool.

That's weird. I wouldn't have expected the file-generation to be dependent on the video driver. Rendering, yes, generation, no.

I sent two versions of the script to my friend with the full version and he was able to generate the 5000-pixel image, where I maxed out at 4000-pixels.

I've just now sent him 7500/10000/15000-pixel versions and will see what kind of feedback I get from him.

If it pans out, I'll dig through the API docs for more features.

Are there any demonstrations in the sample files on prompting with a dropdown select box and/or input box for file-extension and dimension input? Or a file-prompter dialog to select the output directory and file name?

Thanks for all of your help.

Ed_NBOS

That's weird. I wouldn't have expected the file-generation to be dependent on the video driver. Rendering, yes, generation, no.

It's not wierd. The problem is occurring during rendering, when allocating the large in-memory bitmap used for rendering the requested graphic, not on the actual creation of the jpeg files. The actual maximum size that can be allotted differs on each machine.

Dahak

Ed_NBOS wrote:

That's weird. I wouldn't have expected the file-generation to be dependent on the video driver. Rendering, yes, generation, no.

It's not wierd. The problem is occurring during rendering, when allocating the large in-memory bitmap used for rendering the requested graphic, not on the actual creation of the jpeg files. The actual maximum size that can be allotted differs on each machine.

Thanks.

I wasn't thinking in terms of it using video memory when doing the internal rendering.

My friend must have one heck of a video card, if he's generating files four times the width of mine. (Granted, my card is a little long in the tooth.)

I'll probably be having a few more API questions to go along with my other thread (like converting the screen corners to map-coordinates to output a section of a map, instead of the whole map, I do now).

My friend has also tossed out a request for Fractal World Explorer, but my brief foray into that suggests that it's not as flexible as FM8.

Dahak

Ed_NBOS wrote:

It's not wierd. The problem is occurring during rendering, when allocating the large in-memory bitmap used for rendering the requested graphic, not on the actual creation of the jpeg files. The actual maximum size that can be allotted differs on each machine.

More of an FYI, than anything else...

After getting my API-based export plugin running and taking one of your earlier suggestions about tiling the output, I've run into an odd edge-effect issue on the tiles.

Often, when I build tile sets, text boxes don't render across the tile borders. This doesn't seem to be an issue with horizontal text boxes, but I see it often enough with slanted text boxes.

For example, from my friend's world-map:

The white horizontal line represents the tile seam and the angled white lines represent the rough baseline of the angled text boxes.

Roughly the same region from a lower resolution tile set:

At a guess, when FM8 renders the export block (in this case, it was generating a 7x7 tile set of the world map with 3500-pixel-wide tiles yielding a 24500x12236-pixel final file that I stitched together with ImageMagick) it internally decided that the angled text boxes fell outside the region of interest, when it really should have included part of them.

I don't know how you internally mark the positions of the text boxes, but if you do so by the box's center, then I can see how that could happen, but I think it should really determine the full-extent for the text-box, rather than estimating based on its centroid.