[b]Ghost[/b] wrote:Наткнулся на 35 (GetPixel) - подумал, может её переделать? Сейчас приложение сначала узнаёт ширину экрана, перемножает её на x.coord потом ядро делает обратную работу.
[b]sysfuncs.txt[/b] wrote:Parameters:
* eax = 35
* ebx = y*xsize+x, where
* (x,y) = coordinates of a pixel (beginning from 0)
* xsize = horizontal screen size
{35} Function GetPixel(X, Y: Integer): Dword; StdCall;
Asm
push ebx
// at first need to know Screen.Width
mov eax, 61
mov ebx, 1
int 64
// at now eax = (Width << 16) | Height
// need to make ebx = Y * Width + X
shr eax, 16
mul Y
add eax, X
mov ebx, eax
// and now GetPixel
mov eax, 35
int 64
pop ebx
End;
0CodErr
Если критикуешь какое-нибудь извращение - тогда предложи что-нибудь получше.
В растровой графике все пиксели лежат в массиве шириной Width и высотой Height.
Точка с координатами (X,Y) определяется элементом этого массива с номером (Y*Width+X), и никак иначе.
Ну если у твоего монитора фиксированное разрешение 1024х768, тогда умножение+сложение можешь соптимизировать битовым сдвигом с OR-маской по X-координате.
Так будет гораздо быстрее, но учти что
- это будет работать только на твоем компьютере, и
- в ядре десятки подобных растрово-пиксельных компутаций, вся оконная система на них построена.
art_zh, а ты на функцию syscall_getpixel посмотрел перед своим постом? А в инструкцию div там тебя носом ткнуть? 0CodErr, Pathoswithin: и даже для одного пикселя можно использовать функцию 36.
CleverMouse
Функция 35 изначально была хорошо задумана, чтото такое нужно для векторной графики и анимашек
(например стрелочные часы, надо запомнить старые пикселы под линией прежде чем её рисовать).
А параметры функции оптимизированы чтобы ядро разгрузить и в программах можно упростить код.
А потом наверно у когото на EGA-мониторе она не работала и Mr Turjanmaa замкнул всё на GETPIXEL через div
Но это не значит что она совсем лишняя и нельзя её доделать.