Thanks a lot for addressing a cruel lack in NextZXOS !
I had first tried using the early versions of Calm Commander years ago, and it messed up the destination, so I was out of solutions.
I guess it's all fixed and operational in Calm Commander now ? A few weeks ago, you started to indicate multiple files selection was now working, but I was unsure about whole folders and subfolders, I'm happy you can now, meaning Calm Commander will become very useful. :)
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... ^_^
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.
Well, yes. That would be terrific.
- No more attribute clash, nor a second memory area to cope with.
- 1 byte per pixel. More memory to move around, but the DMA could help, and pixels locations easier to calculate (3 or 5 banks of 16k RAM laid out horizontally (256x192) or vertically (320x256), all in order without interlacing. 256 colours palette from 512 colours RRRGGGBBB. No memory contention. Textures possible, as well as more lighting gradients than just "dark or bright"... :p
- Counter not necessary, the Copper can be used to synchronize with the raster. Z80 CTC timers onboard, providing interrupt vectors for true IM2 management if needed.
- Multi-layers possible with transpacency, logical "and" mode, etc.
- Hardware sprites available. Would maybe change the principles a lot from an original Spectrum, though...
- Possibility to run at 3.5, 7, 14 or 28 MHz.
It's true the programming techniques would probably differ a lot because using more colourful objects would mean having to rely more on the new hardware to compensate. But it would result into more readable and aesthetic effects...
However, the optimized maths would still be very useful. It would allow more complexity without sacrificing fps. :)
Hi Leonid, here's a link to Miroslav's picture converted to 256 colours BMP...
It can actually fit into 256x192 so it can be directly opened and displayed from the Next Browser. :)
To center it properly, though, I've shortened the girl's finger by one pixel, as it was weirdly long... Though it was more obvious when zooming the picture. It feels more natural like this, but of course, the original is fine too (since it fits into 256x192 layer 2,1 it should be unconspicuous with BORDER 0 :p ).
https://www.mediafire.com/file/r2l6e1pytzlsm05/Miroslav_Bursa_1_256x192.bmp/file
Note there's no visible difference despite converting from 446 distinct colours to 255. This says lots about the ZX Next's 512 colours palette that actually contains some colours that are quite undistinguishable from one another, so I'm still trying to build a complete 256 colours palette with all the useful colours from the 9 bits full palette.
Chances are there might be less than 256 really different colours in the end (at least the human eye can distinguish). Maybe there'll only be 240-ish of them ? Which isn't necessarily a bad thing, as putting a few redundancies in the palette could help when switching from 256/320 to 512/640 pixels wide modes, as the 16 first entries are automatically used by default, and could be populated with 16 or 15 useful tints, and room for transparency.
My goal is to build a "standard" 256 colours palette using all the useful colours out of the available 512, in order to replace the unsatisfying R3-G3-B2 default palette and never worry anymore about choices. :D
In particular, the 3-3-2 palette only contains 4 greys (including full black and full white) out of the possible 8 hues, lacks lots of tans, browns, etc. and contains a useless excess of greens, limes, purples and pinks, lots of them looking completely identical.
For instance, there's absolutely no visible difference in the picture here when going from 446 to 255 separate colours. Of course the BMP is still encoded into 24 bits colours, but the Next's bmpload DOT command will automatically select the closest colours from the palette. What I don't know, though, is if it choses them from the full 9 bits palette or from the simplified default 8 bits palette.
What's obvious is some slight changes may become more apparent onscreen. That's why I'm working on my own BMP to Layer 2 loading and conversion tool, also to cope with 320x256, 512x192 and 640x256 modes, and why I need a complete 256 out of 512 colours palette, and to generate a relevant16 colours palette for the high resolution modes (though understanding Layer 3 might be a much better answer here).
OK, so different MAME sites provide different zipped packages.
So far, I've encountered 4 different versions :
1 - The one given in the zx-dev forum leads to a "merged" version containing various subfolders with additional files that could belong to some variants, according to the folders names (MegaForce, MegaForce US, etc.). Nexprep absolutely doesn't like them. :p
2 - A "simple" one, with just a 07b.bin file and 4k, 8k and 16 data blocks named 1.xxxx to 18.xxxx, where xxxx are 1 or 2 digits numbers followed by letters ;
3 - The same one, with an additional small html file containing a short message from the guy who hosted it. After removing the html file from the archive, a comparison found it 100% identical to the one just above, so I discarded it. I didn't try to use it with the html file inside.
4 - A very different one, still containing the 07b.bin file, plus 4k, 8k and 16k data blocks named starforc.1 to starforc.18
Since I had an error -1 with the first one, I tried with the second one, and this time, it worked !
I also tried with the 4th one and it worked as well ! A comparison of the resulting starforc.nex files found them 100% identical.
So the 2nd and 4th kinds are the ones to go for. Check the archive contents before trying to build the game. The simpler the better.
HTH. :)
Yes, it's obviously using full screen 320x254 Layer 2 graphics for the background picture and Tilemap for the rulers (all of which overflowing to where the border is located in classic 256x192 ULA display), so emulators have to take the latest developments in account (and they're almost 2 years old now !)
BTW, emulators developper would be nice stopping using only the rubber keyboard 40 keys. Since they all run on computers or smartphones It shouldn't be that difficult to implement at least the cursor keys and the backspace key, right ?
Especially on smartphones where the keyboard is usually displayed by the emulator. More than 35 years later, is it still so difficult to display a Spectrum + keyboard ?
