box_lib.obj - библиотека gui компонентов
-
А в чём магия? Что мой код всего лишь на строчку короче? Ну да, компиляторы неплохо оптимизируют код... нормальный код, без ООП.
Там вон viewtopic.php?f=9&t=2122&p=66983#p66982 перестало работать.
Предположительно из-за этого изменения http://websvn.kolibrios.org/filedetails ... 75#line-28
Предположительно из-за этого изменения http://websvn.kolibrios.org/filedetails ... 75#line-28
Я ошибся - код одинаковый, по 11 команд.Pathoswithin wrote:А в чём магия? Что мой код всего лишь на строчку короче? Ну да, компиляторы неплохо оптимизируют код... нормальный код, без ООП.
И у компилятора тоже есть неочевидная для меня
Code: Select all
lea eax, DWORD PTR [eax+eax*2]
Влил ToolTip и пример использования в библиотеку.
В исходниках - полезная для будущих компонент фича для использования структур в асме.
Spoiler:
Code: Select all
Пишем один раз описание структуры
struc tooltip txt, next, zone_x, zone_w, zone_y, zone_h, col_txt, col_bkg, tm_wait
{
.txt dd txt ; указатель на текст asciiz, разделитель \r 13
.next dd next ; следующиий tooltip в цепочке или 0
.zone_y dw zone_y ; зона контроля (в 90% случаев совпадает с размером контрола)
.zone_x dw zone_x ;
.zone_h dw zone_h ;
.zone_w dw zone_w ;
.col_txt dd col_txt ; цвет текста тултипа, включая размер SysFn4
.col_bkg dd col_bkg ; цвет фона тултипа
.tm_wait dw tm_wait ; время ожидания х10мс
;временные переменные
.font_sz dd ? ; font size
.mouse dd ? ; предыдущее положение (x, y)
.tm_strt dd ? ; время запуска таймера (входа мыши в зону) х10мс
.video dd ? ; память для сохраненного под тултипом
.video_y dw ? ; координаты запомненной области экрана, или 0 если пусто
.video_x dw ?
.video_h dw ? ; размер предрасчитывается при init
.video_w dw ?
}
virtual at edi
ttip tooltip ?, ?, ?, ?, ?, ?, ?, ?, ?
end virtual
Потом используем
mov edi, [ttip] ; регистр смещения указанный в virtual
обращаемся просто
mov [ttip.mouse], 0
...
stdcall get_font_size, [ttip.col_txt]
итп
Siemargl, молодец, конечно, что старался.
Но это всё-таки не совсем tooltip получился.
Tooltip это вот на скриншоте viewtopic.php?f=24&t=1220&start=315#p66855 А у тебя просто квадратик рисуется.
Ну ничего, в принципе, как пример это можно оставить.
Как только появится время, постараюсь добавить нормальный ToolTip.
Но это всё-таки не совсем tooltip получился.
Tooltip это вот на скриншоте viewtopic.php?f=24&t=1220&start=315#p66855 А у тебя просто квадратик рисуется.
Ну ничего, в принципе, как пример это можно оставить.
Как только появится время, постараюсь добавить нормальный ToolTip.
В исходниках - полезная для будущих компонент фича для использования структур в асме.
Америку открыл, да?кстати, можно нормально пользоваться структурами в асм через virtual директиву. см новый тултип
Насчёт editbox-a.
Думаю, лучше было взять дополнительные байты из "внутренних" переменных, таких как, например, ed_shift_pos, ed_shift_pos_old, cl_curs_x, cl_curs_y. Потому как реально там не нужно по 4 байта. Сами эти переменные можно сдвинуть в памяти, они же внутренние, их никто кроме самого editbox-а не использует. Так что, это ещё и экономия памяти.
Думаю, лучше было взять дополнительные байты из "внутренних" переменных, таких как, например, ed_shift_pos, ed_shift_pos_old, cl_curs_x, cl_curs_y. Потому как реально там не нужно по 4 байта. Сами эти переменные можно сдвинуть в памяти, они же внутренние, их никто кроме самого editbox-а не использует. Так что, это ещё и экономия памяти.
Дизайнер есть, насоветует - рисовку улучшим.0CodErr wrote:Siemargl, молодец, конечно, что старался.
Но это всё-таки не совсем tooltip получился.
Tooltip это вот на скриншоте viewtopic.php?f=24&t=1220&start=315#p66855 А у тебя просто квадратик рисуется.
Судя по коду бокс_либ и твоим проблемам с байтами - таки открыл )0CodErr wrote:В исходниках - полезная для будущих компонент фича для использования структур в асме.Америку открыл, да?кстати, можно нормально пользоваться структурами в асм через virtual директиву. см новый тултип
Siemargl, посчитай ещё раз.
Мой код (без "магии"):Впрочем, мерятся с компилятором всё равно что играть с ботами...
Мой код (без "магии"):
Code: Select all
mov ecx,ed_text_color
mov ebx,ecx
shr ecx,28
shr ebx,24
and ebx,7
inc ebx
mov eax,6
jecxz @f
mov al, 8
@@:
mul bl
Так нечестно - ты сейчас выкинул and c маской и у тебя jecx отработает при любых старших битах, например asciiz.
В целом я и не спорю, что ручная оптимизация лучше, да и компилятор иногда такое нарисует (особо относится к gcc),
а поинт был в том, что если уж писать асм руками, то делать это понятным для человека.
Раз пошла такая пьянка, вот ресурс, позволяющий оценить, что напишет бот-компилятор для примера, с выбором ботов. А потом уже можно и напильником.
AFAIK, компиляторы пока сами не умеют хорошо использовать SSE.
В целом я и не спорю, что ручная оптимизация лучше, да и компилятор иногда такое нарисует (особо относится к gcc),
а поинт был в том, что если уж писать асм руками, то делать это понятным для человека.
Раз пошла такая пьянка, вот ресурс, позволяющий оценить, что напишет бот-компилятор для примера, с выбором ботов. А потом уже можно и напильником.
AFAIK, компиляторы пока сами не умеют хорошо использовать SSE.
and dword ed_text_color,17FFFFFFh - это общая валидация для всего editbox, она нужна в обоих случаях.
А ещё, компиляторы не умеют использовать rep movs, lods, stos...
А ещё, компиляторы не умеют использовать rep movs, lods, stos...
Last edited by Pathoswithin on Tue Nov 08, 2016 2:01 pm, edited 1 time in total.
Хорошо, я сам это сделаю тогда viewtopic.php?f=24&t=1220&p=67000#p66992
Никто ведь не против сохранения обратной совместимости?
Pathoswithin, подумай насчёт высоты шрифта, там тоже не надо 4 байта. Может ещё для чего-нибудь сгодится, для флагов там каких-нибудь.
Никто ведь не против сохранения обратной совместимости?
Pathoswithin, подумай насчёт высоты шрифта, там тоже не надо 4 байта. Может ещё для чего-нибудь сгодится, для флагов там каких-нибудь.
В данном случае нет. Компилятор тестирует конкретный бит.Pathoswithin wrote:and dword ed_text_color,17FFFFFFh - это общая валидация для всего editbox, она нужна в обоих случаях.
А ещё, компиляторы не умеют использовать rep movs, lods, stos...
Я против - ты поломаешь C-Layer, а у gcc какие то болячки с отключением выравнивания в структурах. Еще потом с байтами трахаться (со словами не придется).0CodErr wrote:Хорошо, я сам это сделаю тогда viewtopic.php?f=24&t=1220&p=67000#p66992
Никто ведь не против сохранения обратной совместимости?
Pathoswithin, подумай насчёт высоты шрифта, там тоже не надо 4 байта. Может ещё для чего-нибудь сгодится, для флагов там каких-нибудь.
Лучше исправить поломавшиеся программы на нормальный код с родными бокс_либовскими макросами
Last edited by Siemargl on Thu Nov 10, 2016 11:37 am, edited 1 time in total.
Siemargl ух кокой толстый тролинг
Кому не нравится обратная совместимость, могут смело форкать проект.
Кому не нравится обратная совместимость, могут смело форкать проект.
Проверил. Экономия 12 байт в структуре стоит дополнительных 32 байта в коде из-за префикса размера у не 32-битных команд в 32-битном режиме.
Pathoswithin, ты собираешься исправлять или как?
Тогда я тебе тоже сейчас серьёзно и отвечу.
Для трёх EditBox-ов экономия составит уже 12 * 3 = 36 байт, в то время как в коде BoxLib это будут по-прежнему те же самые 32 байта.
Тут проблема в том, что поломались уже работающие программы.
То есть, если после обновления сборки у пользователя перестаёт что-то работать, то ему, вероятно, придётся пойти на форум, потратить время, чтобы понять, в чём проблема, обновить поломавшуюся программу(причём сначала надо будет дождаться её исправления).
Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.
Вообще, хотелось бы по этому поводу комментариев администрации. Я считаю, что такое положение дел это ну никак нормальным назвать нельзя. А представьте, что проблемы с совместимостью возникли бы у гораздо большего количества разработчиков, например 20-30?
Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.
А ты сейчас серьёзно насчёт экономии памяти?Экономия 12 байт в структуре стоит дополнительных 32 байта в коде
Тогда я тебе тоже сейчас серьёзно и отвечу.
Для трёх EditBox-ов экономия составит уже 12 * 3 = 36 байт, в то время как в коде BoxLib это будут по-прежнему те же самые 32 байта.
Отвечу тебе твоими же словами. Тебе нужно всего-тоSiemargl wrote:Я против - ты поломаешь C-Layer
То есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasmSiemargl wrote:исправить поломавшиеся программы на нормальный код с родными бокс_либовскими макросами
Тут проблема в том, что поломались уже работающие программы.
То есть, если после обновления сборки у пользователя перестаёт что-то работать, то ему, вероятно, придётся пойти на форум, потратить время, чтобы понять, в чём проблема, обновить поломавшуюся программу(причём сначала надо будет дождаться её исправления).
Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.
Вообще, хотелось бы по этому поводу комментариев администрации. Я считаю, что такое положение дел это ну никак нормальным назвать нельзя. А представьте, что проблемы с совместимостью возникли бы у гораздо большего количества разработчиков, например 20-30?
Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.
Еще и скорость обращения к полусловам наверное тоже ниже, хотя для интерфейсной части это вряд ли критично.
>То есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasm
Именно. Автосборка системы решает эту проблему, а fasm - стандартный для системы транслятор. Новая версия системных библиотек тянет за собой требование к тестированию и/или обновлению юзер-программ, это всегда и везде так.
>Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.
В С-- структура уже исправлена (т.е.WebView и Eolite вычеркиваем), остальные можешь проверить и сказать, поломались или нет )
>Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.
Такая идеология в static linux http://sta.li
>То есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasm
Именно. Автосборка системы решает эту проблему, а fasm - стандартный для системы транслятор. Новая версия системных библиотек тянет за собой требование к тестированию и/или обновлению юзер-программ, это всегда и везде так.
>Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.
В С-- структура уже исправлена (т.е.WebView и Eolite вычеркиваем), остальные можешь проверить и сказать, поломались или нет )
>Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.
Такая идеология в static linux http://sta.li
Who is online
Users browsing this forum: No registered users and 5 guests