If you don't want to be exposed to sloppy code stop reading...
Ok, this is the problem: I validate the set_gfx_mode and it returns a proper 0.
But there is a problem.
If it wasn't for a hilarious typing mistake I wouldn't have noticed it.
(The program doesn't work properly if I remove it either, that's why I started checking all the values and there seems to be no error after that.)
If I compile with mingw I don't get any error message, just a blank-out like nothing happened.
But if I compile with DJGPP it says (or something):
Error in line: 220
Not a Mode-X colordepth
This shouldn't happen. I've compiled dozens of times with DJGPP on that computer and never had that problem. It shouldn't be reverting to mode-x.(I run it under windows 95). Also the line where I check SET_GFX_MODE never returns a non-zero.
It doesn't seem to load my image either, but that's no surprise.
Here's the startup:
1 | void my_error(int); |
2 | |
3 | int main(int argv, char* argc){ |
4 | |
5 | char ted[24]; //I'll get rid of these |
6 | int reeks[6] ={0,2,6,8,9,10}; // soon enough... |
7 | allegro_init(); |
8 | |
9 | if(install_keyboard()) my_error(__LINE__);//?set_keyboard_rate(1000,0);key_led_flags = 0; |
10 | |
11 | set_color_depth(16); |
12 | if(set_gfx_mode(GFX_AUTODETECT,640,480,0,0)) my_error(__LINE__); |
13 | |
14 | BITMAP * my_buffer = create_bitmap(640,480); //Falsch |
15 | if(!my_buffer) my_error(__LINE__); |
16 | BITMAP * main_field = create_sub_bitmap(my_buffer,0,80,640,400); //Falsch |
17 | BITMAP * status_field = create_sub_bitmap(my_buffer,0,0,640,80); //Falsch |
18 | if(main_field != 0|| status_field != 0)my_error(__LINE__); // :-[ ::) this is line 220 |
19 | sam::character pokiponman(load_bitmap("BB.BMP",NULL),reeks,32,59); |
And if I make everything so it does work in mode-x I get a traceback of 1 line(!)
which says something about a DJGPP wrapper (or something).
And as it doesn't work with mingw either, I probably made some obvious noobish misstake...
Noobish source attached.
(I use allegro 4.2.1 with DJGPP and 4.2.0 with mingw)
I'll be very grateful to any non-noob willing to waste his (or less likely her) time on this.
Hmmm... quick thought:
if((main_field != 0) || (status_field != 0))my_error(__LINE__);
I'm not very good with operator precedence, but your original statement may or may not evaluate to:
if((main_field != (0 || status_field)) != 0)my_error(__LINE__);
which is equivalent to
if((main_field != status_field) != 0)my_error(__LINE__);
which in turn can be boiled down to
if(main_field != status_field)my_error(__LINE__);
...which is very likely to be true.
Not sure though, I might have operator precedence wrong.
The safest check would be:
if(main_field || status_field)my_error(__LINE__);
...but even this doesn't make too much sense; it means that if the creation of any of the 2 sub-bitmaps was successful, you throw an error. I think you mean the opposite:
if(!main_field || !status_field)my_error(__LINE__);
Try this and see if it fixes the error.
That was the hilarious typing misstake I was talking about...
As for all the other consequenses, read my first post. Besides, there shouldn't be an allegro_error at this point if everything worked properly.
[MAGIC EDIT looking into future]
Allegro_error is initialized at this point otherwise the output would have been different (i.e. just "error in line 220"). And it is a relevant message, because Mode-x only supports 8bpp and I (only) tried 16. Please read my post more carefully.
Oh, there's one thing I forgot to mention: in one version I just changed set_color_depth(8). Which results in another error namely: Not a proper mode-X resolution. And it still it only catches this in line 220... Bizarre!
If there has been no error, then allegro_error is undefined (i.e. cannot be trusted to tell you anything meaningful). Inspecting allegro_error makes sense only if an allegro function call has failed.
Not related to the error, but...
(main_field != 0) || (status_field != 0) // Equivalent main_field != 0 || status_field != 0 // Furthermore (main_field != (0 || status_field)) != 0 // NOT Equivalent (main_field != status_field) != 0 // Correct reduction main_field != (bool) status_field
weapon_S: Just print out the value of your driver name:
textprintf_ex(screen, font, 2, 2, -1, 0, "I am using graphics driver %s", gfx_driver->name); readkey();
Thought I might be wrong...
I fixed it (I think).
I had a function definition at the end of main. I think it confused END_OF_MAIN.
Whatever it was it's working (kind of) properly now.
main_field != (bool) status_field
As with many mathematic deductions it's not the same, because if they're both true I get true. Which isn't the case with the original expression,... I think.
I had a function definition at the end of main. I think it confused END_OF_MAIN.
Just for your information, that wasn't the problem.