all the textures are saved as hmp skins, and the last 4 ones are assigned as the 4 material skins on terrain creation (material bmap pointers to entity skins).
I just tried to modify the full texture atlas. they are tga textures. if it will work fine, I think I replace the old dll with yours.
as I remember performance is slightly better when dds textures are used, but they can be converted for the game. currently I have a secondary option to save a terrain texture package (and a terrain lighmap texture) for each level as a set of separate tga files.

I have tested with

bmap_createpart
bmap_createblack
bmap_blitpart

with non square sizes , to try and duplicate your problem when you said it doesn't save non square skins .

but all of those saved them out , however they are filled with black to make them powers of 2, by the engine when applied as a texture skin , that's the only thing I can think of now ,that bears any kind of similarities with your problem , because I am stil not sure what functions your using so that I can try and duplicate the problem .

edit :
let me look in to this a bit more

unfortunately I cannot give a simple answer as in MapBuilder I use different configurations for single skin + detail map terrains, and for multitexturing where blending is stored in the alpha channel. if you are patient enough and want to read a lot, it is within MBteredit_tx.h/.c and MBterrhmp.h/.c. later I'm planning to upload it to GitHub, it would be easier to discuss.

so it is okay now, this mipmap thingie at least fixed some other issues and I can change my shaders to use square atlas maps. currently I'm mostly using an autotexturing shader, which is much better for using with many levels than to save skins to every hmp-s (and I frequently use the same hmp for many levels beside a deformation info file), thus imo it is better if you don't invest too much time into my problem at the moment. and I'm not sure how much I will work with 3dgs in future... the dll basically works fine beside this limitation.

I found this in the manual under bmap_lock

After locking an uncompressed bitmap, you can access its texture content directly through the bmap.finalbits pointer. The texture size (in bytes) is given through (mybmap.finalwidth * mybmap.finalheight * bmap.finalbytespp). The texture size is normally a power of 2 and not identical to the original image size returned by bmap_width and bmap_height.


I just had to know why and what goes wrong

okay, I thought you won't sleep until it is resolved

basically everything works fine with non-square (but power of 2) sized skin textures, except saving. I can make some further tests, unfortunately no much time because of job, and no time at weekend because of family. I can do them probably only next week.

Is there a way to share the dll again? I know a year has passed - but I would love to play around with this.

Thanks.

wikisend.com/download/829782/save_hmp.dll

@Wjbender
Thank you for your quick reply =)