GIF viewer for ZX.

ZXNet echo conference «zxnet.soft»

From Evgeny Goljakov To Valerij Kozhevnikoff 4 October 2002

Hello Valerij. Let's test it! Question: If this is a storage format for indexed colors, why then only B/W? For example, the jpeg viewer conveyed colors by the distribution of pixel density and There are no restrictions on the number of colors. Moreover, that jpeg is an order of magnitude more difficult. Give me a universal GIF viewer!!! ===== If you have a document in Russian to get general idea of this format or comparison with his kind. Please drop it. Here or to the soap. Thank you for your attention.

From Valerij Kozhevnikoff To Alexandr Tkachev 15 October 2002

Hello, Alexandr! 14 Oct 02 00:56, Alexandr Tkachev -> Valerij Kozhevnikoff: VK>> GIF image viewer 1.0b 256x192 B&W VK>> (c) Jason 2002 VK>> I look forward to your wishes and bug reports. AT> An excellent and very useful program, you often come across different circuits AT> in this format, but there’s nothing to see, now thanks to you life will become AT> a little easier THANK YOU... From the wishes, well, of course support for the top AT> memory and the ability to cut out the desired piece... Of the bugs, everything seems to be ok AT> maybe he doesn’t want to show some gifs, but these are probably just those AT> which you mentioned. There is only one serious bug. Amount of available lower memory determined with an error of 260*6=1560 bytes. If you look at wide pictures - the line buffer will creep onto the disk cache. This is what happens if there is an extra JR comment... 1.1b does not have this drawback. Now I will test the version for 512x192... It works! Interlaced 512x384! People, remember this day - October 15, 2002 of the year! With the starting address of the program = 30700 in the bare (all residents and driver for 64 characters) Idose version 3.5, memory for line buffer7460 bytes, which is enough for images 1800 pixels wide! XTR circuit I just looked at the modem, and this is 1084x784 pixels, and there were only 4472 bytes busy! I click the screens every interruption. I’ll make the /g+ key right now so that it’s a gigaskrin include. * Originally written in REAL.SPECCY * also sent to ZX.SPECTRUM * also sent to ZXNET.SOFT WBR, Jason. /*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/ /np:/ *silence*

From Valerij Kozhevnikoff To Evgeny Goljakov 17 October 2002

Hello, Evgeny! 04 Oct 02 14:00, Evgeny Goljakov -> Valerij Kozhevnikoff: EG> Let's test it! There are glitches there. EG> Question: if this is a format for storing indexed colors, EG> why then only B/W? How is this "only"? EG> For example, the jpeg viewer conveyed colors using the distribution of pixel density And that’s what I have. EG> Give me a universal GIF viewer!!! EG> ===== EG> If you have a document in Russian to get EG> general idea of this format or comparison EG> with others like it. Please drop it. Here or to the soap. 256 colors, one bitplane. Regular LZW compression. If you change the unpacker to RLE in the source code - PCX can be watch. WBR, Jason. /*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/ /np:/ *silence*

From Valerij Kozhevnikoff To Evgeny Goljakov 19 October 2002

Hello, Evgeny! 19 Oct 02 17:18, Evgeny Goljakov -> Valerij Kozhevnikoff: EG>>> Let's test! VK>> Glitches there. EG> Then we'll test them too! There were two serious bugs. 1. The amount of available lower memory was determined with an error of 260*6=1560 byte. If you look at wide pictures, the line buffer will creep onto the disk cache. This is what happens if you comment out an extra JR... 2. The /b key did not work. EXX got lost BRIGHT_KEY > EXX this one. INC HL INC HL PUSH HL As a result, the brightness threshold turned out to be equal to the taken number of about 200. VK>> 256 colors, one bitplane. EG> Why is interlacing invented? And x.z. VK>> Regular LZW compression. If the source contains an unpacker in RLE VK>> change - PCX can be viewed. EG> And I naively believed that there was a minimum(!) Huffman :( At offset +2 in the PCH there is a byte. If it =1, then RLE. Doc on him show? The encoding method is as follows: FOR every X byte read from file IF both high order bits of X are 1, then = 6 least significant bits of X = next byte after X OTHERWISE = 1 = X EG> Then maybe you know which format is more effective for indexed ones EG> colors (<256), without loss of quality? PNG. WBR, Jason. /*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/ /np:/ *silence*

From Evgeny Goljakov To Valerij Kozhevnikoff 19 October 2002

Hello Valerij. Thu 17 Oct 02 Valerij Kozhevnikoff -> Evgeny Goljakov: EG>> Let's test it! VK> Glitches there. Then we’ll test them too! EG>> For example, the jpeg viewer transmitted colors by distribution EG>> point densities VK> And that’s what I have. Then it’s probably cool (no offense to chunk fans) EG>> If you have a document in Russian to get EG>> general idea of this format or comparison EG>> with others like it. Please drop it. Here or to the soap. VK> 256 colors, one bitplane. Why was the interlacing invented? VK> Regular LZW compression. If the source contains an unpacker in RLE VK> change - PCX can be viewed. And I, out of naivety, believed that there was a minimum(!) Huffman :( Then maybe you know which format is more efficient for indexed colors (<256), without loss of quality? VK> WBR, Jason. Thank you for your attention.

From Valerij Kozhevnikoff To All 22 November 2002

Hello, All! 21 Oct 02 08:16, Valerij Kozhevnikoff -> Alexandr Tkachev: VK>>> The process is near completion. VK>>> I’m thinking of making a key /db to change the size of the disk buffer VK>>> in sectors. Is it necessary? Or is 1 sector enough? AT>> If you're not too lazy, do it of course. VK> Laziness. 1.1. it will be without him, a lot has already been done there. I'll do it in 1.2. The subject has been more or less settled. The disk buffer has left 1 sector for now. On floppy computers it will slow down. A screw or ramdisk is desirable. What is now. 1. Works in IS-DOS Chic and classic. 2. Memory can handle up to 4 megabytes (256 pages). There are currently only drivers up to 1M. 3. Able to download .scr from the screen. The version for 512x192 screen unloads monochrome unpacked .pcx 512x384. There is a PCX packer, but it’s not good The shrinking pictures are glitching... So for now without it. 4. In addition, the version for an extended screen can display an image on printer (if the driver is installed). 5. Well, Gigascreen is supported. The printing/saving system can be easily disabled in the source code, so I’ll ask now: are they needed? Because I feel sorry for the memory... Now I’ll sit down to finish the manual and put everything in the archive. One of these days it will fly into an echo. The license will be GPL. WBR, Jason./*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/