ZX-Paintbrush 2.6.3 and ZX-Blockeditor 2.4.2 published

Dear readers,
as you see in the subject, two of my ZX-Modules applications have been updated today. The very special change, kindfully and very nice supported by BlackHole is a new TZX block type 4Bh, containing MSX data, MSX header or KCS data blocks. This making a new inofficial version 1.21 of TZX format. I must say, doing this, I felt a bit nervous thinking about the discussions we had about the 1.20 format.
The 1.21 format is fully downwards compatible to the older TZX versions. It follows the exception rule.

I will add the new block format in my file format description for TZX format as soon as possible.

Another important thing is the English language package that was missing in the previous ZX-Paintbrush version.

And last but not least Einar's wonderful NIRVANA+ wtile support in both programs.

It's clear that I have to update ZX-Editor, ZX-Preview and ZX-Explorer as well, but this must wait some more weeks, because of lot work.

Have fun.

There are no problems, only solutions (K. Flynn)

Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
Or visit my music-related website if you're interested in synthesizer music.

Comments

  • Hurray!!!

    Thank you :)
    Creator of ZXDB, BIFROST/NIRVANA, ZX7/RCS, etc. I don't frequent this forum anymore, please look for me elsewhere.
  • You are welcome. Hope that all works fine!

    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
  • Glad to see you back in business, Claus :)

    I'd like to comment upon a few issues that have been on my mind for a fairly long time now, if I may. Take the following as just my opinion. I realize this is probably a lot of work, so this is intended more as some points for you to consider/think over in the long run.
    That said, I do believe these points to be somewhat important from a conceptual standpoint.

    First of all, I think there should be one more palette option, distinct from the others: an option to adjust (what the editor considers to be) the default palette itself, used for displaying 'plain 6912 SCR' images in particular. This should be entirely unrelated to the whole ULA+ thing, and should not implicitly influence and/or change in any way the format of the actual image you're working on, nor what gets saved to disk (yes, the whole palette thing is a bit confusing if you ask me...).
    This should also be the palette used for exporting 'plain SCR' images to PC-image formats, like PNG.

    The second and more important problem is that all sorts of extended features/options that an image might use at any one time:
    - Extended palettes, ULA+
    - Attribute/multicolor modes: 8x1, 8x2, 8x4, 8x8
    - Timex multicolor format (which I suppose is somehow not the same as the 'regular and widely accepted' 8x1 multicolor format, provided one even exists for the Speccy..?)
    - And perhaps some other options of this sort that I might have overlooked

    should ideally all be consolidated into a single, clearly defined menu: 'Image format'. It is these exact settings that should decide:
    - Whether the extended palette control options are active or greyed out
    - Whether to warn about 'narrowing conversions' (for instance, switching from 8x2 to 8x4, or ULA+ -> regular SCR)
    - Which specialized file formats are available for saving

    And so on.

    Doing things like implicitly enabling some of these features, and/or switching the image to another mode just because the user has, for instance, edited some color in a palette is, in my opinion, a definite no-no.
  • Hikaru wrote: »
    First of all, I think there should be one more palette option, distinct from the others: an option to adjust (what the editor considers to be) the default palette itself, used for displaying 'plain 6912 SCR' images in particular. This should be entirely unrelated to the whole ULA+ thing, and should not implicitly influence and/or change in any way the format of the actual image you're working on, nor what gets saved to disk (yes, the whole palette thing is a bit confusing if you ask me...).
    This should also be the palette used for exporting 'plain SCR' images to PC-image formats, like PNG.

    I like this idea. It makes perfect sense and it's probably easy enough to do.

    We know there are no accurate values for ZX-Spectrum colors really, since the original palette is analog and the outcome varied depending on TVs. Not all emulators choose exactly the same values for instance. In particular, wikipedia seems to exaggerate the distinction between bright blue and non-bright blue:

    https://en.m.wikipedia.org/wiki/ZX_Spectrum_graphic_modes

    Therefore it makes sense to give each user the option to configure how they think best represents the original colors (i.e how it appears on screen and converts to PNG without affecting actual data in SCR, ZXP, etc).

    This feature would also help artists. It would be nice being able to exaggerate bright/non-bright distinction temporarily to help editing a regular SCR screen, then change it back again afterwards...

    Hikaru wrote: »
    The second and more important problem is that all sorts of extended features/options that an image might use at any one time:
    - Extended palettes, ULA+
    - Attribute/multicolor modes: 8x1, 8x2, 8x4, 8x8
    - Timex multicolor format (which I suppose is somehow not the same as the 'regular and widely accepted' 8x1 multicolor format, provided one even exists for the Speccy..?)
    - And perhaps some other options of this sort that I might have overlooked

    should ideally all be consolidated into a single, clearly defined menu: 'Image format'. It is these exact settings that should decide:
    - Whether the extended palette control options are active or greyed out
    - Whether to warn about 'narrowing conversions' (for instance, switching from 8x2 to 8x4, or ULA+ -> regular SCR)
    - Which specialized file formats are available for saving

    And so on.

    Doing things like implicitly enabling some of these features, and/or switching the image to another mode just because the user has, for instance, edited some color in a palette is, in my opinion, a definite no-no.

    I disagree.

    Not sure about ULA+ options since I never used them. However I have used multicolor options extensively, they are intuitive and work perfectly.
    Creator of ZXDB, BIFROST/NIRVANA, ZX7/RCS, etc. I don't frequent this forum anymore, please look for me elsewhere.
  • Hikaru wrote: »
    - Timex multicolor format (which I suppose is somehow not the same as the 'regular and widely accepted' 8x1 multicolor format, provided one even exists for the Speccy..?

    There are 3 established file formats for multicolor 8x1:
    * MLT (bitmap pixels in non-linear order, attributes in linear order)
    * SCR (bitmap pixels in non-linear order, attributes in non-linear order)
    * CTILE (bitmap pixels and attributes grouped in 16x16 pixels tiles)

    The "non-linear" order means the byte order that Speccy stores bitmap pixels in memory, and also that Timex 8x1 stores both bitmap pixels and attributes in memory.
    Creator of ZXDB, BIFROST/NIRVANA, ZX7/RCS, etc. I don't frequent this forum anymore, please look for me elsewhere.
  • Hikaru wrote: »
    The second and more important problem is that all sorts of extended features/options that an image might use at any one time:
    - Extended palettes, ULA+
    - Attribute/multicolor modes: 8x1, 8x2, 8x4, 8x8
    - Timex multicolor format (which I suppose is somehow not the same as the 'regular and widely accepted' 8x1 multicolor format, provided one even exists for the Speccy..?)
    - And perhaps some other options of this sort that I might have overlooked

    should ideally all be consolidated into a single, clearly defined menu: 'Image format'. It is these exact settings that should decide:
    - Whether the extended palette control options are active or greyed out
    - Whether to warn about 'narrowing conversions' (for instance, switching from 8x2 to 8x4, or ULA+ -> regular SCR)
    - Which specialized file formats are available for saving

    And so on.

    Doing things like implicitly enabling some of these features, and/or switching the image to another mode just because the user has, for instance, edited some color in a palette is, in my opinion, a definite no-no.

    I disagree.

    Not sure about ULA+ options since I never used them. However I have used multicolor options extensively, they are intuitive and work perfectly.

    This is not a critique on the usefulness of any particular options themselves.

    It makes logical sense for options pertaining to the image format, of which the attribute mode selector is one, to be consolidated in a single menu where they can all be easily found. This should ideally include an explicit ULA+/extended palettes feature on/off switch as well (there isn't one at present, I believe). In my opinion, there's exactly zero reasons to keep stuff like that separated and disjointed, much less as independent 'front panel icon' sorta things that you can show/hide/move all over the place at will. I'd say that the consolidated image format menu option shouldn't be a 'front panel icon' either, but rather located in one of the drop-down menus like the proper 'system' option it is, although this is perhaps a matter of preference
  • Hikaru wrote: »

    First of all, I think there should be one more palette option, distinct from the others: an option to adjust (what the editor considers to be) the default palette itself, used for displaying 'plain 6912 SCR' images in particular. This should be entirely unrelated to the whole ULA+ thing, and should not implicitly influence and/or change in any way the format of the actual image you're working on, nor what gets saved to disk (yes, the whole palette thing is a bit confusing if you ask me...).
    This should also be the palette used for exporting 'plain SCR' images to PC-image formats, like PNG.

    Obviously, you are talking about the need of a direct access to ZX-Paintbrush's internal color table, used for screen display, as well as for storing BMP, JPG and PNG pictures.

    Indeed we already have this:

    Try Colors -> Full color palette -> Edit full color palette.

    Changing these colors, you have direct access in ZX-Paintbrush's internal palette. The only thing is that you have to save the changed palette to a .pal file and load it back in your later ZX-Paintbrush session.
    If you want ZX-P automatically remembers the last colour setting, simply enable the switch "remember colour settings for later sessions" in options dialog, section colours.

    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
  • Awesome! :)
    Creator of ZXDB, BIFROST/NIRVANA, ZX7/RCS, etc. I don't frequent this forum anymore, please look for me elsewhere.
  • clausjahn wrote: »
    Hikaru wrote: »

    First of all, I think there should be one more palette option, distinct from the others: an option to adjust (what the editor considers to be) the default palette itself, used for displaying 'plain 6912 SCR' images in particular. This should be entirely unrelated to the whole ULA+ thing, and should not implicitly influence and/or change in any way the format of the actual image you're working on, nor what gets saved to disk (yes, the whole palette thing is a bit confusing if you ask me...).
    This should also be the palette used for exporting 'plain SCR' images to PC-image formats, like PNG.

    Obviously, you are talking about the need of a direct access to ZX-Paintbrush's internal color table, used for screen display, as well as for storing BMP, JPG and PNG pictures.

    Indeed we already have this:

    Try Colors -> Full color palette -> Edit full color palette.

    Changing these colors, you have direct access in ZX-Paintbrush's internal palette. The only thing is that you have to save the changed palette to a .pal file and load it back in your later ZX-Paintbrush session.
    If you want ZX-P automatically remembers the last colour setting, simply enable the switch "remember colour settings for later sessions" in options dialog, section colours.

    Actually, that was my first impression as to what this option (probably) did. However, it seems that either I misunderstand its use, or it doesn't quite work as intended, or both.

    One weird behavior can be reproduced like this:

    1. Download this archive.
    2. Enable 'remember colour settings for later sessions'.
    3. Reset the palettes to default values.
    4. Select palette 0 and load zxpaintbrush_pulsar.pal as a 'full color palette'.
    5. Open the image file test.tap. At this point, the colors reset to default values by themselves (?).
    6. Load zxpaintbrush_pulsar.pal again.
    7. Modify the image and try to save the file back. A message 'Not all blocks could be saved' appears. If you open the block editor, there's an additional ULAPlus block included after the image data (?).

    Similar things happen if the .PAL file is loaded into palettes 1-3. In this case, the colors do not reset anymore when a new image file is opened in step 5, but the error message and the ULAPlus block from step 7 are still there.

    An even more interesting thing can be observed if the image is saved as a .ZXP file in step 7 instead. Close and reopen the editor, and open the .ZXP file again. The blue color in CLUTs 0 and 1 in Palette 0 seem to reset to the same values, and the ULAPlus feature seems to be enabled (a colored '0123' menu appears in place of the bright/nonbright selector).

    Hopefully you can shed some light on what's going on... :)
  • I will check this, thanks for your detailed bug teport.

    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
  • As it's a long time delay when I made these colour things, I can conclude the appearing effects without checking the program (I will do this this weekend):

    1. If the user edits/loads a so-called "full colour palette", this should not create an ula+ datablock on a tape file that is in memory. It ZX-P does it this way, there is definitely an unwanted issue.

    The reset of the full colour palette when loading another tape was intended so far, but I must agree: Makes sense only if we would ensure the games etc. work with normal colours after loading rather than modified colours.
    This bug/feature could be disabled of course, because full colours should be stable during a full session, or permanently if the above mentioned remember switch is enabled.

    Having in mind that changes on the full colour palette should in no way take effect to SCR/ZXP files, nor the data in clipboard (e.g. copying an image from one ZX-P to another).

    The ULA+ feature should override the colour setting of the full colour palette, because it has its own colours to be displayed. But after closing an ula+ file or loading another tape, the full colour palette should be visible again.

    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
  • Glad to see that we agree on most accounts, as that was the biggest point of confusion for me regarding this palette feature. :) Thanks in advance for looking into it.
  • Hikaru wrote: »
    The second and more important problem is that all sorts of extended features/options that an image might use at any one time:
    - Extended palettes, ULA+
    - Attribute/multicolor modes: 8x1, 8x2, 8x4, 8x8
    - Timex multicolor format (which I suppose is somehow not the same as the 'regular and widely accepted' 8x1 multicolor format, provided one even exists for the Speccy..?)
    - And perhaps some other options of this sort that I might have overlooked

    should ideally all be consolidated into a single, clearly defined menu: 'Image format'. It is these exact settings that should decide:
    - Whether the extended palette control options are active or greyed out
    - Whether to warn about 'narrowing conversions' (for instance, switching from 8x2 to 8x4, or ULA+ -> regular SCR)
    - Which specialized file formats are available for saving

    And so on.

    Doing things like implicitly enabling some of these features, and/or switching the image to another mode just because the user has, for instance, edited some color in a palette is, in my opinion, a definite no-no.

    i must say that I myself was a bit confused about the many spread options around with attribute heights.
    I considered your suggestions above and even if I have not yet checked the code, usually it should no problem to generate an additional dialog that contains copies of all these icons having to do with colours. Also, a list what file formats can be saved as is already internally present.

    I don't want to make too many promises at this time, but the idea is good and an additional dialog, reachable with the 'tools' main menu option should not disturb anyone.

    Well, let me check this, too.
    My first thought is that this should be easily done...


    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
    Thanked by 1Hikaru
  • What more can I say. This is very good news for me. xD Looking forward to it!
  • Hikaru wrote: »
    Glad to see that we agree on most accounts, as that was the biggest point of confusion for me regarding this palette feature. :) Thanks in advance for looking into it.

    I definitely indicated the arising ula+ block on an opened SCR file as a real big bug! So thanks for repeating. I will fix this soon.
    I decided also a rename of some menu points handling palettes. "full colour palette" should better say "internal palette" or so. The four palette 0..3 options that are used for Clut 0..3 of a ULA+ palette should say "ula+ clut 0" to "ula+ clut 3", otherwise the naming interferes with the 4 internal palette switches.

    I will either remove the automatic ZX-Spectrum palette activation when
    loading another tape file, or it will
    be handled with a (by default disabled) switch in the options menu.



    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
  • Hikaru wrote: »
    Glad to see that we agree on most accounts, as that was the biggest point of confusion for me regarding this palette feature. :) Thanks in advance for looking into it.

    I want to continue that colour palette and ula+ palette feature in a new thread.

    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
  • Hi Claus, I noticed a possible bug. You are able to select BRIGHT 0 and FLASH 0 and 1, and BRIGHT 1 and FLASH 0 at the same time, but if you try to select BRIGHT 1 and FLASH 1, the BRIGHT button reverts to 0.
  • @clausjahn

    I just want to say a huge thanks Claus!

    NP_RPG_DC_001.png
    Just something I have been working on ;)
  • Hi Claus, I noticed a possible bug. You are able to select BRIGHT 0 and FLASH 0 and 1, and BRIGHT 1 and FLASH 0 at the same time, but if you try to select BRIGHT 1 and FLASH 1, the BRIGHT button reverts to 0.

    Okay, I will take a closer look at this, too.

    I need more time, as the palette activities are more difficult than imagined.

    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
  • Zetr0 wrote: »
    @clausjahn

    I just want to say a huge thanks Claus!

    NP_RPG_DC_001.png
    Just something I have been working on ;)

    you are welcome!
    Besides: Very nice pictrure / game screen!

    There are no problems, only solutions (K. Flynn)

    Visit my ZX-Modules homepage with lot of free programs, also VU3D-Animator!
    Or visit my music-related website if you're interested in synthesizer music.
  • @Claus

    That's very kind to say, thank you!

    I have spent many hours over the last year with ZX Paintbrush and its really REALLY impressive - I look forward to sharing what I have been up to but I want to say that none of this would of been possible without your program!

    I look forward to catching some time this year and maybe a "how to guide" on youtube.
Sign In or Register to comment.