Hi, I'm a new member here and hope I post my question on the right forum.

I have a problem with my game, RallyCross, which I have developed with the DevC++ and allegro graphical library. The game only starts on those computers which have DevC++ and allegro installed I copied alleg42.dll to the game's directory, because otherwise I got a dialogbox that this file is missing. By the way, I have programmed this project using static dll-mode.

When I execute the game, then a dialogbox is appear and tells something like the program has been closed... Note that this is happening on a computer which don't have DevC++ and allegro installed. On another computer the game's splashscreen shows up, but don't the menu which should appear thereafter.

On the computer which I've programmed the game, it starts directly from this directory. In the RallyCross directory I have the exe-file, a readme-file and a save-file. There is also a subdirectory, graphics, where I have all the graphics which is used by the game.

I think some file is missing which should be in my game-directory, because it runs on any computer which have DevC++ and allegro installed, but if they don't have it, the game doesn't start...

I have also thought that my problem depends on some paths in my code. Because when I first started the game on a computer which don't had DevC++ and allegro, the game doesn't started at all, but after I changed my paths to the graphics, so they look like the example below, the splashscreen is appearing, but not the menu

Example how my paths look like in the code:
"Graphics/Splashscreen/load_2.tga"

But now I don't think this problem is because the paths, because as I wrote before, it starts on computers with DevC++ and allegro, so it's must be some file missing...

I would be very glad if some of you guys could help me with this problem and solve it, because this game I've programmed is a project in a course I've red and it must be working on any Windows computer! It's kind of a short premonition because I'm going to deliver a talk about the game now on friday!

Be sure to check the return values of Allegro's functions, like load_bitmap! They'll tell you the moment something goes wrong, which should help you get to the root of the problem.

Okey, but how do I check the return values? I don't think I understand exacly what you mean.

Not checking return values:

BITMAP * bmp = load_bitmap(...);

/* Can you rely on the validity of bmp?
 * What if something went wrong in load_bitmap,
 * like the file couldn't be found?
 */
blit( bmp, ... );

Checking return values:

BITMAP * bmp = load_bitmap(...);

if ( bmp == 0 ) {
  // Oh noes! Something bad happened!
  allegro_message( "bmp couldn't be loaded!" );
  exit( 1 );
}

/* From this point on, we can rely on the
 * validity of bmp.
 */

The same applies for many Allegro functions, like initialization routines. Of course, above code is just to show what I meant, and can be highly improved with better logging and taking measures to somehow stabilize the game without need to abort it, but that's quite a job and also not always possible, so don't break your head over it.

edit: Of course, which functions return their success, and how to check their return values is documented in the Allegro manual.

Ahh, now I understand what you mean! Thanks, I'm going to test it.

Read the manual, which documents error checking for many functions.

Indeterminatus: I checked the return values for all the images for my splashscreen and the image for my menu, but there wasn't any fault So, I presume that the program find all the images so far. I even tried to copy my project directory to another path and tried to check the return values from there, and it worked! What else could be wrong?

So, your program was in directory A and it didn't bring up any errors, and you moved it to directory B and it stll worked? Are you hardcoding the image locations (i.e. "C:\mygame\dira\" etc..)?

Yes, so was the case. No, my paths don't look like this anymore, "C:\mygame\dira\" (first I accidently wrote my paths so, but then I changed), the now look like this:

BITMAP* load_2 = load_tga("Graphics/Splashscreen/load_2.tga",palette);

Graphics is the subdirectory of RallyCross.

Do you launch the game via Dev-C++ or via the shell?

How do you mean by the shell? You mean the exe-file?
I've launched the game via DevC++ when I checked the return values, I compiled and then executed the game thereafter. This is the so called project dir with all the sourcecodes, headerfiles...

I also have a "game directory" with only the exe, a readme-file and the Graphics subdir. This dir is working on any computer with DevC++ and allegro but not on any others. I have also tried to copy my project dir to another computer, but it's not working.

I'm still a newbie, and don't know anything about distribution, but I was having a similar problem, and it was solved by debugging my project(F8). I don't even know what it does, but it worked, so I'm happy

Okey, did you just press the debug (F8) and it fixed your problem? I'm going to test it now!

Well, after debugging it, it worked on my friend's PC... Hope it works for you too...

No, it didn't worked after debugging But I got two error dialogs:

The first has the title "Microsoft Visual C++ Runtime Library
Runtime Error!
R6034
An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.

The second has the title "RallyCross.exe"
I translate this dialog because this came in swedish (my Windows is a swedish version, but the first dialog came in english ).

It wasn't possible to initiate the program correctly (0x0000142). Click on OK to exit program.

