fx2d_SetVCA по-різному обчислює прозорість вершин

[GoogleCodeExporter]

What steps will reproduce the problem?
(Какие операции/etc. вызывают проблему?)
Функція fx2d_SetVCA по-різному обчислює 
прозорість вершин.

What is the expected output? What do you see instead?
(Что ожидается в итоге? Что происходит
вместо ожидаемого?)
В додатку - результати обчислення 
прозорості для двох різних вершин.

What version of the product are you using? On what operating system? With
what compiler - Delphi/FreePascal?
(Какую версию используете? На какой
операционной системе? С каким
компилятором - Delphi/FreePascal?)
ZenGL 0.2.2, Windows 7, Delphi 7.

Original issue reported on code.google.com by TGud...@gmail.com on 21 Jul 2011 at 10:13

Attachments:

• 1.png
• 2.png

[GoogleCodeExporter]

На жаль це неможливо виправити, тому що 
така специфіка роботи відеокарт. ZenGL 
використовує лише два трикутника для 
побудови спрайту(2.png як раз показує їх 
положення), і "вгадування" правильного 
положення трикутників - буде затратним по 
ресурсам, а в деяких ситуаціях - просто не 
існує рішення. Тому для детального 
відтворення доведеться використовувати 
OpenGL і збільшувати кількість трикутників 
для правильної інтерполяції.

Original comment by dr.andru@gmail.com on 21 Jul 2011 at 10:41

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Хоча... можливо я щось придумаю на цих 
вихідних :)

Original comment by dr.andru@gmail.com on 21 Jul 2011 at 10:48

[GoogleCodeExporter]

Був би вдячний :)
Якщо я правильно зрозумів, кількість 
трикутників достатньо збільшити то 
чотирьох, як у додатку. Я би й сам зробив, 
але OpenGl взагалі не знаю\

Original comment by TGud...@gmail.com on 22 Jul 2011 at 10:22

Attachments:

• 3.png

[GoogleCodeExporter]

Вибачай, був трохи зайнятий. В attach поклав 
тимчасове рішення проблеми для ZenGL 
0.2.2(тепер pr2d_Rect, ssprite2d_Draw, asprite2d_Draw та csprite2d_Draw 
використовують більше трикутників). Візьми 
нові файли та перекомпілюй ZenGL, якщо 
використовуєш ZenGL.dll.

Original comment by dr.andru@gmail.com on 28 Jul 2011 at 6:19

Attachments:

• src.7z

[GoogleCodeExporter]

Дякую! Тепер при плавних переходах 
трикутників майже не видно. Поки писав 
програму для тесту, помітив ще один 
незначний баг - у значенні кольору 
переплутані місцями Red та Blue. Наприклад, 
RGB(255,0,0) дасть замість червоного синій. В 
додатку - програма-тест, де це помічено.

Original comment by TGud...@gmail.com on 31 Jul 2011 at 11:03

Attachments:

• demo.zip

[GoogleCodeExporter]

>> помітив ще один незначний баг - у значенні 
кольору переплутані місцями Red та Blue. 
Наприклад, RGB(255,0,0) дасть замість червоного 
синій. В додатку - програма-тест, де це 
помічено.

Це баг твоєї функції, вона плутає місцями R 
та G, тобто утворює послідовність BGR замість 
RGB. Це видно навіть з коду, де b зміщується 
вліво на 16 розрядів. У цьому випадку синій 
колір буде $FF0000, що зовсім не вірно.

Original comment by dr.andru@gmail.com on 31 Jul 2011 at 6:26

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Я ту функцію скопіював із модуля Windows.pas o_О
Тобто, Delphi 7 скрізь зберігає кольори у 
іншому форматі?

Original comment by TGud...@gmail.com on 1 Aug 2011 at 12:22

[GoogleCodeExporter]

>> Тобто, Delphi 7 скрізь зберігає кольори у 
іншому форматі?

без поняття :)

Original comment by dr.andru@gmail.com on 1 Aug 2011 at 12:30