Is there a limit in bitmap size in A5? My A4 program had megatexture bitmap of 3200x3200 but in A5 it seems like it is not possible to make bitmaps larger than about 2000x2000 (2000x2000 works but 2100x2100 does not work).

Yes, and it's dependent on the video card: al_get_display_option(display, ALLEGRO_MAX_BITMAP_SIZE). The limit applies to video bitmaps.

Usually the limit is a power of 2 so your limit is probably 2048x2048. A4 let you make arbitrary sized ones because it was limited by your ram since a4 is software rendering and memory bitmaps.

This reminded me that al_get_display_option(display, ALLEGRO_MAX_BITMAP_SIZE) was broken in earlier versions. I just checked and it seems that it's now fixed, kinda.

If I remember correctly, on my machine the limit when using OpenGL was 2048 while on Direct3D it was 1024. Allegro reports the size limit on both as 2048. As I have a really ancient graphics card it may be an error on my side with the card reporting an incorrect size.

Anyway, the weird thing is that in Allegro 5.0 attempting to create a bitmap bigger than ALLEGRO_MAX_BITMAP_SIZE caused an assertion. In Allegro 5.1, however, it seems like it actually succeeds in creating the bitmap; drawing the bitmap becomes really slow, though. Is this normal? is Allegro 5.1 automatically falling back to create a memory bitmap? can someone confirm this?.

5.1 falls back to a memory bitmap if you don't explicitly request a video bitmap via the ALLEGRO_VIDEO_BITMAP flag. So if you don't care, don't set either flag.

Basically it now treats a bitmap without either flag as an "auto" type, where it tries to be accelerated if at all possible. So if you, say, load a small image before creating a display, then create the display, it will automatically upgrade it to a video bitmap. (I think that's what eventually was implemented after long discussions...)

So in a nutshell, with 5.1: if you must have a memory or video bitmap, then you need to explicitly set the appropriate flag.

OK, I guess it makes sense. Thanks.

What happens with CPU's with GPU's incorporated like the one I've got

A3850 AMD A8

?

Same thing.

What about minimum bitmap size?.

In my code I'm drawing a patterned line using al_draw_prim() and creating a 2x2 bitmap works fine in OpenGL but in Direct3D it's obviously bitten by this so, for example, I get:

With OpenGL:
{"name":"patternogl.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/9\/59e729fcbad9359036c818da555c2eb3.png","w":636,"h":474,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/9\/59e729fcbad9359036c818da555c2eb3"}
With Direct3D:
{"name":"patternd3d.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/d\/7d452b88069636c26127045ac9318b24.png","w":637,"h":478,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/d\/7d452b88069636c26127045ac9318b24"}

Is there a way to query (currently it's not possible with al_get_display_option()) the minimum bitmap size? or is it better to always assume a minimum size of 16x16?.

The minimum size is 1x1. There seems to be a bug in al_draw_prim or the D3D driver though.

I thought it was related to the minimum texture size as mentioned in the documentation because it clearly coincides with a 16x16 bitmap size.

Yeah, there's some weird DirectX-only hack with bitmaps smaller than 16x16. Not sure what that is about. If we really want a minimum size should document that better I think - but better would be if it could be fixed.

MSDN says nothing about 16 pixel minimum size at least: http://msdn.microsoft.com/en-us/library/bb174363%28VS.85%29.aspx

I'd say that indicating in the documentation that on some cards 16x16 is the minimum supported (and a safe minimum to assume) bitmap size is better if that keeps the code cleaner.

Ok, thanks for the replies. I think I'll just skip the mega texture idea and go for 5x5 640x640 textures instead so make sure there won't be any issues running the game on any machine. Thanks.

EDIT: That didn't work so well either. Game was only able to create the 640x640 up until 3x4 (12 bitmaps) then the al_create_bitmap fails to create. Why is this? Even more limitations regarding bitmaps?

Maybe you ran out of vram?

Just for the heck of it, try power of two sizes. like 512, or 1024.

Ok, I'll try it....

EDIT: So the code tries to make 5x5 bitmaps of 640x640. This crashes when trying to make the 20th bitmap. When changing size to 512x512 all 25 bitmaps can be created.

640x640x19 = 7782400 pixels
512x512x25 = 6553600 pixels

Never tried this in A4 but then I was able to make a single 3200x3200 instead.

3200x3200 = 10240000 pixels

It's pitty the swap from A4 to A5 has generated issues not available in the old A4 version of my game.

Were you using memory bitmaps in Allegro 4? You can create memory bitmaps in Allegro 5 as well, but they will be much slower than video bitmaps.

Some cards or drivers don't work with < 16x16 and D3D in my experience, that's why the limit is there. It looks like you're drawing the full 16x16 in your example there ken, when you should only use a 2x2 piece of it.

This is how I did the 3200x3200 bitmap (and all other bitmaps) in the A4 version of the game:

#define LEVEL_SECTION_SIZE 640
#define LEVEL_SECTIONS 5
megatexture = create_bitmap(LEVEL_SECTION_SIZE * LEVEL_SECTIONS, LEVEL_SECTION_SIZE * LEVEL_SECTIONS);

Don't know if this is video bitmap or memory bitmaps. I've always made them this way.

EDIT: The 512x512 bitmaps in A5 fails to create when doing 9x9 of them. Returning null at number 74.

That's a memory bitmap. You'd have to set ALLEGRO_MEMORY_BITMAP in 5.0 to achieve the same effect. But why do you need such a large bitmap?

It's been like this since the beginning of the project just to make it easier to open up the image (generated in the editor) in Photoshop and check the result. I was going to add the final 5*5 bitmap system later but did it now instead.

The megatexture is temporary for adding dirt, stains and debris on the floor sections. The added details can be intersecting between the sections so adding them first on the big texture and then creating 25 640x640 bitmaps.