direct memory access through the lines[] pointer would is the fastest but you'll have to make sure you won't go out of bitmap bounds.

If he wants to play directly with pixels then won't there be a severe performance loss unless the bitmap is memory bitmap?

I think direct memory access could still have some benefits. E.g you could take the line pointer, saving a bit on pointer calculations (line [X] instead of bmp->line[X]). Also I think using full pixels (int32_t for 32bit) instead of separate RGB channels could give a bit of speed. When getting maximum possible speed very important you could always use MMX/SSE intrinsics for some SIMD action

It is, because it has to lock the bitmap, select the line you're writing to, then write the pixel, then deselect the line, and finally unlock the bitmap. Doing all that yourself to ensure they aren't called more than necessary will be quicker.

Using line is a bit faster, but will only work on memory bitmaps.

Depends. The driver can have it set so you write to system RAM, then will push it all out to the card in one shot when you read/unwrite. In such cases, it won't be much slower as long as you keep read/write switches to a minimal (there'll also be additional gains from having no intermediary bitmap (page flipping or dirty rectangles on the screen), or by having accelerated vram->vram blits).

Kikaru:
If the BITMAP is a memory bitmap, and it's an 8 bit per pixel BITMAP, that's all you need. If it's not an 8 bit per pixel bitmap, it's almost that simple, but you need to add a cast (like: ((short*)(bmp->line[y]))[x] = color; for 15 or 16 bit per pixel modes). Any bitmap created with create_bitmap is a memory bitmap. The screen usually is not a memory bitmap though. However, the screen usually is a linear bitmap, which can be used almost as fast via a slightly different technique.

This is all in the docs, under "Direct access to video memory".

((uintN_t*)(bmp->line[y]))[x] = color;where N is the color depth.

If I recall correctly, there was an Allegro example, 'exflame.c', which compared three methods of writing pixels.
First using 'getpixel()' and 'putpixel()', which was slow, then using direct memory access, which was faster, then using block memory copy operations, which was by far faster than both.
Perhaps you should check that out?

If you're going to use direct memory access, there's a chapter devoted to it in the manual, called 'Direct access to video memory'. You could also try the following optimizations:

Instead of 'for(x = 0; x < SCREEN_W; x++)' do 'for(x = SCREEN_W; x--; )'.
This will save the processor the need of subtracting 'x' from 'SCREEN_W' every time.

Try unrolling the loops in blocks of 8. (I think every resolution can be divided by 8.)
For a resolution of 800x600, it could save you 472,500 operations of incrementing the counters and testing for loop conditions per frame.