What's unknown for now is if .bmpload uses the default RRRGGGBB palette, or builds a new one with selected tints for the 9 bits RRRGGGBBB full palette upon loading.
If it's the latter, then it should already select the closest colours when converting the 24 bits tints in the bmp file into the ZX Next colours.
If it's the former... Then there's nothing that can be done, apart from pre-reading the BMP palette, converting the colours yourself, set the result as a new 256 colour palette, then load the picture using .bmpload...
... So in the end, it'll probably be simpler to rewrite a new DOT command from scratch, able to recognize and automatically adapt to 256x192, 320x256, 512x192 and 640x256 modes, center smaller pictures with a black border, and possibly automatically crop the larger ones... :p
Another solution would be to pre-convert bmp pictures into nxi... I've used one of the first available tool, nextbmp.exe, but the result was awful, and I think it stemmed from using only the default RRRGGGBB palette.
If there are better conversion tools around and/or update, plese tell me what the best ones are. For now, I'll stick with the bmp format, because .bmpload's automatic conversion is giving the best results so far.
Note that what I just replied was only to clarify the actual problem's nature.
Of course ZXPiixelPaste should allow to access the full 9 bits colours range and generate a relevant 8 bits palette out of the selected ones, which is great.
I suppose the nxi loader will create the correct palette in turn from the data in the nxi file... At least each colours should be converted into 8 bit indexes, unlike BMP files that stay coded in 24 bits despite simply limitating the number of colours to 256. :p
The bmp format, howevern is quite user friendly. Every important information such as the picture dimension and palette length are stored at fixed locations in the file, the palette comes first, then the pixels, and special filler bytes are used for odd numbers of pixels, so the internal layout is quite simple and straightforward.
A universal (I mean for other resolutions than Layer 2,1 only) bmp loader project can actually be written in Next BASIC using its powerful file manipulation commands allowing to extract any block of bytes from any file. :)
In fact, until I've managed to understand how they're called from machine code, it will be simpler to use them from Next BASIC to parse the file header and load the data, before passing the actual conversion and display work to machine code... ^_^
