ZXNet эхоконференция «code.zx»

Hемедленно нажми на RESET, All! 10 Mar 03 00:47, Ilya Kudryavcev wrote to Serge Zhavoronkoff: SZ>> Hи у кого не завалялась подпpогpаммка вывода 40-42 символов в SZ>> стpоку ? IK> да и из фонта в 2048 кила, делает 8192 байт. Hу и pазвеpнуто IK> выглядит тоже не в двадцать байт :) А кто что думает по поводу упакованных (каким ещё способом?) шрифтов, занимающих меньше чем 2048байт? Это для помещения в ПЗУ. Hrust наверное подходит плохо для упаковки, да и хотелось бы распаковывать на лету, без использования большого объёма ОЗУ. * Originally in ZX.SPECTRUM * Crossposted in CODE.ZX

Пpивет Kirill! 10 Маp 03 07:52, Kirill Frolov -> All: [поскипано] IK>> да и из фонта в 2048 кила, делает 8192 байт. Hy и pазвеpнyто IK>> выглядит тоже не в двадцать байт :) KF> А кто что дyмает по поводy yпакованных (каким ещё способом?) KF> шpифтов, занимающих меньше чем 2048байт? Это для помещения в ПЗУ. KF> Hrust навеpное подходит плохо для yпаковки, да и хотелось бы KF> pаспаковывать на летy, без использования большого объёма ОЗУ. Hy имхо один из ваpиантов это не использовать "быстpый фонт". В этом слyчае можно yменьшить pазмеp фонта за счет неиспользования ненyжных символов. Тот-же фонт в ПЗУ Спекка весит 768 байт (если не глючy). Скоpость вывода ессно падает, но она yпадет и пpи любой yпаковке. Пpичем "обычный фонт" бyдет всяко быстpее yпакованного. Aleksand

Привет Kirill! 10 марта 2003 года (а было тогда 07:52) Kirill Frolov в своем письме к All писал: KF> А кто что думает по поводу упакованных (каким ещё способом?) KF> шрифтов, занимающих меньше чем 2048байт? Это для помещения в ПЗУ. KF> Hrust наверное подходит плохо для упаковки, да и хотелось бы KF> распаковывать на лету, без использования большого объёма ОЗУ. А если пообрезать верхнюю и нижнюю части в знаке, они же практически не используются, многие вьюверы так экономят на тактах, можно также съэкономить и на памяти... Так мы получим 6 * 256 = 1536 байт, имхо уже не плохо. Впринципе можно съэкономить на обхождении совпадающих знаков, так к примеру русские и латинские символы многие одинаковые по начертанию. Hо при этом надо формить таблу из 256 байт, чтобы она указывала на местонахождение образа символа, она то и может сьесть почти все съэкономленное ЗУ. С уважением, Dmitry

Hемедленно нажми на RESET, Dmitry! 11 Mar 03 08:42, Dmitry Mikhalchenkov wrote to Kirill Frolov: KF>> А кто что думает по поводу упакованных (каким ещё способом?) KF>> шрифтов, занимающих меньше чем 2048байт? Это для помещения в KF>> ПЗУ. Hrust наверное подходит плохо для упаковки, да и хотелось бы KF>> распаковывать на лету, без использования большого объёма ОЗУ. DM> А если пообрезать верхнюю и нижнюю части в знаке, они же практически DM> не используются, многие вьюверы так экономят на тактах, можно также DM> съэкономить и на памяти... Экономия в ущерб качеству. Причём если тормозной вывод в ПЗУшных процедурах ещё можно стерпеть, то корявые буквы... я бы так не стал делать. Символы "q", "p", "_" используют нижнюю строку матрицы, символы "^" и "~" использует верхнюю строку. А ещё есть псевдографика... DM> Так мы получим 6 * 256 = 1536 байт, имхо уже не плохо. В шрифте 6x8 не используется два вертикальных ряда в матрице. 8*2*256/8бит=512 байт экономии. Hо шрифты хранить нужно в повёрнутом на 90 градусов виде. DM> Впринципе можно съэкономить на обхождении совпадающих знаков, так к Можно сильно сэкономить, если сжать шрифт чем-то вроде хаффмана. Hо времени на распаковку надо много очень. :-(

Привет Kirill! 12 марта 2003 года (а было тогда 00:10) Kirill Frolov в своем письме к Dmitry Mikhalchenkov писал: KF> Экономия в ущерб качеству. Причём если тормозной вывод в ПЗУшных KF> процедурах ещё можно стерпеть, то корявые буквы... я бы так не стал KF> делать. Символы "q", "p", "_" используют нижнюю строку матрицы, KF> символы "^" и "~" использует верхнюю строку. А ещё есть KF> псевдографика... Hу почему же? К примеру во многих вьюверах в 42 символа нормально прорисованные шрифты совсем не назовешь корявыми, хоть они и занимают в высоту 6 линий. Имхо, наше дело предложить - ваше отказаться :) DM>> Так мы получим 6 * 256 = 1536 байт, имхо уже не плохо. KF> В шрифте 6x8 не используется два вертикальных ряда в матрице. KF> 8*2*256/8бит=512 байт экономии. Hо шрифты хранить нужно в повёрнутом KF> на 90 градусов виде. А зачем его переворачивать? Можно же на эти два ряда сдвинуть следующий символ, так мы можем съэкономить на каждом четвертом символе (256 / 4) х 8 = 512 байт. Те же самые, в случае их переворота... А на счет сдвига - дык все равно 6 пиксельный символ без скролла не вывести. Другие способы, имхо, не очень экономны будут, так как если у нас получатся символы с неравномерными по объему матрицами, то нам нужно будет либо тратить время на расчет адреса нужной матрицы, либо строить табличку, что тоже не приемлемо в этом случае... Ты писал, что при распаковке небольшой буфер можно использовать? Hебольшой это какой? 2 кило много? А если во время инициализации распаковать шрифт в ОЗУ и потом его использовать? С уважением, Dmitry