DOS ain't dead

> Thank you! Does Allegro support 32-bit VESA modes? If so, may I suggest
> making 640x480x32 the default viewing mode instead, as modern cards and
> built-in video BIOSes of modern systems don't even support the 640x480x24
> mode (no entry in it for the VESA modes in the vBIOS).

Try the "-b" flag as stated by the documentation. That switches to 32bpp...

And I might make that the default, yes...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> I would like you to also offer the compiled executable program for ms-dos
> (dosview.exe)

uhm, it is right there, on the releases page?
https://github.com/SuperIlu/DosView/releases

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> * Under DOSBoX-X, it requires -b to work
I'll add autodetection to the next version...

> * Large images might be better shown scalled down to the size of the
> viewable area. Scrolling the image up and down is rather slow under
> emulator.
try "Z" and "F" to switch between scaled and full size view

> * An info line with some basic information about images might be useful.
> Or, alternatively, the info about the image might be shown under text mode
> after exit.
I'll check what I can do...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> Fantastic work! Thank you.
> Maybe could be changed the image conversion mode. In this mode is no need
> to check whether video card supports 24bpp or 32bpp. It shall just convert
> it without trying to activate or check any videomode.
I don't know if allegro supports image read/write w/o a video mode, I'll check

> It would be also good to have an option how to force the input image
> format.
sorry, this is not easily supported by allegro. the 'detection' is purely based on the extension...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

"old" dosview.exe version v1.0 = 911872 bytes

Dosview.exe version v1.1 = 1480192 bytes
( https://github.com/SuperIlu/DosView/releases/download/v1.1/dosview-1.1.zip )

But... with latest UPX and "--ultra-brute"
( https://github.com/upx/upx/releases/download/v4.2.1/upx-4.2.1-dos.zip )

=> dosview.exe version v1.1 = 591164 bytes !!!


In my first tests, I have problems with num pad keys

> I just released an improved version v1.1
>
> https://github.com/SuperIlu/DosView/releases/tag/v1.1
>
> * added TIFF
> * added JPEG 2000
> * fixed zoom and documentation
> * added 24/32bpp autodetection
> * added image info
> * added num pad keys
> * added check to list modes
Many thanks for all the new options.

Now, both arrow keys and number keys work well for me verses v. 1.0. And, the 8x speed option to move around in the image is very nice indeed.

One other minor point: it appears the -q option is somehow not uniform. It is not linear, at any rate. For .jp2 writing, it appears that anything from -q 50 to -q 100 will write a *lossless* image. -q 1 to -q 49 writes some sort of lossy image with .JP2, but it is not granular. I suggest to change the *default* -q to -q 100 which would be lossless for all three formats: .JPG, .JP2, and .WEB. I know lossless .JPG is a thing, even though it's seldom used.

The -q option for .JPG and .WEB is confusingly more granular than than with .JP2. For JPG and WEB it behaves as you'd expect (ie, -q 5 is a very poor lossy compression, while -q 95 is a very good lossy compression).

If you prefer to keep default -q at -q 95, then write lossy .JP2 by default. It'll avoid confusion. But, personally, I prefer the -q 100 as a pure lossless default to write only lossless images.

I think it would be good if the program supports the "GIF" graphic format.

And with lower priority, it also supports the graphic formats RLE, CDR, PIC, IMG and CLP.

> As per request:
> * added GIF
...
> * added an UPX compressed EXE
> * enabled dithering
> * added 8bpp display mode

Great Are arithmetic coding for JPG and all fancy algorithms of TIFF already supported? Or various exotic styles of PCX and BMP?

Thanks for DosView! Eric

---
FreeDOS / DOSEMU2 / ...

> As per request:
> * added GIF
> * added PSD
> * added HDR
> * added PIC
> * added an UPX compressed EXE
> * enabled dithering
> * added 8bpp display mode
> * fixed another scaling error
> * fixed error when reading certain PNGs
Getting better and better with all of these new features, especially scaling. How could we have forgotten .GIF? Glad to see the support of this legacy format. I also request the old .RLE compression format if easy to implement.

Incidently, is the dithering you're doing nearest color, neural net, diffusion-based, or some other algorithm? There are many different types of 24 bit --> 8 bit dithering.

Again, thanks for putting together DosView; it fills a great niche.

> As per request:
> * added GIF
> * added PSD
> * added HDR
> * added PIC
> * added an UPX compressed EXE
> * enabled dithering
> * added 8bpp display mode
> * fixed another scaling error
> * fixed error when reading certain PNGs


Congratulations!!! This new version exceeds our expectations

> I fixed the zooming bug (hopefully) and I added some more screen
> resolutions to the list. That did change the command line arguments a
> little...
>
> https://github.com/SuperIlu/DosView/releases/tag/v1.4
Thank you. All appears perfect. I'm not seeing any zoom bugs or wrong aspect ratios, especially now that I can display images in my monitor's native resolution of 1920x1080. Do you specifically have any images to test which previously exhibited the AR bug you spoke of?

Thanks for the hint that you are hard-coding of resolutions. I found where in the executable these are hardcoded, and modified some of them to oddball resolutions for my own use (like 720x480, 1024x600, 1366x768, 2048x1536, 1920x1440, etc) that likely won't be useful for anybody else. Every laptop that I have has different VESA resolutions. Video BIOSes have different VESA tables as well... with many strange resolutions beyond the "standard" 4:3 ones.

Until you can automatically detect all VESA resolutions on any given specific machine / vBIOS, and make them available "on the fly" in DOSVIEW, my kludge method of modifying directly the offsets in the DOSVIEW binary works for the outlier oddball resolutions when I need them...

Just a short info:
Qemu now works fine now, but virtualbox and VMWare still have the problems described above. I used the same pictures over all machines.

> I was finally able to add VESA mode autodetection. There was a small error
> in the Allegro library and now ALL* available VESA modes can be selected
> using "-r"
>
> https://github.com/SuperIlu/DosView/releases/tag/v1.5
>
>
> (*) Well, all Allegro modes larger than 320x200. I filtered out all the
> weird stuff below...
Wow, that was fast. In "autodetection" mode, my available modes suddenly went up to 34 on my main laptop. Some of these are really weird (like 360x200 or 640x272) - not all of them work. But, it's great to have the options! Glad you got autodetection working in Allegro.

Incidently, I'm testing only on real bare metal DOS machines. This should be the acid test. Emulators and simulators should be secondary. If they work, all the better...