DaDither - another one Img2Msx tool

Resident (38)

21-02-2023, 03:07

sd_snatcher wrote:

a) There seems to be a typo in the MSX Pixel Aspect ratio. It's being used as 1.104:1, when it should have been 1.14:1. But if you want to use 3 decimal places, then it should be 1.138:1.

I know I'm using the wrong PAR. I just don't know the correct value. How was the value 1.138:1 obtained? Ideally, I need a fraction of the form A/B.

sd_snatcher wrote:

Whenever the screen mode is changed, many of the conversion parameters are reset to their defaults: Dimension, Position, Pixel Aspect Ratio, Dithering Method, etc. Ideally, those should persist, as it makes easier to easily compare between the screen modes to choose which will yield better results. A "reset parameters to the defaults" menu option could be offered for when the user messed up with the settings too much.

It is difficult to implement due to the peculiarities of the internal architecture of the program. Maybe later.

sd_snatcher wrote:

when importing SRx+PLx images, it would be easier if all the available palettes were also automatically imported to the "Fixed Palette" combo-box of the converter window.

Ok, in the next release.

sd_snatcher wrote:

when importing SCx/MAG images, its embedded palette could also be automatically imported to the "Fixed Palette" combo-box of the converter window

Ok, in the next release.

sd_snatcher wrote:

Still on the image regeneration topic, similar to the way RGB colors are used to hide the color bleed on SCREEN10, on the SCREEN2/SCREEN4 the sprites were used for that. If I try to regenerate such images with DaDither, it chews the details on those parts.

Too difficult to implement. I don't know of any algorithms that can be used to use sprites in rendering an image.

sd_snatcher wrote:

Many dithering methods are offered, but their results don't differ that much between them. But one important dithering method for Pixel Art that's missing is the Ordered Dithering, AKA "checkerboard dithering".

Planned.

sd_snatcher wrote:

but also is limited to the TMS9928 palette, when this image has the V9938 palette.

Use Screen4 instead.

By sd_snatcher

Prophet (3659)

21-02-2023, 15:19

Dec wrote:

I know I'm using the wrong PAR. I just don't know the correct value. How was the value 1.138:1 obtained? Ideally, I need a fraction of the form A/B.

I's not easy to explain without a whole dedicated thread and a lot of time. But, in a nutshell, Pixel Aspect Ratios on SD CRT TVs are determined by two factors. To simplify the explanation, I will omit the interlaced feature and focus only on progressive frames, ok? I'll also mostly focus on NTSC, but you can infere the same occurs on PAL within its frame specs.

The frame rate (NTSC=~60Hz, PAL=50Hz), as it dictates the number of lines in a frame: 240p/60Hz for NTSC, 288p/50Hz for PAL
The Pixel clock

It's very important to keep in mind that the dueto of frame-rate and number of lines in a frame is fixed, and written on rock. There's nothing a computer or console could do to change it. Any deviation above the tolerance will cause the TV to loose sync.

OTOH, the horizontal resolution is an all you can eat buffet, since it's an analog device. The highest the clock rate, the more pixels you could theoretically cram into a single line. They even tried crazy resolutions like 1280x480i on some computers, but the truth is that anything above 720x480i would become way too blurry on the majority of consumer TVs.

As a consequence, to obtain the Pixel Aspect Ratio you need to calculate the whole formula based on the Frame Aspect Ratio, number of lines in a frame and Pixel Clock, discounting the border area. This was done in this thread.

But for your converter, all you need is a fraction, so for the MSX it comes down to this:

The ideal PVM monitor, perfectly calibrated, would issue 1.138:1, or 569/500
But consumer TVs had a lot of tolerances, so some variation around this is perfectly acceptable. Then you can use 1.14:1, or 8/7 to keep things simple

These numbers are for NTSC, that it's what's the system was designed for. The PAL versions of Japanese computer/consoles were mostly a cheap shoehorned "solution" that caused aspect ratio distortion and slowness.

By sd_snatcher

Prophet (3659)

21-02-2023, 15:13

It's nice to hear about the upcoming features for the next release. Thanks!

Dec wrote:

sd_snatcher wrote:

Whenever the screen mode is changed, many of the conversion parameters are reset to their defaults <snip>

It is difficult to implement due to the peculiarities of the internal architecture of the program. Maybe later.

Ok, no hurry. It's just a suggestion, and also it's your hobby.

Dec wrote:

sd_snatcher wrote:

<snip>...SCREEN2 images with sprites...

Too difficult to implement. I don't know of any algorithms that can be used to use sprites in rendering an image.

I agree that it's not easy. Maybe a similar algorithm to the one you used to decide between RGB or YJK colors, but with the additional restrictions of size of the sprite, max number of sprites per line and so on.

Definitely, it's something that would require a lot of careful thinking.

By Dec

Resident (38)

23-02-2023, 08:24

sd_snatcher wrote:

569/500

Thanks. Should I also use this value for TMS9918 and V9990?

By sd_snatcher

Prophet (3659)

23-02-2023, 12:11

Yes. But for the V9990, only for the resolutions that use dot-clocks multiple of 5.37MHz. You can check them at the page-14 of the V9990 datasheet.

I don't know what are the Pixel Aspect Ratios of the other dot-clocks of the V9990.

By Dec

Resident (38)

24-02-2023, 12:23

Updated.

sd_snatcher wrote:

it should be 1.138:1.

Fixed.

sd_snatcher wrote:

Whenever the screen mode is changed...

"Native dimension" button has double function now. When you click it, the width and height of the image are set to match the screen size, and the default PAR is set. But at the same time, the name of the button changes to "Image dimension", and the next click on the button will set the original dimensions of the image, and set PAR 1:1.

sd_snatcher wrote:

all the available palettes were also automatically imported

Three available options now: Import image, Import image and palette, Import palette.

Added creation of images in G9B format. The compression is not optimal yet, bmp2g9b.exe creates smaller files. But if this feature is useful for users, then I will try to rewrite a more optimal compression algorithm. (*Also looking for information about PAR of different modes of V9990.*)

By sd_snatcher

Prophet (3659)

25-02-2023, 14:27

Nice improvements! Thank you again for the constant evolution.

The support for the V9990 is also very welcome. BTW, the V9990 also has the BYJKP mode, that is equivalent to the SCREEN10 of the V9958. And the respective YUV version called BYUVP. Support for then will be very welcome, since AFAIK no conversion tool support them yet.

Oh! And it just occurred me that another system that would be great to support would be the SMS (Sega Master System). It's also very difficult to find conversion tools for this console.

By Dec

Resident (38)

25-02-2023, 15:59

sd_snatcher wrote:

V9990 also has the BYJKP mode

As I understand the G9B format does not currently support this mode.

sd_snatcher wrote:

SMS (Sega Master System)

Just point me to the documentation (and possibly a place/forum to discuss, since SMS is outside the scope of this forum).

By sd_snatcher

Prophet (3659)

25-02-2023, 19:20

The SMS is a cousin of the MSX2, so it's not considered a capital crime to speak about it here 😉. Many other threads already did it. There are even two cartridges that allow to run SMS games on the MSX: The Franky and its 2nd generation called Playsoniq.

You can find documentation about the SMS VDP here, here, and here

The documentation about the SBM file format can be found here, and you can find many SBM sample files ate the SMS section of RetroGallery.

By sd_snatcher

Prophet (3659)

07-05-2023, 02:20

I noticed a small bug when saving .MAG files: The comment field is being saved in the header where the Author name should have been (offset 0000Dh).

The text comment, when present, is inserted at the offset 00020.

Also, currently there's no field to type the Author name on DaDither.

The author field has the following requirements:

It starts at 0000Dh
It must be padded with spaces up to the offset 00020h
It must be cropped if it would go beyond 00020h
When no author name is typed, the default hexa string 3Eh,93h,E4h,3Ch must be used. (It means >謎< in shift_JIS)