- Online Community Forums » Programming Questions » Scope issues trying to pass a gobal bitmap to a function

This thread is locked; no one can reply to it. rss feed Print
Scope issues trying to pass a gobal bitmap to a function
Member #4,372
February 2004

I know, I know.. You are going to ask me why am trying to pass a global to a function? Why not just alter the global in my function or just return the pointer?

I'm porting a game that used an index of numbers that kept track of memory buffers holding video memory.. i.e.

#define BUFER1      1
#define BUFER2      2
#define BUFER3      3

and then they load graphics by calling a command like so

LoadPic("background.png", BUFFER3); // LoadPic(char *filename, int buf);

Now I though "Aha! I can make this transparent and change LoadPic() to load Allegro bitmaps into a global space. I'll just change the types like so...


and change the declaration to something like.

LoadPic(char *filename, ALLEGRO_BITMAP *buf);
buf = al_load_bitmap(filename);

Then calling the same exact command will do the same thing right?

LoadPic("background.png", BUFFER3);

But alas, inside Loadpic, I'm losing the scope. *buf us getting the address to the bitmap, but the thing I passed to it, BUFFER3 is not.

Is there an elegant way of doing this? The reason why I'm so keen is that if I can wrap the graphic lib around allegro, I have to do next to nothing to port the code of the game itself...

Maybe there is a way I can use the old index? I'm kinda stuck.

Edgar Reynaldo
Member #8,592
May 2007

You have to use a pointer to an ALLEGRO_BITMAP*, ie. ALLEGRO_BITMAP**. Read up on pointers and references. buf isn't getting set because it's a local copy of a pointer. It's not changing the memory at the address of that pointer you passed in, which is what it should be doing.

Member #4,372
February 2004

That worked, but it turns out looking at the original code, the reason why it used indexes was because it was was an array of buffers, which is what the code is more expecting. I allocated a global array of Allegro bitmaps and reference the via the old method which was better anyway...

I don't know why C pointers kick my rear end all the time. It's not that I don't know what one is, its just that C expresses them is such a strange way. What's even worse is that the * is derived form an assembly operator that does the same thing, and I cut my teeth on 6502 assembly back in the day.

* ORG = $800 ;(Merlin ASM)

The way I remember it is thus.

* = at address
& = value at 

int  a; //container size integer a
int *p; //container size integer, at address p

a=&p; //a equals the value at p 

ALLEGRO_BITMAP *buffer = NULL // container of ALLEGRO_BITMAP, at address "buffer", initially assign to ram location 0

Reading it has always been tricky

Edgar Reynaldo
Member #8,592
May 2007

The way you remember it from assembly is backwards from what it really is. & means address or reference. * means pointer to or the data referenced by the pointer.

int i = 1;
int* ptr = &i;
*ptr = 3;

i is now 3

Read them from left to right :
int pointer ptr assigned the address of i
data pointed to by ptr assigned the value 3

Having the address of a variable allows you to change its contents, by means of the pointer.

Bruce Perry
Member #270
April 2000

A key to understanding the syntax is that the declaration "reflects the usage". You always have the primitive type (e.g. int) first, but apart from that, everything written around the name (e.g. the *) is the same as what you would use to get back to the primitive type.

int *p; //means you can write *p to get an int
int (*f)(); //means you can write (*f)() to get an int

It looks as if you thought the * meant 'take a pointer' and therefore the & must do the opposite. Hopefully this clarifies what's really going on.

Bruce "entheh" Perry [ Web site | DUMB | Set Up Us The Bomb !!! | Balls ]
Programming should be fun. That's why I hate C and C++.
The brxybrytl has you.

Go to: