The usual response is that relative path may not necessarily be where you think it is, i.e. to the executable. Are you checking for file not exists or if the bitmap creation failed?

When I started using A5 recently I found I had difficulty loading stuff as well. Then I learned that A5 has a path-handling system using ALLEGRO_PATH objects. That seemed to solve my problems.

You first create an ALLEGRO_PATH object, then use al_get_standard_path() to get the full path of where your executable is, then you can use al_append_path_component() to go deeper into a directory structure and al_set_path_filename() to set the filename.

Then, to load a file, use al_path_cstr() to convert the contents of an ALLEGRO_PATH object into a string.

Even if this seems overly complicated, it would be good to learn because you can use al_get_standard_path() to get other path locations suitable for storing global data, accessible by all users, or current-user-specific data.

@Kris Asick,

I know that the path is correct :/ I took all of this from my one script version and re-coding it so that I know what's going on since I got lost in the original one.

Yes, Convert the *.dat file to a *.zip file and extract it. You'll notice the images are in there. You can also use 7z to open it as it is.

I would but I really have no clue on how to use it :/

Edit: I get this when I press F8.

I don't get what you mean but I have been sat here trying to work some stuff out and I might have the auto_ptr's setup wrong.

game.h

game.cpp

That's where it is declared and then initialized.

I just tried that and still the same error. :/

Edit: I was given information on how to use auto_ptr within a class before and can be read on these forums ^[1]. However, I have done it correctly according to that :/

I'm going to check this by not using auto_ptr and just allocate it myself to see if it gets rid of the error.

Funny enough, I just edited my last post saying that I am going to see if that fixes my problem.

EDIT: No that didn't fix the error meaning I defiantly set that up correctly. I am now out of ideas on what it causing this.

Taken from game.cpp

This is the first class that is initialized and that initializes Allegro so there is no chance of that happening :/ If I comment out the contents of Graphics::Load() so it only returns -1 then it still gives the error. I don't think it is to do with allegro :/

Graphics is initialized after Game but before Menu so it's defiantly all initialized first.

I will edit this with an attachment to an executable.

Edit: Added the attachment.

But I wan't it to load from menu.cpp like when I get to player I wan't player.cpp to load the player images.

If you want to load your graphics from your menu routine, then your menu routine needs to be made completely aware of your graphics object.

Try this:

game.cpp

this->gfx = std::auto_ptr<Graphics>( new Graphics );
this->menu = std::auto_ptr<Menu>( new Menu );
this->menu->loadgfx(this->gfx);

menu.cpp

#include "menu.h"
#include "graphics.h"

Menu::Menu()
{
  printf( "Menu Started!\n" );
}

int Menu::loadgfx (Graphics *gfx)
{
  return gfx->Load( "gfx/menu_bg.png" );
}

I'm in a rush now and don't have you code in front of me anymore, but I think you can get the idea. Menu doesn't have direct access to your game object which explains why the pointer value is 0x0 when inside your menu routine.

I think you forgot to call al_init_image_addon before you tried to load your graphics. I don't see it in your Game constructor anywhere. Nevermind, I see it in your Graphics constructor now...

#0 004B91C2  std::auto_ptr<Graphics>::operator->(this=0x0) (c:/mingw/bin/../lib/gcc/mingw32/4.5.2/include/c++/backward/auto_ptr.h:195)
#1 0040165E  Menu::Menu(this=0x8d8d858) (E:\Projects\Jump Pacman\src\menu.cpp:7)
#2 004018B2  Game::Game(this=0xa53a20) (E:\Projects\Jump Pacman\src\game.cpp:38)
#3 004015CC  main(argc=1, argv=0xa527d0) (E:\Projects\Jump Pacman\src\main.c:5)

See the part in frame #0 where it says 'this = 0x0'. You're trying to dereference a null pointer somehow. I don't know how the address of the auto_ptr got to be null though.

I see what you did.

src\game.h line 33 :

extern std::auto_ptr<Game> game;

src\game.cpp line 3 :

std::auto_ptr<Game> game;

src\main.c line 5 :

    std::auto_ptr<Game> game( new Game );

If you had turned on all of your compiler warnings, you would have noticed this :
src\main.c:5:29: warning: declaration of 'game' shadows a global declaration
(With gcc/MinGW use -Wall and -Wshadow)

So the reason the Menu constructor is crashing is because it uses the global 'game' variable, which has been initialized by the default auto_ptr constructor, which is unable to guess where your object is located, which is why it was trying to dereference a null pointer.

If you don't know how to use the debugger, I suggest you do it now before you go any further down your programming path.

You mentioned pressing F8, are you using Visual Studio Express 2005?

I've never used code blocks but given it's just a front end to mingw you enable the debugging symbols and hopefully c::b includes the debuger.

A quick google says go to the compiler options and tick the box 'produce debugging symbols', then everything else is done via the debug menu like start/stop/jump over/jump in (probably keypresses if you look closely enough in the menu).

That'll get you started in your code (allegro will still be out of bounds as far as drilling down, but most of the time you don't need to anyway). Couldn't be simpler