Hi,
i got no idee what coul be wrong.
It will not work
a simple example:
I have build a beginner code:
#include "allegro.h"
int main(int argc, char **argv)
{
allegro_init();
allegro_message("Hallo Welt!");
}
END_OF_MAIN();
and send the exe to a friend
but he said the he couldnt run it
and that theres everytime an erro message
but i could run it without problems
Is there any way to clear that problem?
We are not psychic. We can't guess what error messages you are getting. And you haven't even read the FAQ from what I can see.
ok it was the alleg40.dll
alleg40.dll
And you are using Allegro 4.0 because...
is that alright ?
char **argv)
a poitner to pointer ?
use a single pointer then... and try.
ciao
... no, that's entirely correct. Stop giving shoddy advice.
Max S:
When you sent that code to your friend, did you already compile the program, or just sent it as a text file?
If a text file so your friend could compile it himself, then your friend needs to have:
1) A compiler
2) Allegro, compiled and ready-to-go
3) Allegro's libraries somewhere in the path.
If you sent the resulting executable from compiling it himself, then your friend does not have the Allegro DLL. Put the DLL either in the same directory as the executable you sent him, or somewhere common like "C:\Windows\System32", or else compile that program yourself as STATIC so the Allegro DLL is included and he won't need to get the DLL separately.
ok it was the alleg40.dll
I think the OP has worked out what the problem was.
[edit]
However, I agree with TT that Statically linking the dll, as this does seem an easier way of distributing the program.
[/edit]
For small programs, static-linking often means that there is only the .exe to distribute, nothing else, which is a good thing.
Larger projects often come with an editor, one or more datafiles, and a more or less complex directory structure; these will have to be zipped anyway, and the benefit of static-linking is gone. In those cases, if more than one .exe in the package uses allegro, dynamic linking is usually a better choice (re-uses code at run-time).
Ok,
here is the next problem:
#include <allegro.h>
int main(int argc, char *argv[])
{
allegro_init();
install_keyboard();
set_color_depth(32);
set_gfx_mode(GFX_AUTODETECT, 640, 480, 0, 0);
BITMAP *my_pic = load_bitmap("C:\Programmierung\life.bmp",NULL);
acquire_screen();
clear(screen);
blit(my_pic, screen, 0, 0, (SCREEN_W - my_pic->w)/2, (SCREEN_H - my_pic->h)/2, my_pic->w, my_pic->h);
release_screen();
readkey();
destroy_bitmap(my_pic);
while(!keypressed());
}END_OF_MAIN()
what could be wrong with this code???
i could compile it but if I start it the programm chrashes.
1) Edit both your posts to use code tags so they're actually readable. See the "Help" tab for how to use them.
2) You're neither checking set_gfx_mode() nor load_bitmap() to see if they succeed or not (hint: the path you're giving load_bitmap() is not what you think it is).
^
|
What gnolam said.
C needs you to write \\ when you mean a single \ as a character.
finally it works!
sorry for my stupid questions. I havent written codes since 2 years.
C needs you to write \\ when you mean a single \ as a character.
Wouldn't a / suffice?
For all Allegro functions, yes.
For all C file I/O functions.
Wow, gnolam, this is news for me, and completely true.
Here's a long thread that explains the issue:
http://mail.python.org/pipermail/python-list/2003-September/226671.html
To make it short:
Internally, DOS has "always" accepted '/' as well as '\', but up to windows 98 and 2000 included, the shell refused '/' in command names, and in the arguments of its shell commands (cd, copy, etc).
Now does every program today accept both? Notepad.exe on winXP still refuses to save c:/test.txt...
Now does every program today accept both?
It's a valid filename, but Notepad is using Windows file naming functions, which, among other things, say that "/" is an invalid filename character (what the problem is is that it's a directory separator in this case, not a file name).