Vanille code crashes
#00JMP00

I do this with 5.010:

#SelectExpand
1 2al_lock_bitmap (DTA); 3al_set_target_bitmap (DTA,al_get_bitmap_format(DTA),READwRITE); 4a_draw_filled_rectangle (0,0,300,300,al_map_rgb(0,0,0(int))); 5 6al_unlock_bitmap(DTA);

Code will crash reliably when drawing or clearing the bitmap.

Can someone help with this thing??

RPG Hacker

Is there a special reason why you're locking the bitmap before drawing onto it?

#00JMP00

Is there a special reason why you're locking the bitmap before drawing onto it?

Actually yes. The manual tells me to do it :-))

RPG Hacker

Where exactly? Can you put the link here?
al_draw_filled_rectangle, as the name suggest, should be a drawing operation. And drawing operations normally don't require you to lock the target bitmap. I couldn't find anything in the manual that says to lock the bitmap before calling al_draw_filled_rectangle. Where did you read that?

Elias

In fact [1] says:

Quote:

Note: While a bitmap is locked, you can not use any drawing operations on it (with the sole exception of al_put_pixel and al_put_blended_pixel).

Michael Moffitt

I don't understand the confusion. You are very specifically doing drawing operations, which won't work on a locked bitmap.

#00JMP00

Actually I thought, bitmaps have to be locked to keep them from being changed otherwise.

At this current state it seems, it crashes without being locked too. Later I will have another look at it.

Update

It is as stated above. It changed position a little - after returning from this routine - but the effect stays the same. Using draw/clear crashes the program.
Could it be something with incompatible linked libraries???????

RPG Hacker
#00JMP00 said:

Actually I thought, bitmaps have to be locked to keep them from being changed otherwise.

Nah, locking a bitmap has nothing to do with "protecting" it. I have to admit that the terminology can be a bit confusing. When you lock a bitmap, everything that happens is that you map its memory to the CPU. So depending on how exactly you lock the bitmap, you can either read its pixel data that was previously on the GPU, write new pixel data to the bitmap on the GPU or do both.

Quote:

At this current state it seems, it crashes without being locked too.

Can you post your whole code? Aside from the locking, there is nothing obviously wrong with the code above (except for your usage of al_set_target_bitmap, which normally takes only one argument, but I don't think that's the problem here).

#00JMP00

I post some of the relevant code. Posting the whole code wouldn't facilitate things.

#SelectExpand
1 2#include <allegro...> 3#include ... 4#include... 5 6 7 8 9void clear_to_color (ALLEGRO_BITMAP *DTA,int r,int g, int b); 10 11void clear_to_color (ALLEGRO_BITMAP * DTA,int r,int g, int b) { 12 13 14// al_lock_bitmap (DTA,al_get_bitmap_format (DTA),ALLEGRO_LOCK_WRITEONLY); 15 16 17// al_set_target_bitmap (DTA); 18al_msg("farbe int"); 19 20// al_clear_to_color and al_draw_filled will both crash the program 21al_clear_to_color (al_map_rgb(r,g,b)); 22 23// al_draw_filled_rectangle (0,0,BM_W(DTA),BM_H(DTA),al_map_rgb(r,g,b)); 24 25al_msg("unlock"); 26// al_unlock_bitmap(DTA); 27return; 28 29} 30 31int main (vip arguments :-)) { 32 33 34ALLEGRO_BITMAP *SBB = al_create_bitmap (1024,768); // Values are somewhat unimportant 35 36clear_to_color (SBB,0,0,0); 37 38// Program will have crashed now 39 40 41 42}

To avoid the question in advance, the code crashes at runtime.

RPG Hacker

Did you initialize Allegro and all relevant sub systems? (with al_init() etc.)

#00JMP00

I guess yes.

I omitted this point and continued my way through the code.

Now I unearthed another issue:

Assertion failed: bitmap != destination && bitmap != dest->parent, coming along
with a none existing path, ending "allegro-git\src\bitmap_draw.c line33".

- It makes me wonder -

Edgar Reynaldo

It says 'make sure the source bitmap is not a sub bitmap of the destination and make sure you're not drawing to yourself', basically. So you're doing one of those two things somehow.

#00JMP00

Yes, I figured that out - thank you anyway.

The assertion failure is gone, but it still crashes. The assertion was
somewhat blind.

Maybe I get rid of the rest too.

Edgar Reynaldo

Use a debugger like GDB or MSVS built in debugger. Get the stack / backtrace from where it crashes, and then you can see why it is crashing by examining local variables usually.

#00JMP00

Using the debugger, once setup, was easier than thought. Unfortunately the come out wasn't worth the effort.

The error seems to change position sometimes. At the end I can tell, that location and/or size of an object (bitmap) shall be resolved. Last registered access is to ntdll.dll and allegro.../bitmap.c. There the value 0x0 is returned. I guess the value shouldn't be 0x0, thus crashing the program.

All object are in good order :-) and I do not understand this behaviour.

Update:

I found, when I use my function BM_h() - returning height of a bitmap, there will be a wrong value. Just now, program crashed with -5901xxxxx. I guess negative values are not possible.

Hmmm.

RPG Hacker

Are you checking all your pointers for NULL before doing anything with them? It sounds like you could accidentally be passing a NULL pointer into a function that doesn't support NULL pointers, thus the crash. I'd check that.

#00JMP00
Quote:

Are you checking your pointers...

I did and they where ok. Besides this, they are initialised and in use, though code would crash at other position.

Additional question

As I posted above, the assertion failed pointed to a none existing allegro ressource. Why is this? The path to the object requested d:/librariers/allegro... ist completely none existing and probably never existed before.

RPG Hacker
#00JMP00 said:

As I posted above, the assertion failed pointed to a none existing allegro ressource. Why is this? The path to the object requested d:/librariers/allegro... ist completely none existing and probably never existed before.

This probably refers to a path on the system the Allegro libs were build on. Or did you build the libs yourself?

Dizzy Egg

You've got to tell your 'clear_to_color' function which BMP it should be clearing!!

al_set_target_bitmap

#00JMP00

There it was, but then has been outcommented :-))

It doesn't work anyway.

There still occurs an error when calling al_get_bitmap_height, in my version.

Error is still at ntdll.dll/allegro/bitmap.c.

Someone said, pointer is probably NULL, but the bitmap is set, since
the size can be read at other position. Looking at the debugger error,
it really seems to be this, but I can't change it.

Dizzy Egg

I can't see al_get_bitmap_height in your code!?

#00JMP00

Then you have anther look and reread my last posting.

RPG Hacker

I did. There IS no al_get_bitmap_height in the code you posted above.

#00JMP00

Well, op was refering to al_set_target_bitmap...

therefore I was refering to this.

But at a closer look, even al_get_bitmap_height is there,
somewhat coated by a shorter version:

#SelectExpand
1 2 3int BM_H (allegro_bitmap *DBM) { 4 5 6return al_get_bitmap_height (DBM); 7}

To eliminate the possibility of a problem here, I hand
wrote it in my version...

I actually would't want to put my code here.

Edgar Reynaldo

If al_get_bitmap_height is returning crazy values it is because you are calling it on an uninitialized or dangling ALLEGRO_BITMAP*.

Thread #615612. Printed from Allegro.cc