EDIT:
Everytime I start a new allegro project, I must go on to project | project options | parameters tab | and add "liballeg.a" under the title "Linker". Maybe my allegro isn't correctly configurated with DevC++? Shouldn't DevC++ choose the linker automatically every time I start a new project?

I tried to start the game from the game-dir (the dir with only the exe, readme, savegame, graphics-dir and alleg42.dll), and it doesn't even start on this computer which I have allegro and DevC++ installed on! I got a dialogbox which says that the file "MSVCR80.dll" couldn't be found But if I start the exe from the project-dir, it works correctly.

.. Umm, Why is it trying to load MSVCR80.dll ? Have you had ANY allegro programs compile and run?

try this:

/*save this as main.cpp in a new Dev-C++ project.  Make sure it is a Win32 application and that your linker includes liballeg.a */
#include "allegro.h"

int main()
{
    allegro_init();
    allegro_message("All is well!");

}END_OF_MAIN()

Compile and build this. Then try running the .exe file

What do you mean by "static dll-mode"?

Are you talking about the way you've built Allegro, eg. for static or dynamic linking? because if you are getting messages saying that alleg42.dll is missing, then you have built Allegro for dynamic linking.

If you mean the Project Type setting for Dev-C++, then there is a win32 static library type, or a win32 dll type, but not a static dll type, which would be contradictory. Either of these are not what you want anyway, you want to build a win32 console application.

If you moved the entire directory, including the graphics subdirectory, then of course it's still going to find the images.

Yepp, all allegro programs are running (those I execute from their project-dirs, which have all files in it, the source-files, header-files... but if I execute the program from the game-dir where I only have an exe-file, graphics-dir, save-file, readme, then it does'nt start).

I tried your test-snippet and it worked correctly and I've got the dialogbox telling me that everything is alright. I tried to compile and run (this executes the exe from the project-dir, and I've also tried to copy out only the exe-file to another place and started it from there and it also worked!).

Yes exactly, I've chosen static linked when I created this project. I'm trying to create a new project now and choose static linked and then in project options choose win32 console (because now I have the "win32 GUI" marked").

EDIT:

I tried to create a new project and choose static linked, and pasted in my old code and in project options i choose win32 console. It worked to start the exe from the project-dir, and also if I copied only the graphics-dir and exe to somewhere else. Note that this was on this computer which I have DevC++ and allegro installed on. I tried to choose win32 GUI in project options (this is standard if you choose static linked), and it worked perfectly. The difference was when I've choosen console-mode, a console-box was appearing behind my game, and when I've choose GUI-mode, only my game was appearing and this is how I wanted it.

So, I've chosen "static linked" and as I wrote above it worked on this machine. BUT, when I've copied over the Graphics-dir and exe-file from the project-dir to another computer without DevC++ and allegro installed on, the game was searching after alleg42.dll How could this be possible when I've chose static linked Anyhow, I copied the dll to the this directory and then it was searching for the MSVCR80.dll again

EDIT2:

Could I send my project in a zip-file to someone who can fix my problem? Because no I'm heaving really huge problems because I copied my project-dir to my laptop (where I have DevC++ and allegro installed) and compiled and executed the game. The splashscreen started, the menu appeared and all menuchoices worked except the almost most important, when I press 1 for loading the track... for playing, the game crashes If the game doesn't work on any computer, I must show my teacher the game on my laptop, but if it doesn't work on that eather, I have a huge problem So, please, can someone help me?

You need to not only choose static link in the IDE, but also use the allegro static link lib.

This may be a DLL-hell. Maybe some part of your project is using dynamic-linking and some other is using static-linking. This may also appear if you're using some third-party library based on allegro which is dynamic-linked while your project is static linked or vice-versa or something like "part A of project uses Allegro 4.2.0 and part B uses Allegro 4.1.17 (or whatever version)".

May be something related to a corrupt allegro installation. E.g. You could get a corrupt allegro installation if you compiled allegro with sources from different versions mixed. This may occur if you install an old version and sometime after that you try to overwrite their sources with a new version.

This could be too a problem about color depths. Is possible to get some "weird", "annoying", "nobody knows why", "only work on some computers" errors because of problems about color depth or making some assumptions about which video-mode or video resolution allegro would take.

Try switching to MSVC++6 ill fix for you in an instance.

How will using MSVC 6 help?

It won't. But anything piccolo says can be safely disregarded.

Unless it's about his game.

After I told this problem to my former programming teacher, the game is now working on my laptop and any other computer with devc++ and allegro installed. He told me that some resources were wrong. So the game is running and I can show it to my teacher today But it doesn't work on any other computers, but I'm glad it's working on the laptop so I at least can get a grade.

I'm probably going to uninstall DevC++ and allegro then, because all of these weird problems I've had. I think that something maybe went wrong in the installation process of allegro. I have also heard that DevC++ compiler etc. is kind of otherwise and sometimes weird.

So, I think I'll install Visual Studio 2005 Express instead and allegro to it, is it a good choice? As far as I know, the Visual Studio 2k5 Express is free to use? Is it so even for commercial projects? Is it free for anyone? And where can I download it (you've got a direct link)?

While I personally dislike the Dev-C++ IDE, it's not the source of your problem. There are many people on this forum who use it regularly without experiencing any of the problems you describe. Based on this, and what you've said so far in this thread, it's more likely that the problem is simply that you have no idea what you are doing.

Do you have the allegro runtimes on the computers it doesn't work on? Try putting alleg42.dll in your executables directory. I don't know...

@ _mEck0: Can you zip up and attach your code?

Yes, I can... I showed the game for my teacher, it was ok, but I must fix the problem so it executes on any computer... Maybe something is wrong with the paths.

Thank you very much, I really appreciate your help, because this problem is very important for me.

_mEck0, please see this.

Okey, I understand that now.

I'll say it again: Real men don't need IDE's.

Really, to learn programming, I can only advise to use nothing but a good editor and the command line. This way, you learn how to do things on your own; you'll understand what a compiler is, what a linker is, and what all those different file types (.cpp, .h, .o, .a, .dll, .exe, makefile) are for. You'll also learn to use proper coding style.

Once you've gone through that hell and know what you're doing, then go and use an IDE to make your life easier (unless you like the amount of direct control the 'spartan's IDE' gives you).

My personal choice is command line + SciTE. SciTE is basically an editor with syntax highlighting, a light app that starts quickly and doesn't use resources to do unnecessary fancy stuff, but it still has some rudimentary IDE functions like F7 to invoke make, and it understands g++ output so you can jump to the error directly.

Thanks for the tips!

great choose msvs 2005 is nice but see if you can get your hands on msvs6 ,it has much more goodies to help you do flasher things with ease. and its is very stable;D

Flames Tobias with a IDE +1 spell!

Um... I thought you said you didn't use absolute paths:

     BITMAP* load_6 = load_tga("C:/bilspel/RallyCross/Graphics/Splashscreen/load_6.tga",palette);
     BITMAP* load_5 = load_tga("C:/bilspel/RallyCross/Graphics/Splashscreen/load_5.tga",palette);
     BITMAP* load_4 = load_tga("C:/bilspel/RallyCross/Graphics/Splashscreen/load_4.tga",palette);
     BITMAP* load_3 = load_tga("C:/bilspel/RallyCross/Graphics/Splashscreen/load_3.tga",palette);
     BITMAP* load_2 = load_tga("C:/bilspel/RallyCross/Graphics/Splashscreen/load_2.tga",palette);

Your code also throws up several compiler warnings, some of which you shouldn't have ignored (I'm giving you the benefit of the doubt, and am hoping that the ones refering to unused BITMAPS are for as yet unimplimented features). And while I can get the code to eventually compile without warnings, it crashes immediately when I run it. You haven't implemented any error checking, and I'm not in the mood to add any to see if I can find out why it's crashing.

Your program also needlessly includes "winalleg.h", and I think you need to ask your teacher what the purpose of header files is, as you have function declarations and defnitions scattered willy nilly through your source and header file.

I second Tobias, learn how to program using just a text editor and the command line. Once you understand how things work, then start using more complicated tools like an IDE.

However, I think that using the command line in Windows SUCKS. If commandline, then Linux.

Lenny, look out for the tiny blue monsters!

