RIPPER-GFX работает с любыми GFX-темами, не обязательно из серии @DED@ и умеет: РАЗОБРАТЬ готовую GFX-тему на файлы СОБРАТЬ готовую GFX-тему из папки с файлами Заменять ИЗОБРАЖЕНИЯ фона и других компонентов Создавать и редактировать шрифты Помогать в настройке GFX-темы @DED-LEGO@ Запускать виртуальную машину для загрузочной флэшки
Настройка и создание @DED-LEGO@ средствами RIPPER-а Настройка готовой @DED-LEGO@ прямо через MENU.lst Введение Скрытых пунктов в MENU.lst Привязка пунктов MENU.lst к номеру LOGO и справке Пользовательские горячие клавиши для пунктов меню Мультифоновая, мультшрифтовая поддержка Реализованые компоненты: СМОТРЕТЬ
Эта gfxboot была нужна для ТОНКОЙ подгонки цветов и координат. Потеряла актуальность с выпуском RIPPER-а с графическим интерфейсом пользователя (GUI)
ДААА!!!! Получилось не плохо,вот только скорость поубавить надо будет... еще с хелпом не все ладно получается,т.к. анимашка затирает буковки.... А какого размера анимашка может быть????А если анимированный фон использовать,У НАС так и останется затирание других элементов меню???
Получилось не плохо,вот только скорость поубавить надо будет...
В параметрах "скорость" это скорость сдвига (в данном случае сдвиг сканирующего луча). Но если у Вас мало кадров в кадрограмме, то визуально уменьшение скорости может только испортить эффект. Тогда надо переделывать кадрограмму. Можно ее просто растянуть по горизонтали. Кстати хотел еще и замедлитель сделать, что бы пропускать тики, да так и НЕ сделал.
Quote (NecroTYN)
еще с хелпом не все ладно получается,т.к. анимашка затирает буковки
Правда? Не посмотрел. Хелп - это важно, нужно подправить.
Quote (NecroTYN)
У НАС так и останется затирание других элементов меню???
Что касается рабочего экрана, то пока мы не введем категорию слоя и не подведем под это программную базу (а это не быстро), то элементы так и будут "затирать" друг друга и их нужно будет "разводить" по эрану. Конкретно с анимашками пока вообще для восстановления используется back.jpg.
Quote (NecroTYN)
А какого размера анимашка может быть???
Я ограничений не ставил, но не забывайте про память и границы экрана.
Quote (NecroTYN)
А если анимированный фон использовать
Насчет фона сомневаюсь, а вот сканирующую полосу по меню, как Вы хотели, наверное можно сделать. Только нужно подумать. У меня почему-то клинит, когда я начинаю прикидывать какой должна быть кадрограмма и маска. С "кардиограммой" очень долго соображал, а сделал минут за сорок @DED-LEGO@ - конструктор для разработчиков GFX-тем ПОСМОТРЕТЬ
Сообщение отредактировал ded2007 - Воскресенье, 11.07.2010, 18:27
Всё творите, неутомимые... страшно даж качать и смотреть что там наворотили =) (потом как-нить как буду делать свежую версию сборки, так займуся) NEW! Моя сборка - Kupr_Soft-Flash_4.4 ...Не ленитесь поднять репу =)
Как мы разбирали здесь, в общей секции menu.lst, т.е. до первой команды title, можно размещать несколько команд gfxmenu с вызовом различных gfxboot тем. При этом, GRUB4DOSостанавливается на каждой команде gfxmenu и ждет, и только, если не получил указания "выполнять такой-то пункт меню", продолжает двигаться дальше.
В данном случае ключевым является слово "останавливается", т.е. команды идущие после gfxmenu еще не сработали (а может и не сработают ). Значит необходимые timeout, default или даже root и прочие команды нужно выполнять ДО команды gfxmenu (причем если их несколько, то можно для каждой менять настройки!).
PS. В тот раз не отписал, так сейчас изложу. Делаем, скажем, три темы DED10A, DED7B, DED0. Которые отличаются в следующем - количеством "технических", т.е. скрытых пунктов меню: 10, 7 и 0 соответственно и клавитурной комбинацией для выхода. Первое меню, например, покидаем по клавише "A", а второе - по клавише "B". В результате получили систему с тремя "ПРОСТО СЕКРЕТНЫМИ" пунктами меню. Что бы увидеть их нужно нажать "A". А вот оставшиеся 7 пунктов - получились "СОВЕРШЕННО СЕКРЕТНЫЕ", т.к. чтобы добраться до них нужно нажать последовательно сначала "A", а потом "B". @DED-LEGO@ - конструктор для разработчиков GFX-тем ПОСМОТРЕТЬ
Сообщение отредактировал ded2007 - Воскресенье, 11.07.2010, 21:29
В данном случае ключевым является слово "останавливается", т.е. команды идущие после gfxmenu еще не сработали (а может и не сработают). Значит необходимые timeout, default или даже root и прочие команды нужно выполнять ДО команды gfxmenu (причем если их несколько, то можно для каждой менять настройки!).
я никуда особо и не пропадал, просто заглядываю, почитываю... да пора-бы и обновить сборочку, но гад такая жара, так всё в лом, да ещё и по работе напряги... никак не могу начать делать... NEW! Моя сборка - Kupr_Soft-Flash_4.4 ...Не ленитесь поднять репу =)
Кстати, большинство gfxboot, которые я качал с интернета используют HighColor. Даже те, кто удосужился переключиться на разрешение 1024х768, почему то в массе своей оставляли глубину цвета в 16 бит. Меня лично, сдерживало отсутствие поддержки режима 800x600x24bit со стороны QEMU. Не очень-то удобно каждый раз бегать к другой машине для отладки или перегружать свою.
И вот. Нашел вариант videobios.bin для QEMU с поддержкой режимов чуть ли не 1600x1200xTrueColor (проверял только до 1280х960xTrueColor). Подключил его к нашему QEMU, который рекомендовал -=MDI=-, cоответственно подкоректировал и просмотрел работу @DED-LEGO@ в TrueColor. Работает. А чего ему не работать. Ушли эти раздражающие ступеньки на градиентных переходах полутонов.
Следующее обновление уже будет в TrueColor. В конце-концов, найти сейчас видеокарту, которая не поддерживает 800x600xTrueColor - это еще постараться надо!
Разве тип эмулируемой видеокарты (а, значит, и набор поддерживаемых видеорежимов) не выбирается опцией -vga?
Quote (man qemu)
-vgatype Select type of VGA card to emulate. Valid values for type are
cirrus Cirrus Logic GD5446 Video card. All Windows versions starting from Windows 95 should recognize and use this graphic card. For optimal performances, use 16 bit color depth in the guest and the host OS. (This one is the default)
std Standard VGA card with Bochs VBE extensions. If your guest OS supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if you want to use high resolution modes (>= 1280x1024x16) then you should use this option.
vmware VMWare SVGA-II compatible adapter. Use it if you have sufficiently recent XFree86/XOrg server or Windows guest with a driver for this card.
Для размещения подготовленной графики я использую видеопамять и поэтому, эмулируемое videobios количество памяти для меня существенно.
В том пакете, которым мы пользовались было два videobios-a, да и раньше тоже, но... 1. По умолчанию QEMU использует vgabios-cirrus.bin. При этом, доступна глубина цвета до HighColor и 4Mb videoRam 2. C ключем -std-vga используется vgabios.bin. При этом, уже доступна глубина цвета до TrueColor, но только 1Mb videoRam (похоже, что в MobaLiveUSB как раз он-то и используется) 3. Давеча раскопал в нете новый (2009г.) вариант vgabios.bin. С ним доступна глубина TrueColor + 16Mb videoRAM
Вот я и радуюсь.
@DED-LEGO@ - конструктор для разработчиков GFX-тем ПОСМОТРЕТЬ
Сообщение отредактировал ded2007 - Среда, 14.07.2010, 13:14
Вообще говоря нет, но некоторые послабления мы получаем. Сильно лимитирует нас основная память, а вот в видеопамять мы сбрасываем подготовленые фрагменты. Например, пользователь готовит логотип и маску. Если при каждом движении по меню брать логотип из gfxboot, накладывать его через маску на фон и выводить результат, то действия пользователя будут неприятно тормозиться. Выход заключается в использовании видеопамяти. Еще при загрузке, мы заполняем отдельную видеостраницу образцами фона под логотипом и накладываем на них сами логотипы. Теперь у нас есть готовые образцы, которые нужно просто брать и показывать - все гораздо быстрее. В оперативке мы себе такого никак не могли позволить - места мало. Аналогично и с другими модулями. Вот сейчас и АНИМАШКИ переведу на похожий режим.
А в чем же тогда выигрыш, ну кроме более гладкого отображения цветов? В видеопамять не обязательно записывать картинки, можно скидывать и расчетные данные, например массивы. Но при поддерже только HighColor это было весьма затруднительно, т.к. при записи в видеопамять числа интерпретировались как цвет и этот цвет приводился к 16-битной глубине. Например, записываем последовательно три точки с цветами 0,1,2, а когда читаем, то все они имеют код 0. В полном же TrueColor-е что запишешь, то и прочитаешь, т.е. можно хранить не только картинки но и некоторые данные. (Правда, я еще не пробовал , пока что так - теоретизирую)
Рано начал радоваться. Попробовал на двух материнках с интегрированными видео. Если просто интерированное видео, то еще куда ни шло, но если доставить дискретную видеокарту, то видеопамять режется по самое "не могу". Какие там 256 Mb! Две страницы и все. Грустно...
Придется навставлять прямо в gfxboot предупреждений. Иначе, я себе прямо представляю, человек пробует новую "супренавороченную" темку, а у него кроме новых картинок ничего особенного-то и нет. Глянул и все, знакомство закончилось, и выкидывает - картинки-то уже все умеют менять. Да-а-а. Рассылаю ежедневно по сотне приглашений, а тут такое разочарование. NecroTYN, появился еще один форумчанин с потребностью разделения меню на подменю. Будем думать. Может сразу и о "горячих клавишах" подумать? Объем работы пока выглядит смутно, т.к. нужно будет не только со своим кодом поработать, но и common.inc, system.inc, main.inc, etc слегка подприпотрошить @DED-LEGO@ - конструктор для разработчиков GFX-тем ПОСМОТРЕТЬ
Сообщение отредактировал ded2007 - Пятница, 16.07.2010, 10:36
Рано начал радоваться. Попробовал на двух материнках с интегрированными видео. Если просто интерированное видео, то еще куда ни шло, но если доставить дискретную видеокарту, то видеопамять режется по самое "не могу". Какие там 256 Mb! Две страницы и все. Грустно...
Жаль что все так...
Quote (ded2007)
Может сразу и о "горячих клавишах" подумать?
...для перехода по разделам???? может надо,а может и нет, как я себе представляю, переход по меню будет осуществлятся стрелками--как в BIOS,соответственно если мы назначаем цифровые клавиши,то нужно еще доплнительных две--для определения горизонтального и вертикального меню
Я не пропал. В связи с ростом потребностей стал примеряться к gfxboot_3.3. За основу взял версию от уважаемого alser , как наиболее очищенную от "излишеств".
Докладываю о результатах экспериментов: во-первых, оказалось, что можно собирать gfxboot любого размера, хоть 10Мб; во-вторых, из всей информации, включенной в cpio-архив, "достучаться" прямо из работающей gfxboot удалось только до первого 1Мб; в-третьих, оказался важен порядок включения в cpio-архив файлов, т.к. именно файлы "выходящие" за "горизонт" в 1Мб становятся недоступными.
Конечно все это можно было усвоить и раньше, почитав про cpio, но, как обычно, приходится учиться исключительно на своих ошибках
В отношении вышесказанного, показателен прилагаемый пример. При загрузке Example1, мы обнаруживаем артефакты на back-20.jpg. Это потеряна часть картинки "за горизонтом". Если вы уменьшите количество txt-файлов в прилагаемом примере или, наоборот, увеличите объем текста в имеющихся файлах, то после пересборки увидите смещение границы (см. Example2).
). Значит необходимые timeout, default или даже root и прочие команды нужно выполнять ДО команды gfxmenu (причем если их несколько, то можно для каждой менять настройки!). 
, как наиболее очищенную от 