Board.KolibriOS.org

Можно и удалить часть и сжать, но проблема в другом - кто будет сжимать второй раз изображения с программой?

Тогда это будет не порт, а отдельный проект. В таком случае стоит и код причесать (читай переписать). Подумать об изменнии формата хранения изображений (сделать более оптимальным), сменить эти изображения (использовать все 24 бита, а палитру). Оптимизировать вывод изображения, добавить звук и т.д.

..bw

Перерисовки окна просто жуткие, особенно если колибри в каком-нибудь Qemu запускать

А если не в qemu, а если с kqemu?

bw> я портирую код этой реинкарнации на KolibriOS
bw> Если кто-то сочтет необходим, то игру можно полностью переписать, с новой графикой, сделать более оптимальной по коду и по ресурсам (размеру).

..bw

Пропустил следующие изменения в панели - viewtopic.php?f=9&t=809&p=19566#p19566
В следствии чего, при запущенной панели в LRL не работали комбинации Alt+1/2/3/9. Изменил Alt на Ctrl.
Архив с двоичными файлами - ftp://kolibrios.org/users/bw/lrl/lrl.tar.bz2
Исходники в svn - programs/games/lrl

..bw

Проблема lrl - частая перерисовка окна (особенно это видно на заголовке). Такая же была в Косилке, дабы не переписывать дофига текста, я поступил проще: ввёл переменную w_redraw.

void draw_window(void){
if (w_redraw)
{
kos_WindowRedrawStatus(1); //Íà÷àëî ïåðåðèñîâêè
kos_DefineAndDrawWindow(50,50,640,506-22+kos_GetSkinWidth(),0x74,0xEEEEEE,0,0,(Dword)windowTitle);
}
.......

Тоесть если действительно нужет репеинт окна - перерисовываем его, в ином случае нужно всего лишь изменить содержимое, а само окно перерисовывать не надо.
Может быть, тебе это поможет.

Задачей было портирование приложения, а не глобальный рефакторинг.
Это досовская игрушка, где весь вывод выполнялся прямиком в видеопамять. Вывод в момент показа "титров" и в момент игры реализованы по разному. Для первого я не заморачивался вообще, оттого можно наблюдать косяк - окно не перерисовывается при перетаскивании, событие для отрисовки не отслеживается и не обрабатывается. В момент игры - отрисовка выполняется с определенным интервалом. Под QEmu (с kQEmu) при трехкратном увеличении ничего не тормозит, а нагрузка на проц. не значительная.
Если делать "по нормальному", то нужно переписывать игру полностью. Я не вижу в этом необходимости. Для меня, это была обкатка FP под KOS, да и сам процесс портирования меня всегда увлекал, ну и игрушка неплохая :-).

p.s. Спасибо за совет.

..bw

bw
По сути Leency прав. При перерисовке окна затрачивается куча дополнительного времени.
Окно же вообще нужно перерисовывать полностью только в 2-х случаях:
1) Старт программы.
2) Получение события о перерисовке окна.
Во всех остальных случаях исключительно перерисовывать содержимое. Не сочти за нравоучение, вдруг ты не был в курсе.

Я не знаю например как в KVID сделано, но оно в отличие от LRL не тупит. Кстати как оно там поживает - есть ли возможность прикрутить полноценную обработку пути к файлу?

[offtop]
Замечу что загрузку процессора в QEmu смотреть безполезно, в связи со странностью эмуляции PIC в QEmu данные о загрузке процессора получаются неверными.
[/offtop]

> Не сочти за нравоучение, вдруг ты не был в курсе.
Был и есть.

> Кстати как оно там поживает - есть ли возможность прикрутить полноценную обработку пути к файлу?
Очень плохо. Задача синхронизации нескольких (двух хотя бы) дорожек довольно своеобразная, сложная даже. Просто пасую доделать работу. Нужна простая и гениальная идея.

> Замечу что загрузку процессора в QEmu смотреть безполезно
Смотрю в основной системе.

..bw

Heavyiron wrote:Перерисовки окна просто жуткие, особенно если колибри в каком-нибудь Qemu запускать

В эмулях колибри всегда тормозит , наверное она слишком гордая чтобы делить ресурсы компа с другими осями , но последнии релизы более щедрые

Приложение падает в ночной сборке ISO.