Right, to the point:
load_bitmap() isn't the only allegro function that can fail, actually, most can. Especially the initialization routines (setting gfx mode etc.) are definitely worth error-checking.
Then; learn to debug. Debugging is not pushing the F8 key. Debugging means inspecting the program while running to see what exactly is the problem. For this, it is common to use a debugger (MSVC comes with one), which is a tool that enables you to execute your code step-by step (much like an interpreter), define 'breakpoints' (lines at which the program will pause), inspect the values of variables at run-time, and get a 'call stack' (list of function calls that got you where you are in the code). Very useful, but unfortunately, many debuggers suffer bugs, or are hard to understand; with the exception of JIT (just-in-time) debuggers like DrMingw - these programs only kick in after the program crashes; they will then show you where and how the program crashed (though it's up to you to figure out why).
If you don't want to use a debugger, the least you can do is put lots of printf() or TRACE() statements into your code to find out where exactly the program crashes. I like to use printf("%s, %i\n", _FILE_, _LINE_); which outputs something like "main.cpp, 21", meaning that everything worked well until at least line 21 in main.cpp.
Use this technique to boil the problem down to, ideally, a few lines of code. Write a 10-line program that has the same problem, and someone will fix it.

Go on, flame me.

[edit]
The command line in windows xp is much better than the win98 one, though far from linux. There is a windows version of bash somewhere though IIRC.

BITMAP* load_6 = load_tga("C:/bilspel/RallyCross/Graphics/Splashscreen/load_6.tga",palette);

These sentences I just wrote when I tested som stuff, because I don't have absolute paths on any other place in the code.

I'll accidently forgot to remove the include of winalleg.h. From start I wanted to make an win32 gui, but this programming course was pretty small so I didn't have much time to program.

I just got one warning when I compile, but I'll take a look and try to fix it. Yes I know what a headerfile is, I have programmed before, but not anything "big" as this project, just small stuff we needed to do in school, and I haven't barely used allegro, so can you please explain what you mean by function declarations and definitions scattered willy nilly through the source code? I have programmed before, but I still see myself like a newbie (even I can a lot more then a "real" newbie who just started to code), so can you give an example what is wrong with my declarations and definitions? Actually this is the way I've learned to write from school. Because I want to correct and learn from my errors and by the way, everyone is a newbie from start and doesn't program like a more experienced programmer. It takes time to learn

I'll remove the link to my project files now, but thanks for helping me.

Once, again, ignore piccolo about MSVC 6. If you're actually interested in it, you can find more info, including on setting up Allegro, here

MSVC Express is free.

Okey, I understand.

Then you either need new teachers, or to pay more attention.

A header file should NOT include any funtion definitions, just declarations. If you're going to put them both into the same file, then you may as well just rename it .c/.cpp as it's a source file, not a header file.

Try reading this: http://en.wikipedia.org/wiki/Header_file

I can't remember that my teacher said that you shouldn't do so and when she looked at my source code, she didn't asked why I did so, probably she doesn't know it either (she doesn't have so much programming experience as far as I know). But I'm glad I've found this site so you guys can correct my mistakes Thanks for the link, I'll read that now and correct the fault in my code.

The reason you don't want functions declared in a header file is because the header file gets included into many .c/.cpp files. (or otherwise just put the #defines etc. in the one file unless it's for a library). BUT if you have a function in that header file, all the .c/.cpp files will all tell the linker that THEY have the one true function. So the linker complains that it can't tell which one to use or just picks one at random.

Similarly you don't want to have variable names that are the same as function names (in C anyway) since compilers/linkers aren't smart enough all the time.

Oh, I'm so happy now that it's indescribable I have fixed the bug which did that I couldn't execute my game on any computer! I copied the game-dir to a computer which I don't have allegro and DevC++ installed on, and it worked correctly, Windows doesn't search for dll-files anymore...

I fixed some warnings (there is one left to fix), then I corrected som paths and I moved the functiondefinition (for the "settings"-function) from my headerfile to the main cpp-file, and that's it

Thank you guys, without your tips and comments I don't think I've had fixed it so fast...

Granted it looks like this problem is solved, I would like to mention _mEck0 that Dev-C++ does have a debugger that does just as Tobias Dammers said:
Debugging means inspecting the program while running to see what exactly is the problem. For this, it is common to use a debugger (MSVC comes with one), which is a tool that enables you to execute your code step-by step (much like an interpreter), define 'breakpoints' (lines at which the program will pause), inspect the values of variables at run-time, and get a 'call stack' (list of function calls that got you where you are in the code). Very useful, but unfortunately, many debuggers suffer bugs, or are hard to understand; with the exception of JIT (just-in-time) debuggers like DrMingw - these programs only kick in after the program crashes; they will then show you where and how the program crashed (though it's up to you to figure out why).
</quote>There is an option in Dev-C++ to "execute your code step-by-step" that let's you debug your programs. If you look at the bottom of Dev-Cpp you can find the debug tab. Click it and click debug and it will run the debugger that lets you run your code step by step.
And about your allegro library not being installed right. Install Dev-Cpp on your computer, then either download Allegro off the site, off of the devpaks.org, or find it under Tools -> Check for Updates/Packages... in Dev-Cpp. Once you have the .zip folder or the devpak folder, go into the package manager (Tools -> Package Manager) click install, then find the folder. Go through the wizard and it will be properly installed. You can do the same for the DirectX Stuff and they both will be installed. I haven't had anymore problems with Dev-Cpp when I did it this way. I still for some reason have to add the liballeg.a file, though.

The linker won't pick one at random - that would be just fine in most cases (except that it generates unnecessarily long compile times). It will complain that several distinct functions with identical signature exist.

gcc link will not. It will always use the first one in the list of libs you give it. This is useful sometimes as it allows you to override functions in Allegro (e.g. you copy the Allegro function into your source file and add extra debugging code)

Uhhh... no? Visual Studio is weird. I've been using Dev-Cpp for a few years before I switched to plain old Programmer's Notepad 2 and MinGW32 and never had any serious problems with it.