You can also use the hline function instead of the putpixel because it is a lot faster when drawing on to a video bitmap, but only with the hardware acceleration. At least it works faster for me. 
Hi y'all.
i have noticed tht in quite a lot of languages the
getpixel()//get color of pixel at x,y
and the
putpixel()//draws pixel of certain color at x y
functions are really slow. i am working with game maker and importing some allegro functions unto a dll bu i dont know how to add the assembly function to a dll. i dont even know assembly to be honest but i have seen a few scattered codes on the topics so i plan on using if only i can cross compile it.
i dont know if i am making sense cos i am sleepy from staying up all nite.
if someone could be of litte assistance i would be most greatful
]]>No, don't use assembler, you are likely to make things worse. Either use direct bitmap access, through the bitmap array (search allegro.txt for that), or use the optimized versions:
If you are using 8bpp, use the ones without number. If you are at other resolution, change accordingly. Finally, note that these functions (as far as I remember) don't check for clipping: in other words, if you use the common getpixel function with coordenates (10000,10000), nothing will happen. If you use such coordenates with any of these functions, your program will crash.
]]>i never heard of optimized getpixel?
well i am amazed to say the lest. will try soon.
hope i works on this
for(i=0; i<sprite_width; i++)
{
for(j=0; j<sprite_height; j++)
{
color= getPixel(x,y);
//_pallete[] contains color codes
for(v=0; v<old_pallette_array_width; v++)
{
if(color==old_pallete[v])
{
putPixel(x,y,new_pallete[v]);
}
}
}
}
You can also use the hline function instead of the putpixel because it is a lot faster when drawing on to a video bitmap, but only with the hardware acceleration. At least it works faster for me.
this is all great help but the problem is i am not implementing this directly into allegro. i was half-way into a projecct in game maker before i saw allegro and i cant begin to think of starting again (my comrades cant c++/c).
so i guess you have answered the allegro part so the new part is...how do i use the allegro dll in other programs like gamemaker? do i just run the functions as i would normally use it? i tried exporting some functions into a dll but there was a clash with the <windows.h> api as bitmap means different things in both. thts why i was asking for assembly just incase asking for allegro sounded stupid. me so confused.
if only i understood pascal/assembly
| 1 | .PROCEDURE HLine(X1, Y, X2 : INTEGER; Color : BYTE); ASSEMBLER; |
| 2 | ASM |
| 3 | les DI, Screen { Only load ES and DI at the start } |
| 4 | add DI, X1 |
| 5 | mov BX, Y { Y is an index into the ScreenY array } |
| 6 | add BX, BX { Multipy by two because each entry is a word } |
| 7 | add DI, DS:[BX+OFFSET ScreenY] |
| 8 | |
| 9 | { At this point, DI points to the first pixel in the line. } |
| 10 | { Now we will calculate how many times to loop (X2-X1+1)... } |
| 11 | |
| 12 | mov CX, X2 |
| 13 | mov AL, Color { Load the color } |
| 14 | sub CX, X1 |
| 15 | inc CX |
| 16 | |
| 17 | test DI, 1 { Are we on an odd address? } |
| 18 | jz @Even |
| 19 | stosb { Store the first byte } |
| 20 | dec CX { Decrement the counter one } |
| 21 | @Even: { Even address } |
| 22 | |
| 23 | shr CX, 1 { Do half as many transfers } |
| 24 | rep stosw { Copy all of the even words } |
| 25 | adc CX, 0 { If there is a pixel left over, set CX to 1 } |
| 26 | rep stosb { If there is a pixel left over, fill it! } |
| 27 | END; |
]]>
there was a clash with the <windows.h> api as bitmap means different things in both.
Include winalleg.h. See the Windows-specifics section of the manual.
thts why i was asking for assembly just incase asking for allegro sounded stupid.
It's an Allegro forum. Of course it isn't stupid to ask questions about Allegro! 
if only i understood pascal/assembly
Why?
By the way, that code you posted is 16 bit, probably real-mode DOS code. It won't be of much use to you. It's ok to start with if you want to learn about assembler, but for your case I think this is clearly overkill.
I almost see no reason to use assembly anymore for any but embedded and extremely low-level tasks. Using any modern c-compiler an intelligent user can produce almost exactly the assembly they want without losing any cross-platform and readability. Even vector processing can be easily handled without leaving c/c++ nowadays.
]]>No, don't use assembler, you are likely to make things worse. Either use direct bitmap access, through the bitmap array (search allegro.txt for that), or use the optimized versions:
Very true. Get/putpixel are damn slow compared to something like bitmap->line[y][x] = color.
]]>