Now it seems the progress bar is properly cleared when a new file is opened, and compressing multiple files in a single session (without closing and re-opening) VDCompress works.
But still, if you could compile a 32-bit EXE, it would be much appreciated. Besides myself, I know several people using 32-bit versions of Win Vista or Win 7. I don't care about Win 8... from all accounts it sucks as bad as Vista. Are you sure you would like to XXX ? God I hate that OS. I'm not sure about the newest version of Visual BASIC, but in Visual C you just go to Project... Settings... and on one of the tabs there a selection for Win32 / Win64 target. In theory there could be other targets (Win16?) but because M$ doesn't care about comptability, I am 99.9999% sure you won't find Win16... mainly because modern (64-bit) versions will cry like a baby if it discovers a 16-bit app. Ironically, your program is a great example of a program that should/could/would run just fine in 16-bit! Enough about M$
Below are several files I compressed. I show "web-friendly" images which SHOULD represent what you see on a real C128. On a few images (like Risen From Oblivion) I was not sure about the aspect ratio, so it might not be correct (I snagged the image from CSDb). The important thing is the actual VDC files (using Dirk Vrooman's header) will display on your C128, if you can find a stand-alone program to view them. As I understand, Mirkosoft's ACE operating system supports these files... but I am not aware of a stand-alone viewer (sorry). Another alternative would be Tokra's VDC Mode mania viewer (and associated converters by Mike Kircher), however they are VERY strict about image size and format... because my sample images come in a variety of sizes, this was not possible.
So I think the results are very interesting. First I provide a brief summary in a table (for all you folks in a hurry)...
Orig Size (bytes)
Compress Size (bytes)
Risen From Oblvion
In case it isn't obvious, all the "real" images took quite a long time (for a computer) of around 25 seconds, and they had very low compression (about 15% or less). The compression size is (should be) the same on any PC... of course the time may vary. For reference, I timed the compression on a 64-bit Intel P6200 running at 2.17GHz.
On the other hand, all the "CG" (computer-generated) images compressed very fast (less than 5 seconds) and had very high compression (over 75%).
So I think you will agree, the original version of VDCompress is very good with CG images (games, etc.) but not good with "real" photos. Even with "real" images, it does not create files larger than the original (the opposite of compression... inflation!). So it ain't perfect, but it never hurts. That's a winner in my book.
Below are "web-friendly" versions of the images I tested. Hopefully it will be obvious which are computer-generated (CG) and which are derived from real images. If in doubt, refer to the table above!
Jatte: 640x252 pixels @ 8x2 color = 7.25% compression (BAD)
Lena: 512x512 pixels @ 8x2 color = 8.70% compression (BAD)
Risen From Oblivion: 640x200 @ 8x2 color = 90.4% compression (GOOD)
Terminator 3: 640x252 @ 8x2 color = 8.37% compression (BAD)
Toxic: 640x168 @ 8x2 color = 16.4% compression (BAD)
Hopefully (if your web browser is compatible with mine) then all images (except "Lena") will have the same width (640 pixels). "Lena" is a square image of 512x512 (in theory) but only 512x256 in reality (to avoid complexities of Interlace).
Last Edit: Aug 30, 2014 10:09:23 GMT by hydrophilic: Updated images and their description
Yeah, its pretty crappy that one version won't let you choose between 32 and 64 bit targets. But thanks for putting in that extra effort!
The RLE/Copy (byte-oriented) scheme used by your software, and others (GeoPaint, iPaint, and my own CBM Encoder) works best with computer-gnerated (CG) images. In practice, it works great in word documents and in games. But yeah, real-life "dithered" images do not compress well unless you use lossy encoding. Lossy encoding works well for video, and some stand-alone images (if it is not too lossy), but if often not apporopriate for documents or games. Well for a geoWrite/geoPublish document (or similar) lossy images might be acceptle (a photo for example) but often (a chart or diagram) it is very distracting.
It really depends on what you want to acheive. I don't know how you would improve compression without decreasing quality or speed. For example, you could use (high-quality) JPEG images (or similar based on DCT) but they would be VERY slow to render on a stock C128. If you can sacrifice quality, there are some methods (like VQ = Vector Quantization) that are fast for the C128. Both of those are "lossy" but you can improve the results (at the cost of compression) with a "high quality" factor. A third alternative is entropy (Huffman) encoding. Although it is loss-less ("perfect"), rendering on the C128 is slow (for example, use PUcrunch).
Edit By the way PUcrunch does a little bit of everything! RLE codes, Copy codes, and Huffman codes! There is a great series of articles by the author (Pasi Ojala) of PUcrunch (you can't more authoritative than that!) in Commodore Hacking issue #16 and issue #17.
Last Edit: Sept 2, 2014 13:55:26 GMT by hydrophilic: Added more links
Well for a game, I think you have already achieved your goal. I only did 2 CG (game-type) images, but they both compressed very well (over 75%). Also you reported a test image with excellent compression (around 65% as I recall). I mean sure, you might want to tweak the bit allocation for your different codes, and this would improve things for CG-images (who knows how much until you try). But the whole principle is just not adequate for highly dithered (real-life) images. This is mainly due to the random narture of the dithering algorithms... this destroys "easy" compressibility.
So unless you have a game with lots of real-life photos, then you are done (aside from tweaking, if you care to do so).
If you do want real-life (highly dithered) photos, and you want fast decompression, then you'll need to use lossy encoding. Two ways to do this are 1. what I call "linear" / "bitmap" approximation 2. vector quantization
#2 has been written about in many technical articales. It is the main reason I made ImageWork... to develop VQ routines beginning with single images (a much simpler environment then my full-blown video encoder). In no particular order, here are some of my bookmarks... A. "Seafloor Image Compression with Large Tilesize Vector Quantization" (PDF, lots of math, abstract in general, but nice photos) B. "Vector Quantization" (a "just the facts" web page, lots of math symbols, some diagrams, no real code)) C. "Qcc Pack" (this a Source Forge project, so it has a lot of working C code... I wish I knew about this BEFORE starting my ImageWork) D. "VECTOR QUANTIZATION" (a web page somewhere between the last two... more in depth than B but less real code then C [only psudo code]) E. "Algorithms in cluster analysis" (short web page with several links) F. "The Enhanced LBG algorithm" (PDF, lots of math, abstract in general, but nice photos)
Sorry about link F. That is one of my favorites (working with it now to improve VQ in my ImageWork so I can use it for video). Most annoyingly, I can not find a direct link to the article. It seems everything on Google takes you to a site that wants you to sign up and/or pay money to download the file. Well it is a university paper, so I'm pretty sure it is public domain, and the PDF that I have (did not pay for it or sign-up for anything) does not have any copyright notice. So it would probably be safe to upload if anybody really wants it.
Well #2 can be quite complex as you might gather from the university papers or peeking at the C code for hours
#1 is not very-well written about because it is something I just made up for my original video encoder. Some sort of cross between VQ and MPEG. Basically it searches for common ("visually almost the same") byte sequences near each byte sequence. Because it doesn't search very far, it is kind of like MPEG motion vectors... and because it searches for a byte sequence it is like a block used in VQ. However the search is more broad than MPEG and not fixed in size like VQ.
In comparison, #1 only works (well) for true bitmap images. My original/old video encoder also tried using it for text-mode, which gave very questionable results... which is why I have been working to develop #2 (VQ). VQ works for either real bitmap images, or custom-font-text-mode (emulated bitmap) images... however VQ is "best" with text mode which works quite well for VIC-II Multi-Color Text, but sucks for VDC text mode (so you probably don't care)... but VQ also works with real bitmap images (so you may be interested). However for real bitmap mode, you do need to "translate" the fake characters (VQ codes) into real bitmap raster segments. It slows things down a bit, but should be okay for a game... I mean it works about 7 frames per second in video (an estimation based on no audio... someday I'll re-allow silent videos, but at the moment audio is required which reduces max frame rate).
Oh yeah, my time estimations are based on VIC-II because I *still* don't have working VDC video, but the VDC can run the CPU at full 2MHz, while VIC-II is crippled by 1MHz CPU *and* bad lines. In other words, there is naturally a bottle-neck with moving data into the VDC, but the CPU can run much faster so I think overall the frame rates will be similar.
To avoid boring everyone, I'll shut up now, but I can elaborate on any of that upon request.
Still fails to run on 32-bit WinXP. My sister has my 32-bit Vista so I can't test that one at the moment. I still get error "not a valid Win32 application" which (in my experience) usually means it is 64-bit... I thought maybe you uploaded the wrong file, because your 32-bit version is the exact same size as the 64-bit version. That just seems wrong to me... but when I do 'diff' on the two files, there are many differences... so now I don't know what the problem might be.
I just got my Win Vista laptop back from sister... in echange, she took my Win 7 laptop. Well it sounds like she got a good deal because I hate Vista, but this laptop has a full numeric keypad (rare in a laptop, and I LIKE IT!) and it has a larger screen. So oh well, enough about me... I was really hoping to test your 32-bit version on Vista 32-bit, however I just discovered the laptop is also 64 bit! So I have more 64-bit PCs than I thought... or in other words, I can't test 32-bit on my Vista machine.
All I can say is 32-bit version does not run on XP. I assume (but have not tested) that it fails on Win 2K / ME / 98 / 95 too. Naturally a 32-bit app would not run on Win 3.1 (unless maybe you have Go32 extension).
Off topic / FYI... I pulled up this site using Netscape 7 (copyright 2003) and it works quite well. It looks a bit different, but it works. And that is what is important