I have started to re-code Jump Pacman because the code got very very messy but now I can't even load an image without it crashing.

I have attached the entire project without the lib and include directory. (Setup using static libs Allegro 5.0.3)

Anyone have a clue to why this is happening.

This is where it seems to break.

Hope someone can shed some light on this matter.

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?

I am to the archive and it loads that. I know for a fact that the image is in the correct place too. It just seems to crash when calling that function and I've written the function that way many times before without error.

This is what the Load function does.

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.

Did you actually create the game, gfx, and bitmap objects?

And there's no shame in using a debugger

@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 was thinking about the objects in the code, not the data files.

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.

Oh... you're using PHYSFS... That would've been helpful to know ahead of time.

I took a look at your entire codebase... I know this sounds trivial, but try changing your vector definition in graphics.h to this:

std::vector<(ALLEGRO_BITMAP*)> bitmap;

Dunno if this will help but I seem to recall having issues using pointers and vectors in the past.

Beyond that, it would help to know exactly which line of Graphics::Load() is crashing the program, whether it's the actual Allegro load itself or your vector handling commands afterwards.

EDIT: Oh, and I've never used auto_ptr objects so if that's where the problem is then I wouldn't've had a clue.

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.

Though... why are you using auto_ptr objects? Just to get around cleanup code? Couldn't you just use "new" and "delete" commands as usual?

gfx = new Graphics;

and in Game::~Game():

delete gfx;

I dunno, that just seems simpler to me, and then it would be far more obvious when and where these objects would be created and destroyed.

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.

Are you absolutely sure that Allegro is initialised before you try to call any Allegro functions? There are no global variables anywhere with constructors that that call Allegro functions?

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.

I think I know what the problem is, and the fact it's letting you compile and link with this going on is... weird.

Basically, your "game" object should NOT be accessible from menu.cpp.

Try this:

1. Remove the following line from menu.cpp:
game->gfx->Load("gfx/menu_bg.png");

2. Add the following line after creating your new gfx object in game.cpp:
this->gfx->Load("gfx/menu_bg.png");

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.

Can you single step through and into your code and see what might be happening, e.g. the objects are null as mentioned, etc.

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 could just do that and pass the gfx pointer into
this->menu = std::auto_ptr<Menu>( new Menu( this->gfx ) );

or
this->menu = std::auto_ptr<Menu>( new Menu( this ) ); because I need to get input when I set that class up too xD

Edit: I don't know how to step though the code as I don't know how to use the debugger.

Edit 2: I am going with passing a pointer to the class constructor and storing a pointer to it.

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.

, Stupid me. I shall turn on all compiler warnings now. I have a banging headache at the moment so when the paracetamol kicks in I shall work on it.

Thanks

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?

Nope, Code::Blocks 10.05

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

Thanks Neil

Sorry I didn't reply back so fast I was busy with animating the menu. It looks more like The Simpson's now.

{"name":"604415","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/9\/69fb4283685592832ffb2b55f6c0fa22.png","w":640,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/9\/69fb4283685592832ffb2b55f6c0fa22"}