Ok. This was a problem in the code MGB. I fixed it in SVN r.5160.Mario_r4 wrote:I'm not sure about the correct operation f36. You can see in the picture the colors displayed on the screen and the colors obtained in f36 not conform to the format. The application expects that the color will be in the format 24bpp, but the current code simply copies 16bpp to 24bpp.hidnplayr wrote:f36 works correctly, but f73 (blitter) is not yet implemented in 16bpp mode.Mario_r4 wrote:Also we need to fix some of the programs that receive data through f.36 and GS.
I think it is better to do the conversion 16bpp to 24bpp at the kernel level - it will solve the problem for many applications.Spoiler:
Оптимизация ядерной графики
-
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
since #5161 the blitter should also work in 16bpp mode.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Blitter code probably still can be optimized. On the other items, the difference between 32bpp and 16bpp on eBox is not so great. For example, the output images f7 hasn't such failure in performance, as f73.hidnplayr wrote:since #5161 the blitter should also work in 16bpp mode.
Spoiler:
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Mario: feel free to experiment with this blitter code, I dont like it at all and chose the lazy copy-paste-patch method for this.
I want to get back to playing with this 86duino and network code now
I want to get back to playing with this 86duino and network code now
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
I think it makes sense to wait fix for r.5130.hidnplayr wrote:Mario: feel free to experiment with this blitter code, I dont like it at all and chose the lazy copy-paste-patch method for this.
I want to get back to playing with this 86duino and network code now
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
hidnplayr
Serge has fixed the problem r.5130. Here are the results of tests on RoverBook U800.
P.S. Now you can think about the 8-bit modes.
Serge has fixed the problem r.5130. Here are the results of tests on RoverBook U800.
Spoiler:
RoverBook U800 32bpp SVN r.5129 RoverBook U800 32bpp SVN r.5165 RoverBook U800 16bpp SVN r.5165Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
There is also 15 bppMario_r4 wrote:P.S. Now you can think about the 8-bit modes.
I am personally quite satisfied with the available video modes now.
I believe almost all VESA2.0+ compatible cards have at least one 16, 24 or 32bpp mode.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Ух как много интересных новостей по поводу 16(15)bpp.
Могу ли я попросить обновить в вики описание графических функций касательно (8), 16, 24, 32bpp?
Могу ли я попросить обновить в вики описание графических функций касательно (8), 16, 24, 32bpp?
А чего там обновлять? Для приложений ничего не изменилось, не считая того что нужно учитывать возможность режима 16bpp при прямой работе с видеопамятью через регистр GS. Однако работа через GS это скорее системный хак, чем нормальное явление, просто так быстрее считывать данные для скриншутера.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Mario_r4,
жаль, признаю, тот самый случай, когда я совершенно не понимаю сути происходящего,
мне показалось, что fn73 уже может работать не только с 32bpp
жаль, признаю, тот самый случай, когда я совершенно не понимаю сути происходящего,
мне показалось, что fn73 уже может работать не только с 32bpp
Она как раз задумывалась товарищем Serge, чтобы выводить от приложения исключительно 32bpp - так как упрощенный код без кучи проверок работает быстрее ф.65 (которая как раз поддерживает всякие разные bpp).pascualle wrote:мне показалось, что fn73 уже может работать не только с 32bpp
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Скорость ни при чём: viewtopic.php?p=31993#p31993. Функция 65 написана неправильно, её можно существенно ускорить, чтобы она не отличалась от 73, но, видимо, никому не нужно.Mario_r4 wrote:Она как раз задумывалась товарищем Serge, чтобы выводить от приложения исключительно 32bpp - так как упрощенный код без кучи проверок работает быстрее ф.65 (которая как раз поддерживает всякие разные bpp).
Сделаем мир лучше!
Почему не нужно? Просто некоторые вещи либо забываются (я всего лишь человек, да, а не суперпрограммист с идеальной памятью как ты), либо не критичны для текущего использования. И вообще правило, что любой код можно оптимизировать никто не отменял. У меня сложилось мнение, что Serge сделал ф.73 в основном из-за скорости, возможно я и ошибся в своих оценках.CleverMouse wrote:Скорость ни при чём: viewtopic.php?p=31993#p31993. Функция 65 написана неправильно, её можно существенно ускорить, чтобы она не отличалась от 73, но, видимо, никому не нужно.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Во видишь - добрый и вежливый человек все сразу доступно объяснил.pascualle wrote:Mario_r4,
жаль, признаю, тот самый случай, когда я совершенно не понимаю сути происходящего,
Spoiler:
Вот я не добрый и не вежливый.Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Mario_r4
Не столько из-за скорости, сколько из-за отсечения. + ещё зарезервирован ebx для ROP.
Не столько из-за скорости, сколько из-за отсечения. + ещё зарезервирован ebx для ROP.
Who is online
Users browsing this forum: No registered users and 2 guests