Mario
Мог бы и не писать.
Все равно хабрапиплы всегда будут правы - у этой оськи никогда не будет никаких реально нужных практических применений.
И сейчас она никому нафиг не нужна.
Под нее даже и задач никаких специфических не существует.
И прошу заметить - никогда не существовало.
Так, одно недоразумение.
Потому что все равно винда (линукс, qnx) гораздо круче, и отлично работают во всех мыслимых ситуациях.
Оптимизация ядерной графики
Ну, я рад что ты встал на путь истинный и праведный.art_zh wrote:Mario
Мог бы и не писать.
Все равно хабрапиплы всегда будут правы - у этой оськи никогда не будет никаких реально нужных практических применений.
И сейчас она никому нафиг не нужна.
Под нее даже и задач никаких специфических не существует.
И прошу заметить - никогда не существовало.
Так, одно недоразумение.
Потому что все равно винда (линукс, qnx) гораздо круче, и отлично работают во всех мыслимых ситуациях.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Напомнило, как мы в школе ходили гулять к девчёнкам в ругой двор. Приходим как-то раз, они говорят: "Мы кое-что знаем"
Мы такие: "И что же?"
"А мы не скажем" и смеются.
Мы такие: "И что же?"
"А мы не скажем" и смеются.
Из хаоса в космос
leency
а тебя-то что конкретно интересует ?
а тебя-то что конкретно интересует ?
As of revision #5154 KolibriOS kernel supports 16bpp VESA modes.
Last edited by hidnplayr on Mon Nov 03, 2014 6:53 pm, edited 1 time in total.
"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
hidnplayr
Your code is very useful, but I think you're too quick with removing align4 in some places. I think the performance for vesa20.inc has a higher priority than decreasing the size of the binary code by 5%.
Dell Inspiron 32bpp SVN r.5150
Dell Inspiron 32bpp SVN r.5154
Also we need to fix some of the programs that receive data through f.36 and GS.
Your code is very useful, but I think you're too quick with removing align4 in some places. I think the performance for vesa20.inc has a higher priority than decreasing the size of the binary code by 5%.
Dell Inspiron 32bpp SVN r.5150
Spoiler:
Spoiler:
Last edited by Mario_r4 on Sun Nov 02, 2014 2:42 pm, edited 1 time in total.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Okay, I only removed "align 4" where it doesn't seem to make any sense.Mario_r4 wrote:hidnplayr
Your code is very useful, but I think you're too quick with removing align4 in some places. I think the performance for vesa20.inc has a higher priority than decreasing the size of the binary code by 5%.
Also we need to fix some of the programs that receive data through f.36 and GS.
If I'm wrong, please show me where or why and I'll be happy to correct.
Unfortunately, MGB reports seem unstable, and you made a typo labelling both screenshots 5150
Usage of GS has since long time been discouraged. I'll look into f36, where did you see any problems?
"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 am very lazy person so I just put align4 everywhere.hidnplayr wrote:Okay, I only removed "align 4" where it doesn't seem to make any sense.
If I'm wrong, please show me where or why and I'll be happy to correct.
Damn COPY-PASTE! The picture however are right. It's not so noticeable on a Dell Inspiron (core i5), but on slower machines this becomes more apparent. Unfortunately my RoverBook u800 is not working since r.5130. I will be testing 5150 and 5154 on eBox-3300MX and I will post the results later.hidnplayr wrote:Unfortunately, MGB reports seem unstable, and you made a typo labelling both screenshots 5150
Problems exist for MGB and SCRSHOOT for 16 bpp modes. Perhaps there is any program yet.hidnplayr wrote:Usage of GS has since long time been discouraged. I'll look into f36, where did you see any problems?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
btw, here are my test results (from virtualbox, in 800x600x32bpp mode)
align 4 can actually slow down code because it inserts NOP instructions in some code paths.
PS: more is better.
align 4 can actually slow down code because it inserts NOP instructions in some code paths.
Spoiler:
"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
eBox-3300MX 32bpp SVN r.5150
eBox-3300MX 32bpp SVN r.5154
OOPS...
Spoiler:
OOPS...
Spoiler:
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
What happened? System crashed/hung after loading RDC driver?Mario_r4 wrote:eBox-3300MX 32bpp SVN r.5154
OOPS...
Just tested on my eBox, everything OK (32bpp and 16bpp modes work fine)
EDIT: Looks like I spotted the problem, expect a fix soon
"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
please try again with #5157
"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
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.
"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
Yes, it's work fine. Thanks, great job and I withdraw my objections about align4.hidnplayr wrote:please try again with #5157
Spoiler:
eBox-3300MX 32bpp SVN r.5150 eBox-3300MX 32bpp SVN r.5157 eBox-3300MX 16bpp SVN r.5157Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
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 лет себе в жопу!
Who is online
Users browsing this forum: No registered users and 0 guests