Hello,

I have the project to make my own FPS with my own engine (WOlF3d style) with allegro this time, in fact I am really disappointed by SDL 2.0 library so I decided due to the time waisting to move to this library, I had have mouse movement problems and I was too lazy to fix myself these bugged functions.

However before installing this library, I searched for known bugs and I saw that there are still plenty of problems with displaying (bugs seems to appear with allegro 5 and 4.22)and the same problem with mouse movement which is limited by the edge of screen...

" //Quote not from me picked on http://freecode.com/projects/allegro/releases/258252
Release note of version 4.2.2 :A new mouse cursor API is used, but it doesn't work in Windows fullscreen modes.
"

So my questions are :

with allegro :

- Which version of allegro should I use if I want that my program run under windows ?
- Which version of allegro got no mouse problems and full-screen displaying bugs ?
- or even better, what is the last version outdated but fully fonctionnal that works for sure, (I can even use dosbox to launch the game, that's not a problem ! ) ?
- Can i manually set my screen pixels, that is to say, allegro allows me to have a pointer to the screen pixel, then I can modify, then I imagine I must refresh the screen, can allegro do that ? (I don't want to have a fonction that modify 1 pixel, it would be too long to modify the whole_screen)

Thanks a lot, and anyway well done to all contributors of allegro even if there are some bugs

Hi! First of all, you'll be best off with Allegro 5. Allegro 4.x is and old, legacy version of Allegro and not actively developed anymore. And because you want to do 3D graphics, the latest version of Allegro 5.1 will probably be best since it has functionality that helps with drawing 3D graphics that isn't there yet in Allegro 5.0.

There is no version of Allegro without bugs since almost all software has bugs, but AFAICS both fullscreen and the mouse work fine with Allegro 5 under Windows. And if you have any problems, then please report the problem here and we'll do what we can to help you.

You can set pixels manualy to the screen, but nowadays this isn't done anymore since almost all desktop PC's and most handheld devices have a graphics processor (GPU) that can and should be used for drawing 2D or 3D graphics. To do that you use OpenGL, or use the Primitives (https://www.allegro.cc/manual/5/al_draw_prim, etc) Allegro 5 API to render (draw) the 3D world of your game. The following thread gives an example of how to do that: https://www.allegro.cc/forums/thread/614194.

Thank for your answer but you probably misunderstanding me, I wrote :

"I have the project to make my own FPS with my own engine (WOlF3d style)"

Do you know what wolf3d refers to ? It's wolfenstein 3d 1992, it uses raycasting rendering method, there is no high level implementation like open_gl or direct_x, so the problem is that I don't want to use any 3d implentation, I will build myself one as I already begun with SDL 2.0. In fact I just want a pointer to the pixel then maybe call an allegro function to load them into the gpu and give order to refresh the screen with an allegro function. Can allegro do that ? SDL 2.0 allows that. Of course my engine will not use the power of the gpu, but that is not a problem for me.

And all software doesn't have major bugs ! By major bugs I mean that when I was SDL 2.0 programming, my project stopped only because of this library that was buggy, and as I said I was too lazy to contribute to the fix of this problem. Yeah, I am a simple studient with limited time and ressources, I got my own problems, my parents, my studies, my duties, papers managing you know ...

PS: Are you sure that allegro 5 is the best choice ? I mean because if I am not wrong the community with 5 version improve allegro OS targets ? isn't it ? And as I say I don't want to make a portable program, I'm only a little windows user...

PS2: I will try today with allegro 5 to see if I got the limited mouse movement in windows fullscreen mode bug. If I got this problem, I will be maybe forced to see the allegro sources to fix this bug, but I already look to the sources and I must admit that it is pretty difficult to understand the allegro library structure especially when I have never use it . So if I have no bugs I will close this thread. thank again.

What is that problem? I'm curios, can you elaborate a bit more?

to amcerasoli : here a link to a bug with ALLegro, the same I got under SDL 2.0 but Allegro seems to have exactly the same problem :https://www.allegro.cc/forums/thread/608627/0

I have tested now allegro 5 and I can affirm that low resolution are no more taken in charge : 320*200 and 320*240 doesn't work at all in fullscreen mode, I remember that it can work but I imagine allegro 5 will not concentrate effort on it, and that is normal, anyway there is no problem because I can put a 640*480 with a 320*240 by duplicate value of the pixel, however it take a little of cpu time for that and In my case this is a little bit critical.

If this raycasting stuff is really what you're after, I think the appropriate function might be al_lock_bitmap with the ALLEGRO_LOCK_WRITEONLY flag.
You will receive a AL_LOCKED_REGION, which essentially provides raw memory access to pixel data. Note that you have to fill in the whole bitmap before uploading it to the GPU with al_unlock_bitmap. You can also use al_put pixel if you don't want do deal with raw memory access.

I don't know about its speed, but as long as you don't read back any pixel data (ALLEGRO_LOCK_WRITEONLY)and since you seem to intend to use low resolutions anyway, I don't think this'll be a problem.

If you fill in the pixels and unlock your 320x200 bitmap, you can draw it normally using al_draw_bitmap. You could even enable antialiasing (use ALLEGRO_MAG_LINEAR with al_set_new_bitmap_flags when creating) and draw it scaled to your window/screen resolution (al_draw_scaled_bitmap).

Yeah polybios, I have searched for pixel direct acces but all the proposed mehtod are too slow, and the fonction put_pixel ? Arg, a joke this function, I just saw the sources, it is so unoptimised, and the process of locking then unlocking every frame too. SDL 2.0 system of direct acces is much powerfull. The contributors should look to SDL 2.0. In fact I think that I will be forced to program in assembly using modified versions of int 10h fonctions and launching the game via a dosbox. So I will leave you now . Anyway good luck ! admin can close the trhead.

Low res modes just aren't supported by newer windows operating systems period. You can fake them by setting a 2x size res, and then scaling your graphics. which is easier to do with allegro 5.

Assuming Allegro 4:
Don't use put pixel for a lot of drawing. you want either _putpixelNN (8,16, 32), the things mentioned here or just access bmp->line or bmp->data instead. Most people pick bmp->line and bmp->data these days.

For allegro 5, the bitmap locking will give you direct access to the memory for memory bitmaps. but locking a video bitmap will require a texture download and upload each time you lock/unlock it.

Ok, but please don't run away yet, and try to listen to what the people are saying here... I know you're young and restless, but you should take some time to get to know the libraries you are going to use, whether it is Allegro 5 or not.

As other people are telling you can write directly to a bitmap in allegro 5 as well, and then draw that to the display. There's a thread here with more info: https://www.allegro.cc/forums/thread/612922

With contemporary systems it's normally not possible anymore to switch the screen to such a full screen low resolution. In stead, you scale up your 320x240 buffer to screen size using transformations or by rendering the bitmap scaled. SDL 2 actually does the same.

Also, a different approach might be to not draw pixels, but simply draw colored rectangles of the right size to simulate pixels.

Ohhhh the people... Sometimes because the library can't work with 4D and sometimes because the library is not able to simulate a 128X64 display... What's next?

I suggested ALLEGRO_LOCK_WRITEONLY because I thought there was only an upload.

By the way, adding one/more layer(s) of indirection (DosBox, int 10h emulation etc.) won't be much faster, I guess.
But if you're after retro stuff, have fun with int 10h and 16 bit asm.

Technically it should be that. Not 100% sure if it is enforced.

That was exactly my first tought.

Actually it will be slower because dosbox runs on SDL... Might as well use SDL or Allegro directly.

If you're going to compile for DosBox, be sure to compile for 586 or less, it'll barf if you use SIMD or other more advanced instructions.

to beoran :

"
Ok, but please don't run away yet, and try to listen to what the people are saying here... I know you're young and restless, but you should take some time to get to know the libraries you are going to use, whether it is Allegro 5 or not.

As other people are telling you can write directly to a bitmap in allegro 5 as well, and then draw that to the display. There's a thread here with more info: https://www.allegro.cc/forums/thread/612922

With contemporary systems it's normally not possible anymore to switch the screen to such a full screen low resolution. In stead, you scale up your 320x240 buffer to screen size using transformations or by rendering the bitmap scaled. SDL 2 actually does the same.

Also, a different approach might be to not draw pixels, but simply draw colored rectangles of the right size to simulate pixels.
"

Sorry I know that. As I said, I have already tested the purposed methods... and this is so slow that I cannot stop laughing .

" Actually it will be slower because dosbox runs on SDL... Might as well use SDL or Allegro directly. "

Oug ! What a joke ! maybe written with SDL but it will be a lot faster !

to Thomas Fjellstrom :

I suggest you to read my post again :

I wrote :
"[...]anyway there is no problem because I can put a 640*480 with a 320*240 by duplicate value of the pixel[...]"

to AMCerasoli

I am sorry but I don't stay with a library that allows me not to do what I want...

to polybios and pkrcel
Can you post a proof of what you are saying ? It will maybe change my opinion, because in fact I just need to display my bitmap without locking/unlocking each frame. I already tried but I admit that my previos code may be wrong but this one wroks, just tell me how much time you execute this program, it takes 45 secs on my computer and works on a single 3.00 ghz core :

#define ALLEGRO_STATICLINK
#include <stdio.h>
#include <stdlib.h>
#include <allegro5/allegro.h>

int main(int argc, char **argv)
{
ALLEGRO_DISPLAY *display = NULL;

if(!al_init())
{
fprintf(stderr, "failed to initialize allegro!\n");
return -1;
}

//al_set_new_display_flags(ALLEGRO_FULLSCREEN);
display = al_create_display(320, 200);
if(!display)
{
fprintf(stderr, "failed to create display!\n");
return -1;
}
al_hide_mouse_cursor(display);
ALLEGRO_BITMAP *my_screen = NULL;
my_screen = al_get_backbuffer(display);

const int screen_pixels = 320*200;

int i, j, w;

for(w=0;w<256;w++)
for(j=0;j<256;j++)
{
ALLEGRO_LOCKED_REGION *lr = al_lock_bitmap(my_screen, ALLEGRO_PIXEL_FORMAT_ARGB_8888, ALLEGRO_LOCK_WRITEONLY);
unsigned int *ptr = (unsigned int *)lr->data; //points to first pixel
for (i=0; i<screen_pixels; i++)
ptr[i]=i+j*256+w*65536;
al_unlock_bitmap(my_screen);
al_flip_display();
//al_rest(0.01);
}

al_destroy_display(display);

return 0;
}

I never intended to use int 10h functions, just read carefully my post...
Obiously, if there are not modified there are too slow...
I think that when I will launch my program through dosbox, I may loose 10% compared on if I boot on the programm but in fact I don't really know... And yeah 2^20 of memory is enough for me !

to Arthur Kalliokoski
Of course !

edit: nevermind.

It is possible the format you locked the bitmap in is not the same as the actual format of the bitmap. That would cause conversion slowdowns.

The manual entry for al_lock_bitmap says :

This means you would have to adjust your pixel access based on the actual format of the bitmap.

What are you trying to accomplish exactly anyway?

I rewrote your example to fix the mistakes and ran it and I got 65536 frames at 320x200 in 65 seconds. That's 1000fps, on my laptop no less. Not fast enough for you?

Here's the code I used (just the important bits) :

With this test, it took 34.66 seconds for 4095 frames, roughly 118 FPS at 800x600.

And this entire argument is moot anyway, because with A5 you could use shaders for direct pixel access, and then it would be GPU bound, and not CPU bound.

Edit
Just so you know, you can use <code>code goes here...</code> tags to make our lives easier. See https://www.allegro.cc/mockup.html for details.

Edit2
Running fullscreen instead of windowed at 800x600 it took 19.3 seconds for 4096 frames, well over 200 FPS.

Allegro is not slow.

the_cake, like Edgar said, the problem is that there is a logical error in your code. You are locking, unlocking and flipping the backbuffer every time you write a pixel, which is of course very slow.

In stead, you need to first lock the backbuffer, outside of your rendering loop, then do all your rendering and pixel setting, then finally unlock and flip the bitmap. Then your program will be blazing fast. So yes, you can use Allegro 5 for your purposes!

Edit: This goes to show that he concept of locking a bitmap is not always intuitive to everyone. I checked the documentation of al_lock_bitmap and it doesn't quite mention that you are supposed to lock the bitmap only once and then do your pixel twiddling. I'll make a patch to modify the docs of that function later on.

There was another error as well, that of assuming pitch to be equal to pixel_size*width. Pitch can be negative or memory aligned and padded so it isn't guaranteed to be pixel_size*width. And you also can't expect the color order to be the same across systems unless you are very specific with your new display options. al_set_new_display_option

No, his code doesn't do that. The inner for loop is a one liner.

How so? The lock happens inside the double loop, right?

Yep he couldn't have done that with ALLEGRO_LOCK_WRITEONLY cause he's bound to write all pixels, as per docs.

Just so I know, what would happen if one does not write all pixels?

While is true that using shaders would accomplish this better, the argument is not moot since cake stated very clearly that he wants to use this programming technique for his engine and he's pretty much on track.

Anyway:

You know, I don't get your going around in circles, but this doesn't stand to logic...at least to me; SDL ha sa but that prevents your pixel access to be as fast as it should be, but usign an emulated blit over SDL itself should?

I admit I am not really clear on what you are going to do since I am n00b, but still I have difficulties in grasp this.

Of course not, mine was a speculation under the aforementioned logic.

EDIT: adding vertical spacing

int i, j, w;
for(w=0;w<256;w++){
   for(j=0;j<256;j++){ 
      ALLEGRO_LOCKED_REGION *lr = al_lock_bitmap(my_screen, ALLEGRO_PIXEL_FORMAT_ARGB_8888, ALLEGRO_LOCK_WRITEONLY);
      unsigned int *ptr = (unsigned int *)lr->data;

      for (i=0; i<screen_pixels; i++) ptr[i]=i+j*256+w*65536; 
      al_unlock_bitmap(my_screen);
      al_flip_display();
   }
}

he is unlocking after writing all pixels in the bitmap, not after only one, thou he is locking->unlocking for 655536 frames, to my understanding...am I wrong?

Oh yeah, right, can't believe I missed that Anyway, there were other bugs, so I hope Edgar's example is helpful to the_cake.

I like this guy! He writes code with bugs in it which cause lag, and then says "that's it, I can't write my game because no library in existence is fast enough"

Hey, the_cake, why don't you eff off. Nobhead.

@Edgar:
You assume ALLEGRO_PIXEL_FORMAT_ABGR_8888 as native format, right? Wasn't that supposed to be 'default'/'native' on most platforms?
At least that's what I get when I use ALLEGRO_PIXEL_FORMAT_ANY.

It's probably 'undefined', which means uninitialized memory I guess.

to pkrecl

"
Quote:

Can you post a proof of what you are saying ?

Of course not, mine was a speculation under the aforementioned logic.
"

Sorry, I wanted a proof that we are not forced to lock/unlock each frames from polybios

to beoran

I don't want to be bad but you really don't help, plz stay outside of this thread , you are saying that the example provided by Edgar is helpful ? Just compare !

to Edgar Reynaldo

-So what do I need to do to have a bitmap image RGB with 3 bytes per pixel ?, and I would like to have the bitmap in a set of columns, that is to say that each pixel of the bitmap is accesed with ptr[dim_bitmap_y*x+y]...

-And do you know a method which is more rapid to not locking/unlocking each frames ? In fact it is also very important.

You don't really understand that Allegro is slow. I let you remenber that Doom 2 was not supposed to be launched with 3 ghz processor at the time.
then my engine will consume cpu time for the graphic calculation, IA, sound, network, events, physics. You have to understand that I need to not waste stupidly my cpu-time with powerless methods...

Can you post a working complete example ?

But I am also annoyed with that ****** mouse problem !

I saw the Allegro sources and the problem comes with that ClipCursor function :
http://msdn.microsoft.com/en-us/library/windows/desktop/ms648383%28v=vs.85%29.aspx
But I think that if I create my own cursor, the al_ungrab_cursor will work because as I understood, the problem is that the windows cursor is shared and we can't modify easily its state without the autorization of the other applications. I got to study that. I am not the only one who got that problem I am hoping we will solve this.

Maybe I should try a little longer that Allegro 5.

It's not, you are.

Don't feel that you have to.

oh come on Dizzy egg, you are not helping ! Can you understand that ?

I'm just here for balance. You have a bunch of people trying to help you, but you don't want to accept that A5 is blisteringly fast (if you use it properly). This is great forum, full of helpful people....and me. And I say, get yourself a copy of GameMaker and do one, mug.

I'm definitively off with that library, that al_ungrab_mouse doesn't work, there is plenty of other bugs, In fact instead of SDL, or assembly, I will try win32 programming.

to Dizzy Egg
And how can we progress , if we are not being criticized by ourselves or by the others ?

"
I'm just here for balance. You have a bunch of people trying to help you, but you don't want to accept that A5 is blisteringly fast (if you use it properly). This is great forum, full of helpful people....and me. And I say, get yourself a copy of GameMaker and do one, mug.
"

You want a medal ? I am your father. No seriously, I really do not think you should take it that way.

Anyway, Have a lot of fun with allegro 5 !

I'd reply in full but I feel it would be wasted since I understand the_cake won't come over to see the replys....

...anyway I feel compelled to say that for not having time to contribute you surely have a LOT of time to waste to look for the holy grail.

And even if I blatantly have less understanding than you in these matters, I am fairly confident that YOU haven't fully understood what Edgar's example highlighted.

I couldn't try myself Edgar's example, but I remeber my last usage of al_lock_bitmap and al_put_pixel to create a pixel perfect collision mask would exceed 200FPS performance on my laptop, althou it was on a smaller bitmap than your 320x240 (I think I tested on a 200x200 but can't be arsed to check), AND CPU usage was not even close to 100% for sure.

I can't see on what basis you say that the Lib is not fast enuff for you and I strongly suspect that SDL itself was on par with these performances...

By the way, I guess asking something to this guy can help in there regards.

Farewell

the_cake ,

It's rather rude of you to talk in such a way to people who are trying to help you. You want to dish out criticism but seem unwilling to listen to it. That's not a good attitude. Also I see you are French? Perhaps you should learn a bit better English. Don't rely on tools such as google translate too much, that will lead to misunderstandings.

What exactly is the problem you are having with al_grab_mouse / al_ungrab_mouse? You keep complaining but it's not very clear what you want to achieve with it. Do you have some example code that demonstrates the problem.

Finally, since I wanted to show allegro is fast enough for your purposes, I wrote a fully executable example (in attachment). Compile it with `gcc -g -L/usr/local/lib pixel.c -lallegro -lallegro_primitives -o pixel` (on Linux)

It produces the following output for me`on an ultra cheap AMD laptop:
`Drew 500 frames in 5.335397 seconds or 93.713739 fps using al_put_pixel and locking
Drew 500 frames in 2.319453 seconds or 215.568067 fps using direct drawing and locking`

So even with al_put_pixel it is already quite fast. You only need 60 fps anyway, so that means you have a lot of CPU time left. And with direct draws you can even double the speed.

If you want to go faster on a contemporary system, then you should be doing the drawing using 3D models with OpenGL or DirectX, and not waste time on implementing your own software 3D engine.

Even if you use the Win32 API, the performance will not be that much faster than if you use Allegro, or SDL , since both libraries, on windows are thin wraper around the Win32 / Directx or OpenGL library (depending on how you compile them). And by using Win32 api directly, you lose portablity of your program and miss out on many convenient features.

While this is completely off topic, I'd point out that this thread pushed me to download wolfstein3D source code.

I felt so nostalgic to see such old school C, but also I could say that JC wrote such way above-average code but that also made eyes bleed like almost everybody out there (except beoran of course, pixel.c is lovely )

There I found a useful doc also.

Look up the 24 bit pixel formats and al_set_new_display_options for details. It's in 5.1.

You could probably get a speed up by making a batched draw call, where you collect all your geometry and use something like al_draw_indexed_prim.

Alright I made a generic test program called BitmapLocking.exe. Here are my results for a 320 X 200 window in Direct3D and OpenGL modes :

c:\ctwoplus\progcode\allegro5\test>BitmapLocking.exe 320 200 opengl 1000
Starting BitmapLocking in 320 X 200 windowed opengl with numframes = 1000
Pixel format of screen : 9
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 12.163923
FPS : 82.210321

c:\ctwoplus\progcode\allegro5\test>BitmapLocking.exe 320 200 1000
Starting BitmapLocking in 320 X 200 windowed default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 1.051323
FPS : 951.182459

Direct3D 320 X 200 Window 951FPS
OpenGL 320 X 200 Window 82FPS

Here are my results for 1280 X 800 Fullscreen with Direct3D and OpenGL :

c:\ctwoplus\progcode\allegro5\test>BitmapLocking.exe 1280 800 fullscreen
Starting BitmapLocking in 1280 X 800 fullscreen default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 11.102412
FPS : 90.070521

c:\ctwoplus\progcode\allegro5\test>BitmapLocking.exe 1280 800 fullscreen opengl
Starting BitmapLocking in 1280 X 800 fullscreen opengl with numframes = 1000
Pixel format of screen : 9
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 163.307744
FPS : 6.123408

c:\ctwoplus\progcode\allegro5\test>

Direct3D 1280X800 Fullscreen 90FPS
OpenGL 1280X800 Fullscreen 6.1FPS

So there are some major issues with the OpenGL implementation. It is several factors slower than Direct3D when it comes to locking and uploading bitmaps.

Try the program yourself :

BitmapLocking.7z Binaries + dlls + source

Run from command line :

Usage : BitmapLocking.exe WIDTH HEIGHT [fullscreen] [opengl] [#frames]
c:>

Direct3D should be more than fast enough for you. OpenGL seems to need some work though.

{"name":"608564","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/7\/9711a31e166b4088f77e46336e5cb0ba.png","w":1280,"h":800,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/7\/9711a31e166b4088f77e46336e5cb0ba"}

A side not: Edgar, you don't need OpenAL on Windows. Your test program is missing that .dll.

That's a dependency of the monolith I linked to.

I'll upload it in a while.

Edit - here's the updated 7zip of the binary and source and dlls

BitmapLocking.7z
Fixed a bug in parameter processing :
BitmapLocking.7z

c:\ctwoplus\progcode\allegro5\test\BitmapLocking>

Anybody have any idea why bitmap locking is so unbearably slow with OpenGL? Or is it just my crappy laptop with OpenGL 2 again... (Note to self : I have to test this on my desktop.)

Edit2
Fixed link to download. All should be good now.

Tested on my desktop, and OpenGL is still noticeably slower :

My desktop CPU is noticeably faster, but OpenGL still lags behind by a factor of 2 to 3, which is disappointing.

Can other people test this, and see what results they get? The source should work as is with Linux and OSX, you just don't need to specify opengl on the command line.

Usage : BitmapLocking.exe WIDTH HEIGHT [fullscreen] [opengl] [#frames]

I don't know, in my case it looks like something is blocking the framerate when the display is set on fullscreen, I have been messing with Vsync on my graphic card, might be related. Too many 60Hz over there.

Starting BitmapLocking in 800 X 600 fullscreen default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 16.515444
FPS : 60.549388

Starting BitmapLocking in 800 X 600 fullscreen opengl with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 17.812546
FPS : 56.140205

Starting BitmapLocking in 800 X 600 windowed default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 3.498927
FPS : 285.801940

Starting BitmapLocking in 800 X 600 windowed opengl with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 16.663655
FPS : 60.010845

Starting BitmapLocking in 1600 X 1200 fullscreen default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 16.609768
FPS : 60.205537

Starting BitmapLocking in 1600 X 1200 fullscreen opengl with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 16.815327
FPS : 59.469554

Yep confirmed, My graphic card was blocking the drawing operations. Aww I don't want to run the tests again.

Every problem I already have regarding OpenGL performance was a driver related one or a side effect of vsync and buffering.

I even had to use an outdated version of nvidia laptop pilot due to the new one being crappy with opengl.

Note that a lot of driver have vsync and triple buffering enable in opengl.

I just tried your example on my system. It has a GeForce GTX650 which has OpenGl 4.4 and DirectX 11, latest drivers. With VSync on on my driver settings it got 52FPS with OpenGL, when I shut VSync off I got the following, much better rate. My monitor refresh is 60hz.

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 1280 800 fullscreen opengl
Starting BitmapLocking in 1280 X 800 fullscreen opengl with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 8.837769
FPS : 113.150733

Without OpenGL and no VSync:

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 1280 800 fullscreen
Starting BitmapLocking in 1280 X 800 fullscreen default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 4.106563
FPS : 243.512620

Does seem too shabby.

Edit: And just for fun, at 1920x1080 (no VSync)

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 1920 1080 fullscreen opengl

Starting BitmapLocking in 1920 X 1080 fullscreen opengl with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 20.649569
FPS : 48.427161

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 1920 1080 fullscreen
Starting BitmapLocking in 1920 X 1080 fullscreen default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 10.109041
FPS : 98.921349

Again, not too shabby.

Finally, I tried 320x240, but as already mentioned, it is no longer supported in fullscren (in either DirectX or OpenGL) so I went to the next higher, 640x480 as was suggested and got these results (note: DirectX was so fast I didn't see it, I think I blinked and it was done! )

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 640 480 fullscreen opengl
Starting BitmapLocking in 640 X 480 fullscreen opengl with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 4.968636
FPS : 201.262462

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 640 480 fullscreen
Starting BitmapLocking in 640 X 480 fullscreen default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 1.611690
FPS : 620.466638

Well, that's still about a factor of 2, and a factor of 3 in your last test. If I can get a profiling build working then maybe I can see where all the time is being spent with the opengl driver.

And I think it's actually CPU bound, except for the part where it uploads stuff to the gfx card. What kind of CPU were you using on that last test?

Maybe you should run with more frames. if it opens and closes that fast, its not much of a test.

If OpenGL wasn't so slow I would, but I can use more frames with DirectX though. Really, 1000 frames is a decent sample size, but you're right some of the tests could use more. You can specify the number of frames as the last parameter in the command line arguments to the program.

In all tests I have an "AMD Athlon II X3 440 CPU - 3GHz (3 cores)"

A fairly inexpensive CPU (around $90 Canadian) when I bought it a few years ago.

I also have 10Gigs of RAM(64bit system) if that effects anything at all.

Edit: Okay, I ran the tests again with a sample size of 10000!

CPU: AMD Athlon II X3 440 CPU - 3GHz (3 cores)
Video Card: GeForce GTX650
Driver version: 337.5
OpenGL Version: 4.4
DirectX Version: 11
Total RAM: 10Gigs
Operating system: Windows 7 - 64bit

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 640 480 fullscreen 10000
Starting BitmapLocking in 640 X 480 fullscreen default with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 21.037207
FPS : 475.348283

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 640 480 fullscreen opengl 1
0000
Starting BitmapLocking in 640 X 480 fullscreen opengl with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 57.823506
FPS : 172.940049

A driver update might help. OpenGL depends on the quality of the drivers for gpu pretty heavily.

For a long time D3D was done better on windows because most games used it. But OpenGL is starting to gain more traction again due to ease of porting between OSX, mobile and windows (and a little linux, when the dev cares).

Oh, and because the original poster was insistent on 320x200...

D:\Downloads\Allegro\BitmapLocking>BitmapLocking.exe 320 200
Starting BitmapLocking in 320 X 200 windowed default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 0.865257
FPS : 1155.725411

Could ONLY do it in a Window and any library that states they can do a proper 320x200 or 320x240 fullscreen is just plain lying to you.

I would say 1155 FPS is pretty damn decent!

I ran it on my lappy: core i7 2 Ghz, 6GBDDR3, ATI 7800

Gully, since your processor is so fast, could you run the test with more frames? It's hard to tell if the results are useful or not. Just use like 10000 or something. That shouldn't take too long on your computer. For the 320 X 200 mode you could probably even use 50 or 100 thousand frames as well.

Wow GullRaDriel, on an ATI your test done much better with OpenGL. I wonder if this is common for ATI cards, or just due to your CPU?

I go the following results using 10000 frames (CPU: i7-3930K @ 3.2Ghz, GPU: GeForce 680):

C:\Users\LennyLen\Desktop\bl>BitmapLocking.exe 320 200 10000
Starting BitmapLocking in 320 X 200 windowed default with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 1.254570
FPS : 7970.855553

C:\Users\LennyLen\Desktop\bl>BitmapLocking.exe 320 200 opengl 10000
Starting BitmapLocking in 320 X 200 windowed opengl with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 3.439915
FPS : 2907.048658

C:\Users\LennyLen\Desktop\bl>BitmapLocking.exe 1280 720 10000
Starting BitmapLocking in 1280 X 720 windowed default with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 8.776642
FPS : 1139.387968

C:\Users\LennyLen\Desktop\bl>BitmapLocking.exe 1280 720 opengl 10000
Starting BitmapLocking in 1280 X 720 windowed opengl with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 28.258398
FPS : 353.877101

The program doesn't work for me fullscreen. My monitors flash on and off and I get the following output (no results):

C:\Users\LennyLen\Desktop\bl>BitmapLocking.exe 1280 720 10000 fullscreen
Starting BitmapLocking in 1280 X 720 fullscreen default with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23

That's odd. Especially since it doesn't output the time and FPS - it should do that as long as a display is created, and I know it was because it prints off the pixel format of the screen. Do you normally have problems setting 1280 X 720 fullscreen with Allegro 5? I can't really explain that behavior. You must have one hell of a cpu and gpu given your high FPS in a 1280 x 720 window.

I thank everyone for their help testing this, but I can't really do much unless I can get a profiling build working. And I haven't been able to find a profiler that works as expected on my Vista laptop. If anyone has any ideas, feel free to drop in on my other thread.

The result I got could have been due to my multi monitor setup. I'll try later with only a single monitor.

I've rebuilt your program from your last 7-zip with a fully static monolith Allegro in MSYS2, this is what I get on a test 800x600

Care that the Allegro lib is a Debug build (not optimized), my specs on the Laptop are:

Intel core i3-2330M @ 2.2GHz, 4GB RAM, Intel HD graphics 3000 (Opengl 3.1 context max).

$ ./Bitmaplocking
Starting BitmapLocking in 800 X 600 windowed default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 4.094687
FPS : 244.218891

$ ./Bitmaplocking 800 600 opengl
Starting BitmapLocking in 800 X 600 windowed opengl with numframes = 1000
Pixel format of screen : 9
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 39.137457
FPS : 25.550970

A very noticeable difference indeed.

EDIT: I should add that running fullscreen in d3d mode is fast but i can't get the specs since the program does not print those out.

So it turns out that it was running multiple monitors that was causing the program to not run properly. Once I'd disabled all but my main monitor I got the following results:

C:\Users\LennyLen\Desktop\bl>BitmapLocking.exe 1280 720 fullscreen 10000
Starting BitmapLocking in 1280 X 720 fullscreen default with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 15.039495
FPS : 664.915961

C:\Users\LennyLen\Desktop\bl>BitmapLocking.exe 1280 720 fullscreen opengl 10000
Starting BitmapLocking in 1280 X 720 fullscreen opengl with numframes = 10000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 27.325060
FPS : 365.964428

I've tried it on my home lappy, which is a bit beefier and has two GPUs.

Specs are:
Interl core i7-2670QM @ 2.20GHz, 4GB RAM,

Running with the NVIDIA GeForce 610M (own 2GB mem, opengl context 4.3)

Starting BitmapLocking in 800 X 600 windowed default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 1.448427
FPS : 690.404023

Starting BitmapLocking in 800 X 600 windowed opengl with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 16.744071
FPS : 59.722633

There's STILL a 10x difference in speed...:-/

and with the integrated Intel HD3000 (Opengl context 3.1)

Starting BitmapLocking in 800 X 600 windowed default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 2.322496
FPS : 430.571225

Starting BitmapLocking in 800 X 600 windowed opengl with numframes = 1000
Pixel format of screen : 9
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 30.003446
FPS : 33.329505

That's a big difference also on this "better" platform with the NVIDIA GPU.

I dare say TOO MUCH of a difference, if ony profiling on windows would prove to be a bit goddamn easier...>:(

There is clearly something up with windows's opengl, and our gl code. Some of these tests were probably using MS's opengl... but still the numbers over all are not great.

I've updated the GFX drivers for the NVIDIA GPU and...weird enuff...fullscreen opengl is now MUCH faster that D3D...and D3D looks awful with some translucent black bars (surely artifacts) popping up.

Starting BitmapLocking in 800 X 600 fullscreen default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 10.543454
FPS : 94.845576

Starting BitmapLocking in 800 X 600 fullscreen opengl with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 3.076167
FPS : 325.079932

Something's fishy here

Coounterwise...on the Intel HD3000

D:_user\Pkrcel\coding\BitmapLocking>BitmapLocking.exe 800 600 fullscreen
Starting BitmapLocking in 800 X 600 fullscreen default with numframes = 1000
Pixel format of screen : 23
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 0.481809
FPS : 2075.510044

D:_user\Pkrcel\coding\BitmapLocking>BitmapLocking.exe 800 600 fullscreen opengl

Starting BitmapLocking in 800 X 600 fullscreen opengl with numframes = 1000
Pixel format of screen : 9
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 28.388358
FPS : 35.225707

the D3D code runs....I dare say EXTREMELY fast and OpenGL is an awful slog.

I wonder how much is Allegro's "fault" and how dang much is about drivers...

EDIT: by the way it should be noticed that I didn't touch Intel's drivers so I wonder WHAT coudl cause the speed up.

Some weird opengl conflict with dual gpu setups is my assumption...

I only have one GPU, one monitor etc and it is very slow for me.

Well that was for the other report... But yeah, some opengl issue here.

In fact I have a combo of intel hd 3000 and ati 7800.

There was a bug in the code. You should be able to use anything for the 6th parameter now - before it was trying to atoi("fullscreen") or atoi("opengl") for the num of frames.

c:\ctwoplus\progcode\allegro5\test\BitmapLocking>BitmapLocking.exe 800 600 500 fullscreen opengl
Starting BitmapLocking in 800 X 600 fullscreen opengl with numframes = 500
Pixel format of screen : 9
ALLEGRO_PIXEL_FORMAT_ARGB_8888 - 32 bit : 9
ALLEGRO_PIXEL_FORMAT_RGBA_8888 - 32 bit : 10
ALLEGRO_PIXEL_FORMAT_ABGR_8888 - 32 bit : 17
ALLEGRO_PIXEL_FORMAT_XBGR_8888 - 32 bit : 18
ALLEGRO_PIXEL_FORMAT_RGBX_8888 - 32 bit : 22
ALLEGRO_PIXEL_FORMAT_XRGB_8888 - 32 bit : 23
Total time taken : 36.720223
FPS : 13.616475

c:\ctwoplus\progcode\allegro5\test\BitmapLocking>

I attached a new 7z archive